Transformations Between UML Diagrams

Journal of Database Management, 14(3), 37-55, July-Sept INFORMATION SCIENCE PUBLISHING 701 E. Chocolate Avenue, Hershey PA 17033, USA Tel: 717/533-8845; Fax 717/533-8661; URL-http://www.idea-group.com 2003 37 ITJ2455 Transformations Between UML Diagrams Petri Selonen, Kai Koskimies, Tampere University of Technology, Finland Markku Sakkinen, University of Jyväskylä, Finland ABSTRACT The Unified Modeling Language (UML) provides various diagram types for describing a system from different perspectives or abstraction levels. Hence, UML diagrams describing the same system are dependent and strongly overlapping. In this paper we study how this can be exploited for specifying transformation operations between different diagram types. We discuss various general approaches and viewpoints of model transformations in UML. The source and target diagram types for useful transformations are analyzed and given categories. The potentially most interesting transformation operations are discussed in detail. It is concluded that the transformation operations can automate a substantial part of both forward and reverse engineering. These operations can be used, for example, for model checking, merging, slicing, and synthesis. Keywords: UML, model transformation, diagram transformation, model synthesis INTRODUCTION UML (Booch, Rumbaugh, and Jacobson, 1999; OMG, 2001; Rumbaugh, Jacobson, and Booch, 1999) has become an industry standard for the presentation of various design artifacts in objectoriented software development. UML provides different diagram types supporting the development process from requirements specification to implementation. The models, presented by different diagrams, view a system from different perspectives or at different levels of abstraction. Hence, the various UML models of the same system are not independent specifications but strongly overlapping, depending on each other in many ways. For example, 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 Copyright © 2003, Groupjournal, Inc. Copying or distributing print or electronic forms14(3), without written This chapter appearsIdea in the International Journal ofin Database Management, edited by Keng permission of Idea Group Idea Inc. Group is prohibited. Siau. Copyright © 2003, Publishing. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited. 38 Journal of Database Management, 14(3), 37-55, July-Sept 2003 tool support exploiting the logical dependencies of UML models. Some systems (e.g., Rational Rose by Rational Software Corporation, 2002) maintain 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 Rose. However, there is no comprehensive framework that would support such mechanisms throughout all diagram types in a systematic way. In this paper we study the relationships of different diagram types in UML and discuss 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). We consider such transformation operations to be an essential part of a UML-based software design environment. The transformation operations can be used, for example, in the following ways: Model checking. Check whether two diagrams are 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. As with checking, merging is easier between two diagrams of the same type. 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 sequence diagram) can be first transformed into the type of the target diagram (for example, a class diagram). An intersection of the two diagrams of the same type then shows the desired slice. Model slicing (or filtering) is a general technique used, for example, in reverse engineering (Systä, 2000a) and information systems modeling (Seltveit, 1996). 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. We argue that the transformation operations described in this paper can be used as a basis of tool support in UMLbased CASE environment. The expected benefits of this approach are the following: 1. Models become easier and faster to create because they can be partly achieved as results of automated operations. Model synthesis can be exploited both in forward and reverse engineering. In the former, the level of abstraction of the source diagram is the same, or higher, than that of the target diagram. In the latter, the abstraction level of the source Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited. Journal of Database Management, 14(3), 37-55, July-Sept 2003 39 2. 3. 4. 5. diagram is usually lower than that of the target diagram. Forward and reverse engineering aspects of UML models have been considered also by Booch et al. (1999), but mostly with respect to code rather than to other UML models. We argue that forward and reverse engineering techniques between different UML models are equally important. Models become more consistent and correct because they are either produced or updated automatically, or checked against each other exploiting the transformation operations. Models become easier to understand, because model operations can be used to achieve different views of the models, either from different viewpoints or at different levels of abstraction. Customizable tool support can be provided using the transformation operations in user-defined scripts. Transformation operations support incremental development: a diagram can be (automatically) augmented with the information given by another diagram, the result can be further developed manually and used then to augment another diagram, etc. Some of the usage scenarios rely on the existence of operations that produce a union or intersection of two diagrams of the same type (Koskinen, Peltonen, Selonen, Systä, and Koskimies, 2001a). Although such basic diagram operations are not trivial (and indeed not even sensible for certain diagram types), we will not discuss them in this paper since the problems of such “set” operations are essentially different from transformation operations. Work on integration of diagrams of the same type is discussed further, for example, by Frank and Eder (1998) for statechart diagrams, and by Egyed (1999) for UML architectural views. Similar work on integration of requirement viewpoints, parallel to integration of class diagrams, is discussed by Leite and Freeman (1991). The proposed transformation operations are particularly useful when combined together with a larger framework (Koskinen et al., 2001a) of model operations by using, for example, a visual scripting language as suggested by Peltonen (2000). We assume the knowledge of UML (OMG, 2001) throughout the paper. We follow the UML version 1.4; however, most of the discussion applies to the forthcoming version 2.0 as well. USING THE UML METAMODEL IN TRANSFORMATION OPERATIONS The architecture of UML is based on a four-layer metamodel structure, which consists of the following layers: user objects, models, a metamodel and a metametamodel. The meta-metamodel layer is the infrastructure for a metamodeling architecture and it defines the language for specifying metamodels. The metamodel layer is an instance of the meta-metamodel and defines the language for specifying a model. While the terms diagram, diagram type, and model are commonly used, the relationships between them are often not clearly defined. For the purposes of this paper, we define a model as a UML metamodel instance, a diagram as a graphical representation of a model, and a diagram type as a particular kind of a diagram proposed by the UML Notation Guide (OMG, 2001, Sect. 3). In this paper we study the relationships and transformations between different diagram types. Since diagram Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited. 40 Journal of Database Management, 14(3), 37-55, July-Sept 2003 types are only very loosely defined, 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 (in addition, the diagram may contain visual information that is not essential here). We will call this model the minimal model of the diagram. For each diagram type, the minimal models of diagrams of that type are instances of a subset of the UML metamodel; we call this subset the metamodel of the diagram type. As we do this for all (interesting) diagram types, we are able to define transformations between diagram types as functions from the metamodel of a diagram type to the metamodel 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. 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 operation between two diagram types becomes fully defined. This is shown in Figure 1. The mappings between a diagram and its minimal model is implied more or less directly by the UML Notation Guide. The transformation operations can be used in any UML tool environment that either supports directly the metamodels of the diagram types or enables a mapping from its own diagram representation to the metamodels. The core of our method is the definition of the transformations between the minimal models of diagrams. In order to be useful, such transformations preserve all the information of the source diagram that can be represented in the minimal model of the target diagram, determined by the metamodel of the target diagram type. This is often partly achieved by parsing the names of model elements as suggested by OMG. In addition, a transformation function tries to recognize derived and implicit information that can be inferred from the source diagram, and represented in the minimal model of the target diagram. Both types of information are useful: the former presents existing information from a new perspective, the Figure 1: Phases of a Transformation Operation Mapping Diagram layer UML Metamodel Instance Layer Interpretation Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited. Journal of Database Management, 14(3), 37-55, July-Sept 2003 41 latter shows information that was previously not explicitly available. The latter information may also include heuristic guesses that are not strict implications but nevertheless valid in most practical cases or under certain assumptions. We call all the rules mapping the minimal model of a source diagram to the one of the target diagram the interpretation of the transformation. Figures 2, 3, and 4 show the metamodels of class diagrams, interaction diagrams, and statechart/activity diagrams used in this work, respectively. These metamodels are subsets of the UML metamodel. For simplicity, the UML extension mechanisms associated with model elements are left out of the figures. It has been generally acknowledged that the UML metamodel does have problems with its semantics: even basic features like inheritance can be interpreted in different ways (Henderson-Sellers, 2001). However, our focus is not in the clarification of the semantics of UML (through diagram translations) but in the creation of a framework for transformations within UML, to be used as a basis of a designer’s tool kit. The specifications of the transformation operations can be easily tuned or extended for particular interpretations of the Figure 2: Class Diagram Metamodel AssociationClass Class Generalization * 1 +child 1 1 +parent Classifier Interface Association * 0..1 2..* 1 * AssociationEnd 0..1 * DataType * Attribute Operation Figure 3: Interaction Diagram Metamodel * Interaction Action 1 1 1 1..* 1 Collaboration 1 * AssociationRole 0..1 * 1 2..* AssociationEnd Role * 1 * Message * * 1 +sender 1 +receiver ClassifierRole 1..* Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited. 42 Journal of Database Management, 14(3), 37-55, July-Sept 2003 Figure 4: Statechart/Activity Diagram Metamodel 0..1 CompositeState ClassifierInState 0..1 +type 1 0..* * 1..* 0..* StateVertex +source 1 +target 1 +outgoing * +incoming * StateMachine 0..1 1 +top State 0..1 0..1 0..* Partition 0..* 0..1 0..1 +entry +exit 1 +internal * * +doActivity Transition Action 0..1 0..* Event 0..1 * 0..1 Guard semantics — indeed, in this paper we do not even precisely define the operations but rather sketch them on a general level. Hence, although different views on the semantics of UML may affect details of individual transformation operations, they do not affect the overall character of the transformations and the framework. Our current implementations of the transformation operations rely on fairly commonly understood meaning of basic UML features. TECHNIQUES FOR UML DIAGRAM TRANSFORMATION OPERATIONS There can be several levels of confidence in a transformation operation. In the strictest form we require all information in the target diagram to be implied by the source diagram. On the other hand, the most relaxed principle would be that there is no information in the target diagram that is in conflict with the source diagram; that is, the target diagram is free to present additional information as long as it is not invalidated by the source diagram. We call these principles the minimum principle and the maximum principle, respectively. The maximum principle is more appropriate in practice because it allows heuristics that often produce useful results. To find an interpretation of a transformation from one diagram type into another, two approaches can be used. In the push approach, each feature of the source diagram type is considered separately, and the implication of this feature in a target diagram is considered. The feature may be reflected in the target diagram as a single feature or as a pattern of features. In the pull approach, each feature of the target diagram type is considered separately, and possible reasons for the feature are sought from the source diagram. Again, the reason may be the appearance of a single source diagram feature or a pattern of features. In some cases a transformation operation can preserve all the information in the source diagram. This is the case for diagram types that share the same metamodel, for example, collaboration and sequence diagrams (there are some minor Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited. Journal of Database Management, 14(3), 37-55, July-Sept 2003 43 details that cannot be directly represented in both types). A basic transformation operation is defined as a function with signature trans: T1 → T2, where T1 and T2 are particular UML diagram types. However, it is sometimes more sensible to consider several source diagrams with signature trans: T1 x ... x T1 → T2. This is particularly obvious in cases where a complete specification is derived from sample descriptions. UML indeed includes a rather strong provision for design-by-example: examples of interactions among a set of objects can be defined as sequence diagrams or collaboration diagrams. On the other hand, complete behavioral specifications of classes can be given as statechart diagrams. There are several algorithms (Whittle and Schumann, 2000; Harel and Kugler, 2000; Schönberger, Keller, and Khriss, 2001) synthesizing statechart diagrams (or equivalent) from a set of sequence diagrams. It is also sometimes sensible to consider incremental transformations with signature trans: T1xT2 → T2. In this case the transformation operation adds the information of a diagram of type T1 to an existing diagram of type T2, producing a new diagram of type T2. For example, the information contained by a sequence diagram can be merged with an existing statechart diagram using an incremental version of the statechart synthesis algorithm (Systä, 200b). Similarly, the same information can be merged with an existing class diagram. Note that it is possible to take advantage of the existing diagram of type T2 in the interpretation of the diagram of type T1. For example, the existence of a composite relationship between two classes can be guessed from a sequence diagram. However, an existing class diagram may show an aggregation relationship between these classes, thus invalidating the heuristic conclusion. There are also other possible signatures to be considered, such as T1xT2 → T3. One such example might be the transformation from class diagrams and sequence diagrams into a component diagram. Here a set of sequence diagrams might be used to deduce interfaces used by classes to communicate with each other (Koskinen et al., 2001a), and the class diagram would describe, among other things, the host components of different classes. These operations are, however, beyond the scope of this paper. UML provides three extension mechanisms for attaching additional information to the diagrams: stereotypes, tagged values, and constraints. These extension mechanisms can be exploited in transformation operations, provided that the CASE tool used supports them. Stereotypes can be regarded as (possibly user-defined) new metamodel (sub)classes, while tagged values can be regarded as additional attributes of model elements. Constraints, given as either formal or informal logical expressions, restrict the set of possible systems satisfying the model. Such mechanisms are particularly useful when transforming diagrams in the reverse engineering direction, that is, from less abstract diagrams to more abstract diagrams. For example, if classes are attached with tagged values indicating their Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited. 44 Journal of Database Management, 14(3), 37-55, July-Sept 2003 host components, this information can be exploited for extracting an architectural model of a system as a component diagram (see section on supported transformations). CLASSIFICATION OF TRANSFORMATIONS BETWEEN UML DIAGRAM TYPES In this section we will categorize meaningful transformation operations between different diagram types in UML. UML provides nine different diagram types: class diagram (CLD), sequence diagram (SED), collaboration diagram (CBD), statechart diagram (SCD), activity diagram (ACD), object diagram (OBD), component diagram (CMD), deployment diagram (DED), and use case diagram (UCD). The transformation operations have different characteristics in terms of the information passed from the source to the target diagram. We recognize the following four categories of transformation operations: full transformations, strong transformations, supported transformations, and weak transformations. These categories are implied by the varying strength of relations between different pairs of diagram types: the weaker the relation, the more user interaction and guidance is required to make the operation useful. The categorization facilitates the discussion and specification of the operations. In a full transformation operation, the amount of information present in the source diagram is (almost) fully conveyed to the target diagram. These diagram pairs share the same metamodel, making the interpretation of the transformation an identity relationship. Hence, a full transformation is essentially a visual operation where a different diagram is produced for the same model. Strong transformations are based on semantic relationships between diagram types having different metamodels. The core of a strong transformation is based on applying the minimum principle and the push approach. The interpretation of the core transformation is obtained by collecting the mappings defined by the OMG (2001). Used together with a set of heuristic rules applying the maximum principle and the pull approach, a significant amount of information from the source diagram can be conveyed to the target diagram. Although some information will be lost, the target diagram represents a sensible model of some aspect of the system. Supported transformations are based on conventions and user interaction. They rely more on the usage of the maximum principle and the pull approach and are bound to lose more information during the transformation process than strong transformations. The set of conventions can be seen as extensions of the predefined UML semantics. Finally, a weak transformation typically produces only a diagram skeleton as a starting point for design. Figure 5 shows the full, the strong, and the supported transformation relationships between UML diagrams. In Figure 5 the diagram types are arranged so that the upper diagram types focus on structure while the bottom diagrams focus on behavior. The figure also suggests a central role for sequence diagrams, statechart diagrams, and class diagrams in the software development process. In many contexts it is sensible to consider the source code of a system as a model of the system as well. This viewpoint implies yet another class of transformations: transformations from UML models to source code and vice versa. Such transformations are generally called code generation and reverse engineering, respectively. These Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited. Journal of Database Management, 14(3), 37-55, July-Sept 2003 45 Figure 5: Supported, Strong, and Full Transformations Between UML Diagrams Object Diagram Deployment Diagram Component Diagram Class Diagram Sequence Diagram Collaboration Diagram Statechart Diagram full transformation strong transformation supported transformation transformations fall beyond the scope of this paper, but in principle they can be divided into the four categories as well. Full Transformations Within a full transformation, the target diagram contains (almost) the same information as the source diagram. This kind of transformation is possible only between semantically close diagram pairs. There exist two such diagram pairs: SED ↔ CBD and SCD ↔ ACD. Only minor visual information may be lost, like some links in a collaboration diagram not corresponding to message exchange. Indeed, sequence diagrams and collaboration diagrams are not distinguished from each other in the UML metamodel. Sequence diagrams and collaboration diagrams share essentially the same semantic information. While sequence diagrams emphasize the order of the messages in an interaction, collaboration diagrams focus more on the configuration of the interacting objects. The Activity Diagram transformation does not produce significant new information. With statechart diagrams and activity diagrams, the UML metamodel describes an activity diagram essentially as a specialization of the statechart diagram metamodel, added with the Partition and ClassifierInState metaclasses. Transforming a set of statechart diagrams into an activity diagram is therefore straightforward. The other direction can also be defined by mapping the activity diagram elements into more general statechart diagram elements. However, these two diagram types are mostly used for rather different purposes: SCD for state modeling and ACD for process modeling. This difference is reflected in UML 2.0 (see Discussion). By using these four full transformations, we can assimilate the two semantically close diagram pairs. This way, any other transformation having a collaboration diagram as its target diagram can be performed via a sequence diagram, and the same applies to an activity diagram, Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited. 46 Journal of Database Management, 14(3), 37-55, July-Sept 2003 respectively, reducing the number of transformation operations needed. Strong Transformations A strong transformation can be defined between diagrams having a rich set of semantic relationships. The target diagram contains a significant amount of information and is close to a diagram that a person might have drawn by hand for the same part of the system model. Figure 5 shows six strong transformations between diagram types. Provided that sequence diagrams can be constructed on the basis of the use cases, strong transformation operations support the engineering process up to the generation of code. Strong transformations are further discussed in the next section. One could expect there to be interesting direct transformations between use case diagrams and those diagram types commonly used to model the behavior of use cases: activity diagrams, collaboration diagrams, and sequence diagrams. However, there is too little information in a use case diagram for that purpose. This can be regarded as a flaw in UML (D’Souza and Wills, 1999, Sect. 4.3). Supported Transformations A supported transformation is defined between two diagram types that do not share a significant amount of data on the metamodel level. In this case, the designer provides the additional information, for example, by using the UML extension mechanisms. The transformation produces a diagram with a significant amount of information, but only when supported by additional information; without such support the transformation becomes weak in general. An example of a useful supported transformation is CLD → CMD. It is assumed that the designer assigns the proper standard tagged value (“location”) to classes, indicating thus the component containing the class. Then it is possible to automatically generate a component diagram where classes are collapsed into components. This transformation can be further improved by introducing heuristics for identifying disjoint groups of classes interconnected only by a set of interfaces, and using these groups as an additional criterion for constructing components. This approach is useful both in abstracting class diagrams and in identifying components. Similar techniques can be used to generate deployment diagrams from class diagrams. A different example of a supported transformation is SCD → CLD. This transformation can be defined as a strong transformation, but there is also another way of defining it: class-based implementation of statechart diagrams. In this approach, the underlying state machine is objectified by following a set of userdefined transformation rules, possibly following an appropriate design pattern (e.g., the State pattern by Gamma, Helm, Johnson, and Vlissides, 1995, 305-313). In this case the additional information consists of these transformation conventions. This kind of transformation is somewhat different in character when compared to other strong or supported transformations in the sense that it is not based on the logical relationships between the metamodels of the source and target diagrams, but rather on a certain implementation scheme. In a sense, this operation resembles code generation. Weak Transformations In a weak transformation, the target diagram contains only a small amount of Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited. Journal of Database Management, 14(3), 37-55, July-Sept 2003 47 information, but could be nevertheless exploited as a diagram template that can be used as a starting point for constructing a new diagram. One example of a convenient weak transformation is CLD → SED. This weak transformation creates a sequence diagram with a participant for each class in the class diagram, with no events. This skeletal sequence diagram can be used as a prefilled form for describing an interaction between instances in a particular subsystem, represented as a class diagram. STRONG TRANSFORMATIONS IN UML Figure 6 separates object diagrams, class diagrams, sequence diagrams, and statechart diagrams into four different categories and shows the strong transformations between them. The selected diagrams are generally considered as being the most important ones, and they have been well established in software modeling long before UML itself emerged, statechart diagrams originally pre-dating even OOA/OOD. The figure also highlights that the behavioral diagrams contain essentially more information than structural diagrams. While the sequence diagram has a strong transformation to each of the three other diagram types, the class diagram is not a source diagram for any strong transformation. This is natural, since with UML diagrams, structure does not define behavior, only restricts it, but behavior has structural implications. In what follows, we take a closer look at four strong transformations, two of which have a sequence diagram as the source diagram, and the other two a statechart diagram. The remaining two transformations have the following rough interpretations: SED → OBD: This strong transformation creates those instances that participate in the sequence diagram, together with links implied by sent messages. OBD → CLD: This strong transformation represents a design-byexample case: the object diagram is an instance of a class diagram. Associations (and to some extent their multiplicities) can structure behavior example OBD SED specification Figure 6: Strong Transformations Between UML Structural and Behavioral Diagrams CLD SCD Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited. 48 Journal of Database Management, 14(3), 37-55, July-Sept 2003 be inferred from the links in the object diagram. From Sequence Diagrams into Class Diagrams Our interpretation of SED → CLD is as follows. First, we apply the minimum principle with the push approach by translating the elements in a sequence diagram into a class diagram. At this stage the classifier roles and messages of a sequence diagram are mapped to classes, associations, and operations of a class diagram. This mapping is fairly straightforward: if there is a message between two objects then there must be an association between the classes of the objects, and the class of the receiving object must have the corresponding operation. Second, we apply the maximum principle with the pull approach. We use a collection of heuristics to generate interface hierarchies, composition relationships, and multiplicities. Applying these heuristics can be seen as using the pull approach and maximum principle, where we try to use the dynamic information and call patterns contained by a sequence diagram to generate additional structural information that might otherwise be lost during the transformation operation. As an example, if an object interacts with several instances of the same class, the rules suggest to add a multiplicity symbol (*) to the association generated from this interaction. These rules are discussed in more detail by Selonen, Koskimies, and Sakkinen (2001). The heuristics may be seen as “educated guesses” made by the system. The suggestions given by these kinds of rules are uncertain by nature, but plausible. By using the additional heuristics, we can obtain a much richer class diagram that manages to preserve also non-obvious dynamic features. Even if the results suggested by the heuristics are not desired, they can focus a designer’s attention to possible mismatches and errors. The suggestions give useful hints for the designer and inform her about the appearance of certain types of patterns in the sequence diagrams that may have implications in a class diagram. For example, a multiplicity symbol appearing in the produced class diagram indicates that the association is used to access several objects at run-time. It should be noted that in a practical implementation a transformation operation should operate semi-automatically, so that the designer can guide the transformation process. For example, she could decide whether or not to apply the heuristic rules or give additional information when appropriate. As an example of concrete use of this transformation operation, consider a use-case-driven process, such as the Unified Process (Jacobson, Booch, and Rumbaugh, 1999). Given a realization of a use case as a set of sequence diagrams, their structural implications can be conveyed into a new class diagram that can be combined with an existing class model, thus supporting incremental and iterative software development. Conversely, the information extracted from the sequence diagrams can be compared against an architectural model for consistency and completeness. Figure 7 shows a screenshot from an actual prototype tool (Koskinen, Peltonen, Selonen, Systä, and Koskimies, 2001b) facilitating the combination of model operations. Here the tool has been used to define a script that first transforms a set of sequence diagrams, describing a realization for a use case, into a class Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited. Journal of Database Management, 14(3), 37-55, July-Sept 2003 49 diagram. This class diagram is then merged with an existing class diagram using a union operation. From Sequence Diagram into Statechart Diagram We adopt the interpretation of SED → SCD from Koskimies, Männistö, Systä, and Tuomi (1998), where an algorithm is given for synthesizing a minimal state machine from a set of sequence diagrams automatically. The algorithm first extracts a trace from the sequence diagrams by traversing the lifeline of the object of interest from top to bottom in each sequence diagram. The algorithm then maps items in the message trace to transitions and states in a state machine. Sent messages are regarded as primitive actions associated with states. Each received message is mapped to a transition. A synthesized state machine is deterministic, i.e., there cannot be two similarly labeled leaving transitions in any particular state, unless their guards are mutually exclusive. In other words, the synthesis algorithm does not allow two applicable transitions to be simultaneously satisfied. In addition, the algorithm does not allow a completion transition and a labeled transition to leave the same state unless their guards differ. The synthesis algorithm gives a deterministic state machine with the lowest possible number of states. In a use-case-driven software development process, the designer can exploit this kind of transformation operation by expressing a use case as a set of sequence diagrams, and constructing a first approximation for the behavioral specification of an interesting participant of the sequence diagrams as a statechart diagram automatically. Using the incremental version of the transformation operation, one can add the new behavior implied by an additional use case, expressed as a sequence diagram, to the existing statechart diagrams. This process can be further elaborated by using MAS (Mäkinen Figure 7: Combining Model Operations Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited. 50 Journal of Database Management, 14(3), 37-55, July-Sept 2003 and Systä, 2001), an interactive and learning algorithm for statechart diagram synthesis. From Statechart Diagram into Sequence Diagram Conversely to the statechart diagram synthesis, the designer can also transform a set of statechart diagrams into a sequence diagram. A sequence diagram can be generated by simulating a set of statechart diagrams. Following the process described by Systä (2000b), the transformation can be defined on the metamodel level as follows. Actions are messages sent or actions performed by the object whose behavior is described by the statechart diagram. Event triggers of transitions are messages received by the object. Actions that are attached to transitions or states are transformed to corresponding actions of an interaction. These actions imply messages and classifier roles. Also, signal events and call events associated with transitions or states are mapped into send actions and call actions, respectively. This transformation operation is defined using the pull approach, since on the metalevel a statechart diagram in itself does not share information with a sequence diagram. The nature of this transformation operation differs from most of the other transformation operations in principle: if the set of statechart diagrams is not a complete specification, the designer might have to include stimuli for running the diagrams. The external stimuli can be given as a statechart diagram as well, defining the response of an external actor to the output of the system. In a typical software development process, a designer might exploit this kind of transformation operation to find dynamic information that is currently not captured in the model of the system explicitly. For example, the produced sequence diagrams may reveal dynamic communication patterns that can be identified by the heuristics applied in the SED → CLD transformation, thus making the information eventually available in a class diagram. From Statechart Diagram into Class Diagram Unlike the transformation SCD → SED discussed above, the SCD → CLD transformation is performed between two diagram types describing specifications rather than examples. The transformation reveals the static class structure implied by a statechart diagram (or a set of statechart diagrams). In general, our interpretation of the transformation is as follows. Signal events of transitions and states are mapped into signals and ultimately to behavioral features defining their context. Call events are mapped into operations of classifiers. Send actions and call actions are mapped into signals and behavioral features, and operations, respectively. Actions are also used for inferring stimuli and corresponding links that are in turn mapped into associations and association ends of classifiers. Finally, the context of the state machine is mapped into the classifier for which the behavior is defined. In a software development process, this kind of operation can be typically used for two purposes. It either produces a static, structural model for a system based on its description as a set of state machines, or it checks that the behavioral model expressed as a set of statechart diagrams agrees with the static model of the system. In the former case the generation of a class diagram might be a first step towards Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited. Journal of Database Management, 14(3), 37-55, July-Sept 2003 51 implementing a system based on an abstract set of state machines. In the latter case, the produced class diagram would be compared against an existing, handwritten one. RELATED WORK Research work related to single transformation operations between different diagram types has been carried out by several authors. However, to the best of our knowledge, research work dealing with a complete framework of UML transformation operations has been so far more or less neglected. Issues on how to extract static model information from a set of scenarios are discussed by Nørmark (1998). Synthesizing UML statechart diagrams from a set of collaboration diagrams are analyzed by Schönberger et al. (2001). Synthesizing statechart diagrams from interaction diagrams is investigated by Whittle and Schumann (2000) and Harel and Kugler (2000). Synthesizing class diagrams from object diagrams is presented by Engels, Heckel, Taentzer, and Ehrig (1997). These papers go into detail on how to define individual transformation operations, but each concentrates only on one particular operation type. FUJABA (Köhler, Nickel, Niere, and Zündorf, 2000) is a UML case tool providing operations for manipulating UML models of different types. However, FUJABA works at a lower level of abstraction, focusing on using UML rather as a visual programming language for producing code. Egyed (1999) introduces a view integration framework with operations for mapping, transformation, and differentiation as major activities in order to identify design mismatches using UML for system architecting. His work does not focus on individual transformation techniques but rather discusses how these activities can be used together. Our work categorizes these operations and emphasizes the usage of the standard UML metamodel when defining them. Transformations are closely related to consistency checking: in essence, a transformation defines the information that must be shared by consistent diagrams. Bodeveix et al. (2002) introduce a tool called NEPTUNE for checking the consistency of different UML models. In that work, the consistency criterion is defined in terms of (extended) OCL (OMG, 2001, Sect. 6). For example, to check that a class diagram is consistent with a sequence diagram, an OCL expression can be given which applies the same principles as our transformation operation to infer possible conflicts. Hence NEPTUNE assumes the additional specification of consistency rules whereas we rely only on the information included in the UML model itself. DISCUSSION We have shown that meaningful transformation operations can be defined between several pairs of diagram types in UML. When supported by appropriate tools, such operations can automate a substantial part of both forward and reverse engineering. We are currently implementing the transformation operations discussed here in an industrial software development environment, TED (Airaksinen et al., 2002). Implemented operations include SED → CLD, SED → SCD, SED → OBD, SED → CBD, SCD → SED, SCD → CLD, CBD → SED, and CLD → CMD (Koskinen et al., 2001a, 2001b; Selonen, Systä and Koskimies, 2001; Systä, 2000a; Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited. 52 Journal of Database Management, 14(3), 37-55, July-Sept 2003 Systä, 2000b; Mäkinen and Systä, 2001). We are also planning to carry out a realscale industry case study of using our operations in order to evaluate the techniques presented in this paper. Our approach raises other research issues as well. For example, it is extremely important that the synthesized diagrams have reasonable layout, because rearranging the layout can be a notable burden for a user. Current layout algorithms are intended for regular structures like graphs and trees, and in practice work quite poorly for UML diagrams that may contain nodes of different sizes, and arcs with different semantics. In addition, large diagrams (generated, e.g., from source files) need special mechanisms for collapsing parts of the diagram so that only one relevant abstraction layer is shown to the user at a time (e.g., Dósa Rácz and Koskimies, 1999). These issues will be among the topics of our future research. Another research issue is the nature of the required tool support for the transformation operations. We are currently experimenting with the idea of using visual scripts, based on UML activity diagrams, to allow the user to control the execution of the transformation operations (Peltonen, 2000; Peltonen and Selonen, 2001). In UML 2.0, major changes have been proposed for activity diagrams and sequence diagrams. Activity diagrams in UML 2.0 are based on Petri-net-like semantics, thus there is no longer a full transformation between these diagram types. Sequence diagrams have mainly been extended with new features and improved notations. The results concerning sequence diagrams will therefore likely apply to UML 2.0 as well; in some transformations it may even be possible to preserve more information than in UML 1.4. ENDNOTE 1 Currently at the Information Technology Research Institute, University of Jyväskylä, Finland. ACKNOWLEDGMENTS The authors wish to thank Tarja Systä and Timo Poranen for their valuable comments, and the anonymous reviewers for useful suggestions. This work has been financially supported by the National Technology Agency of Finland (TEKES), the Academy of Finland,and our industrial partners (Nokia, Metso, Plenware, Solita and Ebsolut. REFERENCES Airaksinen J., Koskimies K., Koskinen J., Peltonen J., Selonen P., Siikarla M., & Systä T. (2002). xUMLi: Towards a Tool-independent UML Processing Platform. In: K. Østerbye (Ed.), Proceedings of NWPER 2002, Copenhagen, Denmark: IT University of Copenhagen. Bodeveix, J-P., Millan, T., Percebois, C., Le Camus, C., Bazex, P., & Feraud, L. (2002). Extending OCL for verifying UML models consistency. In L. Kuzniarz, G. Reggio, J.L. Sourrouille, & Z. Huzar (Eds.), <<UML>> 2002 Workshop on Consistency Problems in UML-based Software Development. (Research Report 2002:06) (pp. 75-90). Ronneby, Sweden: Blekinge Institute of Technology. Booch, G., Rumbaugh, J., & Jacobson, I. (1999). The Unified Modeling Language User Guide. Reading, MA: Addison-Wesley. Dósa Rácz, F. & Koskimies, K. (1999). Tool-supported compression of UML class diagrams. In R. France, & B. Rumpe (Eds.), Proceedings of Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited. Journal of Database Management, 14(3), 37-55, July-Sept 2003 53 <<UML>>’99, Fort Collins, CO, October (pp. 172-187). Berlin & Heidelberg: Springer. D’Souza, D.F. & Wills, A.C. (1999). Objects, Components, and Frameworks with UML: The Catalysis Approach. Reading, MA: Addison-Wesley. Egyed, A. (1999). Integrating Architectural Views in UML. (Technical Report USCCSE-99-514) Los Angeles, CA: Center for Software Engineering, University of Southern California. Engels, G., Heckel, R., Taentzer, G., & Ehrig, H. (1997). A combined reference model- and view-based approach to system specification. International Journal of Engineering and Knowledge Engineering, 7(4), 457-477. Frank, H. & Eder, J. (1998). Integration of Statecharts. In Proceedings of CoopIS’98, New York City, NY, August (pp. 364-372). Los Alamitos, CA: IEEE Computer Society. Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1995). Design Patterns Elements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley. Harel, D. & Kugler, H. (2000). Synthesizing state-based object systems from LSC specifications. In S. Yu & A. Paun (Eds.), Proceedings of CIAA 2000, London, Ontario, Canada, July (pp. 1-33). Berlin & Heidelberg: Springer. Henderson-Sellers, B. (2001). Some problems with the UML V1.3 metamodel. In Proceedings of HICSS-34 (CD-ROM), Decision Technologies for Management Track, Maui, HA, January. Los Alamitos, CA: IEEE Computer Society. Jacobson, I., Booch, G., & Rumbaugh, J. (1999). The Unified Software Development Process. Reading, MA: Addison-Wesley. Köhler, H., Nickel, U., Niere, J., & Zündorf, A. (2000). Integrating UML diagrams for production control systems. In: Proceedings of ICSE’00, Limerick, Ireland, June (pp. 241-251). New York: ACM Press. Koskimies, K., Männistö, T., Systä, T., & Tuomi, J. (1998). Automated support for modeling of OO software. IEEE Software, 15(1), 87-94. Koskinen, J., Peltonen, J., Selonen, P., Systä, T., & Koskimies, K. (2001a). Towards tool assisted UML development environments. In T. Gyimóthy (Ed.), Seventh Symposium on Programming Languages and Tools, SPLST’2001, Szeged, Hungary, June (pp. 1-15). Szeged, Hungary: University of Szeged. Koskinen, J., Peltonen, J., Selonen, P., Systä, T., & Koskimies, K. (2001b). Model processing tools in UML. In Proceedings of ICSE 2001, Toronto, Canada, May (pp. 819-820). Los Alamitos, CA: IEEE Computer Society. Leite, J. C. S. P. & Freeman, P. A. (1991). Requirements validation through viewpoint resolution. IEEE Transactions on Software Engineering, 17(12), 12531269. Mäkinen, E. & Systä, T. (2001). MAS - An interactive synthesizer to support behavioral modeling. In: Proceedings of ICSE 2001, Toronto, Canada, May (pp. 15-24). Los Alamitos, CA: IEEE Computer Society. Nørmark, K. (1998). Synthesis of Program Outlines from Scenarios in DYNAMO. Available online at: http:// www.cs.auc.dk/~normark/dynamo.html. OMG The Object Management Group (2001, September). The Unified Modeling Language Specification v1.4. Available online at: http://www.omg.org/ uml. Peltonen, J. (2000). Visual scripting for UML-based tools. In Proceedings of ICSSEA 2000, Paris, France, December Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited. 54 Journal of Database Management, 14(3), 37-55, July-Sept 2003 (vol. 3). Paris, France: CNAM. Peltonen, J. & Selonen, P. (2001). Processing UML models with visual scripts. In Proceedings of HCC’01, Stresa, Italy, September (pp. 264-271). Los Alamitos, CA: IEEE Computer Society. Rational Software Corporation (2002, October). Rational Rose Product Family. Available online : http://www.rational.com/ products/rose. Rumbaugh, J., Jacobson, I., & Booch, G. (1999). The Unified Modeling Language Reference Manual. Reading, MA: Addison-Wesley. Schönberger, S., Keller, R. K., & Khriss, I. (2001). Algorithmic support for model transformation in object-oriented software development. Concurrency and Computation: Practice and Experience, 13(5), 351-383. Selonen, P., Koskimies, K., & Sakkinen, M. (2001). How to make apples from oranges in UML. In Proceedings of HICSS-34 (CD-ROM), Decision Technologies for Management Track, Maui, HA, January. Los Alamitos, CA: IEEE Computer Society. Selonen, P., Systä, T., & Koskimies, K. (2001). Generating structured implementation schemes from UML sequence diagrams. In L. Qiaoyun, R. Riehle, G. Pour, & B. Meyer (Eds.), Proceedings of TOOLS USA, Santa Barbara, California, USA, July-August (pp. 317-328). Los Alamitos, CA: IEEE Computer Society. Seltveit, A. (1996). An approach to information systems modelling based on systematic complexity reduction. In Proceedings of HICSS-29, Volume 2: Decision Support and KnowledgeBased Systems, Maui, HA, January (pp. 251-260). Los Alamitos, CA: IEEE Computer Society. Systä, T. (2000a). Static and Dynamic Reverse Engineering Techniques for Java Software Systems. Technical Report A-2000-4, Department of Computer and Information Sciences. Tampere, Finland: University of Tampere. Systä, T. (2000b). Incremental construction of dynamic models for objectoriented software systems. Journal of Object-Oriented Programming (JOOP), 13(5), 18-27. Whittle, J. & Schumann, J. (2000). Generating statechart designs from scenarios. In Proceedings of ICSE’00, Limerick, Ireland, June (pp. 314-323). Los Alamitos, CA: IEEE Computer Society. Petri Selonen is currently a Research Scientist and a PhD student at the Institute of Software Systems, Department of Information Technology in the Tampere University of Technology, Finland. He received his MSc degree majoring in Software Engineering in 1997. Before starting his research on UML and automatic tool support for software engineering in 2000, he worked as a Group Manager for a company specializing in traffic and passenger information systems. Kai Koskimies has been appointed a Professor of Software Engineering at the Tampere University of Technology in 1999. Before that he worked as a Senior Project Manager at Nokia Research Center and as a Professor at the University of Tampere. He has been a Visiting Researcher at GMD Karlsruhe, Germany and at the University of Linz, Austria. He is currently working as a Visiting Researcher Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited. Journal of Database Management, 14(3), 37-55, July-Sept 2003 55 at the University of Groningen, The Netherlands. His research interests include software modeling techniques, software architectures, software product-lines, and object-oriented frameworks. Markku Sakkinen is a Professor at the Department of Computer Science and Information Systems in the University of Jyväskylä, Finland. He graduated majoring in Mathematics, but after that worked in various EDP jobs both at the university and in industry for about 15 years. After his PhD in Computer Science (1992), he worked also at the universities of Frankfurt am Main (Germany) and Linz (Austria) and at the Tampere University of Technology. Dr. Sakkinen’s main research area has been object-oriented programming languages, with an emphasis on inheritance, but his interests also include object-oriented databases. He is probably best known as a critic of C++ since 1988. He was the Organizing Chairperson of ECOOP ’97 in Jyväskylä. Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.