1. Principles of Model-driven Software Engineering

2. Contents Abstraction and modelling Types of models UML, MDA & MDSE 1.
Principles of Model-driven Software Engineering
Contents
Abstraction and modelling Types of models 1. 2.
UML, MDA & MDSE 3.
2/49

3. Abstraction and modelling
Principles of Model-driven Software Engineering
Abstraction and modelling
 Abstraction and modelling are two related techniques for reasoning about systems.
 Abstraction is a process that selectively removes
some information from a description to focus on the information that remains.
 Abstraction is an essential part of modelling where some aspect or part of the real world is simplified.
 One must decide what to show and what to ignore.  Abstraction is related to the notion of simplicity.  The history of software engineering is characterized by an increase in levels of abstraction.
4/49

4. Abstraction and modelling
Principles of Model-driven Software Engineering
Abstraction and modelling
 Raising the level of abstraction is one of the most fundamental techniques in software engineering.
 Refinement is the opposite of abstraction.
 It makes a description more complex by adding information and detail.
 It is used in software development to produce executables from requirements.
 When we add information, we must choose
among alternative solutions (i.e. we take design decisions).
5/49

5. Abstraction and modelling
Principles of Model-driven Software Engineering
Abstraction and modelling
 Complexity and its reduction by reorganization are central ideas in mathematics and software.
 Complexity is a measure of the difficulty of solving a given problem.
 Complexity can be measured in a number of
dimensions, most notably technical complexity.
 Essential complexity is inherent in the problem
being solved, and cannot be reduced or eliminated.  Intuitively, it is a function of the number of features and the number of relations among them that are needed to decompose the problem.
6/49

6. Abstraction and modelling
Principles of Model-driven Software Engineering
Abstraction and modelling
 Modelling is the cost-effective use of something in place of something else for some purpose.
 It allows us to use something that is simpler, safer or cheaper than reality.
 A model represents reality for the given purpose.  The model is an abstraction of reality in the sense that it cannot represent all its aspects.
 This allows the world to be dealt in a simplified manner, avoiding the complexity, danger and irreversibility of reality.
8/49

7. Abstraction and modelling
Principles of Model-driven Software Engineering
Abstraction and modelling
 To be useful and effective, a model must possess the following five key characteristics:
 Abstract
 Understandable  Accurate
 Predictive
 Inexpensive
9/49

8. Abstraction and modelling
Principles of Model-driven Software Engineering
Abstraction and modelling
 Many software models are represented with diagrams.
 Notations are either graphical or textual.
 A finite-state machine can be described by:
 a state-transition diagram
 list of states and transitions
 Graphical (or visual) notations are formal
languages, but they seem to carry a higher degree of vagueness than textual notations.
 Good graphical descriptions are hard to make,
since one must decide where to place the symbols.
11/49

9. Abstraction and modelling
Principles of Model-driven Software Engineering
Abstraction and modelling
meta-model
paradigm
model of
model of
computation
computation
perspective conforms to viewpoint
supports
system is represented by
model language
view
notation
system
specification
description
12/49

10. Abstractions and modelling topographical topological 14/49
Principles of Model-driven Software Engineering
Abstractions
and modelling
topographical
topological
14/49

11. Abstraction and modelling
Principles of Model-driven Software Engineering
Abstraction and modelling
 The bridges of London problem was solved by Euler in 1735.
 The answer laid the foundations of graph theory.
15/49

12. Abstraction and modelling
Principles of Model-driven Software Engineering
Abstraction and modelling
 The Kirchhoff’s law determines the relation of the physical quantities and the topological structure.
 Total amount of electric current around a vertex summed over edges incident to the vertex is zero
(incoming current is positive and outgoing current is negative).
 Total amount of voltage summed along a closed path is zero.
 i1+i2-i3=0
 V1+V2+V3+V4+V5=0
16/49

13. Contents Abstraction and modelling Types of models UML, MDA & MDSE 1.
Principles of Model-driven Software Engineering
Contents
Abstraction and modelling Types of models 1. 2.
UML, MDA & MDSE 3.
18/49

14. Principles of Model-driven Software Engineering
Types of models
 In software engineering, models are used for
various purposes (e.g., life cycle model, process model, project
model, product model, quality model, domain model, requirements model, design model, object model, and data model).
 We focus on analysis and design models.
 A (UML) model can graphically depict a system’s structure and behaviour from a certain viewpoint and at a certain level of abstraction.
 We can better manage a complex system
description through multiple models, where each one captures a different aspect.
19/49

15. Principles of Model-driven Software Engineering
Types of models
 We can use models horizontally to describe different system aspects.
 We can also use models vertically, to be refined from higher to lower levels of abstraction.
 At the lowest level, models use implementation technology concepts.
 Working with multiple, interrelated models
requires significant effort to ensure their overall consistency.
20/49

16. Principles of Model-driven Software Engineering
Types of models
 State-oriented models represent a system as a set of states and transitions between states.
 These models address the dynamic behaviour of the system.
 They evolve in response to external stimuli.
22/49

17. Principles of Model-driven Software Engineering
Types of models
 Activity-oriented models represent a system as a set of activities related by data or execution dependencies.
 These models are good for modelling systems where data is subject to a set of transformations.
23/49

18. Principles of Model-driven Software Engineering
Types of models
 Structure-oriented models describe the physical modules of a system and their connections.
 These models characterise the architecture (physical structure) of the system.
24/49

19. Principles of Model-driven Software Engineering
Types of models
 Data-oriented models describe systems as a
collection of data related by their attributes, their classification, etc.
 These models give more relevance to the organization of data, rather than the system’s
functionality.
25/49

20. Principles of Model-driven Software Engineering
Types of models
 Heterogeneous models incorporate, in a unique
representation, characteristics from the four basic types of models.
 For example, CDFGs model both the sequence of control of the system and the data dependencies.
26/49

21. THE MODEL-DRIVEN ZOO UML, MDA, MDSE Model Transformations
Principles of Model-driven Software Engineering
UML, MDA, MDSE
THE MODEL-DRIVEN ZOO
Model Transformations
Model-Driven Engineering
Model-Based Testing
Model-Based Software Architecture
Model-Based Modernization
of Software Systems Model-Driven
Model-Driven Development
Software Development
Model-Driven Architecture
Model-Driven
Software Adaptation
28/49

22. Principles of Model-driven Software Engineering
UML, MDA, MDSE
 The UML (Unified Modeling Language) is a family of
graphical notations, backed by a single meta- model, for describing software.
 The UML is a relatively open standard, controlled by the OMG, an open consortium of companies.
OMT
UML
(Rumbaugh)
2.0
1996
2003
Booch
UML UML
1997 UML UML UML UML UML 1.5
0.9 1.x
OOSE
(Jacobson) Catalysis
ROOM etc.
29/49

23. Principles of Model-driven Software Engineering
UML, MDA, MDSE
 The UML defines a notation and a meta-model.
 The notation is the graphical
Feature
syntax of the modelling language.  A meta-model is a diagram
that defines the concepts of the language.
Structural Behavioural
Feature Feature
 A meta-model is a model of a modelling language.
0..1
{ordered}
 A meta-model is strongly related to
Parameter
the notion of ontology.
31/49

24. UML, MDA, MDSE  A 4-layer architecture is used to define languages.
Principles of Model-driven Software Engineering
UML, MDA, MDSE
 A 4-layer architecture is used to define languages.
 At level 0, concrete instances of the domain concepts are present.
 Level 1 defines the language or the model used to represent the concepts of the domain.
 Level 2 provides a definition of the language used on level 1, i.e., a meta-model.
 At level 3, a language for defining languages (a meta-meta-model) is used to create new language definitions.
32/49

25. Principles of Model-driven Software Engineering
UML, MDA, MDSE
 Meta-modeling is an approach to define the abstract syntax of languages.
 Meta-modeling has come to mean the
construction of an OO model (class diagram).  A meta-model characterizes language elements as classes and relationships between them using attributes and associations.
33/49

26. Principles of Model-driven Software Engineering
UML, MDA, MDSE
 The UML is a collection of miscellaneous diagrams and its specification is continuously changing.
 The UML is a semi-formal language.
 The idea of rigorous specifications and languages is most prevalent in the field of formal methods.
 With formal methods, the specifications are
mathematically rigorous and carry no ambiguity.  Most graphical languages have little rigour; their notation appeals to intuition.
 Anyway, informal methods are useful.
34/49

27. UML, MDA, MDSE  What is a legal UML model?
Principles of Model-driven Software Engineering
UML, MDA, MDSE
 What is a legal UML model?
 Legal UML is what is defined as well-formed in the specification.
 Does the UML have descriptive or prescriptive rules?
 A language with prescriptive rules is controlled by an official body that states what is legal.
 You understand the rules of a language with descriptive rules by looking at how people use the language in practice.
35/49

28. Principles of Model-driven Software Engineering
UML, MDA, MDSE
 Programming languages tend to have
prescriptive rules set by a standard committee.  Natural languages tend to have descriptive rules, whose meaning is set by convention.
 Simply having a standards body does not ensure that everybody follows the rules (e.g. French).
 The UML is so complex that the standard is open to multiple interpretations and usages.
 A profile is a subset of the UML, extended with a group of stereotypes, for a specific purpose.
36/49

29. UML, MDA, MDSE  Software engineers use the UML in three modes:
Principles of Model-driven Software Engineering
UML, MDA, MDSE
 Software engineers use the UML in three modes:
 sketch (informal design)
 blueprint (model-driven development)  programming language
 In sketch, the UML is used to help communicate some aspects of a system.
 Sketches can be used in forward- and reverse- engineering.
 Forward-engineering draws a UML diagram before writing code.
 Reverse-engineering builds a UML diagram from existing code to help understand it.
37/49

30. UML, MDA, MDSE  The essence of sketching is selectivity.
Principles of Model-driven Software Engineering
UML, MDA, MDSE
 The essence of sketching is selectivity.
 UML as blueprint is about completeness.
 In forward engineering, blueprints are detailed design artefacts used to produce code.
 In reverse engineering, blueprints aim to convey detailed information about the code.
 Round-trip engineering, which supports forward and reverse engineering, allows full automation.
 Round-trip engineering combines code generation and code visualization and synchronizes the changes between the models and the source.
38/49

31. Principles of Model-driven Software Engineering
UML, MDA, MDSE
 As programming gets mechanical, it should be automated.
 Many tools do some form of code generation.
 When all the system can be specified in the UML, we reach UML as programming language.
 The UML as a programming language seems a nice idea.
 However, it is debatable if graphical languages are more productive than textual ones for programming tasks.
39/49

32. Principles of Model-driven Software Engineering
UML, MDA, MDSE
 The UML has succeeded as sketching medium, but not as a MDD or execution language.
 The UML lacks the precision required for automate development.
 The UML does not support CBD (Component-Based
Development) well.
 The UML is too general for real domains and has weak extensibility mechanisms that make it hard to focus.
40/49

33. Principles of Model-driven Software Engineering
UML, MDA, MDSE
 Common mistakes when using UML:
 Over-engineering
 Documentation-only
 Gap from analysis/design to implementation
 Some developers never generate code from many of their models.
 Yet they spend enormous energy and time creating models of excruciating detail.
 Models should be created to better understand
and reason about the system under development and to collaborate with various stakeholders.
41/49

34. Principles of Model-driven Software Engineering
UML, MDA, MDSE
 Modelling the world to a level of precision greater than what the final system will actually be is a mistake.
 Some developers use the UML only as a means of documenting their design decisions.
 UML should be used for creating, then reasoning about systems: documentation is thus not an end unto itself.
 UML has proven a valuable mechanism for communicating and collaborating with the stakeholders.
42/49

35. Principles of Model-driven Software Engineering
UML, MDA, MDSE
 Many models created can be simply thrown away (they are needed to communicate and/or reason about a part of the system).
 UML is typically constrained to so-called analysts and architects.
 UML models are thrown over the wall to the
programmers who actually construct the system.  Programmers must be familiar with the UML, and find great value in using it to better understand and construct the executable code.
 We need operational (executable, computable) models, rather than contemplative ones.
43/49

36. Principles of Model-driven Software Engineering
UML, MDA, MDSE
 MDA (Model-Driven Architecture) is a OMG standard approach to use the UML as a programming language.
 MDA is based on the use of model transformations as the main tool to move the system specification from one abstraction level to another.
 A model transformation takes a set of source models as input and produce a set of target models as output, while following a set of rules.
 MDA divides development into two main areas.  Modellers represent a particular application by creating a PIM.
44/49

37. Principles of Model-driven Software Engineering
UML, MDA, MDSE
 A PIM (Platform-Independent Model) is a UML model that is independent of any technology.
 Tools can then turn a PIM into a PSM.
 The PSM (Platform-Specific Model) is a model targeted for a specific execution platform.
 Further tools take the PSM and generate code for that platform.
 If the process PIM→PSM→code is fully automated, we have the UML as a programming language.  If any of the steps is manual, we have blueprints.
45/49

38. Principles of Model-driven Software Engineering
UML, MDA, MDSE
 Four types of possible model transformations:
 PIM→PIM: promotes refinements (e.g., adding
details) of a specification, in a platform-independent manner;
 PIM→PSM: projects a platform-independent specification on a given “implementation” infrastructure;
 PSM→PSM: covers refinements of the specification, in a platform-dependent manner;
 PSM→PIM: changes existing specification models into more abstract ones, by removing platform-dependent details.
46/49

39. UML, MDA, MDSE captured by models to automate development processes.
Principles of Model-driven Software Engineering
UML, MDA, MDSE
 MDD (Model-Driven Development) uses information
captured by models to automate development processes.
 The basic principle of MDD is that “Everything is a model”.
 MDD is programming with models.
 The focus moves from programming language code to models.
 MDD uses models to capture intent precisely.
 MDD fully or partially automates implementation, by generating executables from models.
48/49

40. Principles of Model-driven Software Engineering
UML, MDA, MDSE
 In MDD, models are used in much the same way as source code is traditionally used.
 Thus, MDD success depends heavily on high- quality tool support.
 To be processed by tools, models cannot be
written in languages designed for documentation.  To be precise, a language must be conceived for a specific purpose.
 A DSL (domain-specific language) is a language that uses concepts from the problem domain.
 A DSL provides greater rigour than UML.
49/49