Adoptio

n

Participants in the adoption group

• Heiko Kern• Parastoo Mohagheghi• Manuel Wimmer• Juha Pärssinen• Juha-Pekka Tolvanen• Laurent Safa• Sven Braun• Gerardo de Geest• Janne

Adoptio

n

Economics of DSM

What data does management need to take a decision on using DSM?

• Decide to go for DSM– Saving side: reduce time to market, develop faster,

Control over evolution, – Invest: training, tool adaptation, cost of building the

language and generators, access to experienced personnel.

• Decide how to DSM– Do it by yourself versus buying （ time to market)

Adoptio

n

Where DSM is beneficial?

• Reuse, similar applications/ similar features within one application, product line

• Learning more about the domain, sharing the Knowledge

• Repetitive tasks• Lack of experienced developers (DSMs hide

complexity)• Simulation, faster prototyping, short way from

specification to implementation

Adoptio

n

How to convince customers?

Find information in the customer’s domain:• Previous studies: industry experiences • Concept demonstration in their environment (also versus

other approaches)• Analyst reports, third party opinion• Good academic reports, more academic research• available good tools, consulting and support services • No vendor locking in meta tools like in the past• Reduced risk since code still exists if models are not

useful

Adoptio

n

DSL design process

• Start in small, iteratively if the tool allows

• Roles: Domain expert, language designer to start with

• Activities: start from the reference application or domain model, do not look at the solution domain (code) but the problem domain when devising the notation

Adoptio

n

Language, model or metamodel evaluation criteria

• Expressive enough• Guarantee consistent models

– Reduce modelling effort

• Generating what you expect– What can be specified in term of visual

models works bug-free

• Domain appropriateness– Full code generation is possible

• Tools

Adoptio

n

Language, model or metamodel evaluation method

• Monitoring people, analysing

• Metrics: Which part of models are used or are related

• Interviewing

• Redo recent product with DSM tool and compare man.month, time-to-market...

Adoptio

n

How to make DSM technology easy or cheap to maintain with standard

developers?• Better tools

• Training, teaching in universities

• Scalability

Adoptio

n

Textual vs. graphical vs. other kinds (table-based etc.)

• Based on the closeness to the problem domain

• Use text if…– Granularity of problem (fine granularity e.g.

sorting algorithm)

• Use graphical if…– Have visual hints (memento, memory, …)– Want to show relationships btw entities

Adoptio

n

UML profiles

• Pros:– Easy to start with existing

tools– People think they know

UML– They have already a

“standard” UML model to annotate

• Cons:– Profiles are limited in

extending– Defining good UML profiles

take more time– Profiles are only additive,

you cannot hide something– Tools do not know how to

deal with a stereotyped element

– Moving to another tool is difficult

– Imprecise UML semantics

Adoptio

n

DSMs

• Pros:– More flexibility– More control– No dependency on the

language defined by the vendor

– No OMG/standardization dependency

– Close to the domain

• Cons:– New tools are needed– New capabilities are

needed– Learning curve for

defining them, not for using (or at least what people think)

– Necessity to maintain home-grown technology

Adoptio

n

Is there more than visually graph-based notation to augment expressiveness of VDSL?

– What are limitations to graph notation?• Crowded big mess• Difficult to edit when big• Hiding/showing information relevant to people

– MS DSL Tools already provide containment, combo box, others such as table-based or matrix-based

– How to improve?• Don’t make BIG graphs Hint to DSL scope ?

– Hint: The DSL should be defined such that most models are small

• Graph + force– See Tutorial of MDSD Best Practices – ~ Intentional Programming?

Adoptio

n

Respective advantages of text & visual DSL

Text• Search/replace• Diff / Merge / Versioning• Faster to refactor?• Composition of heterogeneous

source files• Reading direction

– Top/down & left/right

Visual• Quick overview

– Map view– Links and paths

• Less error prone• Smaller learning curve• Representation of

physical/tangible artifacts• Better possibility to have

different views or levels • Want to show relationships btw

entities• Have visual hints (memento,

memory, …)