Object Oriented Software Engineering

(OOSE)
22CS017

Unified Modelling Language (UML)

Lecture (Theory)
Prepared By Dr. Dinesh Vij
 Index

• Introduction to UML
• Goals of UML
• Characteristics of UML
• UML Building Blocks
• UML Modelling Software
• Introduction to Use Case Diagram
• Practice Questions

2
Introduction to UML

• UML (Unified Modeling Language) is a general-purpose, graphical

modeling language in the field of Software Engineering.

• UML diagrams serve to describe, analyze, and test a system’s characteristics,

behaviors, and other features.

• It was initially developed by Grady Booch, Ivar Jacobson, and James

Rumbaugh in 1994-95 at Rational software.

• In 1997, it got adopted as a standard by the Object Management Group.

3
Goals of UML

• Provide users with 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.
• Support higher-level development concepts such as collaborations,
frameworks, patterns and components.

4
Characteristics of UML

• It is a generalized modeling language.

• It is distinct from other programming languages like C++, Python, etc.
• It is interrelated to object-oriented analysis and design.
• It uses diagrams to represent concepts, making it easier to understand
complex systems.
• It is used to visualize the workflow of the system.
• It is a pictorial language, used to generate powerful modeling artifacts.

5
UML Building Blocks

• UML is composed of three main building blocks, i.e., things, relationships,

and diagrams.

• Building blocks generate one complete UML model diagram by rotating

around several different blocks.

• The basic UML building blocks are enlisted below:

✔ Things
✔ Relationships
✔ Diagrams

6
Things

Things are the most important building blocks of UML. Things can be
−
• Structural
• Behavioral
• Grouping
• Annotational

7
Things (contd.)
1. Structural Things:
• They depict the static behavior of a model and display the physical and conceptual
components.
• They include class, object, interface, node, collaboration, component, and a use case.

⮚ Class: A Class is a set of identical things that outlines the functionality and properties of
an object. It also represents the abstract class whose functionalities are not defined. Its
notation is as follows;

8
Things (contd.)
⮚ Object: An individual that describes the behavior and the functions of a system. The notation
of the object is similar to that of the class; the only difference is that the object name is always
underlined and its notation is given below;

⮚ Interface: A set of operations that describes the functionality of a class.

9
Things (contd.)
⮚ Collaboration: It represents the interaction between things that is done to meet the goal.
It is symbolized as a dotted ellipse with its name written inside it.

⮚ Use case: Use case is the core concept of object-oriented modeling. It portrays a set of
actions executed by a system to achieve the goal.

10
Things (contd.)
⮚ Actor: It comes under the use case diagrams. It is an object that interacts with the system,
for example, a user.

⮚ Node: A physical element

⮚ Component: It represents the
that exists. E.g., server,
physical part of the system
printer, etc.
that reside on the node.

11
Things (contd.)

2. Behavioral Things:

• Behavioral things are the dynamic parts of UML models.

• In all, there are three primary kinds of behavioral things:

i. Interaction
ii. State Machine
iii. Activity

12
Things (contd.)

i. Interaction:
• It is a behavior that comprises a set of messages exchanged among a set of objects or
roles within a particular context to accomplish a specific purpose.

• An interaction involves a number of other elements, including messages, actions, and

connectors (the connection between objects).

• Graphically, a message is rendered as a directed line, almost always including the name
of its operation, as shown below

13
Things (contd.)
ii. State Machine
• It is a behavior that specifies the sequences of states an
object or an interaction goes through during its lifetime
in response to events, together with its responses to those
events.

• A state machine involves a number of other elements,

including states, transitions (the flow from state to state),
events (things that trigger a transition), and activities (the
response to a transition).

• Graphically, a state is rendered as a rounded rectangle,

usually including its name and its substates, if any.

14
Things (contd.)
iii. Activity
• It is a behavior that specifies the sequence of steps a
computational process performs.
• In an interaction, the focus is on the set of objects that
interact. In a state machine, the focus is on the life cycle
of one object at a time. In an activity, the focus is on the
flows among steps without regard to which object
performs each step.
• A step of an activity is called an action.
• Graphically, an action is rendered as a rounded rectangle
with a name indicating its purpose.
• States and actions are distinguished by their different
contexts.

15
Things (contd.)
3. Grouping Things:
• It is a method that together binds the elements of the UML model
• There is one primary kind of grouping thing, namely, packages.
• A package is a general-purpose mechanism for organizing the design itself, as opposed to
classes, which organize implementation constructs. Structural things, behavioral things,
and even other grouping things may be placed in a package.
• Unlike components (which exist at run time), a package is purely conceptual (meaning
that it exists only at development time).
• Graphically, a package is rendered as a tabbed folder, usually including only its name
and, sometimes, its contents

16
Things (contd.)
4. Annotational Things:

• Annotational things are the explanatory parts of UML models.

• These are the comments you may apply to describe, illuminate, and remark about any
element in a model.
• There is one primary kind of annotational thing, called a note.
• A note is simply a symbol for rendering constraints and comments attached to an element
or a collection of elements.
• Graphically, a note is rendered as a rectangle with a dog-eared corner, together with a
textual or graphical comment.

17
Relationships

• It illustrates the meaningful connections between things. There are four types of
relationships given below:
✔ Dependency
✔ Association
✔ Generalization
✔ Realization

1. Dependency: It is a semantic relationship between two model elements in which a change

to one element (the independent one) may affect the semantics of the other element (the
dependent one). Graphically, a dependency is rendered as a dashed line, possibly directed,
and occasionally including a label

18
Relationships (contd.)
2. Association:
• It is a structural relationship among classes that describes a set of links, a link being a
connection among objects that are instances of the classes.
• E.g.: city bus and riders.
• Aggregation is a special kind of association, representing a structural relationship
between a whole and its parts. E.g., shirt and pockets
• Graphically, an association is rendered as a solid line or it is denoted by a dotted line
with arrowheads on both sides to describe the relationship with the element on both
sides.

19
Relationships (contd.)
3. Generalization
• It is a specialization/generalization relationship in which the specialized element (the
child) builds on the specification of the generalized element (the parent).

• The child shares the structure and the behavior of the parent.
• E.g. vehicle is a bus, car, truck.

• Graphically, a generalization relationship is rendered as a solid line with a hollow

arrowhead pointing to the parent

20
Relationships (contd.)
4. Realization
• It is a semantic relationship between classifiers, wherein one classifier specifies a
contract that another classifier guarantees to carry out.

• You'll encounter realization relationships in these places:

✔ between interfaces and the classes or components that realize them, and
✔ between use cases and the collaborations that realize them.

• Graphically, a realization relationship is rendered as a cross between a generalization

and a dependency relationship

21
Examples

Figure: Inheritance

22
Examples Cont..

Figure: Class, Interface, tagged values

23
Examples Cont..

Figure: Generalization-Specialization relationship

24
Examples Cont..

Figure: Aggregation and association relationship

25
UML Modelling Software
• "UML Modelling Software" refers to a computer program that allows users to create
visual diagrams using the Unified Modeling Language (UML), a standardized way to
represent the structure and behavior of a software system.
• Essentially acting like a "blueprint" for designing software applications by visually
depicting different components and their relationships through various types of
diagrams.

• UML itself is not a programming language but a standardized notation, meaning

different UML modeling tools can interpret and display the diagrams in a consistent
manner.
Examples of popular UML modeling software:
• Visual Paradigm, Microsoft Visio, Lucidchart, StarUML, and Enterprise Architect.

26
Diagrams in UML

Figure 1: Types of Diagrams

27
Sequence Diagram

• Class diagrams, however, do not represent the dynamic behavior of the system
(how the system behaves when it performs some of its functions cannot be
represented by class diagrams).

• An interaction diagram typically captures the behavior of a use case and models
how the different objects in the system collaborate to implement the use case.

• A sequence diagram shows the series of messages exchanged between some

objects, and their temporal ordering, when objects collaborate to provide some
desired system functionality (or implement a use case).

28
Sequence Diagram

Sequence diagram for printing a graduation report

29
Collaboration Diagram

Collaboration diagram for printing a graduation report

30
Introduction to Use Case Diagram
What are Use Cases?
• In software and systems engineering, a use case is a list of actions or event steps,
typically defining the interactions between a role (known in the Unified Modeling
Language as an actor) and a system, to achieve a goal.
• The actor can be a human or an external system.
• A use case describes a way in which a real-world actor interacts with the system.
• It captures the functional requirements of a system, showing how different users
engage with various use cases, or specific functionalities, within the system.

31
Importance of Use Case

• Use cases have been used extensively over the past few decades.
• The advantages of Use cases include:
– The list of goal names provides the shortest summary of what the system will
offer.
– It gives an overview of the roles of each and every component in the system.
It will help us in defining the role of users, administrators, etc.

32
Relationships in Use case diagrams
In a Use Case Diagram, relationships play a crucial role in depicting the interactions
between actors and use cases.
1. Association Relationship
The Association Relationship represents a communication or interaction between an
actor and a use case. It is depicted by a line connecting the actor to the use case.
Example: Online Banking System
Actor: Customer
Use Case: Transfer Funds
Association: A line connecting the "Customer" actor to the "Transfer Funds" use case,
indicating the customer's involvement in the funds transfer process.

33
Relationships in Use case diagrams
2. Include Relationship
The Include Relationship indicates that a use case includes the functionality of another
use case. It is denoted by a dashed arrow pointing from the including use case to the
included use case. This relationship promotes modular and reusable design..
Example: Social Media Posting
• Use Cases: Compose Post, Add Image
• Include Relationship: The "Compose Post" use case includes the functionality of
"Add Image." Therefore, composing a post includes the action of adding an
image.

34
Relationships in Use case diagrams
3. Extend Relationship
The Extend Relationship illustrates that a use case can be extended by another use
case under specific conditions. It is represented by a dashed arrow with the keyword
"extend." This relationship is useful for handling optional or exceptional behavior.
Example: Flight Booking System
• Use Cases: Book Flight, Select Seat
• Extend Relationship: The "Select Seat" use case may extend the "Book Flight"
use case when the user wants to choose a specific seat, but it is an optional step.

35
Relationships in Use case diagrams
4. Generalization Relationship
The Generalization Relationship establishes an "is-a" connection between two use
cases, indicating that one use case is a specialized version of another. It is represented
by an arrow pointing from the specialized use case to the general use case.
Example: Vehicle Rental System
Use Cases: Rent Car, Rent Bike
Generalization Relationship: Both "Rent Car" and "Rent Bike" are specialized
versions of the general use case "Rent Vehicle."

36
How to draw a Use Case diagram in
UML?
Step 1: Identify Actors: Determine who or what interacts with the system. These are
your actors. They can be users, other systems, or external entities.
Step 2: Identify Use Cases: Identify the main functionalities or actions the system
must perform. These are your use cases. Each use case should represent a specific
piece of functionality.
Step 3: Connect Actors and Use Cases: Draw lines (associations) between actors
and the use cases they are involved in. This represents the interactions between actors
and the system.
Step 4: Add System Boundary: Draw a box around the actors and use cases to
represent the system boundary. This defines the scope of your system.
Step 5: Define Relationships: If certain use cases are related or if one use case is an
extension of another, you can indicate these relationships with appropriate notations.
Step 6: Review and Refine: Step back and review your diagram. Ensure that it
accurately represents the interactions and relationships in your system. Refine as
needed.
Step 7: Validate: Share your use case diagram with stakeholders and gather feedback.
Ensure that it aligns with their understanding of the system's functionality.

37
Example of Use Case Diagram

38
Contd…
The features of the system depends on the users of it.
• General use case

Figure 2: General Use case diagram of Hospital Management System

39
Contd…
• Monitor and Manage Patients’ Information and Status

Figure 3. Use case diagram of Monitor and Manage Patients’ Information and Status

40
Contd…
• Manage Hospital Rooms and Physicians’ Info and Status

Figure 4. Use case diagram of Manage Hospital Rooms and Physicians’ Info and Status

41
Contd…
• Monitor Hospital Transaction Records

Figure 5. Use case diagram of Monitor Hospital Transaction Records

42
 Practice Questions

• What is a UML diagram stereotype, and how is it used?

• How is inheritance represented in UML?
• Can you explain use case diagrams?
• Can you explain 'Extend' and 'Include' in use cases?
• What do you mean by structure diagram?

43
THANKS

44