Unit 1: Introduction LH 9

Introduction to OOAD
– concept of OOAD
– Concept of UML
–What are the United process(UP) phases
– Inception
– Use case Modeling
– Relating Use cases
– include, extend and generalization
 INTRODUCTION:

Object-Oriented Analysis and Design (OOAD) is a software

engineering methodology that involves using object-
oriented concepts to design and implement software
systems.

OOAD involves a number of techniques and practices,

including object-oriented programming, design patterns,
UML diagrams, and use cases.

 Object-Oriented Programming:

Object-Oriented Programming (OOP) is a computer

programming model that organizes software design
around data, or objects rather than functions and logic.

 Design Patterns:
Design patterns are reusable solutions to common
problems in software design.
 UML Diagrams:
Unified Modeling Language (UML) is a standardized
notation for creating diagrams that represent different
aspects of a software system.

 Use Cases:
Use cases are a way of describing the different ways in
which users interact with a software system.
 Object-Oriented Analysis (OOA)
 During object-oriented analysis (OOA) there is an emphasis on
finding and describing the objects or concepts in the problem
domain.

 OOA focuses on investigation of the problem and requirements,

rather than a solution.

For example:-

In the case of the flight information system, some of the concepts

include Plane, Flight, and Pilot.

Object-Oriented Design (OOD)

 During object-oriented design (or, object design) there is an
emphasis on defining software objects and how they collaborate
to fulfill the requirements.

 OOD focuses on conceptual solution that fulfills the

requirements, rather than its implementation.

For example:-

A Plane software object may have a tailNumber attribute and a

getFlightHistory method.
Advantages of using OOAD in software engineering:

1. Reusability: OOAD emphasizes the use of reusable

components and design patterns, which can save time
and effort in software development.

2. Scalability: OOAD can help developers design software

systems that are scalable and can handle changes in
user demand and business requirements over time.

3. Maintainability: OOAD emphasizes modular design

and can help developers create software systems that
are easier to maintain and update over time.

4. Flexibility: OOAD can help developers design software

systems that are flexible and can adapt to changing
business requirements over time.
 UML (Unified Modeling Language)

What is the UML?

 The Unified Modeling Language is a visual

language for specifying, constructing and
documenting the artifacts of systems.
OR,
Unified Modelling Language (UML) is the set of
notations, models and diagrams used when
developing object-oriented (OO) systems.

 UML first appeared in 1997

 UML is standardized. Its content is controlled by
the Object Management Group (OMG).
A Conceptual Model of the UML

 A conceptual model needs to be formed by an individual

to understand UML.
 UML contains three types of building blocks:
 Things
 Relationships
 and Diagrams.
Things
– Structural things
Classes, interfaces, collaborations, use cases,
components, and nodes.

– Behavioral things
Messages and states.

– Grouping things
Packages
– Annotational things
Notes
Relationships:
 Dependency
 Association
 Generalization
 Realization.

Diagrams:

 Class Diagram
 Object Diagram
 Use case Diagram
 Sequence Diagram
 Collaboration Diagram
 State chart Diagram
 Activity Diagram
 Component Diagram

 Deployment Diagram
 Things in the UML
There are four kinds of things in the UML:
1. Structural things
2. Behavioral things
3. Grouping things
4. Annotational things

Structural Things
Structural things are the nouns of UML models.
These are the mostly static parts of a model,
representing elements that are either conceptual or
physical.

In all, there are seven kinds of structural things.

• Classes
• Interface
• Collaborations
• Cases
• Active Classes
 • Components
• Nodes

i. Classes:

 Classes are user-defined data types that act as the

blueprint for individual objects.

 Graphically, a class is rendered as a rectangle, usually

including its name, attributes, and operations.

Car Class Name

Brand Class’s
Price Attribute

Start()
Stop() Class’s
Opreation /
Honk() Methods

Fig:- Class
ii. Interfaces

 An interface is a collection of operations that

specify a service of a class or component.

 An interface rarely stands alone. Rather, it is

typically attached to the class or component that
realizes the interface.

Fig:- Interface

iii. Collaborations:
 A collaboration defines an interaction. These
collaborations therefore represent the
implementation of patterns that make up a
system.
 Graphically, a collaboration is rendered as an
ellipse with dashed lines, usually including only its
name.

Name of
Collaboration

Fig:- Collaboration

iv. Use Cases:

 A use case is realized by a collaboration.

 Graphically, a use case is rendered as an ellipse
with solid lines, usually including only its name.

Name Of
Use Case

Fig:- Use Case

v. Active Classes:

 An active class is rendered just like a class, but

with heavy lines, usually including its name,
attributes, and operations.

Name_of_class
Attributes ;
Metods();

Fig:- Active Class

vi. Components:

 A component typically represents the physical

packaging of otherwise logical elements, such as
classes, interfaces, and collaborations.
 Graphically, a component is rendered as a
rectangle with tabs, usually including only its
name.

Name_of_component

Fig:- Component
vii. Nodes:

 A node is a physical element that exists at run

time and represents a computational resource,
generally memory and, processing capability.

 Graphically, a node is rendered as a cube,

usually including only its name.

Server

Fig:- Node
Behavioral Things

 A behavioral thing consists of the dynamic parts

of UML models. Following are the behavioral
things –

i. Message :-

 Interaction is defined as a behavior that consists

of a group of messages exchanged among
elements to accomplish a specific task.

 Graphically, a message is rendered as a directed

line, almost always including the name of its
operation.

Display

Fig:- Message
 ii. States:

 A state machine is a behavior that specifies the

sequences of states an object or an interaction
goes through during its lifetime in response to
events, together with its responses to those
events.

Waiting

Grouping Things

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

 Graphically, a package is rendered as a tabbed

folder, usually including only its name and,
sometimes, its contents

Package_Name

Fig:- Package
Annotational Things:

 Annotational things are the explanatory parts of

UML models.
 Note is the only one Annotational thing available.
A note is used to render comments, constraints,
etc. of an UML element.

Comments/Notes
 Relationships in UML
There are four kinds of relationships in the UML:

i. Dependency

ii. Association

iii. Generalization

iv. Realization

i. Dependency
 Dependency is a semantic relationship between
two model elements in which a change to one
element (the independent one) may affect the
semantics of the other element (the dependent
one).
 Graphically, a dependency is rendered as a
dashed line, possibly directed, and occasionally
including a label.
ii. Association

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

 Graphically, an association is rendered as a solid

line, possibly directed, occasionally including a
label, and often containing other adornments,
such as multiplicity and end names.

0..1 *
employer employee
iii. Generalization

 Generalization is a specialization/generalization
relationship in which the specialized element (the
child) builds on the specification of the
generalized element (the parent).

 It basically describes the inheritance relationship

in the world of objects.

 Graphically, a generalization relationship is

rendered as a solid line with a hollow arrowhead
pointing to the parent.
iv. Realization

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

 It is the combination of generalization and a

dependency relationship.
 UML Diagrams
 A diagram is the graphical presentation of a set
of elements, most often rendered as a connected
graph of things and relationships.
 A diagram represents view of the elements that
make up a system.
 A diagram may contain any combination of things
and relationships.

1. Class diagram
2. Object diagram
3. Use case diagram
4. Sequence diagram
5. Collaboration diagram
6. Statechart diagram
7. Activity diagram
8. Component diagram
9. Deployment diagram
1. Class diagram shows a set of classes,
interfaces, and collaborations and their
relationships.

2. Object diagram shows a set of objects and

their relationships. Object diagrams represent
static snapshots of instances of the things found
in class diagrams.

3. Use case diagram shows a set of use cases

and actors (a special kind of class) and their
relationships.

4. Sequence diagram is an interaction diagram

that emphasizes the time-ordering of messages.
5. Collaboration diagram is an interaction
diagram that emphasizes the structural
organization of the objects or roles that send and
receive messages.

6. Statechart diagram shows a state machine,

consisting of states, transitions, events, and
activities.

7. Activity diagram shows the structure of a

process or other computation as the flow of
control and data from step to step within the
computation.

8. Component diagram shows an encapsulated

class and its interfaces, ports, and internal
structure consisting of nested components and
connectors.
9. Deployment diagram shows the configuration
of run-time processing nodes and the
components that live on them.

UML – Architecture

 Architecture refers to the different

perspectives from which a complex system
can be viewed.

 The architecture of a software-intensive

system is best described by five interlocking
views:
– Use case view: system as seen by users,
analysts and testers.

– Design view: classes, interfaces and

collaborations that make up the system.

– Process view: active classes (threads).

– Implementation view: files that comprise the

system.
– Deployment view: nodes on which Software
resides.

Implementation
Design View
View

Use case
view

Process View Deployment

View
 UNIFIED PROCESS (UP)

The Unified Software Development

Process or Unified Process is a popular
iterative and incremental software
development process framework.

A software development process

describes an approach to building,
deploying, and possibly maintaining
software.

Overview

The Unified Process is not simply a process,

but rather an extensible framework which
should be customized for specific
organizations or projects.
 UP has the following major characteristics:
 It is use-case driven
 It is architecture-centric
 It is risk focused
 It is iterative and incremental

– Use case driven

– Use case driven means that use cases are

used as a primary artifact for establishing the
desired behavior of the system, for verifying
and validating the system's architecture, for
testing, and for communicating among the
stakeholders of the project.
– Architecture-centric

– Architecture-centric means that a system's

architecture is used as a primary artifact for
conceptualizing, constructing, managing,
and evolving the system under development.

– Risk focused

– Risk focused means that the project team

requires to focus on addressing the most
critical risks early in the project life cycle.
– Iterative and incremental

– An iterative process is one that involves

managing a stream of executable releases.
An is one that involves the continuous
integration of the system's architecture to
produce these releases, with each new
release embodying incremental
improvements over the other.

Project Lifecycle

The Unified Process divides the project into

four phases:

 Inception
 Elaboration
 Construction
 Transition
Inception :
Inception is the first phase of the process,
when the seed idea for the development is
brought up to the point of being at least
internally - sufficiently well-founded to
warrant entering into the elaboration phase.
Elaboration :
 Elaboration is the second phase of the
process, when the product vision and its
architecture are defined.

 In this phase, the system's requirements

are articulated, prioritized, and
baselined. A system's requirements may
range from general vision statements to
precise evaluation criteria, each
specifying particular functional or
nonfunctional behavior and each
providing a basis for testing.
Construction :
 Construction is the third phase of the
process, when the software is brought
from an executable architectural baseline
to being ready to be transitioned to the
user community.

 Here also, the system's requirements

and especially its evaluation criteria are
constantly reexamined against the
business needs of the project, and
resources are allocated as appropriate to
actively attack risks to the project.
Transition :
 Transition is the fourth phase of the
process, when the software is turned into
the hands of the user community.

 Rarely does the software development

process end here, for even during this
phase, the system is continuously
improved, bugs are eradicated, and
features that didn't make an earlier
release are added.
A stereotype is an extension of the
vocabulary of the UML, allowing to create
new kinds of building blocks similar to
existing ones but specific to problem.
Graphically, a stereotype is rendered as a
name enclosed by guillemets (<< >>) and
placed above the name of another element.
 Use case diagram

Use Case :-

 A use case is a description of the ways

in which a user interacts with a system or
product.
 A Use Case is a single unit of
meaningful work; for example login to
system, register with system and create
order are all Use Cases.
 Each Use Case has a description which
describes the functionality that will be
built in the proposed system.
 Use case diagram :-
 In the Unified Modeling Language (UML),
a use case diagram can summarize the
details of your system's users (also known
as actors) and their interactions with the
system.

 To build one, you'll use a set of

specialized symbols and connectors.

 An effective use case diagram can help

your team discuss and represent:

 Scenarios in which your system or

application interacts with people,
organizations, or external systems.
  Goals that your system or
application helps those entities
(known as actors) achieve.

 The scope of your system

Purpose of use case diagrams :

 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
Use case diagram components :-
1. Actors:

The users that interact with a system. An

actor can be a person, an organization, or
an outside system that interacts with your
application or system.

They must be external objects that produce

or consume data.

2. System:

A specific sequence of actions and

interactions between actors and the
system. A system may also be referred to
as a scenario.
3. Goals:

The end result of most use cases. A

successful diagram should describe the
activities and variants used to reach the
goal.

Use case diagram symbols and notation

1. Use cases:

 System function (process -

automated or manual)
 Named by verb + Noun (or Noun
Phrase).
 i.e. Do something
  Each Actor must be linked to a use
case, while some use cases may not
be linked to actors.

Name of
use case

2. Actors:

 Someone interacts with use case.

 Named by noun.
 Actor plays a role in the business
 Similar to the concept of user, but a user
can play different roles
 Actor triggers use case(s).
 Actor has a responsibility toward the
system (inputs), and Actor has
expectations from the system (outputs).

Actor
3. Associations:

 A relationship between actors and

use cases.

 In complex diagrams, it is important to

know which actors are associated with
which use cases.
4. System boundary boxes:

 A box that sets a system scope to use

cases.

 The system boundary is potentially

the entire system as defined in the
requirements document.

 All use cases outside the box would

be considered outside the scope of that
system.
System
5. Packages:

A UML shape that allows you to put

different elements into groups. Just as with
component diagrams, these groupings are
represented as file folders.
Use Case Diagram Relationships :-
There can be 5 relationship types in a use
case diagram.

 Association between actor and use case

 Generalization of an actor
 Extend
 Include
 Generalization of a use case

Association Between Actor and Use Case

It is the relationship between use case and
actor.
It is most common type of relationship in
use case diagram
Generalization of an Actor

 Generalization of an actor means that

one actor can inherit the role of the other
actor.

 The descendant inherits all the use cases

of the ancestor.

 The descendant has one or more use

cases that are specific to that role.
Extend Relationship

A extend relationship is a relationship to

specify that one use case extends the
behavior of another use case and adds more
functionality to the system.

Here are a few things to consider when using

the <<extend>> relationship.

 The extending use case is dependent

on the extended (base) use case.
 The extending use case is usually
optional and can be triggered
conditionally.
 The extended (base) use case must be
meaningful on its own.
Include Relationship
 An include relationship is a relationship in
which one use case (the base use case)
includes the functionality of another use
case (the inclusion use case).
 The include relationship supports the
reuse of functionality in a use-case model.
 Few things to consider when using the
<<include>> relationship.

 The base use case is incomplete

without the included use case.
 The included use case is mandatory
and not optional.
Generalization of a Use Case

 This is similar to the generalization of an

actor. The behavior of the ancestor is
inherited by the descendant.

 This is used when there is common

behavior between two use cases and also
specialized behavior specific to each use
case.

 For example, in the previous banking

example, there might be a use case
called “Pay Bills”. This can be generalized
to “Pay by Credit Card”, “Pay by Bank
Balance” etc.
Bank ATM Use Case Diagram Example
Online Shopping Use Case Diagram
Example
Use Case Diagram for Library
Management System
Use Case Diagram for Airline
Reservation System
Use Case Diagram for Hospital
Management System