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.