MDA with Executable UML

Welcome Model Driven Architecture with Executable UML

Cambridge,June 17

Chris Raistrick, Kennedy [email protected]

2

Agenda

The MDA ProcessDomain ModellingExecutable UMLIntegrating ModelsSystem Generation

Chris Raistrick

[email protected]

Model Driven Architecture with Executable UML

Cambridge,June 17 Introduction

4

Important TLAs

This presentation describes

a process for system development, known as

Model Driven Architecture (MDA)Model Driven Architecture (MDA)

which involves building

Platform-Independent Models (PIMs)Platform-Independent Models (PIMs)

from which we derive

Platform-Specific Models (PSMs)Platform-Specific Models (PSMs)

and/or

Platform-Specific Implementations (PSIs).Platform-Specific Implementations (PSIs).

The models are represented using the notation known as the

Unified Modeling Language (UML).Unified Modeling Language (UML).

Both the MDA process and the UML notation

are owned by the non-profit consortium known as the

Object Management Group (OMG).Object Management Group (OMG).

seeomg.org/mda

5

Platform Independent Model

A Platform Independent Model (PIM) is a technology agnostic model of some aspect of the system under study.

A PIM contains no information about any of the following:

Hardware Architecture

Operating System

Programming Language

Database Technology

Internal Communication Technology

It is therefore much simpler than a Platform-Specific Model (PSM)

PIMs built using xUML can be:

Executed to demonstrate compliance with functional requirements

Automatically translated into a complete Platform Specific Implementation using a suitable model translator

Used as executable specifications, forming the basis for contract-based procurement

6

What is Special about MDA with xUML?

MDA with xUML provides an approach based upon building models that are:

preciseprecise

completecomplete

platform-independentplatform-independent

testable.testable.

Such models allow us to follow a process with some interesting qualities…

…which will be revealed as the afternoon progresses…

…and which put software engineering on a par with other engineering disciplines.

7

Real Engineers Do It Rigorously

Establish a well-defined and automated construction process

Build precise,predictive models

Subject the models to rigorous testing before

implementation

To build this

Construct the system from large, reusable components

The MDA process can be summarized as:

SPECIFY DOMAINS

Identify New/Reused Domains

Model System Use Cases

VALIDATE PIMS

Execute Domain Use Cases

Execute System Use Cases

BUILD PLATFORM-INDEPENDENT MODELS(PIMS)

Model Domain Use Cases

Build Static Model - Class DiagramBuild Behavioural Model - State Charts & Operations

Build Action Model - State Actions & Methods

Compile and Debug PIMS

SPECIFY SYSTEMCONSTRUCTION PROCESS

Define/Buy PIM To PSI Mapping Rules

Build/Buy PIM Compiler

GENERATE SYSTEM

Apply PIM to PSI Mapping Rules(Execute PIM Compiler)

Perform Target Testing

Chris Raistrick

[email protected]


Cambridge,June 17 The MDA Process

9

MDA Maturity Scale

Code

“What’s amodel?”

Code

Model

Visualize

Code

Model

Synchronize

Code

Model

Synthesize

Model

“What’scode?”

We will focuson this maturity level

Model CentricCode Centric

10

MDA Maturity Scale

Code

“What’s amodel?”

Code

Model

Visualize

Code

Model

Synchronize

Code

Model

Synthesize

Model

“What’scode?”

Translation ProcessElaboration Process

Productivity

11

Translation-based Development

The Executable MDA (xMDA)

process represents an evolution of

traditional development processes…

Write HighLevel Language

(C++/Ada/Java…)

High LevelLanguage

Define HighLevel LanguageMapping Rules

HLLMapping Rules

Translate HighLevel Language

Machine Code

Traditional Software Development

Build PlatformIndependent Model

(xUML)

PIM

Define xUMLMapping Rules

xUMLMapping Rules

Translate xUML

HLL (C++/Ada/Java…)

xMDA Development

Chris Raistrick

[email protected]


Cambridge,June 17 Domain Modelling

13

Definition

A domaindomain is a separate real, hypothetical or abstract worldinhabited by a distinct set of classes that behave according to the

rules and policies characteristic of that domain.

A domaindomain is a separate real, hypothetical or abstract worldinhabited by a distinct set of classes that behave according to the

rules and policies characteristic of that domain.

AIRCRAFT

It is a policy of Air Traffic Control that I must remain at least 3 miles horizontally

and 1000 feet vertically from all other aircraft

Class in Air Traffic Control Domain(a “real” world)

Class in Air Traffic Control Domain(a “real” world)

ICON

It is a policy of this User Interface that I must become translucent if I am in front

of another icon

Class in User Interface Domain(an “abstract” world)

Class in User Interface Domain(an “abstract” world)

14

Source: http://www.webopedia.com/img/OSI_Model.jpg

A Standardised Domain Model

15

Pattern: Domains to Isolate Areas of Change

Technology Independent Domain

Provides standard interface services

Maps to standard interface services to technology-specific services

Technology 1

Provides technology-specific interface services

Technology n

16

Pattern: Domains to Isolate Areas of Change

User Interface

Provides standard interface services

Textual User Interface

Maps to standard interface services to technology-specific services

Graphical User Interface

Provides technology-specific interface services

displayIcon displayText

display3DEntity

17

Plug and Play Weapons

In a perfect world…It should be possible to load any of these weapons…

…onto any of these airframes……and make available a set of common core capabilities…

…even if some weapon-specific capabilities are not available

18

Software System

Plug and Play Domain Architecture

Communications

Future CommsTechnology

Existing CommsTechnology

Weapon Control

Future WeaponExisting Weapon

Target Hardware

xUML Execution Platform

AnyLanguage

AnyOperating System

Achieves weapon type independence

Achieves execution platform independence

Achieves comms platform independence

Weapon specific plug-ins

Comms specific plug-ins

Language specific plug-ins

19

Counterparts

Each real-world thing can be represented as different abstractions in various domains...the counterpart classescounterpart classes, linked via counterpart associationscounterpart associations

The Contact Class“A correlatedradar contact”

The Contact Class“A correlatedradar contact”

The Aircraft Class“A piloted aircraftin controlledairspace”

The Aircraft Class“A piloted aircraftin controlledairspace”

The Icon ClassA shape with context-sensitivepop-up menu options

The Icon ClassA shape with context-sensitivepop-up menu options

AirTrafficControl

GraphicalUserInterface

RadarDataProcessing

Aircraft

Fuzed Track

Icon

The Class Class“An encapsulation ofdata and operations”

The Class Class“An encapsulation ofdata and operations”

PIM-PSMMapping

Class

Chris Raistrick

[email protected]


Cambridge,June 17 Executable UML

21

Primary xUML Artefacts

5. Define Class Interfaces

Domain: Interaction Diagram

1. Capture Requirements

System:Use Cases

2. Partition into Domains

System: Domain Model

3. Define Domain Interfaces

Use Case:Sequence Diagram

4. Specify Classes

Domain: Class Model Class: State Model

6. Specify Behavior

22

Use Case Model

Use cases specify the capabilities to be provided by the system, and how they interact with humans (e.g. Pilot/Ground Crew) and equipment (e.g. Carriage/Weapon Hardware)

23

Domain Model

Domains specify the subject matters, or areas of expertise, on our system.

Domains are organised into layers, each providing services to those above, and requiring services of those below.

For each domain we will build a Platform Independent Model

24

Sequence Diagram

The Sequence Diagram helps identify the domain interfaces needed to support each Use Case

Sequence Diagram for Use Case:

Use Case Model

Domain Model

25

Classes

Classes identify the things that exist with a domain. Ideally, they represent things in the “real world” of that domain.They establish the vocabulary of the domain, or area of expertise.For example, the “Weapon Management” domain might contain this class…

26

Attributes

Attributes specify what we know about each thing (or class).They are analogous to data.

27

Associations

Associations capture real-world connections between classes.

28

Operations

Operations specify what we can do to each thing.They are analogous to code.

29

Operations and Methods

Every operation has a method……which can be specified using a standard 3GL, such as C++……or a UML action language as in this example

Find a set of objects

Invoke an object-scoped operation

Create a link

30

Internalinterface

Externalinterface

Internal and External Interfaces

The Class Interaction Model shows the interfaces within the system, and between the system and the outside world.In this view, “Actors” are represented as <<terminator>> or <<interface>> classes.

Use Case Diagram

Class Interaction Model

31

DomainsClasses

Operations

States

The xUML Model Structure

xUML Model(PIM)

Platform-SpecificConfiguration

System Model

32

Isn’t xUML with ASL Just Coding in Another Language?

Yes…but…

…as xUML “programmers”, we do not need to clutter our minds or our models with:

Code distribution decisions, with consequential additional components such as inter-node communication skeletons and stubsData distribution and replication, with consequential additional components to manage the distributed collectionData structure decisions, with consequential code to access the structuresShared resource locking

…and we can easily change our minds about:Static or dynamic memory managementThreading strategyData persistenceTarget language

…without changing the xUML model

Chris Raistrick

[email protected]


Cambridge,June 17 Integrating Models

34

Elements of a Domain’s Interfaces

Each domain can be thought of as an “integrated circuit” of classes (the black box)……with a set of provided and required interfacesprovided and required interfaces (the ports)……that can be connected together into a system (the connectors)

AirTrafficControl

requiredinterfaces

UserInterface

providedinterfaces

bridge operations

35

Required Interface

AirTrafficControl

requiredinterfaces

UserInterface

providedinterfaces

bridge operations

Air Traffic Control Domain(part of) Class Collaboration Diagram

<<association terminator>>Air TrafficController

Aircraft

requestTaxi

requiredoperation

Attaching an association terminator to a class makes it eligible for

participation in counterpart relationships

The Required Interface consists of operations attached to <<terminator>> classes

36

Provided Interface

AirTrafficControl

requiredinterfaces

UserInterface

providedinterfaces

bridge operations

User Interface Domain(part of) Class Collaboration Diagram

Icon<<association terminator>>

Client

makeIconFlash

providedoperation

The Provided Interface consists of operations attached to domains or classes, and signals attached to classes

37

Air Traffic Control Domain(part of) Class Collaboration Diagram

<<associationterminator>>Air TrafficController

Aircraft

requestTaxi

requiredoperation

User Interface Domain {kl=UI}(part of) Class Collaboration Diagram

Icon<<association terminator>>

Client

makeIconFlash

providedoperation

The “Wiring” Is Specified in a Build Set…

Air Traffic Control System Build Set

CPR1

counterpart association

bridge: requestTaxi

counterpartIcon = this -> CPR1

$USE UI [ ] = ICN2:makeIconFlash[ ] on counterpartIcon

$ENDUSE

Bridge operation

Counterpart associations can be established between classes with at least

one association terminator

Chris Raistrick

[email protected]


Cambridge,June 17 System Generation

39

The Code Generator: Domains

(Part of) Code Generator Domain Chart

Populate Generate

xUML Model(PIM)


System Model Code Generator

GeneratedCode

xUML RuntimeLayer

Generated System

AdaptationLayer

xUML-CodeMappings

CodeGenerator

The code generator itself is a set of domain models expressed using

xUML.

The domains represent the various components of an xUML system.

40

(Part of) Configurable Code Generator

Domain Chart

The Code Generator: Classes and Methods

CodeGenerator

Code Generator

xUML-CodeMappings

(Part of)Executable UML

Class Model

the classes in each domain represent the elements that make up those components.

Method to Generate Java

Method to Generate Ada

Method to Generate C++

Method to Generate C…$FORMAT header_filetypedef struct C[I:this.class_ID]_struct { /* "[T:this.class_name]" Class Header */ struct s_object *next_instance;$ENDFORMAT…

Each element contains operations which specify how to map that xUML element onto a specific

target language.

41

Platform Independent Model : Class Diagram

Build a PIM

The domain experts build PIMs using xUML, such as this one:

Populate Generate

xUML Model(PIM)


System Model

xUML-CodeMappings

CodeGenerator

Code Generator

GeneratedCode

xUML RuntimeLayer

Generated System

AdaptationLayer

42

Domain Instance

Class Instances

Attribute Instances

Instantiate the Formalism Metamodel

Populated Executable

UMLClass Model

Populate

xUML Model(PIM)


System Model

xUML-CodeMappings

CodeGenerator

Code Generator

When the Executable

UML domain is populated with

the PIM components, we see these instances…

43

The Metamodels Embody the Code Generation Rules

Domain.generateCode

Class.generateCode

Attribute.generateCode

The task of translation involves iterating

through these instances and

generating suitable code from them.

CodeGenerator

Code Generator

xUML-CodeMappings

44

Platform Independent Model : Class Diagram

Generated C Code

Generate

Generate the Code

Generate

xUML-CodeMappings

CodeGenerator

Code Generator

GeneratedCode

xUML RuntimeLayer

Generated System

AdaptationLayer

45

Code Generation Overview

Populate Generate

xUML Model(PIM)


System Model

xUML-CodeMappings

CodeGenerator

Code Generator

GeneratedCode

xUML RuntimeLayer

Generated System

AdaptationLayer

PLATFORM SPECIFIC CONFIGURATION FILE

PROCESS "Process One" ONE 1 127.0.0.1 1000 1600PROCESS "Process Two" TWO 1 127.0.0.1 1001 1601

CLASS-PROCESS WM TGT ONECLASS-PROCESS WM WPN TWO

(part of) xUML Metamodel

Domain

Class

Attribute

owning_domain = this -> R2

$FORMAT header_filetypedef struct D[I:owning_domain.domain_ID]_C[I:this.class_ID]_struct { /* "[T:this.class_name]" Class Header */ struct s_object *next_instance; /* Linked list of */ struct s_object *prev_instance; /* object instances */ struct s_object *rel_ptr; /* list of rel'ns */ struct s_object *cpr_ptr; /* list of cp rel'ns */$ENDFORMAT

{attributes_in_class} = this -> R3for the_attribute in {attributes_in_class} do [] = ATT1:generateCode [header_file] on the_attributeendfor

$FORMAT header_file};

$ENDFORMAT

Multi-node multi-process runtime

Windows Vista adaptation layer

Chris Raistrick

[email protected]


Cambridge,June 17 Summary

47

Primary Artefacts

5. Define Class Interfaces

Domain: Interaction Diagram

1. Capture Requirements

System:Use Cases

2. Partition into Domains

System: Domain Model

3. Define Domain Interfaces

Use Case:Sequence Diagram

4. Specify Classes

Domain: Class Model Class: State Model

6. Specify Behavior

48

MDA: Models, Metamodels and Mappings

Class

UML

Type Of Aircraft

ATC

Actual Aircraft

<<instance of>>

Air Force 1:Actual Aircraft

ATC Objects

<<instance of>>

Radar Measurement

RADAR

Fuzed Track

<<model time>>CPR

Package

Ada<<cgen time>>

CPRM2

M1

M0 Fuzed Track 50:Fuzed Track

RADAR Objects

<<instance of>>

<<run time>>CPR

49

Maintainability vs. Executability

PSM

(UML)

manually build a Platform Specific

Model…

manually code a Platform Specific Implementation

PSI

(Code)

manually build a Platform

Independent Model…

PIM

(UML)

Elaborate

Compromise between

maintainability and

executability

In classic approaches, the PSI (code) must be built to be maintainable, typically by incorporating layering and encapsulation……which have a detrimental effect on speed and size of the executing system

PSI

(Code)

automatically generate a

Platform Specific Implementation using PIM-PSI

mappings

manually build a Platform

Independent Model…

PIM

(xUML)

Translate

Built for executability

Built for maintainabili

ty

In translation-based approaches, the maintained entity (the PIM) is built for maintainability with

layering and encapsulation…

…while the executable entity (the PSI) is optimized for

execution efficiency

50

Key Facets of MDA with xUML

K E N N E D Y C A R T E R1

R e a l E n g i n e e r s D o I t R i g o r o u s l y

C o n s t r u c t t h e s y s t e m f r o m l a r g e , r e u s a b l e c o m p o n e n t s

B u i l d p r e c i s e ,p r e d i c t i v e m o d e l s

S u b j e c t t h e m o d e l s t o r i g o r o u s t e s t i n g b e f o r e

i m p l e m e n t a t i o nT o b u i l d t h i s

E s t a b l i s h a w e l l -d e fi n e d a n d a u t o m a t e d c o n s t r u c t i o n p r o c e s s

K E N N E D Y C A R T E R1 1

A c t i o n S p e c i f i c a t i o n L a n g u a g e :

S t a t e a c t i o n s a n d c l a s so p e r a t i o n s a r e s p e c i f i e d u s i n gt h e A c t i o n S p e c i f i c a t i o n L a n g u a g e ( A S L )

A S L i s a h i g h e r o r d e r a n d m u c h s i m p l e r l a n g u a g e t h a n a t y p i c a l h i g h o r d e r l a n g u a g e ( e . g . J a v a )

A S L d e a l s w i t h U M L c o n c e p t s , n o t i m p l e m e n t a t i o n c o n c e p t s

A S L i s a c o n c r e t e l a n g u a g e f o r t h e U M L A c t i o n S e m a n t i c s

A c t i o n S p e c i f i c a t i o n L a n g u a g e :

S t a t e a c t i o n s a n d c l a s so p e r a t i o n s a r e s p e c i f i e d u s i n gt h e A c t i o n S p e c i f i c a t i o n L a n g u a g e ( A S L )

A S L i s a h i g h e r o r d e r a n d m u c h s i m p l e r l a n g u a g e t h a n a t y p i c a l h i g h o r d e r l a n g u a g e ( e . g . J a v a )

A S L d e a l s w i t h U M L c o n c e p t s , n o t i m p l e m e n t a t i o n c o n c e p t s

A S L i s a c o n c r e t e l a n g u a g e f o r t h e U M L A c t i o n S e m a n t i c s

A c t i o n M o d e l B U I L D P L A T F O R M - I N D E P E N D E N T M O D E L S( P I M S )

B u i l d A c t i o n M o d e l - S t a t e A c t i o n s & M e t h o d s


A i r T r a ffi c C o n t r o l D o m a i n { k l = A T C( p a r t o f ) C l a s s C o l l a b o r a t i o n D i a g r a m

< < t e r m i n a t o r > >A i r T r a ffi c C o n t r o l l e r

A i r c r a f t

r e q u e s t P e r m i s s i o nT o T a x i

r e q u i r e do p e r a t i o n

U s e r I n t e r f a c e D o m a i n { k l = U I }( p a r t o f ) C l a s s C o l l a b o r a t i o n D i a g r a m

I c o n{ k l = I C N }

< < t e r m i n a t o r > >C l i e n t

m a k e I c o n F l a s h

p r o v i d e do p e r a t i o n

T h e “ W i r i n g ” I s S p e c i f i e d i n a B u i l d S e t …

A i r T r a ffi c C o n t r o l S y s t e m B u i l d S e t

b r i d g e : r e q u e s t P e r m i s s i o n T o T a x ic o u n t e r p a r t I c o n = t h i s - > C P R 1$ U S E U I

[ ] = m a k e I c o n F l a s h [ ] o n c o u n t e r p a r t I c o n$ E N D U S E

C P R 1

B r i d g e o p e r a t i o n

c o u n t e r p a r t a s s o c i a t i o n

N o t e :

O p e r a t i o n n a m e s h a v e b e e n

s i m p l i fi e d f o r t h i s e x a m p l e . T h e f u l l

s y n t a x w i l l b e s h o w n l a t e r .


T h e A d a e x p e r t s

d e f i n e m a p p i n g s

o n t o A d a …

( p a r t o f ) G e n e r a t e d A d a f o r R a d a r D o m a i n

( p a r t o f ) A d a M e t a m o d e l

P a c k a g e

B o d y V a r i a b l e

S u b p r o g r a m C a l l

F o r m a l i s e t h e F o r m a l i s m s

… t h e A d a m a p p i n g s a r e a p p l i e d t o t h e R a d a r P I M o b j e c t s t o g e n e r a t e t h e R a d a r A d a

T h e r a d a r e x p e r t s i n s t a n t i a t e t h e “ x U M L M e t a m o d e l ” c l a s s e s …

( p a r t o f ) P I M f o r R a d a r D o m a i n

( p a r t o f ) x U M L M e t a m o d e l

C l a s s

A t t r i b u t e

S i g n a l G e n e r a t i o n

RigorousRigorouslightweightlightweight

processprocess

Precise simple Precise simple modelling modelling formalismformalism

SeparationSeparationof concernsof concerns

Formalised Formalised design and design and

implementation implementation policiespolicies

The End Model Driven Architecture with Executable UML

Cambridge,June 17

Chris Raistrick, Kennedy [email protected]