So, the first step of analysis is to go out and collect stories. Lots of them. Call them scenarios to please your IT manager (or whatever manager has commissioned you). Collect them until you have the complete recipe book for an organisation, or the part of an organisation you are interested in. Then, when you have the recipes, you can cook the dishes and prepare the banquet.

Work like a detective. Ask what happens first. Ask what happens next. Sit patiently through the arm waving and the elaborate descriptions - some of them might be worth recording for later use, so use your judgement. Remove conjecture. Keep out the emotive elements. And then, when you have a simple list of instructions, ask your interviewee if he/she agrees with the simple list. Explain that you are after the bare bones, and that all the wonderful detail you have collected will be used later.

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

• 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

Computer systems are built from objects which respond to events. External events arrive at the boundary of the system, say when a mouse button is clicked. Some object picks up the event, responds to it, and perhaps generates some internal event by calling an operation on another object.

In this lesson we examine a way of describing how an individual object responds to events, either internal events triggered by other objects or external events triggered by the outside world.

State diagrams allow you to further explore the operations and attributes that need to be defined for an object. They consist of sets of states which an object is in, and events which take the object from one state to another. Let us go back to our juggling example. A juggling ball starts on the floor, and alternates between being held and being in the air, until it is dropped and lands on the floor. This can be drawn like this:

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.

The level of state decomposition must be decided on judgement. Too fine a grained model is inappropriate; say modelling all the possible ages of an employee as individual states. Too gross a decomposition is useless; say modelling an employee as employed or not.

Let us look at the state diagram for Red Riding Hood. One might be:

Where events come from and go to indicate something about the behaviour of the object. The above diagram implies that Red Riding Hood cannot proceed to living happily ever after while she is in the woods. Of course, if she had fallen madly in love with the woodcutter and did not care for the well-being of her grandmother, then the arrow to lives happily ever after might well have originated at a different place.

Of course, not all objects have behaviour worth modelling. Consider our example from the field of object oriented nursery rhymes, the sad story of Humpty Dumpty. Clearly one would not want to model such trivial examples.

A more complicated example from the world of object-oriented aviation is:

Careful consideration of a state can often uncover more complicated behaviour. Consequently we have a notation to describe substates. The aggregation notation can be used to illustrate this.

What do we learn from this modelling? Firstly, the states need to be recorded in the attributes of an object. For example, we may need an attribute ("is flying", say) which is true or false to indicate whether an aeroplane is flying or not. Also, we recognise the need for operations to cause the state transitions. For example, we may need a "take off" operation to enable the object to move from "at airport" to "flying". The transition diagram also indicates some of the things the operation must do, such as change the attributes which determine the state.

Basically you need to construct a state transition diagram for every object with significant behaviour. You need not construct one for anything with trivial behaviour. The reason for doing this is to identify further operations and attributes, to check the logical consistency of the object, and to more clearly specify its behaviour.

All the best notations can be used to describe the process they facilitate. Now we have the basic ideas of object models and dynamic models, our approach to analysis and design (so far) can be summarised as:

We shall shortly be adding functional modelling to our portfolio of tools, which is another way of discovering attributes, operations and relations for our object model.

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:

The CPU (central processing unit) reads and writes words to and from memory. A peripheral (such as a keyboard or screen) has information transferred to or from memory. A peripheral can also interrupt the CPU. (For the non-computer scientist venturing this far, an interrupt is an electronic signal which forces the CPU to jump to a special instruction stored in memory). There needs to be at least one peripheral to make the computer useful (intraverted computers are of little use). However, not all peripherals use interrupts, so it is possible to have a CPU without interrupts (unlikely, but some simple computers operate this way).

Some careful thinking might open up the operations and attributes thus:

Let us now look at an event trace for an instruction to add two integers (stored in memory) and to put the result back into memory.

This does not tell us about any new operations, but careful consideration of the above indicates that the CPU needs somewhere to store the first integer (at least). Internal storage in a CPU is normally called a register. So our object model for a CPU grows just a tiny amount.

Exploring more instructions is not likely to yield too much more. However, let's look at the state diagram for the CPU.

The CPU loops endlessly, fetching instructions and executing them. We can see from this state diagram that the CPU needs somewhere to store the address of an instruction. It is also clear that there is a need to store an instruction retrieved from memory. Our object model grows a little more.

We have added two more attributes - an instruction register to store the instruction, and a program counter to store the address of the next instruction to be fetched. We have two more operations, fetch instruction and execute instruction.

Let us now look at an interrupt.

An interrupt causes the CPU to start executing a routine stored in a pre-defined location in memory. Before it does that, however, it needs to remember where it is in the program it is executing. The normal way of doing this is to keep a stack, the top of which contains a sequence of addresses of partially complete routines. This implies the need for a stack register, to store the address in memory of the top of a stack. We can model the response of the interrupt by the CPU by extending the state diagram for the CPU.

Basically, the interrupt changes the address of the next instruction which the CPU is to execute. The response to the interrupt must also store the address of the next instruction on the stack.

We now can modify the object model further:

We need to add a stack register to the CPU to store the address of the top of the stack in memory. Also, we need to know the address of the interrupt routine which the CPU must go to when an interrupt takes place. This can be stored as an attribute of the Peripheral, as there is likely to be a different interrupt address for each peripheral. Finally, we can record the goto operation as a special operation for the CPU, which simply changes the address in the program counter.

Now let us be a little adventurous and add a peripheral. Let us put in a mouse.

A mouse, if you take it apart, has two little rollers recording movement in two directions (vertical and horizontal, say). Every tiny movement of the mouse causes the one or both rollers to register a movement and interrupt the CPU. The CPU therefore gets a continual stream of interrupts as the mouse is moved. It then needs to decide what to do (move the cursor on the screen, or whatever). A move which is not vertical or horizontal will send a mixture of vertical and horizontal messages to the CPU.

The mouse inherits the transfer in and transfer out operations for passing information to the memory. One way the mouse might use these is to have two locations in memory to record how far the mouse has moved in the vertical and horizontal directions.

An object model for genetic algorithms.

Let us now consider another example, this time from the realm of evolutionary computing. A genetic algorithm uses simulations of genes to solve problems. To begin with, we have the idea of a chromosome which is made up of one or more genes. The more genes you have, the more complicated the problem you can try to solve.

The genes themselves can be represented as integers, bit strings, characters, or whatever. Normally they are described as bit strings. But basically they represent some value. Suppose we want to find high values of an equation such as

2x³+3yx²-xz³+5

Now we could represent this with a sequence of three genes, each gene being an integer value for x, y and z. We end up with an object diagram:

The chromosome represents (in a sense) the equation. Each gene defines the value of one of the variables. Now the equation knows how the variables are combined, and so can calculate its value using the integer values defined by the gene.

Of course, this is all very uninteresting, until you start putting lots of chromosomes together in a gene pool. The chromosomes can start with randomly chosen values, and you end up with a large number of equations with different values.