Experience shows that describing things using hierarchies is an easy and comprehensive way of communicating both structure and functionality.

Summary of this lesson

• Objects are a natural way of representing things.

• Objects are described by their attributes and their operations.

• Objects can be organised in inheritance hierarchies.

Exercises

1. Describe two of the following objects in terms of their attributes and operations: motor car, sheep, kite, hospital, elephant, garden, school, bacon, teddy bear, bank customer, bus.

2. Devise a simple inheritance hierarchy for two of the following: geometry, sports teams, politicians, rodents, viral infections, restaurants.

Object Lesson 2 - 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. You will have met a similar idea in program decomposition. Here is a simple example of a juggler:

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. Also, we have discovered two new operations, scratch head and kick.

The diamond in the diagram indicates that one object is made up of another object. The numbers are indicative of how many - more will be said about this shortly. 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.

Let us look at another example.

A car engine lubricant is made up of a number of base oils blended with an additive package. The additive package consists of one or more detergents to keep engine surfaces clean, one or more dispersants to suspend particles in the oil to be carried to the filter, one or more anti-oxidants to slow up the thermal decay of the oil, and a viscosity improver to control the viscosity of the oil at different temperatures. A research scientist will experiment with different oils by running engines containing the oils and analysing the effect of the engines on the oils.

Let us look at another example.

For the purposes of assessing the care provision for someone, it is necessary to know their assets, any disabilities they have, any disease they have, any carers they have. Assets are made up of liquid assets, such as cash in the bank, and non-liquid assets such as their home. Carers may be family carers or care packages provided by various services. A care package may be made up of a number of social care packages, such as home helps, and health care packages such as GP service and hospital services.

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

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. However, the arguments for and against multiple inheritance (inheriting from more than one parent) are lengthy and can be side-stepped for now.

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.

Thus a man marries one woman (at a time) and a woman marries one man (at a time). A cat eats one canary (before being battered to death by the little old lady who owned the canary). Canaries do not (in general) eat cats, so the eats relationship is one way.

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.

Zero or more suitors court the Princes. The black dot at the end of the line indicates zero or more.

Before an adequate suitor comes along, as is well known, a princess will kiss at least one frog, and possibly many more if she gets a taste for them. Frogs, being well mannered creatures and not wishing to appear in the gossip columns, never let more than one Princess kiss them.

Many to many relationships

Sometimes objects at either end of a relationship may be related to many objects at the other end.

A dog may bite zero or more postmen. A postman may be bitten by zero or more dogs.

A lubricant is recommended for at least one engine. An engine has at least one lubricant recommended for it.

Object Models

We now have the notation to describe quite complicated systems. The process of object-oriented analysis and design is one of elaborating an object model, increasing its detail and scope until enough is known to construct a computer system (if indeed that is what is wanted).

Here is a simple model for the Red Riding Hood story

Another example is one to describe patient referrals by GP's to specialists.

Another example is for a lift system:

The object model is the principal output of an analysis and design process. The distinction between analysis and design is much greyer in object-oriented development. Essentially it is one of detail. Analysis usually omits concerns about how a system is to be developed, and some of the objects may not be fully decomposed.

The object model is the central pillar of an analysis or design. It defines the computable elements. The dynamic and functional models discussed later all must result in objects, attributes and operations being defined in the object model. It is comprehensive and complete in terms of defining functionality, specifying not only the data but also the operations on the data.

Exercises

Construct an object model for one of the following: the football league, star wars, a personnel system, Cinderella, an automatic washing machine, a video hire shop, a kitchen.

Object Lesson 3

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. All we are going to do in the rest of the course is give you some tools to look for objects. But for the present, we will rely on native wit. Begin by looking at the real world. Open your eyes and your ears.

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. Let us suppose that you are analysing a system for a motor museum. The system is to produce a multi-media guide to the museum.

A preliminary list of objects might be:

car, bus, vehicle, number plate, exhibit, manufacturer, date of manufacture, value, position, weight, size, photograph, tools, shop, garage, ticket, owner, history

No doubt we could go on. However, the above list is probably enough to illustrate our needs.

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. The obvious thing above is to examine the following group

car, bus, vehicle, number plate, exhibit, photograph, tools, garage

It would seem that these could all be grouped together under the object exhibit. The question is, can these all be considered to be one object. In this case, the answer is probably yes. In the museum the behaviour of cars, photographs, and garages are not radically different, so we can group them together. We can differentiate between the individual objects on the basis of an attribute, say type.

Our first object is therefore:

We are then left with the list of candidate objects:

exhibit, manufacturer, date of manufacture, value, position, weight, size, shop, ticket, owner, history

Look for attributes

Attributes are themselves objects, but with trivial behaviour - essentially all you do is record their value. Considering the above list, the following are probably attributes of exhibit:

exhibit, date of manufacture, value, position, weight, size, owner

So we have the exhibit object as:

And we are left with the candidate objects:

exhibit, manufacturer, shop, ticket, history

We might have considered manufacturer as an attribute, but it may be useful to separate out manufacturer information later in the design. So we keep it for the time-being. The time to fold it in as an attribute is when we find it has no discernible behaviour of its own.

Irrelevant objects

Sometimes an object is irrelevant because of what you are designing the system for. Here the ticket object may be very relevant for a sales desk system, but not for a multi-media system. Likewise, the shop is irrelevant. So we strike these out and we are left with the following objects.

exhibit, manufacturer, history

We have these objects potentially linked in the following way.

Both exhibits and manufacturers may have histories. By factoring out manufacturers, the system may be able to trace from an exhibit not only its history, but also that of its manufacturer, and maybe allow someone to search for all the objects in the museum held by a given manufacturer.

The fleshing out of the objects with attributes and operations can be developed hereon in. A first cut of this might be:

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

The design of the process progresses by the construction of a series of prototypes. The prototypes are constructed using the most productive tools in terms of speed of development. The final system, when constructed, is functionally equivalent to the final prototype, but it is implemented in the most suitable technology for use of the system.