Sioux Hot-or-Not: Model Driven Software Development (Markus Voelter)

- - Markus Völter [email_address] www.voelter.de Model-Driven Software Development Hot or Not? www.mdsd-buch.de www.mdsd-book.org

About me - - Markus Völter [email_address] www.voelter.de

About me - - Markus Völter [email_address] www.voelter.de I work as an independent consultant/coach/trainer…

… for software technology and engineering …

… I focus on software architecture, …

… middleware, …

… and model-driven software development.

I have written a number of books…

… regularly speak on conferences …

… and I am an eclipse.org comitter for

openArchitectureWare

I am also founder and editor of software engineering radio

More information is available at www.voelter.de…

and on my blog at voelter.de/blog

I am based in Heidenheim, Germany

And in my spare time I fly my glider…

C O N T E N T S

Part 1: Theory

Part 2: Practice

Part 3: Q&A

- -

Model-Driven Development

Model Driven 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 .

- -

How MDSD works

Developer develops model(s) based on certain metamodel(s), expressed using a DSL.

Using code generation templates , the model is transformed to executable code.

Alternative: Interpretation

Optionally, the generated code is merged with manually written code.

One or more model-to-model transformation steps may precede code generation.

- -

Reasons for DDD

Software Development is too complex and too expensive (now, this is a really new finding  ) … … because:

There is too little reuse

Technology changes faster than developers can learn

Knowledge and practices are hardly captured explicitly and made available for reuse

Domain experts cannot understand all the technology stuff involved in software development

DDD aims at attacking some of these problems. We shall see how on the following slides.

- -

What is a „Domain“

A definition could be: A domain is a bounded area of knowledge or interest.

Examples (from the world of Software) include:

eBanking

Embedded Software

Web-Based eBusiness Applications

Control Software for 4-Cylinder Diesel Engines

Astronomical Image Processing Software

Domains can have varios „ scopes “ as well as various „ flavours “ – see next slides.

- -

MDSD Core Concepts - - Model Domain Specific Language Metamodel textual graphical Domain Ontology bounded area of knowlege/interest semantics precise/ executable multiple partial viewpoint subdomains composable Metametamodel target software architecture software architecture transform compile interpret multi-step single-step no roundtrip knowledge several design expertise

Example 1: Model and Metamodel - - interface Sensor { operation start():void; operation stop():void; operation measure():float; } interface Controller { operation reportProblem(Sensor s, String errorDesc ):void; }

Example 2: Model (J2ME apps) - -

Example 2: Metamodel (J2ME apps) - -

Example 5: Power Grid - -

Example 5: Power Grid Metamodel - -

MDSD Core Values

We prefer to validate software-under-construction over validating software requirements

We work with domain-specific assets , which can be anything from models, components, frameworks, generators, to languages and techniques.

We strive to automate software construction from domain models; therefore we consciously distinguish between building software factories and building software applications

We support the emergence of supply chains for software development , which implies domain-specific specialization and enables mass customization

- -

MDA and Model Driven Software Development Overview

Focus: Platform Independence, (Tool) Interop

- - Model Domain Specific Language Metamodel textual graphical Domain Ontology bounded area of knowlege/interest semantics precise/ executable multiple partial viewpoint subdomains composable Metametamodel transform compile interpret multi - step single-step no roundtrip UML+ Profiles MOF OCL, Action Semantics PIM, PSM, .... QVT several target software architecture software architecture Application design expertise

Other related approaches

Microsoft’s Software Factories: Focus on Reuse, Efficient Development, DSLs

Domain-Specific (Visual) Modelling: Focus on (Visual) DSLs

Generative Programming: Focus on Efficiency, “Automatic Manufactoring”, Software System Families

Language-Oriented Programming: Focus on DSLs instead of Frameworks, incl. Editor/Debugger Support

- -  all basically the same 

MDSD and Agility

Agile Manifesto: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: - Individuals and interactions over processes and tools - Working software over comprehensive documentation - Customer collaboration over contract negotiation - Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.

MDSD-Models are no „paperwork “, they are the code which is translated to code automatically

Agility does not oppose tools in general – compilers are ok, model transformers are a kind of compiler

- -

MDSD and Agility II

Project automation (ant, cruisecontrol) is ok in „agile minds“, so is automation of the writing of repetitive code

Automation of the development process makes responding to change easier and faster (single source principle).

Changes in the model respond to changes in the functional requirements

Changes in the templates/transformations can be used to evolve the architecture

The customer on-site can be integrated better , if we have languages that are better related to domain concepts as opposed to 3GL code or the like.

Pair programming between developer and domain expert is more realistic.

- -

MDSD and Agility III

Tests can still be written manually (even before generation), generators can help is building mocks or scenarios

We do not recommend a waterfall that first builds generators and then builds apps, rather, both are iteratively evolved in parallel.

Domains Architectures are based on experience , not based on „big design upfront“

Developers can do what they can do best:

Some deal with applications and customer requirements,

Others deal with technical architecture, platforms and generators

So: There is no problem with Agility and MDSD!

- -

Reasons for using MDSD

You want to provide a way for your domain-experts to formally specify their knowledge , and to provide a way for your technology people to define how this is implemented (using model transformations).

You might want to provide different implementations (i.e. more concrete models) for the same model , perhaps because you want to run it on different platforms (.NET, Java, CORBA).

You may want to capture knowledge about the domain, the technology, and their mapping in a clear, uncluttered format.

In general, you don’t want to bother with implementation details when specifying your functionality.

MDSD results in a fan-out , i.e. one set of models can be the source for transformations to several targets.

Another reason for using MDSD: You are working in the context of product lines and software system families and need to develop domain-specific assets.

- -

MDSD Benefits I

Models are free of implementation artifacts – they directly represent domain knowledge and are thus reusable.

Implementations for various platforms can be generated in principle – the technology change problem is adressed to some extend.

Technology freaks and domain experts can take care of „their business“ (transformations and models, respectively) and need to care of each other‘s problems only in a limited way.

Domain experts can play a direct role in development since they can more easily understand models expressed with a DSL as opposed to implementation code.  Domain Experts play the central role they deserve!

- -

MDSD Benefits II

Development becomes more efficient since repetitive implementation code can be generated automatically.

Architectural contraints/rules/patterns can more easily be enforced , since the they are embedded in the templates rather than just being documented (and ignored). This is especially important in really large teams, often in the context of Product-Line Engineering and Software System Families.

Transformer/Generator can address cross-cutting concerns (just like an aspect weaver)

- -

MDSD Predjudices

MDSD does not require UML – any kind of modelling language is ok, graphical or textual

Precise and complete models…

… are not the the same as „visualized code“ – the abstraction level is higher

… are not the same as analysis models – analysis models are not computational

MDSD does not require – not even recommend – a waterfall. Development of the generative infrastructure is iterative and incremental.

You do not need big and expensive tools – a lot of small and useful open source tools are available.

You don‘t need to generate 100% of the code – it is ok, to also code some aspects in a 3GL.

- -

Benefits for Software Quality

MDSD requires an explicit, well-defined architecture. Defining an architecture this way improves the quality of the system (indpendent of whether it is generated or not).

Transformations capture expert knowledge. The generated code reflects this expert knowledge uniformly.

An Domain Archtitecture defines a strict programming model for the manually developed parts – again, uniformity and constrained-ness improves quality.

Generator does not produce accidental errors – either things are always right or always wrong. This makes finding errors easier!

Models can serve as an up-to-date and always current documentation .

- -

Benefits for Software Quality II

In general, MDSD forces you to take care of many good things, which you‘d like to have in any application development project:

Domain/Application Scoping

Variability Management

Well-Defined Software Architecture, Architecture Metamodelling

Trying to build a generator for a domain/target architecture enables your understanding of the domain/target architecture. This in itself is a huge benefit.

- -

No Free Lunch - Challenges

You need additional skills in your team (domain analysis , metamodelling, generator development, architecture)  You need a couple of good people who usually aren‘t easy to get, and who aren‘t cheap.

Your development process needs to reflect the two-track nature of MDSD (domain architecture development, application development)

Sometimes tools require some „creative use“ and improvisation (  use open source!)

Remember: a fool with a tool is still a fool

- - generator

MDSD (compared to “normal” Software Development) - -

MDSD Effort (stage 1) - -

MDSD Effort (stage 2) - -

UML Tools as DSL editors

If you want to use a UML tool as the editor for you DSL, the DSL must be mapped onto a UML profile , i.e. a set of

Stereotypes,

Tagged values, and

Constraints

Pros:

Easy to implement

(Looks like a) standard

More or less acceptable export format (XMI)

Model Management features (searching, paritioning…)

Integration into the tool suite (versioning, etc.), if provided by the UML tool and indeed necessary

- -

UML Tools as DSL editors II

Cons:

Graphical Features are very limited (especially, data-dependent graphics!)

Constraints cannot be checked in real time (this may change over time – tool vendors improve!)

You cannot „remove“ UML semantics completely (try to draw a line between two attributes…).

You always have to use the complete UML tool – complex UI

- -

Editor Alternatives: Developing a Custom Tool

Pros:

Typically, quite powerful graphics features

No inherited features forced upon you by the tool

Only valid concrete syntax is possible

Constraints can be checked in realtime

Tool can be as simple as possible – no UML mess

Cons:

Implementation Effort usually high

Often limited partitioning and model management support (depends ultimately on the effort you want to put in)

- -

Editor Alternatives: Developing a Custom Tool II

Models are instances of their metamodel.

The Editor edits models…

… and uses concepts from the metamodel

- -

Editor Alternatives: Custom Tool / Generating Editors

GEF (Eclipse Graphical Editing Framework) is powerful, but hard to use.

Especially, if the domain metamodel changes regularly in a project, adapting the editors correspondingly is annoying.

As a consequence, we generate the editors from the domain meta- model and additional editor descriptions.

- -

GMF Process - -

Custom Tool – the generated Network Editor - -

Characteristics of Textual DSLs

Different characteristics for different domains

Concrete Syntax: textual vs. graphical

Domain Selection: structural vs. behavioural

Expressive Power: declarative vs. imperative

Execution: interpretation vs. compilation/transformation

Integration: internal vs. external

Tool Support: editor, debugger, …

Why concrete syntax is important

Abstract Syntax defines grammar for the language – most important for tools

Concrete Syntax is the “UI” for the language – critical for DSL users

concise vs. redundant

intuitive

simple to write and read

Tool support matters

IDE integration

syntax highlighting

metamodel awareness

Different syntax for different abstractions / domains

Different concrete syntax is well established for different domains

class diagrams to describe types and structure

state charts

textual expression notation for behaviour

XML for structured data

The abstraction should drive syntax decision, not vice versa

Available tool support often decides the syntax

UML has its uses, but it is no panacea

building specific textual languages – and IDEs to work with them – has become feasible

Tradeoffs for textual DSLs

With both textual and graphical syntax you can

Model for any meta model

verify constraints in real time

(Eclipse) write ordinary EMF models

Graphical Editors are good to show structural relationships

Textual Editors are better for „algorithmic“ aspects, or hierarchical models

Textual Editors integrate better with CVS etc. (diff, merge)

Strengths of Textual DSLs

Textual languages have specific strengths compared to graphical languages

ideally there should be the option to have both

compact and expressive syntax

productivity for experienced users

IDE support softens learning curve

configuration management/versioning and integration into the “regular” development process

splitting a model into several files

concurrent work on a model, especially with a version control system: diff, merge

search, replace

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.

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)

We didn’t talk about...

Model-to-Model Transformations

Interpreters

Best Practices

AO & MDSD

CBD & MDSD

PLE & MDSD

Many many other tools... (ME+, DSL Tools, Intentional, ...)

... And many more

Please ask in Q&A

C O N T E N T S

Part 1: Theory

Part 2: Practice

Part 3: Q&A

- -

openArchitectureWare

Open Source

Version 4.2 is almost released

Proven track record in various domains & project contexts

e.g., telcos, internet, enterprise, embedded realtime, finance, …

www.openarchitectureware.org

IDE-portions based on Eclipse

(Optional) Integration with Eclipse Modelling facilities (such as EMF)

- -

openArchitectureWare / Eclipse EMF, GMF, EMP

C O N T E N T S

Part 1: Theory

Part 2: Practice

Part 3: Q&A

- -

Some advertisement  - -

For those, who speak (or rather, read) german: Völter, Stahl, Haase, Efftinge: Modellgetriebene Softwareentwicklung Technik, Engineering, Management 2. Auflage dPunkt, 2007 www.mdsd-buch.de