Towards a Basic Theory to Model: Model Driven Engineering


Published on

The integration of bodies of knowledge to build computer-based systems
is essential in order to successfully achieve the goals, set by researchers,
computer scientists and clients in general. In order to develop a bridge
of understanding among the di erent parts, two main approaches emerge:
MDA(Model-Driven Architecture) and MDE (Model-Driven Engineering).
As Favre [1] mentions, \MDE is not MDA. The MDA standard from the
OMG is just a speci c incarnation of the MDE approach".

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Towards a Basic Theory to Model: Model Driven Engineering

  1. 1. Towards a Basic Theory to Model: Model Driven Engineering Priscill Orue Esquivel September 8, 2012
  2. 2. IntroductionThe integration of bodies of knowledge to build computer-based systemsis essential in order to successfully achieve the goals, set by researchers,computer scientists and clients in general. In order to develop a bridgeof understanding among the different parts, two main approaches emerge:MDA(Model-Driven Architecture) and MDE (Model-Driven Engineering).As Favre [1] mentions, “MDE is not MDA. The MDA standard from theOMG is just a specific incarnation of the MDE approach”. This paper attempts to describe several concepts related to the MDEapproach: its core notions and how its theory is formed. The first sectionenumerates several background concepts, useful to grasp the work. Then,the theoretical foundations of MDE are explained in order to know its com-ponents. Finally, a deeper study of MDE is performed in the last section,with the strengths and weaknesses associated to the MDE approach. Tocarry out this report, secondary online sources were consulted to offer themost up-to-date information on the subject.0.1 Background conceptsThis section contains a set of definitions necessary to understand the con-text of the work. It does not intend to formalize concepts, but to offer abackground on the following topic. The first definition is about models. According to Favre [1], a model “isa simplification of a system built with an intended goal in mind”. The mainidea is that a model should answer questions related to the actual system.In this way, what it is stated theoretically in the paper reflects what isgoing on with reality. However, Favre [1] claims that some authors restricttheir definition of models; he cites Warmer and his colleagues: “A modelis a description of a (part of ) system written in a well-defined language.”For them, a “well-defined language” is a language including well-definedform (syntax), and meaning (semantics), which is suitable for automatedinterpretation by a computer. Technological spaces: they refer to a working context with a set of con-cepts related to each other, body of knowledge, tools, required skills, andpossibilities. Commonly, it is associated “to a given user community withshared know-how, educational support, common literature and even work-shop and conference meetings”. Moreover, it is considered a zone of “estab-lished expertise and ongoing research”, and a repository for resources, both 1
  3. 3. abstract and concrete [2]. The previous concepts form the topic of this work: MDE. Model-DrivenEngineering is an “open and integrative approach that embraces many otherTechnological Spaces (TS) in a uniform way”. Its main emphasis is placed ontechnological spaces, and the integration of bodies of knowledge developedby different research communities. In each space, the concepts of model,metamodel and transformation have different representations. For example,what is called a “metamodel” in Modelware corresponds to what is called a“schema” in Documentware, to a “grammar” in Grammarware, etc [1].0.2 Model-Driven Engineering theoretical founda- tionsThe very definition of model is unclear. According to Favre [1], “MDEexperts claim that models should be precise, but they just use plain Englishand informal drawings to define what is MDE”. UML diagrams were usedat first, but then discarded due to their informality and almost uselessness.However, the need to think about models, metamodels, transformations andhow they work together has not changed. Whenever intuition is not enough, a basic theory of MDE is necessary.This theory helps in reasoning not only in simple cases but when situationsbecome complex. The main approach to complexity is to apply simple andelementary concepts, and combine them into regular structures. For thisreason, the idea is to go back to the roots of Computer Science: the settheory and the language theory; then, a megamodel for MDE is going to beexplained [1].0.2.1 Elements from the set theory: Sets, Pairs, Relations and FunctionsThe concepts of interest for the megamodel are sets, pairs, relations whichare set of pairs, partial functions which are relations, and total functionswhich are partial functions, represented in 1. Though Favre [1] uses UML/OCLnotation, the concepts are not related to UML. “A set is a set, irrespectiveof the language it is expressed in.” Languages are used for notations, andit is avoided to mix the megamodel concepts with the ones coming fromthe language used. “For instance in the UML megamodel, the ∈ concept isrepresented as standard UML association named ElementOf, not the as thebuilt-in − >includes OCL expression.” 2
  4. 4. UML models should be tested in order to demostrate their utility in agiven context. According to Favre [1], this is the only way to get reasonableconfidence in a MDE megamodel. A model can be considered that it satisfiesneeds, until it “provides bad answers in a given situation”.0.2.2 Elements from the language theory: Languages, Pro- grams and Interpreters“The definitive language theory” does not exist. However, there are someconcepts applied when dealing with programming languages. A language isa set. For example, Java is the set of all java programs. “a”, “ab”, “abb”,“abbb”, “abbbb”, ... is the language of the strings that start with an “a”and then continue with some “b”. Languages are usually infinite and dueto this fact, “reasoning with these languages require to deal with models oflanguages”. Grammars constitute models of languages, but, they are notlanguages [1]. Programming languages are “languages of programs, that is sets of pro-grams, where each program is an executable model of a function”. It isimportant to remark that not all models of a given function are meant to beexecutable. For example, the “signature of a C function int power(int a, intb) is a model of that function, but it cannot be executed”. When a modelof a function is executable, this is called a program [1]. Interpreters are functions. “An interpreter function of a programming Figure 1: Set Theory Package 3
  5. 5. language is a function that takes a program with an input value and that re-turns an output value that corresponding to the result of the execution of theprogram.” Interpreter functions of a programming language L that allowsto describe programs that transforms Xs into Ys are therefore characterizedby the following pattern: (LxX) →→ Y [1].0.3 Model-Driven EngineeringIn this section deeper concepts about Model-Driven Engineering (MDE) areanalyzed. These concepts form the theory of MDE that it is explained inthe last part of the section.0.3.1 MDE PatternsThere are several patterns defined by Favre [1], to describe the performanceof MDE: • The meta-step pattern. The metamodel concept corresponds to a role played by a system in a MDE pattern coined meta-step. • A pattern of model transformation. One can distinguish transfor- mation instances (e.g. an XML file transformed into another XML file), transformation functions (e.g. a set of somehow related pairs), transformation models (a description of a function, also called trans- formation program if it is executable, e.g. a XSLT file), transformation modeling language or transformation programming language if it can be executed (e.g. XSLT), transformation metamodel (e.g. the DTD of XSLT) • The interpreter pattern. A transformation program is a transforma- tion model that can be executed.0.3.2 Megamodel infrastructureThe infrastructure of the megamodel, shown in 2, is totally technology de-pendent. The main package of the infrastructure includes several math-ematical entities, as special cases of Abstract Systems. Those systems areprocessed by human minds. The purpose of MDE is to build better computerprograms and better computer models. Those are called Digital Systems.These categories are not important; they are used to demostrate that theterm “System” includes a very wide range of artifacts [1]. 4
  6. 6. A system could be a complex entity, so it can be divided in many parts.“A system can play the role of model with respect to another system, whichthen plays the role of system under studies. This relation, called Represen-tationOf (µ for short), has been identified by many authors” [1]. Figure 2: MDE infrastructure Transformation is a key concept in MDE and it is based on the settheory because the concept of relation is a good abstraction for transforma-tions. Nevertheless, there is no agreement on what to call a transformation:its meaning depends on who is using it. One example describes the pack-age Transformation containing the concepts of TransformationInstance andTransformationFunction, like seen in 3. The figures about MDE infras-tructure 2 and Excerpt of Transformation 3 are related to each other “bythe fact that Pairs and Functions are AbstractSystems”. TransformationIn-stance is the application of a transformation to a particular input. On theother hand, TransformationFunctions are functions, and, as a result, sets ofTransformationInstances [1]. Figure 3: Excerpt of Transformation 5
  7. 7. 0.3.3 Megamodel superstructure and technological spacesThe two components of the megamodel: infrastructure and superstructurecontaining TSs-dependent megamodels are related to each other. The meg-amodel infrastructure is akin to an umbrella covering various technologicalspaces (TSs). However, defining the superstructure, which is modeling theTSs of interest, is not easy; whereas defining the mappings Infrastructure< − > TSs appears to be a promising approach. The most important ideais that: “showing how particular TSs could be integrated in the megamodelis also a very good point to communicate with other research communities,because the megamodel provides a concrete mean to establish terminologycorrespondences across TSs” [1].0.3.4 Towards a basic MDE theoryNow that all the necessary foundations are clear, the next step is to definethe theory supporting MDE. First of all, what is a Theory?. “A theory is away to deduce new statements about an SUS from the statements alreadyin some model of the SUS”. To achieve a theory, the relationship betweenmodels and metamodels with the theory has to be described. “A model isa set of statements about some system under study (SUS).” The model iscorrect if all its statements are true for the SUS. Then, “a metamodel is aspecification model for a class of SUS where each SUS in the class is itself avalid model expressed in a certain modeling language.” So, both terms canbe seen as part of a logical hierarchy conforming a MDE theory [3]. For Favre [1], the relationship between the megamodel and the theory forMDE is not evident with UML, but it is much more recognizable “with theProlog incarnation”. The Prolog DE megamodel is an executable program.It has the ability to deduce new facts about a particular MDE situation, likethe one modelled on the left of the figure 4. “The excerpt of the megamodelin the center shows the translation the meta-step pattern presented before.The power of Prolog can be used to ask questions and get answers (right ofFigure 4)”.0.3.5 Discussion and final analysisFor Favre [1], to build a good model for MDE is a complex research issue.Nevertheless, the approach of introducing concepts incrementally, “trying ateach step to add only truly essential concepts”, has provided good results.At each step, there is a lot of attention on developing examples either fromcomputer technology or the real world to check the validity of the theory. 6
  8. 8. MDE needs refinement. One of the concepts that should be enforced isconformance, which Techopedia [4] defines as: “the degree of adherence topreset expectations. The degree to which a product meets its prespecifiedcriteria is termed as conformance in the context of software engineering.”Including the notion of conformance requires other concepts like syntax,semantics, etc. Another “important requirement during the design of themegamodel is to give the ability to extend it to suit the needs of particulartechnological spaces.” Moreover, the notion of platform is still in doubt,whether to include it or not in the megamodel. For these reasons, moreresearch is needed [1].ConclusionThis work has presented several concepts about the formation of the theoryof Model-Driven Enginnering (MDE). Precise modeling is an ideal goal, butmost of MDE is described with pictures and informal sketches. As seenin the examples, UML diagrams includes most of the relevant informationabout a context but they fail to give all the answers. As Favre [1] points out, “a design which is not tested will invariably bethrown away, sooner or later.” Complex technologies are to be added on topof already complex technology layers. A suggestion is to learn from the pastand identify the Technological Spaces required to integrate various bodiesof knowledge. Moreover, a set of MDE concepts should be agreed upon andlet them be known to future researchers on the area. “The set theory andlanguage theory are parts of the lingua franca in Computer Science, so usingthese concepts can greatly help in identifying bridges with existing TSs.” The main goal of any model is to connect ideas with the real world. Themegamodel detailed in this work deals with a lot concepts, but still needsto take into account several aspects in order to form a complete and logicaltheory of MDE. A good strategy towards this goal is to set the definition Figure 4: Automated reasoning about MDE 7
  9. 9. of core concepts, like models and megamodels, in a definite way, so futurework can be developed based on these definitions. 8
  10. 10. Bibliography[1] Favre, J.-M. (2004) : In Workshop on Software Model Engineering, WISME 2004, joint event with UML2004.[2] Ivan Kurtev, Jean Bzivin, M. A. (2002) In Industrial Track, (ed.), In- ternational Conference on Cooperative Information Systems (CoopIS), : .[3] Seidewitz, E. (2003) IEEE Explore 20(5), 26 – 32 Web; accedido 25- Abr-2012.[4] Techopedia Conformance 14194/conformance (2012) Sitio Web; accedido 26-Abr-2012. 9