Principles of Model-driven Software Engineering. Contents 1. 2. 3. Abstraction and modelling Types...

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


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



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



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



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



To be useful and effective, a model must possessthe following five key characteristics:

Abstract

Understandable Accurate

Predictive Inexpensive

9/49



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



meta-modelparadigm

model ofcomputation

perspective conforms toviewpoint

system is represented by

model ofcomputation

supports

view

system

model language

notation

specification

description

12/49


Abstractionsand modelling

topographical

topological14/49


Abstraction and modelling The bridges of London problem was solved byEuler in 1735.

The answer laid the foundations of graph theory.

15/49


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


Contents

1.

2.

3.

Abstraction and modellingTypes of models

UML, MDA & MDSE

18/49


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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

Principles of Model-driven Software Engineering. Contents 1. 2. 3. Abstraction and modelling Types...

Documents

Transcript of Principles of Model-driven Software Engineering. Contents 1. 2. 3. Abstraction and modelling Types...