Course: Software Engineering

Unit-V

Object Oriented Analysis & UML

Dr. Arpita Sharma

Assistant Professor
Department of Computer Science & Engineering
SKIT, Jaipur
Software Engineering
Syllabus

2
Unit-V
Object Oriented Analysis:
•Object Oriented Analysis Modeling,
•Data modeling.
Object Oriented Design:
•OOD concepts,
•Class and object relationships,
•object modularization,
Introduction to Unified Modeling Language
3
 Course: Software Engineering

Unit-V
(Lecture: 1)

Object-Oriented Software Engineering (OOSE) :

Concepts and Process Model

Dr. Arpita Sharma

Assistant Professor
Department of Computer Science & Engineering
SKIT, Jaipur
 Contents
OBJECT-ORIENTED CONCEPTS
DIFFERENCE BETWEEN STRUCTURED AND OO APPROACHES
IDENTIFYING THE ELEMENTS OF AN OBJECT MODEL
THE OO PROCESS MODEL
MANAGEMENT OF OBJECT-ORIENTED SOFTWARE PROJECTS
 OBJECT-ORIENTED CONCEPTS
• A class encapsulates the data/attributes and the
operations/methods/services that manipulate them
• Attributes in the class are enclosed by the “wall” of
operations
• This achieves information hiding
• Classes are cohesive
• Class is decoupled from other elements of a system
• Reduces the impact of side effects caused by
change
• All of these lead to high quality software.
 OBJECT-ORIENTED CONCEPTS: INHERITANCE
The class hierarchy can be searched to determine if a class higher in the
hierarchy contains any required attributes and operations.
The class can then be inherited from the higher class
Additions may be done, if required.
The class may be built from scratch, if inheritance cannot be used
 OBJECT-ORIENTED CONCEPTS: Messages

❖ Messages are the means by which objects interact

❖ Message: [destination, operation, parameters]
❖ Destination defines the receiver object
❖ Operation refers to the operation that has to be performed by the object
❖ Parameters are the information required for the operation to be executed
❖ The receiver object executes the operation and then returns the control to
the caller
DIFFERENCE BETWEEN STRUCTURED AND OO APPROACHES
Structured Approach Object Oriented Approach
A Top-down approach. A Bottom-up approach.
Program is divided into submodules or functions. Program is organized in classes and objects.
Function call is used. Message passing is used.
More suitable for offshore development It is suitable for in-house development.
It shows clear transition from design to Not so clear transition from design to
implementation. implementation.
Projects can be managed easily due to clearly Projects may be difficult to manage due to
identifiable phases uncertain transitions between phases
Suitable for: real time system and embedded Suitable for: business applications, game
system development projects, which are expected to
customize or extended.
Data Flow Diagram (DFD) & Entity Relationship Class diagram, sequence diagram, state chart
Diafgram (ERD) are used for modeling diagram, use cases all contribute.
 IDENTIFYING THE ELEMENTS OF AN OBJECT MODEL
External entities (e.g., other systems, devices, people)
reports, displays, letters etc.
Occurrences or events (e.g., a property transfer or the completion of a series
of robot movements)
Roles (e.g., manager, engineer, salesperson)
Organizational units (e.g., division, group, team)
Structures (e.g., sensors, computers or other hardware) that define a class of
objects
THE OO PROCESS MODEL
 THE OO PROCESS MODEL
Spiral
Customer communication- the problem domain is defined and that basic problem classes
are identified
Planning and Risk analysis
Construction:
❖ Reuse is emphasized, classes are “looked up” in a library of existing OO classes
❖ If class cannot be found it is built
• object-oriented analysis (OOA
• object-oriented design (OOD)
• object-oriented programming (OOP)
• object-oriented testing (OOT)
❖ The new class is then put into the library so that it may be reused in the future
Release
Customer Evaluation
 MANAGEMENT OF OBJECT-ORIENTED SOFTWARE PROJECTS
Iterative
Do analysis to isolate major problem classes and connections.
Determine whether the classes and connections can be implemented
Extract reusable objects (if available), build a rough prototype and conduct
tests to uncover errors
Get customer feedback on the prototype
Refine the design to accommodate changes
Code objects (that are not available from the library)
 Course: Software Engineering

Unit-V
(Lecture: 2)

Object-Oriented Analysis (OOA)

Kailash Soni
Associate Professor
Department of Computer Science & Engineering
SKIT, Jaipur
 Contents
Introduction

OOA Methods

Steps for OOA

A Unified Approach to OOA

OOA Model Components

Domain Analysis

Class-Responsibility-Collaborator (CRC) Modeling

Object Behavior Model

 Introduction
OOA is used to:
Define all classes that are relevant to the problem to be solved
The operations and attributes associated with the class
The relationships between the classes

A number of tasks are performed:

• Requirements must be communicated between the client and the developer
• Classes, attributes and methods must be identified
• A class hierarchy must be specified
• Object-to-object relationships should be represented
• Object behavior must be modeled
• Repeat tasks 1 through 5 iteratively until the model is complete
 OOA Methods
The Booch method
A ‘Micro’ and ‘Macro’ development process
In micro level, a set of analysis tasks are defined that are applied for each step in the macro
process
An evolutionary approach
❖ Identifies classes and objects
❖ Identifies relationships among classes and objects
❖ Conducts refinement
 OOA Methods contd..
Rumbaugh method or the object modeling technique (OMT)
• three models are created
• object model (a representation of objects, classes, hierarchies, and relationships)
• dynamic model (a representation of system behavior)
• functional model (representation of information flow through the system)

The Coad and Yourdon method.

• Identify objects
• Define attributes
• Define services
• Define a whole/part structure
• Identify subsystem components
 OOA Methods contd..
The Wirfs-Brock method
• No clear distinction between analysis and design tasks
• A continuous process
• Evaluates the customer specification
• Extract candidate classes from the specification
• Group classes to identify super-classes
• Build hierarchical representations of classes
• Assign responsibilities to each class
• Identify relationships between classes
• Define collaboration between classes based on responsibilities
• Construct a collaboration graph for the system

The Jacobson method

Lays emphasis on the use-case i.e. scenarios and how user interacts with the system
 Steps for OOA
1. Elicit customer requirements for the system.
2. Identify scenarios or use-cases.
3. Select classes and objects using basic requirements
4. Identify attributes and operations for each object
5. Define structures and hierarchies to organize classes
6. Build an object-relationship model
7. Build an object-behavior model.
8. Review the OO analysis model against use-cases or scenarios
 Unified Approach to OOA
Booch, Rumbaugh and Jacobson combined the best features of their individual
object-oriented analysis and design methods into the Unified Modeling Language (UML)

In UML, a system is represented using five different “views” or perspectives

❖ User model view
❖ Structural model view
❖ Behavioral model view
❖ Implementation model view
❖ Environment model view
 OOA Model Components
Static view of classes
Static view of attributes
Static view of relationships
Static view of behaviors
Dynamic view of communication
Dynamic view of control and time
 Domain Analysis
Software domain analysis is the identification, analysis, and specification of common
requirements from a specific application domain, typically for reuse on multiple projects
within that application domain

Input and Output for Domain Analysis

[Pressman, Roger S. Software engineering: a practitioner's approach. Palgrave macmillan, 2005.]

 Domain Analysis contd…

Activities:

❖Define the domain to be investigated

❖ Categorize the items extracted from the domain

❖ Collect a representative sample of applications in the domain

❖ Analyze each of the application

❖ Develop an analysis model for the objects

 Class-Responsibility-Collaborator (CRC) Modeling
CRC modeling is a simple means for identifying and organizing the classes that are relevant
to system or product requirements
A CRC model is a collection of standard index cards that represent classes.
The cards are divided into three sections.
On the top of the card is the name of the class
In the body of the card class responsibilities are listed on the left and the collaborators on
the right
A responsibility is anything the class knows or does
Collaborators are those classes that are required to provide a class with the information
needed to complete a responsibility
 CRC Index Card

[Pressman, Roger S. Software engineering: a practitioner's approach. Palgrave macmillan, 2005.]

 OBJECT-BEHAVIOR MODEL
The object-behavior model indicates how an OO system will respond to external
events or stimuli
Steps to create the model:
1. Evaluate all use-cases to fully understand the sequence of interaction within
the system.
2. Identify events that drive the interaction sequence
3. Create an event trace for each use-case
4. Build a state transition diagram for the system
5. Review the model to verify accuracy and consistency
 Course: Software Engineering

Unit-V
(Lecture: 3)

Object Oriented Design (OOD)

Kailash Soni
Associate Professor
Department of Computer Science & Engineering
SKIT, Jaipur
 Contents
•Introduction
•Analysis
•Design
•Characteristics of OOD
•Layers of Object-Oriented Design
 Introduction
•OOA: we find and describe objects or concepts in the problem
domain

•OOD: we define how these software objects collaborate to meet

the requirements.

•OOP: Implementation: we implement the design objects in, say,

Java, C++, C#, etc.
 Analysis
•Investigate the problem and the requirements

•What is needed?

•Required functions

•Investigate domain objects

 Design
•Conceptual solution that meets requirements.

•Not an implementation

•Describe a database schema and software objects

•Avoid the CRUD activities and commonly understood functionality

•Design assumes a robust requirements analysis has taken place

 Object-Oriented Design
One cannot design a solution if the requirements are not understood

One cannot implement the design if the design is faulty

OOD must describe the

❖specific data organization of attributes

❖procedural detail of each individual operation

 Characteristics of OOD
•Objects are abstractions of real-world or system entities
•Objects are independent and encapsulate state and representation
information.
•System functionality is expressed in terms of object services
•Objects communicate by message passing
•Objects may be distributed and may execute sequentially or in
parallel
 Steps for OOD
1. Describe each subsystem and allocate it to processors and tasks.
2. Choose a design strategy for implementing data management, interface support,
and task management.
3. Design an appropriate control mechanism for the system.
4. Perform object design by creating a procedural representation for each operation
and data structures for class attributes.
5. Perform message design using collaborations between objects and object
relationships.
6. Create the messaging model.
7. Review the design model and iterate as required
 Design Modeling Components
• Representation of hierarchy of modules.
• Definition of classes.
• Specification of data definitions.
• Assignment of operations to classes.
• Detailed definition of operations.
• Indication of end-to-end processing sequences.
• Representation of object states and transitions.
 Layers of Object-Oriented Design
The subsystem layer contains a
representation of each of the subsystems
and supporting hardware
The class and object layer contains
❖ the class hierarchies
❖ representations of each object
The message layer contains the design
details that enable each object to
communicate with its collaborators.
The responsibilities layer contains the The OO Design
data structure of attributes and algorithmic [R. S. Pressman,Pyramid
Software Engineering A Practitioner’s
Approach, 5th ed. New York: Mc Graw Hill, 2001.}
design of operations for each object.
 Translating an OOA model into an OOD
model
• Each element of the conventional analysis model maps into one or more layers of
the design model.

[R. S. Pressman, Software Engineering A Practitioner’s Approach, 5th ed. New York: Mc Graw Hill, 2001.}
 Process flow for OOD

[R. S. Pressman, Software Engineering A Practitioner’s Approach, 5th ed. New York: Mc Graw Hill, 2001.}
 Task and Resource Management
• The characteristics of the task are determined
• The priority and criticality of the task must also be determined
• High-priority tasks must have immediate access to system resources
• High-criticality tasks must continue to operate even if resource
availability is reduced or the system is operating in a degraded state
• A variety of different resources are available to an OO system like
external entities (e.g., disk drive, processor, or communication line) or
abstractions (e.g., database, object)
 Unified Approach to OOD
• Booch, Rumbaugh and Jacobson combined the best features of their
individual object-oriented analysis and design methods into the
Unified Modeling Language (UML)

• UML is organized into two major design activities: system design and
object design

• In terms of object-oriented development, the conceptual architecture

is concerned with:
❖ the structure of the static class model
❖ the connections between components of the model
 Examples of Design Models
• Sub-system models that show logical groupings of objects into coherent
subsystems
• Sequence models that show the sequence of object interactions
• State machine models that show how individual objects change their state
in response to events
• Other models include use-case models, aggregation models, generalisation
models etc.
Employee Object class (UML)
 Course: Software Engineering

Unit-V
(Lecture: 4)

Unified Modeling Language (UML) - I

Kailash Soni
Associate Professor
Department of Computer Science & Engineering
SKIT, Jaipur
 Contents

Introduction

Why use UML?

UML Diagrams

Use Case Diagram

Class Diagram
 Introduction

• Unified Modeling Language

• Based on work from Booch, Rumbaugh and Jacobson

• It is a industry-standard graphical modeling language for

specifying, visualizing, constructing and documenting
the artifacts of software systems

• Independent of implementation language

 Why use UML?

• Increase understanding/communication of product to customers

and developers
• Uses graphical notation to communicate
• Support for diverse application areas
• UML is not dependent on any one language or technology.
• Help acquire an overall view of a system.
UML Diagrams

• Use Case Diagrams

• Class Diagrams
• Activity Diagrams
• Sequence Diagrams
• Collaboration Diagrams
• State Transition Diagrams
• Component Diagrams
• Deployment Diagrams
Use Case
A use case represents a functionality provided by the system
Used during requirements elicitation
It has participating actors:
❖ User
❖ External system
❖ Physical environment
Passenger
 Use Case Diagrams
A use case consists of:
• Unique name
PurchaseTicket
• Participating actors
• Entry conditions
• Flow of events
• Exit conditions
• Special requirements
• System boundary

Passenger

Association: communication between an actor and

PurchaseTicket a use case; Represented by a solid line.
 Use Case Diagram: Example
Name: Purchase ticket Event flow:
1. Passenger selects the
Participating actor: Passenger destination
2. Distributor displays the amount
due.
Entry condition:
3. Passenger inserts money, of at
• Passenger standing in front least the amount due.
of ticket distributor.
4. Distributor returns change.
• Passenger has sufficient
money to purchase ticket. 5. Distributor issues ticket.

Exit condition:
• Passenger has ticket.
 The <<extends>> Relationship
• <<extends>> relationships
represent exceptional cases.
Passenge
r
• The direction of a
<<extends>> relationship is
to the extended use case
PurchaseTicket

<<extends>>

<<extends>>
<<extends>> TimeOu
OutOfOrder
t
<<extends>>

Cance NoChang
l e
 The <<includes>> Relationship
Passenger
• <<includes>>
PurchaseTicket <<extends>> relationship represents
behavior that is factored
<<extends>> Purchase out of the use case for
MultiCard
reuse, not because it is an
Purchase exception.
Single Ticket
<<includes>> • The direction of a
<<includes>>
<<includes>>
relationship is to the
using use case
CollectMone
y <<extends>>
<<extends>>

NoChange Cance
l
Use Cases are useful to…

• Determining requirements
• Communicating with clients and developers
• Generating test cases
Class Diagrams
• Gives an overview of a system by showing its classes and the
relationships among them.
• Also shows attributes and operations of each class
• Detailed class diagrams are used for developers

• A class is a rectangle divided into three parts

• Class name
• Class attributes (i.e. data members, variables)
• Class operations (i.e. methods)

• Modifiers
• Private: -
• Public: +
• Protected: #
 Name
Account_Name
- Customer_Name
- Balance Attributes

+addFunds( ) Operations
+withDraw( )
+transfer( )
 OO Relationships

• There are two kinds of Relationships

• Generalization (parent-child relationship)

• Association (student enrolls in course)

• Associations can be further classified as

• Aggregation
• Composition
 OO Relationships: Generalization
Supertype Example:

Customer

Subtype1 Subtype2 Regular Loyalty

Customer Customer

- Generalization expresses
or: Customer
a parent/child
relationship among
related classes.
Regular Loyalty
Customer Customer
OO Relationships: Association
• Represent relationship between instances of classes
• Student enrolls in a course
• Courses have students
• Courses have exams
• Etc.

Student 1 * course
 OO Relationships: Composition
Whole Class
Class W

Class P1 Class P2

Part Classes
Expresses a relationship among
instances of related classes.
Example
It is a specific kind of
Automobile Whole-Part relationship.

Transmissio
Engine
n
OO Relationships: Aggregation
Container Class Expresses a relationship among instances of
Class C
related classes. It is a specific kind of
Container-Containee relationship.
AGGREGATION
It is an appropriate relationship where the
Container and its Containees can be
Class E1 Class E2 manipulated independently.

Containee Classes

Example
Bag

Apples Milk
 Cardinality and Modality

* 4
Students Course
have enrolls

Cardinality refers to the maximum

number of times an instance in one entity

Multiplicity can be associated with instances in the

Symbol Meaning related entity while Modality refers to the
1 One and only one minimum number...
0..1 Zero or one
M..N From M to N (natural language)
* From zero to any positive integer
0..* From zero to any positive integer
1..* From one to any positive integer
UML Class Example

UML Diagrams
 Course: Software Engineering

Unit-V
(Lecture: 5)

Unified Modeling Language (UML) - II

Kailash Soni
Associate Professor
Department of Computer Science & Engineering
SKIT, Jaipur
 Contents

• Activity Diagrams
• Sequence Diagrams
• Collaboration Diagrams
• State Transition Diagrams
• Package Diagram
• Component Diagrams
• Deployment Diagrams
 Activity Diagram
• Displays the flow of activities involved in a single process
OR
Refers to the steps involved in the execution of a use case

Start

Join End
Fork
 Sample Activity Diagram
Ordering System
 Activity Diagram with Swimlanes

• Partition the activity states into groups called swimlanes

• Each swimlane represents a business organization responsible for those activities

• Use solid lines to partition

• Every activity belongs to exactly one swimlane

• Transitions may cross swimlanes

Sample Activity Diagram with Swimlanes
Sequence Diagram

Ref: https://www.slideshare.net/sunilkumar710/online-shopping-cart-system-file
 Collaboration Diagram

Ref:
https://www.slideshare.net/sunilkumar710/online-shoppi
 State Diagram
Shows the possible states of the object and the transitions that cause a change in state

Notation
• States are rounded rectangles
• Transitions are arrows from one state to another.
• Events or conditions that trigger transitions are written beside the arrows
• Initial and Final States indicated by circles as in the Activity Diagram
• Final state terminates the action; may have multiple final states
 State Diagram

Ref: https://www.slideshare.net/sunilkumar710/online-shopping-cart-system-file
 Package Diagram

• Package diagram is used to simplify complex class diagrams

• Group classes into packages
• Packages appear as rectangles with small tabs at the top.
• The package name is on the tab or inside the rectangle.
• The dotted arrows are dependencies.
• One package depends on another if changes in the other could possibly force
changes in the first.
 Package Diagram

Ref:
 Component Diagram

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

• Physical aspects are the elements such as executables, libraries, files, documents, etc.
• Component diagrams are used to visualize the organization and relationships among
components in a system.

Ref: https://www.tutorialspoint.com/uml/uml_component_diagram.htm
Component Diagram

Ref: http://docshare02.docshare.tips/files/23568/235682525.pdf
 Deployment Diagram

• Used to visualize the topology of the physical components of a system, where the
software components are deployed.
• Used to describe the static deployment view of a system
• Shows how the components are deployed in hardware.
Deployment Diagram
Software design is divided into:
- Function OD (divide and conquer method)-DFD
- OOD- UML
THANKS