UML
Walkthrough
UML
Views
There is no sharp line between the various
concepts and constructs in UML, but, for convenience, we divide them into
several views. A view is simply a subset of UML modeling constructs that
represents one aspect of a system. The division into different views is
somewhat arbitrary, but we hope it is intuitive. One or two kinds of diagrams
provide a visual notation for the concepts in each view. At the top level,
views can be divided into three areas: structural classification, dynamic
behavior, and model management. Structural classification describes the things
in the system and their relationships to other things. Classifiers include
classes, use cases, components, and nodes. Classifiers provide the basis on top
of which dynamic behavior is built. Classification views include the static
view, use case view, and implementation view.
Dynamic behavior describes the behavior of a
system over time. Behavior can be described as a series of changes to snapshots
of the system drawn from the static view. Dynamic behavior views include the
state machine view, activity view, and interaction view.
Model management describes the organization
of the models themselves into hierarchical units. The package is the generic
organizational unit for models. Special packages include models and subsystems.
The model management view crosses the other views and organizes them for
development work and configuration control. UML also contains several
constructs intended to provide a limited but useful extensibility capability.
These constructs include constraints, stereotypes, and tagged values. These
constructs are applicable to elements of all views. Table 3-1 shows the UML
views and the diagrams that display them, as well as the main concepts relevant
to each view. This table should not be taken as a rigid set of rules but merely
as a guide to normal usage, as mixing of views is permitted.
Table 3-1: UML Views and Diagrams
Major Area
|
View
|
Diagrams
|
Main Concepts
|
Structural
|
static view
|
class diagram
|
class, association, generalization, dependency,
realization, interface
|
use case view
|
use case diagram
|
use case, actor, association, extend, include, use
case generalization
|
|
implementation view
|
component diagram
|
component, interface, dependency, realization
|
|
deployment view
|
deployment diagram
|
node, component, dependency, location
|
|
dynamic
|
state machine view
|
statechart diagram
|
state, event, transition, action
|
activity view
|
activity diagram
|
state, activity, completion transition, fork, join
|
|
interaction view
|
sequence diagram
|
interaction, object, message, activation
|
|
collaboration diagram
|
collaboration, interaction, collaboration role,
message
|
||
model management
|
model management view
|
class diagram
|
package, subsystem, model
|
extensibility
|
all
|
all
|
constraint, stereotype, tagged values
|
Static View
The static view models concepts in the application
domain, as well as internal concepts invented as part of the implementation
of an application. This view is static because it does not describe the
time-dependent behavior of the system, which is described in other views.
The main constituents of the static view are classes and their relationships:
association, generalization, and various kinds of dependency, such as
realization and usage. A class is the description of a concept from the
application domain or the application solution. Classes are the center around
which the class view is organized; other elements are owned by or attached to
class es .
Classes are drawn as rectangles. Lists of attributes
and operations are shown in separate compartments.
The compartments can be suppressed when full detail is not needed. A class may
appear on several diagrams. Its attributes and operations are often suppressed
on all but one diagram.
Relationships among classes are drawn as paths
connecting class rectangles. The different kinds of relationships are
distinguished by line texture and by adornments on the paths or their ends.
Figure 3-1
shows a class diagram from the box office application. This diagram contains
part of a ticket-selling domain model. It shows several important classes, such
as Customer, Reservation, Ticket, and Performance. Customers may have many
reservations, but each reservation is made by one customer. Reservations are of
two kinds: subscription series and individual reservations. Both reserve
tickets: in one case, only one ticket; in the other case, several tickets.
Every ticket is part of a subscription series or an individual reservation, but
not both. Every performance has many tickets available, each with a unique seat
number. A performance can be identified by a show, date, and time.
Classes can be described at various levels of
precision and concreteness. In the early stages of design, the model captures
the more logical aspects of the problem. In the later stages, the model also
captures design decisions and implementation details. Most of the views have a
similar evolutionary quality.
 |
attributes |
class scope operation
association 1
owner rolename
|
* purchased
 |
|||||
 |
|||||
 |
|||||
1 show |
|||
 |
|||
0..1 constraint 0..1 multiplicities
{xor}
|
|
1..∗
 |
3..6 1 |
∗ 1
qualifier
operation
Figure 3-1. Class diagram
Use Case View
The use case view models the functionality of the
system as perceived by outside users, called actors. A use case is a coherent
unit of functionality expressed as a transaction among actors and the system.
The purpose of the use case view is to list the actors and use cases and show
which actors participate in each use case.
Figure 3-2
shows a use case diagram for the box office example. Actors include the clerk,
supervisor, and kiosk. The kiosk is another system that accepts orders from a
customer. The customer is not an actor in the box office application because
the customer is not directly connected to the application. Use cases include
buying tickets through the kiosk or the clerk, buying subscriptions (only
through the clerk), and surveying total sales (at the request of the supervisor).Buying
tickets and buying subscriptions include a common fragment—that is, making
charges to the credit card service. (A complete description of a box office
system would involve a number of other use cases, such as exchanging tickets
and checking availability.)
Use cases can
also be described at various levels of detail. They can be factored and
described in terms of other, simpler use cases. A use case is implemented as a
collaboration in the interaction view.
Interaction View
The interaction view describes sequences of message exchanges among
roles that implement behavior of a system. A classifier role is the description
of an object that plays a particular part within an interaction, as
distinguished from other objects of the same class. This view provides a
holistic view of behavior in a system— that is, it shows the flow of control
across many objects. The interaction view is displayed in two diagrams focused
on different aspects: sequence diagrams and collaboration diagrams.
Sequence diagram
A sequence
diagram shows a set of messages arranged in time sequence. Each classifier role
is shown as a lifeline—that is, a vertical line that represents the role over
time through the entire interaction. Messages are shown as arrows between
lifelines. A sequence diagram can show a scenario—that is, an individual
history of a transaction.
One use of a
sequence diagram is to show the behavior sequence of a use case. When the
behavior is implemented, each message on a sequence diagram corresponds to an
operation on a class or an event trigger on a transition in a state machine.
Figure 3-3 shows a sequence diagram for the buy
tickets use case. This use case is initiated by the customer at the kiosk
communicating with the box office. The steps for the make charges use case are
included within the sequence, which involves communication with both the kiosk
and the credit card service. This sequence diagram is at an early stage of
development and does not show the full details of the user interface. For
example, the exact form of the seat list and the mechanism of specifying seats
must still be determined, but the essential communication of the interaction
has been specified by the use case.
Collaboration diagram
A collaboration
models the objects and links that are meaningful within an interaction. The
objects and links are meaningful only in the context provided by the
interaction. A classifier role describes an object and an association role
describes a link within a collaboration. A collaboration diagram shows the
roles in the interaction as a geometric arrangement (Figure 3-4). The messages
are shown as arrows attached to the relationship lines connecting classifier
roles. The sequence of messages is indicated by sequence numbers prepended to
message descriptions.
One use of a collaboration diagram is to show the
implementation of an operation. The collaboration shows the parameters and
local variables of the operation, as well as more permanent associations. When
the behavior is implemented, the message sequencing corresponds to the nested
calling structure and signal passing of the program.
Figure 3-4
shows a collaboration diagram for the reserve tickets interaction. The request
arrives from the kiosk and is used to find the database for the particular
performance from the set of all performances. The pointer db that is returned
to the ticketSeller object represents a local transient link to a performance
database that is maintained during the interaction and then discarded. The
ticket seller requests a number of seats to the performance; a selection of
seats in various price ranges is found, temporarily locked, and returned to the
kiosk for the customer’s selection. When the customer makes a selection from
the list of seats, the selected seats are claimed and the rest are unlocked.
Both sequence diagrams and collaboration diagrams show
interactions, but they emphasize different aspects. A sequence diagram shows
time sequence as a geometric dimension, but the relationships among
roles are implicit. A collaboration diagram shows the relationships
among roles geometrically and relates messages to the relationships,
but time sequences are less clear because they are implied by the sequence
numbers.
State Machine View
A state machine models the possible life histories of
an object of a class. A state machine contains states connected by transitions.
Each state models a period of time during the life of an object during which it
satisfies certain conditions. When an event occurs, it may cause the firing of
a transition that takes the object to a new state. When a transition fires, an
action attached to the transition may be executed. State machines are shown as
statechart diagrams.
Figure 3-5
shows a statechart diagram for the history of a ticket to a performance. The
initial state of a ticket (shown by the black dot) is the Available state.
Before the season starts, seats for season subscribers are assigned. Individual
tickets purchased interactively are first locked while the customer makes a
selection. After that, they are either sold or unlocked if they are not chosen.
If the customer takes too long to make a selection, the transaction times out
and the seat is released. Seats sold to season subscribers may be exchanged for
other performances, in which case they become available again.
State machines
may be used to describe user interfaces, device controllers, and other reactive
subsystems. They may also be used to describe passive objects that go through
several qualitatively distinct phases during their lifetime, each of which has
its own special behavior.
Activity View
An activity graph is a variant of a state machine. An activity state represents an activity: a
workflow step or the execution of an operation. An activity graph describes
both sequential and concurrent groups of activities. Activity graphs are shown
on activity diagrams.
Figure 3-6 shows an activity diagram for the box
office. This diagram shows the activities involved in mounting a show. Arrows
show sequential dependencies—for example, shows must be picked before they are
scheduled. Heavy bars show forks or joins of control. For example, after the
show is scheduled, the theater can begin to publicize it, buy scripts, hire
artists, build sets, design lighting, and make costumes, all concurrently.
Before rehearsal can begin, however, the scripts must be ordered and the artist
must be hired.
This example shows an activity diagram the purpose of
which is to model the real-world workflows of a human organization. Such business
modeling is a major purpose of activity diagrams, but activity diagrams can
also be used for modeling software activities. An activity diagram is helpful
in understanding the high-level execution behavior of a system, without
getting involved in the internal details of message passing required by a
collaboration diagram.
The input and output parameters of an action can be
shown using flow relationships connecting the action and an object flow state.
Figure 3-5. Statechart diagram
Physical Views
The previous
views model the concepts in the application from a logical viewpoint. The
physical views model the implementation structure of the application itself,
such as its organization into components and its deployment onto run-time
nodes. These views provide an opportunity to map classes onto implementation components
and nodes. There are two physical views: the implementation view and the
deployment view.
The implementation view models the
components in a system—as well as the dependencies among components so that the
impact of a proposed change can be assessed. It also models the assignment of
classes and other model elements to components.
The implementation view is displayed on component
diagrams. Figure 3-7 shows a component diagram for the box office system. There
are three user interfaces: one each for customers using a kiosk, clerks using
the on-line reservation system, and supervisors making queries about ticket
sales. There is a ticket seller component that sequentializes requests from
both kiosks and clerks; a component that processes credit card charges; and the
database containing the ticket information. The component diagram shows the
kinds of components in the system; a particular configuration of the
application may have more than one copy of a component.
A small circle
with a name is an interface. A solid line from a component to an interface
indicates that the component provides the services listed in the interface. A dashed
arrow from a component to an interface indicates that the component requires
the services provided by the interface. For example, subscription sales and
group sales are both provided by the ticket seller component; subscription
sales are accessible from both kiosks and clerks, but group sales are only
accessible from a clerk.
The deployment
view represents the arrangement of run-time
component instances on node instances. A node is a run-time resource, such as a
computer, device, or memory. This view permits the consequences of distribution
and resource allocation to be assessed.
The deployment view is displayed on deployment
diagrams. Figure 3-8 shows a descriptor-level deployment diagram for the box
office system. This diagram shows the kinds of nodes in the system
and the kinds of components they hold. A node is shown as a cube symbol.
Figure 3-9 shows an instance-level deployment diagram
for the box office system. The diagram shows the individual nodes and their
links in a particular version of the system. The information in this model is
consistent with the descriptor-level information in Figure 3-8.
Model Management View
The model
management view models the organization of the model itself. A model
comprises a set of packages that hold model elements, such as classes,
state machines, and use cases. Packages may contain other packages:
therefore, a model designates a root package that indirectly contains all the
contents of the model. Packages are units for manipulating the
contents of a model, as well as units for access control and configuration
control. Every model element is owned by one package or one other element.
Figure 3-10. Packages
There
may be several models of a system from various viewpoints—for example, an
analysis model as well as a design model. A model is shown as a special kind of
package. A subsystem is another special package. It represents a
portion of a system, that can be implemented as a distinct
component. Model management information is usually shown on class diagrams.
Figure 3-10 shows the breakdown of the entire theater system into packages and
their dependency relationships. The box office subsystem includes the previous
examples in this chapter; the full system also includes theater operations and
planning subsystems. Each subsystem consists of several packages.
Extensibility Constructs UML includes three main extensibility constructs: constraints,
stereotypes, and tagged values. A constraint is a textual statement of a
semantic relationship expressed in some formal language or in natural language.
A stereotype is a new kind of model element devised by the modeler and based on
an existing kind of model element. A tagged value is a named piece of
information attached to any model element.
These
constructs permit many kinds of extensions to UML without requiring changes
to the basic UML metamodel itself. They may be used to create
tailored versions of the UML for an application area.
Figure 3-11
shows examples of constraints, stereotypes, and tagged values. The constraint
on class Show ensures that the names of shows are unique. Constraints statements can be expressed in a text language but which
are not directly supported by UML constructs.
The stereotype on component TicketDB indicates that
the component is a database, which permits the interfaces supported by the
component to be omitted as they are the interfaces supported by all databases. Modelers
can add new stereotypes to represent special elements.
A set of constraints, tagged values,
or code generation properties can be attached to a stereotype. A modeler
can define an icon for a given stereotype name as a visual aid, as shown in
the diagram.
The tagged
values on package Scheduling show that Frank Martin is responsible for
finishing it before the end of the millennium. Any information can be attached to a model element
as a tagged value by the modeler. Text
values are especially useful for project management information and for code
generation parameters. Most tagged values would be stored as popup information
within an editing tool and would not usually be displayed on printed pictures.
Static View
Overview
Dynamic views require the static view to
describe the things that interact dynamically—you can’t say how something
interacts without first saying what is interacting. The static view is the
foundation on which the other views are built. The key elements in the static
view are classifiers and their relationships.
Classifiers A
classifier is a discrete concept in the model, having identity, state, behavior,
and relationships. Kinds of classifiers include class, interface, and
data type.
Class. A class represents a
discrete concept within the application being modeled—a physical thing (such as
an airplane), a business thing (such as an order), a logical thing (such as a
broadcasting schedule), an application thing (such as a cancel button), a
computer thing (such as a hash table), or a behavioral thing (such as a task). A
class is the descriptor for a set of objects with similar structure,
behavior, and relationships. All attributes and operations are attached to
classes or other classifiers. Classes are the foci around which
object-oriented systems are organized.
An object
is a discrete entity with identity, state, and invocable behavior. Objects are the
individual pieces out of which a run-time system is constructed;
A class defines a set of objects that have
state and behavior. State is described by attributes and associations.
Attributes are generally used for pure data values without identity, such as
numbers and strings, and associations are used for connections among objects
with identity. Individual pieces of invocable behavior are described by
operations; a method is the implementation of an operation. The lifetime
history of an object is described by a state machine attached to a class
notation for a class is a rectangle with
compartments for the name of the class, attributes, and operations, as shown in
Figure 4-1. A
set of
classes may use the generalization relationship and the inheritance mechanism
built on it to share common pieces of state and behavior description.
Generalization relates more specific classes (subclasses) to more general
classes (superclasses) that contain properties common to several subclasses. A
class may have zero or more parents (superclasses) and zero or more children
(subclasses). A class inherits state and behavior descriptions from its parents
and other ancestors, and it defines state and behavior descriptions that its
children and other descendants inherit.
The
class has a visibility with respect to its container; the visibility specifies
how it may be used by other classes outside the container.
A class has a multiplicity that specifies how
many instances of it may exist. Most often, this is many (zero or more, without
explicit limit), but singleton classes occur for which a single instance exists
during execution. Interface.
An interface is the description of behavior of
objects without giving their implementation or state; an interface contains
operations but not attributes, and it does not have outgoing associations that
are visible to it. One or more classes or components may realize an interface,
and each class implements the operations found in the interface
Data type.
A data type
is the description of primitive values that lack identity (independent
existence and the possibility of side effects). Data types include numbers,
strings, and enumerated values. Data types are passed by value and are
immutable entities. A data type has no attributes but may have operations.
Operations do not modify data values, but they may return data values as
results
Levels of meaning.
Classes can exist at several levels of meaning
in a model, including the analysis, design, and implementation levels.
An
analysis-level class represents a logical concept in the application domain
or in the application itself. The analysis model should be a minimal
representation of the system being modeled, sufficient to capture the essential
logic of the system without getting into issues of performance or construction.
When
representing a high-level design, concepts such as localization of state
to particular classes, efficiency of navigating among objects, separation of
external behavior and internal implementation, and specification of the precise
operations are relevant to a class. A design-level class represents the
decision to package state information and the operations on it into a discrete
unit. It captures the key design decision, the localization of information and
functionality to objects.
Design-level classes contain both real-world
content and computer system content.
Finally,
when representing programming-language code, the form of a class closely matches
the chosen programming language, and some abilities of a general class may be
forgone if they have no direct implementation in the language.
An implementation-level class maps directly
into programming-language code. The same system can contain more than one level
of class. An implementation class represents the declaration of a class as
found in a particular programming language. It captures the exact form of a
class, as needed by the language.
In many cases, however, analysis, design, and
implementation information can be nested into a single class.
Relationships
Relationships among classifiers are association, generalization, flow, and various kinds of dependency, including realization and usage
The association relationship
describes semantic connections among individual objects of given classes. Associations provide the connections with which objects of different classes can interact.
The generalization relationship relates general descriptions of parent classifiers (superclasses) to more specialized child classifiers (subclasses). Generalization facilitates the description of classifiers out of incremental declaration pieces, each of which adds to the description inherited from its ancestors.
The inheritance mechanism constructs complete descriptions of classifiers from incremental descriptions using generalization relationships. Generalization and inheritance permit different classifiers to share the attributes, operations, and relationships that they have in common, without repetition.
The realization relationship relates a specification to an implementation. An interface is a specification of behavior without implementation; a class includes implementation structure. One or more classes may realize an interface, and each class implements the operations found in the interface.
The flow relationship relates two versions of an object at successive times. It represents a transformation of the value, state, or location of an object. The flow relationship may connect classifier roles in an interaction.
Varieties of flow are become (two versions of the same object) and copy (a new object created from an existing object).
The dependency relationship relates classes whose behavior or implementation affects other classes. There are several kinds of dependency in addition to realization, including trace (a loose connection among elements in different models), re- finement (a mapping between two levels of meaning), usage (a requirement for the presence of another element within a single model), and binding (the assignment of values to template parameters). Usage dependency is frequently used to represent implementation relationships, such as code-level relationships.
Dependency is particularly useful when summarized on model organization units, such as packages, on which it shows the architectural structure of a system. Compilation constraints can be shown by dependencies, for example.
Associations
An association describes discrete connections among objects or other instances in a system. An association relates an ordered list (tuple) of two or more classifiers, with repetitions permitted.
The most common kind of association is a binary association between a pair of classifiers. An instance of an association is a link. A link comprises a tuple (an ordered list) of objects, each drawn from its corresponding class. A binary link comprises a pair of objects.
Associations carry information about relationships among objects in a system. As a system executes, links among objects are created and destroyed.
Associations are the “glue” that ties a system together. Without associations, there are nothing but isolated classes that don’t work together.
A single object may be associated with itself if the same class appears more than once in an association. If the same class appears twice in an association, the two instances do not have to be the same object, and usually they are not.
Each connection of an association to a class is called an association end. Most information about an association is attached to one of its ends. Association ends can have names (rolenames) and visibility.
The most important property they have is multiplicity—how many instances of one class can be related to one instance of the other class.
The notation for a binary association is a line or path connecting the participating classes. The association name is placed along the line with the rolename and multiplicity at each end, as shown in Figure 4-2. An association can also have attributes of its own, in which case it is both an association and a class—an association class (see Figure 4-3).
If an association attribute is unique within a set of related objects, then it is a qualifier (see Figure 4-4). A qualifier is a value that selects a unique object from the set of related objects across an association. Lookup tables and arrays may be modeled as quali- fied associations. Qualifiers are important for modeling names and identification codes. Qualifiers also model indexes in a design model.
A navigable association at the design stage represents state information available to a class, but it can be mapped into programming-language code in various ways. The implementation can be a pointer, a container class embedded in a class, or even a completely separate table object. Other kinds of design properties include visibility and changeability of links. Figure 4-5 shows some design properties of associations.
Aggregation and composition.
An aggregation is an association that represents a part-whole relationship. It is shown by a hollow-diamond adornment on the end of the path attached to the aggregate class. A composition is a stronger form of association in which the composite has sole responsibility for managing its parts— such as their allocation and deallocation. It is shown by a filled-diamond adornment on the composite end. There is a separate association between each class representing a part and the class representing the whole, but for convenience the paths attached to the whole may be joined together so that the entire set of associations is drawn as a tree. Figure 4-6 shows an aggregate and a composite. Links. An instance of an association is a link. A link is an ordered list of object references, each of which must be an instance of the corresponding class in the Figure 4-5. Design properties of association Person Address address 1 TransactionEntry history ∗ {ordered, addOnly} 1 navigability direction ordering property changeability constraint 50 Part 2 • UML Concepts association or an instance of a descendant of the class. The links in a system constitute part of the system state. Links do not exist independently of objects; they take their identity from the objects they relate (in database terms, the list of objects is the key for the link). Conceptually, an association is distinct from the classes that it relates. In practice, associations are often implemented using pointers in the participating classes, but they can be implemented as container objects separate from the classes they connect. Bidirectionality. The different ends of an association are distinguishable, even if two of them involve the same class. This simply means that different objects of the same class can be related. Because the ends are distinguishable, an association is not symmetric (except in special cases); the ends cannot be interchanged. This is only common sense in ordinary discourse; the subject and the object of a verb are not interchangeable. An association is sometimes said to be bidirectional. This means that the logical relationships work both ways. This statement is frequently misunderstood, even by some methodologists. It does not mean that each class “knows” the other class, or that, in an implementation, it is possible to access each class from the other. It simply means that any logical relationship has an inverse, whether or not the inverse is easy to compute. To assert the ability to traverse an association in one direction but not the other as a design decision, associations can be marked with navigability. Why is the basic model relational, rather than the pointer model prevalent in programming languages? The reason is that a model attempts to capture the intent behind an implementation. If a relationship between two classes is modeled as a pair of pointers, the pointers are nevertheless related. The association approach acknowledges that relationships are meaningful in both directions, regardless of how they are implemented. It is simple to convert an association into a pair of pointers for implementation, but very difficult to recognize that two pointers are inverses of each other unless this fact is part of the model. Figure 4-6. Aggregation and composition Order CustomerInfo LineItem composite parts 1 ∗ 1 Subscription Performance ∗ ∗ 1 parts aggregate Chapter 4 • Static View 51 Generalization The generalization relationship is a taxonomic relationship between a more general description and a more specific description that builds on it and extends it. The more specific description is fully consistent with the more general one (it has all its properties, members, and relationships) and may contain additional information. For example, a mortgage is a more specific kind of loan. A mortgage keeps the basic characteristics of a loan but adds additional characteristics, such as a house as security for the loan. The more general description is called the parent; an element in the transitive closure is an ancestor. The more specific description is called the child; an element in the transitive closure is a descendant. In the example, Loan is the parent class and Mortgage is the child class. Generalization is used for classifiers (classes, interfaces, data types, use cases, actors, signals, and so on), packages, state machines, and other elements. For classes, the term superclass and subclass are used for parent and child. A generalization is drawn as an arrow from the child to the parent, with a large hollow triangle on the end connected to the parent (Figure 4-7). Several generalization relationships can be drawn as a tree with one arrowhead branching into several lines to the children. Purpose of generalization. Generalization has two purposes. The first is to define the conditions under which an instance of one class (or other element) can be used when a variable (such as a parameter or procedure variable) is declared as holding values of a given class. This is called the substitutability principle (from Figure 4-7. Generalization notation Order date: Date confirm() MailOrder confirm() dateFilled: Date BoxOfficeOrder confirm() hold: Boolean generalization superclass (parent) subclass (child) abstract operation 52 Part 2 • UML Concepts Barbara Liskov). The rule is that an instance of a descendant may be used wherever the ancestor is declared. For example, if a variable is declared to hold loans, then a mortgage object is a legal value. Generalization enables polymorphic operations—that is, operations whose implementation (method) is determined by the class of object they are applied to rather than being explicitly stated by the caller. This works because a parent class may have many possible children, each of which implements its own variation of an operation, which is defined across the entire set of classes. For example, computing interest would work differently for a mortgage and an automobile loan, but each of them is a variation on computing interest on the parent Loan class. A variable is declared to hold the parent class, and then an object of any child class can be used, any of which has its own particular operations. This is particularly useful because new classes can be added later, without the need to modify existing polymorphic calls. For example, a new kind of loan could be added later, and existing code that uses the compute interest operation would still work. A polymorphic operation can be declared without an implementation in a parent class with the intent that an implementation must be supplied by each descendant class. Such an incomplete operation is abstract (shown by italicizing its name). The other purpose of generalization is to permit the incremental description of an element by sharing the descriptions of its ancestors. This is called inheritance. Inheritance is the mechanism by which a description of the objects of a class is assembled out of declaration fragments from the class and its ancestors. Inheritance permits shared parts of the description to be declared once and shared by many classes, rather than be repeated in each class that uses it. This sharing reduces the size of a model. More importantly, it reduces the number of changes that must be made on an update to the model and reduces the chance of accidental inconsistency. Inheritance works in a similar way for other kinds of elements, such as states, signals, and use cases. Inheritance Each kind of generalizable element has a set of inheritable properties. For any model element, these include constraints. For classifiers, they also include features (attributes, operations, and signal reception) and participation in associations. A child inherits all the inheritable properties of all its ancestors. Its complete set of properties is the set of inherited properties together with the properties that it declares directly. For a classifier, no attribute with the same signature may be declared more than once (directly or inherited). Otherwise, there is a conflict, and the model is ill formed. In other words, an attribute declared in an ancestor may not be redeclared in a descendant. An operation may be declared in more than one classifier, provided the specifications are consistent (same parameters, constraints, and mean- Chapter 4 • Static View 53 ing). Additional declarations are simply redundant. A method may be declared by multiple classes in a hierarchy. A method attached to a descendant supersedes and replaces (overrides) a method with the same signature declared in any ancestor. If two or more distinct copies of a method are nevertheless inherited by a class (via multiple inheritance from different classes), then they conflict and the model is ill formed. (Some programming languages permit one of the methods to be explicitly chosen. We find it simpler and safer just to redefine the method in the child class.) Constraints on an element are the union of the constraints on the element itself and all its ancestors; if any of them is inconsistent, then the model is ill formed. In a concrete class, each inherited or declared operation must have a method defined, either directly or by inheritance from an ancestor. Multiple inheritance If a classifier has more than one parent, it inherits from each one (Figure 4-8). Its features (attributes, operations, and signals) are the union of those of its parents. If the same class appears as an ancestor by more than one path, it nevertheless contributes only one copy of each of its members. If a feature with the same signature is declared by two classes that do not inherit it from a common ancestor (independent declarations), then the declarations conflict and the model is ill formed. UML does not provide a conflict resolution rule for this situation because experience has shown that the designer should explicitly resolve it. Some Figure 4-8. Multiple inheritance TimeStampedReservation Reservation targetDate: Date TimeStampedTransaction stamp() number: Integer received: Time confirm() This class inherits the attributes and operations of both of its parents. No new features are needed by the child. parent child parent 54 Part 2 • UML Concepts languages, such as Eiffel, permit conflicts to be explicitly resolved by the programmer, which is much safer than implicit conflict resolution rules, which frequently lead to surprises for the developer. Single and multiple classification In the simplest formulation, an object has one direct class. Many object-oriented languages have that restriction. There is no logical necessity that an object have a single class—we typically look at real-world objects from many angles simultaneously. In the more general formulation of UML, an object may have one or more direct classes. The object behaves as if it belonged to an implicit class that was a child of each of the direct classes—effectively, multiple inheritance without the need to actually declare the new class. Static and dynamic classification In the simplest formulation, an object may not change its class after it is created. Again, there is no logical necessity for this restriction. It is primarily intended to make the implementation of object-oriented programming languages easier. In the more general formulation, an object may change its direct class dynamically. In doing so, it may lose or gain attributes or associations. If it loses them, the information in them is lost and cannot be recovered later, even if it changes back to the original class. If it gains attributes or associations, then they must be initialized at the time of the change, in a similar manner to the initialization of a new object. When multiple classification is combined with dynamic classification, an object can gain and lose classes during its life. The dynamic classes are sometimes called roles or types. One common modeling pattern is to require that each object have a single static inherent class (one that cannot change during the life of the object) plus zero or more role classes that may be added or removed over the lifetime of the object. The inherent class describes its fundamental properties, and the role classes describe properties that are transient. Although many programming languages do not support multiple dynamic classification in the class declaration hierarchy, it is nevertheless a valuable modeling concept that can be mapped into associations. Realization The realization relationship connects a model element, such as a class, to another model element, such as an interface, that supplies its behavioral specification but not its structure or implementation. The client must support (by inheritance or by direct declaration) at least all the operations that the supplier has. Although realization is meant to be used with specification elements, such as interfaces, it can also be used with a concrete implementation element to indicate that its specifica- Chapter 4 • Static View 55 tion (but not its implementation) must be supported. This might be used to show the relationship of an optimized version of a class to a simpler but inefficient version, for example. Both generalization and realization relate a more general description to more detailed versions of it. Generalization relates two elements at the same semantic level (at the same level of abstraction, for example), usually within the same model; realization relates two elements at different semantic levels (an analysis class and a design class, for example, or an interface and a class), often found in different models. There may be two or more entire class hierarchies at different stages of development whose elements are related by realization. The two hierarchies need not have the same form because the realizing classes may have implementation dependencies that are not relevant to the specifying classes. Realization is displayed as a dashed arrow with a closed hollow arrowhead (Figure 4-9). It is similar to the generalization symbol with a dashed line, to indicate that it is similar to a kind of inheritance. Figure 4-9. Realization relationship Figure 4-10. Interface and realization icons «interface» ChoiceBlock PopUpMenu RadioButtonArray setDefault (choice: Choice) getChoice (): Choice Choice 1..∗ choice Button String setDefault (choice: Button) getChoice(): Button 1..∗ choice choice 1..∗ setDefault (choice: Button) getChoice(): Button realization relationship specifier implementation PrintServer SubmitJob CheckStatus SetPrintProperties realization interface class interface name 56 Part 2 • UML Concepts There is a special collapsed notation to show interfaces (without their contents) and the classes or components that realize them. The interface is shown as a small circle attached to the classifier rectangle by a solid line (Figure 4-10). Dependencies A dependency indicates a semantic relationship between two or more model elements. It relates the model elements themselves and does not require a set of instances for its meaning. It indicates a situation in which a change to the supplier element may require a change to or indicate a change in meaning of the client element in the dependency. The association and generalization relationships are dependencies by this defi- nition, but they have specific semantics with important consequences. Therefore, they have their own names and detailed semantics. We normally use the word dependency for all the other relationships that don’t fit the sharper categories. Table 4-3 lists the kinds of dependency found in the UML base model. A trace is a conceptual connection among elements in different models, often models at different stages of development. It lacks detailed semantics. It is typically used to trace system requirements across models and to keep track of changes made to models that may affect other models. A refinement is a relationship between two versions of a concept at different stages of development or at different levels of abstraction. The two concepts are not meant to coexist in the final detailed model. One of them is usually a less finished version of the other. In principle, there is a mapping from the less finished concept to the more finished concept. This does not mean that translation is automatic. Usually, the more detailed concept contains design decisions that have been made by the designer, decisions that might be made in many ways. In principle, changes to one model could be validated against the other, with deviations flagged. In practice, tools cannot do all this today, although some simpler mappings can be enforced. Therefore a refinement is mostly a reminder to the modeler that multiple models are related in a predictable way. A derivation dependency indicates that one element can be computed from another element (but the derived element may be explicitly included in the system to avoid a costly recomputation). Derivation, realization, refinement, and trace are abstraction dependencies—they relate two versions of the same underlying thing. A usage dependency is a statement that the behavior or implementation of one element affects the behavior or implementation of another element. Frequently, this comes from implementation concerns, such as compiler requirements that the definition of one class is needed to compile another class. Most usage dependencies can be derived from the code and do not need to be explicitly declared, unless they are part of a top-down design style that constrains the organization of the system (for example, by using predefined components and libraries). The specific Chapter 4 • Static View 57 Table 4-3: Kinds of Dependencies Dependency Function Keyword access Permission for a package to access the contents of another package access binding Assignment of values to the parameters of a template to generate a new model element bind call Statement that a method of one class calls an operation of another class call derivation Statement that one instance can be computed from another instance derive friend Permission for an element to access the contents of another element regardless of visibility friend import Permission for a package to access the contents of another package and add aliases of their names to the importer’s namespace import instantiation Statement that a method of one class creates instances of another class instantiate parameter Relationship between an operation and its parameters parameter realization Mapping between a specification and an implementation of it realize refinement Statement that a mapping exists between elements at two different semantic levels refine send Relationship between the sender of a signal and the receiver of the signal send trace Statement that some connection exists between elements in different models, but less precise than a mapping trace usage Statement that one element requires the presence of another element for its correct functioning (includes call, instantiation, parameter, send, but open to other kinds) use 58 Part 2 • UML Concepts kind of usage dependency can be specified, but this is often omitted because the purpose of the relationship is to highlight the dependency. The exact details can often be obtained from the implementation code. Stereotypes of usage include call and instantiation. The call dependency indicates that a method on one class calls an operation on another class; instantiation indicates that a method on one class creates an instance of another class. Several varieties of usage dependency grant permission for elements to access other elements. The access dependency permits one package to see the contents of another package. The import dependency goes further and adds the names of the target package contents to the namespace of the importing package. The friend dependency is an access dependency that permits the client to see even the private contents of the supplier. A binding is the assignment of values to the parameters of a template. It is a highly structured relationship with precise semantics obtained by substituting the arguments for the parameters in a copy of the template. Usage and binding dependencies involve strong semantics among elements at the same semantic level. They must connect elements in the same level of model (both analysis or both design, and at the same level of abstraction). Trace and re- finement dependencies are vaguer and can connect elements from different models or levels of abstraction. The instance of relationship (a metarelationship, not strictly a dependency) indicates that one element (such as an object) is an instance of another element (such as a class). A dependency is drawn as a dashed arrow from the client to the supplier, with a stereotype keyword to distinguish its kind, as shown in Figure 4-11. Constraint UML supplies a set of concepts and relationships for modeling systems as graphs of modeling elements. Some things, however, are better expressed linguistically— that is, using the power of a textual language. A constraint is a Boolean expression represented as a string to be interpreted in a designated language. Natural language, set theoretic notation, constraint languages, or various programming lanFigure 4-11. Dependencies BoxOffice SchedulingEngine «use» dependency keyword for client supplier dependency type Chapter 4 • Static View 59 guages may be used to express constraints. The UML includes the definition of a constraint language, called OCL, that is convenient for expressing UML constraints and is expected to be widely supported. See the entry for OCL and the book [Warmer-99] for more information on OCL. Constraints can be used to state various nonlocal relationships, such as restrictions on paths of associations. In particular, constraints can be used to state existence properties (there exists an X such that condition C is true) and universal properties (for all y in Y, condition D must be true). Some standard constraints are predefined as UML standard elements, including associations in an exclusive-or relationship and various constraints on the relationships of subclasses in generalization. See Chapter 14, Standard Elements, for more information. A constraint is shown as a text expression in braces. It may be written in a formal language or natural language. The text string may be placed in a note or attached to a dependency arrow. Figure 4-12 shows some constraints. Instances An instance is a run-time entity with identity, that is, something that can be distinguished from other run-time entities. It has a value at any moment in time. Over time the value can change in response to operations on it. One purpose of a model is to describe the possible states of a system and their behavior. A model is a statement of potentiality, of the possible collections of objects that might exist and the possible behavior history that the objects might undergo. The static view defines and constrains the possible configurations of values Figure 4-12. Constraints Member-of Chair-of {subset} Person Committee Person Company boss {Person.employer = Person.boss.employer} worker employer employee 0..1 * * * * * 0..1 1 Represents an incorporated entity. constraint on single class constraint as note constraint on path constraint between associations note 60 Part 2 • UML Concepts that an executing system may assume. The dynamic view defines the ways in which an executing system may pass from one configuration to another. Together, the static view and the various dynamic views based on it define the structure and behavior of a system. A particular static configuration of a system at one instant is called a snapshot. A snapshot comprises objects and other instances, values, and links. An object is an instance of a class. Each object is a direct instance of the class that completely describes it and an indirect instance of the ancestors of that class. (If multiple classification is allowed, then an object may be the direct instance of more than one class.) Similarly, each link is an instance of an association, and each value is an instance of a data type. An object has one data value for each attribute in its class. The value of each attribute must be consistent with the data type of the attribute. If the attribute has optional or multiple multiplicity, then the attribute may hold zero or multiple values. A link comprises a tuple of values, each of which is a reference to an object of a given class (or one of its descendants). Objects and links must obey any constraints on the classes or associations of which they are instances (including both explicit constraints and built-in constraints, such as multiplicity). The state of a system is a valid system instance if every instance in it is an instance of some element in a well-formed system model and if all the constraints imposed by the model are satisfied by the instances. The static view defines the set of objects, values, and links that can exist in a single snapshot. In principle, any combination of objects and links that is consistent with a static view is a possible configuration of the model. This does not mean that every possible snapshot can or will occur. Some snapshots may be legal statically but may not be dynamically reachable under the dynamic views in the system. The behavioral parts of UML describe the valid sequences of snapshots that may occur as a result of both external and internal behavioral effects. The dynamic views define how the system moves from one snapshot to another. Object diagram A diagram of a snapshot is an image of a system at a point in time. Because it contains images of objects, it is called an object diagram. It can be useful as an example of the system, for example, to illustrate complicated data structures or to show behavior through a sequence of snapshots over time (Figure 4-13). Remember that all snapshots are examples of systems, not definitions of systems. The definition of system structure and behavior is found in the definitional views, and constructing the definitional views is the goal of modeling and design. The static view describes the possible instances that can occur. Actual instances do not usually appear directly in models, except as examples. Chapter 4 • Static View 61 Figure 4-13. Object diagram triangle: Polygon point1: Point x = 0.0 y = 1.0 point2: Point x = 3.0 y = 1.0 point3: Point x = 3.0 y = 5.0 object PartOf PartOf PartOf link attribute
Relationships among classifiers are association, generalization, flow, and various kinds of dependency, including realization and usage
The association relationship
describes semantic connections among individual objects of given classes. Associations provide the connections with which objects of different classes can interact.
The generalization relationship relates general descriptions of parent classifiers (superclasses) to more specialized child classifiers (subclasses). Generalization facilitates the description of classifiers out of incremental declaration pieces, each of which adds to the description inherited from its ancestors.
The inheritance mechanism constructs complete descriptions of classifiers from incremental descriptions using generalization relationships. Generalization and inheritance permit different classifiers to share the attributes, operations, and relationships that they have in common, without repetition.
The realization relationship relates a specification to an implementation. An interface is a specification of behavior without implementation; a class includes implementation structure. One or more classes may realize an interface, and each class implements the operations found in the interface.
The flow relationship relates two versions of an object at successive times. It represents a transformation of the value, state, or location of an object. The flow relationship may connect classifier roles in an interaction.
Varieties of flow are become (two versions of the same object) and copy (a new object created from an existing object).
The dependency relationship relates classes whose behavior or implementation affects other classes. There are several kinds of dependency in addition to realization, including trace (a loose connection among elements in different models), re- finement (a mapping between two levels of meaning), usage (a requirement for the presence of another element within a single model), and binding (the assignment of values to template parameters). Usage dependency is frequently used to represent implementation relationships, such as code-level relationships.
Dependency is particularly useful when summarized on model organization units, such as packages, on which it shows the architectural structure of a system. Compilation constraints can be shown by dependencies, for example.
Associations
An association describes discrete connections among objects or other instances in a system. An association relates an ordered list (tuple) of two or more classifiers, with repetitions permitted.
The most common kind of association is a binary association between a pair of classifiers. An instance of an association is a link. A link comprises a tuple (an ordered list) of objects, each drawn from its corresponding class. A binary link comprises a pair of objects.
Associations carry information about relationships among objects in a system. As a system executes, links among objects are created and destroyed.
Associations are the “glue” that ties a system together. Without associations, there are nothing but isolated classes that don’t work together.
A single object may be associated with itself if the same class appears more than once in an association. If the same class appears twice in an association, the two instances do not have to be the same object, and usually they are not.
Each connection of an association to a class is called an association end. Most information about an association is attached to one of its ends. Association ends can have names (rolenames) and visibility.
The most important property they have is multiplicity—how many instances of one class can be related to one instance of the other class.
The notation for a binary association is a line or path connecting the participating classes. The association name is placed along the line with the rolename and multiplicity at each end, as shown in Figure 4-2. An association can also have attributes of its own, in which case it is both an association and a class—an association class (see Figure 4-3).
If an association attribute is unique within a set of related objects, then it is a qualifier (see Figure 4-4). A qualifier is a value that selects a unique object from the set of related objects across an association. Lookup tables and arrays may be modeled as quali- fied associations. Qualifiers are important for modeling names and identification codes. Qualifiers also model indexes in a design model.
A navigable association at the design stage represents state information available to a class, but it can be mapped into programming-language code in various ways. The implementation can be a pointer, a container class embedded in a class, or even a completely separate table object. Other kinds of design properties include visibility and changeability of links. Figure 4-5 shows some design properties of associations.
Aggregation and composition.
An aggregation is an association that represents a part-whole relationship. It is shown by a hollow-diamond adornment on the end of the path attached to the aggregate class. A composition is a stronger form of association in which the composite has sole responsibility for managing its parts— such as their allocation and deallocation. It is shown by a filled-diamond adornment on the composite end. There is a separate association between each class representing a part and the class representing the whole, but for convenience the paths attached to the whole may be joined together so that the entire set of associations is drawn as a tree. Figure 4-6 shows an aggregate and a composite. Links. An instance of an association is a link. A link is an ordered list of object references, each of which must be an instance of the corresponding class in the Figure 4-5. Design properties of association Person Address address 1 TransactionEntry history ∗ {ordered, addOnly} 1 navigability direction ordering property changeability constraint 50 Part 2 • UML Concepts association or an instance of a descendant of the class. The links in a system constitute part of the system state. Links do not exist independently of objects; they take their identity from the objects they relate (in database terms, the list of objects is the key for the link). Conceptually, an association is distinct from the classes that it relates. In practice, associations are often implemented using pointers in the participating classes, but they can be implemented as container objects separate from the classes they connect. Bidirectionality. The different ends of an association are distinguishable, even if two of them involve the same class. This simply means that different objects of the same class can be related. Because the ends are distinguishable, an association is not symmetric (except in special cases); the ends cannot be interchanged. This is only common sense in ordinary discourse; the subject and the object of a verb are not interchangeable. An association is sometimes said to be bidirectional. This means that the logical relationships work both ways. This statement is frequently misunderstood, even by some methodologists. It does not mean that each class “knows” the other class, or that, in an implementation, it is possible to access each class from the other. It simply means that any logical relationship has an inverse, whether or not the inverse is easy to compute. To assert the ability to traverse an association in one direction but not the other as a design decision, associations can be marked with navigability. Why is the basic model relational, rather than the pointer model prevalent in programming languages? The reason is that a model attempts to capture the intent behind an implementation. If a relationship between two classes is modeled as a pair of pointers, the pointers are nevertheless related. The association approach acknowledges that relationships are meaningful in both directions, regardless of how they are implemented. It is simple to convert an association into a pair of pointers for implementation, but very difficult to recognize that two pointers are inverses of each other unless this fact is part of the model. Figure 4-6. Aggregation and composition Order CustomerInfo LineItem composite parts 1 ∗ 1 Subscription Performance ∗ ∗ 1 parts aggregate Chapter 4 • Static View 51 Generalization The generalization relationship is a taxonomic relationship between a more general description and a more specific description that builds on it and extends it. The more specific description is fully consistent with the more general one (it has all its properties, members, and relationships) and may contain additional information. For example, a mortgage is a more specific kind of loan. A mortgage keeps the basic characteristics of a loan but adds additional characteristics, such as a house as security for the loan. The more general description is called the parent; an element in the transitive closure is an ancestor. The more specific description is called the child; an element in the transitive closure is a descendant. In the example, Loan is the parent class and Mortgage is the child class. Generalization is used for classifiers (classes, interfaces, data types, use cases, actors, signals, and so on), packages, state machines, and other elements. For classes, the term superclass and subclass are used for parent and child. A generalization is drawn as an arrow from the child to the parent, with a large hollow triangle on the end connected to the parent (Figure 4-7). Several generalization relationships can be drawn as a tree with one arrowhead branching into several lines to the children. Purpose of generalization. Generalization has two purposes. The first is to define the conditions under which an instance of one class (or other element) can be used when a variable (such as a parameter or procedure variable) is declared as holding values of a given class. This is called the substitutability principle (from Figure 4-7. Generalization notation Order date: Date confirm() MailOrder confirm() dateFilled: Date BoxOfficeOrder confirm() hold: Boolean generalization superclass (parent) subclass (child) abstract operation 52 Part 2 • UML Concepts Barbara Liskov). The rule is that an instance of a descendant may be used wherever the ancestor is declared. For example, if a variable is declared to hold loans, then a mortgage object is a legal value. Generalization enables polymorphic operations—that is, operations whose implementation (method) is determined by the class of object they are applied to rather than being explicitly stated by the caller. This works because a parent class may have many possible children, each of which implements its own variation of an operation, which is defined across the entire set of classes. For example, computing interest would work differently for a mortgage and an automobile loan, but each of them is a variation on computing interest on the parent Loan class. A variable is declared to hold the parent class, and then an object of any child class can be used, any of which has its own particular operations. This is particularly useful because new classes can be added later, without the need to modify existing polymorphic calls. For example, a new kind of loan could be added later, and existing code that uses the compute interest operation would still work. A polymorphic operation can be declared without an implementation in a parent class with the intent that an implementation must be supplied by each descendant class. Such an incomplete operation is abstract (shown by italicizing its name). The other purpose of generalization is to permit the incremental description of an element by sharing the descriptions of its ancestors. This is called inheritance. Inheritance is the mechanism by which a description of the objects of a class is assembled out of declaration fragments from the class and its ancestors. Inheritance permits shared parts of the description to be declared once and shared by many classes, rather than be repeated in each class that uses it. This sharing reduces the size of a model. More importantly, it reduces the number of changes that must be made on an update to the model and reduces the chance of accidental inconsistency. Inheritance works in a similar way for other kinds of elements, such as states, signals, and use cases. Inheritance Each kind of generalizable element has a set of inheritable properties. For any model element, these include constraints. For classifiers, they also include features (attributes, operations, and signal reception) and participation in associations. A child inherits all the inheritable properties of all its ancestors. Its complete set of properties is the set of inherited properties together with the properties that it declares directly. For a classifier, no attribute with the same signature may be declared more than once (directly or inherited). Otherwise, there is a conflict, and the model is ill formed. In other words, an attribute declared in an ancestor may not be redeclared in a descendant. An operation may be declared in more than one classifier, provided the specifications are consistent (same parameters, constraints, and mean- Chapter 4 • Static View 53 ing). Additional declarations are simply redundant. A method may be declared by multiple classes in a hierarchy. A method attached to a descendant supersedes and replaces (overrides) a method with the same signature declared in any ancestor. If two or more distinct copies of a method are nevertheless inherited by a class (via multiple inheritance from different classes), then they conflict and the model is ill formed. (Some programming languages permit one of the methods to be explicitly chosen. We find it simpler and safer just to redefine the method in the child class.) Constraints on an element are the union of the constraints on the element itself and all its ancestors; if any of them is inconsistent, then the model is ill formed. In a concrete class, each inherited or declared operation must have a method defined, either directly or by inheritance from an ancestor. Multiple inheritance If a classifier has more than one parent, it inherits from each one (Figure 4-8). Its features (attributes, operations, and signals) are the union of those of its parents. If the same class appears as an ancestor by more than one path, it nevertheless contributes only one copy of each of its members. If a feature with the same signature is declared by two classes that do not inherit it from a common ancestor (independent declarations), then the declarations conflict and the model is ill formed. UML does not provide a conflict resolution rule for this situation because experience has shown that the designer should explicitly resolve it. Some Figure 4-8. Multiple inheritance TimeStampedReservation Reservation targetDate: Date TimeStampedTransaction stamp() number: Integer received: Time confirm() This class inherits the attributes and operations of both of its parents. No new features are needed by the child. parent child parent 54 Part 2 • UML Concepts languages, such as Eiffel, permit conflicts to be explicitly resolved by the programmer, which is much safer than implicit conflict resolution rules, which frequently lead to surprises for the developer. Single and multiple classification In the simplest formulation, an object has one direct class. Many object-oriented languages have that restriction. There is no logical necessity that an object have a single class—we typically look at real-world objects from many angles simultaneously. In the more general formulation of UML, an object may have one or more direct classes. The object behaves as if it belonged to an implicit class that was a child of each of the direct classes—effectively, multiple inheritance without the need to actually declare the new class. Static and dynamic classification In the simplest formulation, an object may not change its class after it is created. Again, there is no logical necessity for this restriction. It is primarily intended to make the implementation of object-oriented programming languages easier. In the more general formulation, an object may change its direct class dynamically. In doing so, it may lose or gain attributes or associations. If it loses them, the information in them is lost and cannot be recovered later, even if it changes back to the original class. If it gains attributes or associations, then they must be initialized at the time of the change, in a similar manner to the initialization of a new object. When multiple classification is combined with dynamic classification, an object can gain and lose classes during its life. The dynamic classes are sometimes called roles or types. One common modeling pattern is to require that each object have a single static inherent class (one that cannot change during the life of the object) plus zero or more role classes that may be added or removed over the lifetime of the object. The inherent class describes its fundamental properties, and the role classes describe properties that are transient. Although many programming languages do not support multiple dynamic classification in the class declaration hierarchy, it is nevertheless a valuable modeling concept that can be mapped into associations. Realization The realization relationship connects a model element, such as a class, to another model element, such as an interface, that supplies its behavioral specification but not its structure or implementation. The client must support (by inheritance or by direct declaration) at least all the operations that the supplier has. Although realization is meant to be used with specification elements, such as interfaces, it can also be used with a concrete implementation element to indicate that its specifica- Chapter 4 • Static View 55 tion (but not its implementation) must be supported. This might be used to show the relationship of an optimized version of a class to a simpler but inefficient version, for example. Both generalization and realization relate a more general description to more detailed versions of it. Generalization relates two elements at the same semantic level (at the same level of abstraction, for example), usually within the same model; realization relates two elements at different semantic levels (an analysis class and a design class, for example, or an interface and a class), often found in different models. There may be two or more entire class hierarchies at different stages of development whose elements are related by realization. The two hierarchies need not have the same form because the realizing classes may have implementation dependencies that are not relevant to the specifying classes. Realization is displayed as a dashed arrow with a closed hollow arrowhead (Figure 4-9). It is similar to the generalization symbol with a dashed line, to indicate that it is similar to a kind of inheritance. Figure 4-9. Realization relationship Figure 4-10. Interface and realization icons «interface» ChoiceBlock PopUpMenu RadioButtonArray setDefault (choice: Choice) getChoice (): Choice Choice 1..∗ choice Button String setDefault (choice: Button) getChoice(): Button 1..∗ choice choice 1..∗ setDefault (choice: Button) getChoice(): Button realization relationship specifier implementation PrintServer SubmitJob CheckStatus SetPrintProperties realization interface class interface name 56 Part 2 • UML Concepts There is a special collapsed notation to show interfaces (without their contents) and the classes or components that realize them. The interface is shown as a small circle attached to the classifier rectangle by a solid line (Figure 4-10). Dependencies A dependency indicates a semantic relationship between two or more model elements. It relates the model elements themselves and does not require a set of instances for its meaning. It indicates a situation in which a change to the supplier element may require a change to or indicate a change in meaning of the client element in the dependency. The association and generalization relationships are dependencies by this defi- nition, but they have specific semantics with important consequences. Therefore, they have their own names and detailed semantics. We normally use the word dependency for all the other relationships that don’t fit the sharper categories. Table 4-3 lists the kinds of dependency found in the UML base model. A trace is a conceptual connection among elements in different models, often models at different stages of development. It lacks detailed semantics. It is typically used to trace system requirements across models and to keep track of changes made to models that may affect other models. A refinement is a relationship between two versions of a concept at different stages of development or at different levels of abstraction. The two concepts are not meant to coexist in the final detailed model. One of them is usually a less finished version of the other. In principle, there is a mapping from the less finished concept to the more finished concept. This does not mean that translation is automatic. Usually, the more detailed concept contains design decisions that have been made by the designer, decisions that might be made in many ways. In principle, changes to one model could be validated against the other, with deviations flagged. In practice, tools cannot do all this today, although some simpler mappings can be enforced. Therefore a refinement is mostly a reminder to the modeler that multiple models are related in a predictable way. A derivation dependency indicates that one element can be computed from another element (but the derived element may be explicitly included in the system to avoid a costly recomputation). Derivation, realization, refinement, and trace are abstraction dependencies—they relate two versions of the same underlying thing. A usage dependency is a statement that the behavior or implementation of one element affects the behavior or implementation of another element. Frequently, this comes from implementation concerns, such as compiler requirements that the definition of one class is needed to compile another class. Most usage dependencies can be derived from the code and do not need to be explicitly declared, unless they are part of a top-down design style that constrains the organization of the system (for example, by using predefined components and libraries). The specific Chapter 4 • Static View 57 Table 4-3: Kinds of Dependencies Dependency Function Keyword access Permission for a package to access the contents of another package access binding Assignment of values to the parameters of a template to generate a new model element bind call Statement that a method of one class calls an operation of another class call derivation Statement that one instance can be computed from another instance derive friend Permission for an element to access the contents of another element regardless of visibility friend import Permission for a package to access the contents of another package and add aliases of their names to the importer’s namespace import instantiation Statement that a method of one class creates instances of another class instantiate parameter Relationship between an operation and its parameters parameter realization Mapping between a specification and an implementation of it realize refinement Statement that a mapping exists between elements at two different semantic levels refine send Relationship between the sender of a signal and the receiver of the signal send trace Statement that some connection exists between elements in different models, but less precise than a mapping trace usage Statement that one element requires the presence of another element for its correct functioning (includes call, instantiation, parameter, send, but open to other kinds) use 58 Part 2 • UML Concepts kind of usage dependency can be specified, but this is often omitted because the purpose of the relationship is to highlight the dependency. The exact details can often be obtained from the implementation code. Stereotypes of usage include call and instantiation. The call dependency indicates that a method on one class calls an operation on another class; instantiation indicates that a method on one class creates an instance of another class. Several varieties of usage dependency grant permission for elements to access other elements. The access dependency permits one package to see the contents of another package. The import dependency goes further and adds the names of the target package contents to the namespace of the importing package. The friend dependency is an access dependency that permits the client to see even the private contents of the supplier. A binding is the assignment of values to the parameters of a template. It is a highly structured relationship with precise semantics obtained by substituting the arguments for the parameters in a copy of the template. Usage and binding dependencies involve strong semantics among elements at the same semantic level. They must connect elements in the same level of model (both analysis or both design, and at the same level of abstraction). Trace and re- finement dependencies are vaguer and can connect elements from different models or levels of abstraction. The instance of relationship (a metarelationship, not strictly a dependency) indicates that one element (such as an object) is an instance of another element (such as a class). A dependency is drawn as a dashed arrow from the client to the supplier, with a stereotype keyword to distinguish its kind, as shown in Figure 4-11. Constraint UML supplies a set of concepts and relationships for modeling systems as graphs of modeling elements. Some things, however, are better expressed linguistically— that is, using the power of a textual language. A constraint is a Boolean expression represented as a string to be interpreted in a designated language. Natural language, set theoretic notation, constraint languages, or various programming lanFigure 4-11. Dependencies BoxOffice SchedulingEngine «use» dependency keyword for client supplier dependency type Chapter 4 • Static View 59 guages may be used to express constraints. The UML includes the definition of a constraint language, called OCL, that is convenient for expressing UML constraints and is expected to be widely supported. See the entry for OCL and the book [Warmer-99] for more information on OCL. Constraints can be used to state various nonlocal relationships, such as restrictions on paths of associations. In particular, constraints can be used to state existence properties (there exists an X such that condition C is true) and universal properties (for all y in Y, condition D must be true). Some standard constraints are predefined as UML standard elements, including associations in an exclusive-or relationship and various constraints on the relationships of subclasses in generalization. See Chapter 14, Standard Elements, for more information. A constraint is shown as a text expression in braces. It may be written in a formal language or natural language. The text string may be placed in a note or attached to a dependency arrow. Figure 4-12 shows some constraints. Instances An instance is a run-time entity with identity, that is, something that can be distinguished from other run-time entities. It has a value at any moment in time. Over time the value can change in response to operations on it. One purpose of a model is to describe the possible states of a system and their behavior. A model is a statement of potentiality, of the possible collections of objects that might exist and the possible behavior history that the objects might undergo. The static view defines and constrains the possible configurations of values Figure 4-12. Constraints Member-of Chair-of {subset} Person Committee Person Company boss {Person.employer = Person.boss.employer} worker employer employee 0..1 * * * * * 0..1 1 Represents an incorporated entity. constraint on single class constraint as note constraint on path constraint between associations note 60 Part 2 • UML Concepts that an executing system may assume. The dynamic view defines the ways in which an executing system may pass from one configuration to another. Together, the static view and the various dynamic views based on it define the structure and behavior of a system. A particular static configuration of a system at one instant is called a snapshot. A snapshot comprises objects and other instances, values, and links. An object is an instance of a class. Each object is a direct instance of the class that completely describes it and an indirect instance of the ancestors of that class. (If multiple classification is allowed, then an object may be the direct instance of more than one class.) Similarly, each link is an instance of an association, and each value is an instance of a data type. An object has one data value for each attribute in its class. The value of each attribute must be consistent with the data type of the attribute. If the attribute has optional or multiple multiplicity, then the attribute may hold zero or multiple values. A link comprises a tuple of values, each of which is a reference to an object of a given class (or one of its descendants). Objects and links must obey any constraints on the classes or associations of which they are instances (including both explicit constraints and built-in constraints, such as multiplicity). The state of a system is a valid system instance if every instance in it is an instance of some element in a well-formed system model and if all the constraints imposed by the model are satisfied by the instances. The static view defines the set of objects, values, and links that can exist in a single snapshot. In principle, any combination of objects and links that is consistent with a static view is a possible configuration of the model. This does not mean that every possible snapshot can or will occur. Some snapshots may be legal statically but may not be dynamically reachable under the dynamic views in the system. The behavioral parts of UML describe the valid sequences of snapshots that may occur as a result of both external and internal behavioral effects. The dynamic views define how the system moves from one snapshot to another. Object diagram A diagram of a snapshot is an image of a system at a point in time. Because it contains images of objects, it is called an object diagram. It can be useful as an example of the system, for example, to illustrate complicated data structures or to show behavior through a sequence of snapshots over time (Figure 4-13). Remember that all snapshots are examples of systems, not definitions of systems. The definition of system structure and behavior is found in the definitional views, and constructing the definitional views is the goal of modeling and design. The static view describes the possible instances that can occur. Actual instances do not usually appear directly in models, except as examples. Chapter 4 • Static View 61 Figure 4-13. Object diagram triangle: Polygon point1: Point x = 0.0 y = 1.0 point2: Point x = 3.0 y = 1.0 point3: Point x = 3.0 y = 5.0 object PartOf PartOf PartOf link attribute
No comments:
Post a Comment