1 Driving MDA with UML: Principles and Practices Junichi Suzuki, Ph.D. School of Information and Computer Science University of California, Irvine

2 Who am I? Research fellow, UC Irvine (2000-) –biologically-inspired software designs for scalable and adaptable distributed computing Ph.D. from Keio U (2001) ex- Technical director, Object Management Group Japan ex.ex- Technical director, Soken Planning Co., Ltd.

3 Where is UC Irvine? UCI (U of California, Irvine) –One of eight UC system universities Irvine –in between LA and San Diego –reported by FBI, as the safest city in the US –1 hour to LA downtown –10 minutes to Newport Beach –20 minutes to Huntington Beach –20 minutes to Anaheim Disneyland –5 hours to Las Vegas

4 Overview MDA (Model Driven Architecture) –Model transformation and integration Patterns and technologies for model transformations MDA Practices –Standardization effort based on MDA principles OMG Super Distributed Objects specification –MDA practice for ubiquitous computing Bio-Networking Architecture

5 Traditional Modeling and Development Traditional modeling/dev tools Domain analysts, Modelers, Designers, Developers Domain expertise Platform/technology expertise Applications

6 MDA-based Modeling and Development MDA tools Platform experts Domain expertise Application developers Applications Domain experts Platform expertise Technology (logic impl) expertise

7 Goals in MDA Model continuation –Maximizing model continuation during software development process. Separation of concerns –Maximizing separation of concerns

8 Benefits from MDA Reduced software development cost Reduced software development time Rapid and smooth integration of legacy and emerging technologies

9 Model Transformation and Integration Model transformation –Domain specialization –Platform specialization Model integration –Model weaving MDA tools Platform experts Domain expertise Application developers Applications Domain experts Platform expertise Technology (logic impl) expertise

10 PIM PSM Source code Configuration files ・・・ Application Domain models Patterns model transformations generates/derives MOF XMI Model maintenance and exchange model transformations Model transformations MDA tools Platform experts Domain expertise Application developers Applications Domain experts Platform expertise Technology (logic impl) expertise

11 Model Transformation UML Java/EJB interface CORBA IDL ADL/ASL UML CWM PIM PSM Source code Configuration files ・・・ Application Domain models Patterns model transformations generates/derives MOF XMI Model maintenance and exchange model transformations Model transformations Action Semantics UML Profile for EJB UML Profile for CORBA UML Profile for RT sched Action Semantics UML Profile for EJB UML Profile for CORBA UML Profile for RT sched

12 Platform Independent Model (PIM) Modeled with –UML –ADL/ASL –Conceptual drawings may incorporate several software patterns –Architectural, analysis and design patterns

13

14

15

16 VehiclesRoadside Centers Dedicated Short Range Communications Travelers Wide Area Wireless (Mobile) Communications Wireline (Fixed-Point to Fixed-Point) Communications Vehicle to Vehicle Communications Vehicle Transit Vehicle Commercial Vehicle Emergency Vehicle Personal Information Access Remote Traveler Support Commercial Vehicle Administration Planning Toll Administration Emergency Management Traffic Management Fleet and Freight Management Transit Management Information Service Provider Roadway Toll Collection Parking Management Emissions Management Commercial Vehicle Check

17

18

19

20 Sale Sales Line Item Item Customer

21 Sale Sales Line Item Item 1 Sale Sales Line Item Item 1 1..* * Customer

22 Model Transformation 2 dimensions of model transformation –Domain specialization –Platform specialization Several forms of model transformation –Manual transformation –Automatic transformation Domain specificity Platform specificity

23 Technologies for Model Transformations UML profiles –for EJB –for CORBA –for Realtime scheduling Action semantics –allows modelers to embed actions (behaviors) into model elements.

24 UML Profiles A UML profile –provides a means to specialize UML models to a specific domain or implementation technology. –is defined with the UML extension mechanism i.e. stereotypes, tag definition/tagged values, and constraints –may extend the UML standard meta model. Virtual meta model

25 UML Profile for EJB 《 JavaInterface 》 Java interface 《 EJBHomeInterface 》 Home interface 《 EJBRemoteInterfa ce 》 Remote interface 《 EJBImplementatio n 》 Implementation class of a bean 《 EJBSessionBean 》 Session bean 《 EJBEntityBean 》 Entity bean

26 EJBHome Remote EJBObject CustomerServerHome +create():Customer 《 Interface 》 Customer +getCustomerEntry(name :String):String +setCustomerEntry(name :String):void CustomerServer +getCustomer (name :String):Customer import java.rmi.Remote; import java.rmi.RemoteException; 《 Interface 》 CustomerServerBean +ejbPassivate():Void +ejbActivate():void +ejbCreate():void +ejbRemove():void +setSessionContext(context:SesseionContext):void +getCustomer (name :String):void import.javax.ejb.*; import java.rmi.Remote; import java.rmi.RemoteException; Javax.ejb.SessionBean Javax.ejb.EnterpriseBean 《 implements 》 《 import 》 《 extends 》

27 Super Distributed Objects (SDOs) The goals of the OMG Super Distributed Objects (SDOs) DSIG (domain SIG) are to –provide a standard computing infrastructure that incorporates massive number of objects (SDOs) including hardware devices and software components –deploy SDOs in highly-distributed and ubiquitous environments, and –allow SDOs to seamlessly interwork with each other in a less centralized manner. SDO is... –a logical representation of hardware devices and software components operating on highly- distributed and ubiquitous networks.

28 History and status: –The SDO RFI issued ( ‘ 00), and responses gathered ( ‘ 01) from 10 organizations including UCI –The SDO white paper published ( ‘ 01) by Hitachi, GMD Fokus and UCI –The first RFP published (Jan. 02), which solicits the resource data model for SDOs, and interfaces to access and manipulate resource data model. sdo/ –The initial proposals submitted (Sept. 02) by Hitachi, GMD Fokus and UCI sdo/ , sdo/ organizations on the voting list –The revised joint proposal was submitted in March by Hitachi, GMD Fokus and UCI sdo/ –The submission was recommended for adoption.

29 SDO PIM and PSM Specification Addresses information and computational aspects for SDOs –Information aspect Resource data model, used to define the capabilities and properties of SDOs. –Computational aspect A set of interfaces, used to access and manipulate resource data model. Defines a PIM and PSM for each of the aspects. –UML used to define PIM. –CORBA IDL used to define PSM.

30 SDO Resource Data Model

31

32 SDO Interfaces Interfaces: SDO Organization Configuration Monitoring Callback SDO SDO/application

33 CORBA PSM CORBA PSM for SDO resource data model and interfaces module SDOPackage { interface SDO; interface SDOService; interface SDOSystemElement; interface Configuration; interface Monitoring; interface Organization; interface SDO : SDOSystemElement { UniqueIdentifier get_id() string get_SDO_type()

34 Scope of SDO PIM/PSM Domain specificity Platform specificity SDO PIM Echonet HAVi UPnP etc. SDO PIM/PSM spec SDO (CORBA) PIM Future PSMs Future domain specialization, or Implementation specific part

35 The Bio-Networking Architecture: An Example of SDO Implementations Computer network environment is seamlessly spanning locations engaged in human endeavor. Need a self-organizing network that supports –scalability in terms of # of objects and network nodes, –adaptability to changes in network conditions, –availability/survivability from massive failures and attacks, –simplicity to design and maintain. Our solution: apply biological concepts and mechanisms to network application design –Biological systems have overcome the above features. e.g. bee colony, bird flock, fish school, etc. The Bio-Networking Architecture is a new framework – for developing large-scale, highly distributed, heterogeneous, and dynamic network applications.

36 Biological Concepts Applied Decentralized system organization –Biological systems consist of autonomous entities (e.g. bees in a bee colony) no centralized (leader) entity (e.g. a leader in a bird flock) –Decentralization increases scalability and survivability of biological systems. –The Bio-Networking Architecture biological entities = cyber-entities (CEs) –the smallest component in an application –provides a functional service related to the application –autonomous with simple behaviors »replication, reproduction, migration, death, etc. »makes its own behavioral decision according to its own policy no centralized entity among CEs

37 Emergence –Biological systems Useful group behavior (e.g. adaptability and survivability) emerges from autonomous local interaction of individuals with simple behaviors. –i.e. not by direction of a centralized (leader) entity –e.g. food gathering function »When a bee colony needs more food, a number of bees will go to the flower patches to gather nectar. »When food storage is near its capacity, only a few bees will leave the hive. –The Bio-Networking Architecture CEs autonomously –sense local/nearby environment »e.g. existence of neighboring CEs, existence/movement of users, workload, availability of resources (e.g. memory space), etc. –invoke behaviors according to the condition in a local/nearby environment –interacts with each other

38 Lifecycle –Biological systems Each entity strives to seek and consume food for living. Some entities replicate and/or reproduce children with partners. –The Bio-Networking Architecture Each CE stores and expends energy for living. –gains energy in exchange for providing its service to other CEs –expends energy for performing its behaviors, utilizing resources (e.g. CPU and memory), and invoking another CE ’ s service. Each CE replicates itself and reproduce a child with a partner.

39 Evolution –Biological system adjusts itself for environmental changes through species diversity and natural selection –The Bio-Networking Architecture CEs evolve by –generating behavioral diversity among them, and »CEs with a variety of behavioral policies are created by human developers manually, or through mutation (during replication and reproduction) and crossover (during reproduction) –executing natural selection. »death from energy starvation »tendency to replicate/reproduce from energy abundance

40 Social networking –Biological systems (social systems) Any two entities can be linked in a short path through relationships among entities. –not through any centralized entity (e.g. directory), rather in a decentralized manner. –six decrees of separation –The Bio-Networking Architecture CEs are linked with each other using relationships. –A relationship contains some properties about other CEs (e.g. unique ID, name, reference, service type, etc.) Relationships are used for a CE to search other CEs. –Search queries originate from a CE, and travel from CE to CE through relationships. The strength of relationship is used for prioritizing different relationships in discovery. –A CE may change its relationship strength based on the degree of similarity between two CEs. –The stronger relationship is likely to lead a query to a successful discovery result.

41 Devise Bionet platform Cyber-entities running on a bionet platform Attributes Body Behaviors cyber-entity users CE ’ s Structure and Behaviors Behaviors –Energy exchange and storage –Communication –Migration –Replication and reproduction –Death –Relationship establishment –Social networking (discovery) –Resource sensing –State change Attributes –ID –Relationship list –Age –… etc. Body –Executable code –Non-executable data

42 Design Strategies of the Bio-Networking Architecture Separate cyber-entity (CE) and Bio-Networking Platform (bionet platform), –Cyber-entity (CE) mobile object (agent) that provides any service logic –Bionet platform middleware system for deploying and executing cyber-entities Model CE and bionet platform with UML –Using SDO PIM Implement CE and bionet platform in Java and CORBA –Using SDO CORBA PSM

43 Architecture of the Bio-Networking Platform Bionet Services Bionet Platform Bionet Container CE CE Context CE Java VM Bionet Message Transport A Cyber-entity (CE) is an autonomous mobile object. CEs communicate with each other using FIPA ACL. A CE context provides references to available bionet services. Bionet services are runtime services that CEs use frequently. Bionet container dispatches incoming messages to target CEs. Bionet class loader loads byte code of CEs to Java VM. Bionet message transport takes care of I/O, low-level messaging and concurrency. Bionet Class Loader

44 Scope of Bionet Implementation Domain specificity Platform specificity SDO PIM Bionet domain model SDO PIM/PSM spec SDO (CORBA) PIM Bionet implementation

45 SDO CORBA PSM Java interface CORBA IDL UML PIM PSM Source code Configuration files ・・・ Application SDO PIM Patterns model transformation generates/derives model transformations Model transformations Bionet domain model