Learning Resource

On

Software Engineering

Chapter-7
Software Design: Object Oriented Design using
UML

Prepared By:
Kunal Anand, Asst. Professor
SoCE, KIIT, DU, Bhubaneswar-24
Chapter Outcomes:
After completing this chapter successfully, the students
will be able to:
– Define Information Modeling
– Explain Entity Relationship Diagram (ERD)
– Identify the purpose of object-oriented design.
– Discuss several object-oriented concepts.
– List different views under UML diagrams.
– Explain several types of UML diagrams
– Draw UML diagrams for a given problem
statement.

2
Organization of the Chapter

• Information Modeling in Software Engineering

• Entity Relationship Diagram
• Introduction to Object Oriented Design
• Overview of Object-Oriented Concepts
• Unified Modeling Language (UML)
• UML Diagrams
• Examples
• Summary

3
Information Modeling in Software Engineering
• Information modeling in software engineering is a method for
managing information exchanges and representing concepts
in a domain of discourse.
• It's a type of structural modeling that focuses on data and
information flow inside an organization and software
solution.
• Information models can help specify data entities by defining
relationships, constraints, rules, and operations between
different types of things, or even individual things.
• Information models can provide more context and formalism
regarding the informational aspects of the software domain
being modeled.
• Information models can help elaborate conceptual
information models into logical and physical data models.
4
Entity Relationship Diagram (ERD)
• ERD use the concepts like entity, attributes, relationship, and
constraints. They are also known as the building blocks of a
data model.
– Entity: An entity represents a real-world concept that can
be described in the database.
– Attribute: property or feature or characteristic that may
further describe an entity.
– Relationship: When there are two or more than two
entities in a database, they are associated to each other in
one way or another. This association is known as
relationship.
– Constraint: A constraint is a restriction placed on a data.
They are important as they help to achieve data integrity
i.e., an assurance of the accuracy and consistency of, data
5
over its entire life-cycle
contd..
• Entity Type
– It is a basic object represented in a ER model.
– An entity type represents any real world object that can be
represented in a database.
• Attributes
– Each entity type can be described into a database with the
help of some features or properties or characteristics known
as attributes.
• For example: EMPLOYEE is an entity type with
attributes like employee's name, Emp_ID, SSN, address,
gender, salary, and DOB.
– A particular entity in an entity type will have value for each
of its attributes.
6
contd..
• In ER Model, following types of attributes exist:
– Simple versus Composite: Attributes that can't be
sub-divided further are known as simple attribute, whereas
the composite attributes can be sub-divided further.
• Ex: “SSN” attribute can't be sub-divided further
whereas “Address” attribute of EMPLOYEE can be
divided further into Street_address, City, State, and PIN.
– Single-valued versus Multi-valued: Attribute which have
single value for a particular entity is known as
single-valued attribute, whereas attribute which may have a
set of values for the same entity is known as multi-valued
attribute.
• Ex: “Age” is a single-valued attribute whereas “Mobile
Number” is a multi-valued attribute.
7
contd..
• Stored versus Derived: Attribute for which the values are
directly stored, is known as stored attribute. Similarly, there
are attributes for which direct values can not be stored, rather
the values are derived from the stored attributes. They are
known as derived attributes.
– For ex: “DOB” is the attribute that will be stored directly
for an employee. On the other hand, “Age” is a derived
attribute as it will be derived from the DOB attribute.
• NULL Values:
• In some cases, a particular entity may not have any
applicable value for an attribute. In this situation, a special
value NULL is created. It can also be used when the value
of an attribute is unknown.

8
contd..
» “Degree” is an attribute that only applies to those employee
who has a degree. There may be employees without a degree.
In this case, NULL value will be stored for them against the
attribute “Degree”.
• Entity Type
– It is a collection of entities that have the same attributes.
However, each entity has its own value for each attribute.
– In a database, each entity type is represented by its name and
attributes.
– Ex: EMPLOYEE is an entity type with attributes Emp_ID,
Name, Age, Salary, etc.
• Entity Set
– The collection of all entities of a particular entity type in the
database at any point of time is referred to as entity set.
– Entity set is also referred by the same name as the entity type.9
contd..
• Entity type and entity set are
represented here.

• An entity type is represented

in ER diagram as a
“Rectangular Box” enclosing
the entity type name.

• Attributes are enclosed in

ovals and are attached to their
entity with straight lines.

10
 contd..
• Composite attributes are
connected to their
components by straight
lines.
• Multi-valued attributes
are displayed using double
oval.
• Derived attribute is
represented as dashed oval.
• A STUDENT entity type is
shown here along with its
attributes.

11
Key Attribute of an Entity Type
• An entity type usually have one or more attributes whose
values are distinct for each individual entity in the entity set.
Such attribute is known as Key Attribute.
• Key attributes can be used to identify each entity uniquely.
– For example: Consider an entity type CAR with attributes
like Model, Make, Color, Year, Reg., Vehicle_ID. Here,
Reg., and Vehicle_ID can be the key attribute.
• Key attribute for two individual entities from an entity set
can’t have same value as key attribute uniquely identifies each
entity.
• In ER diagram, each key attribute has its name underlined
inside the oval.

12
Value Set or Domain of an Attribute
• Each simple attribute of an entity type is associated with a
value set that specifies the set of values which may be assigned
to that attribute for each individual entity.
• For ex:
– Age attribute of an entity type EMPLOYEE may have the
range between 21 to 65. Hence, the value set here is 21 to 65
for the attribute Age.
– Similarly, DOJ or DOB is an attribute where the values will
be given from a pre-defined set like {Day, Month, Year}.
Hence, the value set can be {(1-31),(1-12),(1950-2020)}.
• Value set is not displayed in the ER diagram and are typically
specified using the basic data type available in most
programming language.
13
Relationship Types, Relationship Sets, Roles, and
Structural Constraints
• Multiple entity types are associated to each other in some form
of relationship. This association is known as relationship
type. The relationship name is a verb.

• A relationship set is a set of relationship instances of the same

type. Relationship sets are represented by diamonds and are
connected to the participant entity sets.

14
contd..
• A relationship type R among
n entity types e1, e2,
e3,....,en defines a set of
relationship set among
entities.
– For ex: EMPLOYEE
works for
DEPARTMENT; here,
the entity type
EMPLOYEE is
associated with the entity
type DEPARTMENT and
the relationship type is
“Works for”.
15
contd..

• Each relationship instance ri is connected to the EMPLOYEE

and DEPARTMENT entity types.
• The employees e1,e3, and e6 work for department d1; the
employees e2 and e4 works for department d2; and the
employees e5 and e7 work for department d3.
• The degree of a relationship type is the number of entity types
that participate in a relationship. For example: The degree of
“Works for” relationship type is 2.
• A relationship type of degree 2 is called binary relationship
whereas, the relationship type of degree 3 is known as ternary
relationship.

16
contd..
• Each entity type participating in a relationship type plays a
role in that relationship.
– For ex: In works for relationship EMPLOYEE plays the
role of worker and DEPARTMENT plays the role of
employer.
• Recursive Relationship: Role names are significant where the
same entity type participates more than once in a relationship,
but in different roles. Such relationship types are known as
recursive relationship or self referencing relationship.
– For ex: each employee has a supervisor which is again an
employee i.e. The EMPLOYEE entity type is associated to
this “supervises” relationship in two roles, one as a
supervisor and another as Subordinate.
17
Constraints in Relationship
• Mapping Constraint or Cardinality: The number of times an
entity of an entity set participates in a relationship set is known
as cardinality. Cardinality can be of different types:
– One to One (1:1): When each entity in each entity set can
take part only once in the relationship, the cardinality is one
to one.

18
contd..
• Many to one (M:1) When entities in one entity set can take
part only once in the relationship set and entities in other entity
set can take part more than once in the relationship set,
cardinality is many to one.
– Let us assume that a student can take only one course, but one
course can be taken by many students. So, the cardinality will be
M: 1.

19
contd..
• Many to many (M:N) – When entities in all entity sets can
take part more than once in the relationship cardinality is many
to many.
– Let us assume that a student can take more than one course and one
course can be taken by many students. So, the relationship will be
many to many (M:N).

20
contd..
• One to Many (1:M)- An entity in A is associated with any
number (zero or more) of entities in B; an entity in B,
however, is associated with no more than 1 entity of A.
– For example: A customer can have multiple loans.
However, a loan can only have one customer. Hence, its a
1:M relationship.

21
Participation Constraints
• Participation Constraint is applied on the entity participating in
the relationship set.
• Total Participation: Each entity in the entity set must
participate in the relationship. If each student must enroll in a
course, the participation of student will be total. Total
participation is shown by “double line” in ER diagram.
• Partial Participation: The entity in the entity set may or may
not participate in the relationship. If some courses are not
enrolled by any of the student, the participation of course will
be partial. It is shown by “single line”.
– The diagram depicts the ‘Enrolled in’ relationship set with
STUDENT Entity set having total participation and
COURSE Entity set having partial participation.

22
contd..

23
Strong and Weak Entity Type
• An entity type that has its own KEY attribute, is known as
strong entity type.
– Ex: In COMPANY database, the entity types EMPLOYEE,
DEPARTMENT, and PROJECT are strong as they do have
their own key attribute.
• On the other hand, Weak entity type does not have their own
KEY attribute.
– Ex: In COMPANY database, the DEPENDENT entity type
is a weak entity type as it does not have a key attribute of its
own. It has a partial key which may be used to uniquely
identify the weak entity that are related to the same owner
entity.
• In ER diagram, strong entity type is represented using a single
line rectangle, whereas weak entity type is represented using
double line rectangle. 24
contd..
• For a weak entity set to be meaningful, it must be associated
with another strong entity set called identifying or owner
entity set.

• The relationship associating the weak entity set with the

identifying entity set is called the identifying relationship.

• The identifying relationship is usually many-to-one and the

participation of the weak entity set in the relationship is total
participation.
– Ex: DEPENDENT entity type is related to the
EMPLOYEE entity type using M:1 relationship type and
the participation of the weak entity set is total.
25
Sample Application
• A database application, called COMPANY, keeps track of its
EMPLOYEEs, DEPARTMENTs, and PROJECTs.

• After the requirement collection and analysis phase, the

designers produced the following description of the database
COMPANY.
– The company is organized into departments. Each
department has a unique name, a unique number, and an
employee that manages the department.
– A department controls several projects, each of which has a
unique name, unique number, and a location.
– The database stores each Employee Name, Employee ID,
SSN, age, address, gender, salary, DOB, and supervisor.
26
contd..

– An employee is assigned to one department, but may work

on multiple projects, which are not necessarily controlled
by the same department.

– The database also keeps the track of current number of

hours per week that an employee works on each project,
along with the direct supervisor of each employee.

– The database also records the dependents of each employee

for insurance purpose, including each dependent's first
name, gender, DOB, and relationship to the employee.

27
Initial Conceptual Design of COMPANY database
• Based on the requirements discussed in our sample problem,
following entity types can be defined along with their
attributes.
• EMPLOYEE (Entity Type)
– Attribute: Emp_name, Emp_ID, SSN, age, address,
gender, salary, DOB, and supervisor
• DEPARTMENT (Entity Type)
– Attribute: Name, Number, and Manager
• PROJECT (Entity Type)
– Attribute: Name, Number, Location, and Controlling_dept
• DEPENDENT (Entity Type)
– Attribute: Name, gender, DOB, Employee details, and Relationship
with the employee

28
Refined Conceptual Design for COMPANY database
• Now, the refined ER design for the COMPANY database is
below:
– MANAGES:
• Cardinality: 1:1
• Entity types: EMPLOYEE and DEPARTMENT
• Participation: EMPLOYEE (Partial); DEPARTMENT (Total)
– WORKS_FOR:
• Cardinality: N:1
• Entity types: EMPLOYEE and DEPARTMENT
• Participation: EMPLOYEE (Total); DEPARTMENT (Total)
– CONTROLS:
• Cardinality: 1:N
• Entity types: DEPARTMENT and PROJECT
• Participation: DEPARTMENT (Partial); PROJECT (Total)
29
contd..
– SUPERVISION:
• Cardinality: 1:N
• Entity types: EMPLOYEE
• Participation: EMPLOYEE (Partial);
– WORKS_ON:
• Cardinality: M:N
• Entity types: EMPLOYEE and PROJECT
• Participation: EMPLOYEE (Total); PROJECT (Total)
– DEPENDENTS_OF:
• Cardinality: 1:N
• Entity types: EMPLOYEE and DEPENDENT
• Participation: EMPLOYEE (Partial); DEPENDENT (Total)

30
Entity Relationship Diagram

31
Introduction to Object Oriented Design
• Object Oriented Design (OOD) is another popular design
approach followed in software development process.

• In OOD, the entire system is viewed as a collection of objects.

• All possible objects are identified in the proposed system.

• Further, data and possible operations, are identified for each

object along with the relationship among the objects.

• The modeling of the object-oriented system is based on a

special type of language, known as UML.

32
Overview of Object-Oriented Concepts
• In object-oriented concepts, following key concepts are used:
– Object
– Class
– Message and methods
– Abstraction
– Encapsulation
– Inheritance
– Polymorphism
– Message binding
– Genericity

33
Object Oriented Concepts (contd..)
• Object:
– Any real-world entity can be considered as an object.

– Each object consists of some data and a set of operations,

referred to as methods, that can be applied on that object.

– An object can access only its own data using its methods.
However, it can interact with other objects in order to
perform some task.

– It is easy to understand when the system is analyzed,

developed and implemented in terms of natural objects.
34
Object Oriented Concepts (contd..)
• Class:
– Class is a collection of similar kind of objects. i.e., objects
with similar properties and behavior represents a class.
– In actual, objects exist whereas class is just a theoretical
concept.
– In a library management system, one of the objects is
“Library member”.
• For the object “library member”, the data can be
member_name, member_id, address, phone_no,
date_of_join etc.
• Similarly, the methods can be issue_book,
find_book_outstanding, find_book_overdue, ret_book
etc.
35
Object Oriented Concepts (contd..)
• Methods and Messages: Operations supported by an object,
are called methods.
– The methods of an object are invoked by sending message
to it.
– The set of messages to an object constitutes its protocol.

• Inheritance: This feature allows to define a new class

(derived class) by extending or modifying an existing class
(base class).
– The inheritance can be viewed as
“generalization-specialization” relationship.
– The derived class inherits the properties from its base class.
Additionally, it also has its own properties.
36
Inheritance

• Inheritance is a must for any object-oriented language. It

encourages code reuse.

37
Object Oriented Concepts (contd..)
• Abstract class:
– The class, for which objects can not be created, is known as abstract
class.
– They serve as a skeleton structure based on which other classes can
be derived and used.
• Abstraction:
– It is a mechanism that allows us to focus on a certain portion by
omitting the irrelevant details.
– It allows the developers to understand the problem better.
– It reduces the complexity of the software that ultimately increases
software productivity.
• Encapsulation:
– This property allows the object to interact with the outer world only
through messages. The outer world don’t have any idea about “how
the objects are implemented”.
38
Object Oriented Concepts (contd..)
• Polymorphism:
– It allows the objects to use the same message at different
times to perform different operations, as per the
requirement.
– Here, multiple operations are defined using same name. It
adds the advantage of code reuse.
– Dynamic binding allows to add new derived objects to the
existing objects, with minimal changes.

• Composite Objects:
– Objects that contain other objects are called composite
objects. They can be used to realize complex behavior.

39
Related terms
• Persistent objects:
– The permanently stored objects are known as persistent objects.
They live across different execution.
– It can be done by keeping a copy of object in secondary storage.
• Agents:
– They are known as active objects.
– They monitor events occurring in the application and act
autonomously.
– They are used in applications like monitoring exceptions.
• Widget:
– Widget stands for “window object”. It is a primitive object used in
UML.
– It maintains internal data. The methods supported by a widget
manipulate the stored data and carry out operations.

40
Advantages of OOD
• Code and design reuse
• Increased productivity
• Ease of testing and maintenance
• Better understandability
• Cost effective
– A functioning and well-established object-oriented
methodology and environment is likely to be managed with
20-50% of the cost of the traditional development.

41
Unified Modeling Language
• Unified Modeling Language, UML, provides a set of notations
to create models of a system.

• These models are useful in documenting the design and result

analysis.

• UML is a graphical representation of a real time system using

different diagrams, known as UML diagrams.

• UML was developed to standardize the large number of object

-oriented modeling notations that existed and were extensively
used in early 90s.

42
UML Diagrams
• UML diagrams can capture following five views of a system:
– User's view:
• This view defines the functionalities made available by
the system to its users.
• It captures the external view of a system i.e., how a
user sees the system from outside.
• The user's view is considered as “black box” view
where the users don’t have any idea about “how the
system is working”. They can only use the system
without knowing its internal structure.
• The diagram under user's view is known as use case
diagram.

43
UML Diagrams (contd..)
• Structural View:
– It defines the objects that are important to the
understanding of the working of a system, and its
implementation.
– It also captures the relationship among the objects.
– Diagrams: object diagram, class diagram

• Behavioral View:
– It captures the interactions among the objects to realize the
overall system behavior.
– Diagrams: sequence diagram, activity diagram, state-chart
diagram, collaboration diagram

44
UML Diagrams (contd..)

• Implementation view:
– This view captures the important components and their
dependencies.
– Diagram: Component diagram

• Environmental view:
– This view models how the different components of the
system are implemented on a different piece of hardware.
– Diagram: Deployment diagram

45
Use Case Diagram
• In UML, a use case diagram can summarize the details of the
system's users (also known as actors).
• Use case diagrams are ideal for:
– Representing the goals of system-user interactions
– Defining and organizing functional requirements in a
system
– Specifying the context and requirements of a system
– Modeling the basic flow of events in a use case
• An effective use case diagram can help your team discuss and
represent scenarios in which the system or application interacts
with people, organizations, or external systems

46
Use Case Diagram (contd..)
• A use case diagram, usually have following components:
– Actors: Stick figures that represent the people employing
the use cases.

– Use cases: Horizontally shaped ovals that represent the

different uses that a user might have.

– Relationships: To represent the relationships between an

actor and use case, or between two use cases. A line or
arrow is used to represent the relationships.

– System boundary boxes: A box that sets a system scope to

use cases. All use cases outside the box would be
considered outside the scope of that system.
47
Relationship in Use Case Diagram
• There can be following relationship types in a use case
diagram.
– Association between actors and use cases
– Extend between two use cases
– Include between two use cases
– Generalization of a use case
• Association Between Actor and Use Case
– This one is straightforward and present in every use case
diagram. A line is used to represent association.
– An actor must be associated with at least one-use case.
– An actor can be associated with multiple use cases.
– Multiple actors can be associated with a single use case.
48
Association Between Actor and Use Case

49
Generalization
• In generalization relationship, the behavior of the ancestor is
inherited by the descendant.
• This is used when there is common behavior between two use
cases and specialized behavior specific to each use case.
• For example, there might be a generalized use case called
“Pay Bills”. This can be extended to specific use cases like
“Pay by Card”, “Pay by Net banking”, “Pay by UPI” etc.

Pay Bill Pay by UPI

Pay by Pay by net Pay by

card banking wallet

50
Include Relationship
• Include relationship shows that the behavior of the included
use case, is part of the including (base) use case.
• Include relationship is shown as a dashed line with an open
arrowhead directed towards the included use case. The arrow
is labeled with the keyword «include».
• The base use case is incomplete without the included use case
i.e., included use case is mandatory and not optional.

51
Extend Relationship
• The extend relationship allows to show the optional system
behavior.
• Extend relationship is shown as a dashed line with an open
arrowhead directed from the extending use case to the
extended (base) use case. The arrow is labeled with the
keyword «extend».
• The extend use case can add additional behavior only at an
extension point when certain conditions are satisfied.
• Registration use case is complete and meaningful on its own.
HOwever, it could be extended with optional “Get Help On
Registration” use case.

52
Use Case Diagram: Sample Example
• Problem Title: ATM Application: In general, the interaction
between a user and bank ATM machine happens as below:
– A user logs into the system. This login is authenticated by the
bank administration. The login may result in either successful
login or FAILED login. In case of successful login, the user is
navigated to the TRANSACTION option. However, The user
gets the INCORRECT PIN message and prompted to enter the
correct PIN, in case of FAILED login.
– User is offered with different options available under
TRANSACTION. These options include BALANCE CHECK,
WITHDRAWL, DEPOSIT, FUNDS TRANSFER and other
services. All these options can be performed by the user but only
one at a time. The bank administration authenticates these
transactions option.
– The ATM system is maintained by an IT team which mainly
includes SYSTEM MAINTENANCE and REPORT
GENERATION work. 53
Solution
• Actors: USER, BANK and IT Team

• Use Cases: Login, Transaction, Bad PIN, Balance,

Withdrawal, Deposit, Fund transfer, Other services,
Maintenance, System Maintenance and Report generation.

• Relationships:
– Actors USER and BANK is associated to LOGIN
– BANK is also associated to Transaction.
– Transaction includes BALANCE CHECK, WITHDRAWL,
DEPOSIT, FUNDS TRANSFER and other services.
– Actor IT team is associated to Maintenance which includes
SYSTEM MAINTENANCE (SM) and REPORT
GENERATION (RG).
54
Use Case Diagram for ATM Application

55
Class Diagram
• Class diagram is a graphical representation of the static view
of the system and represents different aspects of the
application.

• A collection of class diagrams represent the whole system.

• The purpose of the class diagram can be summarized as:

– Analysis and design of the static view of an application.
– Describe responsibilities of a system.
– Base for component and deployment diagrams.
– Forward and reverse engineering.

56
Class Diagram
• The following points should be remembered while drawing a
class diagram:
– The name of the class diagram should be meaningful to
describe the aspect of the system.
– Each element and their relationships should be identified in
advance.
– Responsibility (attributes and methods) of each class
should be clearly identified
– For each class, minimum number of properties should be
specified, as unnecessary properties will make the diagram
complicated.
– Use “notes” whenever required to describe some aspect of
the diagram. At the end of the drawing, it should be
understandable to the developer/coder.
57
An Example: Loan_Account
• In the example, a class called “loan_account” is depicted.
Classes in class diagrams are represented by boxes that are
partitioned into three:
– The top partition contains the name of the class.
– The middle part contains the class’s attributes.
– The bottom partition shows the possible operations that are
associated with the class.

58
Relationship in Class Diagram
• In a class diagrams, the classes are interrelated to each other in
following relationships:
– Association: Any logical connection between two classes.

– Directed Association refers to a directional relationship represented by

a line with an arrowhead. The arrowhead depicts a container-contained
directional flow, along with cardinality.

59
contd..
• Aggregation:
– Aggregation is a special type of association where the
involved classes support “whole-part” relationship
between them.
– It is a weak type of association.
– Here, the contained class is not strongly dependent on the
container class.
– Aggregation is represented by an empty diamond symbol at
the aggregate end of a relationship.

60
contd..
• Composition:
– It is also a whole/part relationship. It is a stricter form of aggregation,
in which the “part” is existence dependent on “whole”.
– In composition, there is a strong relationship between the container
and contained classes. The contained class will lose its significance if
the container class is deleted.
– Composition relationship is denoted using a straight line with a filled
diamond drawn at the composite end.

• Aggregation vs Composition:
– If components can be added to or removed from the aggregate, then
the relationship is aggregation. On the other hand, if the
components are not required to be added/deleted dynamically, then
the relationship is composition.
61
contd..
• Inheritance:
– It refers to a type of
relationship wherein one
associated class is a child of
another by virtue of assuming
the same functionalities of
the parent class.
– In other words, the child class
is a specific type of the parent
class.
– To show inheritance in a
UML diagram, a solid line
from the child class to the
parent class is drawn using an
unfilled arrowhead.

62
Class Diagram for ATM Application
• Problem Description: An ATM application can be described as below:
– A Bank, with a branch code and location, maintains and manages
various customers and ATMs.
– A Customer has to provide basic personal information like name, date
of birth and address to their bank. The customers can have one or more
accounts in the bank. The bank issues debit card to each of its
customers. A customer can perform one or many transaction using the
debit card by visiting the bank ATM.
– An Account can be either Savings or PPF account with the details like
account number, account balance and it supports two functions named
as deposit and withdraw. Additionally, PPF account also has a maturity
date.
– The ATMs are assigned with unique ID and are situated at different
locations. The ATM is managed by the bank. ATM identifies customers
and performs the transactions opted by them.
– Every Transaction has unique transaction ID, date of transaction, type
of transaction, amount and balance after transaction. The ATM
transaction updates the customer account after successful completion of
63
the transaction.
contd..

64
Object Diagram
• A class diagram represents an abstract model consisting of
classes and their relationship.
• An object diagram shows a snapshot/instance of the objects in
a system at a point in time. It is also known as instance
diagram.
• It captures the static view of a system at a particular moment.
• The purpose of the object diagram can be summarized as:
– Forward and reverse engineering.
– Object relationships of a system
– Static view of an interaction.
– Understand object behavior and their relationship from
practical perspective

65
Notations used in Object Diagram
• Object Notation:
– The object we create represents an entity which exists in the system.
– We can represent the changes in object over time by creating
multiple instance specifications.
– We use a rectangle to represent an object in an Object Diagram. An
object is generally linked to other objects in an object diagram.

66
contd..
• Links – We use a link to represent a relationship between two
objects.

• Dependency Relationships – We use a dependency

relationship to show when one element depends on another
element.

• Association
• Aggregation
• Composition

67
Object Diagram
• To capture a particular system, numbers of class diagrams are
limited. However, if we consider object diagrams then we can
have unlimited number of instances, which are unique in
nature. Only those instances are considered, which have an
impact on the system.
• From the above discussion, it is clear that a single object
diagram cannot capture all the necessary instances or rather
cannot specify all the objects of a system. Hence, the solution
is:
– First, analyze the system and decide which instances have
important data and association.
– Second, consider only those instances, which will cover the
functionality.
– Third, make some optimization as the number of instances
are unlimited. 68
Object Diagram
• The following things are to be decided before starting the
construction of the diagram:
– The object diagram should have a meaningful name to
indicate its purpose.
– The most important elements are to be identified.
– The association among objects should be clarified.
– Values of different elements need to be captured to include
in the object diagram.

69
Sample Example

70
Activity Diagram
• Activity diagram is another important diagram in UML to
describe the dynamic aspects of the system.
• Activity diagram is basically a flowchart to represent the flow
from one activity to another activity.
• The control flow is drawn from one operation to another. This
flow can be sequential, branched, or concurrent.
• Activity diagrams deal with all type of flow control by using
different elements such as fork, join, etc.
• The purpose of an activity diagram can be described as:
– Draw the activity flow of a system.
– Describe the sequence from one activity to another.
– Describe the parallel, branched and concurrent flow of the
system.
71
Activity Diagram
• Activity diagrams are not exactly flowcharts as they have
some additional capabilities. These additional capabilities
include branching, parallel flow, swim lane, etc.
• The main element of an activity diagram is the activity itself.
• An activity is a function performed by the system. After
identifying the activities, we need to understand how they are
associated with constraints and conditions.
• Before drawing an activity diagram, we should identify the
following elements:
– Activities
– Association
– Conditions
– Swim lanes
72
Sample Example: Withdrawal from ATM

73
State-chart Diagram
• A State-chart diagram describes a state machine that defines
different states of an object that can be controlled by external
or internal events.
• State-chart diagram describes the flow of control from one
state to another state.
• States are defined as a condition in which an object exists and
it changes when some event is triggered.
• The most important purpose of State-chart diagram is to model
lifetime of an object from creation to termination.
• Following are the main purposes of using State-chart diagrams
– To model the dynamic aspect of a system.
– To model the life time of a reactive system.
– To describe different states of an object during its life time.
– Define a state machine to model the states of an object.
74
Example: Withdrawal from ATM

75
Interaction Diagrams
• This interactive behavior is represented in UML by two
diagrams known as Sequence diagram and Collaboration
diagram.

• Sequence diagram emphasizes on time sequence of messages

and collaboration diagram emphasizes on the structural
organization of the objects that send and receive messages.

• Sequence and collaboration diagrams are used to capture the

dynamic nature but from a different angle.

76
Interaction Diagrams
• The purpose of interaction diagram is:
– To describe the message flow in the system.
– To describe the structural organization of the objects.
– To describe the interaction among objects.

• Following things are to be identified clearly before drawing

the interaction diagram:
– Objects taking part in the interaction.
– Message flows among the objects.
– The sequence in which the messages are flowing.
– Object organization.

77
Sequence Diagram

78
Collaboration Diagram
• In the collaboration diagram, the method call sequence is
indicated by some numbering technique.

• Method calls are similar to that of a sequence diagram. The

number indicates how the methods are called one after
another.

• To choose between these two diagrams, emphasis is placed on

the type of requirement.
– If the time sequence is important, then the sequence
diagram is used.
– If organization is required, then collaboration diagram is
used.
79
Collaboration Diagram

80
Component Diagram
• Component diagram is a special kind of diagram in UML. It
does not describe the functionality of the system but it
describes the components used to make those functionalities.
• Component diagrams can also be described as a static
implementation view of a system. Static implementation
represents the organization of the components at a particular
moment.
• They are used:
– to model the physical aspects of a system; such as
executables, libraries, files, documents, etc. which reside in
a node.
– to visualize the organization and relationships among
components in a system. These diagrams are also used to
make executable systems.
81
Component Diagram
• Before drawing a component diagram, the following artifacts
are to be identified clearly:
– Files used in the system.
– Libraries and other artifacts relevant to the application.
– Relationships among the artifacts.

• After identifying the artifacts, the following points need to be

kept in mind.
– Use a meaningful name to identify the component for
which the diagram is to be drawn.
– Prepare a mental layout before producing the using tools.
– Use notes for clarifying important points.

82
Component Diagram

83
Deployment Diagram
• Deployment diagrams are used to describe the static
deployment view of a system. Deployment diagrams consist
of nodes and their relationships.

• Deployment diagrams are used to visualize the topology of the

physical components of a system, where the software
components are deployed.

• An efficient deployment diagram is very important as it

controls the parameters like performance, scalability,
maintainability, portability.

• Component diagrams and deployment diagrams are closely

related.
84
Deployment Diagram

85