OO Analysis and Design

Object oriented analysis is an investigation and to be more specific it is the

identification of objects of a system to be developed.

After identifying objects it is important to understand the relationship among all objects
and prepare design

Object oriented design means collaboration of identified objects.

What is UML 

 UML is not a programming language but tools can be used to generate code in
various languages using UML diagrams.

 Unified Modeling Language diagram is designed to let developers and customers

view a software system from a different perspective

 UML has become a standard modeling language is that it is programming

language independent

 Since UML is not a methodology, it does not require any formal work products.

 To model a system the most important aspect is to capture the dynamic behavior.

 To clarify a bit in details, dynamic behavior means the behavior of the system
when it is running /operating.

 So only static behavior is not sufficient to model a system rather dynamic behavior is
more important than static behavior.

 In UML there are five diagrams available to model 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.
Structural Diagrams

 Structure diagrams emphasize on the things that must be present in the system
being modeled.

 Since structure diagrams represent the structure, they are used extensively in
documenting the software architecture of software systems.

Behavioral Diagrams

 Behavior diagrams emphasize on what must happen in the system being modeled.

 Since behavior diagrams illustrate the behavior of a system, they are used
extensively to describe the functionality of software systems

Explain types of diagrams are there in UML.

Activity diagram: Activity diagram represents the procedural logic, business process
and work flow that supports parallelism.

Class Diagram: A diagram which describes the attributes and the methods of a class
and the relationships between the classes.

Component diagram: A component diagram depicts how the object oriented

components are wired together from larger components.

Deployment Diagram: Depicts the physical deployment of artifacts. The allocation of

artifacts to nodes as per the deployments defined among them.

Use Case diagram: A behavioral diagram which is defined and analyzed by using case
to case.

Sequence Diagram: It is a kind of interactive diagram which shows the flow of

operations of properties, objects with other entities and objects.

Collaboration diagrams: The interactions between objects like a sequence of

messages are represented in this diagram. They describe the basic structure and
dynamic behavior of a system.

State chart diagram: State chart describes the behavior of system in response to the
external stimuli. Trigger the specific events are modeled by the state chart diagrams.
Use case diagrams

Introduction

 A use case diagram describes how a system interacts with outside actors.

 A use case diagram is a representation of a user's interaction with the

system.

 Each use case representation a piece of functionality that a system provides

to its user.

 Use case identifies the functionality of a system.

 Use case to capture the intended behavior of the system you are developing,
without having to specify how that behavior is implemented.

A use case diagram contains four components.

1. The boundary, which defines the system of interest in relation to the world around
it.

2. The actors, usually individuals involved with the system defined according to their
roles.

3. The use cases, which the specific roles are played by the actors within and around
the system.

4. The relationships between and among the actors and the use cases

Purpose:

 The main purpose of the use case diagram is to capture the dynamic aspect of
a system.

 Use case diagram shows, what software is suppose to do from user point of
view.

 It describes the behavior of system from user’s point.

 Use case diagram defines the scope of the system you are building.
When to Use Use Cases Diagrams

 Use cases are used in almost every project.

 They are helpful in exposing requirements and planning the project.

 During the initial stage of a project most use cases should be defined

How to draw Use Case Diagram?

Use case diagrams are considered for high level requirement analysis of a system.

So we can say that use cases are nothing but the system functionalities written in
an organized manner.

When we are planning to draw a use case diagram we should have the following items
identified.

 Functionalities to be represented as a use case

 Actors
 Relationships among the use cases and actors.

Use case diagrams are drawn to capture the functional requirements of a system.

So after identifying the above items we have to follow the following guidelines to draw
an efficient use case diagram.

 The name of a use case is very important. So the name should be chosen in
such a way so that it can identify the functionalities performed.

 Give a suitable name for actors

 Show relationships and dependencies clearly in the diagram

Use Case Notations

System Boundary

System Boundary can be presented with a rectangle.

The scope of a system can be represented by a system boundary.

The use cases of the system are placed inside the system boundary, while the actors
who interact with the system are put outside the system.
The use cases in the system make up the total requirements of the system.

Use Case

Use cases can be presented with ellipse

A use case represents a user goal that can be achieved by accessing the system or
software application

Actors

Actors are the entities that interact with a system.

Although in most cases, actors are used to represent the users of system, actors can
actually be anything that needs to exchange information with the system.

So an actor may be people, computer hardware, other systems, etc.

Note that actor represent a role that a user can play, but not a specific user.
i.e. Just provide user will login not provide info that Akshesh will login
Association

Actor and use case can be associated to indicate that the actor participates in that use
case.

Therefore, an association corresponds to a sequence of actions between the actor and

use case in achieving the use case.

An association is a relationship between objects; aggregation and composition

are types of association.

Association is a relationship where all objects have their own lifecycle and there
is no owner.

Example of Association  of Teacher and Student.

Multiple students can associate with single teacher and single student can associate
with multiple teachers, but there is no ownership between the objects and both have
their own lifecycle. Both can be created and deleted independently.

Aggregation

Aggregation is a specialized form of Association where all objects have their own
lifecycle, but there is ownership and child objects can not belong to another parent
object.

Aggregation of Aggregation  of Department and teacher.

Example  A single teacher can not belong to multiple departments, but if we

delete the department, the teacher object will not be destroyed.

Example  A single class has multiple students,

Here students (child objects) can not belong to another Class and if we delete class
students will still be there as independent objects

It represents “Has-a” relationship

Composition

Composition is again specialized form of Aggregation and we can call this as a

“death” relationship.

It is a strong type of Aggregation.

Child object does not have its lifecycle and if parent object is deleted, all child objects
will also be deleted.

Example  relationship between House and Rooms. House can contain multiple
rooms - there is no independent life of room and any room can not belong to two
different houses. If we delete the house - room will automatically be deleted.

Example  relationship between Questions and Options. Single questions can

have multiple options and option can not belong to multiple questions. If we delete the
questions, options will automatically be deleted.

Example  relationship between book and pages

In UML Class Diagrams, both "aggregation" and "composition" have been defined as
special cases of associations representing part-whole relationships (which have been
discussed in philosophy for a long time).

In their definitions, the distinction between an "aggregation" and a "composition" is

based on the fact if it allows sharing a part between two or more wholes.
They define "compositions" as having non-shareable (exclusive) parts, while
"aggregations" may share their parts

A company has department and department has employees

Now employees have an Aggregation relationship with Department. Employees of say
testing cannot be of different department and if testing department is removed still
employees will be there.

A Company and Department have composition relationship. Department cannot be of

different company and if a company is destroyed department will also be destroyed.

Difference between Include & Extend

 Include Extend
Include relationship is something like a Extend relationship is something like an
prerequisite option / additional

Include  Re use of functionality Extend  add / optional functionality

Include  Login to the system Extend  Compare prices

i.e. you always have to Re use ( Re login i.e. you add / optional functionality to
to use system compare prices

Include case is the case that has to be

performed before performing other cases.

Extend does NOT impose compulsion on

Include impose compulsion on the cases
the cases

Include presents a dependency in the

Extend is an independent in the system
system

Include provides a compulsion behavior Extend provides an optional behavior

which does affects the previous base which does not affect the previous base
cases cases

My use case: I am going to the city.

includes -> drive the car

extends -> fill the petrol

"Fill the petrol" may not be required at all times, but may optionally be required based
on the amount of petrol left in the car. "Drive the car" is a prerequisite hence I am
including.

My use case: Online shopping

Include  Login to the system

Extend  Compare prices of the items

My use case: get a copy of part plan

Include  Enter plot no

Extend  Provide scale for part plan

Example of Paytm

You must be Sign in for payment i.e. include relationship

After Log in you can have options for online payment like Visa / Master card i.e. Extend

Generalization

The UML diagram's Generalization association is also known as Inheritance.

A generalization relationship is used to represent inheritance relationship between

model elements of same type.

Generalization referred to as a "is-a-kind-of" or "is-a" relationship; that means

that the child class is-a-kind-of a base class.

The subclass is a particular case of the superclass and inherits all attributes and
operations of superclass, but can have your own additional attributes and operations.
UML is used also the multiple inheritance when the subclass inherits properties and
behaviors of more than one superclass.

On the UML Diagram the Generalization association represents as the line with empty
triangle that connects superclass and subclass.

Example  Base class Vehicle

Derived class Car, Bike

Generalization:
Generalization is the process of extracting shared characteristics from two or more
classes, and combining them into a generalized superclass. Shared characteristics
can be attributes, associations, or methods."

Generalization identifies the commonalities among a set of entities.

Specialization

Specialization means creating new subclasses from an existing class."

Specialization is the reverse process of Generalization means creating new sub classes
from an existing class
Generalization
---------------
If many similar existing objects are combined to form a superclass to do the job of its
subclass', then it is known as Generalization

Specialization
--------------
if some new subclasses are created from an existing superclass to do specific job of the
superclass, then it is known as specialization.

Dependency

Change in structure or behavior of a class affects the other related class, then there is a
dependency between those two classes.

It need not be the same vice-versa. When one class contains the other class it this
happens.

Example: Relationship between shape and circle is dependency.

Realization

Realization is a relationship between the blueprint class and the object containing its
respective implementation level details.

This object is said to realize the blueprint class.

In a realization relationship, one entity (normally an interface) defines a set of

functionalities as a contract and the other entity (normally a class) "realizes" the
contract by implementing the functionality defined in the contract.

In other words, you can understand this as the relationship between the interface
and the implementing class.

Example: A particular model of a car ‘GTB Fiorano’ that implements the blueprint of a
car realizes the abstraction
Class Diagram

The class diagram is a static diagram.

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

The class diagram describes the attributes and operations of a class and also the
constraints imposed on the system.

The class diagrams are widely used in the modeling of object oriented systems
because they are the only UML diagrams which can be mapped directly with object
oriented languages.
The class diagram shows a collection of classes, interfaces, associations,
collaborations and constraints. It is also known as a structural diagram.

Purpose of Class diagram

The purpose of the class diagram is to model the static view of an application

The Class diagrams can be directly mapped with object oriented languages

How to draw Class Diagram?

Class diagram is basically a graphical representation of the static view of the

system and represents different aspects of the application.

So a collection of class diagrams represent the whole system.

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

 Use notes when ever required to describe some aspect of the diagram. Because
at the end of the drawing it should be understandable to the developer/coder

 Class diagram is also considered as the foundation for component and deployment
diagrams

 Class diagram clearly shows the mapping with object oriented languages like
Java, C++ etc.

 So from practical experience class diagram is generally used for construction

purpose
Object Diagrams

Object diagrams are derived from class diagrams so object diagrams are
dependent upon class diagrams.

Object diagrams represent an instance of a class diagram.

Object diagrams also represent the static view of a system but this static view is a
snapshot of the system at a particular moment.
Purpose of an Object Diagram

The difference is that a class diagram represents an abstract model consisting of

classes and their relationships.

But an object diagram represents an instance at a particular moment which is

concrete in nature.
It means the object diagram is more close to the actual system behavior. The
purpose is to capture the static view of a system at a particular moment.

So the purpose of the object diagram can be summarized as

 Object relationships of a system

 Static view of an interaction.
 Understand object behavior and their relationship from practical perspective

How to draw Object Diagram?

To capture a particular system, numbers of class diagrams are limited.

But if we consider object diagrams then we can have unlimited number of instances
which are unique in nature.

So only those instances are considered which are having 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 objects of a system. So the solution is

 First, analyze the system and decide which instances are having important
data and association.

 Second, consider only those instances which will cover the functionality.

 Third, make some optimization as the numbers of instances are unlimited.

Before drawing an object diagrams the following things should be remembered and
understood clearly

 Object diagrams are consist of objects.

 The link in object diagram is used to connect objects.
 Objects and links are the two elements used to construct an object diagram.

Now after this 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.
 Add proper notes at points where more clarity is required.
Where to use Object Diagrams?

Object diagrams can be imagined as the snapshot of a running system at a

particular moment. Now to clarify it we can take an example of a running train.

Now if you take a snap of the running train then you will find a static picture of it
having the following

1. A particular state which is running

2. A particular number of passengers which will change if the snap is taken in
a different time.

So here we can imagine the snap of the running train is an object having the above
values. And this is true for any real life simple or complex system. In a brief, object
diagrams are used for

 Making the prototype of a system.

 Reverse engineering.
 Modeling complex data structures.
 Understanding the system from practical perspective.
Activity Diagram

Activity diagram is used to describe dynamic aspects of the system

Activity diagram is basically a flow chart to represent the flow form one activity to
another activity

The activity can be described as an operation of the system

So the control flow is drawn from one operation to another. This flow can be sequential,
branched or concurrent.

Purpose of an Activity diagram

The basic purpose of an activity diagram is captures the dynamic behavior of the
system

Other four diagrams are used to show the message flow from one object to another but
activity diagram is used to show message flow from one activity to another

The only missing thing in activity diagram is the message part.

Activity diagram does not show any message flow from one activity to another

How to draw Activity Diagram?

 Activity diagrams are mainly used as a flow chart consists of activities performed
by the system. But activity diagram are not exactly a flow chart as they have
some additional capabilities.

 These additional capabilities include branching, parallel flow, swimlane etc.

 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. 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.
The following diagram is drawn with the four main activities

 Send order by the customer

 Receipt of the order
 Confirm order
 Dispatch 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.

Where to use Activity Diagrams?

The activity diagram is suitable for modeling the activity flow of the system. An
application can have multiple systems.

Activity diagram describes flow from one system to another.

This specific usage is not available in other diagrams. These systems can be database,
external queues or any other system.

So it gives high level view of a system. This high level view is mainly for business
users or any other person who is not a technical person.
This diagram is used to model the activities which are nothing but business
requirements. So the diagram has more impact on business understanding rather
implementation details.

Following are the main usages of activity diagram

 Modeling work flow by using activities.

 Modeling business requirements.
 High level understanding of the system's functionalities.
 Investigate business requirements at a later stage.

Important to remember

Activity diagrams represent the flow of use cases.

But sequence diagrams represent the interaction between classes or objects

according to time.

So there is a difference between these two diagrams.

Before moving to activity diagrams you need to draw the use case diagram. Using use
case (system behavior) diagram you can identify activities (behaviors).

Then you need to draw the activity diagram to show the flow of behaviors.

Then you need to identify the classes and draw the class diagram.

Using class diagram you can draw the sequence diagrams to show the interaction
between classes.

1. use case diagram

2. activity diagram
3. class diagram
4. sequence diagram
Difference between Activity Diagrams & Sequence Diagrams

An Activity Diagram shows a workflow - a starting point, actions, decisions, splits and
joins to show concurrent activities, and ending points. It's essentially a flowchart for a
process or workflow, usually written using domain specific terms.

Activity Diagram doesn't show classes, objects, or calls to methods/functions.

Sequence Diagram shows interactions between actors and objects and between
two objects.

Usually, this is at a method/function call level, perhaps even including parameters and
return types.

Typically, I'll use Activity Diagrams for showing a workflow at a level that is
understandable by users who don't necessarily care about the implementation details.

I will use Sequence Diagrams for capturing implementation details useful for
helping people to write or understand code or to help in testing the software.

An activity diagram is nothing more than a flowchart

Sequence diagrams specifically focus on the "lifelines" of an object and how they
communicate with other objects to perform a function before the lifeline ends.
Component Diagrams
Component diagrams are different in terms of nature and behavior.

Component diagrams are used to model physical aspects of a system.

It describes the components used to make those functionalities of the software

These components are libraries, packages, files etc.

So the purpose of the component diagram can be summarized as

 Visualize the components of a system.

 Describe the organization and relationships of the components.

Those components are libraries, files, executables etc. Now before implementing
the application these components are to be organized.

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

Deployment Diagram
Deployment diagrams are used to visualize the topology of the physical
components of a system where the software components are deployed.

Deployment diagrams are mainly used by system engineers.

These diagrams are used to describe the physical components (hardware), their
distribution and association.

The usage of deployment diagrams can be described as follows

 To model the hardware topology of a system.

 To model embedded system.
 To model hardware details for a client/server system.
 To model hardware details of a distributed application.