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

BASICS OF DOMAIN ANALYSIS

•  Paradigm •  Basic Techniques •  Guidelines •  Added value

5

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)


Car

Rear wheel

Front wheel

2 2

has has Car

Wheel 2 2

has has

rear front

13

Expressiveness Example (4/4)


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

EXERCISE: DOMAIN ANALYSIS

•  Choose a domain •  Extract concepts •  Organize concepts •  Review

17

LANGUAGE DESIGN

•  What is language? •  Paradigm •  Guidelines

18

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

LANGUAGE IMPLEMENTATION

•  Tool Selection •  AToM3 Introduction

23

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

AToM3

25

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

ROUND-UP

•  DSLs: Familiar and Different •  A few bad practices •  References •  Any questions?

28

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