Interactive DSML Design
-
Upload
andriy-levytskyy -
Category
Design
-
view
269 -
download
0
Transcript of Interactive DSML Design
Interactive DSML Design Andriy Levytskyy | MDD Consultant Luminis Software Development B.V. Practical Product Lines 2010 November 17 & 18 Venlo
Introduction
• Goal: • Disclaimer:
• No 100% subject coverage, just what works well • Limited to Visual DSMLs • TransformaBon is briefly touched on
DSL Design: approach, pracBcal techniques and guidelines
2
Language Design
Basics of Domain Analysis
Tutorial Overview
2
3
1
Hands-on case
Exercise: domain selection, analysis
Exercise: abstract metamodel 4
Language Implementation 5
Exercise: executable metamodel, code generator 6
Round-up 5
3
Introducing each other
Name:
Company:
Function:
Domain:
Specialization:
Experience with MDD:
Expectations:
4
Analysis Paradigm
Entity (E) – concepts Relationship (R) – connection among Es Generalization – for sake of the DRY principle
Business rules – text notes in KISS style
Entity
R name
name description
R Generalization
n n
n n
6
Analysis Techniques: Dictionary
Automobile Motor
Sedan
Wheel
Driver
Door
Steering wheel
Rule of Thumb:
• Nouns are Es
• Verbs are Rs
7
Analysis Techniques: Generalization
Full notation Short-hand
Automobile Motor has
Sedan
is a
Automobile Motor has
Automobile
Sedan
• Focus on what matters. • Move repeatable information away w/o loosing track of it.
8
Analysis Techniques: Multiple Classification (1/2)
Vehicle
People
cont
ent
Automobile
Cargo
Craft
Land
trave
l
Consider a car that is either personal or cargo, travels over water or on land..
Generalizations within a set can’t
be combined.
Generalization set or discriminator
9
Analysis Techniques: Multiple Classification (2/2)
Vehicle
People
cont
ent
Automobile
Cargo
No need to create concepts for all possible combinations.
Better expressiveness. Better display of information.
Rules can be expressed via structure instead of text.
Passenger seat
has
n
Domain rule:
Only personal vehicle have passenger seats
10
Analysis Techniques: Roles (1/4)
Role is 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
Dynamic: 1 Object, * Things, * Times
W/O Roles With Roles
Employee
Student Retiree
Husband Son Father
Person
Student Retiree
Employee
Man
Son Father
Husband Man
Person times
su
rrou
ndin
gs
12
Reduction Example (3/4)
W/O Roles With Roles
Car
Rear wheel
Front wheel
2 2
has has Car
Wheel 2 2
has has
rear front
13
Expressiveness Example (4/4)
W/O Roles With Roles
Car
Wheel 2 2
has has
rear front
Car
Wheel
4 has
14
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
Added value
Domain Model
Domain Expert
Trainee Developer
Software Architect Meta-developer
Finally an overview!
Great intro
I clearly see variability
Great DSL concepts!!! The more uses, �
the more sustainable DSL..
The most stable model.
The less abstract model,
the less uses it has, and
the less stable it is.
16
What is a Metamodel?
A language definition comprised of:
§ concepts and their interrelations (abstract syntax)
§ form (concrete syntax): Ø Textual Ø Graphical Ø Combination
§ meaning (semantics): Ø Often realized via transformation
Car
Wheel 2 2
rear front
1
*
*
19
Design Paradigm
Analysis Design
Entity
name attributes description
Syntax
Constraint
n
n Good languages:
• ER • Class Diagrams
Entity
name description
20
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
EXERCISE: DSL DESIGN
• Translate domain model to DSL design(s) • Choose additional semantic domain, e.g. HTML • How your concepts are related to the semantic domain?
22
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
DSL Specification In AToM3
Abstract syntax – ER paradigm
Rules/constraints – python language Concrete Syntax – simple vector editor
Semantics – GG based transformation system
AToM3Object Entity
AToM3Object Relationship
name description n n
n n
AToM3Object
cardinality attributes constraints appearance
26
EXERCISE: DSL IMPLEMENTATION
• Translate DSL design to AToM3 metamodel • Making a simple generator (e.g. for HTML) • Test-drive of the DSL
27
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
.. And Yet Different
• 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 practices are even more important with DSLs!
30
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
References
Eric Evans. Domain-Driven Design: Tacking Complexity In the Heart of Software. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2003.
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.
Steven Kelly and Risto Pohjonen. Worst Practices for Domain-Specific Modeling. IEEE Software, vol. 26, no. 4, pp. 22-29, July/Aug. 2009. doi:10.1109/MS.2009.109
Steven Kelly and Juha-Pekka Tolvanen, Domain-Specific Modeling, enabling full code generation, Wiley-Blackwell, 2008.
[1]
[2]
[3]
[4]
32
http://lsd.luminis.eu [email protected] http://nl.linkedin.com/in/andriylevytskyy http://lsd.luminis.eu/tag/mdd/ http://twitter.com/levytsky
33