Charters

Rather than produce a contract defining all functionality to be delivered in a cycle, it is possible instead to construct a charter. A charter prioritises the functionality which should be delivered in the cycle. The charter can over-specify what is expected in the cycle, in case progress is faster than anticipated.

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.

Lesson 4 - Dynamic Modelling - Event traces 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. We shall meet functional modelling, later, which is another method of uncovering operations and attributes.

We shall look at dynamic modelling as a form of story telling. Do not think this trivialises it. The plot of a good novel is at least as complicated as the most intricate of computer programs, though usually less baroque (at least since Dickens). The approach we are going to adopt is to look at the stories in the world we are analysing, call them scenarios (just so we have some jargon), and then see how these stories affect each of the individual objects (which for the novelist would be characters and artefacts).

Jacobson talks of "Use Cases". They are essentially the same. Unfortunately the name implies too much system design at the initial stages of analysis.

Event traces - building scenarios

As we said that 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 for Red Riding Hood - we will do some serious work later. If we strip down the things that happen to Red Riding Hood in the story, we find that she does the following

1. leaves home

2. meets the Wolf

3. arrives at Grandma's

4. is threatened by the Wolf

5. leaves Grandma's

6. meets the Woodcutter

7. arrives at Grandma's

And no doubt lives happily ever after, wrapped in the arms of the woodcutter. We have focussed purely on the things that Red Riding Hood does, not the things she witnesses. Thus all the stuff about "what big teeth" can be omitted. The facts (as Mr Gradgrind of Hard Times, Dickens' prototype logical positivist, would have said) are all that are to be considered.

This is known as a scenario. We can construct other scenarios. For Grandma it would be:

1. Wolf arrives at Grandma's house

2. Wolf eats Grandma

3. Woodcutter cuts open wolf and Grandma escapes

Personally I have always thought this a little suspect.

Now we can open up the objects by examining the events in relation to the objects using an event-trace diagram. Here is an event trace diagram from Red Riding Hood's perspective.

The object interaction diagram here is the formal notation. Down the left hand side we can list the actions or events in a scenario. The thick vertical bar to the right of the events is the system boundary. Hence the trigger to Red Riding Hood leaving home is outside of the story - perhaps her mother nagged her into it. The vertical lines indicate objects. The arrows represent the interactions between the objects - Red Riding Hood is the protagonist in all this. The labels on the arrows are the operations.

Of course, we do not need an elaborate case tool to represent this. A simple table would do:

	Red Riding Hood	Wolf	Grandma	Grandma's House	Woodcutter
RRH leaves home	leave
RRH meets wolf in wood	meet	meet
RRH arrives at Grandma's	arrive			arrive
RRH runs away from wolf	leave			leave
RRH meets Woodcutter	meet				meet
RRH returns to Grandma's	arrive			arrive

Well, let us look at a more traditional example.

Let us consider a patient being admitted to hospital for treatment of a simple hernia.

• Patient arrives at reception

• Patient gives personal details and is given a form

• Patient goes to ward and hands in form

• Patient is interviewed by nurse and gives medical details

• Patient is interviewed by aneasthetist and gives the same medical details

• Patient is examined by consultant

• Patient is given a pre-med injection

• Patient is taken to surgery

• Patient is given anaesthetic

• Patient is operated on

• Patient is returned to ward

• Patient is examined duty doctor

• Patient is examined by nurse

• Patient is examined by consultant

• Patient is discharged

A simple event trace might be as follows. To fit on the diagram, aneasthetists and consultants have been lumped together as doctors.

The aneasthetists story is a bit different

• Aneasthetist interviews patient

• Aneasthetist arrives at operating theatre

• Aneasthetist aneasthetises patient

• Aneasthetist monitors patient

• Aneasthetist releases patient to ward

Medical practitioners reading this, forgive any errors and omissions. We could go on and look at the story of the consultant, a nurse, or even the hospital bed.

We are trying to pick up the bare bones of stories. Stories tell us what things there are in the world, and how they interact. It is the basis of a good analysis. The simple list considerably simplifies interviewing and recording. We do not consider all cases, alternatives, and complex repetitions. We work through individual cases. Complexity can be introduced later.

Of course an individual may have many stories. The patient story varies with each disease and with any complications. The nurse story of caring for an individual patient depends on the patient's problems. And indeed an individual may be in the middle of a number of stories all at the same time, say a nurse caring for a number of patients and running the staff coffee club. We look for the simple sequences. It is the merging of those sequences which makes the world look a messy and complicated place.

Analysing the world is like unravelling a number of threads which have become wound together. The picking out of individual threads stops the feeling that the world is impossible to comprehend. Taking each thread at a time, the overall pattern begins to make sense. And we do not get buried in confusing knots and misleading patterns.

Here is a story of an initial analysis session

• Analyst contacts manager

• Analyst arranges interview

• Analyst meets manager

• Analyst asks manager the first thing she does in a morning

• Analyst asks manager the next thing she does

• ..... and so on

• Analyst ends enterview

• Analyst looks for ends of threads

• Analyst records possible threads

Of course, this could be quite time-consuming. Visits to the coffee machine, chats with colleagues and so on would be left out. Only the gross detail of the manager's activities would be recorded such as

• Check answerphone messages

• Check diary notes

• Check mail

• Attend safety review meeting

• Carry out staff appraisal interview

• Lunch with salesperson

• Organise workshop

• Write report

• Review bids for a tender

And some of these actions are part of bigger, longer stories. The focus of the analysis will determine which of these threads needs to be examined in detail at a later stage.

Does all this lead to computer programs? The answer is, it can do, but not necessarily. However, to reassure those with aspirations to encode the whole world on their PC, here is an example as part of the design for a washing machine controller. A boil-wash may operate like this:

• Lock washing machine door

• Open hot water valve (Note: start of wash program)

• Switch on drum tumble

• Close hot water valve

• Set thermostat cut-out to 105 degrees

• Set thermostat cut-in to 100 degrees

• Switch on heater

• Switch of heater

• Switch off drum tumble

• Open drain valve

• Turn on pump

• Start drum spin

• Stop drum spin

• Turn off pump

• Close drain valve

• Open cold water valve (Note: start of first rinse)

• Switch on drum tumble

• Close cold water valve

• Switch off drum tumble

• Open drain valve

• Turn on pump

• Start drum spin

• Stop drum spin

• Turn off pump

• Close drain valve

• Open cold water valve (Note: start of second rinse)

• Switch on drum tumble

• Close cold water valve

• Switch off drum tumble

• Open drain valve

• Turn on pump

• Start drum spin

• Stop drum spin

• Turn off pump

• Close drain valve

• Unlock door

Pretty tedious, I know, but a comprehensive explanation of how a washing machine operates on a particular wash. It leaves out a lot of things, such as timing information, but that can be added in later if necessary. And, of course, the hot wash, warm wash and cold wash cycles will be similar, but equally long-winded. Note also that there are some stories hidden behind this. One even duller story is that of the drum. A single tumble story is:

• Set motor direction clockwise

• Turn on motor

• Turn off motor

• Set motor direction anticlockwise

• Turn on motor

• Turn off motor

And drums being the goldfish of the washing machine world will repeat this story endlessly until told to stop.