Smalltalk and Object Orientation: an Introduction - Free

Deployment diagrams . Deployment diagrams (previously known as platform diagrams). As this
model attempts to capture the topology of the system once it is deployed, it reflects the physical
topology upon which the software system is to execute.
17.3 Use case diagrams
Use case diagrams explain how a system (or subsystem) will be used. The elements which interac t with
the system can be humans, other computers or dumb devices which process or produce data. The
diagrams thus present a collection of use cases which illustrate what the system is expected to do, in
terms of its external services or interfaces. Such di agrams are very important for illustrating overall
system functionality (to both technical and non -technical personnel). In addition they can act as the
context within which the rest of the system is defined.
Case based retrieval system
Load casebase
Telephonist
Service
Engineer
Delete case
Save casebase
Search
casebase
Add case
Printout case
Figure 17.2: Case-based retrieval system Use Case example
The large rectangle in Figure 17.2, indicates the system’s boundaries. The rectangles on either side
of the system indicate external ac tors which interact with the system. In this case the Service Engineer
and the Telephonist (this assumes a system being used as a telephone help desk adviser).
The actual notation used for actors is based on what are called stereotypes (stereotypes are discussed
in more detail later in this chapter). Actors are in fact classes with stereotypes. The indicates
the actor stereotype and the stick figure is the actor stereotype icon. Although we have used the class
icon (a box) as well as the stereotyp e icon (the stick man) we could have used only one of them if we
had so wished.
The ovals inside the system box in Figure 17.2 indicate the actual use cases themselves. For
example, both the actors will wish to be able to “load a casebase”. Each individual use case can have a
name, have a description explaining what it does as well as a list of its responsibilities, attributes and
operations. They may also describe their behavior in the form of a state chart. The most ap propriate
form of description for a use case will differ from one domain to another and thus the format should be
chosen as appropriate. This illustrates the flexibility of the UML as it does not prescribe the actual
format of a use case.
It is also possib le to use sequence diagrams and collaboration diagrams with use case diagrams to
illustrate the sequence of interactions between the system and the actors. Use cases should also be
annotated with a statement of purpose to place the use case itself in some overall context.
Finally, the relationship between use case diagrams and class diagrams is that use cases are peers of
classes. Depending on the size of the system, they can be grouped with the object model in a package or
remain totally independent.
17.4 The object model
This is really the key element of a UML model. The constituent diagrams illustrate the static structure
of a system via the important classes and objects in the system and how they relate to each other. The
UML documentation currently talks abo ut class diagrams (and within this about object diagrams)
stating that “class diagrams show generic descriptions of possible systems and object diagrams show
particular instantiations of systems and their behavior”. They go on to state that class diagrams contain
139