Software development methodology model

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Abstract-The most prefered primary techniques used in software development methodology based on model-driven approach is a model transformation. The model transformation is a generation process made from one model to the other model(s) using a well-defined transformation process. The use of bidirectional model transformation (BMT) is extremely useful in software develepment although some terms are required at infancy stage. To achieve the full benefit of BMT several requirements are needed such as formal modeling and formal transformation definition technique. In this research, the use of a UML class diagram is considered as a diagrammatic specification which is formalized into first-order logic as one of logic techniques based on mathematical notation. The formalization result is considered as an input to the model transformation in order to get the effective implementation of BMT.

Keywords-component; model driven development; model transformation; bidirectional transformation; graph-based; first-order predicate logic; unified modeling language

I. Introduction and motivation

The use of model and model transformation are a central artifact in software development process. A model can depict the complexity of a system and provide the structure for problem solving in software engineering field. Basically, a model cannot be executed, but with the help of language modeling, a model can be executed and generated automatically using a well-defined transformation process, and it is also an input in model transformation process. One of the main strengths in model driven development (MDD) is model transformation [1] that is standardized by the Object management Group (OMG) as Model-driven Architecture (MDA).

In MDA, model transformation is defined as a generation process of one model from the other models. Transformation process is specified by transformation definition language which consists of transformation rules and it is executed by transformation tools [2]. Transformation process can be performed into two ways, either unidirectional transformation or bidirectional transformation. In practice, unidirectional transformation is not desirable for a number of reasons [3], such as when one model is modified, then the modified model cannot be automatically reflected back to the original model, and this transformation leads to inconsistency problem. Currently, transformation process is required to be defined in both directions which is called as bidirectional model transformation or BMT in shortly [4].

Researchers from many different areas including software engineering, programming languages, databases, and document engineering are actively investigating the use of BMT to solve a various set of problems. This fact indicates that BMT is extremely required, although it is still at infancy stage. In the last years, there are some proposed techniques by the software engineering (SE) community to develop the BMT in term of approaches, languages and tools. Unfortunately, most of them are defined informally, less proper semantic, insufficient in formalization or complicated [5]. To remedy this problem, BMT is required to defined formally in area of modeling and transformation in order to obtain some goals such as it is easy decomposition, flexible to integrate with other techniques, enable to construct the verification, and easy to go through the validation process [2].

In order to achieve validation of BMT as the objective of research, then this research is divided into several part of mechanism as follows: a class diagram of formalization, a Relational Data Base (RDB) formalization, a concept of two formalization of transformation rules, the mapping definition of BMT by the formalization result, controlling the transformation process, evaluation of BMT process by an industrial strength case study. This research also aims to describe the formalization of UML class diagram in term of formal logics such as the First-order logic (FOL) as a starting step toward validation of BMT.

Section 2 of this paper describes the related work consist of the current approaches of bidirectional model transformation (i.e. graph-based and graph grammar approach, relational approach and hybrid approach) and the diagrammatic software specification is briefly presented. Section 3 presents the motivation of the research. Section 4 discusses the proposed approach which depicts the basic conceptual framework for formalization of two diagrammatic specifications and presents the UML class diagram formalization. Finally, section 5 discusses conclusion and future work.

II. related works

A. Bidirectional Model Transformation (BMT)

The various field of software development such as synchronization, round-trip engineering, software evolution and reverse engineering use BMT as fundamental concept to increase their ability [6]. A BMT is defined as a pair of transformation function that has a forward and backward transformation. In simplify, a forward transformation is described as a transformation process from a source model to a target model, whereas a backward transformation is a transformation process from a target model to a source model. There are a number approaches like QVT-R [3], BOTL [7], IMPROVE [8] and TGG [9] to be addressed to the BMT definition. Most of them unfortunately are defined informal, less proper semantic and explicitly inconsistence. In addition, BMT is written in two separate transformations (or non-bijective) which makes the effort to maintain BMT formally is difficult and contains error prone. According to OMG [10], a BMT is called bijective transformation, if this transformation can be executed in both direction and there is an inverse existed. Some approaches are often used to describe BMT are identified as below:

1) Graph-grammar and Graph transformation approach

Most the transformation process is depicted graphically. Graphs and diagrams are worthwhile to visualize their complex structures of systems and to model concepts and ideas in natural language and intuitive way. In particular, they provide a simple and powerful approach to a various problems that are typical to software engineering. If graphs define the structure of these models, graph transformation can be exploited to specify both how they should be built and how they can evolve. Although, the established foundation and the applications of graphs and graph transformations are available, the formal and conceptual knowledge are not widely spread among software engineers. Frequently, this leads to ad-hoc solutions to problems that are already well understood in a more general context.

Schurr [11] introduced a Triple Graph Grammar (TGG) as a special technique for the specification and execution of bidirectional transformations in declarative way. TGGs were motivated by integration problems between different tools where interrelated documents have to be kept consistent with each other. TGGs are a graph that evolves by applying graph grammar rules. The fundamental concept of TGG consist of three graph that is a left hand side (LHS) as source graph, correspondence graph, a right hand side (RHS) as target graph. The main idea of TGG is to relate two models between a source model and a target model by some correspondence graph which is mapped to both models. The examples for model transformation approaches based on graph grammars and graph transformation include Viatra [12], GreAT [13], AGG [14], Progres [15], and Fujaba [16]. Most of them do not discuss about BMT and consistency problem does not define explicitly.

2) Relational Approach

The main concept of relational approach is mathematical relation that can be seen as a form of constraint solving. Relational approach specifies the relation among source model and target model using constraint in declarative approach. By declarative constraint, the semantic of relation approach can be executed using logic programming. In logic programming, a predicate can be used to describe the relations. All the relational approaches are side-effect-free and can naturally support multidirectional rules. One of examples of relational approaches is Query View Transformation Relation (QVT-R). QVT-R is a relational language standard which is introduce by OMG [10]. The consistency relation and transformation in both directions are described using a single text [17]. The current research uses QVT-R for writing BMT in non-bijective transformation. This research means that a backward transformation should not defined as an inverse of forward transformation and this research does not provide a formal semantic of QVT and a result of mathematically prove of QVT expressiveness.

3) Hybrid Approach

This approach combines different techniques from the existing approaches. The different approaches can be combined as separate components at the level of individual rules. Diskin [18] combines the relational approach and algebraic approach to define the semantic of bidirectional model transformation and synchronization. Hidaka et al. [19] proposes a novel algebraic framework for BMT by integrating the state-of-the-art technologies on bidirectional tree transformation and algebraic graph querying. This research makes a significant extension from bidirectional tree transformation to bidirectional graph transformation and gives a powerful automatic to derive a backward transformation from a forward transformation. However, the existing of hybrid approach in writing BMT is defined in non-bijective and the checking consistency (or the consistency verification) does not be involved. Another example of hybrid approach, in reference [2, 5] combine a Graph Theory (GT) and Category Theory (CT) which are mathematically diagrammatic notations. This approach is called a Diagrammatic Predicate Logic (DPL). Most of the existing languages used to write and execute the transformation rely on the Object Constraint Language (OCL) for the definition of model transformation, since the increasing modeling language in software development tends to use a diagrammatic syntax for the specification of models. DPL is a graph-based specification format that borrows the ideas from both categorical and first-order logic (FOL). From the literature perspective, DPL approach is a suitable specification for formalization of model transformation. This research adopts and exploits the theory to write the diagrammatic specification of BMT, which has not been definet yet in previous research.

B. Diagrammatic Software Specification

Diagrammatic modeling language (DML) [2] is a promising approach for modeling software system due to the following reasons: being a graph-based, its syntax and semantic can be clearly defined in the systematic ways. DML is not new in software engineering. It was firstly introduced as Generalized Sketches (GS) by [20]. DML depict a system using graph or diagram. The graphical manner is often used to specify the specification of input model due to its simplicity and universality, but it is weak in de-composition. Simplicity means that it is easy to understand and universal means that people who have the different background can be involved in the discussion of software architecture as long as a consistent graph notation is used [2].

To achieve a better modeling language as a graph-based, formalized with a strong mathematical foundation, the Diagrammatic Software Specification (DSS) [21, 22] can be considered in BMT. Rutle et al. [2] combines a graph-based approach and first-order logic i.e. predicate logic which is called diagrammatic predicate logic (DPL) defining the model transformation. In DPL, a diagrammatic specification is used to describe a software model.

UML is widely used as a standard object-oriented modeling language in software model [23], which is supported by a number of CASE tools. Restrictiveness of UML in its own syntax and semantic which makes UML is often combined with OCL, since OCL is a part of UML that can be used as a specification formalism to define the platform independent models (PIMs). From a formal point of view the usage of OCL constraint makes reasoning on class diagram undecidable. To remedy this problem, the UML OCL is defined into FOL assertion.

III. Motivation

Bidirectional transformation can be described in a mean of non-bijective and bijective. Non-bijcetive means that bidirectional transformation is written in the two separate unidirectional transformations. This way has some drawback such as consistency between two transformation function is held manually and error-prone [2]. Furthermore, if one of two models is modified or both, the modified models must be able to reflect back to the original source or target model to preserve the definition of the relationship between two models.

To achieve the full benefit of BMT, it is needed to be defined formally i.e. modeling and transformation. For formalization of BMT, a diagrammatic approach is used to constitute a combination approach between a graph-based and first-order logic. These approach is considered because graph-based is easy to view a system and easy to understand than text-based version and it is spported with the sound of mathematical foundation so it makes the transformation result easy to verify. UML class diagram is considered as diagrammatic specification due to it is the richest notation of UML. As the first step toward validation of BMT, UML Class Diagram is formalized using first-order logic as one of thechniques based on mathematical foundation.

IV. the proposed approach

In this section, the proposed approach is presented. First, the basic concept of model transformation as the formalism framework is presented, then, the brief review of the fundamental concept modeling in the propose framework is described and at last of this section the framework to defined BMT is applied.

A. The Basic Concept of Model Transformation

Figure 1 below illustrates the idea of model transformation according to MDA. In fact, a model transformation is composed of translating a source model that conforms to a source metamodel by a well-known transformation engine into a target model which conforms to a target metamodel. The transformation engine is generated by the use specified of transformation rules that explicitly defines a mapping between the two metamodels. The mapping definitions between two metamodels are held by the user. A mapping is used to describe how two metamodels are connected. As a note that defining a mapping is not trivial task.

In MDA, the transformation process is automatically executed by transformation tools and it is described by transformation definition that consists of the transformation rules. A set of rule is used transformation definition to construct a source model or a target model satisfies to their metamodel. There are four steps to built a model transformation [24] as follows: (i) Modeling the source and target metamodel, (ii) Specifying the mapping between two metamodels, (iii) Generating the transformation rules, (iii) Generating the transformation engine whose execution the transformation process from one model into other models.

B. The Formalization Framework

The formalization of BMT is based on formal diagrammatic that takes advantages from both a conceptual modeling diagram (UML) and FOL. By using logic in BMT, formalization is basically considered as a set of reason as follow: a given precise semantics, formal verification, and virtually unlimited expressiveness. These combinations will useful to support in some tasks such as delegating formal semantics to constructs of the conceptual design diagrams, using conceptual design diagrams as usual, taking advantage of methodologies developed in Software Engineering, reading diagrams as logical theories for formal understanding, verification, automated reasoning. UML Class diagram is depicted as the diagrammatic specifications as it is shown in figure 2.

One of the most prominent diagrams of UML is UML class diagram as source metamodel or as domain. UML class diagram consists of several essential elements: feature i.e. attribute and operation, classes, and relationship between classes as well as sub-classes i.e. association, inheritance and composition.

Figure 3 presents UML Class Diagram and Relational Data Base (RDB) metamodel that is formalized in first-order logic. First-Order Logic (FOL) is to formally capture semantics and reasoning, Description Logic to understand the computational properties of reasoning. FOL is a set of string-based language. To make it is easier to understand, FOL must be combined with a diagram in a precise diagrammatic specification. In this paper, two models correspond to each other by a relation. The expression of a relation is a logic programming in transformation process. A graphic presentation provided in this relation is based on the graph-transformation theory.

C. Semantic Definition of Class Diagram

UML class diagram depicts a structural aspect of the model of a system and shows what conceptual 'things' exist in a system, and what relationships exist among them. UML class diagram is a graphical representation of static view on declarative static element. In this section, the Class Diagram (CD) formalization for the syntactic structure as below:

1) Classes

A class is a main block of UML class diagram which is used to store and manage information. Each class is depicted using three part rectangles with class' name at the top, attributes in the middle, and operation at the bottom (see figure 4). A class in UML model represent a set of objects or its instance in which the objects belong to a class are called instances of the class which form instantiation or extension of the class. Based on the above description that a class is generally composed in the form of where:

  • is class name, the class name has to be unique in the whole diagram.
  • is a set of attribute name of the class, for i=1..n.
  • is a set of attribute type of the class, for j=1...n.
  • is a set of operations of a class, for i=1..n

2) Attribute

Attributes represent properties of a class that describe the state of an object. It has attributes name and type ttribute name must be unique only in the class it belongs to, possibly multiplicity (i.e. implicit or explicit). Implicit multiplicity is assume to be 1..1 (i.e the attribute is mandatory and single value), and an explicit multiplicity with a minimal and maximal number of value e.g. 1..*. Let be an attribute of a class with type, an optional multiplicity and binary predicate of attribute then assertion for is formalized as:, where: C(x) is a Class's name, is an attribute's name and an attribute's type, is an attribute's type.

Multiplicity is a constraint on the number of instances of one class that can be related to one instance of the other class. An assertion for multiplicity states that for a associated to each instances of, at least i and most j instances C'. It is stated such. For example by refer to Figure 4, it is possible to write:

3) Operation

Operation is actions or functions from the object of class to which the operation is associated. Both of the operations are followed by parentheses that consists of parameter(s) are needed. If an operation has no parameter(s), the parentheses are still shown but are empty. In generally, operations have names and parameters (has a name and a type). An operation of a class can be stated by mean of FOL relation such:

4) Assocation and Agregation

A relationship between two or more classes, (or a class and itself) in UML class diagram is represented by an association. An association is labeled using a verb phrase or a role name that described properties of the association (e.g. attribute, operation and others). In UML, an association is a relation between instances of two or more classes as shown in figure 5(a). An association between two classes is a property of both classes.

5) Generalization and Inheritance

In UML, generalization depicts that one class (subclass) inherits form other class (super class or base class). It means that the properties and operation of the super class are also valid for objects of the subclass. Note that every instance of each subclass is also instance of the super class. If an UML class generalizes a class C1, we can express this in FOL assertion: or Ê means every properties of are also the properties of but. Generalization in UML can be grouped into a class hierarchy, as shown in figure 7.

6) Constraint

Constraint (i.e.disjoint and complete) can be added in UML' class hierarchy as additional properties of a class, between each child classes and parent class. Disjointness is a condition where the different subclasses cannot have common instance which is stated in FOL assertion as follows:

Whilst, completeness is every instances of super class is also instance of at least one of the subclasses which is defined in FOL assertion as follow:

7) Composition

Composition is a strong form of aggregation that can be defined as an instance of a class becomes a part of other instance of a class. It means that sometimes an object is made up of other object which is depicted with a fulfill diamond. FOL assertion is stated as follow: (x)

D. A Simple Example

In this section, a simple example (see Figure 8) to illustrate the whole formalization. In Class Diagram, there are six classes (i.e. Student(x), Undergrade(x), Graduate(x), Class(x), Lecturer(x), and Course(x)) and one generalization which can be stated in three assertion as follow:

Figure 8. A simple example of UML Class Diagram Definition of properties of Student's class capture attributes and operation as follows: ; ; ; ; The same manner defines attributes and operations for each other class. Association of both classes between student's class and class's class are depicted as follow (the same manner of other classes): ;.

V. conclusion and future work

In this paper, the state-of-the-art BMT approaches and study the actual research of modeling and model transformation on MDA and MDA-related standard approaches are discussed. The formalization ideas of a model transformation development process are sketched. The technique of model transformation is based on the use of the concept of graph-based and first-order logic. The combination of these approaches is possible to formalize the specification of UML class diagram. As first step toward validation of bidirectional model transformation. In this paper, it is shown how to define UML class diagram into first-order logic. This work provides support during the specification phase of software development for BMT.

The formalization in FOL of UML class diagram, some properties can be captured by the formalization in FOL. This represents a significant improvement as a first step toward validation of BMT. In the future work, the RDB metamodel will be formalized into first order logic and define the mapping process between UML class diagram and RDB to execute by transformation rules in BMT process. BMT process will be implemented and evaluated using industrial strength case study.

VI. Acknowledgment

This research is partially funded by Indonesian government's higher education department. The authors would like to convey their utmost appreciation to the anonymous reviewer and respective individuals for their involvement and invaluable feedbacks throughout conducting this research


  1. Object Management Group (OMG). MDA Guide Version 1.0.1 (pmg/2003-06-01),OMG. 2003.
  2. Rutle, A., U. Wolter, and Y. Lamo. A Diagramatic Approach to Model Transformations. in EATIS'8. 2008. Aracaju, Brazil: ACM 2008.
  3. Stevens, P., Bidirectional model transformation in QVT: semantic issues and open questions. Software and Systems Modeling, 2008. 9: p. 7-20.
  4. Matsuda, K., et al. Bidirectional transformation based on automatic derivation of view complement functions. in 10th MoDELS of Lecture Notes in Computer Science. 2007: Springer.
  5. Rulte, A., U. Wolter, and Y. Lamo, A Formal Approach to Modeling and Model Transformations in Software Engineering., in Technical Report 48. 2008, Department of Informatics, University of Turku: Finland.
  6. Hidaka S., et al., Toward a compositional approach to model transformation for software development, in 24th Annual ACM Symposium on Applied Computing (SAC 2009). 2009.
  7. Braun, P. and F. Marschall, Transforming object oriented model with BOTL. Electronic Notes in Theoritical Computer Science, 2003. 72(3).
  8. Becker and Westfechtel, Incremental Integration Tools for Chemical Enginnering: An Industrial Application of Triple Graph Grammars, in 29th intl. Workshop Graph-Theoretic Concept in Computer Science. 2003, LNCS. p. 46-57.
  9. Konigs, A. and A. Schurr. Tool Integration with Triple Graph Grammars - A Survey. in Proceedings of the segraVis School on Foundation of Visual Modeling Techniques. 2006. Amsterdam: Elsevier Science Publ.
  10. OMG. MOF2.0 query/view/transformation (QVT) adopted specification. OMG document ptc/05-11-01, available from 2005.
  11. Schurr, A., Specification of Graph Translators with Triple Graph Grammars, in WG94 20th Int. Workshop on Graph Teorretic Concept in Computer Science, G. Tinhofer, Editor. 1994, Springer Verlag: Heidelberg. p. 151-163.
  12. Varró, D., G. Varró, and A. Pataricza. Designing the automatic transformation of visual languages. in Science of Computer Programming. 2002.
  13. Vizhanyo, A., A. Agrawal, and F. Shi. Towards generation of efficient transformations in Proceedings of the Third International Conference (GPCE) :Generative Programming andComponent Engineering. 2004. Vancouver, Canada: Springer, Berlin.
  14. Ermel, C., M. Rudolf, and G. Taentzer, eds. The AGG approach: language and environment. Handbook of Graph Grammars and Computing By Graph Transformation, ed. H. Ehrig, et al. Vol. 2. 1999, World Scientific Publishing Co., River Edge, NJ. 551-603.
  15. Schürr, A., A.J. Winter, and A.I.e. Zündorf, vol. 2:, pp. 487-550. (1999), eds. The PROGRES approach: language and environment. Handbook of Graph Grammars and Computing By Graph Transformation, ed. H. Ehrig, et al. Vol. 2 : Applications, Languages, and Tools. 1999, World Scientific Publishing Co., River Edge, NJ. 487-550.
  16. University of Paderborn, Germany. Fujaba Tool Suite. Online at
  17. Stevens, P. A Landscape of Bidirectional Model Transformation. in GTTSE 2007. 2008: Springer-Verlag Berlin Heidelberg.
  18. Diskin, Z., Algebraic Model for Bidirectional Model Syncrinization, in MoDELS 2008, LNCS 5301, K. Czarnecki, Editor. 2008, Springer-Verlag Berlin Heidelberg. p. 21-36.
  20. Diskin, Z., Genarlize Sketches as an Algebraic Graph-based Framework for Semantic Modeling and Database Design, in Technical Report. 1997, University of Latvia.
  21. Wolter, U. and Z. Diskin. Generalized Sketches: Towards a Universal Logic for Diagrammatic Modeling in Software Engineering. in ACCAT 2007, ENTCS, Accepted for publication. 2008.
  22. Wolter, U. and Z. Diskin, The Next Hundred Diagrammatic Specification Techniques: A Gentle Intrduction to Generalized Sketches, in Technical Report 358. July 2007, Dept of Informatics: University of Bergen.
  23. Diskin, Z. Visualization vs: Specification in Diagrammatic Notation: A Case Study with the UML. in Diagram 2002, LNAI 2317. 2002: Springer-Verlag Berlin Heidelberg.
  24. Deba, E. and P. Bazex, Mapping in Model Engineering, in First European Workshop in Model Transformation (EWMT 2005). September 26 2005: Rennes, Frances.
  25. OMG, Request for Proposal: MOF 2.0 Query/Views/Transformations RFP 2002.