1. Model-Driven Software Development
Some Essential Best Practices
Markus Völter

2. Markus Völter About me Independent Consultant
Independent Consultant
Based out of Heidenheim, Germany
Focus on
Software Architecture
Model-Driven Software Development
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
design expertise
architecture
architecture
bounded area of
partial
composable
knowlege/interest
knowledge
multiple
multi-step
transform
viewpoint
Domain
single-step
compile
Model
semantics
Ontology
interpret no
precise/
roundtrip
Domain
executable
Specific
Language
graphical
Metamodel
textual

5. Before we start … III: MDSD and MDA
MOF
several
target
Metametamodel
software
software
subdomains
architecture
architecture
design expertise
bounded area of
partial
composable
knowlege/interest
PIM, PSM, ....
QVT
multiple
multi-step
transform
viewpoint
Domain
single-step
compile
Model
semantics
Ontology
interpret no
precise/
Domain
roundtrip
executable
Specific
OCL, Action Semantics
Language
UML+ Profiles
graphical
Metamodel
textual
Focus: Platform Independence, (Tool) Interop

6. Best Practices Domain Architecture Tools Process Multi Model
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-Driven Software Development
Best Practices

7. Best Practices Domain Architecture Tools Process Multi Model
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-Driven Software Development
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 sentence’s statement is just wrong
you have to update the meta model.

10. A component owns any number of ports.
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. Best Practices Domain Architecture Tools Process Multi Model
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-Driven Software Development
Best Practices

12. Hence you may generate much more than code:
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 model::xyz“)

16. Best Practices Domain Architecture Tools Process Multi Model
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-Driven Software Development
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. MOF Based Metamodelling, including OCL
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. Best Practices Domain Architecture Tools Process Multi Model
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-Driven Software Development
Best Practices

26. Example Tool: openArchitectureWare Generator
Open Source, quite active project
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 cont‘d:
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. Best Practices Domain Architecture Tools Process Multi Model
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-Driven Software Development
Best Practices

31. Defining DSLs is, however, something completely different:
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 everybody‘s 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 n+1 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. Best Practices Domain Architecture Tools Process Multi Model
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-Driven Software Development
Best Practices

35. Most systems can be structured into various
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 with separate DSLs
… that have to be „connectable“ in order to build the complete system

36. One DSL is not enough II - Example

37. Best Practices Domain Architecture Tools Process Multi Model
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-Driven Software Development
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…
Today‘s Problems:
Too much technology
Too many hypes and buzzwords
Too many standards too early
So: People don‘t 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
Component implementation should be based on notations specific to the “kind of component”
Various other implementation stragies 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 describing a 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. Best Practices Domain Architecture Tools Process Multi Model
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-Driven Software Development
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. This automates many aspects of the technical aspects;
Levels of MDSD
You would typically start with architecture-centric 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. Questions? Domain Architecture Tools Process Testing Multi Model
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 Softwareentwicklung Technik, Engineering, Management dPunkt,
For all others: A updated translation is under way: Model-Driven Software Development, Wiley, Q