Participants in the adoption group

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 customers 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
UML profiles

• 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

11
DSMs

• 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

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?
• Dont 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
Respective advantages of text visual DSL

• 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, )