Model Oriented Domain Analysisindustrialized software specifications

The First International Workshop on Domain Engineering9 June 2009 @ CAiSE

Amsterdam, The Netherlands

Model Driven Software Product Line Engineering

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

The problem

The process-driven organization

3

T

H

E

A

V

L

U E

O

SF A

B

T

R

A C T

I O N

B L

AC

A L L

1 3 4 16 17 18

workflow steps = the ritual that works, more or less ...

2 5 6

1 6 7

9

8 10

10 11 15

11

12

13 14

13 14 15

19 20 21

Observations

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

Where is the bigger picture?

Process outputs

5

T

H

E

A

V

L

U E

O

SF A

B

T

R

A C T

I O N

B L

AC

A L L

artefact components

Modularity and granularity of artefacts matters a lot

Local semantics of process output

6

T

H

E

A

V

L

U E

O

SF A

B

T

R

A C T

I O N

B L

AC

A L L

artefacts at different levels

The bigger picture requires deeper analysis

Global semantics of process output

7

T

H

E

A

V

L

U E

O

SF A

B

T

R

A C T

I O N

B L

AC

A L L

semantics across levels=> understanding the purpose of the business

Manifestation of knowledge8

A1

AB1 B2

A2

B3

B

A3

areas of knowledge

work products / artefacts

Minor issues

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

9

A1

A B3 Bareas of knowledge

C1=A2C

The heart of domain analysis

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

Raising the importance of domain knowledge

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

Breaking down complexity into manageable modules

Language design cheat sheet

12

Partial, incremental instantiation is common in product lines13

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

How to start depends on the domain14

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

Terminology matters much more than technology

Modelling languages differ from coding languagesObservation: 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

Separation of concerns

ProblemSpace 1

SolutionSpace

Glue

Language Engineering16

LanguageDomain

Reference Implementation

Framework or Component

Code Template

Artefact

Pattern Control Logic Statement

Template Variable

Syntactic Sugar

*1 1 1

1

*

*

1

code segment

implementationpattern1

1

logical sequence

target language text part

language artefacts

**

usage pattern instance

implementation technology

language element1

*

1

*

reference code segments

sub domains

* element value1

1

Increasingly higher levels of abstraction17

Operating SystemAbstraction

HardwareAbstraction

Web ServiceAbstraction

ApplicationPlatform

Val

ue

Ad

de

d

Ap

pli

cati

on

s

Co

mm

od

itiz

ed

T

ech

no

logi

es

Era 2010 1990 1970

EnterpriseApps

< 10relevant

operating systems

EmbeddedApps

< 50relevant

processor families

WebApps

1,000sof relevantframeworks

ApplicationDevelopment

Today’s platforms are defined relative to the user

Paradigm shift: One person’s application

is the next person’s platform!

1. Achieving and preserving modularity in-the-large

Qualities that are only scalable when using models18

Modularity

Operating SystemAbstraction

HardwareAbstraction

Web ServiceAbstraction

In popular implementation languages (Java, C#) modularity constructs are second class citiziens ...

2. Clear separation of application & platform

Qualities that are only scalable when using models19

Separation of Apps & Platform

Operating SystemAbstraction

HardwareAbstraction

Web ServiceAbstraction

Frameworks break the clean separation of the problem space from the solution space

3. Systematic exploitation of commoditized technologies

Qualities that are only scalable when using models20

Strategic use of Open Source

Operating SystemAbstraction

HardwareAbstraction

Web ServiceAbstraction

Configuring open source frameworks mostly requires a certain level of knowlegde about the solution space

From conventions to tool features

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

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

Example of a domain supply chain: Hardware device networks23

One little language for each kind of artefact1. 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

Assessment of EMF Ecore

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.

4. The .ecore file that defines the Abstract Syntax of a modeling language (the meta model) has exactly one instantiable Root Class, a Class that relates to the modeled Artefact.

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

Adhering to this principle in Ecore relies entirely on following conventions.

Assessment of EMF Ecore

Best Practices for Modelling Language Design (2)7. .ecore and .xmi files can only be edited by one user at a time

but can be read by any number of users.

8. References between .ecore files in conjunction with References between .xmi files provide the basis for modularization of modelling language designs and models (leading to modular meta models & models).

9. Only .ecore files can be used in the role of a meta model.

10. Two .ecore files may be joined via one or more References that connect Classes in the two .ecore files.

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

following ...

Adhering to these ...

principles in Ecore relies entirely on ...

conventions.

Limitation!

Best practices for concrete syntax design

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

Domain Implementation

Domain Analysis & Design

Domain engineering process27

Design languagesValidate languages

Extract templates

Develop platform

Validate reference

application

Develop reference

implementation

Analyse decisions

Domain engineering roles28

Conclusions

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

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

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

Potential

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

Keep it sweet and simple

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

Thank you!

Jorn Bettinjbe @ sofismo.chSkype jorn_bettin+41 62 891 0987