Chapter 4: Object-Oriented Method

Object-Oriented Method

4.1 Introduction to Object-Oriented Method

The object-oriented design methods include architecture-driven, incremental, and iterative approaches. They differ from the traditional waterfall model by adopting a spiral model approach. This reflects the incremental nature of object-oriented development, with blurred lines between analysis, design, and implementation.

Some organizations use an evolutionary development approach, delivering system functions in small steps and revising plans based on user feedback. This has proven successful for fully embracing organizations, leading to earlier business benefits.

Object-Oriented Methodology

The object-oriented methodology defines a method to develop an application, software, or system. The process involves:

1. Analysis: Understanding user requirements.

2. Design: Creating an application model with added details.

3. Implementation: Translating the model into a system using programming languages, databases, or hardware.

This process aims to be seamless, preventing information loss during transitions between stages.

Definition

Object-Oriented Methodology is a set of:

• Methods

• Models

• Rules

for developing a system. Modeling conceptualizes and communicates ideas precisely and unambiguously.

Object Oriented Methodologies

• Rumbaugh et al. method (OMT): Suited for describing the object model (static structure) and dynamic model of the system.

• Jacobson et al. method: Good for producing user-driven analysis models.

• Booch method: Produces detailed object-oriented design models.

Object-Oriented Methodology Stages

• System Conception

• Analysis

• System Design

• Class Design

• Implementation

System Conception

System conception begins with an individual who identifies a business requirement and understands blooming technology. This person proposes an application idea and discusses it with developers. The developer then:

• Understands the application requirements.

• Lists necessary features.

• Estimates the cost.

The cost must justify the need for the application. The system concept evolves to model the conception into a working application.

Analysis

Requirement statements can be incomplete, vague, or incorrect. The software analyst:

• Determines the overall application scope.

• Identifies who the application is for.

• Determines the problems the application will solve and when, where, and why it is needed.

• Defines the application workflow.

Further, the application model identifies the objects within the system, such as executing transactions or displaying balances. The analysis phase focuses on planning and deciding what to build.

System Design

In system design:

• Developers use modeling languages to represent different system parts.

• Each part is modeled separately.

• System elements, like architecture, components, interfaces, and data, are designed and organized for easy development.

Further steps include:

• Preparing system performance estimates and feasibility studies.

• Creating error handling policies and optimizing performance characteristics.

• Developing a strategy for assigning subsystems to hardware.

• Designing the software control strategy.

Class Design

The class designer elaborates on the analysis model and adds details. Class design defines classes and their relationships, and selects algorithms for operations.

Implementation

The implementation phase translates classes and relationships into programming language code, connects it to a database, and assigns it to hardware. Programmers apply good engineering practices to ensure code traceability and reusability.

Wrap Up

The object-oriented methodology outlines a system development life cycle, with developers using stages to develop each part of the system.

4.2 Object-Oriented Analysis (Coad-Yourdon)

OOA is the analysis model used to describe system functionalities. It is a popular approach for designing and analyzing applications, businesses, or systems using object-oriented programming.

Peter Coad and Edward Yourdon, in 1991, presented a step-by-step method for developing object-oriented models, using "subjects" to analyze and model complex problem domains.

A subject is a group of related classes & objects represented as a single entity to simplify the model. Typically, a subject represents the top level of a gen-spec or a whole-part class tree. Subject diagrams provide a top-level view to guide programmers through detailed class diagrams for each subject area.

Coad and Yourdon’s OOA

• Reflects the view that defining objects and attributes captures the essential building blocks of information systems.

• It is a unifying approach, as analysis and design benefit from this approach.

• Applications are developed using object-oriented programming languages and CASE (Computer Aided Software Engineering).

• Leads to consistency.

Why do we need Object Oriented Analysis?

1. Tackle more challenging problem domains.

2. Improve analyst and problem domain expert interaction.

3. Increase the internal consistency of analysis results.

4. Explicitly represent commonality.

5. Build specifications resilient to change.

6. Reuse analysis results.

7. Provide a consistent underlying representation for analysis.

Five major activities of OOA / Coad and Yourdon's OOA steps

1. Finding Class & Objects

2. Identifying Structures

3. Identifying Subjects

4. Defining Attributes

5. Defining Services

[1] Finding Class & Objects

Classes & objects are identified within a problem domain and within the context of a system's responsibilities.

Where to look?

1. Observe first-hand

2. Actively listen to problem domain experts

3. Check previous OOA results

4. Check other systems

5. Prototype

6. Read, Read, Read

[2] Identifying Structures

Overall structures of the system are identified by two terms:

1. Generalization and Specialization (Gen-Spec) Structure: Captures the inheritance hierarchy among identified classes.

2. Whole-Part Structure: Models how an object is part of another object and how objects are grouped into larger categories.

NOTATION-Identifying Structures

$Whole$

$Generalization$

$1m$

$1m$

$Specialization 1$ $Specialization 2$

$Part1$ $Part2$

Figure: Gen-Spec Structure notation and Whole-Part Structure notation

[3] Identifying Subjects

• Identifying subjects is done by partitioning the Class & Objects model into larger units.

• Subjects are groups of Class & Objects.

• Subjects are defined after identifying system's structures.

NOTATION-Identifying Subjects

$1. Subject1$
$2. Subject2$

$1. Subject$
Class-&-Object
Class-&-Object2
$2. Subject2$
Class-&-Object3
Class-&-Object4

Figure: Subject notation, collapsed
Figure Subject notation, partially expanded

[4] Defining Attributes

Defining attributes is done by identifying information and associations that should be associated with each and every instance.

NOTATION-Defining Attributes

Class-&-Object
$Attribute1$
$Attribute2$

Figure: Attribute notation

$Class$
Class-&-Object1
$Attribute1$
$Attribute2$
$1m$
Class-&-Object2

Figure: Instance Connection notation

[5] Defining Services

Defining services means defining the operation of the classes, this is done by identifying the object states and defining services such as create, access, connect, display and so on.

How the objects communicate with messages is identified using message connections.

NOTATION-Defining Services

Class-&-Object
$Service1$
$Service2$

Figure: Service notation

$Sender$
$Receiver$
$Class$
$Service1$
$Service2$

Figure: Message Connection notation

Strategy - Defining Services

1. Identifying Object States

2. Identify the required Services

3. Identify the Message Connections

4. Specify the Services$eg. Radar.SerachAirSpace()$

5. Put the OOA documentation set together

Example

Real Time Airlift System (RTAS)

[1] Finding Class & Objects

$Mission$
$AircraftFailure$
$FightSegment$
$Aircraft$
$AirborneltemTrajectory$
$Shipmentitem$
$Airbomeltem$
$Radar$
$Cargoltem$
$Passenger$

Figure: Real-Time Airlift System-Class-&-Object layer

[2] Identifying Structures

$Mission$
$AircraftFailure$
$Aircraft$
$AirbornellemTrajectory$
$FightSegment$
$Shipmentitem$
$Airbomeltem$
$Radar$
$Cargotern$
$Passenger$

Figure: Real-Time Airlift System-Class-&-Object and Structure layers

[3] Identifying Subjects

$1. Mission$
$2. Airlift$

$Aircraf$
$Fightlegmant$
$Arorat$

Figure: Real-Time Airlift System-Subject layer

$Cargote$
$Passenger$
$Automat$
$Artenber$
$Fader$

Figure: Real-Time Airlift System- Subject, Class-&-Object, and Structure layers

[4] Defining Attributes

$Newfa$
$Coatin$
$About$

$Fighdayment$
$Cature$

$Capacity$
$Destine$
$Natibe$

$Caryotum$
$Perger$

Figure: Real-Time Airlift System- Subject, Class-&-Object, Structure, and Attribute layers

[5] Defining Services

$FlighTagmart$
$Art$

Figure: Real-Time Airlift System- Subject, Class-&-Object, Structure, and Service layers

OOA Multilayer Model

Object Oriented Analysis can be presented in five layers:

1. Subject Layer

2. Class & Object Layer

3. Structure Layer

4. Attribute Layer

5. Service Layer

$Subject layer$
Class-&-Object layer
$Structure layer$
$Attribute layer$
$Service layer$

Figure: Depicting human interaction: a preferred approach

4.3 Object-Oriented Design (Booch)

• Also known as Booch methodology.

• The Booch method is a method for object-oriented software development.

• It is composed of an object modeling language, an iterative object-oriented development process, and a set of recommended practices.

• The method was authored by Grady Booch when he was working for Rational Software (acquired by IBM), published in 1992 and revised in 1994.

• It was widely used in software engineering for object-oriented analysis and design and benefited from ample documentation and support tools.

Booch Methodology

It is a widely used object oriented method that helps us design our system using the object paradigm.

• It covers the analysis and design phases of an object oriented system.

• We start with class & object diagrams in analysis phase and refine these diagrams in various steps.

The Booch method consists of the following diagrams:

• Class diagrams,

• Object diagrams,

• State Transition diagrams,

• Module diagrams

• Process diagrams,

• Interaction programs.

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
  to 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

Diagrams

Booch notation for class diagram

$1$
$Class A$
$L$
$L$
$L$
$Class P$
$Class D$
$r$
$) Class B$
$0..n$
$го$
$L$
$Class G$
$Class P$
$W$
$D$
$1$
$Class C$
$Ја$

$Abstract Class$
$Association$
$Inherits$
$Aggregation$
$Uses$

Abstract classes

• Abstract classes are used to represent general concepts (for example, Shape, Animal), which can be used as base classes for concrete classes (for example, Circle, Dog).

• No objects of an abstract class can be created (except for base sub-objects of a class derived from it) and no non-static data members whose type is an abstract class can be declared.

• In C++, abstract class is class which contains at least one pure virtual function.

Diagrams of Booch method.

Class diagrams

describe roles and
responsibilities of
objects

$Order$

$Association$

$dateRecived Date$
$Customer$

$isPrepaid: Boolean$

$name: String$

$number String$

$price:Money$

$address: String$

$creditRating$
$dispatch$
$close$

Object diagrams describe

the desired behavior of the
system in terms of
scenarios

$Mutiplicity$
$Many-valued Mandatory$

State transition diagrams

state of a class based on a stimulus

$Operator TurnOfAlarm$

$Enabled$
$SoundAlarm$
$Silenced$
$Sounding$
$SilenceAlarm$
$Enable$
$Disable$
$AlarmFixed$
$Disabled$

Process diagrams

to determine to which processor to
allocate a process

$Submit Claim$
$more$
$More Input$
$Evaluate$
$Reject$
$Accept$
$Pay$
$Archive$
$Closed$

Module diagrams

to map out where
each class & object
should be declared

$inovasolutions payrollmodule$
$EntryPoint$
$payroll$
$service$

$Component$

$payroll$
$service$
$component 2$

$Component$

$PayrollData$
$service$
$component$

$Warehousing<br>and despatch$
$Customer$
Ordering
& CRM
$ExternalService$
$TaxRateRules$
$Stock Control$
$Document<br>Management$
$Management<br>Information$
$Purchasing$
$Finance$
$Tasks and<br>Manufacturing Workflow$

Interaction diagrams

describes behavior of the
system in terms of scenarios

$getThe$
$Animaler$
$display$
$left: Car$
$getfraneforTime)$
$evejdelta-1)$

$RaceView$
$daclay)$

$right: Car$
$eNewPositionslet, dist)$
$Positionslet, dist$

$get Throttle$
$getxo$
$t: Track$
$getvo$
$tvo$
$Theta$
$theta)$
$: GasPedal$

Booch method prescribes:

• Macro Development Process

• Micro Development Process

The Macro Development process

• The macro process serves as a controlling framework for micro process & its main concern is technical management of system.

• It consists of following steps:

• Conceptualization: Core requirements, goal of system & Prototype to prove the concept.

• Analysis & development of model: Class, object & interaction diagrams for roles & responses

• Design/create sys., architecture: Schedules for multiple processes on each relevant processor

• Evolution or implementation: Refine through iterations and a stream of s/w implementations

• Maintenance: Make localized changes to system to add new requirements & eliminate bugs

Object modeling using Booch notation.

$Car$
$color$
$manufacturer$
$superclass$
$cost$

$inherits$
$Ford$
$inherits$
$Mustang$
$Taurus$
$Escort$

The arrows represent specialization; for example, class Taurus is subclass of the class Ford.

An alarm class state transition diagram with Booch notation.

$Enabled$
$Silenced$
$SoundAlarm$
$Operator::TurnOffAlarm$
$Sounding$
$Silence Alarm$
$Enable$
$Disable$
$Disabled$
$AlarmFixed$

This diagram can capture the state of a class based on a stimulus. For example, a stimulus causes the class to perform some processing, followed by a transition to another state. In this case, the alarm silenced state can be changed to alarm sounding state and vice versa.

The Micro Development process

It is a description of the day-to-day activities by a single or small group of s/w developers which could look blurry to an outside viewer as analysis & design phases are not clearly defined.

• 1. Identify classes and objects

• 2. Identify class and object semantics.

• 3. Identify class & object relationships,

• 4. Identify class & object interfaces & implementation.

BOOCH NOTATIONS For CLASS

O
Vehicle
constructor()
Register()
GetRego()

Class Icon

name
attributes
operations

BOOCH NOTATIONS

O
double
Stud Rec
constructor
GetName
GetIDO
GetMark
string
length
operator ()
int

BOOCH NOTATIONS for CLASS INHERITANCE

O
Vehicle
constructor()
Register
GetRego()
Car
constructor()
Register
GetDescription

Abstract Class Adornment and Class Relationship Icons

association
name
inheritance
attributes
operations
has
_ using

Aggregation

Temperature
Controller
Aggregation
_
Heater

Weather Monitoring System Architecture

LCDDevice
Keypad
Input
Manager
Display
Manager
Wind
Direction
Sensor
WindSpeed.
Sensor
Sampler
TimeDate
Sensors
Timer
Pressure
Sensor
Humidity
Sensor
DewPoint
WindChill
Temperature
Sensor

4.4 Hierarchical object-oriented design (HOOD)

• It is a method of hierarchical decomposition of the design into software units based on identification of objects, classes and operations reflecting problem domain entities.

• It is intended for the Architectural Design, Detailed Design and coding for software to be developed in programming languages such as C++.

• It was developed by European Space Agency (ESA).

• The hierarchy described in HOOD takes two forms:

  • Uses: dependence of one object on another’s services

  • Functional decomposition: object split into child objects, to give functionality of the parent objects.

HOOD theory

• Combination of data structures and functionality

  • Object-oriented (OO) design was first used with OO programming (e.g. Smalltalk)

  • Based on concept of objects, classes and inheritance: OO = Objects + Classes + Inheritance

HOOD - The Basic Design Step

The main process in HOOD is called the Basic Design Step.

"A Basic Design Step has as its goal the identification of child objects of a given parent object, and of their individual relationships to other existing objects, or the refinement of a terminal object to the level of the code. This process is based on the identification of objects by means of object-oriented design techniques"

HOOD - The Basic Design Step

A basic design step process is further split into four phases, thus defining a micro life-cycle for a design step: -

1. Problem definition
   .
   Statement of the problem
   Analysis and structuring of requirement data

2. Development of solution strategy

3. Formalization of the strategy

• Object identification.

• Operation identification.

• Grouping objects and operations (object operation table).

• Graphical description.

• Justification of design decisions.

1. Formalization of the solution

HOOD - The Basic Design Step

Phase 1
Problem definition
Phase 2
Development of
solution strategy
Phase 3
Formalization of the
strategy
Phase 4
Formalization of the
solution

Phase 1: Problem Definition

The context of the object to be designed is stated, with the goal of organizing and structuring the data from the requirement analysis phase. This is an opportunity to provide a completeness check on requirements and traceability to design.

1. Statement of the problem - the designer states the problem in correct sentences which provides:

• a clear and precise definition of the problem;

• the context of the system to design.

1. Analysis and structuring of requirement data the designer gathers and analyses all the information relevant to the problem, including the environment of the system to be designed.

HOOD - The Basic Design Step

Phase 1
Problem definition
Phase 2
Development of
solution strategy
Phase 3
Formalization of the
strategy
Phase 4
Formalization of the
solution

Phase 2: Development of solution strategy

The outline solution of the problem stated above is described in terms of objects at a high level of abstraction.

HOOD - The Basic Design Step

Phase 1
Problem definition
Phase 2
Development of
solution strategy
Phase 3
Formalization of the
strategy
Phase 4
Formalization of the
solution

Phase 3: Formalization of the strategy

The objects and their associated operations are defined. A HOOD diagram of the proposed design solution is produced, allowing easy visualization of the concepts and further formalization. There are five sub phases in the formalization of the strategy:

1. Object identification.

2. Operation identification.

3. Grouping objects and operations (object operation table).

4. Graphical description.

5. Justification of design decisions.

HOOD - The Basic Design Step

Phase 1
Problem definition
Phase 2
Development of
solution strategy
Phase 3
Formalization of the
strategy
Phase 4
Formalization of the
solution

Phase 4: Formalization of the solution

The solution is formalized through:

• formal definition of provided object interfaces.

• formal description of object and operation control structures.

HOOD Representation

Object_name
provided
interface
provided
environment
internals
operations
required interface
used
objects

Example:

A
Parent_object
Child 1
op. 1
Oper_11
Oper_2-
Oper_3-
Child 2
op.2
Child 3
op.3

Hierarchical relationship between two object classes.

SUBCLASS
SUPERCLASS

HOOD - Notation

The main diagram used for describing the structure of a system. is the HOOD object diagram, which shows a static view of the structure in the hierarchical object oriented design. The symbols used are as follows:

Class/Object Name
External
Internal
Operations
Details
A HOOD graphical
class/object
Use Relationship
Include Relationship

HOOD - Diagram for a Company

Company
Person
name
address
name
national_insurance_no
works_for Hire address
Worker
Manager
Chare_time
Earn_salary
manages
Fire phone
product
Department
Works on
project
Project_name
Budget
priority
Responsible for
Product
Product_name
weight
Component
Optional_extras
Manu-
factures

4.5 Object-Oriented Techniques (OMT)

• It is an object modeling approach for software modeling and designing.

• It was developed around 1991 by Rumbaugh, Blaha, Premerlani, Eddy and Lorensen .
  Or, OMT was developed by James Rambaugh.

• OMT describes object model or static structure of the system.

• It is real world based modeling approach for software modeling and designing.

• It was developed basically as a method to develop object-oriented systems and to support object-oriented programming.

• Object Modeling Technique is easy to draw and use.

• It is used in many applications like telecommunication, transportation, compilers etc.

• It is also used in many real world problems.

• OMT is one of the most popular object oriented development techniques used now-a-days.

Purpose of Object Modeling Technique

• To test physical entity before construction of them.

• To make communication easier with the customers.

• To present information in an alternative way i.e. visualization.

• To reduce the complexity of software.

• To solve the real world problems.

OMT’s Models:

• There are three main types of models that has been proposed by OMT:

  • Object Model: Object Model encompasses the principles of abstraction, encapsulation, modularity, hierarchy, typing, concurrency and persistence. Object Model basically emphasizes on the object and class. Main concepts related with Object Model are classes and their association with attributes. Predefined relationships in object model are aggregation and generalization (multiple inheritance).

  • Dynamic Model: Dynamic Model involves states, events and state diagram (transition diagram) on the model. Main concepts related with Dynamic Model are states, transition between states and events to trigger the transitions. Predefined relationships in object model are aggregation (concurrency) and generalization.

  • Functional Model: Functional Model focuses on the how data is flowing, where data is stored and different processes. Main concepts involved in Functional Model are data, data flow, data store, process and actors. Functional Model in OMT describes the whole processes and actions with the help of data flow diagram (DFD).

Phases of Object Modeling Technique:

• Analysis

• System design

• Object design

• Implementation

OMT has the following phases:

• Analysis: This the first phase of the object modeling technique. This phase involves the preparation of precise and correct modelling of the real world problems. Analysis phase starts with setting a goal i.e. finding the problem statement. Problem statement is further divided into above discussed three models i.e. object, dynamic and functional model.

• System Design: This is the second phase of the object modeling technique and it comes after the analysis phase. It determines all system architecture, concurrent tasks and data storage. High level architecture of the system is designed during this phase.

• Object Design: Object design is the third phase of the object modelling technique and after system design is over, this phase comes. Object design phase is concerned with classification of objects into different classes and about attributes and necessary operations needed. Different issues related with generalization and aggregation are checked.

• Implementation: This is the last phase of the object modeling technique. It is all about converting prepared design into the software. Design phase is translated into the Implementation phase.

OMT Stages and Models:

Functional Model
(dataflow diagrams)
Data value transformations
Dynamic Model
(state diagrams)
Control aspects of the system
Object Model
Static structure of objects and their relationships
(object diagram)
Analysis
- Model of real-world situation
- What?
System Design
- Overall architecture (sub-systems)
Object Design
- Refinement of Design
- Algorithms/data structures to
implement each class
Implementation
- Translation of object classes and
relationships to a particular
object-oriented language
time
System

4.6 Responsibility Driven Design (RDD)

• It is a design technique in object-oriented programming, which improves encapsulation by using the client–server model.

• It focuses on the contract by considering the actions that the object is responsible for and the information that the object shares.

• RDD is the influential object-oriented design method that presents an effective way to turn requirements into object-oriented software.

• It was proposed by Rebecca Wirfs-Brock and Brian Wilkerson.

• Developed as Rebecca Wirfs-Brock
  One of object-oriented design techniques, driven by
  an emphasis on behavior at all levels of development
  A design technique that has the following properties:

• Can deal with ambiguous and incomplete specifications

• Naturally flows from Analysis to Solution

• Easily integrates with various aspects of software development

Building blocks of RDD

• Role: A collection of related responsibilities

• Responsibility: An obligation to do (some task/behavior) or know something (some data)

• Collaboration: An interaction of objects or roles (or both)

RDD involved:

• describing the actions and activities for which our software is responsible

• describing the responsibilities in terms that both users and developers can understand

• designing software objects that implement those responsibilities

RDD is not a sequential process

• We will present the technique in stages but, in practice, you may use the steps in different ways for each iteration of your design process

Steps in RDD

• Software components

• Formalize interfaces
  Designing and representations

• Implementing components

• Integration of components

• Maintenance and evolution

Responsibility-Driven Design Principles

• Maximize Abstraction
  Initially hide the distinction between data and behavior.
  Think of objects responsibilities for "knowing", "doing",
  and "deciding"

• Distribute Behavior
  Promote a delegated control architecture
  Make objects smart-have them behave intelligently, not
  just hold bundles of data

• Preserve Flexibility
  Design objects so interior details can be readily changed
  Responsibility-Driven Design Constructs
  an application = a set of interacting objects
  an object = an implementation of one or more roles
  a role = a set of related responsibilities
  a responsibility = an obligation to perform a task or know
  information
  a collaboration = an interaction of objects or roles (or
  both)
  a contract = an agreement outlining the terms of a
  collaboration

What Is A Collaboration Model?

How a group of objects work together to fulfill a specific task
It includes a description of objects, what each does, and how they interact
We use CRC cards to record each object's responsibilities and collaborations and sequence
diagrams to show interactions
Data-Driven Design Responsibility-Driven
Approach Design Approach
centralized control delegated control
controllers coordinators
inherited attributes inherited behavior
many low-level fewer, higher-level
messages messages
lots of simplistic a few smart objects that
information holders blend role stereotypes