Driving MDA with UML: Principles and Practices Junichi Suzuki, - - PDF document

▶
driving mda with uml principles and practices
SMART_READER_LITE
LIVE PREVIEW

Driving MDA with UML: Principles and Practices Junichi Suzuki, - - PDF document

Sep 08, 2023 250 likes •497 views

Driving MDA with UML: Principles and Practices Junichi Suzuki, Ph.D. jxs@computer.org http://www.jks.la/jxs/ School of Information and Computer Science University of California, Irvine 1 Who am I? Research fellow, UC Irvine (2000-)

slide-1
SLIDE 1

1

Driving MDA with UML: Principles and Practices

Junichi Suzuki, Ph.D.

jxs@computer.org http://www.jks.la/jxs/

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.
slide-2
SLIDE 2

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
slide-3
SLIDE 3

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

slide-4
SLIDE 4

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

slide-5
SLIDE 5

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

slide-6
SLIDE 6

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

slide-7
SLIDE 7

13 14

slide-8
SLIDE 8

15 16

Vehicles Roadside 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

slide-9
SLIDE 9

17

TMC Network

D7 Sonet D12 Sonet D8 T1 Ring

170

8 8 12 12 7 7 11 11

D11 Telco

Hub

CCTV CMS

170

CCTV CMS

170

CMS CCTV

170

CCTV CMS

mnt. yd.

Other Corridor Initiatives

  • M. Link

Intercity Bus

  • Ext. USM

Seed Term Server EXTERNAL USERS

11 8 12 7

IMAJINE

LA/Ventura Orange San Bernardino/ Riverside San Diego

Firewalls Firewalls Firewall

Local Fielded Devices Local Ops Center SEEDS

Showcase Network

Regional Kernels CT TMC’s

LAN

CT FEP’s

WAN

FEP’s Network

CT Field Serial I/O

Corridor Deployment

18

Publishing Transportation Center(s) Subscribing Transportation Center(s) Showcase Kernel

Publishes Object Subscribes to Object Publishes Object Update Objects Meeting Subscription Criteria Filters flow of objects based on values of

  • bject parameters and

subscription criteria

1 2 3 4

slide-10
SLIDE 10

19

ConsumerAdmin_impl

(from Notification Service Admin P k )

BaseFilterFactory_impl

(from Notification Service Admin P k )

SCFilterFactory BaseFilter_impl

(from Notification Service Admin P k )

creates SupplierAdmin_impl

(from Notification Service Admin P k )

SCBaseFIlter_impl creates EventChannel_impl

(from Notification Service Admin P k )

creates PushConsumer_impl

(from Notification Service P k )

SCProxyPushSupplier 1 1 1 1 deliver message 1 1 1 1 evaluate criteria SCSupplierAdmin SCConsumerAdmin creates subscribe and unsubscribe 0..* 1 0..* 1 create, evaluate message PushSupplier connect SCProxyPushConsumer create evaluate message deliver message SCNotifyFilter::SCBaseFilter <<Interface>>

20

Sale Sales Line Item Item Customer

slide-11
SLIDE 11

21

Sale Sales Line Item Item 1 Sale Sales Line Item Item 1 1..* 1..* 1 0..1 1 0..* Customer 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

slide-12
SLIDE 12

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
slide-13
SLIDE 13

25

UML Profile for EJB

Entity bean 《EJBEntityBean》 Session bean 《EJBSessionBean》 Implementation class of a bean 《EJBImplementation》 Remote interface 《EJBRemoteInterface 》 Home interface 《EJBHomeInterface》 Java interface 《JavaInterface》

  • http://jcp.org/jsr/detail/26.jsp

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》 《import》 《extends》 《extends》 《extends》 《extends》

slide-14
SLIDE 14

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/02-01-04

– The initial proposals submitted (Sept. 02)

  • by Hitachi, GMD Fokus and UCI
  • sdo/02-09-01, sdo/02-09-02
  • 28 organizations on the voting list

– The revised joint proposal was submitted in March 2003.

  • by Hitachi, GMD Fokus and UCI
  • sdo/02-01-04

– The submission was recommended for adoption.

slide-15
SLIDE 15

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

SDOSystemElement OrganizationProperty DeviceProfile Status Organization 0..* 1 +organizations 0..* +owner 1 0..1 1 0..1 +properties 1 ServiceProfile ConfigurationProfile SDO 1 0..1 1 +deviceProfile 0..1 0..1 1 +status 0..1 1 0..* 1..* +organizations 0..* +members 1..* 0..n 1 +serviceProfile 0..n 1 0..1 1 +configurationProfile 0..1 1

slide-16
SLIDE 16

31

Devi ceProf i l e devi ceType : Stri ng m anuf acturer : Stri ng m odel : Stri ng versi

  • n

: Stri ng properti es : NVLi st Servi ceProf i l e i d : Stri ng i nterf aceType : Stri ng properti es : NVLi st servi ceRef : SDO Servi ce

SDO Enti ty O rgani zati

  • nProperty

properti es : NVLi st O rgani zati

  • n

di recti

  • n

: bool ean SDO i d : St ri ng sdoType : St ri ng +owner 1 0. . 1 +organi zati

  • ns

0. . * 0. . * 1 +pr

  • pert

i es 1 0. . 1 1 +organi zati

  • ns

0. . * +m em bers 1. . * 0. . * 1. . *

32

SDO Interfaces

SDO get C onfi gurat i

  • n()

: C onf i gur ati

  • n

get M oni tor i ng() : M oni tori ng get O r gani zat i

  • ns()

: O rgani zati

  • nLi

st get I D( ) : Stri ng get SD O Type() : Stri ng get Devi ceProf i l e() : Devi ceProf i l e get Servi ceProf i l es( ) : Servi ceProf i l eLi st get Servi ceProf i l e( i d : Stri ng) : Ser vi ceProf i l e Configuration + setDeviceProfile(dProfile : DeviceProfile) : void + addServiceProfile(sProfile : ServiceProfile) : void + addOrganization(organization : Organization) : void + removeDeviceProfile() : void + removeServiceProfile(serviceID : String) : void + removeOrganization(organization : Organization) : void + getConfigParameter() : ParameterList + getParameterValue(name : String) : any + setParameterValue(name : String, value : any) : void + getConfigurationSets() : ConfigurationSetList + addConfigurationSet(configurationSet : ConfigurationSet) : void + removeConfigurationSet(configurationSetID : String) : void + activateConfigurationSet(configID : String) : void <<Interface>>

Interfaces: SDO Organization Configuration Monitoring Callback

SDO SDO/application

slide-17
SLIDE 17

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. etc.

SDO PIM/PSM spec SDO (CORBA) PIM Future PSMs Future domain specialization, or Implementation specific part

slide-18
SLIDE 18

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
slide-19
SLIDE 19

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.

slide-20
SLIDE 20

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.

slide-21
SLIDE 21

41

Devise Bionet platform

Cyber-entities running

  • n 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

slide-22
SLIDE 22

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

slide-23
SLIDE 23

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