A DEEPER VIEW INTO UML

A DEEPER VIEW INTO UML

 Use case diagrams represent the functionality of the system from a user’s point of view. They define the
boundaries of the system
 Class diagrams represent the static structure of a system in terms of objects, their attributes, operations, and
relationships
 Interaction diagrams represent the system’s behavior in terms of interactions among a set of objects. They
are used to identify objects in the application and implementation domains.
 State machine diagrams represent the behavior of nontrivial objects.
 Activity diagrams are flow diagrams used to represent the data flow or the control flow through a system.
 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.
 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.
 For the textual description of a use case, template
composed of six fields

 Name
 Participating actors
 Entry conditions
 The flow of events
 Exit conditions
 Quality requirements
 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.
 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
 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.
 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.

First Responder Interactive Emergency Navigational Database (FRIEND),

 Use case diagrams can include four types of relationships:

 Communication relationship
 Inclusion relationship
 Extension relationship
 Inheritance relationship
 Communication relationship
 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.
 Communication relationships between actors and use cases can be used to denote access to
functionality.
 Ex: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.
 Inclusion relationship
 When describing a complex system, its use case model can become quite complex and can contain redundancy. To
reduce the complexity of the model by identifying commonalities in different use cases.
 Two use cases are related by an include relationship if one of them includes the second one in its flow of events called as
Include relationship
 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»
 Extension relationship
 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
behavior specified by the extending use case.
 A typical application of extend relationships is the specification of exceptional behavior.
 Inheritance relationship
 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.
 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
 Scenarios
 A scenario is an instance of a use case describing a concrete set of actions.
 Scenarios are used as examples for illustrating common cases; their focus is on understandability.
 Use cases are used to describe all possible cases; their focus is on completeness.

Scenario using a template with three fields:

 The name of the scenario enables us to refer to it unambiguously.
 The participating actor instances field indicates which actor instances are involved in this scenario.
 The flow of events of a scenario describes the sequence of events step by step.
 Class Diagrams

 Classes and objects

 Associations and links
 Association class
 Roles
 Multiplicity
 Aggregation
 Qualification
 Inheritance
Classes and objects

 Class diagrams describe the structure of the system in terms of classes and objects.
 Classes are abstractions that specify the attributes and behavior of a set of objects.
 A class is a collection of objects that share a set of attributes that distinguish the objects as members
of the collection.
 Objects are entities that encapsulate state and behavior.

An example of a UML class diagram: classes that participate in the ReportEmergency use case.
An example of a UML object diagram: objects that participate in warehouseOnFire.
 Associations and links
 A link represents a connection between two objects. Associations are relationships between classes
and represent groups of links.
 Each FieldOfficer object also has a list of EmergencyReports that has been written by the FieldOfficer.
 In UML, associations can be symmetrical (bidirectional) or asymmetrical (unidirectional).
 Association class
 Associations are similar to classes, in that they can have attributes and operations attached to them.
Such an association is called an association class and is depicted by a class symbol that contains the
attributes and operations and is connected to the association symbol with a dashed line.
Roles
 Each end of an association can be labeled by a role.
 The roles of the association between EmergencyReport and FieldOfficer are author and reportsGenerated.

 Multiplicity Each end of an association can be labeled by a set of integers indicating the number of links
that can legitimately originate from an instance of the class connected to the association end.
 This set of integers is called the Multiplicity of the association end.
Most of the associations we encounter belong to one of the following three types
 A one-to-one association has a multiplicity 1 on each end. A one-to-one association between two classes
(e.g., PoliceOfficer and BadgeNumber) means that exactly one link exists between instances of each
class.
 A one-to-many association has a multiplicity 1 on one end and 0..n (also represented by a star) or 1..n on
the other. A one-to-many association between two classes.
 A many-to-many association has a multiplicity 0..n or 1..n on both ends. A manyto-many association
between two classes (e.g., FieldOfficer and IncidentReport) denotes that an arbitrary number of links can
exist between instances of the two classes.
 Aggregation
 Associations are used to represent a wide range of connections among a set of objects.
 A special case of association occurs frequently: Aggregation.
For example, a State contains many Counties, which in turn contain many Townships. A PoliceStation is
composed of PoliceOfficers.
A Directory contains a number of Files. Such relationships could be modeled using a one-to-many association.
 Qualification
 Qualification is a technique for reducing multiplicity by using keys. Associations with a 0..1 or 1 multiplicity are easier to
understand than associations with a 0..n or 1..n multiplicity. Often in the case of a one-to-many association, objects on the
“many” side can be distinguished from one another using a name.
For example, in a hierarchical file system, each file belongs to exactly one directory. Each file is uniquely identified by a name in
the context of a directory. Many files can have the same name in the context of the file system; however, two files cannot share the
same name within the same directory.
Without qualification (see top of Figure 2-31), the association between Directory and File has a one multiplicity on the Directory
side and a zero-to-many multiplicity on the File side. We reduce the multiplicity on the File side by using the filename attribute as
a key, also called a qualifier (see top of Figure 2-31). The relationship between Directory and File is called a qualified association
 Inheritance
 Inheritance is the relationship between a general class and one or more specialized classes. Inheritance
enables us to describe all the attributes and operations that are common to a set of classes.
 PoliceOfficer, the generalization, is called a superclass. FieldOfficer and Dispatcher, the specializations,
are called the subclasses. The subclasses inherit the attributes and operations from their parent class.
 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.
 Class diagrams are refined during system design and object design to include
classes representing the solution domain.
 Interaction Diagrams
 Interaction diagrams describe patterns of communication among a set of interacting objects. An
object interacts with another object by sending messages.
 Arguments may be passed along with a message and are bound to the parameters of the executing
method in the receiving object.
 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.
 Communication diagrams depict the same information as sequence diagrams.
Communication diagrams represent the sequence of messages by numbering
the interactions.
Applying interaction diagrams

 Interaction diagrams describe interactions among several objects.

 One of the main reasons for constructing an interaction diagram is to
uncover the responsibilities of the classes in the class diagrams and to
discover even new classes.
 In other words, the interaction diagram helps the developer in deciding
which objects require particular operations. T
 State Machine Diagrams
 A UML state machine is a notation for describing the sequence of states an object goes through in response to
external events. UML state machines are extensions of the finite state machine model.
 A state is a condition satisfied by the attributes of an object. For example, an Incident object in FRIEND can
exist in four states: Active, Inactive, Closed, and Archived.
 A transition represents a change of state triggered by events, conditions, or time.
 A state is depicted by a rounded rectangle. A transition is depicted by an open arrow connecting two states.
States are labeled with their name. A small solid black circle indicates the initial state. A circle surrounding a
small solid black circle indicates a final state.
 Actions are fundamental units of processing that can take a set of
inputs, produce a set of outputs, and can change the state of the
system. Actions normally take a short amount of time to execute and
are not interruptable.
 An internal transition is a transition that does not leave the state. Internal transitions are
triggered by events and can have actions associated with them. However, the firing of an
internal transition does not result in the execution of any exit or entry actions.
 An activity is a coordinated set of actions. A state can be associated an
activity that is executed as long as an object resides in this state. While
an action is short and non-interruptable, an activity can take a
substantial amount of time and is interrupted when a transition exiting
the state is fired.
 Nested state machines reduce complexity. They can be used instead of
internal transitions.
Applying state machine diagrams

 State machine diagrams are used to represent nontrivial behavior of a

subsystem or an 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.
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 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.
 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.
 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.
 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.
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.
 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.
 A note is a comment attached to a diagram. Notes are used by
developers for attaching information to models and model elements.
 Diagram Extensions
 UML provides a number of extension mechanisms enabling the modeler to extend the
language stereotypes and constraints
 A stereotype is an extension mechanism that allows developers to classify model elements
in UML. A stereotype is represented by string enclosed by guillemets (e.g., «boundary») and
attached to the model element to which it applies, such as a class or an association.
 A constraint is a rule that is attached to a UML model element restricting its semantics. This
allows us to represent phenomena that cannot otherwise be expressed with UML