Now we have to worry about the customer and his/her account(s). Now a customer may have more than one account, normally. So it seems sensible to model both. Here, however, we merely need to know about the account. In fact the person depositing money may not be the owner of the account.

Now we are left with trying to understand where the cashier balance might be stored. We might want to create an object for this, or store this as an attribute of the cashier object. There seems no need to keep a cashier balance separate, so we shall record the cashier balance in the cashier object.

Now we are left with a decision about whether to keep a bank object. It seems reasonable, even though there may only be one. (Alternatively, we might think of the bank having many branches, and have to increment the branch balance. Let's keep it simple though.)

Now we have to decide whether to include the customer object. At this stage, the thing we are talking about is a real, physical customer. Hence we might leave a customer object out of the interaction diagram.

And so we progress. Now it is almost certain that two analysts working on the system would come up with different decisions at each stage. There is no single, definitive answer. Hopefully the set of objects derived by independent analysts would be similar, but any expectation that analysis is a deterministic activity with right or wrong answers is bound to be frustrated. Of course, there are good and bad analyses and designs. A large part of what makes for good design comes from experience.

In a nutshell, the first step from requirements analysis to detailed analysis is through the use of object-interaction diagrams to define objects, their behaviour and their attributes. These objects will be found in many interaction diagrams, and their overall behaviour is a composite of the behaviours from the individual interaction diagrams.

Having found some of the behaviours of objects in this way, we can then produce state-transition diagrams for the objects to more tightly define their behaviour. Our initial analysis can progress beyond functionality towards some architecture to support that functionality.

There are many techniques for driving the analysis. An analysis should involve the appropriate parties in the development of the system. There is not enough scope in this course to discuss methods of interviewing. One useful technique, however is to provide some discussion around the interface of the use-cases with the actors. This has the advantage that it begins to open up the way the system may be used, and it defines both attributes and operations the use-case needs to take into consideration.

For example, suppose we wished to discuss with a bank manager what happened when he/she checked an account balance. We might draw up a possible screen and describe it to the bank manager, asking for feedback on the suitability of the screen, its contents, and what the bank manager would expect to be able to do through the screen. It can be related to the use case diagram as below.

As the analysis progresses through to design, interface objects will have to be designed to drive the interfaces with the various actors, and effectively implement the use-cases as objects in their own rights. Use-cases can be thought of as objects whose behaviour is defined in terms of other objects in the system.

Abstract analysis and design can progress a long way before taking into consideration the hardware and software requirements for implementation. Arguably it is better to defer the decisions about implementation as far down the line as possible, though in practice it is often important to have some idea of the basic hardware and software configurations which will be available; in many practical projects these will be given as part of the existing infrastructure or policy of the client.

Conclusion

We have seen how use-case, through object-interaction diagrams, can be linked into object modelling. We have, in this way, provided a complete framework for requirements analysis, through to design of the basic structure to provide the required functionality. Of course, this framework can be elaborated in different ways, for example to incorporate special requirements of real-time systems, or to incorporate formal methods in areas where more rigour is required.

We have seen that analysis and design can be viewed as an iterative process, with a consistent notation throughout. It can proceed as a successive refinement and extension of requirements models, defined in terms of use-cases, dynamic models defined in terms of object-interaction diagrams and state diagrams, functional models defined in terms of data-flow diagrams, and an object-model defined in terms of objects, attributes, operations and relationships. The elegance of object-oriented methods lies in the coherence between the models, and the comprehensive sufficiency of objects to link and implement the various views of the system functionality and behaviour.

A further stage is required to map the design onto software and hardware architectures. A brief discussion of this is given in the rest of the course.

Business Process Reengineering

Business Process Reengineering (BPR) has become a buzz-phrase in the business world. What does it mean?

Largely businesses evolve over a period. There are well-established methods which which look at optimising parts of a business, say maximising the flow through a warehouse. These methods use a variety of mathematical techniques to improve on a given situation. However, methods of revising whole businesses have been largely ad hoc, and often based on accountancy models.

BPR takes the view that an organisation can be viewed as a system. Then systems methods can be used to analyse what is going on, and to redesign the system to improve some aspects of it. Object-oriented methods are one way of looking at businesses.

The value of object methods is that they can clearly separate out architectural and functionality issues, and then link them back. The problems businesses often face is that their architecture can no longer sustain the functionality they wish to provide. This is often expressed in terms of issues such as productivity.

Consider a car-producing company in the late 1970's, early 1980's which used traditional assembly line methods. According to the Henry Ford model, cars were built by hand in a series of steps, with one employee repetitively doing the same task over and over again. This had two major drawbacks. Firstly, the speed of producing cars was limited by the total time taken to do each task, and problems if any one of the tasks was done badly or slowed down for some reason. Secondly, the tasks were tedious which contributed to poor production quality, absenteeism and industrial unrest.

Car companies took two routes. One was to increase the level of automation, reducing the manual tasks. The other was to shift to small teams building cars. Essentially these are different business architectures, though the functionality is essentially the same (that is, producing cars).

Functionality is dependent on architecture. Two systems (or businesses) with similar functionality can be implemented with radically different architectures. However, different architectures can have very different performance characteristics, often in the business community focused on productivity, cost and quality.

Using object-oriented methods we can analyse a whole business in terms of its customers, suppliers and the functions that they expect. We can then consider the existing architecture, considering the components of the business as objects, such as employees, machines, warehouses, and so on. We can then redefine the objects, either adding in new objects, taking out old ones, or changing the behaviour and interaction of objects.

Consider a small company which makes a variety of metal screw fixings. The production line can only make one fixing at a time, and retooling to make another fixing takes half a day. The sales team has been successful in increasing orders, but that has introduced more types of fixing. The warehouse now keeps runing out of stock of some of the fixings. Conflict is arising with production which cannot keep pace with orders - either it produces too much of each line, which the warehouse cannot store, or it spends a great deal of time retooling. An initial analysis of the problem is as follows. Firstly, a use-case analysis of the various actors involved in the process is:

And if we open up the two use cases using object interaction diagrams we get:

After some consideration of this, it might be seen that if orders were to be considered as part of the production scheduling, then the number of stock-outs might be reduced, without over-stocking. A survey of customers indicates that they can often cope with a lead time of up to two weeks before delivery, giving a wider window for the production line to respond to demand. The two object-interaction diagrams are revised to:

By changing the behaviour of the individual objects, and how they interact, the production line now has a chance to optimise production. It can schedule production as late as it needs to and still meet orders. It can also skip restocking the warehouse if the orders are not high enough to justify it. The warehouse may have to take extra stock of certain lines at times to meet bulges in orders of that line.

This does not change radically the basic architecture of the business. In a different type of business, say bulk chemicals production, it might be possible to do away with the warehouse altogether by producing goods just in time for delivery. One change we might consider making to the above architecture is to source some items from another supplier to make up orders. Then the order process might look like:

What we are doing here is exactly the same as we would be doing if we were analysing and designing a computer system. The only difference is that the implementation of the objects is in physical things, not software.

We could go on to do state diagrams for the sales department, the warehouse, the production line and so on. We could construct an object model for the business. These, in different circumstances, might be useful for the analysis and redesign.

Conclusion

Business Process Reengineering views a business as a system. Object oriented methods can be used to analyse the current architecture of the business, and to devise new architectures. The differences appear at the implementation stage, where the objects are realised as physical components, not software components.