Proceedings of the 34th Hawaii International Conference on System Sciences - 2001
How to Make Apples from Oranges in UML
Petri Selonen, Kai Koskimies and Markku Sakkinen1
Tampere University of Technology
Software Systems Laboratory
P.O. Box 553
FIN-33101 Tampere, Finland
+358 3 365 3889
{pselonen, kk}@cs.tut.fi, [email protected]
Abstract
Unified Modeling Language (UML) provides various
diagram types for describing a system from different
perspectives or abstraction levels. Hence, various UML
models of the same system are dependent and strongly
overlapping. This paper discusses various general
approaches and viewpoints of model transformations in
UML. The possible source and target diagram types are
analyzed and categories are given for different
transformations. It is argued that such transformations
should be defined in terms of the UML metamodel, rather
than on the level of the actual diagrams. A detailed
example of a transformation operation from sequence
diagrams into class diagrams is presented to illustrate
such operations. It is concluded that the transformation
operations can automate a substantial part in both
forward and reverse engineering. These operations can
be used, for example, for model checking, merging,
slicing, and synthesis.
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 all diagram
types in a systematic way.
Model2
Model1
Model3
1. Introduction
System
UML [12,13,15] has become an industrial 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 from different abstraction levels.
Hence, the various UML models of the same system are
not independent specifications but strongly overlapping:
they depend 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. This is illustrated in Figure 1.
1
Figure 1. Different UML models describe
overlapping parts of the same system and are
therefore dependent of each other.
In this paper we study the relationships of different
diagram types 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). We consider such
transformation operations as an essential part of a UML-
Currently at the University of Jyväskylä, Finland.
0-7695-0981-9/01 $10.00 (c) 2001 IEEE
1
Proceedings of the 34th Hawaii International Conference on System Sciences - 2001
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.
the role of the UML metamodel in the transformation
operations in Section 2.
We argue that the transformation operations described
in this paper can be used as a basis of tool support in any
UML-based CASE environment. The expected benefits of
this approach are the following:
-
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. 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.
Although we speak about diagrams in this paper, it
should be noted that the UML makes a clear distinction
between the visual presentation, i.e., the diagrams, and
their underlying models. In principle, the models
corresponding to the different diagram types are not
separate, but they all belong to the same system model,
which is an instance of the UML metamodel.
Many things that are "transformed" on the diagram
level can thus be considered to be shared between the
different models on the model level. For instance, in the
transformation from sequence diagram to class diagram
(Section 5), for each class there exists only one model
element (metaobject), and this element is shared by the
two diagrams. It would be shared also by any other
diagrams where the same class appears. We will discuss
-
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
abstraction level of the source diagram is same or
higher than that of the target diagram. In the latter,
the abstraction level of the source diagram is usually
lower than that of the target diagram. Forward and
reverse engineering aspects of UML models have
been considered also in [1], but mostly with respect to
code rather than to other UML models. We argue that
internal 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 on
different abstraction levels.
Tool support can be made more customizable,
because transformation operations can be used 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 the other diagram
type etc.
Note that some of the usage scenarios rely on the
existence of operations that produce a union or
intersection of two diagrams of the same type. Although
such basic diagram operations are not trivial (and indeed
not even sensible for certain diagram types), we will
ignore them in this paper since the problems of such "set"
operations are essentially different from transformation
operations.
In Section 3 we will present various general
approaches for diagram transformations, with several
examples. In Section 4 we will examine the
transformations between particular diagram types in
UML. In Section 5 a detailed case study of a particular
transformation operation is presented, transformation of
sequence diagrams into class diagrams. Related work is
discussed in Section 6. Finally, some concluding remarks
0-7695-0981-9/01 $10.00 (c) 2001 IEEE
2
Proceedings of the 34th Hawaii International Conference on System Sciences - 2001
concerning the future directions of this research are
presented. We assume the knowledge of UML throughout
the paper. This work is part of ATOS project carried out
under TEKES grant 40908/98.
2. Using the UML metamodel in
transformation operations
The architecture of the UML is based on a four-layer
metamodel structure, which consists of the following
layers: user objects, model, metamodel and 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. In a sense,
UML is used to describe itself, as is common with
modeling languages.
We use the metamodel to define our transform
operation for several reasons. First, since UML is
standardized, the metamodel describes all the relevant
information a UML diagram and a model can contain.
Secondly, while it is reasonable to assume that a practical
UML modeling tool has its internal data model more or
less based on the UML metamodel, they typically differ
from each other. We transform the model information
from a tool-specific data model into the standard UML
metamodel form, perform the operation inside the
metamodel layer and then transform the resulting model
back to the tool-specific data model. This way we can
make the core of our operation independent of a particular
design tool. Finally, the implementation platform in our
project, the Nokia TED, already supports a reasonably
large subset of UML metamodel as a component library,
thus allowing us to operate more easily directly with the
tool data.
We divide the transformation operation into three
distinctive phases as illustrated in Figure 2.
A
B
C
View
B
D
C
Tool-Specific
Layer
Mapping
Model
A
UML Metamodel
Instance Layer
Operations
Figure 2. Phases of the transform operation
First, we take the view of a sequence diagram and map
that view to a sequence diagram metamodel instance.
After converting the information inherent in the sequence
diagram to the metamodel instance form, we then further
map this collaboration metamodel instance to a form
required by a class diagram. Here we use the
Core/Backbone and Core/Relationships packages [12] in
order to show the classes, their operations and
relationships. Finally, this information is converted back
to a tool-specific form. We will discuss these phases in
more detail in Section 5.
3. Techniques for UML diagram
transformation operations
There can be several levels of confidence in a
transformation operation. In the strictest form we require
that the information in the target diagram is guaranteed to
be correct, provided that the source diagram is correct. 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 useful heuristics
that produce the desired results usually although not
always. We will present examples of such heuristics in
Section 5.
To find a mapping from one diagram type to 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.
Examples of both push and pull approaches will be given
in the case study of Section 5.
In some cases a transformation operation can preserve
all the information in the source diagram. This is the case
for diagram type pairs that represent different notations
for the same modeling aspect. There is one such pair in
UML: collaboration and sequence diagrams (there are
some minor details that cannot be directly represented in
both types).
The existence of two different notations for the same
thing can be regarded as a design flaw in UML, but on the
other hand there are clear benefits of both notations. A
0-7695-0981-9/01 $10.00 (c) 2001 IEEE
3
Proceedings of the 34th Hawaii International Conference on System Sciences - 2001
transformation operation between sequence and
collaboration diagrams can be useful, for example, for
arranging the order of events in a collaboration diagram.
The collaboration diagram can be first transformed into a
sequence diagram where it is easy to edit the order of
events (due to the vertical time axis), and then
transformed back into a collaboration diagram.
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. 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 single objects can
be given as statechart diagrams. There are several
algorithms (e.g. [10], [16]) synthesizing statechart
diagrams (or equivalent) from a set of sequence diagrams.
Another example could be the synthesis of a class diagram
on the basis of statechart diagrams: since a statechart
diagram concerns usually a single class, the class diagram
produced on the basis of a statechart diagram would be
rather trivial. However, a more sensible class diagram can
be produced on the basis of a set of statechart diagrams.
Each statechart diagram gives rise to a class with the
operations (or signals) implied by the events appearing in
the diagram, and sending an event between the state
machines of two classes yields an association between the
classes.
It is also sometimes sensible to consider incremental
transformation 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 [10]. 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 inferred from a sequence
diagram using certain heuristics (see Section 5). However,
an existing class diagram may show an aggregation
relationship between these classes, thus invalidating the
heuristic conclusion.
UML provides two extension mechanisms that can be
exploited in transformation operations to attach additional
information to the diagrams: stereotypes and tagged
values. Stereotypes are (possibly user-defined) new
metamodel (sub)classes, while tagged values can be
regarded as additional attributes of model elements.
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, it would be very difficult
to generate more than a trivial use case diagram from an
arbitrary class diagram. However, if classes are attached
with a tagged value indicating the use case(s) this class
participates in, and actor classes are marked with
stereotype «actor», a sensible use case diagram can be
generated. A similar example would be the generation of
component diagrams from class diagrams: if the
component a class belongs to is indicated as a tagged
value in a class symbol, a sensible component diagram
can be generated as a projection of the class diagram on
components. Comment boxes are yet another way to
present additional information in UML diagrams, but they
may clutter up a diagram when used excessively.
Hyperlinking is a mechanism that is not included in the
actual UML but that would be useful in connection with
the transformation operations. Although UML does not
directly support hyperlinks, they can (and hopefully will)
be introduced on the tool level. Hyperlinks provide yet
another way to associate additional information to model
elements, in this case as references to other model
elements. Since hyperlinks are (almost) invisible in the
UML diagrams, they do not clutter the diagrams even
when heavily used. For example, hyperlinks could be used
to indicate the origin of a certain model element in the
target diagram, pointing to the element in the source
diagram that was the "reason" for the element in the target
diagram. This could be used as a primitive tracing
mechanism in a software development process exploiting
model transformations.
Sometimes a useful transformation may require userdefined transformation rules. For example, there could be
a variant of a transformation operation producing a class
diagram from a single statechart diagram, assuming a
particular class-based implementation scheme for state
machines (e.g. the State design pattern [7]).
Finally, it should be noted that the source code can be
regarded as an ultimate model of a system. Although
transformation operations from source code to different
UML diagrams (that is, conventional reverse engineering)
are beyond the scope of this paper, it is worth mentioning
that the transformation operations discussed here are very
useful when applied to diagrams produced automatically
0-7695-0981-9/01 $10.00 (c) 2001 IEEE
4
Proceedings of the 34th Hawaii International Conference on System Sciences - 2001
from source code. Just as an example, consider the
following scenario: the source code of a system is
instrumented so that when run, it generates a sequence of
events that can be shown as a UML sequence diagram.
This sequence diagram is transformed into a class
diagram, showing that portion of the static structure model
that is involved in a particular use case.
4. Survey of transformations between UML
diagram types
In this section we will briefly summarize meaningful
transformation operations between different pairs of
diagram types in UML. We will use the following
shorthand names for the nine diagram types:
UCD = use case diagram
SED = sequence diagram
CBD = collaboration diagram
OBD = object diagram
CLD = class diagram
SCD = statechart diagram
ACD = activity diagram
DED = deployment diagram
CMD = component diagram
Weak transformation. The target diagram contains only
small amount of information, but could be nevertheless
exploited as a starting point for constructing a new
diagram.
We can unify the two pairs of diagram types that have
full transformation between them, i.e., SED with CBD and
SCD with ACD. This still leaves us 7 diagram types and
thus 7 x 6 = 42 possible transformations. Figure 3 shows 9
meaningful and interesting transformations between
diagram types (in addition to the full transformations), and
4 ones between diagram types and source code. The
diagram types are arranged from left to right according to
the order in which they are typically employed in a
software development process, although this order should
be seen here only as suggestive. (Indeed, the order is far
from ambiguous. For example, class diagrams are often
applied in early stages of the process as well.) Roughly
speaking, the arrows going from left to right therefore
represent forward engineering while the reverse arrows
represent reverse engineering.
SED
In principle, there are 9 x 8 = 72 possible
transformations between these types. We will show how
we can restrict our consideration to a significantly smaller
number of transformations.
First, we divide the transformations into the following
categories:
DED
SCD
UCD
CBD
CLD
Source
ACD
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, SED/CBD and
SCD/ACD. Only minor information may be lost, like the
links in a CBD. If there is a link exactly between objects
exchanging messages, the links do not add any new
information. Indeed, SED and CBD are not distinguished
from each other in the UML metamodel.
Strong transformation. 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.
Supported transformation. The transformation is useful
when supported by additional information given as tagged
values or stereotypes. Without such support the
transformation becomes generally weak or even useless.
OBD
CMD
full transformation
strong transformation
supported transformation
weak transformation
Figure 3. Transformations between UML diagram
types
We will briefly comment on the less obvious
transformation operations:
CLD → UCD: This supported transformation requires
that the classes in the CLD are annotated with the use
cases they participate in.
OBD → CLD: This strong transformation represents a
design-by-example case: the OBD is an instance of a
CLD. Associations (and to some extent their
multiplicities) can be inferred from the links in the OBD.
0-7695-0981-9/01 $10.00 (c) 2001 IEEE
5
Proceedings of the 34th Hawaii International Conference on System Sciences - 2001
SED → CLD: See Section 5.
CLD → SED: This weak transformation generates a
SED with a participant for each class in the CLD, with no
events. This skeletal SED can be used as a pre-filled form
for describing an interaction between instances of a
particular subsystem, represented as a CLD.
SED → SCD: This strong transformation applies state
machine synthesis algorithms, e.g. [10].
SCD → SED: A collection of state machines can be
run with a particular sequence of external stimuli,
producing a trace that can be presented as a SED.
SCD → CLD: There are two alternatives: user-defined
rules can be applied for class-based implementation of
state machines, or a static projection of the
communication connections between the involved classes
can be represented as a CLD. Both transformations are
considered strong.
CLD → DED: This supported transformation requires
that the classes in the CLD are annotated with the nodes
they belong to.
CLD → CMD: This supported transformation requires
that the classes in the CLD are annotated with the
components they belong to.
Figure 3 reveals the central role of sequence diagrams
and class diagrams in the software development process.
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.
In particular, the class diagram looks like the "pivot
element" of UML here, but that is no surprise, of course.
Many transformations can be performed as two-step
compound transformations through the CLD, losing very
little or no information. This pertains to all
transformations involving UCD, as well as those to CMD
and DED and those from OBD.
From all possible transformations, only those from use
case, component and deployment diagrams and those to
object diagrams are thus completely missing from Figure
3. It looks obvious that such transformations would be
desired only very rarely.
One could expect there to be interesting direct
transformations between use case diagrams (UCD) and
those diagram types commonly used to model the
behavior of use cases: ACD, CBD and SED. However,
there is too little information in UCD for that purpose.
This can be regarded as a clear flaw in UML [3, 4.3].
Additional direct transformations could be useful in
some other cases. For instance, both the OBD and the
CBD contain particular objects instead of classes, and
thus some information can be lost when the transformation
is made through the CLD.
5. Transforming sequence diagrams into class
diagrams
This section describes how a sequence diagram can be
transformed to a class diagram inside the standard UML
metamodel. We can divide this transformation operation
into two phases by applying the push and pull approaches
introduced in Section 3. First, we follow the minimum
principle by using the push approach, so we try to
translate the elements in a sequence diagram into a class
diagram. At this stage, we map the classifier roles
(participants) and messages of a sequence diagram to
classes, associations and methods of a class diagram.
Second, we follow the maximum principle by applying the
pull approach. In this phase we use a collection of
heuristic rules to generate interface hierarchies,
composition relationships and multiplicities.
Figure 4 shows an example of a sequence diagram.
This diagram shows a simplified view of a simple
application that reads the input given by an external user
and then propagates this information to a collection of
graphical elements.
main :
CApplication
piechart :
CChart
barchar :
CChart
dialog :
CDialog
display :
CWinManager
getValue
<<create>> okButton :
CButton
<<create>>
cancelButton :
CButton
<<create>>
input :
CDatafield
showDialog
valueUpdated
buttonPressed
hideDialog
<<destroy>>
<<destroy>>
<<destroy>>
update
update
refresh
setCaption
refresh
setCaption
Figure 4. The sequence diagram to be
transformed
1.
The main application asks a dialog object to input a
value from a user
0-7695-0981-9/01 $10.00 (c) 2001 IEEE
6
Proceedings of the 34th Hawaii International Conference on System Sciences - 2001
2.
3.
4.
5.
The dialog object creates two buttons and an input
field and asks to be shown by a window manager
After the external user has given a value and pressed
the OK button, the dialog object asks to be hidden by
the window manager, destroys its contents and returns
the input value to the main application object.
The main application updates the two chart objects,
which in turn ask themselves to be refreshed by
window manager.
Finally, the main application asks to be refreshed by
the window manager.
The UML metamodel, being object-based and highly
non-redundant, does not localize the elements belonging
to a conceptual diagram type to a single metamodel
package. The elements explicitly shown in a sequence
diagram, for example class names and stereotypes, are
expected to reside outside the Collaborations metamodel.
In general, if a practical tool were to support the UML
metamodel as a whole, it would only accept (almost)
complete models, which is not the case in the real world in fact, most of the practical UML tools do quite the
opposite. Thus, for pragmatic reasons, we relax the
requirements of the UML metamodel and assume that the
necessary information can be obtained from the names of
messages and classifier roles as defined in [12].
The transform operation is isolated, meaning that the
only input the operation receives as an operand is the
sequence diagram to be transformed, and the class
diagram resulting from the operation is a new and
independent one. In other words, the transform operation
does not have any extra information about the system
model readily available.
Collaboration
1..*
+interaction
1
ClassifierRole
+sender
+receiver
AssociationRole
+communication
Connection
Interaction
1
+connection
*
+message
AssociationEnd
Role
Message
*
*
+action
Action
Figure 5. A simplified metamodel for
collaborations (modified from [13, p. 3-101])
A simplification of the structure of the collaboration
metamodel is given in Figure 5, modified from [13]. It
shows that a collaboration consists of one or more
interactions. An interaction consists of one or more
messages that are dispatched using an association role. An
association role connects together two or more classifier
roles using association end roles. There is an action linked
with every message.
Figure 6 shows simplification of the class diagram
metamodel, which is adequate for generating classes and
interfaces, their interrelationships, operations and their
parameters. The transformation operation basically
defines a mapping from a metamodel instance conforming
to Figure 5 to a metamodel instance conforming to Figure
6. Details on how these underlying models are visualized
are defined in [13].
+connection
AssociationEnd
Association
1
2..*
*
*
*
+specification
Class
+type
0..1
Classifier
+owner
0..1
1 +type
* +feature
*
Interface
Parameter
*
+parameter
Operation
0..1
Figure 6. A simplified metamodel for class
diagrams.
First, we must define which metamodel elements are
available for the sequence diagram to be transformed.
Figure 5 shows one example of the elements in a sequence
diagram. In practice, we might not have association roles,
association end roles and actions available, which is the
case in many real-life design tools. In fact, the mentioned
elements are actually a part of a collaboration diagram.
We can, if necessary, also generate these possibly missing
elements, but that is not needed in this particular
transformation. Hence, we further simplify the collection
of source elements to only include messages and classifier
roles, their interrelationships and textual representations.
On the other hand, if there does exist additional
information concerning the sequence diagram, such as
actions associated with messages, arguments associated
with these actions and the types of these arguments, we
can naturally take advantage of this extra information.
We use the push approach and the minimum principle
(Section 3) as follows:
-
-
Generate a class for each classifier role with a
distinctive class name. Transfer stereotypes, such as
«actor» and «active» into the respective class.
For each message, if there does not exist an
association between the base classes of the sending
and receiving classifier roles, generate the
corresponding association ends and an association
0-7695-0981-9/01 $10.00 (c) 2001 IEEE
7
Proceedings of the 34th Hawaii International Conference on System Sciences - 2001
-
-
-
-
-
-
-
-
representing the communication connection for the
message in question, and link these together.
For each class receiving a message, if there does not
already exist an operation with the same name,
generate a new operation for the class. Mark the
navigability of the association.
If there are arguments attached to the message,
generate new parameters for the operation with
corresponding UML basic types and type expressions.
Add this operation to the corresponding class if it does
not already have an operation with the same name and
signature.
A message marked with a stereotype «create» or
«destroy» is ignored here, but discussed later in this
section.
If the message is marked with a stereotype «signal»
and there does not exist a signal with the same name,
generate a new signal. Associate the corresponding
class with this signal.
If the message is marked with a stereotype «become»,
the sending and receiving classifier roles are equated
(this rule assumes that an object cannot dynamically
change its type).
If the message has an object appearing in the sequence
diagram as an argument, we add an association
between the corresponding classes of the sending
object and argument object, if there does not exist one
already and the classes are not the same.
If the message is a return message, containing only a
return value of some type, we conclude the return type
of the operation of the preceding message.
The sequence diagram might contain possibly
contradictory information, for example an active and a
passive object of the same class. In this case, the result
of the transformation operation is undefined.
In addition to the basic transformation rules given
above, we can also define more advanced heuristics that
may suggest more elaborate constructs to the user. We
give three examples of such rules: simple interface
heuristics, broadcast heuristics and composition heuristics.
These heuristics represent logical conditions that, when
true, trigger further operations. 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. 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.
When the results obtained by using these heuristics
support our intuition of the design, they support the
correctness of the design. If not, these results can also
focus our attention to possible mismatches and errors.
These heuristics are mainly meant to be used in the design
phase of software development to address views of the
designers and give suggestions and hints.
Next, we describe the three heuristics and also briefly
explain how they are applied to the example sequence
diagram given in Figure 4.
If there exists a class Implementation, the Operations of
Implementation are called by a set of Objects and the Sets of
Operations called by Objects belonging to different classes are
disjoint,
Then generate an interface for each Set having the name of the
Implementation with the character "I" propended and a sequence
number appended, generate a Uses-association between
corresponding classes and interfaces and an Implementsassociation from Implementation to every interface.
Figure 7. Simple Interface heuristics.
If different call patterns can be detected from sending
classes to one receiving class, we can emphasize this by
generating a set of interfaces which this receiving class
implements. This can also be seen as a way to name or
mark associations. In general, it might be desirable to
generate named associations instead of unnamed ones, but
finding a suitable name automatically is very unlikely to
produce a reasonable result. Naming an association simply
on the basis of the operations called is not really a feasible
solution, so interface heuristics can be seen as one
solution to this problem also. Should the designer choose
not to include these interfaces in the resulting class
diagram, these interfaces can still provide valuable
information on the sets of operations different classes use
to communicate with each other.
In Figure 4, class CWinManager is accessed by the
classes CApplication, CChart and CDialog. The two
former classes use the operations refresh and setCaption,
and the latter uses showDialog and hideDialog. Since
these two sets of operations are disjoint, we generate two
separate interfaces that CWinManager implements for
these classes to use.
If there exists an Operation belonging to a class Receiver, there
are several instances of Receiver, there exists an instance of a
class Sender and Sender makes a call action with Operation to
every instance of Receiver,
Then mark the multiplicity of the Receiver end of the
association between Sender and Receiver with '*' (unlimited,
many).
Figure 8. Broadcast heuristics.
If a broadcast message is detected, i.e. an object of one
particular class sends a message to every instance of
another class, then we can conclude that there exists a '*'multiplicity.
0-7695-0981-9/01 $10.00 (c) 2001 IEEE
8
Proceedings of the 34th Hawaii International Conference on System Sciences - 2001
In Figure 4, all objects of the class CChart (piechart,
barchart) are accessed by a single object main of the class
CApplication, and we conclude a many association from
CApplication to CChart.
If there exists an object Composite and an object Part, Part is
created by Composite, Part is destroyed by Composite, and no
other object than Composite sends messages to Part,
Then set the kind of the association between Composite class
and Part class to "composite".
while CDialog uses the interface IWinManager1. The
active CWinManager class implements these two
interfaces.
CChart
<<interface>>
IWinManager2
CApplication
*
update
refresh
setCaption
<<interface>>
IWinManager1
CDialog
Figure 9. Composition heuristics.
showDialog
hideDialog
getValue
valueUpdated
buttonPressed
If we detect that there is an object whose lifetime is
directly tied to the lifetime of another object and all the
messages sent to this object are passed by the first one,
then this hints to a composite relationship between these
objects.
In Figure 4, the objects of the classes CButton and
CDatafield are created and destroyed by an object of the
class CDialog, and they only communicate with that
object, and we conclude a composition relation between
these classes, CDialog being the composite and CButton
and CDatafield being the parts.
Other interesting heuristics that are being studied
include:
-
-
-
Hierarchical interface heuristics for generating
interface hierarchies. We can define a root interface
class containing a common set of operations for
several implementation classes and derive specialized
interfaces used by different classes from this base
interface. This kind of hierarchy can contain many
levels.
Generalization heuristics for detecting possible
generalization relationships. This heuristics makes a
stronger assumption than interface heuristics. We can
apply, for example, Galois Lattices as in [8].
Heuristics to detect patterns or idioms. It is beyond the
scope of this paper to further discuss these issues, but
pattern recognition can be used to detect dynamic
behavior that could be propagated to the static model.
It should be noted that in a practical implementation
the transformation operation should operate semiautomatically, so that the designer can guide the
transformation process. For example, she or he could
decide whether or not to apply the heuristic rules, give
additional information where appropriate and so forth.
In Figure 10, we show the result we obtain after the
transform operation. We have the main class CApplication
with association to CDialog and a many association to
CChart. There is a composite relationship between
CDialog and classes CButton and CDatafield.
CApplication and CChart use the interface IWinManager2
CButton
<<active>>
CWinManager
CDatafield
Figure 10. A resulting class diagram.
As we can see, by using the additional heuristics we
can obtain a much richer class diagram that manages to
preserve also non-obvious dynamical features. This might
not be what the user actually had in mind when designing
the system, in which case she or he can decide not to use
those heuristics. In any case, this diagram can give a better
insight of the system and even reveal features surprising to
the designer. A plain minimum principle transformation
would simply produce the classes, operations and simple
associations.
6. Related work
Research work related to single transformation
operations between different diagram types has been
carried out by several researchers. Issues on how to
extract static model information from a set of scenarios
are discussed by Nørmark [11] and Egyed [5].
Synthesizing UML statechart diagrams from a set of
collaboration diagrams are discussed by Schönberger et al
[16] and Khriss et al [9]. Synthesizing statechart diagrams
from trace diagrams are discussed by Koskimies et al [10]
and Systä [18]. Synthesizing class diagrams from object
diagrams is discussed by Engels et al [6]. These sources
go into detail on how to define individual transformation
operations but each concentrate only on one particular
operation type.
Egyed [4,5] 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 emphasize individual integration
techniques but rather discusses how these activities can be
used together. However, he does not discuss the different
types of transformation operations in UML, their
interrelationships and usage scenarios. Our work
0-7695-0981-9/01 $10.00 (c) 2001 IEEE
9
Proceedings of the 34th Hawaii International Conference on System Sciences - 2001
categorizes these operations and emphasizes the usage of
the standard UML metamodel when defining them.
7. Concluding remarks
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 [19]. In particular, the
transformation operation discussed in Section 5 has been
implemented in this environment.
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 work poorly for UML diagrams. In
addition, large diagrams (generated e.g. from source files)
need special mechanisms for collapsing parts of the
diagram so that only a relevant abstraction layer is shown
to the user at a time (e.g. [2]). 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, expressed as UML activity diagrams, to allow the
user to control the execution of the transformation
operations [14].
8. References
[1] G. Booch, J. Rumbaugh, and I. Jacobson, The Unified
Modeling Language User Guide, Addison-Wesley, 1999.
[2] F. Dosa, and K. Koskimies, "Tool-supported compression of
UML class diagrams", In Proc. of UML'99, Springer-Verlag,
1999, pp. 172-187.
[3] D.F. D’Souza, and A.C. Wills, Objects, Components, and
Frameworks with UML : the Catalysis Approach, AddisonWesley, 1999.
[4] A. Egyed, "Integrating Architectural Views in UML",
Technical Report USCCSE-99-514, 1999.
[7] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design
Patterns - Elements of Reusable Object-Oriented Software,
Addison-Wesley, 1994.
[8] R. Godin, and H. Mili, "Building and Maintaining AnalysisLevel Class Hierarchies Using Galois Lattices", In Proc. of
OOPSLA'93, ACM 1993, pp. 394-410.
[9] I. Khriss, M. Elkoutbi, and R. Keller, "Automating the
Synthesis of UML Statechart Diagrams from Multiple
Collaboration Diagrams", In Proc. of UML'98, Springer-Verlag,
1998, pp. 132-147.
[10] K. Koskimies, T. Männistö, T. Systä, and J. Tuomi,
"Automated support for modeling of OO software", IEEE
Software, Jan/Feb 1998, pp. 87-94.
[11] K. Nørmark, "Synthesis of Program Outlines from
Scenarios
in
DYNAMO",
Aalborg
University,
http://www.cs.auc.dk/~normark/dynamo.html, 1998.
[12] OMG, The Unified Modeling Language Semantics v1.3,
http://www.rational.com, 1999.
[13] OMG, The Unified Modeling Language Notation Guide
v1.3, http://www.rational.com, 1999.
[14] J. Peltonen, "Visual Scripting for UML-Based Tools",
unpublished manuscript, May 2000.
[15] J. Rumbaugh, I. Jacobson, and G. Booch, The Unified
Modeling Language Reference Manual, Addison-Wesley, 1999.
[16] S. Schönberger, R. Keller, and I. Khriss, "Algorithmic
Support for Transformations in Object-Oriented Software
Development", Technical Report GELO-83, University of
Montreal, 1998.
[17] S. Schönberger, R. Keller, and I. Khriss, "Algorithmic
Support for Model Transformation in Object-Oriented Software
Development", In Theory and Practice of Object Systems
(TAPOS), 2000. To appear.
[18] T. Systä, Static and Dynamic Reverse Engineering
Techniques for Java Software Systems, University of Tampere,
PhD dissertation, 2000.
[19] J. Wikman, "Evolution of a Distributed Repository-Based
Architecture",
NOSA
'98,
http://www.ide.hkr.se/~bosch/NOSA98/JohanWikman.pdf, 1998.
[5] A. Egyed, "Automatically Detecting Modeling Mismatches
between Heterogeneous Views", unpublished manuscript, 1999.
[6] G. Engels, R. Heckel, G. Taentzer, and H. Ehrig, "A
Combined Reference Model- and View-Based Approach to
System Specification", International Journal of Engineering
and Knowledge Engineering Vol.7 No.4, 1997, pp. 457-477.
0-7695-0981-9/01 $10.00 (c) 2001 IEEE
10