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 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
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.

22
Diagrams in UML

Figure 1: Types of Diagrams

23
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.

24
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.

25
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

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

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

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

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

28
Contd…
• Monitor Hospital Transaction Records

Figure 5. Use case diagram of Monitor Hospital Transaction Records

29
 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?

30
THANKS

31