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 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.

Each process needs to be implemented as an operation in one or more of the objects. Each data item arising from an object must have a corresponding attribute or set of attributes in the source object.

Data flow diagrams are useful if:

• you have lots of calculations to carry out

• you are familiar with data flow techniques in a method you have used repeatedly before.

The approach to data flow diagramming should be as follows:

• create a data flow diagram for each of the major outputs of the system

• work back from the outputs to the inputs to construct the diagram

• add new objects where necessary to the object model as you discover the need for them in the data flow modelling

• add new operations and attributes to the object model as you discover the need for them in the data flow modelling

The difference between data flow use in object methods and other methods (e.g. SASD) is that the data flow diagram is not used as a basis for devising the structure of the system

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 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.

And so we build our model of the ways the system is used. We might add two more use-cases of the bank system.

Examining this, we see that there is probably a need for another actor. (I never borrowed money without having to grovel to the bank manager, and the bank manager always looked carefully at my pitiful balance before grudgingly saying yes).

Use cases may in fact use other use-cases. The withdraw cash use-case would make use of the account balance use-case before issuing the money.

A use-case is a very abstract view of what the system provides to the various actors who use it. It is not intended to give a detailed, blow-by-blow account of how the services are provided. Therein lies the beauty of the approach. By keeping out detail, it is possible to reason at a higher level. Later the use-cases can be opened out using object-interaction diagrams to begin to define their precise operation.

So what about our object oriented fairy tales? Where are our use-cases for those? We might model it in this way.

So what about Red Riding Hood and the Wolf and all that? What the example points out is that use-cases are very abstract. They do not define the architecture of the system (the objects and how they interact). They merely list what the system does. Almost all fairy stories would fit into the above use-case.

The first stage of any project should be an analysis of the use of the system being devised. The requirements stage in object modelling, as described in this course, involves constructing use-case models of the system. The next stage is to open up the architectural issues by elaborating the use-cases as scenarios, described earlier.

Here is a simple use-case model for a computer:

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.