1 Model Model - - Driven Development Driven Development State of the Art State of the Art OOP Conference, Monday, January 16 OOP Conference, Monday, January 16 th th , 2005 , 2005 Dr Douglas C Schmidt [email protected]www.dre.vanderbilt.edu/~schmidt Institute for Software Integrated Systems Vanderbilt University Nashville, Tennessee Markus Völter [email protected]www.voelter.de Independent Consultant for Software Engineering and Technology Heidenheim, Germany Thomas Stahl [email protected]www.bmiag.de b+m Informatik AG, Chef-Architekt Kiel, Germany 2 CONTENTS Model-Driven Development: State of the Art z Introduction & Motivation z Definition of Terms z Architecture-Centric MDD & Cascading z Role of Frameworks & Patterns in the Context of MDD z How Generators work – MDD & Compiler Construction z Model-To-Model Transformations z An Architectural Process – A Case Study z Examples of Applying MDD Tools: GME & CoSMIC z Another Tool: openArchitectureWare z SOA, Business Process Modeling, & MDD z Product-line Architecture Case Study z Summary
141
Embed
Model-Driven Development State of the Art - voelter · Model-Driven Development State of the Art OOP Conference, Monday, January 16th, 2005, 2005 Dr Douglas C Schmidt [email protected]
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
1
ModelModel--Driven DevelopmentDriven DevelopmentState of the ArtState of the Art
OOP Conference, Monday, January 16OOP Conference, Monday, January 16thth, 2005, 2005
Introduction & MotivationDefinition of TermsArchitecture-Centric MDD & CascadingRole of Frameworks & Patterns in the Context of MDDHow Generators work – MDD & Compiler ConstructionModel-To-Model TransformationsAn Architectural Process – A Case StudyExamples of Applying MDD Tools: GME & CoSMICAnother Tool: openArchitectureWareSOA, Business Process Modeling, & MDDProduct-line Architecture Case StudySummary
2
3
CONTENTSModel-Driven Development:State of the Art
Introduction & MotivationDefinition of TermsArchitecture-Centric MDD & CascadingRole of Frameworks & Patterns in the Context of MDDHow Generators work – MDD & Compiler ConstructionModel-To-Model TransformationsAn Architectural Process – A Case StudyExamples of Applying MDD Tools: GME & CoSMICAnother Tool: openArchitectureWareSOA, Business Process Modeling, & MDDProduct-line Architecture Case StudySummary
Model-Driven Development – State of the Art 4
CPU & network performance has increased by 3-8 orders of magnitude in past decades
1,200 bits/sec to 10+ Gigabits/sec
The Road Ahead
Extrapolating these trends another decade or so yields• ~100 Gigahertz desktops• ~100 Gigabits/sec LANs• ~100 Megabits/sec wireless• ~10 Terabits/sec Internet backbone
10 Megahertz to 3+ Gigahertz
Unfortunately, software quality & productivity hasn’t improved as
rapidly or predictably as hardware –especially for distributed real-time &
embedded (DRE) systems
3
Model-Driven Development – State of the Art 5
Why Hardware Improves So ConsistentlyAdvances in hardware & networks stem largely from R&D on standardized & reusable APIs & protocols
x86 & Power PC chipsets TCP/IP
Model-Driven Development – State of the Art 6
ApplicationSoftware
ApplicationSoftware
ApplicationSoftware
ApplicationSoftware
Why Software Fails to Improve as ConsistentlyIn general, software has not been as standardized or reusable as hardware
static CORBA::Long receiver_pid_;static FILE *output_file = 0;// File handle of the file into which received data is writtenquo::ValueSC_var actualFrameRate;// Poke this in order to send the measured frame rate toQuO// destination port to send mpeg data to onlocalhoststaticintoutput_port = 8001;// Instrumentation HelperstaticInstrumentor*instrument = 0;// Name of processstatic ACE_CStringprocess_name_;intReceiver_StreamEndPoint::get_callback (constchar *flowname, TAO_AV_Callback*&callback) {
ACE_DECLARE_NEW_CORBA_ENV;// Create and return the sender application callback toAVStreamsfor furtherupcallsint retval= 0;callback = &this->callback_;RECEIVER::instance ()->connection_manager ()connect_negotiator(this,flowname);returnretval; }
bodyadd_double(Instrument::FrameTiming, (CORBA::Double)(tvmsec() - decoded_rtp_hdrts) );bodyadd_string(Instrument::ProcessName, process_name_c_str());bodyadd_long(Instrument::PID, receiver_pid_);instrument->send_event(Instrument::ReceiverFrameStats, body); }if (output_file) {// Write the received data to the fileintresult = ACE_OS::fwrite(send_buf, send_len, 1, output_file); }
/*** Return the last time the client sent a request
associated with this* session, as the number of milliseconds since
midnight, January 1, 1970* GMT Actions that your application takes, such as
getting or setting* a value associated with the session, do not affect
the access time*/public long getLastAccessedTime() {
return (thislastAccessedTime);
}
thislastAccessedTime = time;
ConfigurationSpecification
Analysis Tool
Code
• One way to automate tracing between higher-level specifications & lower-level implementations is to leverage model-driven development techniques & tools
Model-Driven Development – State of the Art 22
Technology Evolution (1/4)Level of A
bstraction
Programming Languages & Platforms
Model-Driven Development (MDD)
• State chart
• Data & process flow
• Petri NetsTransla
tion
Large Semantic Gap
Transla
tion
Transla
tion
CodeCodeCodeCodeCodeCodeModelModel
ModelModelModelModelModel
GeneratedCode
Model
Platform
Machine codeAssemblyC/Fortran
Hardware
OperatingSystems
12
Model-Driven Development – State of the Art 23
Technology Evolution (2/4)Programming Languages
& Platforms
Level of Abstraction
C++/JavaClass LibrariesFrameworksComponents
Machine codeAssemblyC/Fortran
Hardware
OperatingSystems
Model
Application CodeDomain Specific
FrameworkPlatform
Frameworks
Model
Generated CodeFramework
Pattern Language
Platform
Model
Application CodeDomain Specific
FrameworkPlatform
Frameworks
Model
Generated CodeFramework
Pattern Language
Platform
Model
Application CodeDomain Specific
FrameworkPlatform
Frameworks
Model
Generated CodeFramework
Pattern Language
Platform
Model
Domain SpecificFrameworkPlatform
Frameworks
FrameworkPattern Language
Platform
Application Code
•New languages & platforms have raised abstraction level significantly•“Horizontal” platform reuse alleviates the need to redevelop common services
•There are two problems, however:•Platform complexity evolved faster than 3rd-generation languages
•Much application/platform code still (unnecessarily) written manually•Particularly for D&C & QA aspects
• State Charts• Interaction Diagrams• Activity Diagrams
• OMG is evaluating MDD via MIC PSIG• mic.omg.org
13
Model-Driven Development – State of the Art 25
Technology Evolution (4/4)Programming Languages
& Platforms
Needs Automation
Needs Automation
Research is needed to automate DSLs & model translators
Level of Abstraction
Saturation!!!!
PlatformFrameworks
Application Code
Model
Platform
Generated Code
Model
PlatformFrameworks
Application Code
Model
Platform
Generated Code
Model
PlatformFrameworks
Application Code
Model
Platform
Generated Code
Model
PlatformFrameworks
Application Code
Model
Platform
Generated Code
Model
Domain-specific modeling languages
• ESML• PICML• Mathematic• Excel• MetamodelsNeeds
Automation
Domain-independent modeling languages
• State Charts• Interaction Diagrams• Activity Diagrams
C++/JavaClass LibrariesFrameworksComponents
Machine codeAssemblyC/Fortran
Hardware
OperatingSystems
Model-Driven Development (MDD)
26
CONTENTSModel-Driven Development:State of the Art
Introduction & Motivation
Definition of TermsArchitecture-Centric MDD & CascadingRole of Frameworks & Patterns in the Context of MDDHow Generators work – MDD & Compiler ConstructionModel-To-Model TransformationsAn Architectural Process – A Case StudyExamples of Applying MDD Tools: GME & CoSMICAnother Tool: openArchitectureWareSOA, Business Process Modeling, & MDDProduct-line Architecture Case StudySummary
14
Model-Driven Development – State of the Art 27
The MDD Blueprint
Applikations-Modell
Applikations-Modell
HandcraftedCode
HandcraftedCode
Code of Application orReference Implementation
analyse separate
Platform
IndividualCode
ApplicationModel
DSL
Trans-formations
uses creates
GenericCode
IndividualCode
SchematicRepetitive
Code
SchematicRepetitive
Code
Typically you start with a manually built application
You analyse it with respect to
Code that is always identical in applications of
that kind
Code that has the same structure/patterns in all
cases
And code that is completely individual to
the application
Model-Driven Development – State of the Art 28
The MDD Blueprint
Applikations-Modell
Applikations-Modell
HandcraftedCode
HandcraftedCode
Code of Application orReference Implementation
analyse separate
Platform
IndividualCode
ApplicationModel
DSL
Trans-formations
uses creates
GenericCode
IndividualCode
SchematicRepetitive
Code
SchematicRepetitive
Code
The generic, identical code becomes the platform
Application Models describe the repetitive aspects in an
abstract & concise way using a Domain-Specific Language
Transformations create the repetitive code from the application models
15
Model-Driven Development – State of the Art 29
A UML based Ontology for MDD
• Isn‘t the OMG/MDA terminology sufficient ?–Useful as a basis, but perspectives of
domain engineering, product lines & software system families missing orweak
• What is an Ontology ?–Representation of knowlegde: definition
of concepts & their relationships• Why UML for that ?
–Provides a popular & standardizednotation for concepts (classes) & typicalcategories of relations (Association, Composition, InstanceOf, Realization, Uses, …)
–Allows for definition of specificcategories through profiling
Model-Driven Development – State of the Art 30
Domain, Model, & DSL
• A domain describes a bounded area of knowledge or interest– It can be structured into various subdomains
• A metamodel is a formal representation of the concepts in that particular(sub-)domain, as well as their relationships
–A metamodel is also called the abstract syntax (of a DSL)
16
Model-Driven Development – State of the Art 31
Domain, Model, & DSL• A Domain-Specific Language (or DSL) comprises
–The metamodel (the concepts it represents)–A concrete syntax to represent these concepts–As well as the semantics of the concepts
• A DSL is sometimes called a domain-specific modeling language (DSML)
Model-Driven Development – State of the Art 32
Domain, Model, & DSL• A formal model (or just “model“) built by the DSL
– is an instance of its metamodel and respects the static semantics–Uses the concrete syntax of the DSL–And gets its meaning from the DSLs semantics
17
Model-Driven Development – State of the Art 33
Platform
Domain
0..*based on
Plattformsupports
<<abstract>>Building
Block
Framework Component AspectLibraryMiddleware
{open}
• A platform supports a domain Platforms can be cascaded, i.e., they arebased on top of each other (see later)
• A platform consists of a number of building blocks– these can be middleware, libraries, frameworks, components or aspects,–as well as documentation and tests, of course
Model-Driven Development – State of the Art 34
Transformation• The finished product
contains the platform• It consists of generated
artifacts, as as well as non-generated, i.e., manually implementedartifacts
• Both of these types of artifacts know about & rely on the platform
18
Model-Driven Development – State of the Art 35
• The product – specifically, the generated artifacts – must be built– from the formal models describing the system,–Using a number of different transformations
• A transformation always uses a formal model as its source, thus it relieson the metamodel on which this formal model is built
Transformation
Model-Driven Development – State of the Art 36
• Model-to-Model Transformations also produce a formal model as the output
• This is typically based on a different metamodel• The transformation also relies this target metamodel• The M2M step can be repeated any number of times in the context of
MDD, the models typically becoming more specific to the platform
Transformation
19
Model-Driven Development – State of the Art 37
• Finally, Model-to-Platform (or model-to-code) transformations use the formal model to produce the generated artifacts
• these rely on & make use of the platform idioms (“patterns“)• The Idioms, together with the generated artifacts have to realize the
semantics of the model
Transformation
Model-Driven Development – State of the Art 38
Domain Architecture• A domain architecture comprises
– the DSL(s), – the platform–as well as all the transformations needed to transform models built using
the DSLs into code that runs on the platform
20
Model-Driven Development – State of the Art 39
Domain Architecture• A software system familiy can be implemented using such a domain
architecture• In turn, a software system familiy can be used to support (or realize)
product lines• A product line then consists of a number of the products built using the
software system family‘s domain architecture
Model-Driven Development – State of the Art 40
MDA Terms
<<MDA>>MOF
MetaMeta Model
<<MDA>>Action
Semantics
AbstractSyntax Semantics Model2Model
Transformation
<<MDA>>QVT
ConcreteSyntax
GraficalSyntax
<<MDA>>UML Profile <<MDA>>
OCLStatic
Semantics
FormalModel
specified onbasis of
<<MDA>>PIM
<<MDA>>PSM
<<MDA>>Executable
Model
refines
Platformspecific to
runs on
<<MDA>>PDM
describesrelevant
concepts of
The Meta Object Facility is the OMG’s Meta MetaModel XMI is based on
top of it, as is UML
Action Semantics can be used to add additional
semantics & behaviourto models
Query/Views/Trans-formations is the
OMG’s M2M standard
OCL can also add semantics by defining
constraints
21
Model-Driven Development – State of the Art 41
MDA Terms
<<MDA>>MOF
MetaMeta Model
<<MDA>>Action
Semantics
AbstractSyntax Semantics Model2Model
Transformation
<<MDA>>QVT
ConcreteSyntax
GraficalSyntax
<<MDA>>UML Profile <<MDA>>
OCLStatic
Semantics
FormalModel
specified onbasis of
<<MDA>>PIM
<<MDA>>PSM
<<MDA>>Executable
Model
refines
Platformspecific to
runs on
<<MDA>>PDM
describesrelevant
concepts of
MDA models are typically (not mandatorily) based
on UML + Profiles
OMG distinguishes between platform
specific & platform independent models
Platform Description models are basically metamodels of the
platform
42
CONTENTSModel-Driven Development:State of the Art
Introduction & MotivationDefinition of Terms
Architecture-Centric MDD & CascadingRole of Frameworks & Patterns in the Context of MDDHow Generators work – MDD & Compiler ConstructionModel-To-Model TransformationsAn Architectural Process – A Case StudyExamples of Applying MDD Tools: GME & CoSMICAnother Tool: openArchitectureWareSOA, Business Process Modeling, & MDDProduct-line Architecture Case StudySummary
22
Model-Driven Development – State of the Art 43
Architecture – Centric (AC) Model – DrivenDevelopment (MDD) Concept Adoption
DomainArchitecture
<<acmdsd>>Generative
Architecture
Non-generatedArtifact
<<acmdsd>>Code
Snippet
GeneratedArtifact
<<acmdsd>>Skeleton
complements
<<acmdsd>>Template
Target
Model2PlatformTransformation
Target1..*
DSL<<acmdsd>>
DesignLanguage
Meta Model<<acmdsd>>
Architecture-centricMeta Model
FormalModel
<<acmdsd>>Design
The domain is architecturally motivatede.g., architecture for business software
or component infrastructure for embedded systems
Model-Driven Development – State of the Art 44
AC – MDD Concept Adoption
DomainArchitecture
<<acmdsd>>Generative
Architecture
Non-generatedArtifact
<<acmdsd>>Code
Snippet
GeneratedArtifact
<<acmdsd>>Skeleton
complements
<<acmdsd>>Template
Target
Model2PlatformTransformation
Target1..*
DSL<<acmdsd>>
DesignLanguage
Meta Model<<acmdsd>>
Architecture-centricMeta Model
FormalModel
<<acmdsd>>Design
The products to be created are usually complete applications,
not single components
23
Model-Driven Development – State of the Art 45
AC – MDD Concept Adoption
DomainArchitecture
<<acmdsd>>Generative
Architecture
Non-generatedArtifact
<<acmdsd>>Code
Snippet
GeneratedArtifact
<<acmdsd>>Skeleton
complements
<<acmdsd>>Template
Target
Model2PlatformTransformation
Target1..*
DSL<<acmdsd>>
DesignLanguage
Meta Model<<acmdsd>>
Architecture-centricMeta Model
FormalModel
<<acmdsd>>Design
From the black box view, usually only single-step model-to-platform transformations exists
However, these can be internally (white box) structured, serving modularization purposes for sequential execution of several transformations
Model-Driven Development – State of the Art 46
AC – MDD Concept Adoption
DomainArchitecture
<<acmdsd>>Generative
Architecture
Non-generatedArtifact
<<acmdsd>>Code
Snippet
GeneratedArtifact
<<acmdsd>>Skeleton
complements
<<acmdsd>>Template
Target
Model2PlatformTransformation
Target1..*
DSL<<acmdsd>>
DesignLanguage
Meta Model<<acmdsd>>
Architecture-centricMeta Model
FormalModel
<<acmdsd>>Design
The DSL’s metamodel therefore contains architectural conceptsthat are as abstract as possible i.e., “component” & not “EJB 3 stateless session bean”
24
Model-Driven Development – State of the Art 47
AC – MDD Concept Adoption
DomainArchitecture
<<acmdsd>>Generative
Architecture
Non-generatedArtifact
<<acmdsd>>Code
Snippet
GeneratedArtifact
<<acmdsd>>Skeleton
complements
<<acmdsd>>Template
Target
Model2PlatformTransformation
Target1..*
DSL<<acmdsd>>
DesignLanguage
Meta Model<<acmdsd>>
Architecture-centricMeta Model
FormalModel
<<acmdsd>>Design
The DSL is also called design language
Often, UML profiles are used here, sometimes combined with additional textual specifications
Model-Driven Development – State of the Art 48
AC – MDD Concept Adoption
DomainArchitecture
<<acmdsd>>Generative
Architecture
Non-generatedArtifact
<<acmdsd>>Code
Snippet
GeneratedArtifact
<<acmdsd>>Skeleton
complements
<<acmdsd>>Template
Target
Model2PlatformTransformation
Target1..*
DSL<<acmdsd>>
DesignLanguage
Meta Model<<acmdsd>>
Architecture-centricMeta Model
FormalModel
<<acmdsd>>Design
Typically, the model-to-platform transformation is a template that shows great similarity to the generated code & thus can easily be extracted from a reference implementation
25
Model-Driven Development – State of the Art 49
AC – MDD Concept Adoption
DomainArchitecture
<<acmdsd>>Generative
Architecture
Non-generatedArtifact
<<acmdsd>>Code
Snippet
GeneratedArtifact
<<acmdsd>>Skeleton
complements
<<acmdsd>>Template
Target
Model2PlatformTransformation
Target1..*
DSL<<acmdsd>>
DesignLanguage
Meta Model<<acmdsd>>
Architecture-centricMeta Model
FormalModel
<<acmdsd>>Design
The transformation does not aim at creating the complete application, but merely an implementation frameworkcontaining the architectural infrastructure code (skeleton)
Model-Driven Development – State of the Art 50
AC – MDD Concept Adoption
DomainArchitecture
<<acmdsd>>Generative
Architecture
Non-generatedArtifact
<<acmdsd>>Code
Snippet
GeneratedArtifact
<<acmdsd>>Skeleton
complements
<<acmdsd>>Template
Target
Model2PlatformTransformation
Target1..*
DSL<<acmdsd>>
DesignLanguage
Meta Model<<acmdsd>>
Architecture-centricMeta Model
FormalModel
<<acmdsd>>Design
The non-generated, implementation code (“business logic”) is manually implemented in the target language (code snippet)
For this purpose, the generated skeleton may contain protected regions for supplementing the application logic that will persist after iterative regeneration
Alternatively, generated & non-generated code is integrated using suitable design patterns
26
Model-Driven Development – State of the Art 51
Recipe F/W for Integrating Manually Written Code• Recipe Frameworks help developers to write the “correct” manual
code by applying checks on the complete (manual & generated) code
Model-Driven Development – State of the Art 52
Recipe F/W for Integrating Manually Written Code
During code generation, a recipes file is created by the generator The
file is then read by the IDE
• Recipe Frameworks help developers to write the “correct” manual code by applying checks on the complete (manual & generated) code
27
Model-Driven Development – State of the Art 53
Recipe F/W for Integrating Manually Written Code
The IDE evaluates the checks in the recipe file & points to problems in the
manually written code
• Recipe Frameworks help developers to write the “correct” manual code by applying checks on the complete (manual & generated) code
Model-Driven Development – State of the Art 54
Recipe F/W for Integrating Manually Written Code
Checks that are ok are rendered in green (or
can be filtered out)
• Recipe Frameworks help developers to write the “correct” manual code by applying checks on the complete (manual & generated) code
28
Model-Driven Development – State of the Art 55
Recipe F/W for Integrating Manually Written Code
You can get more detailed information
on the checks executed
• Recipe Frameworks help developers to write the “correct” manual code by applying checks on the complete (manual & generated) code
Model-Driven Development – State of the Art 56
Recipe F/W for Integrating Manually Written Code
And a nice explaingtext that tells
developers what to do to fix the problem
• Recipe Frameworks help developers to write the “correct” manual code by applying checks on the complete (manual & generated) code
29
Model-Driven Development – State of the Art 57
Recipe F/W for Integrating Manually Written Code
You can reevaluatechecks at any time
• Recipe Frameworks help developers to write the “correct” manual code by applying checks on the complete (manual & generated) code
Model-Driven Development – State of the Art 58
Recipe F/W for Integrating Manually Written Code
A “quick fix” buttonwill be added till final
release of oAW 4
• Recipe Frameworks help developers to write the “correct” manual code by applying checks on the complete (manual & generated) code
30
Model-Driven Development – State of the Art 59
Cascading MDD Using Platform Stacking
• The generated code of the lower layer serves as the platform for the next higher level
• A sequence of generation steps is used, whereas each of the generates code on which the next step builds
Model-Driven Development – State of the Art 60
Cascading MDD Using M2M
• Here the higher level models are transformed into lower-level models that serve as input for the lower level generators Model-to-Model Transformations are used
• Typically, higher level models are more specific to a certain (sub-)domain
31
Model-Driven Development – State of the Art 61
Example for “Business Level” DSL
SomePlace: Generator
G11: GenerationElement
20KV: Bus
link11
T11: Transformer
link12
220KV: Buslink13 end11
link14
SomeOtherPlace: SwitchingStation
end21
transmissionLine1
B21-220KV: Bus
link21
B22-10KV: Bus
T21: Transformer
link22
link23
link24
end22
Model-Driven Development – State of the Art 62
DYI vs 3rd Party Cartridges
ConceptionalArchitecture
Model
Generator
Cartridge Specificfor the
Conceptionalarchitecture
Model suitable for C2
Model suitablefor C3
Off-the-ShelfCartridge C2
Off-the-ShelfCartridge C3
Code generated by C2
Code generated by C3
Project SpecificCode
Manually written code
• Do you build your own generator for your specific architecture? –This is good, because it’s tailored to your architecture
• Or do you want to (re-)use off-the-shelf cartridges for certain standard technologies (such as J2EE, Hibernate, Spring)?
• You can do the best of both worlds: –Define applications using your own metamodels
(architecture-centric, maybe funtional ones on top)–Transform your models to input models for the off-the-
shelf cartridges on the lower levels
32
63
CONTENTSModel-Driven Development:State of the Art
Introduction & MotivationDefinition of TermsArchitecture-Centric MDD & Cascading
Role of Frameworks & Patterns in the Context of MDDHow Generators work – MDD & Compiler ConstructionModel-To-Model TransformationsAn Architectural Process – A Case StudyExamples of Applying MDD Tools: GME & CoSMICAnother Tool: openArchitectureWareSOA, Business Process Modeling, & MDDProduct-line Architecture Case StudySummary
Model-Driven Development – State of the Art 64
•Present solutionsto common software problemsarising within a certain context
Overview of Patterns
•Capture recurring structures & dynamics among software participants to facilitate reuse of successful designs
MDD tools codify & automate many (but by no means all) aspects of patterns
33
Model-Driven Development – State of the Art 65
Overview of Pattern LanguagesMotivation•Individual patterns & pattern catalogs are insufficient
•Software modeling methods & tools largely just illustrate what/how – not why –systems are designed
Benefits of Pattern Languages• Define a vocabulary for talking about software development problems• Provide a process for the orderly resolution of these problems, eg:
• What are key problems to be resolved & in what order• What alternatives exist for resolving a given problem• How should mutual dependencies between the problems be handled• How to resolve each individual problem most effectively in its context
• Help to generate & reuse software architectures
Pattern languages are crucial for domain-specific languages (DSLs)
Model-Driven Development – State of the Art 66
Overview of FrameworksFramework Characteristics
Application-specific functionality
•Frameworks exhibit “inversion of control” at runtime via callbacks
Networking Database
GUI
•Frameworks provide integrated domain-specific structures & functionality
Mission Computing E-commerce
ScientificVisualization
•Frameworks are “semi-complete” applications
34
Model-Driven Development – State of the Art 67
Benefits of Frameworks
CommunicationServices
OS-AccessLayer
BrokerComponentRepository
ComponentConfigurator
Proxy Proxy
Broker
AdminControllers
AdminViews
AdminClientPicking
ControllersPickingViews
PickingClient
Broker
LoggingHandlerThreadPool
*
Reactor
Broker
Scheduler/ActivationList
ServiceRequest
ServiceRequest
ServiceRequest
WarehouseRepHalfX
DistributionInfrastructure
ConcurrencyInfrastructure
Thin UI Clients
• Design reuse• e.g., by guiding application
developers through the steps necessary to ensure successful creation & deployment of software
Summary of Pattern, Framework, & MDD SynergiesThese technologies codify expertise of domain experts & developers
• Patterns codify expertise in the form of reusable architecture design themes & styles, which can be reused event when algorithms, components implementations, or frameworks cannot
• Frameworks codify expertise in the form of reusable algorithms, component implementations, & extensible architectures
Application-specific functionality
Acceptor Connecto
rComponentConfigurator
Stream
Reactor Proactor
Task
There are now powerful feedback loops advancing these technologies
• MDD tools codify expertise by automating key aspects of pattern languages & providing developers with domain-specific modeling languages to access the powerful (& complex) capabilities of frameworks
Model
Application Code
Domain SpecificFramework
PlatformFrameworks
Model
Generated CodeFramework
Pattern Language
Platform
Model
Application Code
Domain SpecificFramework
PlatformFrameworks
Model
Generated CodeFramework
Pattern Language
Platform
Model
Application Code
Domain SpecificFramework
PlatformFrameworks
Model
Generated CodeFramework
Pattern Language
Platform
Model
Application Code
Domain SpecificFramework
PlatformFrameworks
Model
Generated CodeFramework
Pattern Language
Platform
36
71
CONTENTSModel-Driven Development:State of the Art
Introduction & MotivationDefinition of TermsArchitecture-Centric MDD & CascadingRole of Frameworks & Patterns in the Context of MDD
How Generators work – MDD & Compiler ConstructionModel-To-Model TransformationsAn Architectural Process – A Case StudyExamples of Applying MDD Tools: GME & CoSMICAnother Tool: openArchitectureWareSOA, Business Process Modeling, & MDDProduct-line Architecture Case StudySummary
Model-Driven Development – State of the Art 72
Motivation 1
• Why taking a look at compilerconstruction?
• The core concepts of MDD generators arethe same as in compiler construction
–Formal Languages–Transformation of formal artifacts on a
higher abstraction level into formal artifacts on lower abstraction level(i.e., raising the abstraction level forprogramming)
–Modularity• Compiler construction is a domain, which
is well understood. We should be able to harvest some of the experiences madethere: Generators ARE Compilers
C++ Compiler
Internal Rep.
PPCOpt.
MIPSOpt.
88KOpt.
PPC MIPS 88K
C++ Program
37
Model-Driven Development – State of the Art 73
Motivation 2
• So compiler construction might givehints for MDD/A tool developers, butwhy should “users” care about it?
• Construction criteria that have provengood, are selection criteria too
• We can adopt a clear & unambiguousterminology
• In the context of MDD we needopenness
–Adopting or creating own DSLs–Adopting or creating own
TransformationsThat means, the user (i.e., architect) is
involved & confronted to someextent with the inner structure of the compile process
Platform
Frameworks
Application Code
Model
Platform
Generated Code
Model
Platform
Frameworks
Application Code
Model
Platform
Generated Code
Model
Platform
Frameworks
Application Code
Model
Platform
Generated Code
Model
Platform
Frameworks
Application Code
Model
Platform
Generated Code
Model
Model-Driven Development – State of the Art 74
Compiler Construction Blue Print
Program Text
(e.g., C++ Source-Code)
Compiler-Frontend
= Parser
Programming Language
Concrete Syntax
(e.g., C++ or Java)
Abstract Syntax
Compiler-Backend
= Codegenerator
Artifacts Meta-ArtifactsWorkflow
Static Semantics
(e.g., Declaration of Variables)
Abstract Syntax Tree
Generated Code
Optimizer
Checker
Dynamic Semantics
Runtime System
38
Model-Driven Development – State of the Art 75
Core Concept: Abstract SyntaxResponsibilities of Abstract Syntax
• Modularity of the compiler: Interface between Frontend & Backend
• Neutralisation of different Concrete Syntaxes (e.g., C and PASCAL)
• Pluggability for different backends (e.g., codegen for Intel/PC or Mainframe)
• Interface for modification of program structure (e.g., optimization)
Abstract Syntax
Parser 1Parser 2
Codegen 1Codegen 2
Modification
Model-Driven Development – State of the Art 76
Mapping of ConceptsModel-Driven Software Development(general concepts)
A kind of Modeling LanguageA kind of ModelA kind of DSLPart of Meta-ModelModeling-ConstraintsA kind of DSL EditorModel-ReaderModel 2 Code TransformationA kind of Model-2-Model TransformationPlatform
The plain compiler view on MDD is quite “code-generation centric” & seems to focus textual languages, but in fact MDD takes advantage fromgeneralization & further abstraction of those concepts It‘s an evolution
39
Model-Driven Development – State of the Art 77
MDD from Another PerspectiveSo the task of creating a domainarchitecture from the perspective of compiler construction means:
–Define a formal language withconcrete & abstract syntax & staticsemantics (DSL)
–Implement a Parser for the DSL
–Implement the static semantics
–Implement Modifiers orTransformations based on the abstract syntax (M2M-Transformations)
–Implement a runtime system(Platform)
–Implement one or more backends(M2C-Transformations)
DSL
DSL Parser
Codegenerator Transformations
Abstract Representation
Generated Code
M2M-Transformation
Static SemanticChecker
Runtime System
Model-Driven Development – State of the Art 78
How MDD Tools Can HelpMany of these tasks are supported bygeneric tools or frameworks, eg:
–Generic DSLs with extensionmechanisms (e.g., UML)
/*** Return the last time the client sent a request
associated with this* session, as the number of milliseconds since
midnight, January 1, 1970* GMT Actions that your application takes, such as
getting or setting* a value associated with the session, do not affect
the access time*/public long getLastAccessedTime() {
return (thislastAccessedTime);
}
thislastAccessedTime = time;
ConfigurationSpecification Analysis Tool
Code
40
Model-Driven Development – State of the Art 79
MDD Tool Blueprint
DSL-Editor Generator
Generic DSL-Editor
Tool Support (Open Compiler) Architect‘s Input
Parser Generator
Template Engine
M2M Engine
Metamodel Generator
Constraint Engine
DSL-Model
DSL-Profile
DSL-Grammar Spec
Metamodel
Constraints
M2M Transformations
M2C Transformations
MDSD-Platform
Formal
Language and
Parser
AS
Static Sematics
Runtime System
Backend
Model-Driven Development – State of the Art 80
Example: openArchitectureWare (oAW)
oAW – brief introduction• Open MDD-Framework (i.e., a framework that enables you to write
compilers/generators in the former sense)• Open Source since 11/2002, contributed to the community by b+m
Informatik AG (www.bmiag.de)• More on that later
41
Model-Driven Development – State of the Art 81
oAW – an Object–Oriented Compiler Framework
• Object-orientation is useful for compiler construction, because
– an Abstract Syntax naturally maps to an object-orientedimplementation (Meta Classes, Associations …)
– Unmaintainable switch/case statements on syntax element types canbe avoided in transformations by using polymorphism and late binding
– For usual compilers (C++, Pascal …), this is a view into the black box From the viewpoint of the user the construction details of the compilerare irrelevant
– Note that this does NOT hold in the MDD-context, sincethe AS/MM is plugged into the frameworkSo we are in need of an open compiler/generator framework
– Each Meta-Element has the responsibility to translate itself
– Polymorphism can be used at the meta level
Model-Driven Development – State of the Art 82
Object–Orientation in oAWModel expressed via Concrete Syntax
(e.g., UML-Profile)
MetaModel / Abstract Syntax
(oAW: Implementation in Java)
Check: Every „EntityObject“ must
have at least one „key“-Attribute
Responsibilities (Object-Oriented)
M2C-Template: Generate EJB-Home-Interface
M2C-Template: Generate Hibernate-Mapping
Helper/Property: Return a full qualified Java-Classname
Some Responsibilities are implemented in Java (Properties, Checks), others using the oAW-Templatelanguage (M2C) They are implemented in or decorated on the respective Meta-Classes
42
Model-Driven Development – State of the Art 83
openArchitectureWare – BlueprintDomain Architecture 1 ApplicationoAW - Workflow and Information Flow
M2M-Transformation
Model
Hand written Code
Generated Code
Metamodel Implementation
M2M-Transformation-Implementation
Domain Architecture n
M2C-Transformation-Implementation
DSL
DSL
Instantiated Metamodel (1)
<<instanceof>>Constraints
Metamodel Implementation
Constraints
Instantiated Metamodel (n)
<<instanceof>>
<<relies on>>
<<integra tes into>>
Platform nPlatform n
<<uses>>
[error]
[error]
M2C Transformation(Template-Engine)
Constraint Check
Constraint Check
Model Reader /Parser
84
CONTENTSModel-Driven Development:State of the Art
Introduction & MotivationDefinition of TermsArchitecture-Centric MDD & CascadingRole of Frameworks & Patterns in the Context of MDDHow Generators work – MDD & Compiler Construction
Model-To-Model TransformationsAn Architectural Process – A Case StudyExamples of Applying MDD Tools: GME & CoSMICAnother Tool: openArchitectureWareSOA, Business Process Modeling, & MDDProduct-line Architecture Case StudySummary
• As explained before, cascading MDD requires model-to-model transformations
Model-Driven Development – State of the Art 86
Modular, Automated Transformations
• To more easily reuse parts of a transformation, it is a good idea to modularize a transformation
• Note that in contrast to the OMG, we do not recommend looking at, changing or marking the intermediate models
• They are merely a standardized format for exchanging dataamong transformations
• Example: Multi-Step transformation from a banking-specific DSL to Java via J2EE
Banking-Metamodell
Bank /OO OO Metamodel
J2EE MetamodelProcess
MetamodelBank /Prozess
OO/J2EE
Process/J2EE
WLSMetamodel
WebSphereMetamodel
J2EE/B
EA
J2EE/IB
M
JavaMetamodel
BEA/Java
IBM/Java
44
Model-Driven Development – State of the Art 87
Modular, Automated Transformations II• Example cont’d:
Now consider a Call-Center application; only the first step needs to be adapted
• If both should be transformed to NET, only the backend needs to be exchanged
CallCenterMetamodel
CC /OO OO Metamodel
ProcessMetamodel
CC /Prozess
...
...
...
OO Metamodel
ProcessMetamodel
OO/.NET
Prozess/.NET
.NET Metamodel .NET/C# C# Metamodel
Model-Driven Development – State of the Art 88
Transforming “in the Tool”
openArchitectureWareModel(UML)
Model(XMI)
ParserModel
(Object Graph)
ModelTrans-former
Modified Model(Object Graph)
export
Generated Code
CodeGenerator
(may be repeated)
Developer builds model using for example a UML
tool
45
Model-Driven Development – State of the Art 89
openArchitectureWareModel(UML)
Model(XMI)
ParserModel
(Object Graph)
ModelTrans-former
Modified Model(Object Graph)
export
Generated Code
CodeGenerator
(may be repeated)
The XMI produced by the UML tool is parsedby the generator tool –& an AST is created
in memory
Transforming “in the Tool”
Model-Driven Development – State of the Art 90
openArchitectureWareModel(UML)
Model(XMI)
ParserModel
(Object Graph)
ModelTrans-former
Modified Model(Object Graph)
export
Generated Code
CodeGenerator
(may be repeated)Inside the generator,model-to-model
transformations are used to build new or modified ASTs
The intermediate ASTscannot be modifiedinteractively by the
developer
Transforming “in the Tool”
46
Model-Driven Development – State of the Art 91
openArchitectureWareModel(UML)
Model(XMI)
ParserModel
(Object Graph)
ModelTrans-former
Modified Model(Object Graph)
export
Generated Code
CodeGenerator
(may be repeated)
In a final step, code is generated from
the AST
Transforming “in the Tool”
Model-Driven Development – State of the Art 92
External Model Markings (AO–Modeling)
• To allow the transformation of a source model into a target model (or to generate code) it is sometimes necessary to provide “support”information that is specific to the target meta model
–Example: Entity Bean vs Type Manager
• Adding these to the source model “pollutes” the source model with concepts specific to the target model
• MDA proposes to add “model markings,” but this currently supported well by very few tools
• Instead, we recommend keeping this information outside of the model(e.g., in an XML file); the transformation engine would use this auxiliary information when executing the transformations
• This is an example of “aspect-oriented programming”
47
Model-Driven Development – State of the Art 93
M2M: One Metalevel Higher– Precondition:
Representing a class diagram of metalevel n as an object diagram of metalevel n+1
Model-Driven Development – State of the Art 94
Model–to–Model Transformations: QVT
• Most of the transformations I have built by now have been constructed with Java code– If the metaclasses have a well-designed API (repository API) then
this „procedural transformations“ do indeed work well
• However, more & more dedicated model transformation languagesbecome available:– ATL, MOLA, Wombat (oAW), etc
• The QVT standard isbecoming a reality Itwill be finalized bythe end of 2006
Model createEJBModel( Model source ) {Model target = new Model();foreach c:Class in sourceclasses {
ImplementationClass implClass = new ImplementationClass();implClasssetName( cgetName()+"Bean" );targetaddClass( implClass ); Dependenciesdefine( implClass, c );RemoteInterface ri = new RemoteInterface ();// set name & add it to target modelHomeInterface hi = new HomeInterface ();// set name & add it to target modelforeach o:Operation in coperations {
// bidirectional, because of generated APIriaddOperation( new Operation( oclone() ) );implClassaddOperation( new Operation( oclone() ) );
}}return target;
}
• With good metaclasses, this works acceptably today
50
Model-Driven Development – State of the Art 99
Graphical M2M: UMLX
class:UML::Class
*
1
AssociationEnd
Class
in component:CM::Component
out
otherSideEnd:UML::AssociationEnd
roleName = $nnavigable = true
assocAttributeUML::Attribute
name = $n
thisSideEnd:UML::AssociationEnd
assoc:UML::Association
<<UML::Class>>Vehicle
plate : Stringtype: String
Personname : String
drive() : void
driver
<<CM::Component>>Person
name : String
<<CM::Component>>Vehicle
plate : Stringtype: Stringdriver : Person
drive() : void
Model-Driven Development – State of the Art 100
Many Means of Transformations• Today, many means of transformations are used:
• Plain old Java• Eclipse GMT ATL• IBM MTF
• A paper by Czarnecki/Helsen gives a very good overview:www.swen.uwaterloo.ca/~kczarnec/ECE750T7/czarnecki_helsen.pdf
• ISIS GReAT• Several partial QVT implementations• UMLX
51
101
CONTENTSModel-Driven Development:State of the Art
Introduction & MotivationDefinition of TermsArchitecture-Centric MDD & CascadingRole of Frameworks & Patterns in the Context of MDDHow Generators work – MDD & Compiler ConstructionModel-To-Model Transformations
An Architectural Process –A Case StudyExamples of Applying MDD Tools: GME & CoSMICAnother Tool: openArchitectureWareSOA, Business Process Modeling, & MDDProduct-line Architecture Case StudySummary
Technology–Independent Architecture• We decide that our system will be built from components
– Each component can provide a number of interfaces– It can also use a number of interfaces (provided by other
components) – Communication is synchronous, Communication is also restricted to
be local– We design components to be stateless
• In addition to components, we also explicitly support businessprocesses
– These are modeled as a state machine– Components can trigger the state machine by supplying events to
them– Other components can be triggered by the state machine, resulting in
the invocation of certain operations– Communication to/from processes is asynchronous, remote
communication is supported
54
Model-Driven Development – State of the Art 107
• We decide that our system will be built from components– Each component can provide a number of interfaces– It can also use a number of interfaces (provided by other
components) – Communication is synchronous, Communication is also restricted to
be local– We design components to be stateless
• In addition to components, we also explicitly support businessprocesses
– These are modeled as a state machine– Components can trigger the state machine by supplying events to
them– Other components can be triggered by the state machine, resulting in
the invocation of certain operations– Communication to/from processes is asynchronous, remote
communication is supported
Technology–Independent Architecture
Use the well-known architectural styles & patternshere Typically these are best practices for architectingcertain kinds of systems independent of a particulartechnology They provide a reasonable starting point fordefining (aspects of) your systems's architecture
• The programming model uses a simple DependencyInjection approach à la Spring to define componentdependencies on an interface level
• An external XML file takes care of the configuration of the instances
Model-Driven Development – State of the Art 110
Programming Model• The following piece of code shows the implementation of a simple
example component Note how we use Java 5 annotations
• Processes engines are components like any other• For triggers, they provide an interface w/ void operations• They also define interfaces with the actions that those components can
implement that want to be notified of state changes
public @component class ExampleComponentimplements HelloWorld { // provides HelloWorld
private IConsole console;
public @resource void setConsole( IConsole c ) { thisconsole = c; // setter for console
} // component
public void sayHello( String s ) { consolewrite( s );
}
}
56
Model-Driven Development – State of the Art 111
Programming Model
public @process class SomeProcessimplements ISomeProcessTrigger {
private IHelloWorld resource;
public @resource void setResource( IHelloWorld w ) {thisresource = w;
}
public @trigger void T1( int procID ) { SomeProcessInstance i = loadProcess( procID );if ( guardG1() ) {
// advance to another state…}
}
public @trigger void T2( int procID ) {SomeProcessInstance i = loadProcess( procID );// …resourcesayHello( "hello" );
Vertical Prototype• The vertical prototype includes parts of the customer & billing systems
–For creating an invoice, the billing system uses normal interfaces to query the customer subsystem for customer details
–The invoicing process is based on a long-running process
• A scalability test was executed & resulted in two problems:
–For short running processes, the repeated loading & saving of persistent process state had become a problem A caching layerwas added
–Second, web-service based communication with process components was a problem Communication was changed to CORBA for remote cases that were inside the company
60
Model-Driven Development – State of the Art 119
• The vertical prototype includes parts of the customer & billing systems–For creating an invoice, the billing system uses normal interfaces to
query the customer subsystem for customer details–The invoicing process is based on a long-running process
• A scalability test was executed & resulted in two problems: –For short running processes, the repeated loading & saving of
persistent process state had become a problem A caching layerwas added
–Second, web-service based communication with process components was a problem Communication was changed to CORBA for remote cases that were inside the company
Vertical Prototype
Work on performance improvements here, not earlier
It is bad practice to optimize design for performance from the beginning, since this often destroys good architectural practice
In certain domains, there are patterns to realize certain QoS properties (such as stateless design for large-scale business systems) You shouldn't ignore these intentionally at the beginning
if a component B is a new versionof a component A, then B has tohave the same interfaces,additional provided interfaces,fewer required interfaces or newversion of interfaces of A
a new version of an interface has tohave the same return type and thesame parameters - or parameterswith subtypes.
ProcessComponent
StateMachine State
1..n
Transition
fromto0..n 0..n
TriggerOperation0..1
Components can provide & require
interfaces
Model-Driven Development – State of the Art 124
Architecture Metamodel
Interface
providedInterface
0..n
requiredInterface
0..n
Container
0..n
Component
Characteristic0..n
ContainerService0..n
Operation1..n
Parameter
0..n
Type
retu
rnTy
pe
type
PrimitiveType
ComplexType
1 0..n
newVersionOf
1 0..n
newVersionOf
if a component B is a new versionof a component A, then B has tohave the same interfaces,additional provided interfaces,fewer required interfaces or newversion of interfaces of A
a new version of an interface has tohave the same return type and thesame parameters - or parameterswith subtypes.
ProcessComponent
StateMachine State
1..n
Transition
fromto0..n 0..n
TriggerOperation0..1
Interfaces have operations – they’re
defined as usual
63
Model-Driven Development – State of the Art 125
Architecture Metamodel
Interface
providedInterface
0..n
requiredInterface
0..n
Container
0..n
Component
Characteristic0..n
ContainerService0..n
Operation1..n
Parameter
0..n
Type
retu
rnTy
pe
type
PrimitiveType
ComplexType
1 0..n
newVersionOf
1 0..n
newVersionOf
if a component B is a new versionof a component A, then B has tohave the same interfaces,additional provided interfaces,fewer required interfaces or newversion of interfaces of A
a new version of an interface has tohave the same return type and thesame parameters - or parameterswith subtypes.
ProcessComponent
StateMachine State
1..n
Transition
fromto0..n 0..n
TriggerOperation0..1
Process Components are special kinds of
components
Model-Driven Development – State of the Art 126
Architecture Metamodel
Interface
providedInterface
0..n
requiredInterface
0..n
Container
0..n
Component
Characteristic0..n
ContainerService0..n
Operation1..n
Parameter
0..n
Type
retu
rnTy
pe
type
PrimitiveType
ComplexType
1 0..n
newVersionOf
1 0..n
newVersionOf
if a component B is a new versionof a component A, then B has tohave the same interfaces,additional provided interfaces,fewer required interfaces or newversion of interfaces of A
a new version of an interface has tohave the same return type and thesame parameters - or parameterswith subtypes.
ProcessComponent
StateMachine State
1..n
Transition
fromto0..n 0..n
TriggerOperation0..1
A process component’s process is described using a
state machine
64
Model-Driven Development – State of the Art 127
Architecture Metamodel
Interface
providedInterface
0..n
requiredInterface
0..n
Container
0..n
Component
Characteristic0..n
ContainerService0..n
Operation1..n
Parameter
0..n
Type
retu
rnTy
pe
type
PrimitiveType
ComplexType
1 0..n
newVersionOf
1 0..n
newVersionOf
if a component B is a new versionof a component A, then B has tohave the same interfaces,additional provided interfaces,fewer required interfaces or newversion of interfaces of A
a new version of an interface has tohave the same return type and thesame parameters - or parameterswith subtypes.
ProcessComponent
StateMachine State
1..n
Transition
fromto0..n 0..n
TriggerOperation0..1
And the triggers are special kinds
of operations
Model-Driven Development – State of the Art 128
Architecture Metamodel
Interface
providedInterface
0..n
requiredInterface
0..n
Container
0..n
Component
Characteristic0..n
ContainerService0..n
Operation1..n
Parameter
0..n
Type
retu
rnTy
pe
type
PrimitiveType
ComplexType
1 0..n
newVersionOf
1 0..n
newVersionOf
if a component B is a new versionof a component A, then B has tohave the same interfaces,additional provided interfaces,fewer required interfaces or newversion of interfaces of A
a new version of an interface has tohave the same return type and thesame parameters - or parameterswith subtypes.
ProcessComponent
StateMachine State
1..n
Transition
fromto0..n 0..n
TriggerOperation0..1
A container runs a number of components
65
Model-Driven Development – State of the Art 129
Architecture Metamodel
Interface
providedInterface
0..n
requiredInterface
0..n
Container
0..n
Component
Characteristic0..n
ContainerService0..n
Operation1..n
Parameter
0..n
Type
retu
rnTy
pe
type
PrimitiveType
ComplexType
1 0..n
newVersionOf
1 0..n
newVersionOf
if a component B is a new versionof a component A, then B has tohave the same interfaces,additional provided interfaces,fewer required interfaces or newversion of interfaces of A
a new version of an interface has tohave the same return type and thesame parameters - or parameterswith subtypes.
• Our scenario has several useful locations for glue code generation–We generate the Hibernate mapping files –We generate the web service & CORBA adapters based on the
interfaces & data types that are used for communication The generator uses reflection to obtain the necessary type information
–Finally, we generate the process interfaces from the state machine implementations
• In the programming model, we use Java 5 annotations to mark upthose aspects that cannot be derived by using reflection alone
• Annotations can help a code generator to "know what to generate"without making the programming model overly ugly
System model deploysconfigurations onto systems& nodes Nodes define the
kind of system they represent
Model-Driven Development – State of the Art 138
DSL–based Programming Model
<<gen-code>>SomeEntity.java
<<entity>>SomeEntity
<<generate>>
<<interface>>SomeEntityDAO
<<transform>><<generate>> <<gen-code>>
SomeEntity-DAO.java
<<component>>SomeEntityDAO
<<transform>><<generate>> <<gen-code>>
SomeEntity-DAOBase
.java
<<gen-code>>SomeEntity-
DAO.java
<<generate>>
• Using Cascaded MDD, we generate –DAO Components for Entities from the Entities in the model–An interface for the DAO component,–As well as the implementation code for the DAO & the Entity itself
Instead of letting developers implement the business logic manually, we generate an “Intermediate” class that contains the executable, & persistence-aware state
machine
• We also use cascading for the Process Components
Introduction & MotivationDefinition of TermsArchitecture-Centric MDD & CascadingRole of Frameworks & Patterns in the Context of MDDHow Generators work – MDD & Compiler ConstructionModel-To-Model TransformationsAn Architectural Process – A Case Study
Examples of Applying MDD Tools: GME & CoSMICAnother Tool: openArchitectureWareSOA, Business Process Modeling, & MDDProduct-line Architecture Case StudySummary
76
Model-Driven Development – State of the Art 151
MDD Tool Developers (Metamodelers)
Application Developers (Modelers)
Generic Modeling Environment (GME)
GME is open-source: www.isis.vanderbilt.edu/Projects/gme/default.htm
“Write Code That Writes Code That Writes Code!”
Decorator Decorator
GModel GMeta
CORE
MetamodelXML
Paradigm Definition
Storage Options… DB #nDB #1 XML …
UML / OCL
COM
COMCOM
XML
XML
ODBC
ConstraintManagerBrowser
Translator(s)Add-On(s)
GME Editor
GME Architecture
Supports “correct-by-construction” of software systems
Model-Driven Development – State of the Art 152
MDD Application Development with GME
•Application developers use modeling environments created w/MetaGME to build applications–Capture elements & dependencies visually
77
Model-Driven Development – State of the Art 153
MDD Application Development with GME
•Application developers use modeling environments created w/MetaGME to build applications–Capture elements & dependencies visually
–Model interpreter produces something useful from the models•e.g., 3rd generation code, simulations, deployment descriptions & configurations
Introduction & MotivationDefinition of TermsArchitecture-Centric MDD & CascadingRole of Frameworks & Patterns in the Context of MDDHow Generators work – MDD & Compiler ConstructionModel-To-Model TransformationsAn Architectural Process – A Case StudyExamples of Applying MDD Tools: GME & CoSMIC
Another Tool: openArchitectureWareSOA, Business Process Modeling, & MDDProduct-line Architecture Case StudySummary
109
Model-Driven Development – State of the Art 217
Modeling Frontends
• Frontends (parsers) are pluggable• a large number of UML modeling tools
• A cartridge is a self-sustained “piece of tool”i.e., it comes with templates, transformations, workflow snippets, metaclasses
• Real, Deep modularizationa cartridge can extend other cartridges by– extending metaclasses– overriding templates– advising templates (before, after, around)– providing new methods for existing metaclasses
111
Model-Driven Development – State of the Art 221
Code Generation
• powerful & elegant template language (XPand)– template modularization– template polymorphism– template overriding– AOP support for template
• Checks manually written code for compliance with a defined programming model– Based on the
model, checksare instantiated
– The IDE (Eclipse) verifies the checks & provides quick fixes
112
Model-Driven Development – State of the Art 223
Model–to–Model Transformation
V4
• model transformation as well as model-enrichment/completion
• Java code can be used for transformationsvery rich APIs & libraries are provided to make this easy
• WOMBAT: Textual, functional languagepowerful collections support, sameexpression language as in XPand
Can operate on all supported metametamodels(EMF, MDR, oAW classic) & transform between them
• Integration with Industry-Standard M2M tools such as ATL for EMF metamodels
CREATE (#Book: {title <- „XYZ",numPages <- 1354
});
V4
Model-Driven Development – State of the Art 224
Status / Track Record / Future
• Version 3.1 is current
• Proven track record in various domains & projectcontextstelcos, internet, enterprise, embedded realtime, finance, …
• Version 4 will be released end of Jan, 2006– Parts are already in use by some developers– First milestone build Dec 15, 2005
• www.openarchitectureware.org
LIVE DEMO!
113
225
CONTENTSModel-Driven Development:State of the Art
Introduction & MotivationDefinition of TermsArchitecture-Centric MDD & CascadingRole of Frameworks & Patterns in the Context of MDDHow Generators work – MDD & Compiler ConstructionModel-To-Model TransformationsAn Architectural Process – A Case StudyExamples of Applying MDD Tools: GME & CoSMICAnother Tool: openArchitectureWare
SOA, Business Process Modeling, & MDDProduct-line Architecture Case StudySummary
Model-Driven Development – State of the Art 226
What is SOA?• The whole concept of SOA is not really well defined today. There are a
couple of ideas:–SOA (at least in practice) means web services–SOA means that everything is run through one middleware
infrastructure instead of many–SOA means, that IT is more business department-oriented
• Rather, SOA is an architectural style to build scalable (performance as well as size), maintainable & managable systems
114
Model-Driven Development – State of the Art 227
A Typical SOA Blueprint
Model-Driven Development – State of the Art 228
SOA vs. Component – Based Architecture• A well-done component-based architecture with well-defined
interfaces & clearly cut component responsibilities can quite justifiable be considered SOA
–Components are a natural choice as the building blocks that provide & consume services, specifically, since component platforms already separate functionality from infrastructure!
–The industry currently defines a standard for Service-Component Architectures [SCA]
115
Model-Driven Development – State of the Art 229
Characteristics of SOAs• Service interactions are typically (though not mandatorily) message-
oriented, or document centric–Instead of defining rigidly typed interfaces, document structures
(schemas) are defined that serve as the basis for interactions –This can make evolution of message structures & versioning much
simpler
• The interaction patterns, i.e., valid sequences of messages are explicitly defined
–Interactions are often conversational, i.e., conversational session state is kept „at both sides“ of a service interaction
–This allows orchestration among services –Usually, interactions are asynchronous
Model-Driven Development – State of the Art 230
Characteristics of SOAs II• Quality of service aspects are explictly addressed
–Service providers do not just provide a certain services’ functionality, they provide the functionality with a define service level (performance, reliability, etc)
• Service descriptions & characteristics are available at runtime–Using service registries systems can be assembled dynamically
• Often, services are interoperable - they can be used by systems implemented on various platforms
• Services should be designed to be coarse grained & encapsulate functionality relevant from “business perspective” (although nobody can say what this really means)
• Services are typically (but by no means exclusively) used by explicitly modeled business processes
• They are secure, transactional & manageable (like any good system)
116
Model-Driven Development – State of the Art 231
Relationship to MDD• MDD is ideally suited to describe & develop these kinds of systems
The signatures & data structures used in the service
can be using models
Model-Driven Development – State of the Art 232
Relationship to MDD• MDD is ideally suited to describe & develop these kinds of systemsThe valid interactions
can be defined using models (e.g., protocol
state machines)
117
Model-Driven Development – State of the Art 233
Relationship to MDD• MDD is ideally suited to describe & develop these kinds of systems
Quality of Service Contractscan be defined using models –code to watchdog them can be
generated
Model-Driven Development – State of the Art 234
Relationship to MDD• MDD is ideally suited to describe & develop these kinds of systems
Component-based Development, as well as
the assignment of service providers &
services comsumerscan be based on models
118
Model-Driven Development – State of the Art 235
Relationship to MDD• MDD is ideally suited to describe & develop these kinds of systems
Glue code for the deployment to various execution platforms can
be generated automatically
Model-Driven Development – State of the Art 236
Relationship to MDD• MDD is ideally suited to describe & develop these kinds of systems
The Mappings of the Service Messages/Calls
to communication infrastructures (web
services, Tibco, JMS, ) can be automatically
generated
119
Model-Driven Development – State of the Art 237
Relationship to MDD• MDD is ideally suited to describe & develop these kinds of systems
The runtime repository can be populated from the data in the models
Model-Driven Development – State of the Art 238
Metamodel for SOA/CBD Development• This metamodel describes
Metamodel for SOA/CBD Development• This one describes component instances & their “wiring”
Model-Driven Development – State of the Art 240
Metamodel for SOA/CBD Development• This final viewpoint associates component instances with nodes & containers for
deployment & glue code generation
121
Model-Driven Development – State of the Art 241
Metamodel for SOA/CBD Development• Dependencies between viewpoint models are only allowed in the way shown
below in order to– Be able to have several compositions per type model– And several system models per composition
• This is important to be able to have several “systems”,– Several deployed locally for testing, using only a subset of the defined
components,– And “the real system”
Model-Driven Development – State of the Art 242
A Simple Metamodel for SOA – with CBD
Service
Message
name
Type
name
Attribute
name
*
type
RequestMessage
OnewayMessage
OutboundMessage
1..*
MessageFlow
Control
*
*ElementaryService
resp
InboundMessageaccepted
Message
1..*Compound
Service
Component
name
Provider Consumer
0..1
1..*1..*
1..*
providesconsumes p
c
1..*
ProviderConsumer
• Here we define thenotion of a servicemore extensively
• Note how servicesare connected to thecomponents definedin the previous setof metamodels
• Note that the SCA standard uses the same metaphors: components, instances, deployment, services
122
Model-Driven Development – State of the Art 243
Business Process Modeling & SOA• BPM comes top down, SOA goes bottom up (driven by WS-technology)• There is a non-empty intersection: Declaration of BPs, infrastructure
software (BPE, ESB). Approaches are not harmonized yet (e.g. BPEL vs. BPML/N)
• However, there are significant synergies – especially when using separation of concerns. BPM needs SOA but not the other way round
Business Processes & BPE
Service Interfaces & Middleware (ESB)
Service Providing &Consuming Components
Model-Driven Development – State of the Art 244
Business Process Modeling & SOA• BPM comes top down, SOA goes bottom up (driven by WS-technology)• There is a non-empty intersection: Declaration of BPs, infrastructure
software (BPE, ESB). Approaches are not harmonized yet (e.g. BPEL vs. BPML/N)
• However, there are significant synergies – especially when using separation of concerns. BPM needs SOA but not the other way round
Business Processes & BPE
Service Interfaces & Middleware (ESB)
Service Providing &Consuming Components
The business processes are typically
also modeled, as is their relationship to the service
(interfaces) they use
123
Model-Driven Development – State of the Art 245
Business Process Modeling & SOA• BPM comes top down, SOA goes bottom up (driven by WS-technology)• There is a non-empty intersection: Declaration of BPs, infrastructure
software (BPE, ESB). Approaches are not harmonized yet (e.g. BPEL vs. BPML/N)
• However, there are significant synergies – especially when using separation of concerns. BPM needs SOA but not the other way round
Business Processes & BPE
Service Interfaces & Middleware (ESB)
Service Providing &Consuming Components
Note that it is often unrealistic to have one &
only one middleware because of varying non-functional requirements
Model-Driven Development – State of the Art 246
Business Process Modeling & SOA• BPM comes top down, SOA goes bottom up (driven by WS-technology)• There is a non-empty intersection: Declaration of BPs, infrastructure
software (BPE, ESB). Approaches are not harmonized yet (e.g. BPEL vs. BPML/N)
• However, there are significant synergies – especially when using separation of concerns. BPM needs SOA but not the other way round
Business Processes & BPE
Service Interfaces & Middleware (ESB)
Service Providing &Consuming Components
The important thing is that you are able to map the same
services to different middleware infrastructures –
& use all of them from the business processes Again a
reason to use models!
124
247
CONTENTSModel-Driven Development:State of the Art
Introduction & MotivationDefinition of TermsArchitecture-Centric MDD & CascadingRole of Frameworks & Patterns in the Context of MDDHow Generators work – MDD & Compiler ConstructionModel-To-Model TransformationsAn Architectural Process – A Case StudyExamples of Applying MDD Tools: GME & CoSMICAnother Tool: openArchitectureWareSOA, Business Process Modeling, & MDD
Product-line Architecture Case StudySummary
Model-Driven Development – State of the Art 248
Nav Sensors
ExpendableManagement
Data LinksMissionComputer
VehicleMgmt
Expendables
•Avionics mission computing product-line architecture for Boeing aircraft
•DRE system with 100+ developers, 3,000+ software components, 3-5 million lines of C++
•Based on COTS hardware, networks, operating systems, languages, & middleware
Common Middleware ServicesCommon Middleware ServicesDomain-specific ServicesDomain-specific Services
AirFrame
APNav
HUD GPS
IFF
FLIR
Overview of Product-line Architectures (PLAs)
Reusable Architecture Framework
Reusable Application Components
128
Model-Driven Development – State of the Art 255
Applying SCV to the Bold Stroke PLA•Commonalities describe the attributes that are common across all members of the PLA family•Common object-oriented frameworks & set of component types
3: Sensor proxies process data & pass to missionsfunctions
4: Mission functions perform avionics operations
Limitations with Legacy Avionics Architectures•Stovepiped•Proprietary•Expensive•Vulnerable•Tightly coupled•Hard to schedule•Brittle & non-adaptive
AirFrame
AP
Nav WTS
GPS IFF
FLIR
Cyclic Exec
Model-Driven Development – State of the Art 260
Decoupling Avionics Components
•Apply the Publisher-Subscriber architectural pattern to distribute periodic, I/O-drivendata from a single point of source to a collection of consumers
Bold Stroke uses the Publisher-Subscriber pattern to decouple sensor processing from mission computing operations• Anonymous publisher & subscriber relationships
• Group communication• Asynchrony
Model-Driven Development – State of the Art 262
Ensuring Platform-neutral Inter-process Communication
•Apply the Brokerarchitectural pattern to provide platform-neutral commsbetween mission computing boards
•Applications need capabilities to:• Support remote communication• Provide location transparency• Handle faults• Manage end-to-end QoS• Encapsulate low-level system details
: Broker: Client Proxy : Server Proxy: Client : Server
Ensuring Platform-neutral Inter-process Communication
•Apply the Brokerarchitectural pattern to provide platform-neutral commsbetween mission computing boards
•Applications need capabilities to:• Support remote communication• Provide location transparency• Handle faults• Manage end-to-end QoS• Encapsulate low-level system details
•Mission computing requires remote IPC
•Stringent DRE requirements
SolutionProblemsContext
Model-Driven Development – State of the Art 264
Applying the Broker Pattern to Bold Stroke
Board 1
VME
1553
1: Sensors generate data
Board 2
2: I/O via interrupts
5: Event Channel pushes events to subscribers(s)
6: Subscribers perform avionics operations
GPS IFF FLIR
HUD Nav WTS Air Frame
Publishers
Subscribers
push(event)
push(event)
Event Channel
4: Sensor publishers push events to event channel
Bold Stroke uses the Broker pattern to shield distributed applications from environment heterogeneity, e.g.,•Programming languages•Operating systems•Networking protocols•Hardware
3: Brokerhandles I/O via upcalls
BrokerA key consideration for implementing the Broker pattern for mission computing applications is QoS support
Benefits of Component Middleware•Creates a standard “virtual boundary” around application component implementations that interact only via well-defined interfaces
•Define standard container mechanisms needed to execute components in generic component servers
•Specify the infrastructure needed to configure & deploy components throughout a distributed system
•Modeling technologies are still maturing & evolving
• i.e., non-standard tools
•Magic (& magicians) are still necessary for success
Model & Component Library
ApplicationsApplications
$ $ $
Limitations of MDD
140
279
CONTENTSModel-Driven Development:State of the Art
Introduction & MotivationDefinition of TermsArchitecture-Centric MDD & CascadingRole of Frameworks & Patterns in the Context of MDDHow Generators work – MDD & Compiler ConstructionModel-To-Model TransformationsAn Architectural Process – A Case StudyExamples of Applying MDD Tools: GME & CoSMICAnother Tool: openArchitectureWareSOA, Business Process Modeling, & MDDProduct-line Architecture Case Study
Summary
Model-Driven Development – State of the Art 280
Open MDD R&D Issues• Inherent Complexities• Capturing specificity of target domain
• Automated specification & synthesis of
• Model interpreters
• Model transformations
• Broader range of application capabilities
• Static & dynamic QoS properties
• Migration & version control of models
• Scaling & performance
• Verification of the DSLs
Solutions require validation on large-scale, real-world systems
• Accidental Complexities• Round-trip engineering from
models ↔ source
• Mismatched abstraction levels for development vs debugging
• Tool chain vs monolithic tools
• Backward compatibility of modeling tools
• Standard metamodeling languages & tools
141
Model-Driven Development – State of the Art 281
Positive Development
• Today’s tools can be used productively – although sometimes some “magic” is necessary
• Today’s problem is not really that we need better tools, we rather need more experience!
• Standardization efforts are slowly coming to fruition: EMF, QVT, MIC
• CoSMIC is available from www.dre.vanderbilt.edu/cosmic
• GME is available from www.isis.vanderbilt.edu/Projects/gme/default.htm
• openArchitectureWare is available fromwww.openarchitectureware.org
Start today – it will make you more productive
Model-Driven Development – State of the Art 282
Some Advertisements ☺
• For those, who speak(or rather, read ;-)) german: