Discussion

The above examples could have been described in many ways. The use of the activities from the business activity model meant that the problem could be explained in terminology which could be understood by different businesses. The use of information flows, with delays, proved very effective at describing the benefits of changes in IT to business managers in ways that could be quantified.

Object Modelling with Activity Models

Activities are logically arranged groups of events. Dynamic modelling, through event traces, is one way of linking events to objects, thereby defining object behaviour and identifying new objects. Activities can be used in a similar way to identify operations on objects. This can be done by simply producing a matrix; a simplified example from the PLANEC application is illustrated below. This is for the ARRANGE RESOURCES activity. PROVIDER, FUNDER and RESOURCE are three of the candidate objects for the PLANEC system.

A similar cross-referencing process can be used to identify attributes.

This process has proved remarkably productive and effective in defining functionality. Over a two day workshop involving the representatives of the consortium, approximately 250 operations and attributes were identified and agreed. The list for one of the objects is given in appendix 2.

The high level specification ended up with nine core objects in the specification:

• RESOURCE

• POPULATION

• CLIENTS

• CARE

• COSTS

• FUNDER

• PURCHASER

• PROVIDER

• PLAN

The objects are related according to the following diagram

The PLAN object interacts with all other objects, and so has been drawn as above for clarity.

These objects are really large groupings which will need further refinement with specialisations and component objects to be devised in the design phase. The objective of the functional specification has been to obtain a logical and complete grouping of all the data and functionality requirements for the first prototype.

The activity model was used extensively to drive the process of defining these objects and their relationships. The process of cross-referencing objects with activities clarified a number of issues an reduced the set of candidate objects considerably.

The relationship of activity modelling to object modelling techniques

An object model, consisting of objects, their attributes, their operations, and their relationships, can be viewed as a computable representation of the real world. Dynamic modelling, through event traces and state diagrams, and functional modelling, through data flow diagrams, can be viewed as a means of refining the object model. Activity models, as used above, can be thought of in the same light. Thus they extend the repertoire of available tools to analyse a business environment.

The difference between activity models and event traces (or use-cases), is their omission of temporal considerations. In this sense they are weaker than dynamic models. On the other hand, they prove easier to deal with in the earlier stages of analysis. In particular, the lack of temporal and information flow considerations allows specification of system functionality without overly constraining implementation.

Planned research

The above methods and techniques have emerged initially as ad hoc approaches to solving high-level analysis and design problems, and communicating IT issues to senior management and to non-IT researchers. They have not, therefore, been related to the literature. Two avenues of research are opening up. One is to extend existing methods, using the activity modelling approach. Another is to investigate the use of activity models as a bridge between business process re-engineering and software engineering.

Conclusion

Activity models are proving a useful means of reasoning about systems at an abstract level. By omitting temporal and information flow considerations, they allow high level reasoning about systems and the environment in which the systems operate. They are largely independent of organisational considerations. They can be used as a framework for strategic planning and analysis, as a basis for a common terminology in BPR, and as an entry point for specification and initial design of systems in an object modelling approach. They offer a possible, useful extension to existing methods, and a possible bridge between BPR and software engineering. They have been proven in a number of practical projects where the characteristics of the projects have involved differing organisations which provide similar products or services.

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.

Opening up the use-case requirements model

Use-cases allow us to describe at a high level the basic functionality of a system in terms of the various actors who need to interact with the system. We now consider how to flesh out those use-cases, and to link them into the object modelling method we considered earlier.

From the use-cases, which describe broad functionality, we begin to analyse the details of the functionality of the systems we want to construct. Use-cases are broken down into sequences of actions and events. These actions and events are mapped onto objects through object interaction diagrams.

Let us look at the bank example:

The deposit cash involves the following sequence of actions

• Complete pay in slip

• Hand cash to cashier

• Increase cash balance of account

• Increase cashier's balance

• Increase bank's balance

• Issue receipt to customer

It could be more complicated if we included cheques, but you can do that as an exercise. The link between the requirements model and the object model is built through object interaction diagrams. We can now construct an object interaction diagram something like:

Now we have to consider what objects we might need for interaction. The first debate is whether we want to model the pay-in slip. In the final analysis, the decision to model something as an object depends on how important the behaviour is to the system we are developing. It might be that we only need to record the existence of the pay-in slip, and it can be referenced by an attribute. But to be safe, at first we shall include it as an object.

Next we have to decide if we wish to model the cashier. Again, at first it is better to model something as an object and reduce its status to an attribute (say) or remove it from the system at a later stage. So we include a second object.