OO Concepts, Principles, and Design

Chapters 19, 20, 21

Background and Derivation

Object oriented (OO) technology has its roots way back in the 60’s. E.g., Simula-67 programming language encapsulated the notion of an object and operations permissible on the data structures defined in the object.
Our real-world can be thought of as composed of objects, and operations permissible on those objects.

E.g., A house can be denoted by an object instance and the generic model of the house can be denoted by an object class.
A particular house (an instance) then, is a manifestation of the properties defined by the model (a class) -- that is, the properties are inheritted by the instance from its class.
In general, an instance may inherit properties from more than one class (eg., a child from both parents). This is called multiple inheritance.
Clearly, the idea of inheritance facilitates reuse. This leads to faster development and (in general) a proven quality.
When designing software system, you need to think in terms of functions and decomposition of functions (structures design).

The OO Paradigm (Sect. 19.1)

We know that software system evolves over time.
The idea of objects and the need for new object types and changes to inheritance properties and suggest the need for an evolutionary life-cycle development approach.
The OO process model (See fig. 19.1, pg 553) captures this quite well.

OO Concepts (Sect. 19.2)

There are Objects (eg., chair is an object).
There are object-types (or classes) (e.g., furniture is the type of the object chair).
A class has properties (or attributes) (eg., furniture has the attributes: cost, dimension, weight, location, colour, etc.)
An object (eg., chair) inherits all the attributes from its class (eg., furniture).
Every object(eg., chair) can be manipulated (eg., moved, bought/sold, etc.). That is, there are “operations” (also “services” or “methods”) that are permissable on a given object.
These operations are defined in the definition of the class (to which the object belongs).
E.g., The class furniture could have the operations: buy, sell, weigh, move
When a class has been defined, any new object of that class inherits all the attributes and operations of the class.
The operations manipulates the attributes defined in the class.
An object encapsulates the data, operations, and other related information (much like a module encapsulates data structures and related procedures/functions).
The term Object-Oriented (OO) implies:

Objects
Classification
Inheritance
Communication (amongst the objects)

An OO software system uses the above mentioned concepts to achieve the real-world objectives (requirements).
You can group similar classes into a superclass.

Furniture ------ Table

(Superclass) |------ Chair ------

| (Classes) |-- Many instances of chair

| |--

|------ Desk

Thus, you can have a hierarchy of classes (also called class hierarchy).
This is called a powerful abstraction mechanism facilitating reuse, evolution of software, specialisation, etc.

Identifying Classes (or Objects)

Look out for “nouns” in the description of the problem.
Objects can be:

External entities that produce (or consume) information for (or from) the system to be built (eg., other systems, devices, people, etc.).
Things that are part of the information domain for the problem (e.g., reports, messages, letters, signals, etc.)
Occurrences (or events) that occur within the context of the system operation. (eg., a property transfer, completion of some action, etc.).
Roles played by people in the use of the information system (eg., manager, engineer, slaesperson, etc.)
Organisational units thart are relevant to the application (eg., division, group, team).
Places that establishes the context of the problem and the overall function of the system
Structures that are part of the system (eg., sensors, vehicles, computers, printer, etc.).
Others?

Make sure not to mix up verbs & nouns as objects. (eg., “Car cleaning” is not an object. Car is the object and cleaning is the operation on the object).
Thus, keep data and operations separate.

Identifying Operations and Attributes

Once classes have been identified, we need to go into more detail for each class.

What are the key attributes of interest for a given class, relevent to the information system?

Eg., For the class “stack”, the type of data to be stacked/popped is important to know.

What are the key operations of interest for the given class?

Eg., For the class “stack”, push/pop operations (others: inquire, print, etc.) are inportant to know.
A class definition should encapsulate these attributes and operations.

Use Case (Sect. 20.4.1)

Based on the requirements gathered (see requirement engineering notes), the analyst/engineer can create a set of scenarios, each of which identifies a thread of usage for the system to be constructed.
Each scenario, called a Use case, describes how the system will be used
To create a use case, we need to identify different types of people (devices) that use the system

Identify specific roles they play

People/device playing a particular role is called an Actor.
Actors are identified (often in several iterations) after case review of the requirements
Use cases are then developed.

Class Responsibility – Collaborator (CRC) Modelling (Sect. 20.4.2)

Once usage scenarios have been developed we need to:

Identify candidate classes
Indicate their responsibilities (ie., attributes and operations)
Collaboration (ie., requests from clients of the (server) class in fullfillment of a client responsibility. A collaboration is the embodiement of the contract between the client and the server.

Leads to the definition of class interface & message passing.

Defining subjects & Subsystems (section 20.4.4)

Once classes have been identified using CRC modelling, class hierarchies can be built (see 20.4.3)
When a subset of classes collaborate among themselves to accomplish a set of cohesive responsibilities, they are often referred to as subjects (or subsystems)
Subject/subsystems are a form of abstraction over a set of classes.
A subsystem (treated like a black-box) has its own outside collaborators.

Defining Object-Relationship (Sect. 20.5)

Using CRC modelling, we need to identify (or define) those collaborators classes that help in achieving each responsibility of a given class. (Helps establish the “connection” between classes: relationships).
Relationship can be derived be examining verbs (or verb phrases) in the text (statement of scope) or use cases for the system.
Example: Verbs may intricate:

Location or placement: next to, part of, contianed in….
Communications: transmit to, aquires from …..
Ownership: incorporated by, is composed of….
Satisfaction of a condition: manages, coordinates, controls….

The Object Behavior Model (Sect. 20.6)

The CRC model and the object-relationship model represents static elements of OO analysis.
We also need to analyse the dynamic behavior of the OO system.
We thus must model the system in terms of external events and state transitions.
The Object state table captures the essence of a behavior model.

OO Analysis (Sect. 20.1.2)

There are various approaches, although ovelapping in many ways, to OO specific OOA techniques include:

The Booch Method
The Coad + Yourdon Method
The Jackobson Method
The Rambaugh Method
The Wurfs-Brock Method
….
The “Uncle Tom Cobly” Method

However, during OOA the developer should perform the following generic steps: (see 20.1.2 at the end).

Obtain customer requirements

Identify scenarios or use cases
Build a requirements model

Select classes & objects using requirements as a guide
Identify attributes & operations for each system object.
Define structures & hierarchies that organise classes.
Build an object-relationship model
Build an object-behaviour model
Review the OO analysis model against use cases/scenarios.

OO Design (OOD)

We need to map the OOA model onto an object-oriented design (OOD) model.

OOA|OOD

------|------

Class | Objects

Attributes | Data Structures

Methods/Operation | Algorithms

Relationship | Message Passing

Behavior | Control

(See fig. 21.4)

OOA to OOD Process

(differs from the book: fig. 21.3)

OO Analysis ------ OO Design

/ \

Subsystem Object

Design Design

(Sect. 21.3) Steps

Partition OOA into subsystems (Goto * ODD Steps Sect. for additional info.)
Identify concurrency (if any in the problem)
Allocate subsystems to machine processors & operating System tasks
Choose Strategies for implmenting data management
Identify global resources, & control mechanisms to access data.
Design control flow mechanism for the system
Consider boundary conditions
Review trade-offs

*ODD Steps

Also for each subsystem:

Identify intersubsystem communications
Break down subsystem further , as appropriate
Do object design (see Sect. 21.4):

A Protocol Description:

Establish interface of an object (ie., messages it can receive)
Establish related operations performed when a message is received.

An implementation description:

Show implementation details of each operation (ie., data structures that describe the attributes of the object, and the procedural details of the methods)

OO Product Aspects

During the OOD process the following key product aspects should be considered: (Sect. 21.2)

Problem Domain: The subsystem that are responsible for implementing customer requirements directly.
Human Interactions: The subsystems that implement the user interface.
Task Management: The subsystems that are responsible for controlling and coordinating concurrent tasks.
Data Management: The subsystem that is responsible for the storage and retrieval of objects.