30 Transformational Design with Essential Aspect Decomposition: - - PowerPoint PPT Presentation

Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie – Prof. Aßmann - Softwaretechnologie II

30 Transformational Design with Essential Aspect Decomposition: Model-Driven Architecture (MDA)

• Prof. Dr. U. Aßmann

Technische Universität Dresden Institut für Software- und Multimediatechnik Gruppe Softwaretechnologie http://st.inf.tu-dresden.de/teaching/swt2 Version 15-1.6, 15.10.15

• 1. EAI* for Modular Product

Lines

• 2. Model-Driven Architecture
• 3. Model Mappings
• 4. Marked PIM
• 5. Model Merging and Weaving

1. MDSD with domain-specific tagging

1

Softwaretechnologie II

References

Ø Obligatory:

• www.omg.org/mda Model driven architecture.
• MDA Guide. OMG (ed.). Reference document for MDA applications
• AndroMDA toolkit for MDA

§ http://www.andromda.org/andromda-documentation/getting-started-java/ index.html

Ø Optional:

• J. Frankel. Model-driven architecture. Wiley. Excellent book on the concepts of

MDA, including the MOF, model mappings.

• Manfred Nagl, editor. Building tightly integrated software development

environments: the IPSEN approach, volume 1170 of Lecture Notes in Computer

• Science. Springer-Verlag Inc., New York, NY, USA, 1996.
• CIP Language Group. The Munich Project CIP, volume 1 of Lecture Notes in

Computer Science. Springer-Verlag, 1984.

• Bauer et al. The Munich project CIP. Volume 1: The wide spectrum language CIP-

L, volume 183 of Lecture Notes in Computer Science. Springer-Verlag, Berlin, Germany, 1985.

• F. L. Bauer, et al. The Munich Project CIP. Volume II: The Transformation System

CIP-S. Springer-Verlag, LNCS 292, 1987.

• Prof. U. Aßmann

2

Softwaretechnologie II

Software Development in the V-Model

Ø The most simple software development process is the V-model

• Prof. U. Aßmann

Pre-Study

• Product concept catalogue

(Lastenheft)

Requirements Analysis

• Software Requirement Specification

(SRS)

Achitectural Design

• Architecture (Grobentwurf)

Detailed Design

• (Feinentwurf)

Implementation

Acceptance Test Installation, Beta Test System Test (in- house) Component, Subsystem Test Contracts, Class Tests

System test cases

Unit test cases

Acceptance test cases

3

Softwaretechnologie II

Problem: The Representation Schizophrenia

Ø Problem: Design Aging, one of the biggest problems in software

maintenance Ø If a system has several representations, such as design, implementation,

documentation, and code: always the code is modified, and the other become inconsistent

Ø Usually, a design specification ages faster than implementation, because the

programmers are tempted to change the implementation quickly, due to deadlines and customer requests

Ø Programmers “forget” to update the design

Ø Solution:

Ø XP: Single-source principle Ø don't represent in other ways that code Ø “clean code that works” Ø MDA: Generate the code from models, enable a round-trip to solve the problem

• Prof. U. Aßmann

4

Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie – Prof. Aßmann - Softwaretechnologie II

30.1 PRODUCT LINES WITH MODULAR VARIABILITY

• Prof. U. Aßmann

5

Softwaretechnologie II

Problem – Reuse in Product Lines (Product Families)

Ø Many products must be produced in variants for different platforms

(portability problem): Ø Machines ranging from PDA over PC to host Ø Component models from .NET over CORBA to EJB Ø Technical spaces such as Java vs .NET vs. Python

Ø How to develop a product line with products for all these platforms? Ø How to reuse common parts of products (programs)? Ø How to reuse common parts of models?

• Prof. U. Aßmann

6

A A pro roduct ct lin line re require ires a a mo modula larit rity tech chniq ique ( (co comp mponent mo model) )

Softwaretechnologie II

Employ Modularity (Modular EAI): Addition of Modules in the Essential Modules

Ø The product’s modules consist of essence, administration, infrastructure (EAI aspects) Ø Modular design adds administration and infrastructure components later (remember Parnas’ principle of information hiding)

I I A A E E I I A A E E E E E E E E E E E E E E E E E E I I A A

+ +

E E I I A A E E E E E E E E E E E E E E E E E E E E I I A A E E E E E E E E E E E E E E E E E E

• Prof. U. Aßmann

7

Softwaretechnologie II

Corollar: EAI-based Product Lines are Independent of the Component Model

Ø Be aware: This scheme works with all forms of modules, components, and architectural styles (see course CBSE)

• Modules, Functions, Actions, Processes, Packages, etc in programs
• Objects, slides in runtime systems
• Data-flow diagrams, ECA-modules in models
• Views in programs and models
• Prof. U. Aßmann

8

Softwaretechnologie II

Modular EAI with Partial System Configurations of Modules or Components

Ø The development process of Modular EAI adds administration and infrastructure views to the essence

• Prof. U. Aßmann

9

Essence Validated Essence: Essence + Administration Platform-specific: Essence + Administration + Infrastructure

+ +

Infra rast stru ruct cture re

+ +

Ad Admin minist istra ratio ion

Softwaretechnologie II

What Are Platforms?

Ø Platforms are concerns on the infrastructure, describing the environment

• n which a system runs
• Platforms slice a system into platform-independent (aspect-independent) and

platform-dependent parts (aspect-related)

Ø Possible platforms:

• Abstract machines

Ø Libraries, such as JDK, .NET

• Implementation languages

Ø Java, Eiffel, C#

• Component models

Ø CORBA, Enterprise Java Beans (EJB), .NET-COM+, JSF, Swing, etc.

• Ontology of a domain (e.g., medicine, cars, insurance)

§

SNOMED ontology, Gene Ontology

• Constraints of the system

Ø Time Ø Memory Ø Energy

Ø Platforms define variability levels of a system, with variants that produce a

variant of the specification

• Prof. U. Aßmann

10

Softwaretechnologie II

Modular EAI* with Partial System Configurations of Modules or Components

Ø The development process Modular EAI* adds several infrastructure views (platform views) to the essence

• Prof. U. Aßmann

11

Essence Validated Essence: Essence + Administration Platform-specific: Essence + Administration + Infrastructure

+ +

Infra rast stru ruct cture re of

• f

Pla Platform rm 1 1

+ +

Ad Admin minist istra ratio ion Platform-specific 2: Essence + Administration + Infrastr. 1 + Infrastr. 2 Infra rast stru ruct cture re of

• f

Pla Platform rm 2 2

+ +

Softwaretechnologie II

Example: Variant 1: Modular EAI* of an OMS

Ø OMS is extended for platforms OpenERP and Java

• Prof. U. Aßmann

12

Essence: Order Management System (OMS) Validated Essence: OMS with Contract Checking Platform-specific: OMS based on platform OpenERP

+ +

Infra rast stru ruct cture re of

• f

Pla Platform rm OpenER ERP

+ +

Ad Admin minist istra ratio ion Platform-specific: OMS on OpenERP on Java Infra rast stru ruct cture re of

• f

Pla Platform rm Ja Java va

+ +

Softwaretechnologie II

Example: Variant 2: Modular EAI* of an OMS

Ø OMS is extended with platform views SAP and ABAP

• Prof. U. Aßmann

13

Essence: Order Management System (OMS) Validated Essence: OMS with Contract Checking Platform-specific: OMS based on platform SAP

+ +

Infra rast stru ruct cture re of

• f

Pla Platform rm SAP SAP

+ +

Ad Admin minist istra ratio ion Platform-specific: OMS on SAP on ABAP Infra rast stru ruct cture re of

• f

Pla Platform rm ABAP ABAP

+ +

Softwaretechnologie II

Modular EAI*: Modular Variability with Partial System Configurations of Modules or Components

Ø Modular EAI* is an development style for modular product lines, in which several

infrastructural aspects (“platform-specific aspects”) are distinguished

• Prof. U. Aßmann

Validated Essence: Platform- Independent Module Set (PIMS) Platform-Specific Module Set 1 (PSMS 1) Platform-Specific Module Set 2 (PSIMS 2)

Pla Platform rm Descrip scriptio ion Mo Module le (PD (PDM) M)

+

Pla Platform rm Ext Extensio sion Mo Module les s 2

+

Pla Platform rm Ext Extensio sion Mo Module les s 1

Platform-Specific Implementation Module Set (PSIMS 3, Code)

Handwrit ritten mo module les

+

14

Softwaretechnologie II

Addition of Modules in the Modular EAI*

Ø The product’s components consist of

• Platform-independent components
• Platform-specific components / extensions

Ø Modular EAI* adds platform-specific components later

• Prof. U. Aßmann

15

+ +

Softwaretechnologie II

Multiple Platforms – Multiple Addition of Modules in the Modular EAI*

Ø The product’s components consist of

• Platform-independent components
• Platform-specific components / extensions

Ø Modular EAI* adds platform-specific components later

• Prof. U. Aßmann

16

+ + + + + +

Softwaretechnologie II

Exercise: Modular EAI* with GNU Packages

Ø Download a C-based GNU package Ø Identify essential, adminstrational, platform-specific modules Ø How many platforms are distinguished? Ø Analyse the “configure” script and its input “configure.in”

• Can you identify the platforms and their variants?

Ø How does configure achieve platform variability?

• Prof. U. Aßmann

17

Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie – Prof. Aßmann - Softwaretechnologie II

30.2 TRANSFORMATIONAL DESIGN WITH THE MODEL-DRIVEN ARCHITECTURE (MDA)

• Prof. U. Aßmann

18

Softwaretechnologie II

Remember: Refinement-based Modelling

Ø Refinement-based design and transformative design (with GRS) are an old

idea

• Broadband languages, such as CIP or IPSEN did this in the 70s already

Ø Process:

• Refinement starts with some simple model
• Apply refinement steps:

Ø Elaborate (more details – change semantics) Ø Add platform-specific details Ø Semantics-preserving operations Ø Restructure (more structure, but keep requirements and delivery, i.e.,

semantics)

Ø Split (decompose, introduce hierarchies, layers, reducibility) Ø Coalesce (rearrange) Ø TransformDomains (change representation, but keep semantics)

• Prof. U. Aßmann

19

Softwaretechnologie II

Model-Driven Architecture (MDA)

Ø MDA http://www.OMG.org/mda is a refinement- and transformation-based

development method for product families (product lines).

• It uses Essence-Administration-Infrastructure (EAI) aspect-decomposition

Ø Split the all design models into

Ø Platform-independent model: The PIM focuses on essence, the logical

architecture and the administration (consistency)

Ø Platform-specific extension: infrastructure code for a platform Ø Platform-specific model: The PSM adds platform-specific details and timing

constraints (infrastructure)

Ø Platform-specific implementation contains the code Ø Platform description model

describes the platform concepts

Ø Advantages

Ø Separation of concerns: Platform-

independent vs platform-dependent issues

Ø Portability Ø Automation: derive implementation

models from design models (semi-) automatically

• Prof. U. Aßmann

20

Platform Independent Model (PIM) Platform Specific Model (PSM) Platform-Specific Implementation (PSI, Code)

Pla Platform rm Descrip scriptio ion Mo Model l (PD (PDM) M)

Softwaretechnologie II

Code Code Code Code Platform Specific Model (PSM) Platform Specific Model (PSM) Platform Independent Model (PIM) Platform Specific Model (PSM) Code

MDA Describes Product Lines

Ø The upper levels of the MDA stack form transformational frameworks

• Prof. U. Aßmann

21

Computationally Independent Model (CIM) Requirements specification Platform Independent Model (PIM) Platform Specific Model (PSM) Platform-Specific Implementation Model (PSI, partial Code) The products of the product line Domain model for application domain Esse Essence ce Infra ra- st stru ruct cture re Require ire- me ments

Softwaretechnologie II

Model Mappings and Model Weavings

Ø Model completions completes models with new fragments Ø Model mappings connect models horizontally (on the same level) or vertically (crossing levels).

• From a model mapping, a simple transformation can be inferred

Ø Model transformations transform one model into another, often based on a model mapping

• Model enrichments add information or hand-written extensions

Ø Model weavings are model transformations weaving two input models to an output model

• Usually, some parts are still hand-written code
• Prof. U. Aßmann

22

Computationally Independent Model (CIM) Requirements specification Platform Independent Model (PIM) Platform Specific Model (PSM) Platform-Specific Implementation (PSI, Code) Domain model

Pla Platform rm Descrip scriptio ion Mo Model l (PD (PDM) M) weavin ving Handwrit ritten co code

co comp mple letio ion

Pla Platform rm Descrip scriptio ion Ext Extensio sion (PD (PDE) E)

Softwaretechnologie II

Example: MDA Performed by Hand-Written Refinements

• Prof. U. Aßmann

23

Requirements Specification (UML, formal methods, ...) PIM (standard UML with parallelism) PSM2 (EJB middleware) PSM4 (Java Code) Elimination of all non- programming constructs Adaptation to EJB platform PSM1 (parallelism resolved) PSM3 (relations refined) Elimination of abstract relations Realize active/ passive objects PSM2 (.NET middleware) PSM4 (C# Code) PSM3 (relations refined) Variant 2

Tra ransf sforma rmative ive st step

Softwaretechnologie II

Example: Compilers Are Simple, but Automatic MDA Tools

Ø A compiler transforms a source program via several intermediate

representations to the binary program

Ø Models are intermediate representations

• Platform-specific model is the abstract syntax tree (AST) and the IL
• Prof. U. Aßmann

24

Program in Concrete Syntax Abstract Syntax Tree (AST) Program in Intermediate Language (IL) Program in Binary Machine Language (BML) Ma Mach chin ine Language Language Descrip scriptio ion Mo Model l (PD (PDM) M) +

Softwaretechnologie II

Benefit of MDA

Ø MDA sees the system development process as a sequence of refinement and

transformation steps from requirements to code Ø MDA is an architectural style for transformational frameworks

Ø Separation of platform information (separation of concerns) reduces

dependencies on platform Ø Middleware (.NET, Corba, DCOM, Beans) Ø Platform specific details (resource constraints, memory handling) Ø Platforms in embedded and realtime systems Ø Domain

Ø Reuse of PIM for many platforms

Ø The PIM is a generic framework for a product family Ø A transformational framework, not an object-oriented framework

Ø MDA provides generic frameworks for designs and models

Ø Parameterization with model mappings

• Prof. U. Aßmann

25

Softwaretechnologie II

MDA is a Specific Form of EAI*

Ø EAI* is modular and relies on the underlying component model.

• It works for ALL component models
• In general, it is not transformative, but uses the linker of the component model

§

Static linking (as in C and C++)

§

Dynamic linking (as in Java and C#)

Ø MDA uses model weaving and model transformation to complete the

system, completing the partial configuration step-by-step

Ø MDA is more powerful, because models can be adapted quite thoroughly

with model transformations and model weavings

• EAI* is simpler though
• Prof. U. Aßmann

26

Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie – Prof. Aßmann - Softwaretechnologie II

30.3 SPECIFYING MODEL MAPPINGS AND TRANSFORMATIONS BY MODEL MARKING WITH STEREOTYPES

• Prof. U. Aßmann

27

Softwaretechnologie II

AndroMDA, a Leading MDA Tool

• Prof. U. Aßmann

28

Platform Independent UML Model (PIM) Partial Platform Specific Implementation (PSM) Platform-Specific Implementation (PSI, Code)

Mo Model l parsin rsing Handwrit ritten co code

co comp mple letio ion

Platform Specific Cart rtrid ridge with Model Mapping PIM->PSM

Platform Independent UML Model (PIM) in internal representation

Mo Model l tra ransf sforma rmatio ion

Ø AndroMDA defines model mappings in platform-specific cartridges.

• A cartridge contains a mapping from UML to e.g., Java, C# or C++ and a model

transformation

[www.androMDA.org]

Ø AndroMDA defines cartridges for

• UML-CD: Spring, Hibernate

(persistency), XML, Enterprise Java Beans (EJB)

• UML-AD: Struts, Java Server

Pages(JSP), Servlets

Softwaretechnologie II

Morphic Mappings on Marked PIMs

Ø 1:1 or 1:n mappings are

important for marked PIMs:

• Stereotypes introduce an

exclusively-owns relationship from 1 element of the PIM to n elements in the PSM

• Supported by many MDA tools, such

as AndroMDA

Ø The stereotype creates a mapping

between a PIM class and a set of PSM classes

• The stereotype tells the MDA system

how to transform the PIM class to the PSM

• The stereotypes partition the PSM:

The border of a partition is demarcated by the PIM stereotype tag

• Prof. U. Aßmann

29

• int sum

+withdraw() <<with_interface>> Loan

• int sum

+withdraw() LoanImpl +withdraw() LoanInterf

PI PIM M PSM PSM

Softwaretechnologie II

Marking PIMs with Stereotypes from an UML Profile

Ø Instead of transforming the PIM types automatically (by a metamodel

mapping and its induced transformation defined by a cartridge), they can be marked up by hand with stereotypes (marks) from profiles

Ø A (UML) profile is a metamodel describing a platforms or a domain

Ø Technically, a profile is a set of new stereotypes and tagged values Ø Stereotypes correspond to metaclasses Ø A profile has a metamodel that extends the UML metamodel Ø Stereotypes are metaclasses in this metamodel that are derived from standard

UML metaclasses

Ø Examples for platform profiles:

Ø EDOC Enterprise Distributed Objects Computing Ø Middleware: Corba, .NET, EJB Ø Embedded and realtime systems: time, performance, schedulability

Ø Examples for domain profiles (describing a domain model)

Ø Derived from an ontology of a domain Ø A profile can be the core of a domain specific language (DSL) Ø With own vocabulary, every entry in metamodel is a term Ø Banking, insurances, cars, airplanes, …

• Prof. U. Aßmann

30

Softwaretechnologie II

Marking of a PIM with Stereotypes

• Prof. U. Aßmann

31

[MDA Guide, OMG]

St Stere reotyp ypes s defin ined in in a UML ML pro rofile ile

Softwaretechnologie II

Example of a Marked PIM and the Induced Model Transformations

Ø Tags (stereotypes) are mapped to different class implementations in a PSM Ø Here: mapping of a class and activity diagram to different languages, using

different code generation templates, triggered by stereotype marking

• Prof. U. Aßmann

32

• int sum

+withdraw() <<Java>> Loan // Java implementation as a decorator class Loan extends Account { // decorator backlink Account upper; private int sum; public void withdraw( int amount) { sum -= amount; } // C# implementation: a partial class class Loan partial Account { private int sum; public void withdraw( int amount) { sum -= amount; }

• int sum

+withdraw() <<C#>> Loan

<<generate>>

sum = sum - amount

amount

Ma Marke rked PI PIM M Ma Marke rked PI PIM M PSI PSI Ja Java va PSI PSI C# C#

Softwaretechnologie II

Cartridges are Transformation Libraries for Marked PIMs

Ø Cartridges define both the model mapping from a PIM to a PSM and the model transformation

• manual marking of the PIM
• selective transformation of the marked PIM classes
• automatic transformation using the mapping and transformations from the

cartridge

• no manual specifications of mappings and transformations necessary
• Prof. U. Aßmann

33

Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie – Prof. Aßmann - Softwaretechnologie II

30.4.2 Domain-Specific Marking

• Prof. U. Aßmann

34

Softwaretechnologie II

Model-Driven Software Development (MDSD) with Domain Specific Marking of PIMs

Ø Model-based software development (MDSD, MDD) tags UML diagrams

with domain profiles Ø From the profile stereotypes and tags, domain-specific code is generated Ø set/get, standard functions, standard attributes Ø compliance functions for component models

Ø <!--In contrast, MDA profile tags are platform-specific-->

• Prof. U. Aßmann

35

withdraw() <<Account>> Loan

class Loan extends IAccount { private Person owner; void setOwner(Person p) {..} Person getOwner() {..} private int sum; /*** end generated code **/ public void withdraw( int amount) { sum -= amount; } /*** begin generated code **/ }

<<generate>>

sum = sum - amount

amount

Softwaretechnologie II

Pattern-Based Model Transformations

Ø Identify patterns in the PIM and rewrite them (using GRS or Storyboards)

• Prof. U. Aßmann

36

[MDA Guide, OMG]

Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie – Prof. Aßmann - Softwaretechnologie II

30.4 MODEL MAPPINGS

• Prof. U. Aßmann

37

Softwaretechnologie II

What are Model Mappings?

Ø Remember Pidd’s definition of a model:

Ø “A model is a representation of a part of a function of a system, its structure, or

behavior”

Ø Model mappings relate models and induce transformations from between

them

• Vertical mapping: from an upper to a lower model
• Horizontal mapping: between sister models

Ø The mappings are automatic or semi-automatic: step-wise refinement of the

model by transformation

• Prof. U. Aßmann

38

Model Platform Metamodel Mapping Mapping Technique source target applicationOf instanceOf describes source target Transformation Transformation Technique applicationOf Vertical Horizontal

Softwaretechnologie II

Different Kinds of Mappings

Ø The MDA Guide suggests several MDA patterns, i.e., transformation patterns

from a PIM to a PSM, inducing mapping patterns between PIM and PSM:

Ø Instantiation: binding the formal parameters of a model template

(instantiation of templates, framework instantiation)

• [see courses DPF and CBSE]

Ø Isomorphic mapping: expand a tag in a PIM to 1 element of a PSM (1:1

mapping) Ø Map an element of a PIM to one element of a PSM Ø The extension information of a PSM can be expressed as one stereotype in a PIM

(marked PIM)

Ø Homomorphic mapping: expand a tag in a PIM to n elements of a PSM

(1:n mapping) Ø Map an element of a PIM to several elements of a PSM Ø The extension information of a PSM can be expressed as one stereotype in a PIM

(marked PIM)

Ø Concept transformation mapping: Change a concept of a PIM into

another concept in a PSM Ø For instance, a PIM method to a PSM Command object

Ø Aspect mappings: aspects are woven into the core PIM

Ø For instance, with a GRS

• Prof. U. Aßmann

39

Softwaretechnologie II

Metaclass Transformation (Metamodel Transformation) from PIM to PSM

Ø If the metamodel is changed in a vertical transformation, we speak of a exogeneous transformation

• Prof. U. Aßmann

40

[MDA Guide, OMG]

PSM PSM PI PIM M Pla Platform- rm- sp specif cific ic me metacla classe sses Pla Platform- rm- in independent me metacla classe sses Tra ransf sforma rmatio ion sp specif cifica icatio ion

subtypes_of subtypes_of source_types target_types

Defin ined in in ca cart rtrid ridge

Softwaretechnologie II

Metamodel Transformation

Ø If the metamodel is changed in a vertical transformation, we speak of a exogeneous transformation

• Prof. U. Aßmann

41

[MDA Guide, OMG]

Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie – Prof. Aßmann - Softwaretechnologie II

30.5 Model Weaving

• Prof. U. Aßmann

42

Softwaretechnologie II

Model Merging and Weaving

Ø Model merging enters an extension into a core model, i.e., a PSE into a PIM Ø Model weaving uses a crosscut specification how to do this, e.g., GRS rules or storyboards

• Prof. U. Aßmann

43

[MDA Guide, OMG]

Platform-specific extension (PSE)

Cro rosscu sscut sp specif cifica icatio ion

Softwaretechnologie II

Additional Information

• Prof. U. Aßmann

44

[MDA Guide, OMG]

Softwaretechnologie II

Model weaving Platform-1 specific model (PSM) Platform-1 specific extension (PSE) Infrastructure Platform independent model (PIM) Essence, Administration Model weaving Platform-(1+2) specific model (PSM) Platform-2 specific extension (PSE) Infrastructure

Stepwise Adding Platform-Specific Extensions to Platform- Independent Models

• Prof. U. Aßmann

45

Aspect 1 Aspect 2

Cro rosscu sscut Sp Specif cifica icatio ion 1 Cro rosscu sscut Sp Specif cifica icatio ion 2

Softwaretechnologie II

Model weaving Platform-1 specific model (PSM) Algorithm+data Platform-1 specific extension (PSE) Data structure Platform independent model (PIM) Algorithmic Essence, Administration Model weaving Platform-(1+2) specific model (PSM): Distributed algorithm Platform-2 specific extension (PSE) Memory Mapping

Example: Platform-Specific Extensions to Platform-Independent Models: For Code Generation on Parallel Distributed Machines

• Prof. U. Aßmann

46

Aspect 1 (data structure) Aspect 2 (distribution)

Me Memo mory ry Mo Model: l: Sh Share red me memo mory ry Me Memo mory ry mo model: l: Dist istrb rbuted farm rm Cro rosscu sscut Sp Specif cifica icatio ion 1 Cro rosscu sscut Sp Specif cifica icatio ion 2

Softwaretechnologie II

Problem: Full MDA Needs Roundtrip

Ø Otherwise, the models age (design aging) Ø This is still an unsolved problem (-> course MOST)

• Prof. U. Aßmann

47

Model mappings should be invertible Requirements Specification Platform Independent Model (PIM) Platform Specific Model (PSM) Code

Softwaretechnologie II

Problem 2: MDA Needs More Levels (Multi-Stage MDA)

Ø Transformative MDA does not work for multiple levels in industrial practive Ø But Modular EAI* does, if you design your modules and classes with EAI* concerns

• Prof. U. Aßmann

48

“platform stack” Requirements Specification Platform Independent Model (PIM) Platform Specific Model (PSM) Code

...

Softwaretechnologie II

Remember: Multiple Platforms – Multiple Addition of Modules in the Modular EAI*

Ø The product’s components consist of

• Platform-independent components
• Platform-specific components / extensions

Ø Modular EAI* adds platform-specific components later

• Prof. U. Aßmann

49

+ + + + + +

Softwaretechnologie II

The End

Ø MDA(R) is a trademark of OMG Ø What is EAI? Ø What is modular EAI? Ø Compare MDA with modular EAI Ø What is a “marked PIM”? Ø What is an “aspect-oriented PIM”? Ø Why can marked PIM express domain dependencies?

• Prof. U. Aßmann

50

Softwaretechnologie II

When Can We Semi-Automatically Enrich A PIM to a PSM? Ø Describe platform specific extension (PSE) as aspects or views Ø The PIM is the core, the PSM the weaved system Ø The model mapping becomes an aspect weaver

• Prof. U. Aßmann

51

PSE for Aspect 1 PSE for Aspect 3 PIM Op PSM Op Op Op Op Op Op PSE for Aspect 2

Softwaretechnologie II

MDA With Several Layers for Resource-Constrained Systems Ø HIDOORS EU Projekt

(High Integrity Distributed Object-Oriented Real-Time Systems), http://www.hidoors.org

Ø MDA for RT-UML

Ø Realtime sequence diagrams (MSC) Ø UML realtime statecharts

Ø Transformation into timed

automata of Uppaal model checker

• Prof. U. Aßmann

52

PSE for Aspect 1 (time)

PIM

Op Op Op Op Op Op Op

PSE for Aspect 2 (memory)

PSM-1 PSM-2

Op Op Op Op Op Op Op

Softwaretechnologie II

RT Sequence Diagram (UML)

• Prof. U. Aßmann

53

<<subject>> Heart Rate Server <<observer>> HR Trend Recoder <<observer>> HR Sensor GetRate() Subscribe() Subscribe() GetRate() A B C D Advice: {D-C<=1ms} {B-A <= 2ms}

Join Points

RT Extension Aspect

Softwaretechnologie II

RT-SD und RT-Statecharts are Platform Specific Aspects

• Prof. U. Aßmann

54

RT Sequence diagram PIM: UML class diagram

Op Op Op Op Op Op Op

RT-Statecharts PSM-1 PSM-2

Op Op Op Op Op Op Op