1. http://burks.bton.ac.uk/burks/pcinfo/progdocs/oocourse/ooc/obj14/lesson14.htm
Object oriented analysis and design
Object modelling is useful for designing computer systems, whether those systems are to
be implemented in object-oriented languages or not. Most designs are likely to need more
than an object-oriented language, such as a database.
Object modelling also has a use outside of the design of computer systems. It is an
excellent analysis method, and it can be used in business process reengineering, in social
science research, or any complex environment where it is important to capture the
structure and functionality of some world.
Why Design?
Even the most professional programmers feel the temptation to sit down and produce
code at the earliest possible moment. Therein lie many of the ills of the software
engineering industry. Design is a process which involves
• communication
• creativity
• negotiation
• agreement
It is a human process, to produce products for human consumption. Too often the
communication, negotiation and agreement aspects are left out.
Object modelling provides a notation which is clear, consistent, and which can be used to
communicate within a software development team, and with the clients and other third-
parties which the team need to deal with.
Design methods
Traditionally systems were constructed using the waterfall method. This was based on the
idea that clients would formally agree a requirements document. A design would then be
put together, which would be further agreed. Then the system would be implemented, and
then there would be an endless process of maintenance.
Modern ideas move away from this. Iterative methods are considered more appropriate
for many system development approaches. This still follows the notion of analysis,
design and implementation, but on a cyclical basis, where subsequent cycles build on
earlier cycles.
Objects

2. We begin at the beginning. The world is made of objects. Just open your eyes and ears.
They are out there. Bank customers, students, cats, elephants, cars, balls of string, atoms,
molecules, tubs of ice cream, Madonna, stars, bureaucrats, Robin Hood. The world is
built of objects. Objects are built of smaller objects, and so ad infinitum. Objects combine
to make bigger objects. We already live in an object-oriented world.
The first thing an object analyst must do is to remove the scales from his or her eyes.
Object modelling consists of looking for objects. Of course, there has to be some
boundary. Even sitting at ones desk one can see more objects than one could reasonably
list. But that is where the beauty of object modelling comes in. It uses observation.
Objects can be described by their attributes and operations. Attributes are the changeable
characteristics of an object. Cats have colour, size and weight. Operations are the things
an object does or can have done to it. Cats can catch mice, eat, miaow, worm up to
owners, and be stroked. In our notation we draw an object such as a cat like this.
The name is shown at the top. The attributes are listed underneath. The operations are
listed below that. Actually, strictly speaking, this is a class diagram. But we will explain
that later.
In an object model, all data is stored as attributes of some object. The attributes of an
object are manipulated by the operations. The only way of getting at the attributes is
through an operation. Attributes may sometimes be objects in their own right (more of
that later).
In an object model, all functionality is defined by operations. Objects may use each
others operations, but the only legal way one object can manipulate another object is
through an operation. An operation may inform, say "mass of ball", or change the state of
an object, say "throw ball".
Object modelling is about finding objects, their attributes and their operations, and tying
them together in an object model. Nothing more. Here are some more objects:

3. Do not be constrained to be those dull systems that most software engineers drag out.
Object modelling can be used to design lots of things. The trick comes in knowing what
objects are appropriate, and what their appropriate attributes and operations are.
Remember entity-relationship models having a notion of entity. These are really objects.
All we are doing in object modelling is relabelling entity modelling. However, we put the
emphasis on capturing and grouping together both functions and data (operations and
attributes in our terminology). That is the elegant simplicity of object modelling. object
models look remarkably like entity-relationship models.
We will now look one powerful way of arranging objects - inheritance hierarchies.
Inheritance
Often we will find that there are objects which have something in common. It is then
useful to create an abstract object which groups together the common features, and to use
inheritance to define the original objects.

4. Designing complex class hierarchies takes time and good design requires experience. But
the basic principles outlined above, with some intuitive guidelines, are the basis for the
design of good, re-usable designs.
Re-use can be viewed from two directions. Components can be re-used, which is a sort of
bottom-up approach to re-use. Or designs can be re-used. Both elements are important in
the production of re-usable software.
Experience shows that describing things using hierarchies is an easy and comprehensive
way of communicating both structure and functionality.
Relationships and Object Models
Aggregation
We can make up objects our of other objects. This is known as aggregation. The
behaviour of the bigger object is defined by the behaviour of its component parts,
separately and in conjunction with each other. Here is a simple example of a juggler:

5. A juggler has two hands and two feet. He or she uses hands to catch, drop, pick up and
throw a ball, and perhaps from time to time scratch his or her head. He or she may also
kick a ball with his or her foot.
By analysing our juggler object and breaking it down into component objects, we now
have a better understanding of our object.
The diamond in the diagram indicates that one object is made up of another object. The
numbers are indicative of how many. Now the behaviour of a juggler is entirely defined
by the behaviour of his or her hands and feet. Of course, real jugglers are made of quite a
bit more, but for the purposes of considering their juggling skills we can focus on just the
bits of them that are involved in juggling.
Hands and feet could be broken down into their constituent parts, say palms and fingers,
soles and toes. However, that does not seem to help us to understand juggling, so the
decomposition above is probably enough.
One of the important analysis and design tools we have is the break-down of complex
objects into their constituent parts. It provides a meaningful and sensible decomposition,
and it provides scope for re-use of components. Further, the constituent components are
often easier to design than large, complex components - this is the thesis on which the
early ideas of structured programming were based.
Delegation
The behaviour of an object which is made up of other objects is usually defined by the
behaviour of the smaller objects. For example

6. To start a car, you start the engine. Thus the start operation on the car involves calling the
start operation on the engine. This is known as delegation. The engine then will switch on
the ignition system, switch on the starter motor then switch off the starter motor. This is
further delegation. To stop the car, there will be a call to stop the engine, which in turn
will make a further call to switch off the ignition.
You may read elsewhere about the benefits of multiple inheritance. Most of the features
of multiple inheritance can be simulated using delegation, with safer consequences.
Relationships
Objects can be related in other ways than by inheritance and aggregation. Any
relationship between real world objects can be modelled: cats eat canaries, dogs bite
postmen, the woodcutter murders the wolf, cars run over little old ladies, employees work
for organisations, patients visit hospitals, patients stay in hospitals.
One to one relationships
In a one-to-one relationship, one object is associated with exactly one of its related
objects. This is modelled by a straight line drawn between the objects. If the relationship
is one-way, then an arrow is used to indicate the direction. The line can be labelled.

7. One to many relationships
Sometimes one object can be related to many objects. This is indicated by different marks
at the end of the line.
A player plays for one football team. There are at least 11 players for a given football
team. Football teams do not play for players.
Many to many relationships
Sometimes objects at either end of a relationship may be related to many objects at the
other end.
A lubricant is recommended for at least one engine. An engine has at least one lubricant
recommended for it.
Analysis - the rudiments of an approach
The first reaction to any project with any complexity is "how do we get started?". Where
do you begin? The starting point for object-oriented analysis is to identify candidate
objects and their relationships. In fact, this is the be-all and end-all of object-oriented
analysis.
The first stage can be a simple brain-storming of the possible objects. One method is to
go through all the nouns in any documentation about the world you are analysing, and
considering these as candidate objects
Removing synonyms and/or generalising
The first stage is to try and group together items which are either just different names for
the same thing, or whether there is a common generalisation

8. Look for attributes
Attributes are themselves objects, but with trivial behaviour - essentially all you do is
record their value. Considering the above list
Irrelevant objects
Sometimes an object is irrelevant because of what you are designing the system for.
The process of development
The approach to development recommended here is an iterative one. It involves repeated
refinement of the object model. The process needs to be controlled by an appropriate
project management process, involving reviews and checkpointing.
There are a variety of techniques for driving this cycle.
Prototyping
Evolutionary development

9. Why object modelling lends itself to iterative methods
The problem with traditional systems developments has been that notations differ in each
of the phases of development. There is then a translation problem and consistency
problem at each phase transition. Consequently changes upstream have always been
resisted.
Object modelling uses the same notation for both analysis and design, and if object-
oriented languages and databases are used, the notation persists through to
implementation. Design is essentially a fleshing out of the analysis, by further refining
and adding detail to the objects produced by the analysis, and by adding new objects, say
for the purposes of providing interfaces.
Object modelling, by using a consistent notation in each phase, results in more productive
CASE tools, which can generate the code outlines for the implementation.
Dynamic Modelling
Dynamic modelling tries to capture how objects behave and how they interact. In this
way, we can find new operations, attributes and relationships for the object model.
Dynamic models are perhaps the most effective way of uncovering the behaviour of
systems.
Event traces - building scenarios
As we were going to tread dynamic modelling as a form of plot construction for stories,
let us begin by looking at a trace of events
Progressing the analysis with event traces
At first it can be a little disconcerting to approach problem-solving in this way. Where is
the flow of control? This seems too simple. The answer is that we eat a banquet one
mouthful at a time. We climb mountains one step at a time. Great floods arrive in
raindrops. There is no wisdom in trying to do everything at once.
What do you do with the event traces?
As you develop an event trace you will find the following:
• There are objects missing from your object model - so add them.
• There are operations missing from your object model - so add them
• There may be attributes you have overlooked - so add them

10. • Perhaps there are objects and operations which you thought at first were
appropriate, but now look unused - so remove them.
This follows the philosophy that everything in object modelling is to do with expanding
the object model.
Dynamic modelling - state diagrams
Initial states are represented by a black blob. Intermediate states are represented by
round-cornered boxes. Final states are represented by bulls-eyes. Events are represented
by arrows with labels giving a name. An event usually corresponds to an operation in the
object model.
Basically any system which you can reasonably model on a computer jumps from state to
state. Even those apparently continuous games are made up of objects which change their
state very quickly.
An example of an object model for a simple computer
Let us look at the example of designing a computer. Of course, one is unlikely to be
asked to design a computer this way, but it is an interesting way of exploring the method
so far using a relatively complicated application that computer scientists are familiar
with. Our first notions of a computer might be:

11. Object Modelling with Activity Models
Activities are logically arranged groups of events. Dynamic modelling, through event traces, is one way of
linking events to objects, thereby defining object behaviour and identifying new objects. Activities can be
used in a similar way to identify operations on objects. This can be done by simply producing a matrix; a
simplified example from the PLANEC application is illustrated below. This is for the ARRANGE
RESOURCES activity. PROVIDER, FUNDER and RESOURCE are three of the candidate objects for the
PLANEC system.
A similar cross-referencing process can be used to identify attributes.
Functional modelling - data flows
Data flow modelling is a common component of many software engineering methodologies in. It is
exceptionally useful for analysing and describing systems where there is a large amount of calculation

12. involved. However within the object modelling community it seems to be losing ground in favour of other
techniques - object interaction diagrams can cover most of the needs met by data flow diagrams. They tend
to be less effective and more arbitrary in producing designs. They are included here for completeness.
Data flow models consist a of a number of processes which exchange information. A process transforms
information it receives and passes the transformed information on to other processes or to objects in the
system. Data flow models can be used to uncover new operations and new attributes for the object model.
Sometimes new objects can be discovered too.
Processes are drawn as bubbles, with the name of the process written inside. Arrowhead lines are used to
connect processes to each other and to objects in the system. The lines are labelled with the information
that is being passed. Objects are drawn as rectangular boxes, just as in the object model, but usually with
just the name of these objects and not the attributes and operations.
Let us look at a simple example.
The next stage is to devise operations and attributes to support the calculations. From the above we can
probably deduce the following attributes and operations for the Customer, Invoice, Sales and Product
objects - of course there will be more attributes and operations derived from other techniques or other data
flow diagrams.
Use Cases
One of the most fundamental problems in software engineering is determining the
requirements of a system. The notion of use-cases, introduced by Jacobson is an excellent
approach. It complements the activity modelling approach developed by Lunn described
earlier in the course, and has wider application.
The use-case approach requires the analyst to determine all the potential actors involved
in a system. Actors are external to the system and make use of it. An actor is typically a

13. person, but may be a third-party organisation or another computer system. One person
may in fact be multiple actors, say a shop assistant may be a customer of the same shop at
another time. We model actors, not individuals.
An actor makes use of a system in different ways. Each of these ways is known as a use-
case. A use-case may involve a number of actors, just as an individual actor may make
use of several use-cases. We draw little stick men to represent actors and ovals to
represent use-cases. In a banking system where a customer can withdraw money, we
would draw:
Of course, to withdraw money, a customer must have put money in, so there is at least
one more use-case.
Now it might be that the system which is being implemented in the bank needs to involve
a cashier for depositing, but that to withdraw money the customer has to use the cash
machine. The cashier is then an actor.

14. And so we build our model of the ways the system is used. We might add two more use-
cases of the bank system.
Here is a simple use-case model for a computer:

15. Programmers are distinguished from ordinary users of the computer by the fact that they
compile and edit programs as well as running them (for testing) and printing files. Edit
and compile use-cases make use of the run-program use case (editors and compilers
being just programs to be run).
Use-cases are simple to describe to potential users of the system, and therefore should be
used in the dialogue as part of requirements analysis.