130 likes | 216 Views
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. Economics of DSM. What data does management need to take a decision on using DSM? Decide to go for DSM
E N D
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
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)
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
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
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
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
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...
How to make DSM technology easy or cheap to maintain with standard developers? • Better tools • Training, teaching in universities • Scalability
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
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 UML profiles
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 DSMs
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?
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, …) Respective advantages of text & visual DSL