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.
Stories written down like this are a wonderful basis for discussion. People quickly relate to them and feel they can make changes. Their very simplicity is their power. Once the idea is grasped, it works very well. And above all, we have got away from the jargon and mysticism of computer system design-speak. Theology is fine for theologians, but not for the layman. Talk the jargon in private, in the cloisters of the system development team.
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.