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 (Ruddell, 2003). 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 (Pastor, 2007), 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 (Rational Rose Software Architecture 6.0). 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, 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, 2003 is cited in this DRP. Selonen 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.
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:
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?
1. What are meta-modeling, Meta Object Facility and Object Constraint language?
2. How to operate the transformation?
3. 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, 2000). The sequence diagram and class diagram derived from the same use case and can not be transformed between each other. This DRP discusses a particular UML transformation operation mentioned in (Selonen, 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 DRP will concentrate on the conceptual research of UML semantics, and do not concentrate on any development tool. However, Object Constraint Language (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 DRP 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 DRP 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 DRP.
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 Unified Modeling Language
The software development process of getting from a set of requirements to a proper system is very complex and time consuming, therefore, simplification becomes a key to effective software development. A mode is a simplified description of something that can help us understand a complex read world problem (Malgouyres, 2006).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 software systems. The UML uses graphical notations to show the design of software systems. It plays a very important role in constructing software designs, especially object-oriented software (Fowler, 2003). The latest UML version 2.0 has been formally adopted in June 2003, and it will be applied throughout this DRP. There are 13 different types of UML diagrams that fall in two main categories - structural ad behavioral diagrams. Each of them describes different 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 developer can use it for the architecture of any software system that has both a static structure and dynamic behavior. A project can rely on UML as the standard language to express user requirements, system design and development, and code structure (Eriksson, 2004).
2.2 Agile Modeling
The techniques of test case modeling and an evolutionary approach are at the heart of model transformation (Rumpe, 2004). UML nowadays has become the most popular modeling language for developing software systems. Models can be used for a variety of purposes.
One obvious advantage to using models for test case description is the application specific parts, such as connection to frameworks, error handling, and persistence, 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 Platform Independent Model (PIM). Therefore, when the technology changes, we can reuse the system defining models without much change, and only need to update the code generator. 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. Sequence diagrams are used for test cases and can be taken from the previously modeled requirements. When we start software development 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. On the other hand, when we start software development by drawing a state or sequence diagram, we are developing a software model by defining dynamic aspects through a dynamic view. Class diagrams are called structural views, sequence diagrams are called dynamic views, and both of them are written in the same language, which is UML (Kleppe, 2003).
In Agile modeling (Ambler, 2002), we develop an Information system in following steps by using UML.
Use case diagram displays all the external actors of a system, the relationship among the actors, and their connection to the system. 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 (Mclaughlin, 2007). They show how the objects interact to execute operations, emphasis on the time ordering of the messages. Class diagrams contain all the elements of a model, such as classes, types, and their contents and relationships. Once we have the use cases, the next step is to create the class diagrams. This approach is the heart of the object-oriented model.
This DRP concentrates on the steps of modeling from Use Case Models to Class Diagrams and sequence Diagrams.
2.3 Transformations between UML diagrams
“Unified Modeling Language provides different diagram types supporting the development process from requirements specification to implementation” (Selonen, 2001, p. 3054). Different diagrams present the models are viewing a system from different perspectives. Therefore, the same system UML models are not independent specified, yet strongly overlapping: they are depending on each other in different 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” (Petri, 2003).
This DRP studies the relationships of Class diagram and Sequence diagram in UML, the operations of the transformation are based on these relationships. An operation of the transformation takes a UML diagram as its operand (the source), and the results are coming from producing another diagram of another type (the target). 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:
2.4 Techniques for Transformation Operations
Two transformation rules were used to find a transformation from one diagram type to another. The rules are called push and pull.
This DRP will also use Object Constraint Language to describe the push and pull operation, hoping the operations of transformation can be realized by UML-based tools. (Bloomfield, 2005)
2.5 Phase of Transformation Operation
The Unified Modeling Language (UML) meta-model was used to define the transformation between UML diagrams (Loch, 2006). Since diagram types are only very loosely defined (the same notation may represent different meaning on different diagrams), we have to organize a precise mapping from a graphical view to represent a type of diagram to a model; defining a model which corresponds to a given diagram is needed. The logical information is contained in this model, and exactly exposed by the diagram, the transformation operations is needed. We will call this model as the minimal model of the diagram. For all diagram types, transformations between diagram types will be defined as functions from the meta-model diagram type to the meta-model of another diagram type. Like a function which gets the source of minimal diagram model as the argument, and to produce the target of minimal diagram model. They call the transformation rules the interpretation of the transformation. Assume that a diagram mappings into minimal model, and then into the target diagram minimal model, and finally into the target diagram, are all defined uniquely, the transformation between two diagram types becomes fully defined (Loch, 2006). First, map a given sequence diagram into its minimal model. Then transform this minimal model to a minimal model of a class diagram. Finally, this minimal model is mapped into a class diagram in model level. This DRP will base on this process to introduce a definite transformation operation.
2.6 Meta-model of Class Diagram and Sequence Diagram
This section will discuss about the meta-model of class and sequence diagrams. However, I will not debate all elements of class and sequence diagrams. I list only some elements which used for my research purpose.
The knowable of a class diagram is describing the types of objects in the system and the various kinds of static relationships which exist among them. A class diagram presents the class properties and applies that all objects which related are connected (Malgouyres, 2006). A class diagram is an illustration of static view for a software system and represents the structure of it. In this section, the meta-model of a class diagram will be shown first.
2.6.1 Meta-model of Class Diagram
Figure 2- 1 shows the meta-model of the class diagram which is derived from OMG (OMG, 2006). It represents some meta-model elements which appended by UML 2.0 specifications, such like interface, association class and so on. I combine each part of meta-model which corresponding to class diagram into one class meta-model diagram based on OMG (OMG, 2006).
Figure 2- 1: Class Diagram Meta-model
2.6.2 Class
Object describes some real entity in the real world. A class describes a set of objects that share the same specifications of features, constraints, and semantics. The purpose of a class is to specify a classification of objects and to specify the features that characterize the structure and behavior of those objects (OMG, 2006). The structural feature of class is attributes and the behavioral feature of class is operations. The mete attribute of Class “is Abstract” denotes the class is abstract. An abstract class can not be instantiated and is intended to be used by other classes e.g. as the target of generalization relationships. The meta attribute's default value is “false”. If a class is abstract, the class name is written in italics. The default notation for a class is a solid-outline rectangle containing the class's name, and optionally with compartments separated by horizontal lines containing features or other members of the class. Three compartments are shown in a class. One of the compartments holds the attributes while the bottom compartment holds a list of operations. Other details will be shown if there are additional compartments supplied, such as constraints, or to divide features. In order to fulfill the requirement of viewer, any compartment or some details can be suppressed (OMG, 2006).
Figure 2- 2 shows three different notations with different details which represent the same class Window.
Figure 2- 2
2.6.3 Meta-model of Sequence Diagram
Figure 2- 3 shows the meta-model of the sequence diagram that is drawn and inferred from OMG (OMG, 2006).
Figure 2- 3: Sequence Diagram Meta-model
Table 2- 1 identifies the complete list of new and existing features of the Sequence diagram defined in UML2.0; The main purpose of this DRP is to discuss how to transform form sequence diagram to class diagram , so I only introduce some feature that we often use. The word new in the table means that the element is newly add-in UML2.0.
Table 2- 1: features of the UML 2.0 Sequence diagram (Pender, 2003)
Reference
Ambler. (2002). Agile Modeling: Effective Practices for Extreme Programming and the
Unified Process, Wiley
Brett D. Mclaughlin, Gary Pollice and David west. (2007). Head First: Object Oriented
Analysis & Design, O'reilly
Daniel Varro (2007), Automating model transformation by example using inductive logic
programming. The ACM digital library, p. 978 - 984 Retrieved February 25, 2008
H. Malgouyres (2006) A UML model consistency verification approach based on meta-modeling
formalization. The ACM digital library, P. 1804 - 1809 Retrieved February 25, 2008
Jos Warmer, Anneke Kleppe.(2003). The Object Constraint Language: Getting Your
Models Ready for MDA (2nd Edition), Wesley
John W. Satzinger, Robert B. Hackson, Stephen D. Burd. (2007). Systems Analysis &
design: In a changing world. Thomson course technology
Martin Fowler. (2004). UML Distilled (3rd edition), Wesley
Nora Loch (2006). Transformation techniques in the model-driven development process
of UWE. The ACM digital library, Article No.3 Retrieved February 25, 2008
Oscar Pastor and Juan Carlos Molina (2007, July). Model-Driven Architecture in Practice:
A Software Production Environment Based on Conceptual Modeling, Springer
OMG. (2006). UML 2.0 OCL Specification, Retrieved February 22, 2008,
from: http://www.omg.org/docs/
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
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
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
Rumpe, B.(2004). Agile Modeling with the UML, Springer-Verlag Berlin Heidelberg
Tom Pender. (2003). UML Bible (1st edition). Wiley
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
