• Abstract and Figures
• Public Full-text

Masaryk University Faculty of Informatics MASTER'S THESIS Matej Jakab The problem of model-code consistency and Model Driven Development Supervisor: Ing. RNDr. Barbora B¨uhnov´a,Ph.D. Study program: Informatics Field of study: Information systems 2012 Acknowledgements: I would like to thank my supervisor Ing. RNDr. Barbora B¨uhnov´a,Ph.D., for intensive discussions and guidance for my thesis to the right direction. Special thanks go to my sister and girlfriend who supported me in various ways. I declare that I have worked on this thesis independently using only the sources listed in the bibliography. All resources, sources, and literature, which I used in preparing or I drew on them, I quote in the thesis properly with stating the full reference to the source. In Brno, Matej Jakab Abstrakt: Pr´aceje zamˇeˇren´ana udrˇzen´ıkonzistence medzi modelem a k´odem pomoc´ıMDD. Pr´aceanalyzuje existuj´ıc´ın´astroje, kter´etento probl´emˇreˇs´ı. Na kombinaci n´astroj˚udemonstruje funkˇcnost. Na z´avˇerzhrnuje nadobud- nut´evˇedomostia porovn´an´ızobrazuje v tabulk´ach. Kl´ıˇcov´aslova: Model driven development, code engineering, reverse en- gineering, transformace modelu, konzistence modelu a k´odu,IDE Abstract: The thesis is focused on maintaining the consistency between a source code and a model with the help of MDD. The thesis analyses existing tools that are capable of dealing with this issue. On the best combination of such a tools, demonstration is introduced. Finally the knowledge gained is listed and the evaluation of tools is displayed in tables. Keywords: Model driven development, code engineering, reverse engi- neering, model transformation, model code consistency, IDE Contents Introduction 6 1 Model Driven Development 9 1.1 Definition . .9 1.2 Model Transformation . 11 2 Categorisation 13 3 Platform Specific Category 17 3.1 Eclipse . 17 3.2 Visual Studio . 20 4 Platform Independent Category 24 4.1 NetBeans . 24 4.2 Altova . 28 4.3 StarUML . 31 4.4 OpenAmeos . 34 4.5 VisualParadigm . 37 4.6 EnterpriseArchitect . 41 4.7 OtimalJ . 45 4.8 Rational Rose . 46 5 Demonstration 48 6 Discussion 55 6.1 Ideal Tool . 55 6.2 Final comparison . 57 3 CONTENTS 5 Conclusion 61 Bibliography 61 Appendix 64 Introduction Motivation The model consistency problem is caused by an absence of automated func- tions within modelling tools, that maintain consistency when changes to one model are made. Even if a system is in a consistent state, the risk that after many changes implemented during the project's lifetime the consistency is violated, is real. In the case, when the source code is present at the beginning of the project, consistency may be an issue right from the start of the project. The source code may be looked at as a model on the lowest level with zero rate of abstraction. The consistency with a model constructed with one level higher abstraction rate needs to be maintained. This is the area that this thesis is focusing on. There is no need for a tool that helps representing source code. However, one for representation of the model with some rate of an abstraction is needed. The best instrument to do so is Unified Modelling Language (UML). Aim The aim of this thesis is to find methods and tools that are able to solve the problem of consistency between a source code and a model, represented as UML diagram. There are many tools available nowadays. However, their functionality, correctness and robustness needs to be analysed. A tool with full and robust functionality in this matter is not likely to be found. Never- theless, satisfactory result can be achieved by applying combination of several tools. 6 CONTENTS 7 Model consistency There are several approaches on how to solve the issue of model consistency. In the thesis of Kim Mens [11] the solution for the problem of maintaining the consistency between a software architecture and the corresponding source code using a logic programming language is introduced. Even though the algorithm is correct, it turned to be inefficient. Even more disturbing is the fact, that a full-fledged programming language is used. Therefore there is no guarantee concerning the decidability or completeness of the consistency algorithm. [18]. Another solution is offered by Tom Mens, Ragnhild Van Der Straeten, and Jocelyn Simmonds [18]. They split the consistency problem into two cases. The first one is caused by the fact, that the design may be inter- nally inconsistent or incomplete. The other one, is caused by the source code being "out of sync". Their approach to the problem is based on the use of description logic (DL). DL is an appropriate formal tool for solving consistency issue, due to the fact that DL contains five reasoning tasks that achieve the consistency. There are subsumption, instance checking, relation checking, concept consistency and knowledge base consistency [18]. The question, whether it is necessary to look for another approach solving consistency issue, may be asked. However the study [18] is dated in 2003 and the main motivation is a poor UML tools support in the given matter. Work on defining model driven development (MDD) started in 2001 and was far from complete at that time. Many new tools focusing on the MDD's approach to the project development have been launched and many new approaches have been defined. This is the main reason why we adopt this approach to achieve the goal of the thesis. Structure of the thesis In the first chapter we define MDD and all related terms. We need to identify all the connections between these definitions and code-model consistency aspects. Consistency problem is separated and tools capable of solving the problem are categorised and analysed. Demonstration of the best set of tools CONTENTS 8 on an exemplary project is build. In the last chapter, the ideal tool described. Other tools analysed within this thesis are evaluated with respect to the ideal tool. Chapter 1 Model Driven Development In this chapter, definitions of notions necessary for understanding the thesis are defined. We need to fully understand the difference between model driven development and model driven architecture, terms like model, transformation and relations between them. The following knowledge is gained from [2] and [18]. 1.1 Definition During the study of the model development, one often meets with terms mod- els, modelling and model transformation. Models serve us for the reasoning about the problem and the solution domain. Relationships between them provide us with the web of dependencies recording the process. These facts allow us to define the kind of models that must be modelled, and define pre- cise semantics of these models. As follows, we can define rules for automat- ing steps converting one model representation into another, tracing between model elements and analysing characteristics of the model that we desire. This methodology is called Model driven development (MDD) [2]. MDD is a paradigm for writing and implementing computer programs quickly, effec- tively and at minimum cost. Model driven architecture (MDA) [2] is a software design approach for development of software systems. It provides a set of guidelines for structur- ing specifications, which are expressed as models. MDA is a type of domain 9 CHAPTER 1. MODEL DRIVEN DEVELOPMENT 10 engineering, and supports model-driven engineering of software systems. It was launched by the Object Management Group (OMG) [12] in 2001. It is important to mention at the beginning, that model driven develop- ment and model driven architecture often refer to the same methodology. In the commercial sector, this methodology is more often named MDA, but MDA is only a style of MDD, that offers the possibility of defining rules for automating many of the steps needed to convert one model representation to another. MDA enhances the use of MDD by tracing throughout model elements and analysing important characteristics of the models. Since these automated steps of converting models are the main focus of this thesis, the term MDA is being used from now on, as its definition captures given theme the best. There are several terms, that need to be explained for better understand- ing of the following chapters. The central term of MDA is a model [2]. According to MDA's definition, model is a set of statements about the sys- tem that is under study. The model is in a need of abstraction for the user to better understand it. Abstraction allows the user to focus on the system aspects one wishes to, and enables model's complexity to be handled. The language is in the MDA's definition termed as a formalism [2]. Its meaning is to precisely define the syntax and semantics for the given model. There are two types of the syntax of the formalism, concrete and abstract. Concrete syntax is used for a specification of the readable representation of the abstract notational elements. There are two types of semantics as well, static, also referred to as well-formed rules, and dynamic. Representation of restrictions for valid models is ensured by static semantics. The dynamic semantics is the behaviour of a sentence as its context potentially changes. It is expected, with the dynamic semantics description of a model, a foundation for understanding and evaluating the design issues, and a valuable reference for transformations that involve this model [3]. Figure 1.1 describes the relationship between given terms. CHAPTER 1. MODEL DRIVEN DEVELOPMENT 11 Figure 1.1: Model Driven Architecture [2] 1.2 Model Transformation The main focus of this thesis lies within model transformation. Before con- tinuing any further, this term needs to be defined and explained. Lets assume that M is the model of a system S (or specification for a system set) and F is the formalism in which the model is described.

Load more

  70

Copy Link