Bule Hora University Department of Computer Science 2024

CHAPTER TWO
Unified Modeling Language (UML)
1. Introduction
UML was developed by Grady Booch, James Rumbaugh, and Ivar Jacobson in the 1990s and has
since become a widely adopted industry standard for software development. It is not specific to
any programming language or methodology, making it applicable to a wide range of software
development projects. Unified Modeling Language (UML) is a standardized visual modeling
language used to design, document, and communicate the structure and behavior of software
systems. It provides a set of graphical notations for representing different aspects of a system,
such as its structure, behavior, and interactions between components. UML diagrams are used to
represent various perspectives of a system and facilitate communication among stakeholders,
including software architects, developers, and clients
UML is a powerful tool for software development as it helps in visualizing, specifying,
constructing, and documenting software systems. It promotes a standardized and consistent
approach to system design, making it easier for teams to collaborate and understand complex
systems. UML has been designed for a broad range of applications. Hence, it provides constructs
for a broad range of systems and activities (e.g., real-time systems, distributed systems, analysis,
system design, and deployment). System development focuses on three different models of the
system:
 Functional Model: represented in UML with use case diagrams, describes the functionality
of the system from the user’s point of view.
 Object Model: represented in UML with class diagrams, describes the structure of a system
in terms of objects, attributes, associations, and operations.
 Dynamic Model: represented in UML with sequence diagrams, state chart diagrams, and
activity diagrams, describes the internal behavior of the system. Sequence diagrams describe
behavior as a sequence of messages exchanged among a set of objects, whereas state chart
diagrams describe behavior in terms of states of an individual object and the possible
transitions between states.
2. Where Can the UML Be Used
Unified Modeling Language (UML) is commonly applied for requirements analysis, system
design, object-oriented programming, software architecture, software documentation, system
maintenance and refactoring, and communication and collaboration. UML facilitates modeling,
analysis, and communication of system requirements, structure, behavior, and architecture. It is
used to design, document, and maintain software systems, aiding understanding and
collaboration among stakeholders.
Most commonly, a UML diagram is used to analyze existing software, model new software, and
plan software development and prioritization. Simply put, if you need a way to visualize and
plan your software development process, a UML diagram is incredibly helpful.

1
Bule Hora University Department of Computer Science 2024

3. Building Blocks of the UML

There are three major Building Blocks or elements of UML. those are:
 Things: The "things" in UML refer to the building blocks or elements that represent the
entities in a system. These include classes, objects, interfaces, components, packages, and
other similar entities that make up the structure of the system.
 Relationships: Relationships define the associations, dependencies, and connections between
the "things" in the system. These relationships depict how the elements interact and
collaborate with each other. Examples of relationships include associations, aggregations,
compositions, generalizations (inheritance), realizations (implementations), and
dependencies.
 Diagrams: Diagrams are graphical representations of the "things" and relationships in a
system. UML provides a variety of diagrams that allow you to visualize and communicate
different aspects of the system. Some common UML diagrams include class diagrams, use
case diagrams, sequence diagrams, activity diagrams, state machine diagrams, and
component diagrams. Diagrams provide a visual representation of the system, making it
easier to understand and communicate its structure, behavior, and interactions.
By utilizing these three major elements, UML provides a standardized and comprehensive
approach to modeling, documenting, and communicating software systems and other complex
systems.
4. Relationships in the UML
In the Unified Modeling Language (UML), relationships are used to represent associations,
dependencies, and connections between different elements within a system. There are several
types of relationships in UML, including:
 Association: Association represents a relationship between two or more classes, indicating
that objects of one class are connected to objects of another class. It is typically depicted as a
line connecting the classes, with optional multiplicity and role names.

 Aggregation: Aggregation represents a "part-of" relationship, where one class is composed

of or contains other classes. It is a specialized form of association where the whole can exist
independently of its parts. It is depicted using a diamond shape at the whole end of the
relationship.
 This is a special type of association
 The association with label “contains” or “is part of” is an aggregation
 It represents “has a “ relationship
 It is used when one object logically or physically contains other
 The container is called as aggregate
 It has a diamond at its end
 The components of aggregate can be shared with others

2
Bule Hora University Department of Computer Science 2024

 It expresses a whole - part relationships

 Composition: Composition is a stronger form of aggregation, where the composed class has
a strong lifecycle dependency on the container class. If the container is destroyed, the
composed class is also destroyed. It is represented by a filled diamond shape at the whole end
of the relationship.

 Generalization/Inheritance: Generalization, also known as inheritance, represents an "is-a"

relationship between classes. It signifies that one class (subclass or derived class) inherits the
properties and behavior of another class (superclass or base class). It is depicted as a solid
line with an open arrowhead pointing from the subclass to the superclass.

3
Bule Hora University Department of Computer Science 2024

 Realization/Implementation: Realization represents the relationship between an interface

and the class that implements it. It signifies that the implementing class provides the behavior
specified by the interface. It is depicted as a dashed line with an open arrowhead pointing
from the implementing class to the interface.
 Dependency: Dependency represents a relationship between two elements where a change in
one element may affect the other element. It is a weaker form of association and is typically
used when one element depends on another element without a direct structural relationship. It
is depicted as a dashed line with an open arrowhead pointing from the dependent element to
the supplier element.

These relationship types provide a means to depict the connections and dependencies between
elements in a system, allowing for a better understanding of the system's structure and behavior.
5. Diagrams in the UML
In the Unified Modeling Language (UML), diagrams are graphical representations that allow you
to visualize and communicate different aspects of a system. UML provides a variety of diagrams,
each serving a specific purpose. The commonly used UML diagrams are the following.
5.1. Use Case Diagrams
Use case diagrams are one of the most widely used and fundamental diagrams in the Unified
Modeling Language (UML). They depict the interactions between actors (users or external
systems) and the system under consideration. Use case diagrams focus on the functional
requirements of a system and illustrate the various use cases or functionalities that the system
provides. Key elements in a use case diagram include:
 Actors: Actors represent the external entities, such as users, other systems, or hardware
devices, that interact with the system. Actors are depicted as stick figures or named
rectangles.
 Use Cases: Use cases represent the specific functionalities or behaviors that the system
provides to its actors. Each use case represents a discrete task or goal that an actor can
perform using the system. Use cases are depicted as ovals or ellipses.
 Relationships: Relationships in a use case diagram illustrate the interactions and associations
between actors and use cases. The main relationship types are:
Association: represents a relationship between an actor and a use case, indicating that the
actor is involved in that particular use case.
Include: represents the relationship between two use cases, where one use case includes
the functionality of another use case. It signifies that the included use case is a part of the
including use case.

4
Bule Hora University Department of Computer Science 2024

Extend: used to connects two use cases, indicating that one use case extends or adds
additional functionality to another use case. It signifies that the extending use case is
optional and can be triggered under certain conditions.
 System Boundary: The system boundary is a rectangle that encloses all the use cases and
actors in the diagram, representing the scope or boundary of the system being modeled.
For example, Figure 2.1 depicts a use case diagram for a simple watch. The WatchUser
actor may either consult the time on their watch (with the ReadTimeuse case) or set the time
(with the SetTimeuse case). However, only the WatchRepairPersonactor may change the
battery of the watch (with the ChangeBatteryuse case).

Figure 2-1 A UML use case diagram describing the functionality of a simple watch. The
WatchUser actor may either consult the time on her watch (with the ReadTime use case) or set
the time (with the SetTime use case). However, only the WatchRepairPerson actor may change
the battery of the watch (with the ChangeBattery use case). Actors are represented with stick
figures, use cases with ovals, and the boundary of the system with a box enclosing the use cases.
5.2. Class Diagrams
Class Diagrams describe the structure of the system. Classes are abstractions that specify the
common structure and behavior of a set of objects. Objects are instances of classes that are
created, modified, and destroyed during the execution of the system. Objects have state that
includes the values of its attributes and its relationships with other objects.
Class diagrams describe the system in terms of objects, classes, attributes, operations, and their
associations. For example, Figure 2-2 is a class diagram describing the elements of all the
watches of the SimpleWatchclass. These watch objects all have an association to an object of the
PushButtonclass, an object of the Displayclass, an object of the Timeclass, and an object of the
Batteryclass. The numbers on the ends of associations denote the number of links each
SimpleWatchobject can have with an object of a given class. For example, a SimpleWatchhas
exactly two PushButtons, one Display, two Batteries, and one Time. Similarly, all PushButton,
Display, Time, and Batteryobjects are associated to exactly one SimpleWatch object.

5
Bule Hora University Department of Computer Science 2024

Figure 2-2 A UML class diagram describing the elements of a simple watch.
5.3. Sequence Diagrams
Sequence diagrams are used to formalize the behavior of the system and to visualize the
communication among objects. They are useful for identifying additional objects that participate
in the use cases. We call objects involved in a use case participating objects. A sequence diagram
represents the interactions that take place among these objects. For example, Figure 2-3 is a
sequence diagram for the SetTimeuse case of our simple watch. The leftmost column represents
the WatchUseractor who initiates the use case. Labeled arrows represent stimuli that an actor or
an object sends to other objects. In this case, the WatchUserpresses button 1 twice and button 2
once to set her watch a minute ahead. The SetTimeuse case terminates when the
WatchUserpresses both buttons simultaneously.

Figure 2-3 A UML sequence diagram for the SimpleWatch. The leftmost column represents the
timeline of the WatchUser actor who initiates the use case. The other columns represent the
timeline of the objects that participate in this use case. Object names are underlined to denote
that they are instances (as opposed to classes). Labeled arrows are stimuli that an actor or an
object sends to other objects.
5.4. State Chart Diagrams
State Chart Diagrams describe the behavior of an individual object as a number of states and
transitions between these states. A state represents a particular set of values for an object. Given
a state, a transition represents a future state the object can move to and the conditions associated
with the change of state. For example, Figure 2-4 is a state chart diagram for the SimpleWatch.

6
Bule Hora University Department of Computer Science 2024

Note that this diagram represents different information than the sequence diagram of Figure 2-3
does. The sequence diagram focuses on the messages exchanged between objects as a result of
external events created by actors. The state chart diagram focuses on the transitions between
states as a result of external events for an individual object

Figure 2-4 A UML state chart diagram for SetTime use case of the SimpleWatch.
5.5. Activity Diagrams

The main reason to use activity diagrams is to model the workflow behind the system
being designed. Activity Diagrams are also useful an activity diagram describes a system
in terms of activities. Activities are states that represent the execution of a set of
operations. The completion of these operations triggers a transition to another activity.
Activity diagrams are similar to flowchart diagrams in that they can be used to represent
control flow (i.e., the order in which operations occur) and data flow (i.e., the objects that
are exchanged among operations). For example, Figure 2-5 is an activity diagram
representing activities related to managing an Incidentin FRIEND. Rounded rectangles
represent activities; arrows represent transitions between activities; thick bars represent
the synchronization of the control flow. The activity diagram of Figure 2-5 depicts that
the AllocateResources , CoordinateResources , and DocumentIncidentcan be initiated
only after the OpenIncidentactivity has been completed. Similarly, the
ArchiveIncidentactivity can be initiated only after the completion of AllocateResources ,
CoordinateResources , and DocumentIncident . These latter three activities, however, can
occur concurrently.

7
Bule Hora University Department of Computer Science 2024

Figure 2-5 An example of a UML activity diagram. Activity diagrams represent behavior in
terms of activities and their precedence constraints. The completion of an activity triggers an
outgoing transition, which in turn may initiate another activity.
5.6. Component Diagram
Component Diagrams in UML illustrate the structure of a software system by depicting its
software components, their interfaces, and dependencies. These diagrams can be used to model
software systems at a high level or to showcase components at a lower, package level. They
support component-based development, where a system is divided into reusable and replaceable
components and interfaces.
There are several reasons why component diagrams are valuable:
 Defining executable and reusable aspects: Component diagrams help define the executable
and reusable aspects of a software system, enabling a clear understanding of its functional
components and their interactions.
 Revealing configuration issues: By depicting dependency relationships, component
diagrams reveal software configuration issues, allowing for the identification and resolution
of potential problems.
 Providing an accurate depiction: Component diagrams offer an accurate representation of a
software application, enabling stakeholders to visualize the system's structure before
implementing changes or enhancements.
Additionally, component diagrams can represent the physical parts of a software system,
including:
 Source code files developed in an integrated development environment.
 Executable files required for delivering a running system.
 Physical databases that store information in tables (relational database) or pages (object-
oriented database).
 Adaptable systems with components capable of migrating for load balancing and failure
recovery.
In summary, component diagrams serve as valuable tools for understanding, designing, and
communicating the structure and dependencies of software systems, enabling effective
component-based development and system analysis.

8
Bule Hora University Department of Computer Science 2024

5.7. Deployment Diagram

In UML, deployment diagrams depict the physical structure of a system, illustrating the
relationships between its software and hardware components and the actual distribution of
processing. These diagrams are created during the implementation phase of development and
showcase the physical arrangement of nodes in a distributed system, the artifacts stored on each
node, and the components and other elements implemented by these artifacts. Nodes in
deployment diagrams represent hardware devices such as computers, sensors, printers, and other
devices that support the system's runtime environment. Communication paths and deploy
relationships are used to model the connections and interactions within the system.
To summarize, deployment diagrams in UML provide a visual representation of the physical
architecture of a system, showcasing the relationships between software and hardware
components, the distribution of processing, and the arrangement of nodes in a distributed system.
They are typically created during the implementation phase and help in understanding and
communicating the system's physical deployment.
 A deployment diagram shows the relationship among software and hardware components
in the delivered system.
 These diagram include nodes and connections between nodes.
 Each node in deployment diagram represents some kind of computational unit, in most
cases a piece of hardware.
 Connection among nodes show the communication path over which the system will
interact.
 The connections may represent direct hardware coupling line RS-232 cable, Ethernet
connection, they also may represent indirect coupling such as satellite to ground
communication.

9
Bule Hora University Department of Computer Science 2024

Deployment diagrams are effective for visualizing, specifying, and documenting the following
types of systems:
 Embedded Systems: that use hardware that is controlled by external stimuli; for example, a
display that is controlled by temperature change
 Client/server Systems: that typically distinguish between the user interface and the
persistent data of a system
 Distributed Systems: that have multiple servers and can host multiple versions of software
artifacts, some of which might even migrate from node to node
Because deployment diagrams focus on the configuration of the runtime processing nodes and
their components and artifacts, you can use this type of diagram to assess the implications of
distribution and resource allocations.
5.8. Diagram Extensions
In addition to the standard UML diagrams, there are also some diagram extensions or variations
that are commonly used in specific domains or for specialized purposes. These extensions adapt
the UML notation to address the specific needs of different industries or aspects of system
modeling. Some of the diagram extensions are:
 Package Diagram: is used to organize and illustrate the dependencies between packages in a
system. It helps in visualizing the high-level structure and organization of the system's
components.
 Communication Diagram: is also known as a collaboration diagram, focuses on the
interactions between objects or actors. It emphasizes the messages exchanged between
objects rather than the sequence of events.

10
Bule Hora University Department of Computer Science 2024

 Component Diagram: While a component diagram exists in the standard UML, it is worth
mentioning that it can also be extended and utilized to represent system components in more
detail. This extension may involve specifying component interfaces, ports, provided and
required interfaces, and other related information.
 Data Flow Diagram (DFD): is not a part of the standard UML, but it is commonly used for
visualizing the flow of data within a system. It illustrates how data is input, processed, and
output by various components or subsystems.
 Entity-Relationship Diagram (ERD): is used to model the data entities, relationships, and
attributes within a database. It helps in understanding the structure and relationships between
various data elements.
 Timing Diagram: is used to represent the behavior and timing constraints of objects and
messages in a system over a specific period. It shows the chronological order of events and
the duration of actions.
These diagram extensions provide additional modeling capabilities and offer specialized
representations for specific aspects of system design and analysis. They can be used in
conjunction with the standard UML diagrams to provide a more comprehensive and domain-
specific view of the system.

11