An Introduction to MDE - PDF Free Download

An Introduction to MDE Alfonso Pierantonio Dipartimento di Informatica Università degli Studi dell Aquila alfonso@di.univaq.it.

Outline 2 2» Introduction» What is a Model?» Model Driven Engineering Metamodeling Model Transformation MDE Deployments» Domain Specific Languages» DSLs vs UML» MDD and Embedded Systems» Conclusions

What is a Model?» A simplification of a system built with an intended goal in mind. The model should be able to answer questions in place of the actual system [Bézivin et al 2001]» A set of a statements about a system under study [Seidewitz 2003] 3 3

What is a Model?» A coherent set of formal elements describing something built for some purpose that is amenable to a particular form of analysis [Mellor et al 2003] 4 4

What is a Model?» A description or specification of that system and its environment for some certain purpose. A model is often presented as a combination of drawings and text. [MDA Guide 2003] 5 5

What is a Model?» In our opinion these formulations do not conflict but rather complement one another. A model has a purpose A model is an abstraction, it does not describe details of the entity that are not of interest to the audience of the model 6 6

12 1 2

13 1 3

Model Driven Engineering (MDE)» Designers can greatly benefit from leveraging the abstraction level by means of models in order to understand complex problems and their potential solutions» Models are artifacts that are understood by computers and manipulated through some form of automation to bridge different abstraction layers» Development by means of models defined with concepts that are much closer to the problem domain rather than to the underlying technologies 14 1 4

Model Driven Engineering (MDE)» The focus is shifted from coding to modeling: everything is a model paradigm [Bézivin 2005]» MDE is based on a conceptual infrastructure which consists at least of models, a metamodeling architecture, and model transformations.» Model algebras: operations, weaving, compare, differencing, evolution, conflicts, etc. 15 1 5

Metamodeling» It is a technique for defining the abstract syntax of models and the interrelationships between concepts within a domain 16 1 6 Meta Level MOF terms Examples M3 Metametamodel MOF models M2 M1 Metametadata, metamodel Metadata, model UML Metamodel, UML profiles UML Models (eg. Class diagrams) M0 Data Modeled systems

Metamodeling» It is a technique for defining the abstract syntax of models and the interrelationships between concepts within a domain 17 1 7 Meta Level MOF terms Examples M3 Metametamodel MOF models M2 M1 Metametadata, metamodel Metadata, model UML Metamodel, UML profiles UML Models (eg. Class diagrams) M0 Data Modeled systems

Metamodeling 18 1 8

Model Transformation» A model transformation is the automatic generation of a target model from a source model. 19 1 9» Different approaches Model to model, a model is derived from another model > Transformation languages: QVT, ATL, VIATRA, etc. Model to text, a textual artifact is derived from a model using templating techniques > Transformation approaches: Acceleo, JET, AndroMDA, etc Other approaches may include executable models > Action Semantics, Kennedy&Carter iuml, Xactium XMF

M2M Transformation 20 2 0 Meta Metamodel conformsto conformsto conformsto Transformation Laguage conformsto Source Metamodel from Transformation Rules to Target Metamodel conformsto exec conformsto Source Model source Transformation Engine target Target Model

MDE deployments» Model Driven Architecture (MDA) MDA is an effort defined by OMG around industrial standards, such as MOF, UML, QVT, etc.» Eclipse Modeling Framework (EMF) EMF project is a modeling framework and code generation facility for building tools and other applications based on a structured data model.» Software Factories Initiative (SFI) A Software Factory is a software product line that configures extensible development tools DSLs for building specific kinds of applications. 21 2 1

MDE deployments 22 2 2 Metamodeling M2M M2C MDA MOF/UML QVT Model to text RFP EMF Ecore ATL, VIATRA2 JET, Acceleo, etc. SFI DSL Tools X Text Templates

Domain Specific Languages (DSLs)» Small, highly focused languages for solving clearly identifiable problems within crispy boundaries» The development of DSLs is an intensive activity which requires skills and expertise which are beyond tools being used In fact, a prerequisite is the deep knowledge of the application domain which requires to be analyzed and engineered The domain engineering leads to an encapsulation accomplished by means of metamodels» Plenty of DSL are available since ever 23 2 3

UML vs DSLs» Depending on the framework, modeling is done by using UML/profiles or by defining metamodels/dsls.» These are two paradigmatic approaches which may have a very different impact on software development UML may be chosen also for historical reasons, eg. because of the existence of tools devoted to analyses Interoperability between UML and DSLs is sometimes necessary, eg. to perform at an early stage of development analysis which may lead to better software 24 2 4

UML vs DSLs 25 2 5 small artifacts, individual skills complex artifacts, more formal processes, established domains costs MDA UML Modeling Introducing UML at this level is too expensive and model-to-text the return is often unsatisfactory Granularity is too fine grained, ie. at the same level of programming Behavioral description are part of the model Designers are required to gain almost complete knowledge of UML model-to-model complexity

UML vs DSLs 26 2 6 small artifacts, individual skills complex artifacts, more formal processes, established domains costs Introducing a domain-specific formalism (ie. model-to-text a metamodel) has a convenient cognitive impedance MDA Designers already know the semantics of the domain, thus also the semantics of the Meta Model UML Modeling model-to-model complexity

UML vs DSLs 27 2 7 small artifacts, individual skills complex artifacts, more formal processes, established domains costs MDA UML Modeling model-to-text model-to-model Too Source big abstraction and target metamodels difference have between to be decided the PIM in and advance, code more Transformations formality are very complex and difficult Easier code to maintain generation due by to chaining the abstraction model-to-model jump and model-to-code ad-hoc transformations transformation design Metamodels are consequently difficult to maintain, because transformations are tailored on them model-to-text model-to-model complexity

A few considerations» Most of UML approaches does not generate business rules, but just code schemata, up to 70 90% of code lines (but less value)» How to improve it? By controlling the whole language process Designing a specific metamodel which has to be tailored over the application domain is crucial Adopting a model to model transformation language which offers usability and enough pragmatic qualities but also rigor Composition mechanisms, it should be possible to adapt, extend, modify and combine source metamodels and consequently the transformation programs 28 2 8

MDD and Embedded System» Product Line Architectures (PLA) have been already adopted in the area of embedded systems they permit conditional code generation by means of feature diagrams 30 3 0

MDD and Embedded System» DSLs can be viewed as PLA where the features are described by means of an abstract syntax and not only by simple feature diagrams» DSLs can deploy the same application on several hardware platforms» iuml showed a certain effectiveness in this respect, ie. multi hardware code generation Multiplatform digital radio software F17 cockpit software» Interpretation of models can be also an option in case awareness and system reconfiguration are required 31 3 1

MDD and Embedded Systems» University of Berkeley Giotto, HyTech, Mocha, POLIS, etc.» University of Vanderbilt Generic Modeling Environment (GME)» IBM Corporation / Rational Software» Telelogic Rational Rose Developer (Formerly known as Rational Rose Real Time) Rhapsody: UML Model Driven Development» Kennedy Carter Ltd. Target Architecture 5 Code Generator 32 3 2

Conclusions» The principle everything is a model allows to deal with any kind of entity at any level of abstraction using standard tools» Model are not semantics, but are more than just syntax, eg. lessical vs design based conflicts» Embedded systems usually are defined over a welldefined domain which let appear the DSLs as very appealing 33 3 3

MDD at University of L Aquila» The work which has been done refers to the following research directions > Model Transformation and Weaving > Model Difference Representation > Change Propagation» Different formalism for the specification and the implementation of model operations, i.e. > Abstract State Machines and > Answer Set Programming» A lightweight MDD approach has been defined for data intensive web applications > becontent http://www.becontent.org 34 3 4