Post on 14-Jul-2015
MDE IntroMaestría en Ingeniería – énfasis Ingeniería del Software
Fáber D. Giraldo -fdgiraldo@uniquindio.edu.cofdgiraldo@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…
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.
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)
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.
Model-driven (III)
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.
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
SPEM
SPEM
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:fdgiraldo@uniquindio.edu.co