Download to read offline
![A Few Bad Practices
• Lack of domain understanding
• Too generic/too specific
• Letting the tool dictate language analysis design
• Failing to consider the language’s real-life usage
• Top/down and bottom/up confusion => inflexible MDD
• and more (see [3])…
31](https://image.slidesharecdn.com/interactivedsmldesigntutorialppl2010-131026052313-phpapp01/85/Interactive-DSML-Design-31-320.jpg)
![References
[1] Eric Evans. Domain-Driven Design: Tacking Complexity In the
Heart of Software. Addison-Wesley Longman Publishing Co., Inc.,
Boston, MA, USA, 2003.
[2] Martin Fowler and Kendall Scott. UML Distilled: A Brief Guide to
the Standard Object Modeling Language. Addison-Wesley
Longman Publishing Co., Inc., Boston, MA, USA, 3rd edition, 2003.
[3] Steven Kelly and Risto Pohjonen. Worst Practices for DomainSpecific Modeling. IEEE Software, vol. 26, no. 4, pp. 22-29, July/
Aug. 2009. doi:10.1109/MS.2009.109
[4] Steven Kelly and Juha-Pekka Tolvanen, Domain-Specific
Modeling, enabling full code generation, Wiley-Blackwell, 2008.
32](https://image.slidesharecdn.com/interactivedsmldesigntutorialppl2010-131026052313-phpapp01/85/Interactive-DSML-Design-32-320.jpg)
More Related Content
![[2015/2016] Introduction to software architecture](https://cdn.slidesharecdn.com/ss_thumbnails/05softwarearchitecture-151203124359-lva1-app6891-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to Interactive DSML Design
Interactive DSML Design
- 1. Interactive DSML Design AndriyLevytskyy | MDD Consultant Luminis Software Development B.V. Practical Product Lines 2010 November 17 & 18 Venlo
- 2. Introduction • Goal: DSL Design: approach, pracBcal techniques and guidelines • Disclaimer: • No 100% subject coverage, just what works well • Limited to Visual DSMLs • TransformaBon is briefly touched on 2
- 3. Tutorial Overview Hands-on case 1 Basics ofDomain Analysis 2 3 Exercise: domain selection, analysis Language Design 4 5 Exercise: abstract metamodel Language Implementation 6 5 Exercise: executable metamodel, code generator Round-up 3
- 4. Introducing each other Name: Company: Function: Domain: Specialization: Experiencewith MDD: Expectations: 4
- 5. • Paradigm • BasicTechniques • Guidelines • Added value BASICS OF DOMAIN ANALYSIS 5
- 6. Analysis Paradigm R Generalization Entity (E)– concepts Relationship (R) – connection among Es Entity Generalization – for sake of the DRY principle Business rules – text notes in KISS style name n description n R n n name 6
- 7. Analysis Techniques: Dictionary Driver Motor Rule ofThumb: • Nouns are Es • Verbs are Rs Steering wheel Automobile Wheel Sedan Door 7
- 8. Analysis Techniques: Generalization Full notation Short-hand Motor Motor has has Automobile Automobile Automobile isa Sedan Sedan • Focus on what matters. • Move repeatable information away w/o loosing track of it. 8
- 9. Analysis Techniques: Multiple Classification(1/2) Consider a car that is either personal or cargo, travels over water or on land.. Vehicle Cargo travel People content General i za or discrim tion set inator Craft Land Generalizations within a set can’t be combined. Automobile 9
- 10. Analysis Techniques: Multiple Classification(2/2) has People Cargo omain rule: D Only personal vehicle have passenger seats No need to create concepts for all possible combinations. content n Passenger seat Vehicle Better expressiveness. Better display of information. Rules can be expressed via structure instead of text. Automobile 10
- 11. Analysis Techniques: Roles (1/4) Roleis a particular aspect or usage of a concept that is utilized in a specific context. Context is the (changing) circumstances (i.e. other "surrounding" concepts) under which the concept is being used. Therefore such a concept can have several roles. • Reduction in the number of concepts. • Enhances expressive power for modeling. 11
- 12. Dynamic: 1 Object,* Things, * Times W/O Roles With Roles times Person Employee Student Retiree Student Person Retiree surroundings Employee Man Husband Son Father Husband Son Man Father 12
- 13. Reduction Example (3/4) W/ORoles has 2 Rear wheel Car With Roles has 2 Front wheel has has Car 2 rear Wheel 2 front 13
- 14. Expressiveness Example (4/4) W/ORoles Car With Roles has has Car has 4 Wheel 2 rear Wheel 2 front 14
- 15. Analysis Guidelines &Tips • When stuck ask domain expert for more information • Apply Law of preservation to extracted information • Define depth and scope of domain around needs of end users • Avoid working on domain model from the time/process perspective • Expose all information visually as entities <= facilitates discussion • Use multiple classification over role if: • Classifications are exclusive • Roles need to be more prominent. • Entities have no properties nor attributes (except for Name) • Resist tendency of putting info in business rules/comments • Use Wikipedia for generic vocabularies/classifications • Avoid large diagrams • Iterate analysis-modeling-review until the model: • Consistent, adequate, has no gaps, “feels” right 15
- 16. Added value Great intro Finallyan overview! Trainee Developer Domain Expert Domain Model Great DSL concepts!!! Meta-developer The more uses, " le DSL.. the more sustainab el. The most stable mod odel, The less abstract m and the less uses it has, the less stable it is. I clearly see variability Software Architect 16
- 17. • Choose adomain • Extract concepts • Organize concepts • Review EXERCISE: DOMAIN ANALYSIS 17
- 18. • What islanguage? • Paradigm • Guidelines LANGUAGE DESIGN 18
- 19. What is aMetamodel? 1 Car A language definition comprised of: § concepts and their interrelations (abstract syntax) § form (concrete syntax): 2 rear 2 Wheel front * Ø Textual Ø Graphical Ø Combination § meaning (semantics): * Ø Often realized via transformation 19
- 20. Design Paradigm Analysis Design n Entity Syntax name description Good languages: • ER • Class Diagrams Entity name attributes description Constraint n 20
- 21. Design Guidelines &Tips • Stay consistent with domain model • Focus on variability/configuration and “mass” production • Do not focus on aspects (leave it to transformations) • Use generalization • No multiple classifications => entities or properties • No roles => entities or properties • Add administrative attributes, such as id, version, title, etc.. • No constructors, no interface definitions, no XML, no Java, etc.. • Consider breaking the domain model into multiple DSLs based on: • high cohesion and low coupling of concepts • different change frequency of concepts instances 21
- 22. • Translate domainmodel to DSL design(s) • Choose additional semantic domain, e.g. HTML • How your concepts are related to the semantic domain? EXERCISE: DSL DESIGN 22
- 23. • Tool Selection • AToM3 Introduction LANGUAGE IMPLEMENTATION 23
- 24. Tool Selection Selection guidelines: • No meaningful guidelines exist • My advice: Choose tools that are as close to design paradigm as possible (raise level of abstraction) Skipped Candidates: ✘Eclipse based tools ✘Tools from industry heavyweights (IBM, Microsoft, Borland) ✘Popular DSL tools (Would not fit into the allocated time or will spend time clicking/typing in many dialogue windows) 24
- 25.
- 26. DSL Specification In AToM3 AToM3Object cardinality attributes constraints appearance Abstractsyntax – ER paradigm Rules/constraints – python language AToM3Object Entity name n description Concrete Syntax – simple vector editor Semantics – GG based transformation system n AToM3Object n n Relationship 26
- 27. • Translate DSLdesign to AToM3 metamodel • Making a simple generator (e.g. for HTML) • Test-drive of the DSL EXERCISE: DSL IMPLEMENTATION 27
- 28. • DSLs: Familiarand Different • A few bad practices • References • Any questions? ROUND-UP 28
- 29. DSLs are Familiar.. • DSL development is a software development process • DSL is a very special, but still a software system • Status quo: DSL development still done at PSM (i.e. coding/3GLs) • With all consequences • All best practices from SE apply here as well: • Good analysis • Modeling to raise abstraction • Modeling architectures (e.g. MDA’s CIM/PIM/PSM), etc.. 29
- 30. .. And YetDifferent • Clients do not know domain concepts <= agile • Metamodels are more domain-driven <= good domain analysis • No one wants a vendor lock <= CIM/PIM/PSM/ • DSLs are very specific systems <= automate DSL development Best SE pract ices are even mor e important wit h DSLs! 30
- 31. A Few BadPractices • Lack of domain understanding • Too generic/too specific • Letting the tool dictate language analysis design • Failing to consider the language’s real-life usage • Top/down and bottom/up confusion => inflexible MDD • and more (see [3])… 31
- 32. References [1] Eric Evans.Domain-Driven Design: Tacking Complexity In the Heart of Software. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2003. [2] Martin Fowler and Kendall Scott. UML Distilled: A Brief Guide to the Standard Object Modeling Language. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 3rd edition, 2003. [3] Steven Kelly and Risto Pohjonen. Worst Practices for DomainSpecific Modeling. IEEE Software, vol. 26, no. 4, pp. 22-29, July/ Aug. 2009. doi:10.1109/MS.2009.109 [4] Steven Kelly and Juha-Pekka Tolvanen, Domain-Specific Modeling, enabling full code generation, Wiley-Blackwell, 2008. 32
- 33.