Smalltalk and Object Orientation: an Introduction - Free

In the remainder of this chapter we consider how the UML can represent the class, objects,
relationships and attributes in an object oriented system. The next chapter considers sequence and
collaboration diagrams, State diagrams and deployment diagrams.
17.2 The UML Infrastructure
The UML is built upon a common metamodel which defines the semantics of the language. On top of
this is a common notation which interprets these semantics in an easily (human) comprehensible
manner. Each of these is discussed below.
17.2.1 The Metamodel
A metamodel describes the constituents of a model and its relationships. That is, it is a model (in its
own right) which documents how another model can be defined. S uch models are important because
they provide a single, common and unambiguous statement of the syntax and semantics of a model. It
thus allows CASE tool builders to do more than provide diagramming tools. In fact the metamodel
serves several purposes including:
• Defining the syntax and describing the semantics of the UML’s concepts.
• Providing a (reasonably) formal basis for the UML.
• Providing a description of the elements of the UML.
• Providing the basis for the interchange of models between vendors’ tools.
In the normal course of events a user of the UML (or indeed of a tool which supports the UML) need
never know anything about the metamodel. It should be, and is, hidden from sight. However, for the
developers of the UML and for tool vendors in general it is a valuable, indeed essential, feature.
At present the UML metamodel is defined in terms of the UML and textual annotations (although
this may appear infinitely recursive, it is possible). Work on the metamodel is still progressing with the
authors of the UML attempting to make it more formal and simpler.
17.2.2 The UML models
The UML defines a number of models and the notations to be used with these models. They are:
Use case diagrams. These diagrams are based on the use case diagrams of Objectory and organiz e
the use cases that encompass a system’s behavior.
Class diagrams . These are derived form the Booch and OMT methods and express the static
structure of the system. For example the part of and is a relationships between classes and
objects. Note that the c lass diagrams also encompass the object diagrams. Therefore, in this
book, we will refer to them as the object model following the name used in OMT.
State machine diagrams . These, like those in OMT, are based on statecharts. They capture the
dynamic behavior of the system.
Sequence diagrams. Sequence diagrams (formerly known as message-trace diagrams in version 0.8
of the Unified method draft) deal with the time ordered sequence of transactions between
objects.
Collaboration diagrams. Collaboration diagrams (previously known as Object -message diagrams)
indicate the order of messages between specified objects. They are complementary to sequence
diagrams as they both illustrate the same information. The difference is that the sequence
diagrams hi -light the act ual sequence, while the collaboration diagrams hi -light the structure
required to support the message sequences.
Component diagrams . In version 0.8 of the Unified Method draft these diagrams were called
module diagrams. These diagrams represent the develop ment view of the system or how the
system should be developed into software modules. They can also be used to represent concepts
such as dynamic libraries.
138