Chapter 2

Unified Modeling Language (UML)

An Overview of UML
• The Unified Modeling Language (UML) is a standard graphical
language for modeling object-oriented software.
• It was developed in the mid-1990s as a collaborative effort by James
Rumbaugh, Grady Booch and Ivar Jacobson,
• each of whom had developed their own notation in the early 1990s.
• The UML is a language for specifying, constructing, visualizing, and
documenting the software system
• The UML is a graphical language with sets of rules and semantics.

• The rules and semantics of a model are expressed in English, in a form

known as object constraint language (OCL).
2
Goals of UML
• The primary goals in the design of the UML were as follows:
• Provide users a ready-to-use, expressive visual modeling language so they can
develop and exchange meaningful models.
• Provide extensibility and specialization mechanisms to extend the core
concepts.
• Be independent of particular programming languages and development
processes.
• Provide a formal basis for understanding the modeling language.
• Encourage the growth of the 00 tools market.
• Support higher-level development concepts.
• Integrate best practices and methodologies.

3
Building Blocks of UML
• The building blocks of UML can be defined as:
• Things
• Relationships
• Diagrams
• Things: - are the most important building blocks of UML. Things can
be:
• Structural
• Behavioral
• Grouping
• A notational

4
… Building Blocks Of UML
• Structural things:
• The Structural things define the static part of the model.
• They represent physical and conceptual elements.
• Following are the brief descriptions of the structural things.
• Class
• Class represents a group of objects having similar responsibilities.
• Using UML, a class is represented using a rectangle with 3 compartments
corresponding to the name of the class, attributes and operations
ClassName
Attributes
Operations
5
… Structural things
• Interface:
• Interface defines a set of operations which specify the responsibility of a
class. Interface

• Collaboration:
• Collaboration defines interaction between elements.

• Use case:
• Use case represents a set of actions performed by a system for a specific goal.

Use case

6
• Component:
• Component describes physical part of a system.

• Node:
• A node can be defined as a physical element that exists at run time

7
Behavioral things
• A behavioral thing consists of the dynamic parts of UML models.
Following are the behavioral things:
• Interaction:
• Interaction is defined as a behavior that consists of a group of messages
exchanged among elements to accomplish a specific task.
Message

• State machine:
• State machine is useful when the state of an object in its life cycle is
important.
• It defines the sequence of states an object goes through in response to
events.
• Events are external factors responsible for state change. State
8
Grouping things & Notational things
• Grouping things can be defined as a mechanism to group elements of
a UML model together.
• There is only one grouping thing available:
• Package
• Package is the only one grouping thing available for gathering structural and
behavioral things.

• A notational thing:
• A notational thing can be defined as a mechanism to capture
remarks, descriptions, and comments of UML model elements.
• Note is the only one a notational thing available.
• Note: A note is used to render comments, constraints etc. of an UML
element. 9
(2) Relationship
• Relationship is another most important building block of UML.
• It shows how elements are associated with each other.
• There are four kinds of relationships available:
• Dependency:
• Dependency is a relationship between two things in which change in one
element also affects the other.

• Association:
• Association is basically a set of links that connects elements of an UML model.
It also describes how many objects are taking part in that relationship.

10
• Generalization:
• Generalization can be defined as a relationship which connects a specialized
element with a generalized element. It basically describes inheritance
relationship in the world of objects.

• Realization:
• Realization can be defined as a relationship in which two elements are
connected.
• One element describes some responsibility which is not implemented and the
other one implements them.
• This relationship exists in case of interfaces.

11
UML Diagrams
• All the elements, relationships are used to make a complete UML
diagram and the diagram represents a system
• UML includes the following nine diagrams:

• Class diagram
• Activity diagram
• Collaboration diagram
• Component diagram
• Deployment diagram
• Sequence diagram
• Object diagram
• State chart diagram
• Use case diagram

12
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.
• Describe the functionality of the system w.r.t external users
• Actors initiate a use case to access the system functionality. The use case can
then initiate other use cases

13
… use case diagrams
• For example, in an accident management system, field officers, such
as, a police officer or a fireman 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, FieldOfficer and Dispatcher are actors

14
… Use case diagrams
• the actor FieldOfficer invokes the use case ReportEmergency to notify
the actor Dispatcher of a new emergency.
• As a response, the Dispatcher invokes the OpenIncident use case to
create an incident report.
• The Dispatcher enters preliminary information from the FieldOfficer in
the incident database and orders additional units to the scene with
the AllocateResources use case.
• the associations are bidirectional:
• They can represent the actor initiating a use case (e.g., FieldOfficer initiates
ReportEmergency) or
• a use case providing information to an actor (e.g., ReportEmergency notifies
Dispatcher).
15
 Register for Courses

Student Select courses to teach

Maintain professor Professor

information

Maintain student
Registrar
information

Maintain curriculum

Use case diagram for a Registrar system

16
Use cases
• To describe a use case, we use a template composed of six fields:
• 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 actions of the use case,
which are numbered for reference. The common case (i.e., cases that
occur frequently) and the exceptional cases (i.e., cases that seldom
occur, such as errors and unusual conditions) are described separately
in different use cases for clarity.
17
… Use case description template
• Exit conditions describe the conditions that are satisfied after the
completion of the use case.
• Special 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.
• Use case descriptions are written in natural language.
• This enables developers to use them for communicating with the
client and the users
• The use of natural language also enables participants from other
disciplines to understand the requirements of the system
18
19
Scenarios
• A use case is an abstraction that describes all possible scenarios
involving the described functionality.
• A use case is an abstraction of scenarios (it is a class)
• A scenario is an instance of a use case describing a concrete set of
actions.
• The focus of scenarios is on understandability.
• Use cases are used to describe all possible cases.
• The focus of a use case is on completeness.

20
… Scenarios
• We describe a scenario using a template with three fields:
• The name of the scenario enables us to refer to it unambiguously.
• The name of a scenario is underlined to indicate that it is an instance.
• The participating actor instances field indicates which actor instances
are involved in this scenario.
• Actor instances also have underlined names.
• The flow of events of a scenario describes the sequence of events
step by step.

21
Communication relationships
• Actors and use cases communicate when information is exchanged
between them.
• Communication relationships are depicted by a solid line between the
actor and use case symbol
• Include relationships
• When describing a complex system, its use case model can become quite
complex and can contain redundancy.
• We reduce the complexity of the model by identifying commonalities in
different use cases
• For example, assume that the Dispatcher can press at any time a key
to access Help.
• This can be modeled by a use case HelpDispatcher that is included by the use
cases OpenIncident and AllocateResources 22
… Communication relationships
• The resulting model only describes the HelpDispatcher functionality
once, thus reducing complexity
• In UML, include relationships are depicted by a dashed arrow
originating from the including use case.
• Include relationships are labeled with the string <<include>>.

23
… Communication relationships
• Extend relationships
• 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.
• Example: assume that the network connection between the
Dispatcher and the FieldOfficer can be interrupted at any time

24
• The use case ConnectionDown describes the set of events taken by
the system and the actors while the connection is lost.
• ConnectionDown extends the use cases OpenIncident and
AllocateResources.
• Separating exceptional behavior from common behavior enables us to
write shorter and more focused use cases

25
Generalization relationships
• Generalization/specialization relationships are a third mechanism for
reducing the complexity of a model.
• A use case can specialize a more general one by adding more detail.
• For example, FieldOfficers are required to authenticate before they
can use FRIEND.

26
Class Diagrams
• 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.
• Objects are entities that encapsulate state and behavior.
• Each object has an identity: It can be referred individually and is
distinguishable from other objects.
• In UML, classes and objects are depicted by boxes including three
compartments.

27
… Classes & Objects
• The top compartment displays the name of the class or object.
• The center compartment displays its attributes, and the bottom
compartment displays its operations.
• The attribute and operation compartment can be omitted for clarity.
• Object names are underlined to indicate that they are instances.
• By convention, class names start with an uppercase letter.
• Objects in object diagrams may be given names (followed by their
class) for ease of reference. In that case, their name starts with a
lowercase letter.

28
Classes & Objects
• The main symbols shown on class diagrams are:
• Classes, which represent the types of data themselves.
• Associations, which show how instances of classes reference
instances of other classes.
• Attributes, which are simple data found in instances.
• Operations, which represent the functions performed by the
instances.
• Generalizations, which are used to arrange classes into inheritance
hierarchies
• Example: bob:FieldOfficer, alice:FieldOfficer are two different objects of the
class FieldOfficer
29
… Classes & Objects
• An example of a UML class diagram

30
… Classes & Objects
• An example of a UML object diagram: objects that participate in the
warehouse On Fire scenario.

31
… Classes & Objects
• 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 the previous class diagram, the line between the FieldOfficer class and the
EmergencyReport class is an association.
• In the figure, the line between the alice:FieldOfficer object and the
report_1291:EmergencyReport object is a link

32
… Classes & Objects
• Roles
• Each end of an association can be labeled by a string called role.
• the roles of the association between the EmergencyReport and
FieldOfficer classes are author and reportsGenerated.
• Labeling the end of associations with roles allows us to distinguish
multiple associations originating from a class.

33
… Classes & Objects
• 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.
• The association end author has a multiplicity of 1.
• This means that all EmergencyReports are written by exactly one FieldOfficer.
• In other terms, each EmergencyReport object has exactly one link to an
object of class FieldOfficer.
• The multiplicity of the association end reportsGenerated role is “many,”
shown as a star (*).
• The “many” multiplicity is shorthand for 0..n.
• This means that any given FieldOfficer may be the author of zero or more
EmergencyReports. 34
Aggregation
• Associations are used to represent a wide range of connections among a
set of objects.
• In practice, a special case of association occurs frequently: composition.
• For example, a State contains many Counties, which in turn contains many
Townships.
• A PoliceStation is composed of PoliceOfficers.
• a Directory that contains a number of Files.
• Such relationships could be modeled using a one-to-many association.
• Instead, UML provides the concept of an aggregation to denote
composition.
• An aggregation is denoted by a simple line with a diamond at the
container end of the association.
35
… Aggregation
• Example aggregation

36
Generalization
• Generalization is the relationship between a general class and one or
more specialized classes.
• Generalization enables us to factor out common attributes and
operations into the base class that aids in reducing redundancy.
• Example: FieldOfficer and Dispatcher both have name and
badgeNumber attributes.
• However, FieldOfficer has an association with EmergencyReport, whereas
Dispatcher has an association with Incident.
• The common attributes of FieldOfficer and Dispatcher can be
modeled by introducing a PoliceOfficer class that is specialized by the
FieldOfficer and the Dispatcher classes.

37
… Generalization
• PoliceOfficer, the generalization, is called a superclass. FieldOfficer
and Dispatcher, the specializations, are called the subclasses.

38
UML: Dynamic models
• Sequence diagram:
• Shows the interaction between objects
• Each column represents an object that participates in the interaction.
• The vertical axis represents time from top to bottom.
• Messages are shown by arrows.
• Labels on arrows represent message names and may contain
arguments.
• Activations (i.e., executing methods) are depicted by vertical
rectangles.
• Actors are shown as the leftmost column.
• The sequence diagram focuses on the messages exchanged between
objects as a result of external events created by actors. 39
Sequence diagram
• Example of a sequence diagram: setting the time on 2Bwatch (two
button watch)

40
… UML: Dynamic models
• State chart Diagram:
• is a notation for describing the sequence of states an object goes through in
response to external events.
• The state machine diagram focuses on the transitions between states as
a result of external events for an individual object
• A transition represents changes of state triggered by events, conditions,
or time
• A state is depicted by a rounded rectangle.
• A transition is depicted by arrows 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. 41
• A state machine diagram for the Watch (2Bwatch)

42