02/13/162:15 AM
Translating Graphically-Based Object-Oriented Specifications to
Formal Specifications
Scott A. DeLoach
Air Force Institute of Technology
Department of Electrical and Computer Engineering
Wright-Patterson Air Force Base, OH 45433-7765
scott.deloach@afit.af.mil
Jeffrey E. Smith
Sanders, a Lockheed Martin Company
Nashua, NH 03061
jeffrey.e.smith@lmco.com
Thomas C. Hartrum
Air Force Institute of Technology
Department of Electrical and Computer Engineering
Wright-Patterson Air Force Base, OH 45433-7765
thomas.hartrum@afit.af.mil
Abstract
Formal software specification has long been touted as a way to increase the quality and reliability of
software; however, it remains an intricate, manually intensive activity. An alternative to using formal
specifications is to use graphically-based, semi-formal specifications such as those used in many objectoriented specification methodologies. While semi-formal specifications are generally easier to develop and
understand, they lack the rigor and precision of formal specification techniques. The basic premise of this
investigation is that formal software specifications can be constructed using correctness preserving
transformations from grahically-based object-oriented representations. In earlier work, an algebraic model
of object-orientation was developed that defines how object-oriented concepts are represented algebraically
using an object-oriented algebraic specification language O-SLANG. In this work, we develop
transformations from the Unified Modeling Language Class and Statechart Diagrams to formal O-SLANG
SPECIFICATIONS.
Categories and subject descriptors: D.2.2 [Software Engineering]: Design Tools and Techniques – Computer
aided software engineering; F.3.1 [Logics and Meanings of Programs]: Specifying and Verifying and
Reasoning about Programs – Specification techniques; F.4.3 [Mathematical Logic and Formal Languages]:
Formal languages – Algebraic language theory; I.2.2 [Artificial Intelligence]: Automatic Programming –
Program transformation
General Terms: Theory, Design
Keywords: formal methods, specification acquisition, specification transformation
D:\116107556.doc
TABLE OF CONTENTS
1.
2.
3.
INTRODUCTION ................................................................................................................................................... 1
THEORY FUNDAMENTALS ............................................................................................................................... 3
THEORY-BASED OBJECT MODEL .................................................................................................................. 6
3.1
INHERITANCE .................................................................................................................................................... 7
3.2
AGGREGATION .................................................................................................................................................. 8
3.3
ASSOCIATIONS .................................................................................................................................................. 9
3.4
OBJECT COMMUNICATION ............................................................................................................................... 11
3.5
SYNTAX........................................................................................................................................................... 12
4. UNIFIED MODELING LANGUAGE DIAGRAMS ......................................................................................... 13
4.1
CLASS DIAGRAM ............................................................................................................................................. 14
4.2
STATECHART DIAGRAM .................................................................................................................................. 16
4.2.1 Restrictions to the UML Statechart Diagram............................................................................................. 18
5. DIAGRAM TRANSLATION ............................................................................................................................... 18
5.1
CLASS DIAGRAM TRANSLATIONS .................................................................................................................... 19
5.1.1 Classes ....................................................................................................................................................... 19
5.1.1.1
5.1.1.2
5.1.1.3
5.1.2
5.1.3
Class Sets ................................................................................................................................................... 24
Aggregates ................................................................................................................................................. 25
5.1.3.1
5.1.4
Attributes ............................................................................................................................................................ 20
Operations .......................................................................................................................................................... 22
Constraints .......................................................................................................................................................... 24
Domain Theory Aggregate ................................................................................................................................. 28
Associations ............................................................................................................................................... 29
5.1.4.1
Link Classes........................................................................................................................................................ 30
5.2
STATECHART DIAGRAM TRANSLATIONS ......................................................................................................... 31
5.2.1 States .......................................................................................................................................................... 31
5.2.2 Transitions ................................................................................................................................................. 32
5.2.2.1
5.2.2.2
5.2.2.3
5.2.2.4
5.2.2.5
6.
7.
Old-State............................................................................................................................................................. 34
Guard-Condition ................................................................................................................................................. 34
New-State ........................................................................................................................................................... 34
Method-Invocations ............................................................................................................................................ 35
Event-Sends ........................................................................................................................................................ 35
TRANSFORMATION VALIDATION ............................................................................................................... 35
DEMONSTRATION SYSTEM ........................................................................................................................... 36
7.1
EXAMPLE ........................................................................................................................................................ 37
8. FUTURE WORK .................................................................................................................................................. 39
9. ACKNOWLEDGMENTS..................................................................................................................................... 40
10. REFERENCES ...................................................................................................................................................... 41
1. Introduction
As the field of software engineering continues to evolve toward a more traditional engineering discipline,
an important concept to this evolution will be the use of formal specifications [1, 2]. Formal
specifications have many potential benefits, ranging from the increased quality of the specification itself,
to automatic code generation. While some impressive results have been reported [3, 4], developing
formal specifications that adequately represent a user's requirements is still a difficult task and has slowed
the adoption of formal specifications by practitioners. Specification acquisition problems include a lack
of expertise in mathematical and logical concepts among software developers, an inability to effectively
communicate formal specifications with end users, and the tendency of formal notations to restrict
solution creativity [5]. Fraser et al. suggest an approach to overcoming these problems via parallel
refinement of semi-formal and formal specifications. In a parallel refinement approach, designers
develop specifications using both semi-formal and formal representations, successively refining both
representations in parallel [5].
On the other hand, an approach to requirements modeling that has been gaining acceptance is the use of
grahically-based object-oriented methods. Initially introduced as a programming paradigm, object
orientation has been extended to the entire software lifecycle. This semi-formal approach, consisting of
graphical representations and natural language descriptions, has many variations, but the Unified
Modeling Language (UML) is now an Object Management Group (OMG) standard [6, 7]. In UML,
many models are combined to capture the essence of a software system. The Use Case Diagram is used
during analysis to organize the system behavior. The Sequence Diagram and Collaboration Diagram are
the two diagrams that describe how objects in the system interact. The Class Diagram captures the
structural aspects of the system by defining objects, their attributes, and the relationships between them.
The Statechart Diagram and Activity Diagram capture the internal control flow of object classes. The
Component Diagram shows the dependencies between software components and the Deployment
Diagram shows the configuration of system components at runtime. Some UML diagrams overlap and
not all UML diagrams are required to capture the software system's requirements. For a given system,
1
some of the models may be of lesser importance and omitted. Our work concentrates on two of the more
widely used diagrams: Class Diagrams and Statechart Diagrams. We chose to use these two diagrams
since they model basic system structure and behavior.
Defining provably correct formal transformations from semi-formal to formal object-oriented models is
critical to the successful application of the parallel refinement approach discussed above. This paper
describes a method for translating UML specifications into our theory-based model of object-oriented
concepts described in an earlier paper [8]. In our previous work, we developed an algebraic language
O-SLANG as an extension of Kestrel Institute's Slang [9]. O-SLANG not only supports an algebraic
representation of objects, but also allows the use of category theory operations such as morphisms and
colimits to combine primitive object specifications to form more complex aggregates and to extend object
specifications to capture multiple inheritance [10].
Category theory itself has been gaining popularity in formal approaches to software engineering. While
many formal specification techniques provide the ability to describe the structure and behavior of
problems, category theory explicitly captures relationships between specification objects. This capability
has led to its selection as the formal foundation for the emerging UML-RT standard [11].
There are at least two methods of implementing correctness proving transformations from UML to a
Slang formal specification. One approach is to construct a Slang form of the UML Semantics Guide [12]
and to ensure that a transformation from a UML application to Slang is consistent with the Slang form of
UML Semantics [13-15]. Our approach is to define a theory-based object model, with an associated
object-based formal specification language (viz. O-SLANG) and to translate UML applications to
O-SLANG. In a related effort, we performed the language-to-language translation of O-SLANG to Slang.
This distinction is important in explaining our theory-based object model. In the first approach, an object
and instance are both meta-objects, specified in the UML Semantics Guide, and are dependent on a metaobject hierarchy that includes specifications of many other meta-objects, e.g. Classifier, Association,
Attribute, etc., all of which have only semi-formal semantic specification. In this paper, we give our
(meta) objects a precise meaning with respect to the given theory-based object model.
2
The remainder of the paper is organized as follows. Section 2 defines the basic concepts of theory-based
algebraic specification, while Section 3 gives a quick overview of our theory-based object model.
Section 0 introduces the UML Class and Statechart Diagrams and Section 5 defines their translation into
the theory-based object model. Section 6 presents our method for proving the transformations are correct
while Section 7 discusses a demonstration system that produces O-SLANG directly from UML diagrams.
Finally, Section 8 presents our plans for future research.
2. Theory Fundamentals
Theory-based algebraic specification is concerned with (1) modeling system behavior using algebras (a
collection of values and operations on those values) and axioms that characterize algebra behavior, and
(2) composition of larger specifications from smaller specifications. Composition of specifications is
accomplished via specification building operations defined by category theory constructs [16]. A theory
is the set of all assertions that can be logically proved from the axioms of a given specification. Thus, a
specification defines a theory and is termed a theory presentation.
In algebraic specifications, the structure of a specification is defined in terms of sorts, which are abstract
collections of values, and operations over those sorts. This structure is called a signature. A signature
describes the structure of a solution; however, it does not describe the meaning of that structure. To
specify semantics, a signature is extended with axioms defining the intended semantics of signature
operations. A signature with its associated axioms is a specification. An example of a specification is
shown in Figure 1.
spec
ARRAY
is
sorts
E, I, A
operations
assign :
A, I, E  A
apply
:
A, I  E
axioms  (i,j  I, a  A, e  E)
(i = j)  apply(assign(a,i,e),j) = e;
(i  j)  apply(assign(a,i,e),j) = apply(a,j)
end-spec
Figure 1. Array Specification
3
A specification allows us to formally define the internal structure of object classes (attributes and
operations); however, they do not provide the capability to reason about relationships between object
classes. To create theory-based algebraic specifications that parallel object-oriented specifications, the
ability to define and reason about relationships between theories, similar to those used in object-oriented
approaches (inheritance, aggregation, etc.), must be available. Category theory is an abstract
mathematical theory used to describe the external structure of various mathematical systems [17] and is
used here to describe relationships between specifications.
A category consists of a collection of C-objects and C-arrows between objects such that (1) there is a
C-arrow from each object to itself, (2) C-arrows are composable, and (3) arrow composition is
associative. An obvious example is the category Set where “C-objects” are sets and “C-arrows” are
functions between sets. However, of greater interest in our research is the category Spec. Spec consists
of specifications as the “C-objects” with specification morphisms as the “C-arrows”. A specification
morphism, , is a pair of functions that map sorts (S) and operations () from one specification to
compatible sorts and operations of a second specification such that the axioms of the first specification are
theorems of the second specification. Intuitively, specification morphisms define how one specification is
embedded in another. An example of a morphism from array (Figure 1) to finite-map, as shown in Figure
2, is as follows.
 = {assign  update, apply  apply}
S = {A  M, I  D, E  R}
Specification morphisms are the basic instrument for defining and refining specifications. However, we
can extend the notion of a specification morphism to allow for the creation of new specifications from a
set of existing specifications. Often two specifications derived from a common ancestor specification
need to be combined. The desired combination consists of the unique parts of two specifications and
some “shared part” common to both specifications (the part defined in the shared ancestor specification).
This combining operation is a colimit.
4
spec
FINITE-MAP
is
sorts
M, D, R
operations
empty
:
 M
update :
M, D, R  M
apply
:
A, D  R
def?
:
A, D  Boolean
axioms  (d1,d2  D, m  M, r  R)
(d1 = d2)  apply(update(m,d2,r),d1) = r;
(d1  d2)  apply(assign(m,d2,r),d1) = apply(m,d1);
def?(update(m,d2,r),d1) = (d1 = d2)  def?(m,d1);
def?(empty,d1) = false
end-spec
Figure 2. Finite Map Specification
Conceptually, a colimit defines a colimit specification that is the “shared union” of a set of specifications
based on the morphisms between the specifications. These morphisms define equivalence classes of sorts
and operations. For example, as shown in Figure 3, if a morphism, , from specification A to
specification B maps sort  to sort , then  and  are in the same equivalence class and thus become a
single sort in the colimit specification created by taking the colimit of A, B, and . In addition to the
colimit specification, the colimit operation creates a specification morphism from each specification to the
colimit specification.
spec A is
sort 
end-spec
 : {   }
A
B
colimit spec
spec B is
sort 
end-spec
spec colimit-spec is
sort {, }
end-spec
Figure 3. Colimit Example
From these basic instruments (morphisms and colimits), we can construct specifications in a number of
ways [16]. We can (1) build a specification from a signature and a set of axioms, (2) form the union of a
set of specifications via a colimit, (3) rename sorts or operations via a specification morphism, and (4)
parameterize specifications. Many of these methods are useful in translating object-oriented
specifications into theory-based specifications.
5
3. Theory-Based Object Model
In object-orientation, the object class defines the structure of an object and its response to external stimuli
based on its current state. In our theory-based object model, we capture the structure of a class as a theory
presentation, or algebraic specification, in O-SLANG, an object-oriented algebraic specification language.
In these class specifications, we use sorts to describe collections of data values. In our theory-based
object model, the class sort is a distinguished sort that represents the set of all possible objects in the
class. In an algebraic sense, this is actually the set of all possible abstract value representations of objects
in the class.
Attributes, methods, and operations are defined as functions in O-SLANG class specifications. Attributes
are defined implicitly by functions that return specific data values while methods are functions that
modify an object's attribute values. In Figure 4, the functions create-person and increment-age are
methods. The semantics of functions, as well as invariants between class attribute values, are defined
using first order predicate logic axioms.
In the theory-based object model, we capture the notion of state explicitly by separating state attributes
from normal attributes. An O-SLANG class specification has at least one state sort, a set of states that are
elements in a state sort (defined by nullary functions), and a state attribute defined over each state sort as
a function that returns the current state of an object. Typically, a single state sort is used to model simple
state-based objects; however, we can use multiple state sorts to model more complex objects that require
concurrent or substate models. In Figure 4, the class state sort is Person-State, the class state attribute is
person-state, and the actual states are young and old.
Communication between objects is handled by events, which are functions that may invoke methods,
generate events for other objects, and directly modify state attributes. Events are distinct from methods to
separate control from execution. Each class has a new event which triggers the create method to create a
new object and initialize its attributes. In Figure 4, the functions new-person and birthday are events.
6
class PERSON is
import Sex, Natural
class sort Person
sorts Person-State
operations
person-attr-equal : Person, Person  Boolean
attributes
age : Person  Integer
gender : Person  Sex
state-attributes
person-state : Person  Person-State
methods
create-person : Sex  Person
increment-age : Person  Person
states
old, young :  Person-State
events
new-person : Sex  Person
birthday : Person  Person
axioms  (p, p1: Person, s : Sex)
old  young;
person-state(a) = young  age(a) < 30;
person-state(a) = old  age(a)  30;
person-attr-equal(p, p1)  gender(p) = gender(p1)  age(p) = age(p1);
age(create-person(s)) = 0  gender(create-person(s)) = s;
age(increment-age(p)) = age(p) + 1
 gender(increment-age(p)) = gender(p);
person-attr-equal(birthday(p), increment-age(p));
person-attr-equal(new-person(s), create-person(s))
end-class
Figure 4. Person Class
Operations are functions that do not modify attribute values and are generally used to compute derived
attributes. In Figure 4, the function person-attr-equal is an operation. Similar to methods and events, the
semantics of operations are also defined using first order predicate logic axioms.
In order to manage a set of objects in a class, a class set is also created for each class defined. A class set
is a class whose class sort is a set of objects from a previously defined object class. A class set includes
class event definitions for each event in the original class. This class event is defined so that the reception
of a class event by a class set object sends the corresponding event to each object in the class set.
3.1 Inheritance
Our theory-based object model uses a strict form of inheritance that allows a subclass object to be freely
substituted for a superclass object in any situation as captured in the “substitution property” [18]:
7
If for each object o1 of type S there is an object o1 of type T such that for all programs P defined in terms of
T the behavior of P is unchanged when o1 is substituted for o1, then S is a subtype of T.
We can ensure the substitution property holds if we have a specification morphism from the superclass to
the subclass and the subclass class sort is a sub-sort of the superclass class sort. In O-SLANG, this is
usually done using the import operation, which includes the superclass specification directly into the
subclass specification, and a statement that ensures the appropriate sub-sort relationship between the class
sorts.
An example of single inheritance, using a subclass of the Person class, is shown in Figure 5. The import
statement includes all the sorts, functions, and axioms declared in the Person class directly into the new
class. The class sort declaration, Student < Person, states that Student is a sub-sort of Person, and as
such, all functions and axioms that apply to a Person object apply to a Student object as well.
Multiple inheritance requires a slight modification to the notion of inheritance stated above. The set of
superclasses must first be combined via a category theory colimit operation and then used to “inherit
from”. Importing the colimit specification and specifying that the class sort is a sub-sort of each of the
superclass sorts ensures that the subclass inherits from each superclass and satisfies the substitution
property.
3.2 Aggregation
Aggregation is a relationship between two classes where one class, the aggregate, represents an entire
assembly and the other class, the component, is “part-of” the assembly. Not only do aggregate classes
allow the modeling of systems from components, but they also provide a convenient context in which to
define constraints and associations between components. Components of an aggregate class are modeled
similarly to attributes of a class through the concept of object-valued attributes. An object-valued
attribute is a class attribute whose sort type is a set of objects – the class sort of another class. Formally,
object-valued attributes are functions that take an object and return an external object or set of objects.
An aggregate class combines a number of classes via the colimit operation to specify a system or
subsystem. The colimit operation also unifies sorts and functions defined in separate classes,
8
associations, and events. To capture the entirety of a domain model within a single structure, we can
create a domain-level aggregate. To create this aggregate, the colimit of all classes and associations
within the domain is taken.
class STUDENT is
import Person, Class
class sort Student < Person
operations
student-attr-equal : Student, Student  Boolean
attributes
class : Student  Class
methods
create-student :  Student
increment-class : Student, Date  Student
events
new-student :  Student
promote : Student  Student
axioms  (s, s1: Student)
student-attr-equal(a, a1)  class(s) = class(s1)  person-attr-equal(s, s1);
class(s) = Freshman  class(increment-class(s)) = Sophomore;
class(s) = Sophomore  class(increment-class(s)) = Junior;
class(s) = Junior  class(increment-class(s)) = Senior;
class(s) = Senior  class(increment-class(s)) = Alumni;
age(increment-class(s)) = age(s);
gender(increment-class(s)) = gender(s);
class(create-student(s)) = Freshman
 age(create-student(s) = age(create-person(s))
 gender(create-student(s)) = gender(create-person(s));
student-attr-equal(promote(s), increment-class(s));
student-attr-equal(new-student(), create-student())
end-class
Figure 5. Student Class
3.3 Associations
Associations model the relationships between aggregate components. We define a link as an actual
connection, or relationship, between specific object instances and an association as a set of such links. A
link defines which object classes are related, along with any link attributes or link functions. A link is
basically a class specification that uses object-valued attributes to reference other objects while
associations are represented as a class set of links.
9
Association multiplicities are defined as the number of links in which any given object may participate.
These multiplicities are defined as constraints on the links in an association and can be captured
axiomatically in the association specification.
Examples of a link and association specification are given in Figure 6 and Figure 7 respectively. This
example defines an association between the Student class as shown in Figure 5 and a similarly defined
Teacher class (not shown). The student – teacher (ST-Link) link specification relates objects from the two
classes without embedding internal references into the classes themselves. Although the names of the
object-valued attributes and sorts correspond to the Student and Teacher classes, the link specification
does not formally tie the classes together. This relationship is actually formalized in the aggregate
specification.
link ST-LINK is
class sort ST-Link
sorts Student, Teacher
operations
ca-link-attr-equal : ST-Link, ST-Link  Boolean
attributes
student : ST-Link  Student
teacher : ST-Link  Teacher
methods
create-st-link : Student, Teacher  ST-Link
events
new-st-link : Student, Teacher  ST-Link
axioms
 (l1,l2: ST-Link) st-link-attr-equal(l1,l2)
 student(l1) = student(l2)  teacher(l1) = teacher(l2);
 (s: Student, t: Teacher)
student(create-st-link(s,t)) = s  teacher(create-st-link(s,t)) = t;
 (s: Student, t: Teacher)
st-link-attr-equal(new-st-link(s,t), create-st-link(s,t))
end-link
Figure 6. Student-Teacher Link
The Student-Teacher class defines a set of ST-Link objects while its axioms define the multiplicity
relationships between teachers and students. In this case a student must have at least one teacher while a
teacher may have zero or more students. The sorts Students and Teachers are implicitly defined as sets of
individual students and teachers respectively and are unified with their related class set in a higher level
aggregate class.
10
association STUDENT-TEACHER is
link-class ST-Link
class sort Student-Teacher
sorts Teachers, Students
methods
image : Student-Teacher, Student  Teachers
image : Student-Teacher, Teacher  Students
events
new-student-teacher :  Student-Teacher
axioms
% multiplicity axioms
 (st: Student-Teacher, s: Student) size(image(st, s))  1;
 (st: Student-Teacher, t: Teacher) size(image(st, t))  0;
% new event definition
new-student-teacher() = empty-set;
... definition of image operations ...
end-association
Figure 7. Student-Teacher Association
3.4 Object Communication
In our theory-based object model, each object is aware of only a certain set of events that it generates or
receives. From an object's perspective, these events are generated and broadcast to the entire system and
received from the system. In this scheme, each event is defined in a separate event theory as shown in
Figure 8.
event EVENT-NAME is
class sort Class-Sort
sorts Param-Sort
events
event-name : Class-Sort, Param-Sort  Class-Sort
end-class
Figure 8. Event Theory
An event theory consists of a class sort, parameter sorts, and an event signature that are mapped via
morphisms to sorts and events in the generating and receiving classes. If an event is being sent to a single
object then the event theory class sort is mapped to the class sort of that object class. However, if the
event theory class sort is mapped to the class sort of a class set then communication may occur with a set
of objects of that class. The other sorts in an event theory class are the sorts of event parameters. The
final part of an event theory, the event signature, is mapped to a compatible event signature in the
receiving class. The colimit of the classes and the event theory are used to unify the event and sorts of
11
two or more classes so that invocation of the event in the generating class corresponds to an invocation of
the actual event in the receiving class.
Communicating with objects from multiple classes requires the addition of another level of specification
that “broadcasts” the communication event to all interested object classes. The class sort of a broadcast
theory is called a broadcast sort and represents the object with which the sending object communicates.
The broadcast theory then defines an object-valued attribute for each receiving class. Multiple receiver
classes add a layer of specification; however, multiple sending classes are handled very simply. The only
additional construct required is a morphism from each sending class to the event theory mapping the
appropriate object-valued attribute in the sending class to the class sort of the event theory, and the event
signature in the sending class to the event signature in the event theory.
3.5 Syntax
The syntax used to capture the theory-based object model is shown below. Lowercase names represent
terminal symbols, “{…}” represents a set, “<…>” represents a tuple and “[…]” represents a sequence. It
should be noted that while axioms have a very specific syntax, we have omitted the complete description
here for simplicity. Since we only describe a subset of the formal mappings between the UML models
and the theory-based model (see [19] for the complete set), we have omitted the syntax definitions for all
specification types (abstract classes, events, links, associations, and aggregates) except the basic class
definition, which is used in the formal mappings presented in this paper.
TheoryModel = {Spec}
Spec = C | Event | Link | A | Aggregate
C = <name, ClassSort, Operations, Imports, Sorts, Attributes, Methods,
StateAttrs, Events, States, Axioms, contained-in>
ClassSort = <name, Subsorts>
Operations = {Op}
Attributes = {Op}
Methods = {Op}
StateAttrs = {Op}
Events = {Op}
12
States = {Op}
Imports = {name}
Sorts = {name}
Subsorts = {name}
Axioms = {valid O-SLANG expression}
Op = <name, Domain, Range>
Domain = [sort]
Range = [sort]
4. Unified Modeling Language Diagrams
In this section, we present an overview of the two UML diagrams under consideration – Class and
Statechart – and some restrictions placed on their use in our research. The restrictions imposed on the
diagrams ensure we can automatically translate them from their graphical notation to an algebraic
representation.
Translation of grahically-based models into algebraic specifications in the category Spec requires that two
criteria be met. First, all entities in the model must correspond to components of an algebraic
specification or be defined using category theory constructs. This means that all important features of the
model must be representable as specifications, functions, sorts, first-order axioms defined over those sorts
and functions, or category theory operations between specifications. The second requirement is that there
must be a single, unique interpretation of the model.
In a previous paper [8], we defined a theory-based model of object-orientation, originally based on
concepts from Rumbaugh's OMT. In this paper, we define transformations from UML Class and
Statechart Diagrams into our O-SLANG algebraic specification language. We originally showed the
correctness of these transformations from OMT to O-SLANG [19]. Since the UML Class and Statechart
Diagrams have changed little from OMT, we do not reproduce those results here. A complete comparison
between UML and OMT features was given in an early version (0.8) of the Unified Method, comparing
97 features of UML and OMT (as well as the Booch method). Most of these features were similar with
13
respect to Class/Object properties and Statechart Diagrams. Table 1 is exemplary of some of the key,
primarily notational, differences.
4.1 Class Diagram
The UML Class Diagram defines the structure of a domain based on classes of objects and the
relationships between them. A UML class, C, defines the structure of a similar set of objects. This
structure is defined by attributes, which are data that describe various aspects of an object, and operations
that describe how an object behaves.
Table 1. Class and Object Properties UML/OMT Comparison Chart
Feature
abstract class
UML
Keyword “abstract" as class property
parameterized class
class rectangle impacted by small dashed
rectangle containing list of template arguments
in attribute format
stacked objects indicating anonymous set of
objects, stacked to upper right
link line to multiobject implies multilink
dashed arrow (dependency) labeled friend from
the friend to the supplier
multiobject
multilink
friend
nested class
global visibility of a
category
dependency
parallel inheritance
nest class box within other class box or special
icon within the name compartment of the class
box
stereotype “global"
dashed line from a client to a supplier
Grouping with “and" constraint
OMT
multiplicity 0 in upper right of
class
C++ like syntax with a list of
actual expressions
N/A
N/A
% in front of the name of the
friend class or operation
within the supplier class
none
N/A
deemed unnecessary
explicit with multiple
generalization symbols
A UML association, A, captures relationships between objects. Associations are relationships between
two or more classes and include the special relationships: aggregation and inheritance. Aggregation
describes a “part-of” relationship between an object and a sub-object (or its component), which is used to
make up the aggregate object. In UML, aggregation is the exception from the other relationships
described in this paper in that there is no meta-object specification for an aggregation. An aggregation is
an association where one of the ends of an association connection is marked with the type of aggregation
(marked as aggregate if the other end, or part, may be contained in other aggregates or marked as
14
composite if the other end may not be part of any other composite). Inheritance describes a
“generalization-specialization” relationship between two classes of objects where, if A is a subclass of B,
then objects of class A are also objects of class B.
General associations represent some relationship between two or more object classes. These associations
can be a simple relation between two classes or may be more complex with class-like properties such as
attributes and operations. An association may also have a role name for each class in the association as
well as qualifiers, which are attributes that identify specific objects associated with a specific object.
Finally, each association has a specific multiplicity, which defines the number of objects that may be
associated with another object.
Thus we can represent a UML class in a formal notation as a set consisting of the attributes shown below.
(The State and Transition parts of a class are discussed in Section 4.2.)
UMLmodel = <{ C}, {A}>
C = <name, Attributes, Operations, Superclasses, Components, States, Transitions,
Constraints>
A = <name, Attributes, Operations, Classes>
Attributes = {Attribute}
Attribute
Normal
Derived
= Normal | Derived
= <name, type, Axiom>
= <name, type, Axiom>
Operations = {Operation}
Operation = <name, Parameters, type, Axioms>
Parameters = {Parameter}
Parameter =
<name, type>
Superclasses = {name}
Constraints = {Axiom}
Components = {name}
Axioms = {Axiom}
Axiom = valid O-SLANG expression
Classes = {Class}
Class = <name, role, Qualifier, Multiplicity>
Qualifier = <name, type>
Multiplicity = {<lower, upper>}
15
An example of a UML Class Diagram, the Pump domain, is shown in Figure 9. Basically, the diagram
models a type of pump, or more precisely, two types of pumps – sophisticated and regular – that are
subtypes of a basic pump class. Each object in a pump class has a Pump-ID attribute and consists of one
Gun-Holster-Assemblies, Clutch-Motor-Assemblies, and Displays. Each Gun-Holster-Assembly object
consists of a Gun object and a Holster object. While both the Gun and Holster classes appear to be
simple classes with no attributes, their Statecharts are non-trivial. Likewise, a Clutch-Motor-Assembly
object has exactly two components, Motor and Clutch, which also are defined by their dynamic models.
The Display class has a more typical appearance than the Gun, Holster, Motor, or Clutch classes in that it
has four attributes: cost, volume, ppg, and grade.
Gun
Holster
Motor
Gun-Holster-Assembly
Clutch
Clutch-Motor-Assembly
Display
cost : amount = 0
volume : volume = 0
grade
/ ppg : amount = cost / volume
set-amount()
Pump
Pump-id : integer
Regular
Sophisticated
volume-select : volume = 0
amount-select : amount = 0
Figure 9. Pump Domain Object Model
4.2 Statechart Diagram
The concept of state is vital to object-orientation. In object-orientation, state is generally an abstraction of
an object's attribute values and is represented in UML via a Statechart. A typical Statechart is shown in
Figure 10. Statecharts have five parts: states, transitions, parameterized events, guards, and actions. The
state of a system “summarizes the information concerning past input and what is needed to determine the
16
behavior of the system on subsequent inputs” [20]. Therefore, a system typically resides in a state
between events and may change state based on the occurrence of additional events. Transitions change
the state of an object based on a specific input and the current state. Transition labels define the input
event, parameters, guard, actions and send-clauses associated with a transition as shown below.
event-name (parameter-list) [ guard-condition ] / action1 ... actionn send-clause
(Note, in the UML 1.3 draft, the send-clause is replaced by an action expression – an action sequence
comprising a number of distinct actions including actions that generate events). Events are the
instantaneous transmittal of information from one object (or the external environment) to another object.
If there is no explicit transition from a given state for a particular event, it is assumed that no resulting
actions occur. Guard Conditions allow a system to ensure that certain conditions hold before a transition
takes place. Actions are the behavior initiated by a transition and may include computation of data,
modification of object attributes, or broadcasting of additional events. A special type of action, a
send-clause, specifies that an event is to be broadcast to other objects as shown below.
event-name(parameter-list)
In this case, the event-name is sent to another object along with its associated parameters. All other
actions are operations on the current object.
withdrawal(a,x) [bal(a) >= x) / debit(a,x)
deposit(a,x) [x + bal(a) < 0]
/ credit(a,x)
new-acct(d)
OK
withdrawal(a,x) [bal(a) < x]
/ debit(a,x) ^ notify-user
Overdrawn
deposit(a,x) [x + bal(a) >= 0] / credit(a,x)
deposit(a,x) / credit(a,x)
Figure 10. Account Statechart Diagram
Statecharts also allow for concurrent states or substates in which case the state of an object becomes a
tuple consisting of the object state in each concurrent state diagram. Within a single state, substates may
17
exist that refine the state allowing the object to change its substate while remaining in the superstate.
Such substates “inherit” the transitions of their superstate.
Formally we capture the State and Transition information from a UML Statechart as part of the
domain as described in Section 4.1. The components of states and transitions are formalized as follows.
States = {State}
State = <name, States>
Transitions = {Transition}
Transition = <name, Parameters, Guard, Actions, Events, FromState, ToState>
Guard = valid axiom
Actions = {Action}
Action
= <name, Parameters>
Events = {Event}
Event = <name, Parameters>
FromState = name
ToState = name
4.2.1 Restrictions to the UML Statechart Diagram
Although UML allows actions inside states (the equivalent of a Moore machine from finite automata) as
well as on transitions, for convenience and simplicity we assume all actions occur on transitions (a Mealy
machine). This does not represent a semantic restriction as the equivalence of Mealy and Moore
machines is well known [20].
We also assume that if the user specifies guard conditions for a set of transitions on event e from state s,
then the guards for that set of transitions are consistent and complete. This may require the user to define
transitions that “do nothing”; however, this assumption ensures that a complete and consistent set of
axioms can be generated from the Statechart Diagram without resorting to considerable reasoning about
the validity of the guard conditions.
5. Diagram Translation
In this section, we present the translations from the UML Class Diagram and Statechart Diagram
described in Section 0. Section 5.1 defines the Class Diagram translations while Section 5.2 defines the
Statechart Diagram translations. In this section, we use the convention that calligraphic uppercase letters,
18
such as A and C, refer to associations and classes from the UML diagrams while letters using a font such
as A and C refer to equivalent association and class specifications in O-SLANG (i.e., C is the UML class
corresponding to the O-SLANG class C). Dot notation is used to refer to both sub-objects and attributes of
objects.
5.1 Class Diagram Translations
A UML Class Diagram consists of two basic entities: classes and associations. In this section, we discuss
the translations of each of these to O-SLANG. Throughout this section, we use the example shown in
Figure 9 to illustrate the translation process. We use the Sophisticated and Motor classes to demonstrate
basic translations. The example translations based on Figure 9 were created using our demonstration
system, which is discussed in Section 6.
5.1.1 Classes
Each UML class C generates an O-SLANG class specification C. If C is a simple class (no inheritance or
aggregation), then the class sort of C is simply the name of the class as shown in Figure 11, which is the
class specification for the Motor class from Figure 9. However, if inheritance is involved then the
superclass specifications of C must be imported into the O-SLANG class specification C and class sort of
C must be defined to be a subset of each of the superclass class sorts [8]. This is accomplished by placing
each superclass name in the import block of C and stating that the class sort of C is a sub-sort of each of
its superclass class sorts. An example of such a sub-sort definition is shown in the Sophisticated pump
class in Figure 12. The following statements are part of each O-SLANG class. A class without
superclasses simply omits the import statement and has a simple class sort statement such as
class sort class-name.
class sort class-name < superclass-name1, ... superclass-namen
import superclass-name1, ... superclass-namen
The following mapping formally defines the translation from the UML class to the O-SLANG class
specification C. We show this formal mapping for each transformation in this section to demonstrate our
19
methodology; however, to keep from overwhelming the reader with detail, we do not include them in the
rest of the paper. The detailed definition of each transformation can be found in [19].
 C  UMLmodel
( C  TheoryModel 
C.name = C.name 
C.ClassSort.name = C.name 
C.Imports = C.Superclasses 
C.ClassSort.Subsorts = C.Superclasses)
class Motor is
class-sort Motor
import free-clutch, disable-clutch
sort Motor-State
attributes
free-clutch-Obj : Motor  free-clutch-Sort
disable-clutch-Obj : Motor  disable-clutch-Sort
state-attributes Motor-State: Motor  Motor-State
operations
attr-equal : Motor, Motor  Boolean
methods
create-motor :  Motor
states
motor-disabled:  Motor-State
motor-running:  Motor-State
events
start-pump-motor : Motor Motor
stop-motor : Motor  Motor
new-motor : Motor  Motor
axioms
motor-disabled <> motor-running;
attr-equal(M1, M2)  (free-clutch-Obj(M1) = free-clutch-Obj(M2)
 disable-clutch-Obj(M1) = disable-clutch-Obj(M2));
(Motor-State(New-Motor(M)) = motor-disabled
 attr-equal(New-Motor(M), create-motor(M)));
(Motor-State(M) = motor-disabled)
 (Motor-State(start-pump-motor(M)) = motor-running
 free-clutch-Obj(start-pump-motor(M)) =
free-clutch(free-clutch-Obj(M)));
(Motor-State(M) = motor-running)
 (Motor-State(stop-motor(M)) = motor-disabled
 disable-clutch-Obj(stop-motor(M)) =
disable-clutch(disable-clutch-Obj(M)));
Motor-State(M) = motor-disabled
 Motor-State(stop-motor(M)) = motor-disabled;
Motor-State(M) = motor-running
 Motor-State(start-pump-motor(M)) = motor-running;
end-class
Figure 11. Motor Specification
20
class Sophisticated is
class-sort Sophisticated < Pump
import Pump, volume-select, amount-select
attributes
volume-select : Sophisticated  volume
amount-select : Sophisticated  amount
operations
attr-equal : Sophisticated, Sophisticated  Boolean
methods
Create-Sophisticated:  Sophisticated
events
New-Sophisticated:  Sophisticated
axioms
volume-select(create-Sophisticated(S)) = 0;
amount-select(create-Sophisticated(S)) = 0;
attr-equal(S1, S2)  (volume-select(S1) = volume-select(S2)
 amount-select(S1) = amount-select(S2));
attr-equal(New-Sophisticated(), Create-Sophisticated())
end-class
Figure 12. Sophisticated Pump Specification
5.1.1.1 Attributes
Each attribute in C is either normal or derived and has a name, datatype and expression. Each attribute
thus defines an attribute declaration in C of the form:
attribute-name : class-name  attribute-datatype
The expression of a normal attribute is interpreted as the initial value computation for the attribute and
defines an axiom of the form,
attribute-name(CREATE-class-name(parameters)) = attribute-expression
where CREATE-class-name(parameters) is the create object function automatically created when C is
defined (see below). Both the volume-select and amount-select attributes of the Sophisticated class are
normal attributes as shown in Figure 12. Each of these has a default value of zero as specified in the first
two axioms of the specification.
The user may define the value of a derived attribute by providing an expression in the attribute definition,
which becomes an axiom in the axiom block of C of the form:
attribute-name(class-name) = attribute-expression
A formal representation of this transformation is shown below.
21
   C.Attributes
(   C.Attributes 
.name = .name 
.Domain  [C.name] 
.Range  [.type] 
.Axioms  C.Axioms)
5.1.1.2 Operations
Operations can represent three different O-SLANG constructs: 1) a newly defined O-SLANG method, 2) a
newly defined O-SLANG operation, or 3) the method definition of an action in the Statechart Diagram.
As defined in UML, operations consist of a name, a set of parameters (with a name and datatype), an
output datatype, and an axiomatic definition.
If the operation does not have an output datatype, we assume the operation is a method and the output
datatype is the class sort of C (i.e., it produces a modified object). Each UML operation defines either a
method or operation signature in O-SLANG.
If the output datatype is the class sort of C or undefined, the operation defines a method signature in the
method block of C (where p1 ... pn are parameter types of the operation), as shown below.
operation-name : class-name, p1 ... pn  class-name
If the output datatype of the UML operation is not the class sort of C then the operation defines an
O-SLANG operation whose signature is placed in the operations block of C.
operation-name : class-name, p1 ... pn  operation-datatype
An operation is defined as a set of axioms, which are specified by the designer. In our demonstration
system, the user may specify preconditions and postconditions of the operation. For translation purposes,
we assume that the axioms are valid O-SLANG syntax, semantically correctly, and thus can be translated
directly into axioms in the axiom block of C. A formal representation of these transformations is shown
below.
22
 o  C.Operations
(o.type     m  C.Operations 
m.name = o.name 
 p  o.Parameters p.type  m.Domain 
m.range = [o.type] 
o.Axioms  C.Axioms)
 o  C.Operations
(o.type =    m  C.Methods 
m.name = o.name 
o.name  m.Domain 
 p  o.Parameters p.type  m.Domain 
m.range = [o.name] 
o.Axioms  C.Axioms)
A special operation defined in all classes with non-state attributes is attr-equal, which determines if two
objects of the same class have identical non-state attribute values. Therefore, if a class has normal
attributes, it must have an attr-equal operation. The signature of the operation is shown below.
attr-equal : class-name, class-name  Boolean
Assuming C has normal attributes 1 ... n, the definition of attr-equal takes the form:
attr-equal(c1, c1)  1(c1) = 1(c1)  ...  n(c1) = n(c1)
The formal mapping is shown below.
 a  C.Attributes  a .Attribute = Normal   o  C.Operations 
o.name = “attr-equal” 
o.Domain = [C.name, C.name] 
o.Range = [“Boolean”] 
attr-axiom  C.Axioms
where
attr-axiom = “attr-equal(c1, c1)  1(c1) = 1(c1)  ...  n(c1) = n(c1)”
as defined above.
Each class also generates a default create method if it is not explicitly defined by the user in the Class or
Statechart models. A default create method takes no inputs and produces a value of the class sort of C as
shown below.
CREATE-class-name :  class-name
The default values of normal attributes define the effect of the create method. For each normal attribute
in C with a defined default value expression, the following axiom is generated.
23
attribute-name(CREATE-class-name())= attribute-expression
Examples of the attr-equal axiom can be seen in both Figure 11 and Figure 12. In both cases, all the
attributes are normal attributes and are included in the appropriate axiomatic definition of attr-equal.
When a default create method is defined, a corresponding new event must also be created to invoke the
create method. This new event has the exact same domain and range as the create method,
NEW-class-name :  class-name
and its only axiom “invokes” the create method as shown below.
ATTR-EQUAL(NEW-class-name(), CREATE-class-name())
An example of such an event definition and axiom can be seen in Figure 12 where the last axiom defines
the event in terms of the associated Create-Sophisticated method.
5.1.1.3 Constraints
In addition to attributes and operations, a user may also supply additional axioms to constrain the
behavior of various components of the class. These constraints are translated directly to axioms in the
axiom block of C.
C.Constraints  C.Axioms
5.1.2 Class Sets
Each class C generates a second specification called the class set, Cs, that defines a set of objects of type
C, as shown in Figure 13. The name of C defines the name of Cs as well as the name of the class sort of
Cs. The string “-CLASS” is simply appended to the name of the class set specification and class sort. To
explicitly state that Cs defines a set of objects of type C, a contained-class name is defined as the name of
the defining class.
If C has superclasses, the class sets of these superclasses must also be imported into the class set of C.
This is accomplished by placing each superclass name in the import block of Cs.
24
class Motor-CLASS is
class-sort Motor-CLASS
contained-class Motor
events
start-pump-motor : Motor-class  Motor-class
stop-motor : Motor-class  Motor-class
new-motor-class :  Motor-class
axioms
New-Motor-class() = empty-set;
 (M : Motor, MC : Motor-class) M  MC
 (start-pump-motor(M)  start-pump-motor(MC));
 (M : Motor, MC : Motor-class) M  MC
 (stop-motor(M)  stop-motor(MC))
end-class
Figure 13. Motor Class Specification
Each event in class C defines a class event in Cs. The purpose of class-level events is to distribute the
object-level event to each object in the class set. As shown by the first two events in Figure 13, these
class events have the same signature as the events from class C with the class sort of C replaced by the
class sort of Cs. The axioms that implement these class events are defined as:
 (x:class-name, y:class-name-CLASS) x  y

event-name(x)  event-name(y)
Because O-SLANG requires that all methods be invoked by events, each class must have a new event that
invokes the create method to create a new object. Because the class sort of a class set is a set, a new class
set object is simply an empty set.
5.1.3 Aggregates
If a class C has components, then it is an aggregate class and an O-SLANG aggregate class specification
must be defined and imported into C. This aggregate class has a special form that defines the colimit of a
category theory diagram. When generating the aggregate class, the name of CA is defined by simply
appending the string “-AGGREGATE” to the name of the C, e.g. with the aggregation of the Clutch and
Motor classes shown in Figure 14.
The diagram of specifications and specification morphisms is defined by a set of nodes (specifications)
and a set of arcs (specification morphisms). These nodes correspond to all classes, data types,
associations, and event theories referenced by a class, or any of its superclasses or components. For
25
instance, in Figure 14, we include the Motor and Clutch class components of the
Clutch-Motor-Assembly-Aggregate and the event theories (and send-clauses associated with those
theories) associated with the Clutch and Motor classes, e.g. the free-clutch and disable-clutch events and
start-fuel send-clause defined in the Clutch class and the free-clutch and disable-clutch send-clauses
defined in the Motor class. A specification is in the node set of CA if it is one of the following.
A specification imported in C.
A component of C.
The class set specification of a component of C.
The aggregate specification of a component of C.
Any specification imported by nodes in CA.
An association specification whose connections are all nodes in CA.
Any specification imported by components of two or more nodes of CA.
A unique TRIV specification is added to the node set for each connection in an association
specification CA.Node.
9. An event theory defining the communication between nodes in CA.
10. A broadcast theory defining the communication between multiple nodes in CA.
1.
2.
3.
4.
5.
6.
7.
8.
aggregate Clutch-Motor-Assembly-AGGREGATE is
nodes Motor, Motor-CLASS, free-clutch, disable-clutch, Clutch,
Clutch-CLASS, start-fuel
arcs
Motor  Motor-Class : {},
free-clutch  Motor : {},
free-clutch  Clutch : {free-clutch-Sort  Clutch},
disable-clutch  Motor : {},
disable-clutch  Clutch : {disable-clutch-Sort  Clutch},
Clutch  Clutch-Class : {},
start-fuel  Clutch : {}
end-aggregate
Figure 14. Clutch-Motor-Assembly Aggregate Specification
The morphisms between nodes of C define the set of arcs in C and are critical to correctly defining the
colimit of the diagram. An arc is in the arc set of C if for n1, n1 in the node set of CA one of the following
holds.
1.
2.
3.
4.
5.
6.
7.
8.
9.
n1 is directly or indirectly imported by n2
n1 is a component of n2
n1 is superclass of n2
n2 = n1-CLASS
n1 = n2-AGGREGATE
n1 = n2-LINK
n2 is a connection of n1, an association
n1 is an event theory received by n2 (or a subcomponent of n2)
n1 is an event theory sent by a component of n2
26
Once the aggregate specification has been created and imported into C, as shown in Figure 15,
mechanisms for referencing component objects are created. A component of the aggregate C has a name,
an optional qualifier (a name and a datatype), an optional role name, and a multiplicity.
class Clutch-Motor-Assembly is
class-sort Clutch-Motor-Assembly
import Clutch-Motor-Assembly-Aggregate
attributes
Motor-Obj : Clutch-Motor-Assembly  Motor-Class
Clutch-Obj : Clutch-Motor-Assembly  Clutch-Class
methods
Create-Clutch-Motor-Assembly:  Clutch-Motor-Assembly
events
New-Clutch-Motor-Assembly:  Clutch-Motor-Assembly
axioms
attr-equal(C1, C2)  (Motor-Obj(C1) = Motor-Obj(C2)
 Clutch-Obj(C1) = Clutch-Obj(C2));
attr-equal(New-Clutch-Motor-Assembly(),
Create-Clutch-Motor-Assembly());
size(Motor-obj(C)) = 1 ;
size(Clutch-obj(C)) = 1
end-class
Figure 15. Clutch-Motor Assembly Specification
Each component class defines an object-valued attribute that is used to reference the component. If the
component has a role name assigned to it, the name of the object-valued attribute becomes the role name
as shown below.
class-role : class-name  class-name-CLASS
If the component does not have a role name assigned, the component name appended with the string
“-OBJ” is used to define the object-valued attribute. The Motor-Obj and Clutch-Obj of Figure 15 are the
object-valued attributes that refer to the motor and clutch objects belonging to the aggregate.
class-name-OBJ : class-name  class-name-CLASS
A component qualifier is used to discriminate between components in a set. To identify individual
components, the qualifier becomes an attribute of the component class specification.
If component classes of an aggregate class C have a common association, A, then the association defines
an object-valued attribute in C of the form:
27
association-name-ASSOC : class-name  association-name
The multiplicity of a component defines how many of each component may be part of the aggregate class
C. As defined in UML, these multiplicities are denoted as a sequence of integer intervals. Therefore, the
multiplicity of component defines an O-SLANG axiom specifying the allowable number of components
that may be part of C. Generating the axiom defining the appropriate multiplicity may be complex since it
may have more than one range. It may be used to specify an exact number, a range of numbers, or a
combination of both. For each single-valued range, the sub-axiom,
SIZE(attr-name(c)(O)) = single-value
is generated as part of the overall specified axiom. However, if two values (value1 .. value2) are
specified, then the multiplicity defines a range as shown in the following sub-axiom.
SIZE(attr-name(c)(O))  value1  SIZE(attr-name(c)(O))  value2
A special case where an asterisk (*) is used in either the form 1..* or just * results in axioms of the form:
SIZE(attr-name(c)(O))  1
SIZE(attr-name(c)(O))  0
In the case of multiple ranges, the sub-axioms are disjuncted to create a single axiom defining the possible
multiplicities of a component c. In Figure 14, both components have a multiplicity of exactly one and
thus the axioms are of the form size(Motor-obj(C)) = 1.
5.1.3.1 Domain Theory Aggregate
To ensure that all classes, associations, and events are unified in the domain theory, an overall domain
theory aggregate is created that combines all top-level classes into a single specification. This is
accomplished by creating a top-level aggregate with all top-level classes as nodes. Then additional nodes
(associations, common imports, and event and broadcast theories) and arcs are added to the aggregate.
The top-level classes are those classes that are not components or subclasses of any other class.
28
5.1.4 Associations
An association in UML, A, consists of a name, a set of participating classes, a set of attributes, and a set
of operations. Each association, A, defines two O-SLANG specifications, a link specification, AL, and an
association specification A where the association specification defines a set of link objects similar to a
class set specification. The name of A defines the names and class sorts of A and AL.
We must know how many links an object may participate in to constrain link multiplicity. This requires
an image operation. To reference sets of objects from the participating classes, we define a sort in A for
each participating class. (This sort is eventually unified with the actual class set sort in a higher level
aggregate.) Assuming the association is a simple (no qualifier) binary association, the signature for the
two image operations defined by classes c1 and c2 is shown below.
IMAGE : association-name, c1-name  c2-name-CLASS
IMAGE : association-name, c2-name  c2-name-CLASS
Both operations take an association object (a set of links) and an object from one of the two participating
classes and returns the set of objects that are related via links to the input object. The image operation is
defined as follows.
 (S : association-name, l : link-name, x : c1-name, y : c1-name)
l  S  attr-name(c1)(l) = x  attr-name(c1)(l) = y  y  image(S, x)
A qualifier is used to discriminate between links in an association and thus the link qualifier becomes an
attribute of the link class. This qualified attribute is used as an additional parameter in a modified image
operation. Assuming class c1 has a qualifier, the following image operation would be generated.
IMAGE : association-name, c1-name, type(c1-qualifier)  c1-name-CLASS
The multiplicity of a component defines how many of each component may be referred to by links in the
association class A and thus generates multiplicity axioms over the image operations defined above.
These multiplicity axioms are very similar to the aggregate multiplicity axioms defined in Section 5.1.3.
The axioms generated by these multiplicities for simple binary associations are shown below.
SIZE(attr-name(c)(O))  value1  SIZE(attr-name(c)(O))  value2
SIZE(attr-name(c)(O))  value1
SIZE(attr-name(c)(O))  0
29
Each association also defines a new event, but not a create method, since an association has no attributes.
The new event simply returns an empty set.
5.1.4.1 Link Classes
A UML association also defines a link class, AL, as shown in Figure 6. A link may also contain additional
attributes, operations, methods, and events. Each class participating in an association defines an objectvalued attribute in AL.
class-name-OBJ : link-name  class-name
However, if the participating class has a role name, the role name is used as the attribute name.
class-role : link-name  class-name
Additional link attributes and operations may be entered directly into the Class Diagram and are
transformed exactly like class attributes and operations as defined in Section 5.1.1. The only method
created automatically for a link is the create method similar to the create method defined for classes.
However, to create a link, all object references must be provided to the create method. Therefore, the link
create method has the signature
CREATE-linkname : component1, ... , componentn  linkname
while the new event has a similar signature.
NEW-linkname : component1, ... , componentn  linkname
The axiom that defines a link create method is simple since object references for each component must be
provided. This axiom takes the form
attr-name(xi)(CREATE-association-name(x1, ... xn)) = xi
where xi represents a parameter in the parameter string of create and attr-name(xi) is the object-valued
attribute name in the link class corresponding to that component.
30
5.2 Statechart Diagram Translations
The Statechart Diagram of an UML class C is translated by translating the states and transitions into sorts,
operations and axioms in the theory-based object model. A statechart for the Motor class is shown in
Figure 16.
5.2.1 States
Each state in C is defined by a name and a set of substates. If the Statechart Diagram is defined for a
class C, then four types of declarations are added to C. However, before adding these declarations, the set
of states must be partitioned into n partitions such that 1) there is exactly one initial state in each partition,
2) each state is reachable from the start state in its partition, and 3) there are no transitions between
partitions. If n  2 then there are n distinct concurrent subdiagrams for class C.
start-pump-motor ^ free-clutch
new-motor / create-motor
motor-disabled
motor-running
stop-motor ^ disable-clutch
Figure 16. Motor Class Statechart
For each partition i  1...n, a sort declaration and state attribute are added as shown below.
sort class-name-STATE-i
class-name-STATE-i : class-name  class-name-STATE-i
Then, for each state in the partition, a state attribute of the form state-name :  class-name-STATE-i
is added to the states block. Finally, for each pair of states, 1 and 2, in a partition the axiom,
1-state-name  2-state-name,
is added to the axioms of C.
Each state, , may also contain substates. If a state contains substates, then four additional declarations,
similar to the ones defined above, are generated for the state. Again, however, before the declarations can
be added, the concurrent states must be partitioned for the subdiagram.
31
The procedure for partitioning substates is identical to the procedure for partitioning top level states
described above except for the name of the substate sort, where substate-name-SUBSTATE-i is
substituted for class-name-STATE-i.
Since the Motor class statechart does not have any concurrent or substates, there is only one state
attribute, Motor-State, as shown in Figure 11. The Motor class statechart also defines two states,
motor-disabled and motor-running, which are also shown in Figure 11 in the states block.
5.2.2 Transitions
In the Statechart Diagram, transitions are used to represent incoming events and actions taken by the
object. A transition defines a receive event, a set of methods, and a transition axiom in O-SLANG and
consist of seven components:
1.
2.
3.
4.
5.
6.
7.
a name,
a set of parameters (name and datatype),
a set of guard conditions defined via axioms,
a set of actions,
a set of send-clauses,
a from-state, and
a to-state.
Each transition in class C defines an incoming event signature in the event block of C. Each parameter, p,
passed via the transition becomes a parameter in the event as defined below.
transition-name : class-name, p1 ... pn  class-name
Each action in a transition defines a signature in the method block of C and each parameter, p, in an action
becomes a parameter of the method as shown below.
action-name : class-name, p1 ... pn  class-name
Send-clauses are used to send messages to other objects. Each send-clause in a transition defines an
outgoing event in C, as well as an event theory specification that is used in an aggregate specification to
unify C with the receiving object's class specification. The event theory defines an event sort and
signature and is imported into C. Therefore, instead of creating a signature for the outgoing event, the
32
event theory name, which is the name of the send-clause, is added to the import block of C. An event
theory is shown below,
event event-name is
class sort event-name-SORT
sorts p1, ..., pn
events event-name : event-name-SORT, p1 ... pn  event-name-SORT
end-event
where p1 ... pn denote the parameters of the outgoing event. In Figure 11, the free-clutch and
disable-clutch names in the import block refer to event theories generated from the send-clauses in Figure
16. The event theory for the free-clutch event is shown in Figure 17.
event free-clutch is
class-sort free-clutch-sort
events free-clutch : free-clutch-sort  free-clutch-sort
end-event
Figure 17. Free-Clutch Event Specification
Before sending an event, the sending object must know where to send it. Therefore each event must have
an object-valued attribute of the form:
event-name-OBJ : class-name  event-name-SORT
to define where an event is sent. This declaration is generated and placed in the attribute block of C.
Both free-clutch-Obj and disable-clutch-Obj in Figure 11 are the object-valued attributes associated with
the free-clutch and disable-clutch events.
Each transition defines an axiom that causes the object, upon receipt of an incoming event in the
appropriate state, to change state as well as to invoke methods and send events. This axiom has five parts
the current state, guard condition, new state, method invocations, and event sends. These parts are
merged into a single axiom of the form:
old-state  guard-condition  new-state  method-invocations  event-sends
In Figure 11, the last four axioms are defined directly from the state transitions in Figure 16. The
transformations for each of the components of these transition axioms are defined in the following
sections.
33
5.2.2.1 Old-State
Because the from-state is a mandatory part of a transition, an old-state is always generated. If the
transition’s from-state is a top-level state, then the old-state part of the axiom is simply:
class-name-STATE(o) = from-state
However, if the from-state is a substate of another state then the superstate must be in the correct state as
well, as shown below.
class-name-STATE(o) = superstate(transition, from-state)
 superstate(transition, from-state)-SUBSTATE(o) = from-state
In this example, superstate is a function that determines the superstate of a substate. Obviously, there can
be many levels of substates so that an arbitrary number of superstates may be included in the old state part
of the axiom.
5.2.2.2 Guard-Condition
The guard condition part of the transition axiom is optional. If the guard condition does exists, it is
assumed that the guard condition is an axiom written in O-SLANG syntax based on the object's attribute
values and incoming parameter values only. Thus if the guard condition exists, it requires no translation.
5.2.2.3 New-State
Because a transition always has a to-state, the new state part of the transition axiom takes the form:
class-name-STATE(transition-name(o, p1 ... pn)) = to-state
or, if the state is a substate,
superstate(transition, to-state)-SUBSTATE(transition-name(o, p1 ... pn)) = to-state
where p1 ... pn denote the parameters of the incoming event. If the transition occurs in a substate diagram,
the values of superstate attributes do not change.
34
5.2.2.4 Method-Invocations
An action specifies that a method is invoked as the result of the event receipt. The form used to specify
method invocation is,
attr-equal(transition-name(o, p1 ... pn), action-name(o, pa1 ... pa2))
where p1 ... pn denote the parameters of the incoming event and pa1 ... pa2 denote the parameters of the
method.
5.2.2.5 Event-Sends
Send events represent the sending of an event to the object whose reference is stored in the appropriate
object-valued attribute. Therefore, a send event generates the axiom,
event-name-OBJ(transition-name (o, p1...pn))
= event-name(event-name-OBJ(o), ps1...ps2)
where p1 ... pn denote the parameters of the incoming event and pa1 ... pa2 denote the parameters of the
outgoing event.
Once the valid transitions have been transformed and all incoming events and states defined in C, invalid
transitions can be computed. Because the theory-based object model assumes there is no reaction to an
event that occurs in a state with no explicitly defined transition for that event, axioms explicitly stating
this assumption must be generated. These axioms, as illustrated in the last two axioms in Figure 11, are
of the form,
old-state  same-state
where old-state are defined as before and same-state is of the form:
class-name-STATE(transition-name (o, p1 ... pn)) = from-state
6. Transformation Validation
This section shows how we formally established the correctness of our transformations. First, we defined
a formal semantics for both the Class and Statechart Diagrams [20, 21] and then defined a formal
mapping from O-SLANG to those semantics. The definition of the semantics and the mapping from
35
O-SLANG defined the arrows  and  in Figure 18. From there we constructed a set of proofs that
showed that, given either a Class or Statechart Diagram, the formal semantics defined by  were identical
to the formal semantics defined by   . These proofs led to the following theorems.

Restricted
Restricted
UML
UML Diagram
Diagram

Formal
Formal Semantics
Semantics

O-Slang
O-Slang
Figure 18. Transformation Verification
Theorem 6.1: Given a valid UML Class Diagram, the translation to O-SLANG as defined by  in Section
5 preserves the semantics of the object model as defined in [19].
Theorem 6.2: Given a valid UML Statechart Diagram, the translation to O-SLANG as defined by  in
Section 5 preserves the semantics of the dynamic model as defined in [19].
7. Demonstration System
We developed a prototype system to demonstrate the feasibility of a formal specification acquisition and
transformation system. Our goal was simply to show that UML diagrams could be automatically
transformed into theory-based specifications consistent with the original diagrams. In [19], DeLoach
performed the transformation of the pump domain object model, depicted in Figure 9, as a process of
several automated and manual translations. This process has recently been updated to perform the
conversion from UML to the O-SLANG specification in a single automated translation [22]. This one step
approach uses Visual Basic to transform a Rational Rose UML model into O-SLANG. The rules to
transform UML diagrams to the theory-based object model are captured in the transformation software.
36
We reused the same pump domain object model to verify that our translation produces the same results as
in [19]. Figure 19 shows an actual screen of the CASE tool used to construct the pump domain model.
Figure 20 depicts the Visual Basic IDE (with a fragment of the translator software) and sample output
screen.
Figure 19. Actual Pump Domain Object Model Screen
7.1 Example
Using the following code fragment, the transformation software first invokes Rational Rose and opens a
model file, which contains the UML specification. AllClasses is set to a collection of all the classes in the
model file as shown below.
umlfile = InputBox("Input Name of UML .mdl File ("Input UML File to translate?")
roseApp.OpenModel umlfile
Set AllClasses = roseApp.CurrentModel.GetAllClasses()
37
Figure 20. Actual Integrated Development Environment (IDE) and Output Screen
The translation software contains a loop, transforming each class in the model file individually. Logic
inside the loop implements the formal transformations described in Section 5, thus translating each UML
Class and Statechart Diagram into O-SLANG. Next, using the Motor specification, we demonstrate some
of the transformations from UML into O-SLANG.
As a simple example, we stated “Each UML class C generates an O-SLANG class specification C. If C is
a simple class, then the class sort of C is simply the name of the class”. When theClass.Name (theClass is
a RoseClass in the RoseClassCollection AllClasses) equals Motor in the translation loop, the first two
lines of the Motor specification are created by the following code.
38
If theClass.Abstract Then
prl ("abstract-class " & theClass.Name)
Else
pr ("class " & theClass.Name & " is")
End If
prl (" class-sort " & theClass.Name)
The translation software is a Visual Basic implementation of each transformation rule. For a more
involved example, farther into the Motor class specification we show the Visual Basic analog for the
semantic rule in the Statechart Diagram section that stated “for each pair of states in partition i  1...n, 1
and 2, the axiom 1-state-name  2-state-name is added to the axioms of C”. This rule generates
the motor-disabled  motor-running; axiom in the Motor specification and is implemented by the
following code. (AllStates contains a collection of all the states for the Motor Class and theState is the
state of the Motor class currently being processed.)
' axioms for state space inequality
For I = 1 To AllStates.Count - 2
For J = I + 1 To AllStates.Count - 1
Set theState = AllStates.GetAt(I)
Set theStateTemp = AllStates.GetAt(J)
If nostates <> "" Then
pr (" " & theState.Name & " <> " & theStateTemp.Name & ";")
End If
Next J
Next I
As another example, we explained in the Section 5 how the attr-equal operation determines if two
objects of the same class have identical non-state attribute values as shown below.
operations
attr-equal : Motor, Motor -> Boolean
axioms
attr-equal(M1, M2) <=> (free-clutch-Obj(M1) = free-clutch-Obj(M2)
& disable-clutch-Obj(M1) = disable-clutch-Obj(M2));
This portion of the Motor class specification are automatically generated by our demonstration system
using the code shown in Figure 21.
8. Future Work
The definition of theory-based models that can be created directly from semi-formal graphical
representation provides the necessary framework for a parallel refinement system for specification
development [5]. Our current prototype allows a user to develop graphically-based specifications that can
39
automatically be converted into O-SLANG specifications. The O-SLANG specifications can then be
transformed into a Slang specification in a straightforward manner to allow the full use of the Specware
code generation system [9]. Work is also currently underway to define transformations from all UML
diagrams beyond the Class and Statechart Diagrams to O-SLANG. This research will concentrate on
formally defining the relationships between modeling constructs in the different diagrams and capturing
the combination of dynamic and functional aspects of UML Collaboration Diagrams.
9. Acknowledgments
This work has been supported by grants from the National Security Agency, the Air Force Research
Laboratory, and the Air Force Office of Scientific Research.
40
' for the operation section
If theClass.Attributes.Count > 0 Then
pr (" operations")
pr ("
attr-equal : " & theClass.Name & ", " & theClass.Name & " -> Boolean")
End If
' for the axiom section
S1 = Left(theClass.Name, 1)
S2 = ""
If nostates <> "" Then
For stateid = 1 To AllStates.Count - 1
Set theState = AllStates.GetAt(stateid)
If theState.Name <> "" Then
For xitionid = 1 To theState.Transitions.Count
S = ""
S = S & "
(" & theClass.Name & "-State(" & S1 & ") = " & theState.Name & ")"
& Chr$(10) & "
=>
(" & theClass.Name & "-State("
Set theXition = theState.Transitions.GetAt(xitionid) ' trace xition from current state
' cls1 contains send-clauses and clsc1 contains the number of send-clauses
getxsends theClass, theXition, cls1, clsc1
Set theAction = theXition.GetTriggerAction()
' RoseAction retrieves the action of target state of the transition
Set theEvent = theXition.GetTriggerEvent()
' RoseEvent stemming from current transition
Set targetState = theXition.GetTargetState()
' RoseState of transition endpoint
Set targetSend = theXition.GetSendAction()
' RoseAction retrieves the message to send when the transition occurs
If theEvent.Name <> "" Then
If InStr(S, theEvent.Name) = 0 Then
S = S & theEvent.Name & "(" & S1 & ")) = " & targetState.Name
If clsc1 <> 0 Then
For sendno = 0 To clsc1 - 1
S = S & Chr$(10) & "
& " & cls1(sendno)
& "-Obj(" & theEvent.Name & "(" & S1 & "))" & Chr$(10)
& "
=
"
& cls1(sendno) & "(" & cls1(sendno) & "-Obj(" & S1 & ")))"
Next sendno
S = S & ";"
ElseIf theAction.Name <> "" Then
'
process action block rules here
End If
pr (S)
End If
End If
Next xitionid
End If
Next stateid
End If
Figure 21. Transformation Code
10. References
1. Green, C., et al., Report on a Knowledge-Based Software Assistant, in Readings in Artificial
Intelligence and Software Engineering, C. Rich and R. Waters, Editors. 1986, Morgan Kaufmann
Publishers: Los Altos, California. p. 377-428.
2. Lowry, M.R., Software Engineering in the Twenty-First Century. AI Magazine, 1992.
3. Smith, D.R., KIDS - A Semi-automatic Program Development System. IEEE Transactions on Software
Engineering, 1990. 16(9): p. 1024-1043.
4. Smith, D.R., Transformational Approach to Transportation Scheduling. in Proceedings of the 8th
Knowledge-Based Software Engineering Conference. 1993.
41
5. Fraser, M.D., K. Kumar, and V.K. Vaishnavi, Strategies for Incorporating Formal Specifications.
Communications of the ACM, 1994. 37(10): p. 74-86.
6. OMG, OMG UML Specification, 1999, OMG, http://www.rational.com/uml/.
7. Booch, G., The Unified Modeling Language User Guide. 1999.
8. DeLoach, S.A., A Theory-Based Representation for Object-Oriented Domain Models. IEEE
Transactions on Software Engineering, to appear.
9. Waldinger, R., SPECWARE Language Manual: Specware 2.0.3. 1998, Kestrel Institute.
10. Goguen, J.A. and R.M. Burstall, Some Fundamental Algebraic Tools for the Semantics of
Computation Part I: Comma Categories, Colimits, Signatures and Theories. Theoretical Computer
Science, 1984. 31: p. 175-209.
11. Grosu, R., et al., What is Behind UML-RT, in Behavioral specifications of businesses and systems, H.
Kilov, B. Rumpe, and I. Simmonds, Editors. 1999, Kluwer Academic.
12. Booch, G., J. Rumbaugh, and I. Jacobsen, UML Semantics, Version 1.1. 1997, Rational Software
Corporation.
13. Smith, J., M. Kokar, and K. Baclawski, Alternative Formalizations of Aggregations and Associations
in UML. in The Second International Conference on The Unified Modeling Language (UML '99).
1999. Fort Collins, Colorado.
14. Smith, J., M. Kokar, and K. Baclawski, Formal Verification of UML Diagrams: a First Step Towards
Code Generation. in OOPSLA'99. 1999. Denver, Colorado.
15. Smith, J., UML Formalization and Transformation thesis, Northeastern University, Graduate School
of Engineering, 1999, Northeastern University. Boston, MA. p. 299.
16. Srinivas, Y.V., Algebraic Specification: Syntax, Semantics, Structure. 1990, Department of
Information and Computer Science, University of California, Irvine. TR 90-15.
17. Srinivas, Y.V., Category Theory Definitions and Examples. 1990, Department of Information and
Computer Science, University of California, Irvine. TR 90-14.
18. Liskov, B., Data Abstraction and Hierarchy. in (addendum to) Conference Proceedings, Object
Oriented Programming Systems Languages and Applications (OOPSLA). 1987.
19. DeLoach, S.A., Formal Transformations from Graphically-Based Object-Oriented Representations to
Theory-Based Specification thesis, Air Force Institute of Technology, Department of Electrical and
Computer Engineering. AFIT/DS/ENG/96-05, AD-A310-608, 1996, Air Force Institute of
Technology. Wright-Patterson AFB, OH.
20. Hopcroft, J.E. and J.D. Ullman, Introduction to Automata Theory, Languages, and Computation.
1979, Reading, Massachusetts: Addison-Wesley.
21. Bourdeau, R.H. and B.H.C. Cheng, A Formal Semantics for Object Model Diagrams. IEEE
Transactions on Software Engineering, 1995. 21(10): p. 799-821.
22. Baclawski, K., et al., Object Oriented Transformation, in Behavioral Specifications of Businesses and
Systems, H. Kilov, B. Rumpe, and I. Simmonds, Editors. 1999, Kluwer Academic Publishers: Norwell,
MA. p. 1-14.
42