38 Chapter 2 • Modeling with UML

An abstract data type is a data type defined by an implementation-independent

specification. Abstract data types enable developers to reason about a set of instances without
looking at a specific implementation of the abstract data type. Examples of abstract data types
are sets and sequences, which can be mathematically defined. A system may provide different
implementations of the set abstract data type, each optimizing different criteria (e.g., memory
consumption, insertion time). However, a developer using a set only needs to understand its
semantics and need not be aware of the internal representation of the set. For example, the
abstract data type Person may define the operations getName(),1 getSocialSecurityNumber(),
and getAddress(). The fact that the social security number of the person is stored as a number
or as a string is not visible to the rest of the system. Such decisions are called implementation
decisions.

2.3.3 Classes, Abstract Classes, and Objects

A class is an abstraction in object-oriented modeling and in object-oriented programming

languages. Like abstract data types, a class encapsulates both structure and behavior. Unlike
abstract data types, classes can be defined in terms of other classes by using inheritance. Assume
we have a watch that also can function as a calculator. The class CalculatorWatch can then be
seen as a refinement of the class Watch. This type of relationship between a base class and a
refined class is called inheritance. The generalization class (e.g., Watch) is called the
superclass, the specialized class (e.g., CalculatorWatch) is called the subclass. In an
inheritance relationship, the subclass refines the superclass by defining new attributes and
operations. In Figure 2-8, CalculatorWatch defines functionality for performing simple
arithmetic that regular Watches do not have. Superclass and subclass are relative terms. The
same class can be a subclass with respect to one class and a superclass with respect to another
class.
When an inheritance relationship serves only to model shared attributes and operations,
that is, if the generalization is not meant to be instantiated, the resulting class is called an
abstract class. Abstract classes often represent generalized concepts in the application domain,
and their names are italicized. For example, in chemistry, Benzene can be considered a class of
molecules that belongs to the abstract class OrganicCompound (Figure 2-9). OrganicCompound is
a generalization and does not correspond to any one molecule; that is, it does not have any
instances. In Java, Collection is an abstract class providing a generalization for all collection
classes. However, there are no instances of the class Collection. Rather, all collection objects
are instances of one of the subclasses of Collection, such as LinkedList, ArrayList, or
HashMap. Note that not all generalizations are abstract classes. For example, in Figure 2-8 the
Watch class is not an abstract class as it has instances. When modeling software systems,

1. We refer to an operation by its name followed by its arguments in parentheses. If the arguments are not specified, we
suffix the name of the operation by a pair of empty parentheses. We describe operations in detail in the next section.
Modeling Concepts 39

Watch

time
date
SetDate(d) CalculatorWatch

calculatorState

EnterCalcMode()
InputNumber(n)

Figure 2-8 A UML class diagram depicting two classes, Watch and CalculatorWatch.
CalculatorWatch is a refinement of Watch, providing calculator functionality not found in normal watches.
In a UML class diagram, classes and objects are represented as boxes with three compartments: the first
compartment depicts the name of the class, the second depicts its attributes, the third its operations. The
second and third compartments can be omitted for brevity. An inheritance relationship is displayed by a line
with a triangle. The triangle points to the superclass, and the other end is attached to the subclass.

abstract classes sometimes do not correspond to an existing application domain concept, but
rather are introduced to reduce complexity in the model or to promote reuse.
A class defines the operations that can be applied to its instances. Operations of a
superclass can be inherited and applied to the objects of the subclass as well. For example, in
Figure 2-8, the operation SetDate(d), setting the current date of a Watch, is also applicable to
CalculatorWatches. The operation EnterCalcMode(), however, defined in the
CalculatorWatch class, is not applicable in the Watch class.
A class defines the attributes that apply to all its instances. An attribute is a named slot in
the instance where a value is stored. Attributes have a unique name within the class and the type.
Watches have a time and a date attribute. CalculatorWatches have a calculatorState
attribute.
An object is an instance of a class. An object has an identity and stores attribute values.
Each object belongs to exactly one class. In UML, an instance is depicted by a rectangle with its
name underlined. This convention is used throughout UML to distinguish between instances and

OrganicCompound

Benzene

Figure 2-9 An example of abstract class (UML class diagram). OrganicCompound is never instantiated
and only serves as a generalization class. The names of abstract classes are italicized.
40 Chapter 2 • Modeling with UML

classes.2 In Figure 2-10, simpleWatch1291 is an instance of Watch, and calculatorWatch1515

is an instance of CalculatorWatch. Note that, although the operations of Watch are applicable to
calculatorWatch1515, calculatorWatch1515 is not an instance of the class Watch. The
attributes of an object can be visible to other parts of the system in some programming
languages. For example, Java allows the implementor to specify in great detail which attributes
are visible and which are not.

«instanceOf»
simpleWatch1291:Watch Watch

calculatorWatch1515 «instanceOf»
:CalculatorWatch CalculatorWatch

Figure 2-10 A UML class diagram depicting instances of two classes. simpleWatch1291 is an instance
of Watch. calculatorWatch1515 is an instance of CalculatorWatch. Although the operations of Watch
are also applicable to calculatorWatch1515, the latter is not an instance of the former.

2.3.4 Event Classes, Events, and Messages

Event classes are abstractions representing a kind of event for which the system has a common
response. An event, an instance of an event class, is a relevant occurrence in the system. For
example, an event can be a stimuli from an actor (e.g., “the WatchUser presses the left button”),
a time-out (e.g., “after 2 minutes”), or the sending of a message between two objects. Sending a
message is the mechanism by which the sending object requests the execution of an operation in
the receiving object. The message is composed of a name and a number of arguments. The
receiving object matches the name of the message to one of its operations and passes the
arguments to the operation. Any results are returned to the sender.
For example, in Figure 2-11, the :Watch object computes the current time by getting the
Greenwich time from the :Time object and the time difference from the :TimeZone object by
sending the getTime() and the getTimeDelta() messages, respectively. Note that :Watch
denotes an undesignated object of class Watch.
Events and messages are instances: they represent concrete occurrences in the system.
Event classes are abstractions describing groups of events for which the system has a common
response. In practice, the term “event” can refer to instances or classes. This ambiguity is
resolved by examining the context in which the term is used.
44 Chapter 2 • Modeling with UML

• State machine diagrams represent the behavior of nontrivial objects (Section 2.4.4).
• Activity diagrams are flow diagrams used to represent the data flow or the control
flow through a system (Section 2.4.5).

2.4.1 Use Case Diagrams

Use cases and actors

Actors are external entities that interact with the system. Examples of actors include a
user role (e.g., a system administrator, a bank customer, a bank teller) or another system (e.g., a
central database, a fabrication line). Actors have unique names and descriptions.
Use cases describe the behavior of the system as seen from an actor’s point of view.
Behavior described by use cases is also called external behavior. A use case describes a
function provided by the system as a set of events that yields a visible result for the actors.
Actors initiate a use case to access system functionality. The use case can then initiate other use
cases and gather more information from the actors. When actors and use cases exchange
information, they are said to communicate. We will see later that we represent these exchanges
with communication relationships.
For example, in an accident management system, field officers (such as a police officer or
a fire fighter) have access to a wireless computer that enables them to interact with a dispatcher.
The dispatcher in turn can visualize the current status of all its resources, such as police cars or
trucks, on a computer screen and dispatch a resource by issuing commands from a workstation.
In this example, field officer and dispatcher can be modeled as actors.
Figure 2-13 depicts the actor FieldOfficer who invokes the use case ReportEmergency
to notify the actor Dispatcher of a new emergency. As a response, the Dispatcher invokes the

FRIEND

ReportEmergency

OpenIncident Dispatcher
FieldOfficer

AllocateResources

Figure 2-13 An example of a UML use case diagram for First Responder Interactive Emergency
Navigational Database (FRIEND), an accident management system. Associations between actors and use
cases denote information flows. These associations are bidirectional: they can represent the actor initiating
a use case (FieldOfficer initiates ReportEmergency) or a use case providing information to an actor
(ReportEmergency notifies Dispatcher). The box around the use cases represents the system boundary.
A Deeper View into UML 45

OpenIncident use case to create an incident report and initiate the incident handling. The
Dispatcher enters preliminary information from the FieldOfficer in the incident database
(FRIEND) and orders additional units to the scene with the AllocateResources use case.
For the textual description of a use case, we use a template composed of six fields (see
Figure 2-14) adapted from [Constantine & Lockwood, 2001]:

• The name of the use case is unique across the system so that developers (and project
participants) can unambiguously refer to the use case.

• Participating actors are actors interacting with the use case.

• Entry conditions describe the conditions that need to be satisfied before the use case is
initiated.

Use case name ReportEmergency

Participating Initiated by FieldOfficer

actors Communicates with Dispatcher
Flow of events 1. The FieldOfficer activates the “Report Emergency” function of her terminal.
2. FRIEND responds by presenting a form to the FieldOfficer.
3. The FieldOfficer fills out the form by selecting the emergency level, type,
location, and brief description of the situation. The FieldOfficer also
describes possible responses to the emergency situation. Once the form is
completed, the FieldOfficer submits the form.
4. FRIEND receives the form and notifies the Dispatcher.
5. The Dispatcher reviews the submitted information and creates an Incident in
the database by invoking the OpenIncident use case. The Dispatcher selects a
response and acknowledges the report.
6. FRIEND displays the acknowledgment and the selected
response to the FieldOfficer.
Entry condition • The FieldOfficer is logged into FRIEND.
Exit condition • The FieldOfficer has received an acknowledgment and the selected response
from the Dispatcher, OR
• The FieldOfficer has received an explanation indicating why the transaction
could not be processed.
Quality • The FieldOfficer’s report is acknowledged within 30 seconds.
requirements • The selected response arrives no later than 30 seconds after it is sent by the
Dispatcher.

Figure 2-14 An example of a use case, ReportEmergency.

46 Chapter 2 • Modeling with UML

• The flow of events describes the sequence of interactions of the use case, which are to
be numbered for reference. The common case (i.e., cases that are expected by the user)
and the exceptional cases (i.e., cases unexpected by the user, such as errors and unusual
conditions) are described separately in different use cases for clarity. We organize the
steps in the flow of events in two columns, the left column representing steps
accomplished by the actor, the right column representing steps accomplished by the
system. Each pair of actor–system steps represents an interaction.
• Exit conditions describe the conditions satisfied after the completion of the use case.
• Quality requirements are requirements that are not related to the functionality of the
system. These include constraints on the performance of the system, its
implementation, the hardware platforms it runs on, and so on. Quality requirements are
described in detail in Chapter 4, Requirements Elicitation.

Use cases are written in natural language. This enables developers to use them for
communicating with the client and the users, who generally do not have an extensive knowledge
of software engineering notations. The use of natural language also enables participants from
other disciplines to understand the requirements of the system. The use of the natural language
allows developers to capture things, in particular special requirements, that cannot easily be
captured in diagrams.
Use case diagrams can include four types of relationships: communication, inclusion,
extension, and inheritance. We describe these relationships in detail next.

Communication relationships

Actors and use cases communicate when information is exchanged between them.
Communication relationships are depicted by a solid line between the actor and use case
symbol. In Figure 2-13, the actors FieldOfficer and Dispatcher communicate with the
ReportEmergency use case. Only the actor Dispatcher communicates with the use cases
OpenIncident and AllocateResources. Communication relationships between actors and use
cases can be used to denote access to functionality. In the case of our example, a FieldOfficer
and a Dispatcher are provided with different interfaces to the system and have access to
different functionality.

Include relationships

When describing a complex system, its use case model can become quite complex and can
contain redundancy. We reduce the complexity of the model by identifying commonalities in
different use cases. For example, assume that the Dispatcher can press at any time a key to
access a street map. This can be modeled by a use case ViewMap that is included by the use cases
OpenIncident and AllocateResources (and any other use cases accessible by the Dispatcher).
The resulting model only describes the ViewMap functionality once, thus reducing complexity of
A Deeper View into UML 47

the overall use case model. Two use cases are related by an include relationship if one of them
includes the second one in its flow of events. In use case diagrams, include relationships are
depicted by a dashed open arrow originating from the including use case (see Figure 2-15).
Include relationships are labeled with the string «include».

«include»
OpenIncident

ViewMap
«include»
AllocateResources

Figure 2-15 An example of an «include» relationship (UML use case diagram).

Use case name AllocateResources

Participating actor Initiated by Dispatcher

Flow of events ...
Entry condition • The Dispatcher opens an Incident.
Exit condition • Additional Resources are assigned to the Incident.
• Resources receives notice about their new assignment.
• FieldOfficer in charge of the Incident receives notice about the new
Resources.

Quality requirements At any point during the flow of events, this use case can include the ViewMap
use case. The ViewMap use case is initiated when the Dispatcher invokes the
map function. When invoked within this use case, the system scrolls the map
so that location of the current Incident is visible to the Dispatcher.

Figure 2-16 Textual representation of include relationships of Figure 2-15. “Include” in bold for clarity.

We represent include relationships in the textual description of the use case with one of
two ways. If the included use case can be included at any point in the flow of events (e.g., the
ViewMap use case), we indicate the inclusion in the Quality requirements section of the use case
(Figure 2-16). If the included use case is invoked during an event, we indicate the inclusion in
the flow of events.

Extend relationships

Extend relationships are an alternate means for reducing complexity in the use case
model. A use case can extend another use case by adding events. An extend relationship
indicates that an instance of an extended use case may include (under certain conditions) the
A Deeper View into UML 49

Inheritance relationships
An inheritance relationship is a third mechanism for reducing the complexity of a
model. One use case can specialize another more general one by adding more detail. For
example, FieldOfficers are required to authenticate before they can use FRIEND. During early
stages of requirements elicitation, authentication is modeled as a high-level Authenticate use
case. Later, developers describe the Authenticate use case in more detail and allow for several
different hardware platforms. This refinement activity results in two more use cases:
AuthenticateWithPassword which enables FieldOfficers to login without any specific
hardware, and AuthenticateWithCard which enables FieldOfficers to login using a smart
card. The two new use cases are represented as specializations of the Authenticate use case
(Figure 2-19). In the textual representation, specialized use cases inherit the initiating actor and
the entry and exit conditions from the general use case (Figure 2-20).

Authenticate
WithPassword
Authenticate

Authenticate
WithCard

Figure 2-19 An example of an inheritance relationship (UML use case diagram). The Authenticate use
case is a high-level use case describing, in general terms, the process of authentication.
AuthenticateWithPassword and AuthenticateWithCard are two specializations of Authenticate.

Use case name AuthenticateWithCard

Participating actor Inherited from Authenticate use case.

Flow of events 1. The FieldOfficer inserts her card into the field terminal.
2. The field terminal acknowledges the card and prompts
the actor for her personal identification number (PIN).
3. The FieldOfficer enters her PIN with the numeric keypad.
4. The field terminal checks the entered PIN against the PIN
stored on the card. If the PINs match, the FieldOfficer
is authenticated. Otherwise, the field terminal rejects the
authentication attempt.
Entry condition Inherited from Authenticate use case.
Exit condition Inherited from Authenticate use case.

Figure 2-20 Textual representation of inheritance relationships of Figure 2-19.

A Deeper View into UML 59

Applying class diagrams

Class diagrams are used for describing the structure of a system. During analysis, software
engineers build class diagrams to formalize application domain knowledge. Classes represent
participating objects found in use cases and interaction diagrams, and describe their attributes and
operations. The purpose of analysis models is to describe the scope of the system and discover its
boundaries. For example, using the class diagram pictured in Figure 2-22, an analyst could examine
the multiplicity of the association between FieldOfficer and EmergencyReport (i.e., one
FieldOfficer can write zero or more EmergencyReports, but each EmergencyReport is written
by exactly one FieldOfficer) and ask the user whether this is correct. Can there be more than one
author of an EmergencyReport? Can there be anonymous reports? Depending on the answer from
the user, the analyst would then change the model to reflect the application domain. The
development of analysis models is described in Chapter 5, Analysis.
Analysis models do not focus on implementation. Concepts such as interface details,
network communication, and database storage are not represented. Class diagrams are refined
during system design and object design to include classes representing the solution domain. For
example, the developer adds classes representing databases, user interface windows, adapters
around legacy code, optimizations, and so on. The classes are also grouped into subsystems with
well-defined interfaces. The development of design models is described in Chapter 6, System
Design: Decomposing the System, Chapter 8, Object Design: Reusing Pattern Solutions,
Chapter 9, Object Design: Specifying Interfaces, and Chapter 10, Mapping Models to Code.

2.4.3 Interaction Diagrams

Interaction diagrams describe patterns of communication among a set of interacting objects.
An object interacts with another object by sending messages. The reception of a message by an
object triggers the execution of a method, which in turn may send messages to other objects.
Arguments may be passed along with a message and are bound to the parameters of the
executing method in the receiving object. In UML, interaction diagrams can take one of two
forms: sequence diagrams or communication diagrams.
Sequence diagrams represent the objects participating in the interaction horizontally and
time vertically. For example, consider a watch with two buttons (hereafter called 2Bwatch).
Setting the time on 2Bwatch requires the actor 2BWatchOwner to first press both buttons
simultaneously, after which 2Bwatch enters the set time mode. In the set time mode, 2Bwatch
blinks the number being changed (e.g., the hours, minutes, seconds, day, month, or year).
Initially, when the 2BWatchOwner enters the set time mode, the hours blink. If the actor presses
the first button, the next number blinks (e.g, if the hours are blinking and the actor presses the
first button, the hours stop blinking and the minutes start blinking). If the actor presses the
second button, the blinking number is incremented by one unit. If the blinking number reaches
the end of its range, it is reset to the beginning of its range (e.g., assume the minutes are blinking
and its current value is 59, its new value is set to 0 if the actor presses the second button). The
actor exits the set time mode by pressing both buttons simultaneously. Figure 2-34 depicts a
60 Chapter 2 • Modeling with UML

sequence diagram for an actor setting his 2Bwatch one minute ahead. Each column represents an
object that participates in the interaction. Messages are shown by solid arrows. Labels on solid
arrows represent message names and may contain arguments. Activations (i.e., executing
methods) are depicted by vertical rectangles. The actor who initiates the interaction is shown in
the left-most column. The messages coming from the actor represent the interactions described
in the use case diagrams. If other actors communicate with the system during the use case, these
actors are represented on the right-hand side and can receive messages. Although for simplicity,
interactions among objects and actors are uniformly represented as messages, the modeler
should keep in mind that interactions between actors and the system are of a different nature
than interactions among objects.
Sequence diagrams can be used to describe either an abstract sequence (i.e., all possible
interactions) or concrete sequences (i.e., one possible interaction, as in Figure 2-34). When
describing all possible interactions, sequence diagrams provide notations for iterations and
conditionals. An iteration is denoted by a combined fragment labeled with the loop operator (see
Figure 2-35). An alternative is denoted by a combined fragment containing a partition for each
alternative. The alternatives are selected by guards on the first message of the partition ([i>0]
and [else] in Figure 2-35). If i is positive, the top alternative of the alt combined fragment is
executed and the op1() message is sent. Otherwise, the bottom alternative is executed and the
op2() message is sent.

:2BwatchOwner :2BwatchInput :2BwatchDisplay :2BwatchTime

pressButtons1And2()
blinkHours()
pressButton1() blinkMinutes()

pressButton2() incrementMinutes()
Time

refresh()
pressButtons1And2() commitNewTime()

stopBlinking()

Figure 2-34 Example of a sequence diagram: setting the time on 2Bwatch.

A Deeper View into UML 61

a b c

alt
[i>0] op1()

[else] op2()

loop op3()

Figure 2-35 Examples of conditions and iterators in sequence diagrams.

Communication diagrams depict the same information as sequence diagrams.

Communication diagrams represent the sequence of messages by numbering the interactions.
On one hand, this removes the need for geometrical constraints on the objects and results in a
more compact diagram. On the other hand, the sequence of messages becomes more difficult to
follow. Figure 2-36 depicts the communication diagram that is equivalent to the sequence
diagram of Figure 2-34.

:2BwatchOwner

1:pressButtons1And2()
2:pressButton1()
3:pressButton2()
1.1:blinkHours()
4:pressButtons1And2()
2.1:blinkMinutes()
4.2:stopBlinking()
:2BwatchInput :2BwatchDisplay

3.1:incrementMinutes()
4.1:commitNewTime()

3.2:refresh()
:2BwatchTime

Figure 2-36 Example of a communication diagram: setting the time on 2Bwatch. This diagram represents
the same use case as the sequence diagram of Figure 2-34.
A Deeper View into UML 65

Figure 2-40 Refined state machine associated with the SetTime state (UML state machine diagram). lB
and rB correspond to pressing the left and right button, respectively.

Applying state machine diagrams

State machine diagrams are used to represent nontrivial behavior of a subsystem or an

object. Unlike interaction diagrams that focus on the events impacting the behavior of a set of
objects, state machine diagrams make explicit which attribute or set of attributes have an impact
on the behavior of a single object. State machines are used to identify object attributes and to
refine the behavior description of an object, and interaction diagrams are used to identify
participating objects and the services they provide. State machine diagrams can also be used
during system and object design to describe solution domain objects with interesting behavior.
We describe the use of state machine diagrams in detail in Chapter 5, Analysis, and Chapter 6,
System Design: Decomposing the System.

2.4.5 Activity Diagrams

UML activity diagrams represent the sequencing and coordination of lower level behaviors. An
activity diagram denotes how a behavior is realized in terms of one or several sequences of
66 Chapter 2 • Modeling with UML

activities and the object flows needed for coordinating the activities. Activity diagrams are
hierarchical: an activity is made out of either an action or a graph of subactivities and their
associated object flow. Figure 2-41 is an activity diagram corresponding to the state diagram in
Figure 2-37. Rounded rectangles represent actions and activities. Edges between activities
represent control flow. An activity can be executed only after all predecessor activities
completed.

Handle Document Archive

Incident Incident Incident

Figure 2-41 A UML activity diagram for Incident. During the action HandleIncident, the Dispatcher
receives reports and allocates resources. Once the Incident is closed, the Incident moves to the
DocumentIncident activity during which all participating FieldOfficers and Dispatchers document the
Incident. Finally, the ArchiveIncident activity represents the archival of the Incident related
information onto slow access medium.

Control nodes coordinate control flows in an activity diagram, providing mechanisms for
representing decisions, concurrency, and synchronization. The main control nodes we use are
decisions, fork nodes, and join nodes.
Decisions are branches in the control flow. They denote alternatives based on a condition
of the state of an object or a set of objects. Decisions are depicted by a diamond with one or
more incoming open arrows and two or more outgoing arrows. The outgoing edges are labeled
with the conditions that select a branch in the control flow. The set of all outgoing edges from a
decision represents the set of all possible outcomes. In Figure 2-42, a decision after the
OpenIncident action selects between three branches: If the incident is of high priority and if it is
a fire, the FireChief is notified. If the incident is of high priority and is not a fire, the
PoliceChief is notified. Finally, if neither condition is satisfied, that is, if the Incident is of low
priority, no superior is notified and the resource allocation proceeds.
Fork nodes and join nodes represent concurrency. Fork nodes denote the splitting of the
flow of control into multiple threads, while join nodes denotes the synchronization of multiple
threads and their merging of the flow of control into a single thread. For example, in
Figure 2-43, the actions AllocateResources, Coordinate–Resources, and DocumentIncident
may all occur in parallel. However, they can only be initiated after the OpenIncident action, and
the ArchiveIncident action may only be initiated after all other activities have been completed.
Activities may be grouped into swimlanes (also called activity partitions) to denote the
object or subsystem that implements the actions. Swimlanes are represented as rectangles
enclosing a group of actions. Transitions may cross swimlanes. In Figure 2-44, the Dispatcher
swimlane groups all the actions that are performed by the Dispatcher object. The
FieldOfficer swimlane denotes that the FieldOfficer object is responsible for the
DocumentIncident action.
A Deeper View into UML 67

[lowPriority]
Open Allocate
Incident Resources
[fire & highPriority]
[not fire & highPriority]
Notify
Fire Chief

Notify
Police Chief

Figure 2-42 Example of decision in the OpenIncident process. If the Incident is a fire and is of high
priority, the Dispatcher notifies the FireChief. If it is a high-priority Incident that is not a fire, the
PoliceChief is notified. In all cases, the Dispatcher allocates resources to deal with the Incident.

Allocate
Resources

Open Coordinate Archive

Incident Resources Incident

Document
Incident

Figure 2-43 An example of fork and join nodes in a UML activity diagram.

Dispatcher
Allocate
Resources

Open Coordinate Archive

Incident Resources Incident

FieldOfficer
Document
Incident

Figure 2-44 An example of swimlanes in a UML activity diagram.

68 Chapter 2 • Modeling with UML

Applying activity diagrams

Activity diagrams provide a task-centric view of the behavior of a set of objects. They can
be used: for example, to describe sequencing constraints among use cases, sequential activities
among a group of objects, or the tasks of a project. In this book, we use activity diagrams to
describe the activities of software development in Chapter 14, Project Management, and
Chapter 15, Software Life Cycle.

2.4.6 Diagram Organization

Models of complex systems quickly become complex as developers refine them. The complexity
of models can be dealt with by grouping related elements into packages. A package is a
grouping of model elements, such as use cases or classes, defining scopes of understanding.
For example, Figure 2-45 depicts use cases of the FRIEND system, grouped by actors.
Packages are displayed as rectangles with a tab attached to their upper-left corner. Use cases
dealing with incident management (e.g., creating, resource allocation, documentation) are grouped
in the IncidentManagement package. Use cases dealing with incident archive (e.g., archiving an
incident, generating reports from archived incidents) are grouped in the IncidentArchive
package. Use cases dealing with system administration (e.g., adding users, registering end stations)
are grouped in the SysAdministration package. This enables the client and the developers to
organize use cases into related groups and to focus on only a limited set of use cases at a time.