UNIT-4

UNIT – IV: Class Modeling: Object and Class Concepts, Link and Association concepts, Generalization and
Inheritance, A Sample Class Model.
State Modeling: Events, States, Transitions and Conditions, state diagrams.
Interaction Modelling: Use Case Models, Sequence Models, Activity Models.
Types of Models:
There are 3 types of models in the object oriented modelling and design are: Class Model, State Model,
and Interaction Model. These are explained as following below.
1. Class Model:
The class model shows all the classes present in the system. The class diagram is used to show the
class model. The class diagram shows the class name followed by the attributes followed by the
functions or the methods that are associated with the object of the class. Goal in constructing class
model is to capture those concepts from the real world that are important to an application.
2. State Model:
State model describes those aspects of objects concerned with time and the sequencing of operations –
events that mark changes, states that define the context for events, and the organization of events and
states. Actions and events in a state diagram become operations on objects in the class model. State
diagram describes the state model.
3. Interaction Model:
Interaction model is used to show the various interactions between objects, how the objects collaborate
to achieve the behaviour of the system as a whole.
The following diagrams are used to show the interaction model:
• Use Case Diagram
• Sequence Diagram
• Activity Diagram

CLASS MODELLING
A class model captures the static structure of a system by characterizing the objects in the system, the
relationships between the objects, and the attributes and operations for each class of objects. The class model
is the most important of the three models.
Object & Class Concepts
Objects:
➢ The purpose of class modelling is to describe objects. An object is a concept, abstraction, or thing
with identity that has meaning for an application.
➢ An object is an instance of class, representing a real-world entity. It contains data and methods
specific to that instance.
➢ The choice of objects depends on judgment and the nature of a problem; there can be many correct
representations.
➢ All objects have identity and are distinguishable.
➢ Two apples with the same colour, shape, and texture are still individual apples; a person can eat one
and then eat the other. Similarly, identical twins are two distinct persons, even though they may look
the same. The term identity means that objects are distinguished by their inherent existence and not
by descriptive properties that they may have.
➢
Classes:
➢ An object is an instance—or occurrence—of a class. A class describes a group of objects with the
same properties (attributes), behaviour (operations), kinds of relationships, and semantics.
➢ Objects in a class have the same attributes and forms of behaviour. Most objects derive their
individuality from differences in their attribute values and specific relationships to other objects.
➢ Each object “knows” its class. Most OO programming languages can determine an object’s class at
run time. An object’s class is an implicit property of the object.
 ➢ A class describes an object and they also form a hierarchy to model the real-world system. The
hierarchy is represented as inheritance and the classes can also be associated in different ways as per
the requirement.
Class Diagrams:
➢ Class diagram is a static diagram. It represents the static view of an application. Class diagram is not
only used for visualizing, describing, and documenting different aspects of a system but also for
constructing executable code of the software application.
➢ Class diagram describes the attributes and operations of a class and also the constraints imposed on
the system.
➢ The class diagram can be used to show the classes, relationships, interface, links, association, and
collaboration.
➢ Since classes are the building block of an application that is based on OOPs, so as the class
diagram has an appropriate structure to represent the classes, inheritance, relationships, and
everything that OOPs have in their context.

An object diagram shows individual objects and their relationships. Object diagrams are helpful for
documenting test cases and discussing examples.
A class diagram corresponds to an infinite set of object diagrams.

Figure 4.1 A class and objects. Objects and classes are the focus of class modelling.

Values and Attributes

• A value is a piece of data. You can find values by examining problem documentation for examples.
• Attributes are data elements that are contained in every object of a class and have a value for each of
these objects. Attributes are shown in the middle of the class rectangle, are aligned left, and the first
letter is lowercase (note that it is very common to use camelCase for both attributes and methods).
• The following analogy holds: Object is to class as value is to attribute.
Operations and Methods
Classes have particular operations for dealing with communication with other classes. Methods are shown in
the bottom part of the class rectangle and, like attributes, are aligned left with the first letter in lowercase.

There are three types of modifiers that are used to decide the visibility of attributes and operations.
• + is used for public visibility (for everyone)
• # is used for protected visibility (for friend and derived)
 • – is used for private visibility (for only me)
• ~ means package

Relationships between classes

If used correctly, UML precisely conveys how code should be implemented from diagrams.
A class may be involved in one or more relationships with other classes. A relationship can be one of the
following types:
Links and Associations
A link is a physical or conceptual connection among objects. Most links relate two objects, but some links
relate three or more objects.
Associations is a set of links that connects elements of the UML model. It also defines how many objects
are taking part in that relation.
Association is represented by a dotted line with (without) arrows on both sides. The two ends represent two
associated elements as shown in the following figure.
The multiplicity is also mentioned at the ends (1, *, etc.) to show how many objects are associated.

Multiplicity: Multiplicity in an association specifies how many objects participate in a relationship.

Multiplicity decides the number of related objects. Multiplicity is generally explained as “one” or “many,”
but in general it is a subset of the non-negative integers.
Generalization(Inheritance)
Generalization describes the inheritance relationship of the object-oriented world. It is a parent and child
relationship.

Generalization is represented by an arrow with a hollow arrow head as shown in the following figure. One
end represents the parent element and the other end represents the child element.

Generalization is used to describe parent-child relationship of two elements of a system.

Dependency
Dependency is an important aspect in UML elements. It describes the dependent elements and the direction
of dependency.
Dependency is represented by a dotted arrow as shown in the following figure. The arrow head represents
the independent element and the other end represents the dependent element.

Dependency is used to represent the dependency between two elements of a system.

Aggregation

This type of association relationship indicates an element is formed by a collection of other elements.

For instance, a company has departments or a library has books. The aggregate element relies on other
elements as parts, but those other elements can also exist independently of it. An aggregation is represented by
a line from one class to another, with an unfilled diamond shape near the aggregate, or the element that
represents the class that is assembled by combining the part elements.
Another type of aggregation relationship, composition, is one in which the part elements cannot exist without
the aggregate. For instance, the rooms in a house cannot continue to exist if the house is destroyed. For a
composition relationship, a filled diamond is shown on the line near the aggregate.

A sample class Diagram

State Modelling

A state diagram is used to represent the condition of the system or part of the system at finite instances of
time. It’s a behavioural diagram and it represents the behaviour using finite state transitions. State diagrams
are also referred to as State machines and State-chart Diagrams. These terms are often used interchangeably.
So simply, a state diagram is used to model the dynamic behaviour of a class in response to time and changing
external stimuli.
Uses of state chart diagram –

• We use it to state the events responsible for change in state (we do not show what processes cause
those events).
• We use it to model the dynamic behaviour of the system.
• To understand the reaction of objects/classes to internal or external stimuli.

Firstly, let us understand what are Behaviour diagrams? There are two types of diagrams in UML:

1. Structure Diagrams – Used to model the static structure of a system, for example- class diagram,
package diagram, object diagram, deployment diagram etc.
2. Behaviour diagram – Used to model the dynamic change in the system over time. They are used to
model and construct the functionality of a system. So, a behaviour diagram simply guides us through
the functionality of the system using Use case diagrams, Interaction diagrams, Activity diagrams and
State diagrams.

Difference between state diagram and flowchart –

The basic purpose of a state diagram is to portray various changes in state of the class and not the processes
or commands causing the changes. However, a flowchart on the other hand portrays the processes or
commands that on execution change the state of class or an object of the class.

Figure – a state diagram for user verification

The state diagram above shows the different states in which the verification sub-system or class exist for a
particular system.

Basic components of a state chart diagram –

1.Initial state – We use a black filled circle represent the initial state of a System or a class.

Figure – initial state notation

2.Transition – We use a solid arrow to represent the transition or change of control from one state to
another. The arrow is labelled with the event which causes the change in state.

Figure – transition

3.State – We use a rounded rectangle to represent a state. A state represents the conditions or circumstances
of an object of a class at an instant of time.
 Figure – state notation

4.Fork – We use a rounded solid rectangular bar to represent a Fork notation with incoming arrow from the
parent state and outgoing arrows towards the newly created states. We use the fork notation to represent a
state splitting into two or more concurrent states.

Figure – a diagram using the fork notation

5.Join – We use a rounded solid rectangular bar to represent a Join notation with incoming arrows from the
joining states and outgoing arrow towards the common goal state. We use the join notation when two or
more states concurrently converge into one on the occurrence of an event or events.

Figure – a diagram using join notation

6.Self transition – We use a solid arrow pointing back to the state itself to represent a self transition. There
might be scenarios when the state of the object does not change upon the occurrence of an event. We use
self transitions to represent such cases.

Figure – self transition notation

1.Composite state – We use a rounded rectangle to represent a composite state also.We represent a state
with internal activities using a composite state.

Figure – a state with internal activities

2.Final state – We use a filled circle within a circle notation to represent the final state in a state machine
diagram.
 Figure – final state notation

Steps to draw a state diagram –

1. Identify the initial state and the final terminating states.

2. Identify the possible states in which the object can exist (boundary values corresponding to different
attributes guide us in identifying different states).
3. Label the events which trigger these transitions.

Example – state diagram for an library management system –

Interaction Modelling
Use-Case Modelling:

To model a system, the most important aspect is to capture the dynamic behaviour. Dynamic behaviour
means the behaviour of the system when it is running/operating. Only static behaviour is not sufficient to
model a system rather dynamic behaviour is more important than static behaviour. In UML, there are five
diagrams available to model the dynamic nature and use case diagram is one of them.
The Use-case model is defined as a model which is used to show how users interact with the system in order
to solve a problem. As such, the use case model defines the user's objective, the interactions between the
system and the user, and the system's behaviour required to meet these objectives.

Use-case diagrams are helpful in the following situations:

Before starting a project, you can create use-case diagrams to model a business so that all participants in the
project share an understanding of the workers, customers, and activities of the business.

• While gathering requirements, you can create use-case diagrams to capture the system requirements
and to present to others what the system should do.
• During the analysis and design phases, you can use the use cases and actors from your use-case
diagrams to identify the classes that the system requires.
• During the testing phase, you can use use-case diagrams to identify tests for the system.

Basic Use-Case Diagram Symbols and Notations

Here are following use-case diagram symbols and notations:

System

With the help of the rectangle, we can draw the boundaries of the system, which includes use-cases. We need
to put the actors outside the system's boundaries.

Use-Case

With the help of the Ovals, we can draw the use-cases. With the verb we have to label the ovals in order to
represent the functions of the system.

Actors

Actors mean the system's users. If one system is the actor of the other system, then with the actor stereotype,
we have to tag the actor system.
Relationships

With the simple line we can represent relationships between an actor and use cases. For relationships between
use-case, we use arrows which are labeled either "extends" or "uses". The "extends" relationship shows the
alternative options under the specific use case. The "uses" relationship shows that single use-case is required
to accomplish a job.

Guidelines for Better Use-Cases

Generally, the use-case diagram contains use-cases, relationships, and actors. Systems and boundaries may
be included in the complex larger diagrams. We'll talk about the guidelines of the use-case diagram on the
basis of the objects.

Actors
• The actor's name should be meaningful and relevant to the business
• Place inheriting actors below the parent actor
• External Systems are actors

Use-Cases
The name of the use-case begins with a verb
The use-case models action, so the name of the use-case must start with a verb.
The name of the use-case must be descriptive
The use-case is created to provide more information to others who are looking at a diagram, such as instead
of "Print," "print Invoice is good.
Put the use-cases to the right of the included use-cases.
In order to add clarity and enhance readability, we have to place the included use-cases to the right of the
invoking use-cases.
Place inheriting use-case below the parent use-case
In order to enhance the diagram's readability, we have to place the inheriting use-case below the parent use-
case.

Systems/Packages
o Give descriptive and meaningful names to these objects.
o Use them carefully and only if needed.

Relationships
o When we are using <<extend>> arrow, points to the base use-case.
o When we are using <<include>> then arrow points to the comprised use-case.
o Actor and use-case relationship do not display arrows.
o <<extend>> may have an optional extension condition.
o <<include>> and <<extend>> both are shown as dashed arrows.
Sequence Diagrams

Sequence Diagram Notations –

1. Actors – An actor in a UML diagram represents a type of role where it interacts with the system and
its objects. It is important to note here that an actor is always outside the scope of the system we aim
to model using the UML diagram.

Figure – notation symbol for actorWe use actors to depict various roles including human users and
other external subjects. We represent an actor in a UML diagram using a stick person notation. We
can have multiple actors in a sequence diagram. For example – Here the user in seat reservation
system is shown as an actor where it exists outside the system and is not a part of the system.
 Figure – an actor interacting with a seat reservation system

2. Lifelines – A lifeline is a named element which depicts an individual participant in a sequence

diagram. So basically each instance in a sequence diagram is represented by a lifeline. Lifeline
elements are located at the top in a sequence diagram. The standard in UML for naming a lifeline
follows the following format – Instance Name : Class Name

Figure – lifelineWe display a lifeline in a rectangle called head with its name and type. The head is located
on top of a vertical dashed line (referred to as the stem) as shown above. If we want to model an unnamed
instance, we follow the same pattern except now the portion of lifeline’s name is left blank. Difference
between a lifeline and an actor – A lifeline always portrays an object internal to the system whereas actors
are used to depict objects external to the system. The following is an example of a sequence diagram:
 Figure – a sequence diagram

3. Messages – Communication between objects is depicted using messages. The messages appear in a
sequential order on the lifeline. We represent messages using arrows. Lifelines and messages form the
core of a sequence diagram. Messages can be broadly classified into the following categories :

Figure – a sequence diagram with different types of messages

Synchronous messages – A synchronous message waits for a reply before the interaction can move forward.
The sender waits until the receiver has completed the processing of the message. The caller continues only
when it knows that the receiver has processed the previous message i.e. it receives a reply message. A large
number of calls in object oriented programming are synchronous. We use a solid arrow head to represent a
synchronous message.
 Figure – a sequence diagram using a synchronous message

Asynchronous Messages – An asynchronous message does not wait for a reply from the receiver. The
interaction moves forward irrespective of the receiver processing the previous message or not. We use a

lined arrow head to represent an asynchronous message.

Create message – We use a Create message to instantiate a new object in the sequence diagram. There are
situations when a particular message call requires the creation of an object. It is represented with a dotted
arrow and create word labelled on it to specify that it is the create Message symbol. For example – The creation
of a new order on a e-commerce website would require a new object of Order class to be created.
 ➢ Figure – a situation where create message is used

Delete Message – We use a Delete Message to delete an object. When an object is deallocated memory or is
destroyed within the system we use the Delete Message symbol. It destroys the occurrence of the object in the
system.It is represented by an arrow terminating with a x. For example – In the scenario below when the order
is received by the user, the object of order class can be destroyed.

Figure – a scenario where delete message is used

Self Message – Certain scenarios might arise where the object needs to send a message to itself. Such
messages are called Self Messages and are represented with a U shaped arrow.
Figure – self messageFor example – Consider a scenario where the device wants to access its webcam. Such
a scenario is represented using a self message.

Figure – a scenario where a self message is used

Reply Message – Reply messages are used to show the message being sent from the receiver to the sender.
We represent a return/reply message using an open arrowhead with a dotted line.

The interaction moves forward only when a reply message is sent by the receiver.

Figure – reply messageFor example – Consider the scenario where the device requests a photo from the
user. Here the message which shows the photo being sent is a reply message.
Figure – a scenario where a reply message is used

Found Message – A Found message is used to represent a scenario where an unknown source sends the
message. It is represented using an arrow directed towards a lifeline from an end point. For example:
Consider the scenario of a hardware failure.

Figure – found messageIt can be due to multiple reasons and we are not certain as to what caused the
hardware failure.
 Figure – a scenario where found message is used

Lost Message – A Lost message is used to represent a scenario where the recipient is not known to the
system. It is represented using an arrow directed towards an end point from a lifeline. For example: Consider
a scenario where a warning is generated.

Figure – lost messageThe warning might be generated for the user or other software/object that the lifeline
is interacting with. Since the destination is not known before hand, we use the Lost Message symbol.
Figure – a scenario where lost message is used

4.Guards – To model conditions we use guards in UML. They are used when we need to restrict the flow of
messages on the pretext of a condition being met. Guards play an important role in letting software developers
know the constraints attached to a system or a particular process. For example: In order to be able to withdraw

cash, having a balance greater than zero is a condition that must be met as shown below.

Figure – sequence diagram using a guard

A sequence diagram for an emotion based music player –

 Figure – a sequence diagram for an emotion based music playerThe above sequence diagram depicts
the sequence diagram for an emotion based music player:

1. Firstly the application is opened by the user.

2. The device then gets access to the web cam.
3. The webcam captures the image of the user.
4. The device uses algorithms to detect the face and predict the mood.
5. It then requests database for dictionary of possible moods.
6. The mood is retrieved from the database.
7. The mood is displayed to the user.
8. The music is requested from the database.
9. The playlist is generated and finally shown to the user.

Uses of sequence diagrams –

• Used to model and visualise the logic behind a sophisticated function, operation or procedure.
• They are also used to show details of UML use case diagrams.
• Used to understand the detailed functionality of current or future systems.
• Visualise how messages and tasks move between objects or components in a system.
Activity Models

UML models basically three types of diagrams, namely, structure diagrams, interaction diagrams, and
behaviour diagrams. An activity diagram is a behavioural diagram i.e. it depicts the behaviour of a system.
An activity diagram portrays the control flow from a start point to a finish point showing the various decision
paths that exist while the activity is being executed.

We can depict both sequential processing and concurrent processing of activities using an activity diagram.
They are used in business and process modelling where their primary use is to depict the dynamic aspects of
a system. An activity diagram is very similar to a flowchart. So let us understand if an activity diagrams or
a flowcharts are any different :

Difference between an Activity diagram and a Flowchart –

Flowcharts were typically invented earlier than activity diagrams. Non-programmers use Flow charts to model
workflows. For example: A manufacturer uses a flow chart to explain and illustrate how a particular product
is manufactured. We can call a flowchart a primitive version of an activity diagram. Business processes where
decision making is involved is expressed using a flow chart. So, programmers use activity diagrams (advanced
version of a flowchart) to depict workflows.

An activity diagram is used by developers to understand the flow of programs on a high level. It also enables
them to figure out constraints and conditions that cause particular events. A flow chart converges into being
an activity diagram if complex decisions are being made. Brevity is the soul of wit. We need to convey a lot
of information with clarity and make sure it is short. So an activity diagram helps people on both sides i.e.
Businessmen and Developers to interact and understand systems.

A question arises: Do we need to use both the diagram and the textual documentation? Different
individuals have different preferences in which they understand something. For example: To understand a
concept, some people might prefer a written tutorial with images while others would prefer a video lecture.
So we generally use both the diagram and the textual documentation to make our system description as clear
as possible. We also need to be sensitive to the needs of the audience that we are catering to at times.

Difference between a Use case diagram and an Activity diagram An activity diagram is used to model the
workflow depicting conditions, constraints, sequential and concurrent activities. On the other hand, the
purpose of a Use Case is to just depict the functionality i.e. what the system does and not how it is done. So
in simple terms, an activity diagram shows ‘How’ while a Use case shows ‘What’ for a particular system. The
levels of abstraction also vary for both of them. An activity diagram can be used to illustrate a business process
(high level implementation) to a stand alone algorithm (ground level implementation). However, Use cases
have a low level of abstraction. They are used to show a high level of implementation only.

Figure – an activity diagram for an emotion based music player The above figure depicts an activity
diagram for an emotion based music player which can also be used to change the wallpaper. The various
components used in the diagram and the standard notations are explained below.

Activity Diagram Notations –

1. Initial State – The starting state before an activity takes place is depicted using the initial state.
Figure – notation for initial state or start state A process can have only one initial state unless we are depicting
nested activities. We use a black filled circle to depict the initial state of a system. For objects, this is the state
when they are instantiated. The Initial State from the UML Activity Diagram marks the entry point and the
initial Activity State. For example – Here the initial state is the state of the system before the application is
opened.

Figure – initial state symbol being used

2. Action or Activity State – An activity represents execution of an action on objects or by objects. We

represent an activity using a rectangle with rounded corners. Basically any action or event that takes
place is represented using an activity.

Figure – notation for an activity state For example – Consider the previous example of opening an
application opening the application is an activity state in the activity diagram.

Figure – activity state symbol being used

3. Action Flow or Control flows – Action flows or Control flows are also referred to as paths and
edges. They are used to show the transition from one activity state to another.

Figure – notation for control Flow An activity state can have multiple incoming and outgoing action flows.
We use a line with an arrow head to depict a Control Flow. If there is a constraint to be adhered to while
making the transition it is mentioned on the arrow. Consider the example – Here both the states transit into
one final state using action flow symbols i.e. arrows.
 Figure – using action flows for transitions

4. Decision node and Branching – When we need to make a decision before deciding the flow of
control, we use the decision node.

Figure – notation for decision node The outgoing arrows from the decision node can be labelled with
conditions or guard expressions.It always includes two or more output arrows.

Figure – an activity diagram using decision node

 5. Guards – A Guard refers to a statement written next to a decision node on an arrow sometimes

within square brackets.

Figure – guards being used next to a decision node The statement must be true for the control to shift
along a particular direction. Guards help us know the constraints and conditions which determine the
flow of a process.

6. Fork – Fork nodes are used to support concurrent activities.

Figure – fork notation When we use a fork node when both the activities get executed concurrently i.e. no
decision is made before splitting the activity into two parts. Both parts need to be executed in case of a fork
statement. We use a rounded solid rectangular bar to represent a Fork notation with incoming arrow from the
parent activity state and outgoing arrows towards the newly created activities. For example: In the example
below, the activity of making coffee can be split into two concurrent activities and hence we use the fork
notation.
 Figure – a diagram using fork

7. Join – Join nodes are used to support concurrent activities converging into one. For join notations we
have two or more incoming edges and one outgoing edge.

Figure – join notation For example – When both activities i.e. steaming the milk and adding coffee
get completed, we converge them into one final activity.

Figure – a diagram using join notation

8. Merge or Merge Event – Scenarios arise when activities which are not being executed concurrently
have to be merged. We use the merge notation for such scenarios. We can merge two or more activities
into one if the control proceeds onto the next activity irrespective of the path chosen.

Figure – merge notation For example – In the diagram below: we can’t have both sides executing
concurrently, but they finally merge into one. A number can’t be both odd and even at the same time.

Figure – an activity diagram using merge notation

9. Swimlanes – We use swimlanes for grouping related activities in one column. Swimlanes group
related activities into one column or one row. Swimlanes can be vertical and horizontal. Swimlanes
are used to add modularity to the activity diagram. It is not mandatory to use swimlanes. They usually
give more clarity to the activity diagram. It’s similar to creating a function in a program. It’s not
mandatory to do so, but, it is a recommended practice.
 Figure – swimlanes notation We use a rectangular column to represent a swimlane as shown in the figure
above. For example – Here different set of activities are executed based on if the number is odd or even. These
activities are grouped into a swimlane.

Figure – an activity diagram making use of swimlanes

10. Time Event –

Figure – time event notation We can have a scenario where an event takes some time to complete. We use
an hourglass to represent a time event. For example – Let us assume that the processing of an image takes
a lot of time. Then it can be represented as shown below.
 Figure – an activity diagram using time event

11. Final State or End State – The state which the system reaches when a particular process or activity
ends is known as a Final State or End State. We use a filled circle within a circle notation to represent
the final state in a state machine diagram. A system or a process can have multiple final states.

Figure – notation for final state

How to Draw an activity diagram –

1. Identify the initial state and the final states.

2. Identify the intermediate activities needed to reach the final state from he initial state.
3. Identify the conditions or constraints which cause the system to change control flow.
4. Draw the diagram with appropriate notations.
 Figure – an activity diagram The above diagram prints the number if it is odd otherwise it subtracts one
from the number and displays it.

Uses of an Activity Diagram –

• Dynamic modelling of the system or a process.

• Illustrate the various steps involved in a UML use case.
• Model software elements like methods,operations and functions.
• We can use Activity diagrams to depict concurrent activities easily.