1 / 13

Participants in the adoption group

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

ham
Download Presentation

Participants in the adoption group

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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. 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. 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. 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. 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. 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. 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. How to make DSM technology easy or cheap to maintain with standard developers? • Better tools • Training, teaching in universities • Scalability

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

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

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

More Related