Object Oriented Software Engineering

Unit 2
 Object Oriented Methodologies

 Rambough’s method
Booch’s method
 Jacobso’s use cases
Rumbaugh’s Object Modeling Technique
Object - (object modeling technique) was developed
in the late 1980s at the general electric research and
development.
Rumbaugh’s OMT describes the method for the
analysis, design and implementation of system using
an object oriented technique.
OMT consist of four phases, which can b performed
iteratively:
 Analysis
 System Design
 Object Design
 Implementation
OMT MODELS
 OMT separates modeling in to three different
parts:

 Object Model
 dynamic Model
 functional Model
OMT Object Model

Describes the static structure of the objects in the

system and their relationships.

 The object model is represented graphically with an

Object Diagrams.

The object diagrams contains classes interconnected

by an association lines.
Object Diagram
OMT Dynamic Model
Dynamic Model: It represent those aspect of a
system that are concerned with time and changes.
Event : An event is something that happens at a
point in time.
State: A state is an abstraction of the attribute
value and link of an object.
State Diagram: A sate diagram is a network of
states and events.
State Diagram
OMT Functional Model
It describes those aspects of a system concerned with
transformations of values.
It specifies the result of a computation without
specifying how or when they are computed.

Data Flow Diagrams : describes the data

transformation of the system.
DFD uses four primary symbols:
1. Process:
2. Data Flow:
3. Data Store:
4. External Entity:
DFD of the ATM System
Booch Methodology
This methodology was developed by G. Booch in the
early 1980’s.
It is a widely used object oriented method that helps
you design your system using the object paradigm.
Booch method consist of following diagrams:
 Class Diagrams
 Object Diagrams
 State Transition Diagrams
 Module Diagrams
 Process Diagrams
 Interaction Diagrams
Diagrams of Booch method
 Class diagrams-
Describe roles and responsibilities of objects.
 Object diagrams
Describe the desired behavior of the system in terms of
scenarios.
 State transition diagrams
State of a class based on a stimulus.
 Module diagrams
Map out where each class & object should be declared.
 Process diagrams
To determine to which processor to allocate a process.
 Interaction diagrams
Describes behavior of the system in terms of scenarios.
Object Modelling
Booch method prescribes:

Macro Development Process

Micro Development Process

Macro Development Process
Controlling framework for the micro process.
Primary concern-technical management of the system.
Steps for macro development process
1. Conceptualization
2. Analysis & Development of the model
3. Design or create the system architecture
4. Evolution or implementation
5. Maintenance
Micro Development Process
Each macro process has its own micro development
process
Steps:
 Identify classes & objects
 Identify class & objects semantics
 Identify class & object relationship
 Identify class & objects interface and implementation
JACOBSON METHODOLOGIES
Use Cases.
Object Oriented Software Engineering.
Object Oriented Business Engineering.
Use Cases
 Understanding system requirements
 Interaction between Users and Systems
 The use case description must contain:-

 How and when the use case begins and ends.

 The Interaction between the use case and its actors,
including when the interaction occurs and what is
exchanged.
 How and when the use case will need data stored in the
system.
 Exception to the flow of events
 How and when concepts of the problem domain are
handled.
OOSE
Object Oriented Software Engineering.
Objectory is built models
Use case model
Domain object model
Analysis object model
Implementation model
Test model
OOBE
Object Oriented Business Engineering
OOBE is object modeling at the enterprise level.
Analysis phase
Design and Implementation phase
Testing phase
E.g. Unit testing, integration and system testing.
PATTERNS
It is an instructive information that captures the
essential structure and insight of a successful family of
proven solutions to a recurring problem that arises
within a certain context and system of forces.
Good Pattern will do the following
It solves a problem.
It is a proven concept.
The Solution is not obvious.
It describes a relationship.
The pattern has a significant human component.
Patterns

Patterns

Generative Patterns Non Generative Patterns

(describe recurring phenomena (describe recurring phenomena
with saying how to without saying how to
reproduce them) reproduce them)
Patterns Template
Essential Components should be clearly
recognizable on reading a pattern:
Name
Problem
Context
Forces
Solution
Examples
Resulting context
Rationale
Related Patterns
Known uses
Frameworks
Way of delivering application development patterns to
support best practice sharing during application
development.

Can be viewed as the implementation of a system of

design patterns.
Benefits of Frameworks
Reusability
Modularity
Extensibility
Inversion of Control
Difference between Patterns and
Frameworks
Design patterns are more abstract than frameworks.
Design patterns are smaller architectural elements than
frameworks.
Design patterns are less specialized than frameworks.
Unified Approach
Layered Approach
Model
 An abstract representation of a system.
 Types of model
1. Use case model
2. Domain model
3. Analysis object model
4. Implementation model
5. Test model
Model
 Types of model
1. Use case model  defines the outside (actors) &
inside (use case) of the system’s behavior.
2. Domain model  maps real world objects into the
domain object model.
3. Analysis object model  how source code should be
carried out & written.
4. Implementation model represents the
implementation of the system.
5. Test model  test plans, specifications & reports.
 Model
 Model is an iterative process.
 It can represent static or dynamic situations.
 Model

Static Dynamic

Provides a system’s Represents a system’s behaviors

parameters at rest or at a that, taken together, reflect its
specific point in time. behavior over time.

(e.g.) class diagram (e.g.) interaction & activity diagrams

What is Unified Modeling Language
(UML)?
The UML is a graphical / standard language for
visualizing, specifying, constructing & documenting
the software system and its components.
UML Diagrams
1. Class diagram
2. Use case diagram
3. Sequence diagram Interaction
diagram
4. Collaboration diagram behavior
diagram
5. State chart diagram
6. Activity diagram
7. Component diagram Implementation
8. Deployment diagram diagram
1. Class diagram
 Class  a set of objects that share the same
attributes, operations & relationships.
 It represented by a compartmentalized rectangle.
 It shows the structure of your software.
 3 compartments
1. Top
2. Middle
3. Bottom
1. Class diagram
1. Top  shows class name
2. Middle  shows class attributes
3. Bottom  shows class operation

Class name

Class properties

List of Operation
Class Interface Notation

It describes externally visible behavior of class.

A class that requires the operations in the interface
may be attached to the circle by a dashed arrow.
Role Name
A role name is one end of Association.

employer employee
Company Person
Works-for
Qualifier
OR Association
Association class
An association class is an association that also has an
association properties.
N-Ary Association
Aggregation and Composition
 Aggregation is a form of association.
 A hollow diamond is attached to the end of the path.

 Composition is a form of aggregation to represent

the component of a complex object.
 Also referred to as a part-whole relationship.
 1 1
Car
1 1
4 4,10 2,5 1
Wheel Light Door Engine

Composition

Generalization
 It is a relationship between a general class and a specific class.
 It is displayed as a directed line with a closed,hollow arrowhead
at the superclass end.
Generalization
Use Case Diagram
• A use case diagram corresponds to a sequence of
transactions in which each transaction is invoked
from outside the system(actors).
• It engages internal objects to interact with one
another and with the system’s surroundings.
• Use cases represent specific flows of events in the
system.
• A use-case diagram is a graph of actors,a set of use
cases enclosed by a system boundary,associations
between the actors and the use cases.
 A Use-Case Diagram
Help Desk

Make a call

Take the call

Operator

Client
Do Research

Return a call Support

Representative
Three representations of an actor:

<<actor>> <<actor>>
Customer Customer

Customer
Relationships in a use case diagram:
• Communication: It is shown by connecting the actor
symbol to the use case symbol with a solid path.

• Uses: It is shown by a generalization arrow from the use

case.It reuses common behavior in different use cases.

• Extends:It is used when you have one use case that is

similar to another use case but does a bit more. It is like
a subclass.
 Interaction Diagrams
• Interaction diagrams are diagrams that describe
how groups of objects collaborate to get the job
done.
• There are two kinds of interaction models:
 Sequence diagrams
 Collaboration diagrams
4.Sequence Diagram
 It shows an interaction arranged in a time sequence.
 It has 2Ds.
1. Vertical dimensions  represents time
2. Horizontal dimensions  represents different objects.
 Vertical line is called the object’s life line.
 Life line  the existence object at a particular time.
 Objects are shown at the top.
 The object role is shown as a vertical dashed line, the
life line.
Contd..

Exchang
Caller Receiver Talk
e
OffHook
DialTone
DialNumber
RingTone
OffHook
OnHook
Collaboration Diagram
Caller Message

1:OffHook 2:DialTone 3:DialNumber

Exchang
e
4:RingTone

Receiver
5:OffHook
6:OnHook

Talk
 State Chart Diagram
It shows the sequence of states.
A state is represented as a rounded box, which may
contain one or more compartments.
Name compartment  holds the name of the state.
Internal transition compartment  list of actions /
activities

Idle
Lift receiver and
get dial tone
 State Chart Diagram
Dialing

digit(n)
 Activity Diagram
An activity diagram is a special case of a state machine
in which states are activities representing the
performance of operations and transitions are triggered
by the completion of the operations.

It shows the flow of events with our system & what is
going on inside a use case.

We draw the activity diagram for each & every use
case.
An activity is shown as a round box, containing the
name of the operation.

When an operation symbol appears within an

activity diagram it indicates the execution of the
operation.

An outgoing solid arrow attached to an activity

symbol indicates a transition triggered by the
completion of the activity.
A start state is represented by a solid circle.
A state transition shows what activity follows after
another.
It is represented by a solid line with an arrow.

A synchronization bar allows you to show concurrent

threads in a work flow of a use case.
It represented by a thick horizontal or vertical line.
A decision is a point in an activity diagram where
guard conditions are used to indicate different
possible transitions.

It is represented by a diamond.

Actions may be organized into swimlanes.

Each swimlane represents responsibility for part of
the overall activity.
 Prepare incoming
documents

Index documents
Synchronization bar
Make electronic file
Complete request

Check data for Draw up contract

life insurance Mortgage-deed

Calculate data for Draw up insurance

Construction Mortgage policy

Pay provision to
insurance agent
3.Activity Diagram – Login Use case

Custom er Enters
the login details

Sys tem retrives

the details

System validates
the cus tom er

[ False ]
Sys tem prompts to
reenter
[ True ]

System welcomes
the cus tom er
 Implementation Diagrams
Implementation diagrams show the implementation
phase of systems development such as the source code
structure and the run-time implementation structure.
There are two types of implementation diagrams :
(i)Component Diagrams:which show the structure of
the code itself.
(ii)Deployment Diagrams:which show the structure of
the run –time system.
 Component Diagrams
Component Diagrams model the physical components
(such as source code,user interface) in a design.

Another way of looking at components is the concept

of packages.

A package is used to show how you can group

together classes.
Component Diagram
Updat
Access e

UI
 Deployment Diagram
It shows the configuration of run time processing
elements & the software components, processes &
objects that live in them.

It is a graph of nodes connected by communication

association.

Components are connected to other components by

dashed-arrow dependencies usually through interfaces.
Deployment diagram
 Package
A package is a grouping of model elements.
Packages themselves may contain other packages.
A package is represented as a folder shown as a large
rectangle with a tab attached to its upper left corner.
Model dependency represents a situation in which a
change to the target element may require a change to
the source element in the dependency, thus indicating
the relationship between two or more model elements.
Package
Grade Note
Book
Package and its dependencies
Customer
Business
Model

Clients Bank

Accounts

Checking Saving