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

▶
30 transformational design with essential aspect
SMART_READER_LITE
LIVE PREVIEW

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

Mar 08, 2024 282 likes •790 views

Fakultt Informatik, Institut fr Software- und Multimediatechnik, Lehrstuhl fr Softwaretechnologie 30 Transformational Design with Essential Aspect Decomposition: Model-Driven Architecture (MDA) 1. EAI* for Modular Product Lines Prof. Dr.

slide-1
SLIDE 1

Fakultät Informatik, Institut für Software- und Multimediatechnik, Lehrstuhl für Softwaretechnologie

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 Version 13-1.1, 22.01.14 1. EAI* for Modular Product Lines 2. Model-Driven Architecture 3. Model Mappings 4. Model Merging and Weaving 5. MDSD with domain-specific tagging

slide-2
SLIDE 2

References

Ø Obligatory:

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

Ø Optional:

  • J. Frankel. Model-driven architecture. Wiley. Excellent book on the concepts
  • f 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.

TU Dresden, Prof. U. Aßmann MDA 2

slide-3
SLIDE 3

Problem: The Representation Schizophrenia

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

maintenance

Ø If an artifact 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

Ø They “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

TU Dresden, Prof. U. Aßmann MDA 3

slide-4
SLIDE 4

30.1 PRODUCT LINES WITH MODULAR VARIABILITY

slide-5
SLIDE 5

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?

TU Dresden, Prof. U. Aßmann MDA 5

slide-6
SLIDE 6

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

slide-7
SLIDE 7

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

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

  • Modules, Functions, Actions, Processes, Packages, etc
  • Objects
  • Data-flow diagrams
  • ECA-modules
  • Aspects

TU Dresden, Prof. U. Aßmann MDA 7

slide-8
SLIDE 8

Modular EAI with Partial System Configurations of Modules or Components

TU Dresden, Prof. U. Aßmann 8

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

+ +

Infra rast stru ruct cture re

+ +

Ad Admin minist istra ratio ion

slide-9
SLIDE 9

What Are Platforms?

Ø Platforms are concerns (aspects) on the infrastructure, describing

the environment on 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+, etc.

  • Ontology of a domain (e.g., medicine)
  • Constraints of the system

Ø Time Ø Memory Ø Energy

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

produce a variant of the specification

TU Dresden, Prof. U. Aßmann MDA 9

slide-10
SLIDE 10

Modular EAI* with Partial System Configurations of Modules or Components

TU Dresden, Prof. U. Aßmann 10

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

+ +

slide-11
SLIDE 11

Example: Variant 1: Modular EAI* of an OMS

TU Dresden, Prof. U. Aßmann 11

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

+ +

slide-12
SLIDE 12

Example: Variant 2: Modular EAI* of an OMS

TU Dresden, Prof. U. Aßmann 12

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

+ +

slide-13
SLIDE 13

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

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

aspects (“platform-specific aspects”) are distinguished

TU Dresden, 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

+

slide-14
SLIDE 14

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

TU Dresden, Prof. U. Aßmann MDA 14

+ +

slide-15
SLIDE 15

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

TU Dresden, Prof. U. Aßmann MDA

+ + + +

slide-16
SLIDE 16

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?

TU Dresden, Prof. U. Aßmann MDA 16

slide-17
SLIDE 17

30.2 MODEL-DRIVEN ARCHITECTURE (MDA)

TU Dresden, Prof. U. Aßmann MDA 17

slide-18
SLIDE 18

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

Ø 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)

TU Dresden, Prof. U. Aßmann MDA 18

slide-19
SLIDE 19

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

TU Dresden, Prof. U. Aßmann

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

MDA 19

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

slide-20
SLIDE 20

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 platform stack form transformational

frameworks

TU Dresden, Prof. U. Aßmann

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

MDA 20

slide-21
SLIDE 21

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

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

  • Usually, some parts are still hand-written code

TU Dresden, Prof. U. Aßmann

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

21

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)

slide-22
SLIDE 22

Modular MDA with Partial System Configurations of Modules or Components

Ø MDA can work with different forms of models. One type of model can be partial

configurations of modules or components

  • Partial systems are partial, not abstract

Ø Model weaving then means system completion, completing the partial

configuration with more modules

Ø This form of MDA is not transformative, but relies on the underlying

component model. It works for ALL component models

TU Dresden, Prof. U. Aßmann

Platform-Independent Module Set (PIMS) Platform-Specific Module Set (PSMS) Platform-Specific Implementation Module Set (PSIMS, Code)

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

+

Handwrit ritten mo module les

+

Pla Platform rm Descrip scriptio ion Ext Extensio sion Mo Module les s (PD (PDE) E)

slide-23
SLIDE 23

Example: MDA Performed by Hand

TU Dresden, Prof. U. Aßmann

Requirements Specification (UML, formal methods, ...) PIM (standard UML with parallelism) PSM2 (EJB middleware) PSM4 (Java Code) Java Elimination of all non- Java 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)

MDA 23

Variant 2

slide-24
SLIDE 24

Example: Compilers Are Simple, but Automatic MDA Tools

Ø Metamodels are language descriptions Ø Models are intermediate representations Ø Platform specific (abstract syntax tree) Ø Platform dependent (binary code)

TU Dresden, Prof. U. Aßmann

Programming Language in Concrete Syntax Abstract Syntax Tree (AST) Intermediate Language (IL) Machine Language (ML)

MDA 24

Ma Mach chin ine Language Language Descrip scriptio ion Mo Model l (PD (PDM) M) +

slide-25
SLIDE 25

What are Model Mappings?

Ø Remember Model:

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

  • r behavior”

Ø Model mappings induce transformations from an upper to a lower

model

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

model by transformation

TU Dresden, Prof. U. Aßmann

Model Platform Metamodel Mapping Mapping Technique source target applicationOf instanceOf describes source target

MDA 25

slide-26
SLIDE 26

Benefit of MDA

Ø MDA sees the system development process as a sequence of

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

TU Dresden, Prof. U. Aßmann MDA 26

slide-27
SLIDE 27

EAI* and MDA

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

  • It works for ALL component models

Ø In contrast to MDA, 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

TU Dresden, Prof. U. Aßmann MDA 27

slide-28
SLIDE 28

30.3 MODEL MAPPINGS

TU Dresden, Prof. U. Aßmann MDA 28

slide-29
SLIDE 29

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 template (instantiation

  • f templates, framework instantiation) [see Design Patterns and

Frameworks]

Ø 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

TU Dresden, Prof. U. Aßmann MDA 29

slide-30
SLIDE 30

Morphic Mappings on Marked PIMs

Ø 1:1 or 1:n mappings (isomorphic mappings, marked PIMs)

are important

Ø They introduce an exclusively-owns relationship from 1 element of the PIM to

n elements in the PSM

Ø Supported by many UML and MDA tools

Ø They partition the PIM and the PSM: The border of a partition is demarcated

by the PIM tag

Ø This serve for clear responsibilities, on which level a partition is edited

TU Dresden, Prof. U. Aßmann MDA 30

slide-31
SLIDE 31

Marking PIMs with Stereotypes from an UML Profile

Ø 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, …

TU Dresden, Prof. U. Aßmann MDA 31

slide-32
SLIDE 32

Marking of a PIM with Stereotypes

TU Dresden, Prof. U. Aßmann

[MDA Guide, OMG]

MDA 32

slide-33
SLIDE 33

Example of a Marked PIM and the Induced Model Transformations

Ø Tags are mapped to different class implementations in a PSM Ø Here: mapping to different languages, using different code

generation templaes

TU Dresden, Prof. U. Aßmann

  • 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

MDA 33

<<generate>>

sum = sum - amount

amount

slide-34
SLIDE 34

Pattern-Based Model Transformations

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

TU Dresden, Prof. U. Aßmann

[MDA Guide, OMG]

MDA 34

slide-35
SLIDE 35

Type Transformation from PIM to PSM

TU Dresden, Prof. U. Aßmann MDA 35

[MDA Guide, OMG]

PSM PSM PI PIM M Pla Platform- rm- sp specif cific ic typ ypes s Pla Platform- rm- in independent typ ypes s Tra ransf sforma rmatio ion sp specif cifica icatio ion

subtypes_of subtypes_of source_types target_types

slide-36
SLIDE 36

Metamodel Transformation

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

  • f a exogeneous transformation

TU Dresden, Prof. U. Aßmann

[MDA Guide, OMG]

MDA 36

slide-37
SLIDE 37

30.4 MODEL WEAVING

TU Dresden, Prof. U. Aßmann MDA 37

slide-38
SLIDE 38

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

TU Dresden, Prof. U. Aßmann

[MDA Guide, OMG]

MDA 38

PSE

Cro rosscu sscut sp specif cifica icatio ion

slide-39
SLIDE 39

Additional Information

TU Dresden, Prof. U. Aßmann

[MDA Guide, OMG]

MDA 39

slide-40
SLIDE 40

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

Adding Platform-Specific Extensions to Platform-Independent Models

TU Dresden, Prof. U. Aßmann MDA 40

Aspect 1 Aspect 2

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

slide-41
SLIDE 41

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

TU Dresden, Prof. U. Aßmann MDA 41

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

slide-42
SLIDE 42

Problem: Full MDA Needs Roundtrip

Ø Otherwise, the models age (design aging) Ø This is still an unsolved problem

TU Dresden, Prof. U. Aßmann

Model Mappings Requirements Specification Platform Independent Model (PIM) Platform Specific Model (PSM) Code

MDA 42

slide-43
SLIDE 43

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

TU Dresden, Prof. U. Aßmann

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

...

“platform stack”

MDA 43

slide-44
SLIDE 44

30.5 DOMAIN-SPECIFIC MARKING

TU Dresden, Prof. U. Aßmann MDA 44

slide-45
SLIDE 45

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

TU Dresden, Prof. U. Aßmann

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 **/ }

MDA 45

<<generate>>

sum = sum - amount

amount

slide-46
SLIDE 46

The End

Ø MDA(R) is a trademark of OMG

TU Dresden, Prof. U. Aßmann MDA 46

slide-47
SLIDE 47

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

TU Dresden, Prof. U. Aßmann

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

MDA 47

slide-48
SLIDE 48

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

TU Dresden, Prof. U. Aßmann

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

MDA 48

slide-49
SLIDE 49

RT Sequence Diagram (UML)

TU Dresden, Prof. U. Aßmann

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

MDA 49

slide-50
SLIDE 50

RT-SD und RT-Statecharts are Platform Specific Aspects

TU Dresden, Prof. U. Aßmann

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

MDA 50