Smalltalk and Object Orientation: an Introduction - Free

16.4 Object Oriented Analysis
We shall first consider the Object Oriented Analysis Approach (known as OOA) of Coad and Yourdon
[Coad and Yourdon 1991]. This is because the identification of objects and classes is a crucial task in
OO analysis and de sign, however, many techniques ignore this issue. For example, both the Booch
method and OMT do not deal with this issue at all. They indicate that it is a highly creative process
which can be based on the identification of nouns and verbs in an informal verbal description of the
problem domain! A different approach is to use a method such as OOA as the first part of the design
process and then to use some other OOD method for the later parts of the process.
OOA is aimed at helping designers identify the requirements of their software in detail - rather than
how the software should be structured or implemented. It therefore aims to describe the existing
system, how it operates and how the software system should interact with it. One of the claims of OOA
is that it helps the designer to package the requirements of the system in an appropriate manner (for
object oriented systems?) and helps to reduce the risk of the software failing to meet the customer’s
requirements. In effect, OOA helps to build the Obj ect (systems) Model which we will look at in more
detail when we look at OMT.
There are five activities within OOA. These act as the framework used to direct the analyst during
the analysis process. They are:
1. Finding classes and objects. This activity aims to identify the objects (and the classes of objects)
in the domain.
2. Identifying structures (amongst those classes and objects). Here structures relate to relationships
such as is a as well as part of.
3. Identifying subjects. In essence subjects indicate related objects.
4. Defining attributes. These are the data elements of the objects.
5. Defining services. These are the active parts of objects and indicate what the object does.
These are not five steps (as steps implies a sequential ordering to the activities). Instead, as information
becomes available, the analyst performs the appropriate activity. The intention is that the analyst can
work in whatever way the domain expert finds easiest for them to express their knowledge. Thus the
analyst may drop down deeper into one activity than the others as the domain expert provides greater
information on that area. Equally, the analyst may jump around between activities identifying classes
one minute and services the next.
16.5 The Booch method
The Booch method (also known as just Booch and Object Oriented Development or confusingly OOD)
is one of the earliest recognizable object oriented design methods. It was first described in a paper
published in 1986 [Booch 1986] but has becom e widely adopted since the publication of the book
describing the method [Booch 1991] and the more recent second edition [Booch 1994].
The Booch method provides a step by step guide to the design of an object oriented system.
Although Booch's books do dis cuss the analysis phase, they do so in too little detail, compared to the
design phase.
16.5.1 The steps in the Booch method
The major steps in the Booch method are the identification of objects and their classes, identification of
the semantics of classes and ob jects, identification of the relationships between classes and objects and
the implementation of the classes and objects. Each of these steps is briefly outlined below:
Identification of classes and objects . This involves analyzing the problem domain an d the system
requirements to identify the set of classes required. This is not trivial and relies on a suitable
requirements analysis.
Identification of the semantics of classes and objects . This step involves identifying the services
offered by an objec t as well as those required of an object. A service is essentially a function
performed by an object (it is therefore during this step that the overall system functionality is
132