INF5120 Modellbasert Systemutvikling Modelbased System development

Transkript

1 INF5120 Modellbasert Systemutvikling Modelbased System development Forelesning Arne-Jørgen Berre 1 Velkommen til INF5120 Modellbasert Systemutvikling Modellbasert Systemutvikling Tidligere: Modellering med objekter Forelesere: Arne-Jørgen Berre Brian Elvesæter Jan Øyvind Aagedal Birger Møller Pedersen, Øystein Haugen inf5120-forelesere@ifi.uio.no Øvingsansvarlige: Audun Strand, Kai Fredriksen inf5120-oppgaver@ifi.uio.no 2 1

2 Forelesning 1 - Introduksjon Introduction to the lectures and exercises Modeller og modellering Modellbasert Systemutvikling Architecture (Systems, Enterprises, Software,.) Principles of object orientation Systems Architecture and System modeling Enterprise Architecture - overview UML notasjon Strukturell modellering UML notasjon Oppførselsmodellering RUP (Rational) Unified Process -> COMET MDA Model Driven Architecture SOA Service Oriented Architecture Diskusjoner... 3 Målsetning med faget Modellbasert Systemutvikling - gjennom modellering med objekter Objektorientert -> Komponentbasert -> Tjenestebasert utvikling Gjenbruk Lære teknikker Unified Modeling Language (UML 2.0) for arkitektur m.m. MDA Modell drevet arkitektur med modelltransformasjoner SOA Service (Tjeneste) orienterte arkitekturer 4 2

3 Undervisning Forelesninger Dekker utvalgte deler av teorien i bok og kompendium Hovedboken gir en oversikt som kurset detaljerer videre gjennom forelesninger og øvinger Øvinger Bruke forelest stoff i praksis Case-oppgave på eksamen Eksempler i forelesninger og øvingstimer 5 Praktisk Forelesninger m/øvinger torsdager (Store) 10 studiepoeng, skriftlig, åpen bok eksamen En obligatorisk oppgave med to innleveringer og presentasjon/opposisjon Papirkopier av foiler på forelesning Oppdatert web før neste forelesning (27/1) 6 3

4 INF Forelesninger E: (Enterprise Architecture bok) ) C: (COMET kompendium) 1. Intro to System Modeling, Background: OO and UML, RUP, MDA, SOA 2. Enterprise Architecture - Enterprise Modeling (E1) 3. Business Modeling COMET methodology (C1) 4. Requirements Modeling COMET methodology (C2) 5. Enterprise and IT architecture (17. February DnD Software 2005) 6. UML 2.0 and UML SysML profile (UML 2.0 ref.) 7. Software Architecture and architecture modeling of services/components (E2) PIM modeling and PSM mappings/transformations (MDA, MOF, QVT) (C3) 8. Model transformation tools & QVT Modelware (JOEA) 9. Agile Methods and Agile Modeling, (17. March) F8 (E4) 10. Architectural Patterns, Design Patterns and Refactoring (E2-a) 11. Non-functional requirements OCL and Quality of service (JOEA) 12. Service Oriented Architectures UML profile, Interoperability and Data Architectures (E3) (E2-b) 13. Usability and human centered design (E5) 14. Aspect Oriented Computing, Agents, other PSMs 15. Product Lines Families, Frameworks, Reuse, RAS, Teamwork (E6) 16. LAST: Summary preparation for exam - endringer som bytte av rekkefølge etc. kan forekomme 7 INF Forelesninger / Kalender m/ansvar AJB: Arne-Jørgen rgen Berre JOEA: Jan Øyvind Aagedal BRE: Brian Elvesæter BMP: Birger MøllerM ller-pedersen, ØH: Øystein Haugen 1: 20/1: AJB 2: 27/1: AJB 3: 3/2: BRE 4: 10/2: BRE 5: 17/2: AJB (DnD seminar Software 2005 Virksomhets/IT Arkitektur) 6: 24/2: BMP/ØH UML 2.0 7: 3/3: AJB - BRE 8: 10/3: JOEA 9: 17/3: AJB (Agile Modeling and methodologies) fra kl / : 31/3: AJB - BRE 11: 7/4: JOEA 12: 14/4: BRE 13: 21/4: AJB 14: 28/4: BRE - AJB 15: 12/5: AJB - AJB 16: 19/5: BRE - AJB Eksamen: Torsdag 2. juni 2005 (tentativt) (minus 24/3: Påske, 5/5: Kr.HF.) 8 4

5 DnD Software 2005 torsdag 17. februar Hotell Radisson SAS Scandinavia, kl Sesjon Virksomhetsarkitektur i praksis Velkommen Søkemotorer og Informasjonsforvaltning Strategiske muligheter både fra virksomhet og IT-arkitektur perspektiver. Bjørn Olstad, FAST Search and Transfer Kaffepause Hva er egentlig arkitektur? Ole Gustavsen, Snøhetta og Bjørn Nordmoen, Western GECO 13. Virksomhetsarkitektur i praksis 14. IT-arkitektur for integrasjon trinn for å bygge en EA Paul Fosland, Computas AS DNV Maritime City plan et EA prosjekt i DNV Maritime Jørgen Kadal, Det Norske Veritas Vägen mot ett Enterprise Data Warehouse Arne Svedberg, FöreningsSparbanken Dynamic Enterprise Architecture Marlies van Steenbergen Erfaringer med virksomhetsarkitektur i Forsvaret. Ole Øyvind Stenslie, Forsvaret Virksomhetsarkitektur i Hafslund som motor for forretningsutvikling. Thomas Pettersen, Hafslund og Thorsten Keller, CommITment AS Felles oppsummering/paneldebatt Avslutning EAI Tools - Principles and the tool market Chris Sluman, OpenIT Ltd., UK Fra stormaskinarkitektur til integrasjonsarkitektur Sigmund Evjen, Rikstrygdeverket og Bjørn Arne Berge, Accenture Integrasjonsarkitektur i praksis Are Torgersen, IBM Certified og Håkan Hallberg, Zystems Altinn for sikker innrapportering Henning Normann, Accenture Integrasjon ved hjelp av EAI-verktøy Domstolene, NN Integrasjon som konkurransefortrinn Bjarne Birkeland, Walenius Wilhelmsen For studenter i INF5120 er deltakelse fra kl gratis, (- spesialpris for hele dagen kr. 750,- i stedet for kr. 4250,-) 9 Smidige Metoder (Agile Methods) - Ifi temadag torsdag 17. mars Store Auditorium, kl Velkommen Smidige metoder hva er det? pause Smidige metoder i praksis når virker det? Smidig modellering Øvingstime 10 5

6 Krav og forutsetninger Ingen formelle krav (student ved UiO) Kunnskaper tilsvarende INF-31(41)20, og INF5040 vil være en fordel Egeninnsats til lesing om UML notasjon (ref. også INF2120) (UML undervises nå i fag på lavere grad) se egen støttebok (Vi har en forelesning om nyheter i UML 2.0) 11 Book: A Practical Guide to Enterprise Architecture J. McGovern et.al., ISBN , 290 pages, Prentice Hall, : Systems Architecture 2: Software Architecture 3: Service Oriented Architecture 4: Software Product Lines 5: Methodology overview 6: Enterprise Unified Process 7: Agile Architecture 8: Agile Modeling 9: Presentation Tier Architecture 10: Usability and User Experience 11: Data Architecture 12: Thought Leadership 12 6

7 A Practical Guide to Enterprise Architecture (subject grouping for INF5120) 1: Systems Architecture and Enterprise Architecture (E1) 5: Methodology overview 6: Enterprise Unified Process 2: Software Architecture (E2) 3: Service Oriented Architecture 11: Data Architecture and Interoperability (E3) 7: Agile Architecture (E4) 8: Agile Modeling 9: Presentation Tier Architecture (E5) 10: Usability and User Experience 4: Software Product Lines (and Reuse) (E6) 12: Thought Leadership 13 A Practical Guide to Enterprise Architecture - Annexes A: Business case B: Practical Considerations C: The 7 habits of an Agile EA D: Models E: References F: Additional Reading G: Future Books 14 7

8 COMET - MDD for Interoperable Systems (Berre/Elvesæter/ ) kompendium *ny versjon februar 2005 vil oppgraderes til UML 2.0 og UML profil for bruk av IBM Software Modeler tool 1: Introduction to COMET overview/motivation/nutshell 2: An introduction to Interoperable Systems and Enterprise Architecture 3: An introduction to the sample application 4: Business Modeling and Enterprise Architecture 5: Requirements (Actors and use cases, User Experience ) 6: Architecture 7. Components and Design 8: Extra-functional requirements, Quality of Service 9: Implementation 10: Phases: Inception, Elaboration, Construction, Transition 11: Additional. Topics: Testing, Repository, Tool environment A: Profiles and stereotypes, B. MDA environment & tools/umt ++ X: Web Structure support COMET 15 UML 2.0 støttebok: The Unified Modeling Language Reference Manual, Second edition (ISBN ) (J. Rumbaugh, Booch, Jacobsson) 1: UML overview 2: The Nature and Purpose of Models 3: UML Walkthrough 4: Static View 5: Design View 6: Use Case View 7: State Machine View 8: Activity View 9: Interaction View 10: Deployment View 11: Model Management View 12: Profiles 13: UML Environment X: Reference Alphabetical definitions/examples, page

9 UML 2.0 UML 2.0 og SysML Background and Reference material See Også hos OMG: (UML) (MDA) (MOF, XMI, CWM) 17 other UML reference books UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd Edition covering UML 2.0) by Martin Fowler, Kendall Scott Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process (3rd Edition) by Craig Larman Object-Oriented Modeling and Design with UML (2nd Edition), J. Rumbaugh et. al., 2005, ISBN: Aspect-Oriented Software Development with Use Cases (Addison-Wesley Object Technology Series) by Ivar Jacobson, Pan-Wei Ng,

10 Støtte-bok: Software Factories, Assembling applications with patterns, models, frameworks and tools J. Greenfield & al (Microsoft), J. Wiley, ISBN: , 630 pages Introduction (Example=Construction Tools Incorporated) Dealing with Complexity, Dealing with Change, Paradigm Shift, Software Factories Models and patterns Programming with models (MDD-I) Language Autonomy Families of languages (MDD-II) Systematic Reuse - Software Product Lines (Reuse/Families) Platform Based Abstractions Components and services (Assembly/Orchestration) Mappings and Transformations Generating Implementations (Generative Programming) A Software Factory Example - FAQ Nesten valgt som pensumbok, men litt for Microsoft-orientert 19 Eksamen Case-basert oppgave (ref. tidligere eksamen) Alle skriftlige hjelpemidler er tillatt (3 timer) tentativt, torsdag 2. juni,

11 Modeller og modellering 21 Dealing with Complexity and Change Working at the right level of abstraction OO dealing with complexity objects -> components -> services *SOA Design by contract, role composition Aspect-oriented programming Use of patterns Visual Modeling (MDA) Arkitektur 22 11

12 Diskusjon Modellbasert Systemutvikling Sett dere sammen i grupper a 2-3 og diskuter begrepet: Modellbasert systemutvikling (5 min) 23 Objektorientert Modellering 24 12

13 OOAD metoder Class Phase Traditional SA/SD/ERA ANALYSIS DESIGN DETAILED DESIGN SA - Yordon SD - Page Jones ERA - Chen ER-Rel.db - 3NF SA-based OO ERA-based OO Hybrid SA/ERbased OO SD-basert OO Ada(C++)-based SDL-based OO OO-based OO RT SA - Wards OOA/OOD - Coad/Yordon OMT - Rumbaugh et. al OOAD - Martin/Odell Fusion - HP OOSD - Wasserman HOOD - ESA OOAD - Booch (93 w/c++) OSDL-92 - CCITT/Bræk et. al OOSE/ObjectOry - Jacobson RDOOD - Wirfs-Brock et. al CRC-cards - Cunningham OOram - Reenskaug et. al Catalysis, Syntropy, SOMA, OBA, BHS,... UML (96) Booch/OMT/ObjectOry 25 Evolution of the UML Submission of UML 1.1 to OMG for adoption, Sept 97 UML 1.0 UML 2.0 (2004) UML 1.4 UML 1.1 (Sept. 1997) Taskon, SINTEF public feedback June 96 & Oct 96 OOPSLA 95 UML 0.9 & 0.91 Unified Method 0.8 UML Partners Expertise Booch 93 OMT - 2 Other methods Booch 91 OMT - 1 OOSE 26 13

14 Hvorfor UML: Systemkompleksitet Enhet Enhet Omgivelse Subsystem Subsystem System 27 Hvorfor UML: Felles beskrivelse System Mental model arealworldphenomena A model is created for a purpose A model is never complete We think in multiple models The world is rarely hierarchical Manifest Model Objects 28 14

15 Evolution of methodologies OOram Catalysis Pulse OMT UML Components 2001 KobrA Booch UML1.0 Objectory UML1.1 Notation UP UML1.2 RUP UML1.3 UML1.4 UML4EDOC Process 2002 COMET UML2 29 Objektorientering, Begreper og konsepter Basis tanker Objekt Modellering Basis konsepter Klassifisering / Typer / skaping av individer Innkapsling Deling og Arv Polymorfi og dynamisk binding CRC kort 30 15

16 Historisk fokus Kvalitet og Produktivitet Modellering (mdlg) Abstraksjon og Modularisering Gjenbruk og Vedlikehold Funksjonell mdlg ( -55 -> ) Data mdlg (-60 ->) Simula mdlg av individer mdlg av individers oppgave ( -70 ->) Oppgave-behandlere / saksbehandlere [Oppgavefokus] SW Engineering + komplekse systemer fra velprøvete deler Abstrakte Data Typer Klassifisering Ferdiglagete deler / komponenter av gitt type [Eksterne egenskaper] Biblioteker ( -55 -> ) Komponenter og rammeverk ( -80 -> ) Patterns (-90 -> ) Vedlikehold kostbart Økende kompleksitet / størelse. [modulbygging] Splitt og hersk : store, komplekse problemer deles opp i et sett av små, selvstendige og enkle problemer. (i ett eller flere trinn!) 31 Skandinavisk Modellerings-perspektiv (Fra Simula) A program execution is regarded as a physical model, simulating the behaviour of either a real or imaginary part of the world. A physical model consists of objects, each object is characterized by attributes and a sequence of actions. Objects organize the substance aspect of phenomena, and transformations on substance are reflected by objects executing actions. Objects may have part-objects. An attribute may be a reference to a part object or to a separate object. Some attributes represent measurable properties of the object. The state of an object at a given moment is expressed by its substance, its measurable properties and the actions going on then. The state of the model is the states of the objects in the model

17 Basis for OO Teknologi Kvalitet og Produktivitet Modellering Abstraksjon og Modularisering Gjenbruk og Vedlikehold Klassifisering/ Instansiering Innkapsling Deling Arv Polymorfisme Objekt Modell 33 Objektorientert Modell En objektorientert modell er en (simulerings) modell som består av samspillende objekter i interaksjon med hverandre. En parallell i virkeligheten : en bil. Den består av et sett deler / komponenter som samvirker i et gitt mønster. ( ikke alle påvirker alle andre direkte; interaksjonene/samspillet er diktert av oppgaver og hensikt) 34 17

18 OO - SYN PÅ VERDEN SAMSPILLENDE OBJEKTER. Hvert Objekt: har klart ansvar vet om samarbeis partnerene er robust Ingen vet om det hele! Monolitisk Data storage Internal storage Disc 35 System and objects A system is a part of the real world which we choose to regard as a whole, separated from the rest of the world during some period of consideration. A whole that we choose to consider as a collection of objects, each object being characterized by attributes and by actions which may involve itself and other objects. Mental modell Real-World phenomenon Manifest Model 36 18

19 Object oriented modeling arealworld- Phenomena anobjectmodel rolemodels animplemented System Environment Model environment Mental model Real-World phenomenon System model Manifest Model 37 Noen ord om Objekt-Orientering En filosofi ; en måte å betrakte verden på En måte å spesifisere systemer på En måte å designe systemer på En måte å programmere systemer på Alt er objekter Det som skjer, hender ved at objekter agerer i samspill Peker mot oppdeling, distribusjon og delegering 38 19

20 OO Programming Terminology Encapsulation Object Message Method Class Instance Inheritance Polymorphism Dynamic (Late) Binding 39 CRC Method, class, responsibilities, and collaborators Method to learn the most basic OO concepts plus OO thinking The most effective way of teaching the idiomatic way of thinking with objects is to immerse the learner in the "object-ness" of the material. To do this we must remove as much familiar material as possible, expecting that details such as syntax and programming environment operation will be picked up quickly enough once the fundamentals have been thoroughly understood. Technique also very useful during informal and creative analysis and design Created by Kent Beck and Ward Cunningham, Textronix,

21 The CRC-Card an object of paper personalizing the object Class (Name): Responsibility: Collaborators: 41 Class, responsibilities, and collaborators Class The class name of an object creates a vocabulary for discussing a design. Indeed, many people have remarked that object design has more in common with language design than with procedural program design. We urge learners (and spend considerable time ourselves while designing) to find just the right set of words to describe our objects, a set that is internally consistent and evocative in the context of the larger design environment. Responsibilities Responsibilities identify problems to be solved. The solutions will exist in many versions and refinements. A responsibility serves as a handle for discussing potential solutions. The responsibilities of an object are expressed by a handful of short verb phrases, each containing an active verb. The more that can be expressed by these phrases, the more powerful and concise the design. Again, searching for just the right words is a valuable use of time while designing. Collaborators Objects which will send or be sent messages in the course of satisfying responsibilities. Collaboration is not necessarily a symmetric relation. For example in Smalltalk, View and Controller operate as near equals while OrderedCollection offers a service with little regard or even awareness of its client

22 CRC is Not distinguishing between Object Instance and Class It is not needed because the CRC-methods physical aspects where each class description becomes an individual physical object, a filing card. This enables the double role of class and object in discussion and analysis with no confusions. It gives an benefit the number of concepts to be handled and mastered are kept to a minimum!! 43 Card Playing Rules - Notation Every card represents possibly several objects at the same time (if needed) Overlapping cards implies close collaboration Positioned above a card implies that the object is controlled by this card A stack of cards implies hierarchical detailing of abstractions - the most abstract card is placed on top and represents the rest of the hierarchy 44 22

23 Card Playing Rules - Process Regard the cards as objects Start with the known, evolve towards the unknown Evolve design by 'playing' through scenarios (simulate execution) pick up the object which is executing and identify yourself with it create new objects or responsibilities founded on requirements / needs emerging during simulation. (not for some hypothetical future needs) Work in a team. A single person will have difficulties finding all requirements or scenarios. 45 UML og ( R )UP Two parts of a Harmonized Whole Unified Modeling Language Process Convergence Today Unification leads to standards Convergence in the future Process frameworks through consensus 46 23

24 UML Structural Modeling Class Diagram Object Diagram Component Diagram (new in UML 2.0) Package Diagram Deployment diagram 47 UML Behavioral Modelling Use Case Diagrams Interactions Sequence diagrams (enhanced in UML 2.0) Timing diagrams (new in UML 2.0) Interaction overview diagrams (new in UML 2.0) Communication diagrams (i.e. collaboration diagram) State machine diagrams (enhanced in UML 2.0) Activity Diagrams (enhanced in UML 2.0) 48 24

25 Different kind of models Conceptual models Specification models Implementation models 49 Utvikling/Trender for Utviklingsprosesser ? Fossefallsmodell Funksjonell design -Skalerings-økonomi Egne verktøy 100% skredder Ad hoc prosess Alltid: over tid/kost Prosess forbedring Innkapslings-basert -Skalerings-økonomi Uavhengige verktøy 30% komp 70% eget Gjentakbare prosess Uvisst: til tid / kost Iterativ utvikling Komponent-basert ROI Integrerte verktøy 70% komp 30% eget Admin/Målt prosess -Oftest: til tid og kost Source: Software Project Management, A Unified Framework, Walker Royce, Addison-Welsey,

26 10 viktige prinsipper for moderne systemutvikling Arkitektur-orientert tilnærming Iterativ livs-syklus prosess Komponentbasert utvikling Endrings-orientert miljø Round-trip engineering Modell-basert notasjon Objektiv kvalitets-kontroll Økende detaljeringsgrad Konfigurerbar prosess 51 Unified Process Framework Disciplines Process Components Process Requirements Workflows Analysis Business Modeling Requirements Architecture Level Analysis Design Design Implementation Class Level Test Implementation Deployment Inception Test Supporting Workflows Supporting Components Management Project Management Conf. Mngmt Process Configuration Environment preliminary iteration(s) iter. #1 Phases Elaboration Construction Transition iter. #2 iter. #n iter. #n+1 Iterations iter. #n+2 iter. #m iter. #m

27 Faser i livssyklusen Inception (Begynnelse/unnfangelse) Elaboration (Utdyping av planer, beskrivelse av egenskaper og basis arkitektur) Construction (Bygging av produktet) Transition (Overgang til brukere) 53 Requirements Analysis Core development disciplines.design Implementation Test 54 27

28 SA Find actors and use cases Structure use case model Plan and design test Evaluate test TE UCS Detail a use case Integrate system SI UID Prototype user interface Perform integration tes IT A Prioritise use cases Architectural analysis Arch. Design Arch. Impl Perf.sys. test ST UCE Analyse a use case Design a use case CE Analyse a class/package Design a class/package Implement class/ss -u.test Implement test 55 Model world Real world Context Business 0,1 model Goal Model Context statement Business Resource Model 0,1 Business model Scoping statements Context statement Goal Model Business Resource Model COMET Vision for change Risk analysis Business Process & Role Model Vision for change Risk analysis Business Process & Role Model -> WARM Work Element Analysis Model Requirements model Use case model Prototype System Boundary Concepts& Processes Actors Artifacts Business Domain RA Analysis * Busines domain to system domain mapping Work element analysis Use case refinement and RA analysis Architecture model Use case Scenario Model Workflow Service Domain Component structure and internal design Interface and interaction specification Platform specific model UMT Config model Component implementation model PIM Data Types User Service Domain Business Service Domain User Interface Tier User Service Tier User Resource Service Tier Business Service Tier Resource Service Tier RA Presentation Tier UserDialog Tier LA LS RA Component Infrastructure & Workflow Engine ( Microworkflow) Legacy System Domain Deployment 56 28

29 OMG Model-Driven Architecture (MDA) 57 MDA From Feet Use of platform independent models (PIM) as specification Transformation into platform specific models (PSM) using tools 58 29

30 MDA From Feet J2EE.Net A PIM can be retargeted to different platforms Not the only reason why MDA might be of interest to you 59 Automation in Software Development Requirements Requirements Requirements Manually implement Manually implement Manually implement Source in domain-specific language (DSL) High-level spec (functional and nonfunctional) Source in domain-specific language (DSL) Implement with Interactive, automated support Source in a general-purpose language, e.g., Java or C++ Compile (may generate code in Java or C++) (may generate code in Java or C++) Compile Compile Compile Compile Implementation Implementation Implementation 60 30

31 MDA and Agile Development MDA is appropriate for agile development Models are not just additional documentation artifacts, but they are the actual source Instant feedback through simulation / rapid code generation Model-based testing Domain-specific modeling languages may simplify communication with your customer 61 The Waves of Client/Server Technology First Wave Second Wave Third Wave Fourth Wave Fifth Wave MDA, Web Services,.Net Servers Distributed Server-side Service-oriente Objects componentsc File Database Architecture Servers OMG CORBA J2EE/EJBSOAP, XML COM/OLE COM+ WSDL/WSFL Web/Internett Corba Comp Java Groupware TP Monitors Base Source: Client/Server Survival Guide, 1994, 1996 Robert Orfali, Dan Harkey OS/2 Edition, VNR Computer library + AJB update 2004 P2P Agents, Grid FIPA SOA 31

32 Synchron. request Deferred Synch request Interaction/Pres services User Interface Document model Web interaction XML Message Streaming Event - publish & subscribe Naming service Discovery Trading service Multi Media, QoS Security service User services (application/process) Shared Business Services Data services & Legacy systems Integration service Workflow service System/Use Mngt Server Components Concurrency service Transaction service Persistence service 63 WSDL IIS, ASP+ XML/HTML SOAP HTTP UDDI -white -yellow - green pages WebServices WS Security SAML Interaction/Pres services User services (application/process) Shared Business Services Data services & Legacy systems XML/XSLT BPEL4WS Web Transactions? BTS Integration Server, CICS,

33 SOA Services Messages Dynamic discovery Web services 65 Service Oriented Architecture (SOA) definition A set of components which can be invoked, and whose interface descriptions can be published and discovered (W3C). The policies, practices, frameworks that enable application functionality to be provided and consumed as sets of services published at a granularity relevant to the service consumer. Services can be invoked, published and discovered, and are abstracted away from the implementation using a single, standards-based form of interface. (CBDI) (