introduction to mde

MDE IntroMaestría en Ingeniería – énfasis Ingeniería del Software

Fáber D. Giraldo [email protected]@pros.upv.es

In memory – Robert France

https://advancing.colostate.edu/ROBERTFRANCEFELLOWSHIP

• His paper on UML was honored with a 10-year MostInfluential Paper Award at the Model Driven Engineeringand Languages and Systems conference

• Co-founder of the Software and Systems Modeling Journal• Leader of ReMoDD

(http://www.cs.colostate.edu/remodd/v1/content/repository-model-driven-development-remodd-overview)

Sources

• Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-driven softwareengineering 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 ConceptualModeling, 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!!! =)

…and model-driven term X-(

History of Modelling LanguagesSource: 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 InformationSystems?

• 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 approachesare founded on three ideas: Direct representation, Automation and Standards.

• Direct representation allows a more direct coupling of problems to solutionswith the help of Domains Specific Languages (DSLs).

• Automations means that the facets represented in these DSLs are intended tobe processed by computer-based tools to bridge the semantic gap betweendomain concepts and implementation technologies and not only for meredocumentation.

• This should be complemented by the use of open standards that will allowtechnical solutions to interoperate

When Model-driven born ?

Source: Bézivin, J. (2006). Model Driven Engineering: An Emerging Technical Space. Generative and TransformationalTechniques 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 tointeroperability named MDA™ (Model-Driven Architecture).MDA is one example of the broader Model Driven Engineering(MDE) vision, encompassing many popular current researchtrends related to generative and transformational techniques insoftware engineering, system engineering, or data engineering.

Considering models as first class entities and any softwareartifact as a model or as a model element is one of the basicprinciples of MDE.

Before…


The OMG MDA initial proposal may be defined as therealization of MDE principles around a set of OMGstandards 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 theModel-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

ModelsWhat 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

MotivationWhat 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

MotivationWhy 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?

ConceptsPrinciples 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 methodologyNotations: 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

MotivationApplication 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

MotivationIncreasing abstraction in software development

The used artifacts of software developmentslowly converge to the concepts ofthe application area

Assembler (001001)

Assembler and mnemonicabbreviations (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 becauseitgoes 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 thefoundation of OMG's industry-standard environment wheremodels can be exported from oneapplication, imported intoanother, transported across a network, stored in a repositoryand then retrieved, rendered intodifferent formats (including XMI, OMG's XML-based standard format for model transmissionand 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 inwhich 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 LevelsCIM, 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

CIM, PIM and PSM

CIM – PIM – PSM mappings

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 asconceptual framework, which can provide the necessaryconcepts for modeling, documenting, presenting,managing, interchanging, and enacting developmentmethods and processes.

An implementation of this meta-model would be targeted atprocess engineers, project leads, project and programmanagers who are responsible for maintaining andimplementing processes for their development organizationsor individual projects.

SPEM Metamodel

CIMMDA Computation Independent Model (CIM)

E.g., business process

49

PIM MDA Platform Independent Model (PIM)

specification ofstructure and behaviourof a system, abstractedfrom technologicicaldetails

Using the UML(optional)

Abstraction of structur and behaviour of a system with the PIM simplifies thefollowing: Validation for correctness of the model Create implementations on different platforms Tool support during implementation

50

PSMMDA Platform Specific Model (PSM)

Specifies how the functionality described in the PIM isrealized on a certain platformUsing 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.phphttp://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 yourattention

Questions?

Contact Info:[email protected]

introduction to mde

Engineering

mda modeldriven

modeldriven architecture

modeldriven paradigm

interoperatewhen model

modeldriven term xhistory

software quality

mde mda

modelling languages