1. Adoption 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

2. Adoption 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)

3. Adoption 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

4. Adoption 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

5. Adoption 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

6. Adoption 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

7. Adoption 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...

8. Adoption How to make DSM technology easy or cheap to maintain with standard developers? Better tools Training, teaching in universities Scalability

9. Adoption 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

10. Adoption 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

11. Adoption 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

12. Adoption 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?

13. Adoption 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, …)