Model Oriented Domain Analysis focuses on industrializing software specifications through model driven techniques. The workshop discusses challenges with existing modeling approaches and UML, the value of domain expertise, and observations about process-centric requirements analysis. Key themes are the need for deeper analysis of domains of knowledge, clear separation of application and platform concerns, and strategic use of open source technologies through modeling language best practices.

1. Model Oriented Domain Analysis
industrialized software specifications
The First International Workshop on Domain Engineering
9 June 2009 @ CAiSE
Amsterdam, The Netherlands

2. The challenges
• Those who have been disillusioned by UML
and those who are not yet disillusioned by UML
• Those who have discovered the power of model driven generation
in the last five years
★ focus on amount of code generated, not quality
★ low quality input specifications (models, config files, ...)
★ ignorance of best practices for modelling language design
★ some of the same people sold objects as a silver-bullet in the 90s ...
• Love affair of software professionals with complexity & technologies
• Underestimating the value of true domain expertise
2 Model Driven Software Product Line Engineering

3. The process-driven organization
B
12 A
13 L
14 L
15
B
1 6
L U
7 8
E F
10 A
11 S
13 T
14
H
2 A
5 6
L O
9 C
10 A
11 R
15 19
I O
20 N
21
1
T 3
E 4
V 16
A 17
C 18
T
workflow steps = the ritual that works, more or less ...
3 The problem

4. Weaknesses of workflow-centric requirements analysis
• Which areas of knowledge are required to run a specific business?
• Can all knowledge be documented in the form of a process?
• Is the role of software limited to supporting/enforcing a process?
• Where are the use cases that elaborate configurability?
• Is there a clear distinction between using and producing applications?
• Are humans really working by following sequential processes?
• What is a suitable notation for describing work products (artefacts)?
4 Observations

5. Process outputs
B A L L
B L U E F A S T
H A L O C A R I O N
T E V A C T
artefact components
5 Where is the bigger picture?

6. Local semantics of process output
B A L L
B L U E F A S T
H A L O C A R I O N
T E V A C T
artefacts at different levels
6 Modularity and granularity of artefacts matters a lot

7. Global semantics of process output
B A L L
B L U E F A S T
H A L O C A R I O N
T E V A C T
semantics across levels
=> understanding the purpose of the business
7 The bigger picture requires deeper analysis

8. work products / artefacts
A1 A2
A3
B1
B2 B3
A areas of knowledge
B
8 Manifestation of knowledge

9. Solving the minor issues is easy
• If the overlap between two disciplines is large, the common denominator
can be treated as a distinct discipline
• As a result, some artefacts belong to this new discipline
• Disciplines are best described by associating them with corresponding
role names
A1
A C C1=A2
B3
B
areas of knowledge
9 Minor issues

10. Solving the real problems
• Overlapping artefacts need to be replaced with non-overlapping artefacts
• Disentangling the overlap comes down to investigating decision making
processes that occur when applying knowledge:
★ Who makes a decision?
★ When is the decision made?
★ Where (in which artefact) is the decision made?
★ What are the possible choices?
★ What heuristics apply?
★ How often does a decision require revision?
10 The heart of domain analysis

11. Think of artefact definitions as language definitions
• The quality of the terminology is of paramount importance
★ familiarity, precision, low risk of misinterpretation
• For production use, the tool used to create/maintain artefact instances
needs to have “product” quality - usability is king
• The language should be quite stable over time, but each sentence is
different
• If sentences contain obvious patterns in content (not grammar), then the
level of abstraction can be raised further (and the sentences become
shorter and simpler)
• The objective is clear and unambiguous communication between
domains!
11 Raising the importance of domain knowledge

12. Language design cheat sheet
12 Breaking down complexity into manageable modules

13. Examples of real-world use case steps
• Instantiation links are not always as simple as OO theory suggests ...
under-specified
instance of the VWGolf
product line
nearly fully-specified instance
only here the instance is
fully-specified
13 Partial, incremental instantiation is common in product lines

14. Use cases vs. meta modelling?
• If deep domain expertise is available:
★ Start with the definition of meta models
★ Validate meta models with a sufficient number of sample models
★ Validate the domain terminology by using it to
write use cases for modelling language users
★ Validate modelling languages and sample models by using them to
generate a working implementation
• If deep domain expertise is lacking:
★ Start with writing use cases to identify candidate domain terminology
★ Validate use cases by manually developing a first implementation
★ Use a second and third implementation to incrementally identify patterns, and
use MODA to distill first meta models
14 How to start depends on the domain

15. Modelling languages differ from coding languages
Observation: Given that in the context of software the term coding is often used
interchangeably with programming, it is instructive to compare the dictionary definitions of
to code and to model to understand the not-so-subtle difference in intent:
• to code: express (a statement or communication) in an indirect or euphemistic way
• to model: devise a representation, especially a mathematical one of (a
phenomenon or system)
Coding can be viewed as having to deal with someone else’s representation
(program notation or otherwise). This is exactly what happens when we work with third
party implementation technologies and when mapping to such technologies in a template
language.
Modelling can be viewed as dealing with a representation that is fit for purpose. This
is what happens when we capture knowlegde in a domain specific language that is
grounded in established domain terminology.
15 Terminology matters much more than technology

16. Separation of concerns
1 1 1 *
Domain Language Artefact
Problem language artefacts
Space 1
1 * 1 language element 1 element value
sub domains
* 1
* reference code segments
Reference code segment 1 Pattern Control * * Template
Glue Implementation 1 implementation Logic Statement Variable
pattern
* usage pattern instance 1 logical sequence
1 implementation technology
* target language text part
Solution Framework or
Space Syntactic Sugar
Component
Code Template
16 Language Engineering

17. Today’s platforms are defined relative to the user
Application Web Service Operating System Hardware
Platform Abstraction Abstraction Abstraction
Commoditized
Technologies
Value Added
Applications
Era 2010 1990 1970
Application Web Enterprise Embedded
Development Apps Apps Apps
1,000s < 10 < 50
Paradigm shift: of relevant relevant relevant
One person’s application frameworks operating systems processor families
is the next person’s platform!
17 Increasingly higher levels of abstraction

18. 1. Achieving and preserving modularity in-the-large
Web Service Operating System Hardware
Abstraction Abstraction Abstraction
In popular implementation
languages (Java, C#)
modularity constructs are
second class citiziens ...
Modularity
18 Qualities that are only scalable when using models

19. 2. Clear separation of application & platform
Web Service Operating System Hardware
Abstraction Abstraction Abstraction
Frameworks break the clean
separation of the problem
space from the solution space
Separation of
Apps & Platform
19 Qualities that are only scalable when using models

20. 3. Systematic exploitation of commoditized technologies
Web Service Operating System Hardware
Abstraction Abstraction Abstraction
Configuring open source
frameworks mostly requires a
certain level of knowlegde
about the solution space
Strategic use of
Open Source
20 Qualities that are only scalable when using models

21. Best Practices for Modelling Language Design (1)
1. A domain is partitioned into well-defined areas of knowledge, each of
which relates to exactly one role
2. All artefacts (work products) are based on information produced by a
specific role as a result of capturing a specific kind of knowledge or
requirements
3. A modelling language is developed for each kind of instantiable artefact
(leading to modular meta models)
4. The meta model of a modelling language has exactly one root node that
relates to the modeled artefact
5. Variants of artefacts are expressed as extensions of a common root
6. Artefacts are the only granularity at which versioning is applied
21 From conventions to tool features

22. Best Practices for Modelling Language Design (2)
7. Artefacts can only be edited by one user at a time
8. An explicit modularization mechanism is required within a modelling
language (leading to modular models)
9. No limit on the number of meta levels (instantiation levels), meta models
are models that define the instantiation semantics (including structure
and constraints) for a group of models
10. Two meta models may be joined via references between concepts in
both meta models
11. No circular or bi-directional dependencies between meta models
12. The set of models associated with a meta model is recorded as part of
the meta model artefact or via a reference to the meta model within each
model artefact
22 From conventions to tool features

23. One little language for each kind of artefact
1. In this example the modelling languages are much more domain specific
than a general purpose feature modelling language
2. Sometimes a general purpose feature modelling language is a good fit - but
even then it is not necessarily the “leading dimension” for modularizing the
domain
23 Example of a domain supply chain: Hardware device networks

24. Best Practices for Modelling Language Design (1)
1. A Meta Model is partitioned into well-defined .ecore files, each of which relates to
exactly one producer role, and one or more consumer roles. A Model is partitioned into
well-defined .xmi files, each of which relates to exactly one producer role, and one or
more consumer roles.
2. All .ecore and .xmi files are based on information produced by a specific role
as a result of articulating or clarifying specific knowledge or requirements.
3. A modelling language is developed for each kind of model based Artefact.
Adhering to
this principle in
Ecore relies
4. The .ecore file that defines the Abstract Syntax of a modeling language
entirely on (the meta model) has exactly one instantiable Root Class, a Class that
following relates to the modeled Artefact.
conventions.
5. Variants of a Root Class are expressed as Specializations of a shared Generalization.
6. .ecore and .xmi files are the only granularity at which versioning is applied.
24 Assessment of EMF Ecore

25. Best Practices for Modelling Language Design (2)
Adhering to
these ...
7. .ecore and .xmi files can only be edited by one user at a time
but can be read by any number of users.
principles in 8. References between .ecore files in conjunction with References between .xmi files
Ecore relies provide the basis for modularization of modelling language designs and models
entirely on ... (leading to modular meta models & models).
9. Only .ecore files can be used in the role of a meta model. Limitation!
following ...
10. Two .ecore files may be joined via one or more References
that connect Classes in the two .ecore files.
conventions. 11. No circular or bi-directional References between .ecore files and between .xmi files
12. The instantiation links between .xmi files & their meta model .ecore file is part of the .xmi
files.
25 Assessment of EMF Ecore

26. Notation design elements and options
• Textual syntax
• Form based representation
• Tree based representation
• Boxes (shapes) and lines paradigm
• Nested boxes or element to child-diagram “drill-down”
• Two dimensional arrangements of domain-specific symbols
• Animated diagrams
• Combinations of the above
26 Best practices for concrete syntax design

27. Domain Analysis & Design
Validate
Validate languages Design languages Analyse decisions reference
application
Develop
Extract templates reference
implementation
Develop platform
Domain Implementation
27 Domain engineering process

28. 28 Domain engineering roles

29. Difference between a model editor & an ordinary application
• The user of a model editor is always aware that (s)he is manipulating a model
• The model conforms to a formal notation that the user is familiar with
• The model has well-defined semantics which are provided via a generator, an
interpreter, or other component that relies on the meta model corresponding to the
formal notation to navigate the model
• When using and/or implementing an “ordinary” application
★ the user relies on a fuzzy mental model of what the application does, he is not
dealing with a familiar/intuitive formal notation
★ the application developer relies on a fuzzy mental model of the concepts that
constitute the terminology of the user
★ hence the implementation can’t contain any formal mapping between problem
space and solution space
29 Conclusions

30. Any difference between user and software developer?
• The user of a modelling language is a domain expert,
he/she needs “power user” functionality
• Power user functionality is delivered via appropriate model editors
• Models are automatically translated into corresponding software
• Domain experts create/define software behaviour
• That’s what’s usually called software development!
• Domain experts and software developers are both using and producing
“model driven software”.
30 Conclusions

31. Any difference between software development & configuration?
• Traditionally software configuration has been the poor cousin of software development
• Often, software product configurability is extended in haste, at the last minute, when a
new customer is screaming for a new feature
• Over the years this results in configuration tables and files that rival the complexity of
legacy source code
• The quality of configuration files and traditional software source code almost inevitably
degrades over time
• Model oriented domain analysis treats software development and software
configuration on an equal footing right from the start
★ Usable model editors for all work products that are created by
software professionals and/or domain experts
★ The only difference between development & configuration is binding time,
and nothing more
31 Conclusions

32. Unlocking the full potential of model driven software
• Using model driven techniques to implement applications conceived via a
traditional requirements analysis process only requires a paradigm shift in
software engineering
★ software development productivity typically increases by a factor of 2 or
more
★ Quality rises as whole classes of defects can be eliminated
systematically
• Using model oriented domain analysis to uncover deep domain knowledge
and conceive model driven applications requires a paradigm shift in
business modeling and requirements engineering
★ Potential productivity and quality improvements by an order of
magnitude
32 Potential

33. Knowldege Industry Survial Strategy (KISS)
• www.industrialized-software.org/kiss-initiative
★ Reaching a strong consensus on fundamental values
and principles for designing and using DSLs
★ Progress towards interoperability between tools
• Upcoming conference events
★ 16 June, Code Generation 09, Cambridge, UK
★ 25 or 26 October, OOPSLA 09, Orlando, Florida
★ 16 or 17 November, Automated Software Engineering 09, Auckland, NZ
• For a powerful message on simplicity, visit www.spinellis.gr/blog/20090203
33 Keep it sweet and simple

34. Thank you!
Jorn Bettin
jbe @ sofismo.ch
Skype jorn_bettin
+41 62 891 0987