principles of model-driven software engineering. contents 1. 2. 3. abstraction and modelling types...
TRANSCRIPT
Principles of Model-drivenSoftware Engineering
Principles of Model-driven Software Engineering
Contents
1.
2.
3.
Abstraction and modellingTypes of models
UML, MDA & MDSE
2/49
Principles of Model-driven Software Engineering
Abstraction and modelling
Abstraction and modelling are two relatedtechniques for reasoning about systems.
Abstraction is a process that selectively removessome information from a description to focus on theinformation that remains.
Abstraction is an essential part of modelling wheresome 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 characterizedby an increase in levels of abstraction.
4/49
Principles of Model-driven Software Engineering
Abstraction and modelling
Raising the level of abstraction is one of the mostfundamental techniques in software engineering.
Refinement is the opposite of abstraction. It makes a description more complex by addinginformation and detail.
It is used in software development to produceexecutables from requirements.
When we add information, we must chooseamong alternative solutions (i.e. we take designdecisions).
5/49
Principles of Model-driven Software Engineering
Abstraction and modelling
Complexity and its reduction by reorganization arecentral ideas in mathematics and software. Complexity is a measure of the difficulty of solvinga given problem.
Complexity can be measured in a number ofdimensions, most notably technical complexity.
Essential complexity is inherent in the problembeing solved, and cannot be reduced or
eliminated. Intuitively, it is a function of the number of featuresand the number of relations among them that areneeded to decompose the problem. 6/49
Principles of Model-driven Software Engineering
Abstraction and modelling
Modelling is the cost-effective use of somethingin 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 sensethat it cannot represent all its aspects.
This allows the world to be dealt in a simplifiedmanner, avoiding the complexity, danger andirreversibility of reality.
8/49
Principles of Model-driven Software Engineering
Abstraction and modelling
To be useful and effective, a model must possessthe following five key characteristics:
Abstract
Understandable Accurate
Predictive Inexpensive
9/49
Principles of Model-driven Software Engineering
Abstraction and modelling
Many software models are represented withdiagrams.
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 formallanguages, but they seem to carry a higher degreeof vagueness than textual notations. Good graphical descriptions are hard to make,
since one must decide where to place the symbols.
11/49
Principles of Model-driven Software Engineering
Abstraction and modelling
meta-modelparadigm
model ofcomputation
perspective conforms toviewpoint
system is represented by
model ofcomputation
supports
view
system
model language
notation
specification
description
12/49
Principles of Model-driven Software Engineering
Abstractionsand modelling
topographical
topological14/49
Principles of Model-driven Software Engineering
Abstraction and modelling The bridges of London problem was solved byEuler in 1735.
The answer laid the foundations of graph theory.
15/49
Principles of Model-driven Software Engineering
Abstraction and modelling The Kirchhoff’s law determines the relation of thephysical quantities and the topological structure.
Total amount of electric current around a vertexsummed 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 pathis zero.
i1+i2-i3=0 V1+V2+V3+V4+V5=0
16/49
Principles of Model-driven Software Engineering
Contents
1.
2.
3.
Abstraction and modellingTypes of models
UML, MDA & MDSE
18/49
Principles of Model-driven Software Engineering
Types of models
In software engineering, models are used forvarious 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’sstructure and behaviour from a certain viewpointand at a certain level of abstraction.
We can better manage a complex systemdescription through multiple models, where eachone captures a different aspect.
19/49
Principles of Model-driven Software Engineering
Types of models
We can use models horizontally to describedifferent system aspects.
We can also use models vertically, to be refinedfrom higher to lower levels of abstraction. At the lowest level, models use implementationtechnology concepts.
Working with multiple, interrelated modelsrequires significant effort to ensure their overallconsistency.
20/49
Principles of Model-driven Software Engineering
Types of models
State-oriented models represent a system as a setof states and transitions between states.
These models address the dynamic behaviour ofthe system.
They evolve in response to external stimuli.
22/49
Principles of Model-driven Software Engineering
Types of models Activity-oriented models represent a system as aset of activities related by data or executiondependencies.
These models are good formodelling systems wheredata is subject to a set oftransformations.
23/49
Principles of Model-driven Software Engineering
Types of models Structure-oriented models describe the physicalmodules of a system and their connections.
These models characterise the architecture(physical structure) of the system.
24/49
Principles of Model-driven Software Engineering
Types of models Data-oriented models describe systems as a
collection of data related by their attributes, theirclassification, etc.
These models givemore relevance tothe organization ofdata, rather thanthe system’s
functionality.
25/49
Principles of Model-driven Software Engineering
Types of models Heterogeneous models incorporate, in a uniquerepresentation, characteristics from the four basictypes of models.
For example, CDFGs model both the sequence ofcontrol of the system and the data dependencies.
26/49
Principles of Model-driven Software Engineering
UML, MDA, MDSE
THE MODEL-DRIVEN ZOO
Model-DrivenEngineering Model-Based
Testing
Model Transformations
Model-BasedSoftware Architecture
Model-Based Modernizationof Software Systems
Model-DrivenSoftware Development
Model-DrivenDevelopment
Model-DrivenArchitecture Model-Driven
Software Adaptation28/49
Principles of Model-driven Software Engineering
UML, MDA, MDSE The UML (Unified Modeling Language) is a family ofgraphical notations, backed by a single meta-model, for describing software.
The UML is a relatively open standard, controlledby the OMG, an open consortium of companies.
OMT(Rumbaugh)
Booch
OOSE(Jacobson)
Catalysis
1996
UML UML0.9 1.x
ROOM etc.
UML2.0
2003
1997 UML 1.11998 UML 1.21999 UML 1.32001 UML 1.42002 UML 1.5
29/49
Principles of Model-driven Software Engineering
UML, MDA, MDSE The UML defines a notation and ameta-model.
The notation is the graphical Feature
syntax of the modelling language. A meta-model is a diagramthat defines the concepts
of the language.
A meta-model is a model of amodelling language.
Structural BehaviouralFeature Feature
0..1
{ordered}
A meta-model is strongly related to Parameterthe notion of ontology.
31/49
Principles of Model-driven Software Engineering
UML, MDA, MDSE
A 4-layer architecture is used to definelanguages.
At level 0, concrete instances of the domainconcepts are present.
Level 1 defines the language or the model usedto represent the concepts of the domain.
Level 2 provides a definition of the language usedon level 1, i.e., a meta-model.
At level 3, a language for defining languages (ameta-meta-model) is used to create newlanguage definitions.
32/49
Principles of Model-driven Software Engineering
UML, MDA, MDSE
Meta-modeling is an approach to define theabstract syntax of languages.
Meta-modeling has come to mean theconstruction of an OO model (class diagram).
A meta-model characterizes language elementsas classes and relationships between themusing attributes and associations.
33/49
Principles of Model-driven Software Engineering
UML, MDA, MDSE
The UML is a collection of miscellaneous diagramsand its specification is continuously changing.
The UML is a semi-formal language. The idea of rigorous specifications and languagesis most prevalent in the field of formal methods.
With formal methods, the specifications aremathematically rigorous and carry no
ambiguity. Most graphical languages have little rigour; theirnotation appeals to intuition. Anyway, informal methods are useful.
34/49
Principles of Model-driven Software Engineering
UML, MDA, MDSE
What is a legal UML model? Legal UML is what is defined as well-formed inthe specification.
Does the UML have descriptive or prescriptiverules? A language with prescriptive rules is controlledby an official body that states what is legal.
You understand the rules of a language withdescriptive rules by looking at how people usethe language in practice.
35/49
Principles of Model-driven Software Engineering
UML, MDA, MDSE
Programming languages tend to haveprescriptive 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 ensurethat everybody follows the rules (e.g. French). The UML is so complex that the standard is opento multiple interpretations and usages. A profile is a subset of the UML, extended with agroup of stereotypes, for a specific purpose.
36/49
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 communicatesome aspects of a system. Sketches can be used in forward- and reverse-engineering.
Forward-engineering draws a UML diagram beforewriting code.
Reverse-engineering builds a UML diagram fromexisting code to help understand it.
37/49
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 detaileddesign artefacts used to produce code.
In reverse engineering, blueprints aim to conveydetailed information about the code. Round-trip engineering, which supports forwardand reverse engineering, allows full automation.
Round-trip engineering combines code generationand code visualization and synchronizes thechanges between the models and the source.
38/49
Principles of Model-driven Software Engineering
UML, MDA, MDSE
As programming gets mechanical, it should beautomated. 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 anice idea.
However, it is debatable if graphical languagesare more productive than textual ones forprogramming tasks.
39/49
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 forautomate development.
The UML does not support CBD (Component-Based
Development) well. The UML is too general for real domains and hasweak extensibility mechanisms that make it hardto focus.
40/49
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 manyof their models.
Yet they spend enormous energy and timecreating models of excruciating detail.
Models should be created to better understandand reason about the system under developmentand to collaborate with various stakeholders.
41/49
Principles of Model-driven Software Engineering
UML, MDA, MDSE
Modelling the world to a level of precision greaterthan what the final system will actually be is amistake. Some developers use the UML only as a means ofdocumenting their design decisions. UML should be used for creating, then reasoningabout systems: documentation is thus not an endunto itself.
UML has proven a valuable mechanism forcommunicating and collaborating with thestakeholders.
42/49
Principles of Model-driven Software Engineering
UML, MDA, MDSE
Many models created can be simply thrown away(they are needed to communicate and/or reasonabout a part of the system). UML is typically constrained to so-called analystsand architects.
UML models are thrown over the wall to theprogrammers who actually construct the
system. Programmers must be familiar with the UML, andfind great value in using it to better understandand construct the executable code. We need operational (executable, computable)models, rather than contemplative ones.
43/49
Principles of Model-driven Software Engineering
UML, MDA, MDSE MDA (Model-Driven Architecture) is a OMG standard
approach to use the UML as a programminglanguage.
MDA is based on the use of model transformationsas the main tool to move the system specificationfrom one abstraction level to another.
A model transformation takes a set of sourcemodels as input and produce a set of targetmodels as output, while following a set of rules.
MDA divides development into two main areas. Modellers represent a particular application bycreating a PIM.
44/49
Principles of Model-driven Software Engineering
UML, MDA, MDSE
A PIM (Platform-Independent Model) is a UML model that isindependent 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 forthat 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
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-independentmanner;
PIM→PSM: projects a platform-independentspecification on a given “implementation”infrastructure;
PSM→PSM: covers refinements of the specification, ina platform-dependent manner; PSM→PIM: changes existing specification models intomore abstract ones, by removing platform-dependentdetails.
46/49
Principles of Model-driven Software Engineering
UML, MDA, MDSE
MDD (Model-Driven Development) uses informationcaptured by models to automate developmentprocesses.
The basic principle of MDD is that “Everything isa model”.
MDD is programming with models. The focus moves from programming languagecode to models. MDD uses models to capture intent precisely.
MDD fully or partially automates implementation,by generating executables from models.
48/49
Principles of Model-driven Software Engineering
UML, MDA, MDSE
In MDD, models are used in much the same wayas source code is traditionally used.
Thus, MDD success depends heavily on high-quality tool support. To be processed by tools, models cannot bewritten in languages designed for
documentation. To be precise, a language must be conceived fora 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