OBJECT-ORIENTED ANALYSIS AND

DESIGN (CSC 302)

2017/2018 SESSION
 WHAT IS UML?
 UML is a standard language for specifying, visualizing,
constructing, and documenting the artifacts of software systems.
 It stands for Unified Modeling Language.
 It is different from the other common programming languages
such as C++, Java, COBOL, etc.
 It is a pictorial language used to make software blueprints.
 It can be described as a general purpose visual modeling language
to visualize, specify, construct, and document software system.
 Although UML is generally used to model software systems, it is
not limited within this boundary. It is also used to model non-
software systems as well. For example, the process flow in a
manufacturing unit, etc.
 UML is not a programming language but tools can be used to
generate code in various languages using UML diagrams. UML has
a direct relation with object oriented analysis and design. After
some standardization, UML has become an OMG standard.
 A Conceptual Model of UML
 A conceptual model can be defined as a model
which is made of concepts and their relationships.
 It is the first step before drawing a UML diagram. It
helps to understand the entities in the real world
and how they interact with each other.
 As UML describes the real-time systems, it is very
important to make a conceptual model and then
proceed gradually.
 The conceptual model of UML can be mastered by
learning the following three major elements −
• UML building blocks
• Rules to connect the building blocks
• Common mechanisms of UML
UML building blocks
The building blocks of UML can be defined as :
Things
Relationships
Diagrams

THINGS
Things are the most important building blocks of
UML. Things can be:
 Structural
 Behavioural
 Grouping
 Annotational
Structural things define the static part of the
model. They represent the physical and
conceptual elements. Following are the brief
descriptions of the structural things.
i. Class − It represents a set of objects having
similar responsibilities.

ii. Interface − It defines a set of operations, which

specify the responsibility of a class.

iii. Collaboration −It defines an interaction

between elements.
iv. Use case − It represents a set of actions
performed by a system for a specific goal.

v. Component − It describes the physical part of a

system.

vi. Node − It can be defined as a physical element

that exists at run time.
A behavioural thing consists of the dynamic parts
of UML models. Following are the behavioural
things:
i. Interaction − It is defined as a behaviour that
consists of a group of messages exchanged
among elements to accomplish a specific task.

ii. State machine − It is useful when the state of

an object in its life cycle is important. It defines
the sequence of states an object goes through
in response to events. Events are external
factors responsible for state change
Grouping things can be defined as a mechanism to
group elements of a UML model together. There is
only one grouping thing available:
i. Package − Package is the only one grouping
thing available for gathering structural and
behavioural things.

Annotational things can be defined as a

mechanism to capture remarks, descriptions, and
comments of UML model elements. Note - It is the
only Annotational thing available. A note is used
to render comments, constraints, etc. of an UML
element.
 RELATIONSHIP
It shows how the elements are associated with
each other and this association describes the
functionality of an application.
There are four kinds of relationships available.
i. Dependency is a relationship between two
things in which change in one element also
affects the other.
ii. Association is basically a set of links that
connects the elements of a UML model. It also
describes how many objects are taking part in
that relationship.
iii. Generalization can be defined as a relationship
which connects a specialized element with a
generalized element. It basically describes the
inheritance relationship in the world of
objects.

iv. Realization can be defined as a relationship in

which two elements are connected. One
element describes some responsibility, which
is not implemented and the other one
implements them. This relationship exists in
case of interfaces.
 UML Diagrams
 They are the ultimate output of the entire
discussion. All the elements, relationships are
used to make a complete UML diagram and the
diagram represents a system.
 UML includes the following nine diagrams, the
details of which are described subsequently.
i. Class diagram vi. Activity diagram
ii. Object diagram vii. Statechart diagram
iii. Use case diagram viii.Deployment
iv. Sequence diagram diagram
v. Collaboration diagram ix. Component diagram
Any real-world system is used by different
users. The users can be developers,
testers, business people, analysts, and
many more. Hence, before designing a
system, the architecture is made with
different perspectives in mind. The most
important part is to visualize the system
from the perspective of different viewers.
The better we understand the better we
can build the system.
UML plays an important role in defining different
perspectives of a system. These perspectives are:
i. Design
ii. Implementation
iii. Process
iv. Deployment
The centre is the Use Case view which connects all
these four.
A Use Case represents the functionality of the
system. Hence, other perspectives are connected
with use case.
Design of a system consists of classes, interfaces, 
and collaboration. UML provides class diagram, 
object diagram to support this.
Implementation defines the components 
assembled together to make a complete physical 
system. UML component diagram is used to 
support the implementation perspective.
Process defines the flow of the system. Hence, the 
same elements as used in Design are also used to 
support this perspective.
Deployment represents the physical nodes of the 
system that forms the hardware. UML deployment 
diagram is used to support this perspective.
 UML - Modelling Types
There are three important types of UML
modelling. Different diagrams are used for
different types
i. Structural modelling captures the static
features of a system. They consist of the
following:
 Classes diagrams
 Objects diagrams
 Deployment diagrams
 Package diagrams
 Composite structure diagram
 Component diagram
ii. Behavioural Modelling: It describes the
interaction in the system. It represents the
interaction among the structural diagrams. It
shows the dynamic nature of the system. They
consist of the following:
 Activity diagrams
 Interaction diagrams
 Use case diagrams
All the above show the dynamic sequence of flow
in a system.
iii. Architectural Modelling: It represents the
overall framework of the system. It contains
both structural and behavioural elements of
the system. It can be defined as the blueprint
of the entire system. Package diagram comes
under architectural modelling.
UML - Basic Notations
Class Notation
UML class is represented by the following figure.
The diagram is divided into four parts.
The top section is used to name the class.
The second one is used to show the attributes of
the class.
The third section is used to describe the
operations performed by the class.
The fourth section is optional to show any
additional components.

Classes are used to represent objects. Objects can

be anything having properties and responsibility.
Object Notation
The object is represented in the same way as the
class. The only difference is the name which is
underlined as shown in the following figure.

As the object is an actual implementation of a

class, which is known as the instance of a class.
Hence, it has the same usage as the class.
Interface Notation
Interface is represented by a circle
as shown in the following figure.
It has a name which is generally
written below the circle. It is used
to describe the functionality
without implementation. It is just
like a template where you define
different functions, not the
implementation. When a class
implements the interface, it also
implements the functionality as
per requirement.
Collaboration Notation
Collaboration is represented by a
dotted eclipse as shown in the
following figure. It has a name
written inside the eclipse.
It represents responsibilities,
which generally, are in a group.

Use Case Notation

Use case is represented as an
eclipse with a name inside it.
It may contain additional
responsibilities.
Actor Notation
An actor can be defined as some internal
or external entity that interacts with the
system. It is used in a use case diagram
to describe the internal or external
entities.

Initial State Notation

Initial state is defined to show the start
of a process. This notation is used in
almost all diagrams.
Final State Notation
Final state is used to show the end of
a process. It is also used in almost all
diagrams to describe the end.

Active Class Notation

Active class looks similar to a
class with a solid border. It is
generally used to describe the
concurrent behaviour of a
system.
It is used to represent the concurrency
in a system.
Component Notation
Component is used to represent
any part of a system for which UML
diagrams are made.

Node Notation
A node in UML is represented by a
square box as shown in the
following figure with a name. It is
used to represent the physical part
of a system such as the server,
network, etc.
Behavioural Things
UML has a set of powerful features to represent
the dynamic part of software and non-software
systems. These features include :
(i) interactions and (ii) state machines.
Interactions can be of two types −
i. Sequential (Represented by sequence
diagram)
ii. Collaborative (Represented by collaboration
diagram)
Interaction Notation
Interaction is basically a
message exchange
between two UML
components.
The diagram shows
different notations used
in an interaction.
It is used to represent
the communication
among the components
of a system.
State Machine Notation
State machine describes
the different states of a
component in its life
cycle. The notations are
described in the
diagram.
It is used to describe
different states of a
system component. The
state can be active, idle,
or any other depending
upon the situation.
Grouping Things
Organizing the UML models is one of the most
important aspects of the design. In UML, there is
only one element available for grouping and that is
package.

Package Notation
Package notation is shown in the following figure
and is used to wrap the components of a system.
Annotational Things
In any diagram, explanation of different elements
and their functionalities are very important.
Hence, UML has notes notation to support this
requirement.

Note Notation
This notation is shown in the following figure.
These notations are used to provide necessary
information of a system.
Relationships
A model is not complete unless the relationships
between elements are described properly.
The Relationship gives a proper meaning to a UML
model. Following are the different types of
relationships available in UML.
 Dependency
 Association
 Generalization
 Extensibility
Dependency Notation
Dependency is an important aspect in UML
elements. It describes the dependent elements
and the direction of dependency.
It 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
Association Notation
It describes how many elements are taking part in
an interaction.
It 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.
Generalization Notation
It describes the inheritance relationship of the
object-oriented world. It is a parent and child
relationship. It 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.

It is used to describe parent-child relationship of

two elements of a system.
Extensibility Notation
UML also has the following mechanisms to
provide extensibility features.
 Stereotypes (Represents new elements)
 Tagged values (Represents new attributes)
 Constraints (Represents the boundaries)
 Class Diagram
 It represents the static view of an application. It is not only
used for visualizing, describing, and documenting different
aspects of a system but also for constructing executable
code of the software application.
 It describes the attributes and operations of a class and also
the constraints imposed on the system.
 It is widely used in the modelling of object-oriented systems
because it is the only UML diagrams, which can be mapped
directly with object-oriented languages.
 It shows a collection of classes, interfaces, associations,
collaborations, and constraints.
 It is also known as a structural diagram.
 It can be used as base for component and deployment
diagrams.
 It is used for both forward and reverse engineering.
 How to Draw a Class Diagram?
The following should be remembered while drawing a class diagram:
i. The name of the class diagram should be meaningful to
describe the aspect of the system.
ii. Each element and their relationships should be identified in
advance.
iii. Responsibility (attributes and methods) of each class should be
clearly identified.
iv. For each class, minimum number of properties should be
specified, as unnecessary properties will make the diagram
complicated.
v. 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.
vi. Finally, before making the final version, the diagram should be
drawn on plain paper and reworked as many times as possible
to make it correct.
The following diagram is an example of an Order
System of an application. It describes a particular
aspect of the entire application.
 First of all, Order and Customer are identified as the
two elements of the system. They have a one-to-
many relationship because a customer can have
multiple orders.
 Order class is an abstract class and it has two
concrete classes (inheritance relationship)
SpecialOrder and NormalOrder.
 The two inherited classes have all the properties as
the Order class. In addition, they have additional
functions like dispatch () and receive ().
The following class diagram has
been drawn considering all the
points mentioned above.
In a nutshell it can be said, class
diagrams are used for −
 Describing the static view of
the system.
 Showing the collaboration
among the elements of the
static view.
 Describing the functionalities
performed by the system.
 Construction of software
applications using object
oriented languages.
 Object Diagrams
 They are derived from class diagrams, so, object
diagrams are dependent upon class diagrams.
 They represent an instance of a class diagram. The
basic concepts are similar for class diagrams and
object diagrams.
 They also represent the static view of a system but this
static view is a snapshot of the system at a particular
moment.
 They are used to render a set of objects and their
relationships as an instance.
 They are used for both forward & reverse engineering.
 Understand object behaviour and their relationship
from practical perspective
 How to Draw a Object Diagram?
The following things should be remembered and
understood clearly:
i. Object diagrams consist of objects.
ii. The link in object diagram is used to connect objects.
iii. Objects and links are the two elements used to
construct an object diagram.
iv. The object diagram should have a meaningful name to
indicate its purpose.
v. The most important elements are to be identified.
vi. The association among objects should be clarified.
vii. Values of different elements need to be captured to
include in the object diagram.
viii.Add proper notes at points where more clarity is
required.
The following diagram is an example of an object diagram.
It represents the Order management system which we
have discussed in the Class Diagram.
The following diagram is an instance of the system at a
particular time of purchase. It has the following objects.
 Customer
 Order
 SpecialOrder
 NormalOrder
Now the customer object (C) is associated with three order
objects (O1, O2, and O3). These order objects are
associated with special order and normal order objects
(S1, S2, and N1). The customer has the following three
orders with different numbers (12, 32 and 40) for the
particular time considered.
The customer can increase the number of orders in future
and in that scenario the object diagram will reflect that. If
order, special order, and normal order objects are
observed then you will find that they have some values.
For orders, the values are 12, 32, and 40 which implies that
the objects have these values for a particular moment
(here the particular time when the purchase is made is
considered as the moment) when the instance is captured
The same is true for special order and normal order
objects which have number of orders as 20, 30, and 60. If a
different time of purchase is considered, then these values
will change accordingly.
The following object diagram has been drawn considering
all the points mentioned above
In a nutshell, it can be said that object diagrams are used
for:
 Making the prototype of a system.
 Reverse and forward engineering.
 Modelling complex data structures.
 Understanding the system from practical perspective.
 Component Diagrams
 They are different in terms of nature and behaviour.
 They are used to model the physical aspects of a system
such as executables, libraries, files, documents, etc.
 They are used to visualize the organization and
relationships among components in a system.
 They diagrams are also used to make executable
systems.
 They do not describe the functionality of the system
but rather describe the components used to make
those functionalities.
 They can also be described as a static implementation
view (which represents the organization of the
components at a particular moment) of a system.
 How to Draw a 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.
Following is a component diagram for order management
system. Here, the artifacts are files. The diagram shows the
files in the application and their relationships.
Four files are identified and their relationships are
produced. Component diagram cannot be matched
directly with other UML diagrams discussed so far as it is
drawn for completely different purpose.
 Deployment Diagrams
 Deployment diagrams are used to visualize the
topology of the physical components of a system,
where the software components are deployed.
 Deployment diagrams are used to describe the static
deployment view of a system.
 Deployment diagrams consist of nodes and their
relationships.
 Describe the runtime processing nodes.
 Component diagrams and deployment diagrams are
closely related in that while component diagrams are
used to describe the components, deployment
diagrams shows how they are deployed in hardware.
 How to Draw a Deployment Diagram?
Deployment diagrams are useful for system engineers. An
efficient deployment diagram is very important as it
controls the following parameters:
 Performance
 Scalability
 Maintainability
 Portability

Before drawing a deployment diagram, the following

artifacts should be identified:
 Nodes
 Relationships among nodes
Following is a sample deployment diagram to provide an
idea of the deployment view of order management
system. Here, we have shown nodes as:
 Monitor
 Modem
 Caching server
 Server
The application is assumed to be a web-based application,
which is deployed in a clustered environment using server
1, server 2, and server 3. The user connects to the
application using the Internet. The control flows from the
caching server to the clustered environment.
The following deployment diagram has been drawn
considering all the points mentioned above.
Where to Use Deployment Diagrams?
Deployment diagrams are mainly used by system
engineers. Software applications are developed to model
complex business processes. Now-a-days software
applications are very complex in nature. Software
applications can be standalone, web-based, distributed,
mainframe-based and many more. Hence, it is very
important to design the hardware components efficiently.
 Use Case Diagrams
 In UML, there are five diagrams available to model the
dynamic nature and use case diagram is one of them.
 Now as we have to discuss that the use case diagram is
dynamic in nature, there should be some internal or
external factors for making the interaction.
 These internal and external agents are known as actors.
 Use case diagrams consists of actors, use cases and
their relationships.
 The diagram is used to model the system/subsystem of
an application.
 A single use case diagram captures a particular
functionality of a system.
 Hence to model the entire system, a number of use
case diagrams are used.
 Purpose of Use Case Diagrams
 Use case diagrams are used to gather the requirements
of a system including internal and external influences
 These requirements are mostly design requirements.
 Hence, when a system is analyzed to gather its
functionalities, use cases are prepared and actors are
identified.
 When the initial task is complete, use case diagrams are
modelled to present the outside view.

How to Draw a Use Case Diagram?

 Functionalities to be represented as use case
 Actors
 Relationships among the use cases and actors.
Following is a sample use case
diagram representing the order
management system. Hence,
we have 3 use cases (Order,
SpecialOrder & NormalOrder)
and one actor which is the
customer. The SpecialOrder and
NormalOrder use cases are
extended from Order use case.
Hence, they have extended
relationship. Another important
point is to identify the system
boundary. The actor Customer lies
outside the system as it is an
external user of the system.
 Where to Use a Use Case Diagram?
 These diagrams are used at a very high level of design
which is refined again and again to get a complete and
practical picture of the system.
 A well-structured use case also describes the pre-
condition, post condition, and exceptions. These extra
elements are used to make test cases when performing
the testing.
 In forward engineering, use case diagrams are used to
make test cases.
 In reverse engineering use cases are used to prepare the
requirement details from the existing application.
 Interaction Diagrams
 From the term Interaction, it is clear that the diagram is
used to describe some type of interactions among the
different elements in the model.
 This interaction is a part of dynamic behaviour of the
system.
 This interactive behaviour is represented in UML by two
diagrams known as Sequence diagram and Collaboration
diagram.
 The basic purpose of both the diagrams are similar.
 Sequence diagram emphasizes on time sequence of
messages
 Collaboration diagram emphasizes on the structural
organization of the objects that send and receive
messages.
 Purpose of Interaction Diagrams and how to draw them
The purpose of interaction diagram is −
 To capture the dynamic behaviour of a system.
 To describe the message flow in the system.
 To describe the structural organization of the objects.
 To describe the interaction among objects.
 To visualize the interactive behaviour of the system.
 Sequence and collaboration diagrams are used to
capture the dynamic nature but from a different angle.
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.
Following are two interaction diagrams modelling the order
management system. The first diagram is a sequence
diagram and the second is a collaboration diagram
The Sequence Diagram
The sequence diagram has four objects (Customer, Order,
SpecialOrder and NormalOrder).
 The first call is sendOrder () which is a method of Order
object.
 The next call is confirm () which is a method
of SpecialOrder object and
 The last call is Dispatch () which is a method
of SpecialOrder object.
The following diagram mainly describes the method calls
from one object to another, and this is also the actual
scenario when the system is running.
The Sequence Diagram The Collaboration Diagram
The Collaboration Diagram
In the collaboration diagram, the method call sequence is
indicated by some numbering technique. The number
indicates how the methods are called one after another.
Method calls are similar to that of a sequence diagram.
However, difference being the sequence diagram does not
describe the object organization, whereas the
collaboration diagram shows the object organization.
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.
 Where to Use Interaction Diagrams?
To understand the practical application, we need to know
the basic nature of sequence and collaboration diagram.
 Sequence diagrams are used to capture the order of
messages flowing from one object to another.
 Collaboration diagrams are used to describe the
structural organization of the objects taking part in the
interaction.
 Interaction diagrams are used when we want to
understand the message flow and the structural
organization.
 Message flow means the sequence of control flow
from one object to another. Structural organization
means the visual organization of the elements in a
system.
 Statechart Diagrams
 The name of the diagram itself clarifies the purpose of
the diagram and other details.
 It describes different states of a component in a
system. The states are specific to a component/object
of a system.
 A Statechart diagram describes a state machine. State
machine can be defined as a machine which defines
different states of an object and these states are
controlled by external or internal events.
 As Statechart diagram defines the states, it is used to
model the lifetime of an object.
 Purpose of Statechart Diagrams
 They define different states of an object during its
lifetime and these states are changed by events.
 Statechart diagrams are useful to model the reactive
systems. Reactive systems can be defined as a system
that responds to external or internal events.
 Statechart 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 Statechart diagram is
to model lifetime of an object from creation to
termination.
 Statechart diagrams are also used for forward and
reverse engineering of a system.
 How to Draw a Statechart Diagram?
Before drawing a Statechart diagram we should clarify the
following points:
i. Identify the important objects to be analyzed.
ii. Identify the states.
iii. Identify the events.

Following is an example of a Statechart diagram where

the state of Order object is analyzed
 The first state is an idle state from where the process
starts.
 The next states are arrived for events like send request,
confirm request, and dispatch order. These events are
responsible for the state changes of order object.
During the life cycle of an
object (here order object) it
goes through the following
states and there may be some
abnormal exits. This
abnormal exit may occur due
to some problem in the
system. When the entire life
cycle is complete, it is
considered as a complete
transaction as shown in the
following figure. The initial
and final state of an object is
also shown in the following
figure.
 Where to Use Statechart Diagrams?
 Statechart diagram defines the states of a component
and these state changes are dynamic in nature. Its
specific purpose is to define the state changes
triggered by events. Events are internal or external
factors influencing the system.
 Statechart diagrams are used to model the states and
also the events operating on the system.
 When implementing a system, it is very important to
clarify different states of an object during its life time
and Statechart diagrams are used for this purpose.
 When these states and events are identified, they are
used to model it and these models are used during the
implementation of the system.
 Activity Diagrams
 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 activity can be described as an operation of the
system.
 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
 Purpose of Activity Diagrams
 They used to show message flow from one activity to
another rather to show the message flow from one
object to another as other dynamic diagrams
 They are not only used for visualizing the dynamic
nature of a system, but also to construct the
executable system by using forward and reverse
engineering techniques.
 It does not show any message flow from one activity to
another. Activity diagram is sometimes considered as
the flowchart.
 Although the diagrams look like a flowchart, they are
not. It shows different flows such as parallel, branched,
concurrent, and single.
 How to Draw an Activity Diagram?
Before drawing an activity diagram, we must have a clear
understanding about the elements used in activity
diagram. The main element of an activity diagram is the
activity itself.
Before drawing an activity diagram, we should identify the
following elements −
i. Activities
ii. Association
iii. Conditions
iv. Constraints
Once the above-mentioned parameters are identified, we
need to make a mental layout of the entire flow. This
mental layout is then transformed into an activity
diagram.
Following is an example of an activity diagram for order
management system. In the diagram, four activities are
identified which are associated with conditions. Following
diagram is drawn with the four main activities:
i. Send order by the customer
ii. Receipt of the order
iii. Confirm the order
iv. Dispatch the order
After receiving the order request, condition checks are
performed to check if it is normal or special order. After
the type of order is identified, dispatch activity is
performed and that is marked as the termination of the
process.
Activity diagram can be used for:
 Modelling work flow by using activities.
 Modelling business requirements.
 High level understanding of the system's
functionalities.
 Investigating business requirements at a later stage.