Introduction to MDE

MDE Intro
Maestría en Ingeniería – énfasis Ingeniería del Software
Fáber D. Giraldo -
fdgiraldo@uniquindio.edu.co
fdgiraldo@pros.upv.es

In memory – Robert France
https://advancing.colostate.edu/ROBERTFRANCEFELLOWSHIP
• His paper on UML was honored with a 10-year Most
Influential Paper Award at the Model Driven Engineering
and Languages and Systems conference
• Co-founder of the Software and Systems Modeling Journal
• Leader of ReMoDD
(http://www.cs.colostate.edu/remodd/v1/content/repositor
y-model-driven-development-remodd-overview)

Sources
• Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-driven software
engineering in practice.Morgan & Claypool, USA, 2012
• Bézivin, J. (2006). Model Driven Engineering: An Emerging Technical Space.
Generative and Transformational Techniques in Software Engineering. R.
Lämmel, J. Saraiva and J. Visser, Springer Berlin / Heidelberg. 4143: 36-64
• David W. Embley · Bernhard Thalheim Editors. Handbook of Conceptual
Modeling, Theory, Practice, and Research Challenges. Springer, 2011.
• Oscar Pastor and Juan Carlos Molina. Model-driven architecture in practice,
A Software Production Environment Based on Conceptual Modeling.
Springer, 2007.
• and more…

Agenda
• Model-driven preliminaries
• Key terms in MDE
• MDA in deep
• Some examples
• Models in Deep (philosophy)

Fuente: Bill Curtis. Software Quality in Healthcare Systems. MBSE in HealthCare Summit, Boston MA. June 2014

Yesterday, I searched for model in Google…
just look here!!! =)

History of Modelling Languages Source: Tolvanen & Cabot,
http://modeling-
languages.com/history-
modeling-languages-one-
picture-j-p-tolvanen/

And, models for what?
• Why models are useful in Software Engineering and Information
Systems?
• Why Software Engineering practitioners must consider the model-
driven paradigm?
• Does model-driven compites againts Software Engineering itself?

Models & Engineering
Key: Taming the complexity
http://www.miliarium.com/Bibliografia/Monografias/ModelosSimulacionAmbiental/ModeloMODFLOW.jpg
http://www.scielo.org.ve/img/fbpe/imme/v44n1/art04img1.1.gif
http://wikifab.dimf.etsii.upm.es/wikifab/images/8/82/Circuito_electronico_..jpg
http://upload.wikimedia.org/wikipedia/commons/thumb/2/2b/Osi-model.png/250px-Osi-model.png

Facts and truths about model-driven
Source: http://www.nii.ac.jp/userimg/lectures/20120117/Lecture3.pdf

• The IBM MDA manifesto (2004) makes the claim that MDA-based approaches
are founded on three ideas: Direct representation, Automation and Standards.
• Direct representation allows a more direct coupling of problems to solutions
with the help of Domains Specific Languages (DSLs).
• Automations means that the facets represented in these DSLs are intended to
be processed by computer-based tools to bridge the semantic gap between
domain concepts and implementation technologies and not only for mere
documentation.
• This should be complemented by the use of open standards that will allow
technical solutions to interoperate
When Model-driven born ?
Source: Bézivin, J. (2006). Model Driven Engineering: An Emerging Technical Space. Generative and Transformational
Techniques in Software Engineering. R. Lämmel, J. Saraiva and J. Visser, Springer Berlin / Heidelberg. 4143: 36-64.

In November 2000 the OMG proposed a new approach to
interoperability named MDA™ (Model-Driven Architecture).
MDA is one example of the broader Model Driven Engineering
(MDE) vision, encompassing many popular current research
trends related to generative and transformational techniques in
software engineering, system engineering, or data engineering.
Considering models as first class entities and any software
artifact as a model or as a model element is one of the basic
principles of MDE.
Before…

The OMG MDA initial proposal may be defined as the
realization of MDE principles around a set of OMG
standards like MOF, XMI, OCL, UML, CWM, and SPEM.
Model-driven (II)

Model-driven (III)
http://www.omg.org/mda/

Part II – KEY TERMS
Most of the followings slides are taken from Teaching material for the
Model-driven software engineering in practice book, chapters 1-4.
More information in
https://www.sites.google.com/site/mdsebook/ ,
http://www.slideshare.net/jcabot/
Thanks to authors for sharing this material to the MDE community

Abstraction and human mind
• The human mind continuously re-works reality by applying cognitive
processes
• Abstraction: capability of finding the commonality in many different
observations:
• generalize specific features of real objects (generalization)
• classify the objects into coherent clusters (classification)
• aggregate objects into more complex ones (aggregation)
• Model: a simplified or partial representation of reality, defined in
order to accomplish a task or to reach an agreement

Models
What is a model?
Mapping Feature A model is based on an original (=system)
Reduction Feature A model only reflects a (relevant) selection of
the original‘s properties
Pragmatic Feature A model needs to be usable in place of an
original with respect to some purpose
ModelrepresentsSystem
Purposes:
• descriptive purposes
• prescriptive purposes

Motivation
What is Model Engineering?
 Model as the central artifact of software development
 Related terms
 Model Driven Engineering (MDE),
 Model Driven [Software] Development (MDD/MDSD),
 Model Driven Architecture (MDA)
 Model Integrated Computing (MIC)
Model
Rapid prototyping
Static analysis
Code generation
Automated testing
Refactoring/
Transformation
Documentation

Motivation
Why Model Engineering?
 Increasing complexity of software
 Increasing basic requirements, e.g., adaptable GUIs, security, network capabilities, …
 Complex infrastructures, e.g., operating system APIs, language libraries, application
frameworks
 Software for specific devices
 Web browser, mobile phone, navigation system, video player, etc.
 Technological progress …
 Integration of different technologies and legacy systems, migration to new technologies
 … leads to problems with software development
 Software finished too late
 Wrong functionality realized
 Software is poorly documented/commented
 and can not be further developed, e.g., when the technical environment changes, business
model/ requirements change, etc.

Motivation
Why Model Engineering?
 Traditional usage of models in software development
 Communication with customers and users (requirement specification, prototypes)
 Support for software design, capturing of the intention
 Task specification for programming
 Code visualization
 What is the difference to Model Engineering?

Concepts
Principles and objectives
 Abstraction from specific realization technologies
 Requires modeling languages, which do not hold specific concepts of realization
technologies (e.g., Java EJB)
 Improved portability of software to new/changing technologies – model once, build
everywhere
 Interoperability between different technologies can be automated (so called
Technology Bridges)
 Automated code generation from abstract models
 e.g., generation of Java-APIs, XML Schemas, etc. from UML
 Requires expressive und precise models
 Increased productivity and efficiency (models stay up-to-date)
 Separate development of application and infrastructure
 Separation of application-code and infrastructure-code (e.g. Application
Framework) increases reusability
 Flexible development cycles as well as different development roles possible

MDSE methodology ingredients
 Concepts: The components that build up the methodology
 Notations: The way in which concepts are represented
 Process and rules: The activities that lead to the production of the final
product
 Tools: Applications that ease the execution of activities or their
coordination
Models + Transformations = Software

Motivation
Application area of modeling
 Models as drafts
 Communication of ideas and alternatives
 Objective: modeling per se
 Models as guidelines
 Design decisions are documented
 Objective: instructions for implementation
 Models as programs
 Applications are generated automatically
 Objective: models are source code and vice versa

Motivation
Increasing abstraction in software development
 The used artifacts of software development
slowly converge to the concepts of
the application area
Assembler (001001)
Assembler and mnemonic
abbreviations (MV, ADD, GET)
Procedural constructs
(while, case, if)
Libraries (GUI, lists)
Components (provided/required interface)
Business objects
(course, account, customer)
[Illustration by Volker Gruhn]

Relations between MD* Acronyms
Source: Jordi Cabot. Clarifying concepts: MBE vs MDE vs MDD vs MDA.
Available in http://modeling-languages.com/clarifying-concepts-mbe-vs-mde-vs-mdd-vs-mda/
• Model-Driven Development
(MDD) is a development paradigm
that uses models as the primary
artifact of the development
process.
• Model-driven Architecture (MDA)
is the particular vision of MDD
proposed by the Object
Management Group (OMG)
• Model-Driven Engineering (MDE)
is a superset of MDD becauseit
goes beyond of the pure
development
• Model-Based Engineering (or
“model-based development”)
(MBE) is a softer version of ME,
where models do not “drive” the
process.

Target of MDSE
 The Problem Domain
is defined as the field
or area of expertise
that needs to be
examined to solve a
problem.
 The Domain Model is
the conceptual model
of the problem domain
 Technical Spaces
represent specific
working contexts for
the specification,
implementation, and
deployment of
applications.

Modeling Languages
 Domain-Specific Languages (DSLs): languages that are designed specifically
for a certain domain or context
 DSLs have been largely used in computer science. Examples: HTML, Logo,
VHDL, Mathematica, SQL
 General Purpose Modeling Languages (GPMLs, GMLs, or GPLs): languages
that can be applied to any sector or domain for (software) modeling
purposes
 The typical examples are: UML, Petri-nets, or state machines

Model Transformations – the model-driven heart
 Transforming items
 MDSE provides appropriate languages for defining model
transformation rules
 Rules can be written manually from scratch by a developer, or can be
defined as a refined specification of an existing one.
 Alternatively, transformations themselves can be produced
automatically out of some higher level mapping rules between models
 defining a mapping between elements of a model to elements to another one
(model mapping or model weaving)
 automating the generation of the actual transformation rules through a system
that receives as input the two model definitions and the mapping
 Transformations themselves can be seen as models!!

MDA Consequences
From: http://www.omg.org/mof/
Key: The MetaObject Facility
(MOF) Specification is the
foundation of OMG's industry-
standard environment where
models can be exported from one
application, imported into
another, transported across a
network, stored in a repository
and then retrieved, rendered into
different formats (including XMI,
OMG's XML-based standard
format for model transmission
and storage), transformed, and
used to generate application code

MDA Consequences (II)
Source: http://www.modeliosoft.com/en/technologies/mda.html

• A Metamodel is the construction of a collection of "concepts"
(things, terms, etc.) within a certain domain.
• A model is an abstraction of phenomena in the real world;
• A metamodel is yet another abstraction, highlighting properties of
the model itself.
• A model conforms to its metamodel in the way that a computer
program conforms to the grammar of the programming language in
which it is written.
Metamodel (from Wikipedia)
http://en.wikipedia.org/wiki/Metamodeling

Source: Bézivin, J. and I. Kurtev Model-based Technology Integration with the Technical Space
Concept.
Key: the Technical spaces concept
metametamodel level
metamodel level
model level
Real life level
MDA

MDA Consequences (II)
Source: http://www.jot.fm/issues/issue_2006_11/article4/
Note: XMI means XML Metadata Interchange

Metamodeling
 To represent the models
themselves as “instances”
of some more abstract
models.
 Metamodel = yet another
abstraction, highlighting
properties of the model
itself
 Metamodels can be used
for:
 defining new languages
 defining new properties or
features of existing
information (metadata)
Source: Chapter 2 Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-driven software engineering in
practice.Morgan & Claypool, USA, 2012

Part III: MDA in deep
• The Object Management Group (OMG) has defined its own
comprehensive proposal for applying MDE practices to system’s
development

Four principles of MDA
• Models must be expressed in a well-defined notation, so as to
enable effective communication and understanding
• Systems specifications must be organized around a set of models and
associated transformations
• implementing mappings and relations between the models.
• multi-layered and multi-perspective architectural framework.
• Models must be compliant with metamodels
• Increase acceptance, broad adoption and tool competition for MDE

Definitions according to MDA
• System: The subject of any MDA specification (program, computer system, federation of
systems)
• Problem Space (or Domain): The context or environment of the system
• Solution Space: The spectrum of possible solutions that satisfy the reqs.
• Model: Any representation of the system and/or its environment
• Architecture: The specification of the parts and connectors of the system and the rules
for the interactions of the parts using the connectors
• Platform: Set of subsystems and technologies that provide a coherent set of
functionalities for a specified goal
• Viewpoint: A description of a system that focuses on one or more particular concerns
• View: A model of a system seen under a specific viewpoint
• Transformation: The conversion of a model into another model

Modeling Levels
CIM, PIM, PSM
 Computation independent (CIM): describe requirements and needs at a
very abstract level, without any reference to implementation aspects (e.g.,
description of user requirements or business objectives);
 Platform independent (PIM): define the behavior of the systems in terms of
stored data and performed algorithms, without any technical or
technological details;
 Platform-specific (PSM): define all the technological aspects in detail.
39

Modeling language specification
• MDA’s core is UML, a standard general-purpose software modeling
language
Two options for specifying your languages:
• (Domain-specific) UML Extensions can be defined through UML
Profiles
• Full-fledged Domain-specific languages (DSMLs) can be defined by
MOF

Part IV: some model-driven real examples

Example: MDA & Software Process
Source: https://wiki.aston.ac.uk/foswiki/pub/DanCornford/FinalYearProjectResources/RUP_Guide.pdf

MOF
Example: MDA & Software Process
metametamodel level
metamodel level
model level
Real life level
SPEM
RUP SCRUM XP
Taylored Process

The Software and Systems Process Engineering Meta-model
(SPEM) is a process engineering meta-model as well as
conceptual framework, which can provide the necessary
concepts for modeling, documenting, presenting,
managing, interchanging, and enacting development
methods and processes.
An implementation of this meta-model would be targeted at
process engineers, project leads, project and program
managers who are responsible for maintaining and
implementing processes for their development organizations
or individual projects.
SPEM Metamodel

CIM
MDA Computation Independent Model (CIM)
 E.g., business process
49

PIM
MDA Platform Independent Model (PIM)
 specification of
structure and behaviour
of a system, abstracted
from technologicical
details
 Using the UML(optional)
 Abstraction of structur and behaviour of a system with the PIM simplifies the
following:
 Validation for correctness of the model
 Create implementations on different platforms
 Tool support during implementation
50

PSM
MDA Platform Specific Model (PSM)
 Specifies how the functionality described in the PIM is
realized on a certain platform
 Using a UML-Profile for the selected platform, e.g., EJB
51

Approaches
 Considered Approaches
 Computer Aided Software Engineering (CASE)
 Executable UML
 Model Driven Architecture (MDA)
 Architecture Centric Model Driven Software Development (AC-MDSD)
 MetaCASE
 Software Factories
 Distinguishing features
 Special objectives and fields of application
 Restrictions or extensions of the basic architecture
 Concrete procedures
 Specific technologies, languages, tools

Real models
• IBM Rational and IBM Software Tools
• Metacase (https://www.metacase.com/)
• Mendix (http://www.mendix.com/)
• Integranova (http://www.integranova.com/)
• Eclipse xtext Project (https://eclipse.org/Xtext/)
• Eclipse EMF and GMF
http://eclipse.org/modeling/emf/
http://eclipse.org/modeling/graphical.php
http://eclipse.org/modeling/
• fUML
(https://github.com/ModelDriven/fUML-Reference-Implementation)
And more!!!…..

Part V: Models in Deep (philosophy).
• The following slides are extracted from:
Bernhard Thalheim. Chapter 17 The Theory of Conceptual Models, the
Theory of Conceptual Modelling and Foundations of Conceptual
Modelling. In Handbook of Conceptual Modeling - Theory, Practice, and
Research Challenges, Springer 2011.

Models commonalities in computer science
• Purpose: Models and conceptual models are governed by the
purpose. The model preserves the purpose. Therefore the purpose is
an invariant for the modelling process.
• Mapping: The model is a mapping of an origin. It reflects some of the
properties observed or envisioned for the origin.
• Language as a carrier: Models use languages and are thus restricted
by the expressive power of these languages. Candidates for languages
are formal or graphical languages, media languages, illustration
languages, or computer science constructions.
• Value: Models provide a value or benefit based on their utility,
capability and quality characteristics.

Typical intentions and aims within models
purposes
• Perception support for understanding the application domain.
• Explanation and demonstration for understanding an origin.
• Preparation to management and handling of the origin.
• Optimization of the origin.
• Hypothesis verification through the model.
• Construction of an artifact or of a program.
• Control of parts of the application.
• Simulation of behaviour in certain situations.
• Substitution for a part of the application

The author – addressee model relationship

Four aspects of the modelling space

Myths around models
1. Modelling equals documentation.
2. You can think everything through from the start.
3. Modelling implies a heavyweight software process.
4. You must “freeze” requirements and then you can start with modelling.
5. Your model is carved in stone and changes only from time to time.
6. You must use a CASE tool.
7. Modelling is a waste of time.
8. The world revolves around data modelling.
9. All developers know how to model.
10. Modelling is independent of the language.

Dimmensions of modelling
• Purpose (“wherefore”) of models and modelling, with the intentions,
goals, aims, and tasks that are going to be solved by the model.
• Mapping (“whereof”), with a description of the solution provided by the
model, the characterisation of the problem, phenomena, construction or
application domain through the model.
• Language (“wherewith”), with a careful selection of the carrier or cargo
that allows one to express the solution, the specification of the world or
the construction.
• Value (“worthiness”) of a model, by explicit statement of the internal and
external qualities, and the quality of use, e.g. explicit statement of
invariance properties relating the model to its associated worlds or by
preservation properties that are satisfied by the model in dependence on
the associated worlds.

General properties of models
• Mapping property: Each model has an origin and is based on a mapping
from the origin to the artifact.
• Truncation property: The model lacks some of the ascriptions made to the
original and thus functions as an Aristotelian model by abstraction of
irrelevant.
• Pragmatic property: The model use is only justified for particular model
users, tools of investigation, and period of time.
• Amplification property: Models use specific extensions which are not
observed for the original.
• Distortion property: Models are developed for improving the physical
world or for inclusion of visions of better reality.
• Idealization property: Modelling abstracts from reality by scoping the
model to the ideal state of affairs

A model that resumes the conceptual
modelling

Problems in models adoption
• Tool support
• MDE alignment with organizational & business goals
• MDA no enough to support rational and new challenges over models
• Lack of flexibility of models regarding external changes
• Social factors
• No model-driven processes
See more in
http://www.sciencedirect.com/science/article/pii/S0167642313000786 and
https://s3.amazonaws.com/oqmmleftechreports/ProS-OQMML-TR-2014-
01/ProS-OQMML-TR-2014-01.pdf

Thanks for your
attention
Questions?
Contact Info:
fdgiraldo@uniquindio.edu.co

Introduction to MDE

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (10)

Similar to Introduction to MDE

Similar to Introduction to MDE (20)

More from Fáber D. Giraldo

More from Fáber D. Giraldo (17)

Recently uploaded

Recently uploaded (20)

Introduction to MDE