Analysis of Unified Modelling Language

Analysis of Unified Modelling Language Chapter 1: Introduction Context of the Problem The Unified Modeling Language is a graphical modeling language used for the visualization, specification, construction, and documentation of object-oriented software systems. It has been adopted by the Object Management Group (OMG) and is widely accepted as a standard in industry and research. The UML provides thirteen types of diagrams for different purpose. This thesis focuses on sequence and class diagram known as structure diagram and behavior diagram. Sequence forms concentrate on the presentation of dynamic aspects of a software system, and class forms the structural view of software system. Sequence diagrams stress time ordering while Class focus on static. In Model-driven Architecture (MDA), class diagram is the source for code generation in object-oriented development (Pender, 2003), so how to map what we find in the interaction diagram back to class diagram become an important subject if we want to develop system from behavior aspect initially. There are some existing relatively modest tool supports exploiting the logical dependencies of UML diagrams. Some systems maintain method lists across class diagrams and sequence diagrams and the transformation between sequence diagrams and collaboration diagrams. However, nowadays, the two diagrams that sequence and Class are draw divided and can not be transformed between each other. And there is no comprehensive framework that would support such mechanisms throughout these two diagram types in a systematic way (Selonen et al., 2003). That waste much time to maintain system and often make the system development documents should rewrite again and again. To solve these problems, a transformation theorem which proposed by Selonen et al. (2003) is cited in this paper. Selonen et al. (2003) propose a framework and categorize meaningful transformation operations between different diagram types in UML. These operations can be used, for example, for model checking, merging, slicing and synthesis (Selonen et al., 2003). The transformation operation can be used as a basis of tool support in UML-based modeling tools. With these operations, we can get the benefits as follows: Class Diagram becomes easier and faster to create because they can be achieved as results of automated operations. Class Diagram becomes more consistent and correct because they are either produced or updated automatically, or checked against each other exploiting the transformation operations. Improve the software development process. The process of agile modeling become from use case to sequence diagram and then translated to class diagram. It will be more simply and efficiency. Research Question and sub-questions How does the transformation between sequence and Class diagrams make systems easier to develop and maintain and avoid system development documents to be rewritten all the time? What are meta-modeling, Meta Object Facility and Object Constraint language? How to operate the transformation? How does the transformation work in the real world (Examples)? Significance of the Study Sequence diagrams provide a natural and easy medium for designing the examples of typical dynamic interactions of objects, often as refined representations of use cases. After modeling examples of interactions, the designer should add the information implied by the sequence diagrams to the static view (class diagrams), or check that the static view conforms to the sequence diagrams (Selonen et al., 2000). The sequence diagram and class diagram derived from the same use case and can not be transformed between each other. This paper discusses a particular UML transformation operation mentioned in (Selonen et al., 2003), which transforms from a sequence diagram into a class diagram. The transformation operation is based on the UML 2.0 Specification (OMG, 2003), which defines the syntax and semantics of UML. The thesis defines the rules on the phases of this transformation operation and gives a transformation example to show the result of transformation. This paper will concentrate on the conceptual research of UML semantics, and do not concentrate on any development tool. However, OCL will be used to describe the transformation rules and hoped can be used in UML-based modeling tools development. I hope that the steps of modeling will improve; Support for synthesizing a new class diagram from an existing sequence diagram can provide significant help for the designer. Such synthesis operation helps the designer keep the two diagrams consistent because the synthesized class diagram can be compared with existing class diagram. The transformation operation also speeds up the design process, and to decrease the risk of human errors. In UML CASE tool vendors can implement this transformation operation in their tools to get the benefits described above. Research Design and Methodology The protocol for this research project is mostly using qualitative by design. A Case study will be used as the most important a strategy of research methodology in the study. The research process consists of six steps. It collects and analysis the documents and papers which are corresponding to the UML transformation thesis, OCL and MDA transformation theory. Then proposing a transformation framework for transformation from sequence diagram to class diagram and concluding transformation mapping rules. This paper will testify and revise the transformation mapping rules via implement a real case of agile modeling development process. And finally proposing the research result, and discuss the conclusion and future work. Organization of the Study Chapter 1: Introduction Chapter one introduces the research. This chapter will present the context of the problem, the problem statement, the main research question, the significance of the study, and the research methodology used to address the main research question. Chapter 2: Review of the Literature Chapter two gives an overview of the background literature for the thesis. Chapter 3: Meta-modeling, Meta Object Facility and Object Constraint language Chapter three will give the brief introduction of UML, MDA, meta-model, transformation and OCL are described at first, followed are the separate meta-models of sequence and class diagram. Chapter 4: Operation of the Transformation Chapter four will propose a framework of transformation from Sequence diagram to Class diagram. Also, a rule will be defined on every phase of transformation, using OCL to describe transformation rules. Chapter 5: Example of the Translations Chapter five will be working on a Case Study, and demonstrating the transformation for a true case in the real world. Chapter 6: Conclusion Chapter six will present the summery and conclusion. Chapter 2: Review of Literature 2.1 UML The complexity in software development process of getting from a set of requirements to a proper abstraction of the solution leads people to develop models. A model is a simplification of something so we can view, manipulate, and reason about it, and so help us understand the complexity inherent in the subject under study (Mellor et al., 2004). The UML is a family of graphical notations, backed by single meta-model, that help in describing and designing software systems, particularly software systems built using the object-oriented (OO) style (Fowler, 2003). The Unified Modeling Language (UML), since adopted as a standard (UML 1.1) by OMG in 1997, has become a widely accepted as standard for modeling a software system. The latest UML version 2.0 has been formally adopted in June 2003, and it will be applied throughout this thesis. UML 2 describes 13 official diagram types which fall in two categories depending on whether they describe structural or behavioral aspects of a software system. The UML can capture an array of processes and structures which related to business and software. UML has such power that a modeler can use it for the general architecture of any construction that has both a static structure and dynamic behavior. A project can rely on UML as the standard language to express requirements, system design, deployment instructions, and code structure (Eriksson et al., 2004). 2.2 Agile Modeling Test case modeling and an evolutionary approach are two major and strongly related techniques to model transformation (Rumpe, 2004). UML nowadays has become popular modeling language for software intensive systems used. Models can be used for a variety of purposes. One advantage of using models for test case description is the application specific parts which are modeled with UML-diagrams, such as connection to frameworks, error handling, persistence, or communication are handled by the parameterized code generator (Rumpe, 2004). This allows us to develop models which can be independent of any technology or platform, such as PIM. When the technology changes, we only need to update the generator, and the application defining models can directly be reused. This concept also directly supports the above mentioned MDA-Approach (OMG, 2005) of the OMG. Another important merit is that both of the production code and automatically executable tests are modeled by the same UML diagrams. Therefore developers could use a single homogeneous language to describe implementation and tests. This will enhance the availability of tests at the beginning of the coding activities. Analogously to the â€Å"test first approach† (Beck, 2001), sequence diagrams are used for test cases and can be taken from the previously modeled requirements. When we start software modeling by drawing classes in a class diagram does not mean we are developing a class model. Instead, we are developing a software model by defining static aspects through a static view. If we start our development by drawing a dynamic diagram, like the state or sequence diagram, we are developing a software model by defining dynamic aspects through a dynamic view. The class and sequence diagrams could better be called structural and dynamic views. They are all written in the same language: UML (Kleppe et al, 2003). In Agile modeling (Ambler, 2002), we develop an Information system in following steps by using UML. System Use Case Models UI Prototypes UML Class Diagrams UML Sequence Diagrams UML Activity Diagrams Use case diagram shows a number of external actors and their connection to the use cases that the system provides. A use case is a description of a functionality (a specific usage of the system) that the system provides. The description of the actual use case is normally done in plain text or as a document linked to the use case. The functionality and flow can also be described using an activity diagram. The use case description only views the system behavior as the user perceives it and does not describe how the functionality is provided inside the system. Use cases define the functional requirements of the system. Sequence diagrams address an interaction and may be used to model flows within use cases (Booch et al., 1999). They show how the objects interact to execute operations, emphasis on the time ordering of the messages. Class diagrams shows a collection of declarative (static) model elements, such as classes, types, and their contents and relationships. Once we have the use cases, the next step is to create the class diagram. This is the heart of the object-oriented model. This paper concentrates on the steps of modeling from Use Case Models to Class Diagrams and sequence Diagrams. 2.3 MDA The MDA is a new software engineering approach developed and published by the Object Management Group (OMG). One fundamental observation in the evolution of living software systems over the years is that their basic design models are mostly unchanged. Most changes to evolving software systems take place only at engineering level, forced by the introduction of new technologies and platforms (BAohme et al., 2005). MDA promotes simply the usage of models for the whole software system development. To capture the problem of technology evolution MDA defines two categories of models. The first one is for abstract modeling of the software systems at the design level. This model class is called Platform Independent Model (PIM). The second category is related to specific platforms and technologies. It contains mainly engineering aspects of the software system and is called Platform Specific Model (PSM). Between these two classes of models, MDA defines a relation in the form of several transformations, which ensure the structural equivalence of PIM and PSM. Another key issue of MDA is a technology framework for different kinds of model handling (storage, exchange, mapping of models, etc.). The Meta Object Facility (MOF) (OMG, 2000) is convenient for this purpose. Historically modeling languages were defined by abstract grammars. MOF instead defines modeling languages on the base of so-called Meta-Models. Meta-Models are models (instances) of built-in MOF concepts. Using this framework the developer can focus more on the definition of mappings between models rather than having to struggle with ordinary model handling. This is due to the fact that MOF comes with a method for the definition of model classes (Meta-Models) and for the exchange of models using the XML Metadata Interchange (XMI). In addition, MOF provides mappings of Meta-Models to repository interfaces as well. Such a repository holds all necessary information about model instances. The above argument is correct for most of todays component technology. To show the real application we have to choose concrete Meta-Models for PIM and PSM. This also leads to the selection of appropriate Meta-Models and notations for PIM and PSM. One requirement for both is the support of the component concept as a first class concept. Moreover, the Meta-Model for the PSM should be part of a well-defined and established component technology. Because the spread industrial usage is a process consuming several years, the suitable technologies have traditional syntax based languages for component definition. MDA exploits the emergence of a class of tools, which support model translation and allow meta-model manipulation. Meta-models are models of the formalism used to build models. They define the various kinds of contained model elements and the way they are arranged, related and constrained. The process of developing a model results in the creation of instances of the model elements defined in the meta-model – the meta-model is â€Å"populated† with instance data. Model transformation is the process of converting a model expressed in one formalism to another model of the same system expressed using a different formalism. This can be achieved by building a meta-model of each of the source and target model representations and then defining a mapping between them. The meta-model of the source model is populated with instance data of the specific source model to be transformed. The mapping rules are applied as a set of operations invoked on the source meta-model, which results in a meta-model of the target model populated with instance data. This populated target meta-model is then used to generate the target model (or possibly the target text in the case of code generation. (Bloomfield, 2005) 2.4 Models, modeling, and MDA Models and model-driven software development are at the heart of the MDA approach. So it is appropriate to start by looking at what is being practiced when enterprise application developers take advantage of modeling. In the software engineering world, modeling has a rich tradition from the earliest days of programming. The most recent innovations have focused on notations and tools that allow users to express system perspectives of value to software architects and developers in ways that are readily mapped into the programming language code that can be compiled for a particular operating system platform. The current state of this practice employs the Unified Modeling Language (UML) as the primary modeling notation (Rumbaugh et al.,1999). The UML allows development teams to capture a variety of important characteristics of a system in corresponding models. Transformations among these models are primarily manual, with tool support for managing traceability and dependency relationships among modeling elements, supported by best practice guidance on how to maintain synchronized models as part of a large-scale development effort. One useful way to characterize current practice is to look at the different ways in which the models are synchronized with the source code. Each category identifies a particular use of models in assisting software practitioners to create running applications (code) for a specific runtime platform, and the relationship between the models and the code. Today, most of software developers still take a code-only approach, and do not use separately defined models at all. They rely almost entirely on the code they write, and they express their model of the system they are building directly in a 3rd generation programming language such as Java, C++, or C# within an Integrated Development Environment (IDE) such as IBM WebSphere Studio, Eclipse, and Microsoft VisualStudio. Any â€Å"modeling† they do is in the form of programming abstractions embedded in the code (e.g., packages, modules, interfaces, etc.), which are managed through mechanisms such as program libraries and object hierarchies. Any separate modeling of architectural designs is informal and intuitive, and lives on whiteboards, in PowerPoint sides, or in the developers’ heads. While this may be adequate for individuals and very small teams, this approach makes it difficult to understand key characteristics of the system among the details of the implementation of the business logic. Furthermore, it becomes much more difficult to manage the evolution of these solutions as their scale and complexity increases, as the system evolves over time, or when the original members of the design team are not directly accessible to the team maintaining the system. An addition is to provide code visualizations in some appropriate modeling notation. As developers create or analyze an application, they often want to visualize the code through some graphical notation that aids their understanding of the code’s structure or behavior. It may also be possible to manipulate the graphical notation as an alternative to editing the text based code, so that the visual rendering becomes a direct representation of the code. Such rendering is sometimes called a code model, or an implementation model, although many feel it more appropriate to call these artifacts â€Å"diagrams† and reserve the use of â€Å"model† for higher levels of abstraction. Some tools that allow such diagrams (e.g., IBM Web Sphere Studio and Borland Together/J), the code view and the model view can be displayed simultaneously; as the developer manipulates either view the other is immediately synchronized with it. In this approach, the diagrams are tightly coupled representations of the code and provide an alternative way to view and possibly edit at the code level. Further advantage of the models can be taken through roundtrip engineering (RTE) between an abstract model of the system describing the system architecture or design, and the code. The developer typically elaborates the system design to some level of detail, then creating a first-pass implementation from the code generated by applying model-to-code transformations, usually manually. For instance, one team working on the high level design provides design models to the team working on the implementation (perhaps simply by printing out model diagrams, or providing the implementation team some files containing the models). The implementation team converts this abstract, high-level design into a detailed set of design models and the programming language implementation. Iterations of these representations will occur as errors and their corrections are made in either the design or the code. Consequently, without considerable discipline, the abstract models and the implementation models usually and quickly – end up out of step. Tools can automate the initial transformation, and can help to keep the design and implementation models in step as they evolve. Typically the tools generate code stubs from the design models that the user has to further refine. As changes are made to the code they must at some point be reconciled with the original model. To achieve this some approach to recognize generated versus user defined code is used such as placing markers in the code. Tools adopting this approach, such as IBM Rational Rose, can offer multiple transformation services supporting RTE between models and different implementation languages. In a model-centric approach, models of the system are established in sufficient detail that the full implementation of the system can be generated from the models themselves. To achieve this, the models may include, for example, representations of the persistent and non persistent data, business logic, and presentation elements. Any integration to legacy data and services may require that the interfaces to those elements are also modeled. In some cases much more than code stubs can be generated depending on the fidelity of the models of patterns to transform the models to code, frequently allowing the developer some choice in the patterns that are applied (e.g., among various deployment topologies). To further assist in the code generation, this approach frequently makes use of standard or proprietary application frameworks and runtime services that ease the code generation task by constraining the styles of applications that can be generated. Hence, tools using this approach typically specialize in the generation of particular styles of applications (e.g., IBM Rational Rose Technical Developer for real-time embedded systems). However, in all cases the models are the primary artifact created and manipulated by developers. A model-only approach is at the far-right end of the modeling spectrum. In this approach developers use models purely as thought aids in understanding the business or solution domain, or for analyzing the architecture of a proposed solution. Models are frequently used as the basis for discussion, communication, and analysis among teams within a single organization, or across multi-organizational projects. These models frequently appear in proposals for new work, or adorn the walls of offices and cubes in software labs everywhere as a way of understanding some complex domain of interest, and establishing a shared vocabulary and set of concepts among disparate teams. In practice the implementation of a system, whether from scratch or updating an existing solution, may be practically disconnected from the models. An interesting example of this approach can be seen in the growing number of organizations who outsource implementation and maintenance of their systems while maintaining contr ol of the overall enterprise architecture. 2.5 Transformations between UML diagrams UML provides different diagram types supporting the development process from requirements specification to implementation (Selonen et al., 2001). The models presented by different diagrams view a system from different perspectives or from different abstraction levels. Therefore, the various UML models of the same system are not independent specifications but strongly overlapping: they depend on each other in many ways. For Instance, changes in one model may imply changes in another, and a large portion of one model may be synthesized on the basis of another model. So far there exists relatively modest tool support exploiting the logical dependencies of UML models. Some systems (e.g. Rational Rose) maintain, for instance, method lists across class diagrams and sequence diagrams: adding a call of a new method in a sequence diagram automatically causes the corresponding updating of the class symbol in a class diagram. Another example is the transformation between sequence diagrams and collaboration diagrams, also supported by Rational Rose. However, there is no comprehensive framework that would support such mechanisms throughout Class diagram and Sequence diagram in a systematic way. This paper studies the relationships of Class diagram and Sequence diagram in UML, and transformation operations that are based on those relationships. A transformation operation takes a UML diagram as its operand (the source diagram), and produces another diagram of another type as its result (the target diagram). It considers such transformation operations as an essential part of a UML- based software design environment. The transformation operations can be used for example in the following ways: Model checking:Are two diagrams consistent with each other? It is much easier to find inconsistencies between two diagrams of the same type than between two diagrams of different types. If the diagrams are of different types, transformation operations can be first applied to obtain two diagrams of the same type, which are then compared for consistency. Model merging:Add the information contained in one diagram to another diagram. Merging the modeling information of two diagrams is much easier when the diagrams are of the same type (Alanen and Porres, 2003). If the diagrams are of different types, transformation operations can be first applied to obtain two diagrams of the same type, which are then merged. Model slicing:Create a partial view of a diagram showing only a particular aspect. Often the aspect can be presented in the form of another diagram (of some other type). For example, one may want to see a dynamic slice of a static diagram. The diagram representing the slicing criterion (for example, a dynamic diagram) can be first transformed into the type of the target diagram (for example, a static diagram). An intersection of the two diagrams of the same type then shows the desired slice. Model synthesis:Produce a diagram on the basis of an existing diagram of another type. This is the most straightforward usage of transformation operations. Such synthesis can be useful for two purposes: to obtain automatically an initial form of a diagram needed in a subsequent phase of the software development process, or to obtain a different view of the information contained by a diagram. The latter may be used just as a transient view on a model, rather than as a persistent design artifact. 2.6 Phase of Transformation Operation Selonen et al. (2003) use the UML meta-model to define the transformation between UML diagrams. Since diagram types are only very loosely defined (the same notation may represent different meaning on different diagrams), we need to establish a precise mapping from a graphical view representing a diagram type to a model; i.e. we must define a model that corresponds to a given diagram. This model contains exactly the logical information exposed by the diagram, needed by the transformation operations. We will call this model the minimal model of the diagram. As we do this for all diagram types, we are able to define transformations between diagram types as functions from the meta-model of a diagram type to the meta-model of another diagram type. Such a function takes the minimal model of the source diagram as its argument, and produces the minimal model of the target diagram. They call the transformation rules the interpretation of the transformation. Assuming that the mappings from the source diagram into its minimal model, from this minimal model into the minimal model of the target diagram, and finally into the target diagram, are all defined uniquely, the transformation between two diagram types becomes fully defined (Selonen et al.,2003). First, take a given sequence diagram and map the sequence diagram to its minimal model. Then transform this minimal model to a minimal model of a class diagram. Finally, this minimal model is mapping to a class diagram in model level. This thesis will base on this process to introduce a definite transformation operation. Reference Tom Pender. (2003). UML Bible (1st edition). Wiley, ISBN: 0764526049 Martin Fowler. (2004). UML Distilled (3rd edition), Wesley, ISBN: 0321193687 Hans-Erik Eriksson, Magnus Penker, Brain Lyons, and David Fado. (2004). UML 2 Toolkit, Wiley, ISBN: 0471463612 Ambler. (2002). Agile Modeling: Effective Practices for Extreme Programming and the Unified Process, Wiley, ISBN: 0471202827 Jos Warmer, Anneke Kleppe.(2003). The Object Constraint Language: Getting Your Models Ready for MDA (2nd Edition), Wesley, ISBN: 0321179366 Grzegorz Rozenberg.(1997). Handbook on Graph Grammars and Computing by Graph Transformation: Foundations (1st edition), World Scientific Publishing Company, ISBN: 9810228848 James Rumbaugh, Grady Booch, and Ivar Jacobson. (1999). The Unified Modeling Language Reference Manual, Wesley, ISBN: 020130998X Jams R Rumbaugh, Michael R. Blaha, William Lorensen, Frederick Eddy. (1991). Object-Oriented Modeling and Design, Prentice Hall; United States Ed edition, ISBN: 0136298419 Rumpe, B.(2004). Agile Modeling with the UML, Springer-Verlag Berlin Heidelberg Petri Selonen, Kai Koskimies and Markku Sakkinen. (2001). How to Make Apples from Oranges in UML. Proceedings of the 34th Hawaii International Conference on System Sciences. Retrieved February 21, 2008, from: http://csdl2.computer.org/comp/proceedings/hicss/2001/0981/03/09813054.pdf Petri Selonen, Kai Koskimies and Markku Sakkinen. (2003). Transformations between UML diagrams. Journal of Database Management. Retrieved February 21, 2008, from: http://www.accessmylibrary.com/coms2/summary_0286-23439697_ITM Petri Selonen (2000). Scenario-based Synthesis of Annotated Class Diagrams in UML. Tampere University of Technology, Retrieved February 21, 2008, from: http://citeseer.ist.psu.edu/462963.html Mellor, S. J., Scott, K., Uhl, A., and Weise,D., MD. (2004). a Distilled: Principles of Model-Driven. Wesley, Retrieved February 22, 2008, From: http://www.metamodel.com/,2005 OMG. (2003). UML 2.0 OCL Specification, Retrieved February 22, 2008, from: http://www.omg.org/docs/ptc/03-10-14.pdf,2003 Tony Bloomfield. (2005). MDA,Meta-Modelling,and Model Transformation: introduction New Technology into the Defence Industry, Retrieved February 22, 2008, from: http://www.enabler.com/en/skills/ecmda/PAPER_Bloomfield.pdf