Kein Folientitel

1
Model-DrivenSoftware Development
www.mdsd-buch.de
Some Essential Best Practices
Markus Völtervoelter_at_acm.orgwww.voelter.de
2
About me

• Markus Völter
• voelter_at_acm.org
• www.voelter.de

• Independent Consultant
• Based out of Heidenheim, Germany
• Focus on
• Software Architecture
• Model-Driven SoftwareDevelopment
• Middleware

3
Before we start I

• Model-Driven Software Development is about making
  software development more domain-related as
  opposed to computing related. It is also about
  making software development in a certain domain
  more efficient.

4
Before we start II MDSD on a Slide
several
Metametamodel
target
subdomains
software
software
designexpertise
architecture
architecture
bounded area of
partial
knowlege/interest
composable
multiple
knowledge
viewpoint
multi-step
transform
Domain
single-step
semantics
compile
Model
Ontology
interpret
no
precise/
Domain
roundtrip
executable
Specific
Language
graphical
Metamodel
textual
5
Before we start III MDSD and MDA
MOF
several
Metametamodel
target
software
software
subdomains
architecture
architecture
designexpertise
bounded area of
partial
knowlege/interest
composable
PIM, PSM, ....
QVT
multiple
viewpoint
multi-step
transform
Domain
single-step
Model
semantics
compile
Ontology
interpret
no
precise/
Domain
roundtrip
executable
Specific
Language
OCL, Action Semantics
UMLProfiles
graphical
Metamodel
textual

• Focus Platform Independence, (Tool) Interop

6
C O N T E N T S

• Domain Architecture
• Domain Metamodelling
• Code Generation
• Tools
• Features And Structure
• An Example
• Process
• Multi Model
• Architecture and CBD
• Adopting MDSD

Model-DrivenSoftware Development
www.mdsd-buch.de
Best Practices
7
C O N T E N T S

• Domain Architecture
• Domain Metamodelling
• Code Generation
• Tools
• Features And Structure
• An Example
• Process
• Multi Model
• Architecture and CBD
• Adopting MDSD

Model-DrivenSoftware Development
www.mdsd-buch.de
Best Practices
8
How do I come up with a good metamodel?

• Incrementally!
• Based on experience from previous projects, and
  by mining domain experts.
• A very good idea is to start with a (typically)
  very well known domain the target software
  architecture (platform)? Architecture-Centric
  MDSD

9
Talk Metamodel

• In order to continuously improve and validate the
  FORMAL META MODEL for a domain, it has to be
  exercised with domain experts as well as by the
  development team.
• In order to achieve this, it is a good idea to
  use it during discussions with stakeholders by
  formulating sentences using the concepts in the
  meta model.
• As soon as you find that you cannot express
  something using sentences based on the meta
  model,
• you have to reformulate the sentence
• the sentences statement is just wrong
• you have to update the meta model.

10
Talk Metamodel II

• Example

• A component owns any number of ports.
• Each port implements exactly one interface.
• There are two kinds of ports required ports and
  provided ports.
• A provided port provides the operations defined
  by its interface.
• A required port provides access to operations
  defined by its interface.

11
C O N T E N T S

• Domain Architecture
• Domain Metamodelling
• Code Generation
• Tools
• Features And Structure
• An Example
• Process
• Multi Model
• Architecture and CBD
• Adopting MDSD

Model-DrivenSoftware Development
www.mdsd-buch.de
Best Practices
12
Leverage the Model

• The information captured in a model should be
  leveraged to avoid duplication and to minimize
  manual tasks.
• Hence you may generate much more than code
• user guides
• help text
• test data
• build script
• content, etc.
• Find the right balance between the effort
  required for automating manual tasks and the
  effort of repetitively performing manual tasks
• Make use of SELECT FROM BUY, BUILD, OR OPEN
  SOURCE in your assessment.

13
Separate Generated and Non-Generated Code

• Keep generated and non-generated code in separate
  files.
• Never modify generated code.
• Design an architecture that clearly defines which
  artifacts are generated, and which are not.
• Use suitable design approaches to join
  generated and non-generated code. Interfaces as
  well as design patterns such as factory,
  strategy, bridge, or template method are good
  starting points.

14
Separate Generated and Non-Generated Code II

• A) Generated code can call non-generated code
  contained in libraries
• B) A non-generated framework can call generated
  parts.
• C) Factories can be used to plug-in the
  generated building blocks
• D) Generated classes can also subclass
  non-generated classes.
• E) The base class can also contain abstract
  methods that it calls, they are implemented by
  the generated subclasses(template method
  pattern)

15
Produce Nice-Looking Code whenever possible!

• PRODUCE NICE-LOOKING CODE WHEREVER POSSIBLE!
• When designing your code generation templates,
  also keep the developer in mind who has to at
  least to some extent work with the generated
  code, for example
• When verifying the generator
• Or debugging the generated code
• Using this pattern helps to gain acceptance for
  code generation in general.
• Examples
• Comments
• Use pretty printers/code formatters
• Location string (generated from modelxyz)

16
C O N T E N T S

• Domain Architecture
• Domain Metamodelling
• Code Generation
• Tools
• Features And Structure
• An Example
• Process
• Multi Model
• Architecture and CBD
• Adopting MDSD

Model-DrivenSoftware Development
www.mdsd-buch.de
Best Practices
17
Tools Overview

• Many kinds of tools can be used in the context of
  model driven development
• UML modelling tools
• Metamodelling environments
• (XMI) Repositories
• Code Generators
• Model verifiers
• There is also a large amount of tools that are
  MDA certified. These range from completely
  integrated environments such as ArcStyler to
  simple code generators or technology specific
  generators (e.g. for J2EE).

18
Tools Vendor Lock-in

• Because a lot of issues are not yet standardized,
  it is hard to integrate tools. Open issues
  include
• Some XMI aspects
• Specification of model transformation rules
• Code generation
• ...
• As a consequence, integrated MDD/MDA tooling is
  currently impossible to achieve without vendor
  lock-in.
• Alternatively, building/integrating your own
  tooling based on open source can be done, but
  requires compromises.
• Many tools are exemplified in the context of code
  generation (see other presentation). Build Tools
  are also important. UML tools (such as Rational
  XDE) also develop in the direction of supporting
  MDA.

19
Tools The Ideal One

• MOF Based Metamodelling, including OCL
• Usage of thses metamodels for subsequent modeling
  of M1
• Metamodel specific repositoriy
• GUI adapted to metamodel
• Model Validation based on metamodel
• Also including OCL
• Transformation rules based on user-defined
  metamodels
• Flexible Code Generation
• Test support

20
Implement the Metamodel

• Implement the meta model in some tool that can
  read a model and check it against the meta model.
  
• This check needs to include everything including
  declared constraints.
• Make sure the model is only transformed if the
  model has been validated against the meta model.
• The meta model implementation is typically part
  of the transformation engine or code generator
  since a valid model is a precondition for
  successful transformation.

21
Ignore Concrete Syntax

• Define transformations based on the source and
  target meta models.
• The transformer uses a three phase approach
• first parse the input model into some in-memory
  representation of the meta model (typically an
  object structure),
• then transforms the input model to the output
  model (still as an object structure)
• and finally unparse the target model to a
  concrete syntax

22
Transformations as first class citizens

• Transformations (and Templates) are central
  assets in MDSD. You should treat them
  accordingly.
• Transformations should be versioned.
• Refactor transformations to keep them current and
  well organized.
• Modularize transformations, e.g. using
  object-oriented concepts such as encapsulation,
  polymorphism, inheritance, etc.

23
Modular, Automated Transforms

• In order to more easily reuse parts of a
  transformation, it is a good idea to modularize a
  transform.
• 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 data among the transformations.
• Example Multi-Step transformation from a
  banking-specific DSL to Java via J2EE

24
External Model Markings (AO-Modelling)

• In order 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 only 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.

25
C O N T E N T S

• Domain Architecture
• Domain Metamodelling
• Code Generation
• Tools
• Features And Structure
• An Example
• Process
• Multi Model
• Architecture and CBD
• Adopting MDSD

Model-DrivenSoftware Development
www.mdsd-buch.de
Best Practices
26
Example Tool openArchitectureWare Generator

• Open Source, quite active project http//www.open
  architectureware.org
• Core Features
• Can Read any model (XMI from various UML tools,
  UML, textual, JDBC, Java classes )
• Can generate any kind of output
• Explicit Domain-Metamodel (implemented in Java)
• Semi-Declarative Metamodel Constraints,
  Functional Programming
• Simple, efficient template language
• Template Polymorphism and Template overwriting
• Multi-Model (Merging-Support)

27
Example Tool openArchitectureWare Generator

• Core Features contd
• Inter-Model References among various model
  syntaxes (i.e. UML to XML)
• Support for Aspects in the metamodel and in the
  templates
• Arbitrary Namespace Models can be supported
• Plugin-Based Generator configuration (ant-based)
• Additional Features
• Syntax-Highlighting Template Editor for Eclipse
• Metamodel can be generated from UML model, incl.
  DTD, HTML Docs, etc.
• Graphical GEF-Based Editors can be generated
• Dialog-Based Editors can be generated
• Framework for building IDEs based on this
  Generator
• Future Features
• EMF Integration, Visio Integration

28
Example Tool openArchitectureWare Generator

• How it works

29
Example Tool openArchitectureWare Generator

• Usage Examples
• Web Development (J2EE, Servlets, Struts)
• Banking, Insurances
• Mobile Phone Software (C QT, J2ME Java)
• Embedded Software (C, CANbus, Osek)
• Automotive Component Middleware
• (Interactive) Web sites
• Architectural Management, Entertainment)
• Multi-Platform Middleware (XML, C, Java, )
• Radioastronomy

30
C O N T E N T S

• Domain Architecture
• Domain Metamodelling
• Code Generation
• Tools
• Features And Structure
• An Example
• Process
• Multi Model
• Architecture and CBD
• Adopting MDSD

Model-DrivenSoftware Development
www.mdsd-buch.de
Best Practices
31
Teaming issues

• Using DSLs is not very different from normal
  programming every developer can basically do
  it.
• Defining DSLs is, however, something completely
  different
• Finding the right abstractions, defining
  metamodels, keeping the various metalevels
  sorted, etc. is not everybodys business.
• Some of the tools to define metamodels, DSLs,
  generators and model-2-model transformations are
  not (yet) intuitively usable.
• Therefore I recommend to keep DSL/generator
  development to a limited group of people in your
  project.

32
Iterative Dual Track Development

• Develop Domain Architecture and at least one
  application at the same time.
• Establish rapid feedback from application
  developers to domain architecture developers.
• Develop both aspects iteratively and
  incrementally. Use strict timeboxing.
• Infrastructure develops iteration n1 whereas
  application developers use iteration n.
• Introduce new Domain Architecture releases only
  at the beginning of iterations.

33
Extract the Infrastructure

• Before starting ITERATIVE DUAL-TRACK DEVELOPMENT,
  Extract the transformations from manually
  developed application.
• Either, start by developing this prototype
  conventionally, then build up the MDSD
  infrastructure based on this running application,
  
• Or extract the code from applications developed
  in the respective domain before doing MDSD (but
  only if the quality is sufficiently good!)

34
C O N T E N T S

• Domain Architecture
• Domain Metamodelling
• Code Generation
• Tools
• Features And Structure
• An Example
• Process
• Multi Model
• Architecture and CBD
• Adopting MDSD

Model-DrivenSoftware Development
www.mdsd-buch.de
Best Practices
35
One DSL is not enough

• Most systems can be structured into various
• partitions functional subsystems
• subdomains technical aspects
• It is hardly possible to describe each of these
  with the same DSL.
• You will need to come up withseparate DSLs
• that have to be connectablein order to build
  the complete system

36
One DSL is not enough II - Example
37
C O N T E N T S

• Domain Architecture
• Domain Metamodelling
• Code Generation
• Tools
• Features And Structure
• An Example
• Process
• Multi Model
• Architecture and CBD
• Adopting MDSD

Model-DrivenSoftware Development
www.mdsd-buch.de
Best Practices
38
Rich Domain-Specific Platform

• Define a rich domain-specific application
  platform consisting of
• Libraries
• Frameworks
• base classes
• interpreters, etc.
• The transformations will generate code for
  this domain-specific application platform.
• As a consequence, the trans-formations become
  simpler.
• DSLs and Frameworks are two sides of the same
  coin

39
Software Architecture Process on a slide
and actually, this is
a talk of its own

• Todays Problems
• Too much technology
• Too many hypes and buzzwords
• Too many standards too early
• So People dont focus on architectural concepts
• PHASE 1 Elaborate!
• Technology-Independent Architecture
• Programming Model
• Technology Mapping
• Mock Platform
• Vertical Prototype
• PHASE 2 Automate!
• Architecture Metamodel
• Glue Code Generation
• DSL-based Programming Model
• Model-based Architecture Validation

40
MDSD and CBD the three viewpoints

• Type Model Components, Interfaces, Data Types
• Composition Model Instances, Wirings
• System Model Nodes, Channels, Deployments

41
Component Implementation

• Componentimplementation should be based on
  notationsspecific to the kind of component
• Various other implementationstragies can be
  used, such as
• Rule-Engines
• Procedural DSLs or action semantics
• Note that, here, interpreters can often be used
  sensibly instead of generating code!

42
Aspect Models

• Often, the described three viewpoints are not
  enough, additional aspects need to be described.
• These go into separate aspect models, each
  describinga well-defined aspect of the system.
• Each of them uses a suitable DSL/syntax
• The generator acts as a weaver
• Typical Examples are
• Persistence
• Security
• Forms, Layout, Pageflow
• Timing, QoS in General
• Packaging and Deployment
• Diagnostics and Monitoring

43
C O N T E N T S

• Domain Architecture
• Domain Metamodelling
• Code Generation
• Tools
• Features And Structure
• An Example
• Process
• Multi Model
• Architecture and CBD
• Adopting MDSD

Model-DrivenSoftware Development
www.mdsd-buch.de
Best Practices
44
Adopting MDSD prerequisites

• Well-practices MDSD builds on several mature
  other practices, among them
• Well-defined software architecture
• Iterative software development and requirements
  management
• Mature project automation (regression testing,
  automatic builds, etc.)

45
Adopting MDSD process
46
Levels of MDSD

• You would typically start with architecture-centri
  c MDSD where the abstractions of the DSL
  correspond to the core concepts of the technical
  platform.
• This automates many aspects of the technical
  aspects
• Results in a wide platform/infrastructure
• Many projects can be handled with the
  infrastructure
• In later phases, functional MDSD infrastructures
  will be built on this technical one, resulting in
  cascaded MDSD.

47
Levels of MDSD
48
Levels of MDSD III M2M Transformations
49
Levels of MDSD III M2M Transformations II
50
Levels of MDSD III M2M Transformations III
51
PATTERN DSL-based Programming Model
52
C O N T E N T S

• Domain Architecture
• Domain Metamodelling
• Code Generation
• Tools
• Features And Structure
• An Example
• Process
• Testing
• Multi Model
• Adopting MDSD

Questions?
The End.
53
Some advertisement ?

• For those, who happen to speak(or rather, read)
  german Völter, Stahl Modellgetriebene
  SoftwareentwicklungTechnik, Engineering,
  ManagementdPunkt, 2005www.mdsd-buch.de
• For all othersA updated translation isunder
  wayModel-Driven Software Development, Wiley,
  Q2 2006www.mdsd-book.org