Lecture
Software is maintained and continually refined, which is especially true of large systems such as ours. Indeed, one can still encounter programs written some twenty years ago (positively patriarchal by computing standards). The more users apply the traffic management system, and the better we adapt the design to new requirements, the more often clients will find new and unexpected uses for existing mechanisms, creating a need to incorporate new functions into the system.
Consider a single addition to our requirements: payroll processing. Suppose analysis has shown that the railway company's payroll is handled using hardware that is no longer manufactured, so there is a serious risk of irretrievably losing the entire payment system as a result of a few critical failures. In this case we can merge payroll processing with the traffic management system. To begin with, we must understand how these two unrelated tasks will coexist; we may regard them as different applications, with payroll processing running in the background.
Further analysis shows that enormous benefit may be gained from integrating payroll processing. Recall that train plans contain information about crew assignments. Consequently, we can analyze the planned and actual crew assignments, compute working hours, overtime, and so on. By obtaining this information directly, we can process the payroll more cheaply and more quickly.
What does adding this function affect in our design? Very little. The new subsystem can be added to the UserApplications subsystem. From there, the new subsystem will have visibility to all the important mechanisms it needs in order to function. This is the hallmark of a well-designed object-oriented system: significant additions to the requirements can be accommodated fairly simply by building new functionality on top of existing mechanisms.
Suppose we want to introduce a more substantial change: adding an expert system that assists the dispatcher in determining routes and responding to emergency situations. How would this requirement affect our design? Only slightly. We can place the new subsystem between the TrainPlanDatabase and DispatcherApplications subsystems, since the knowledge base created for the expert system is similar in content to TrainPlanDatabase; moreover, the DispatcherApplications subsystem is the expert system's only client. We would have to devise some new mechanism for conveying recommendations to the end user. For example, we might use the blackboard metaphor, as was done in Chapter 11.
We have already noted that hardware evolves faster than software. Moreover, there will always be reasons that force us to make hardware choices during design that we later come to regret [For example, some of the hardware may have to be purchased from a third party, and it may then turn out that the delivered product does not meet the agreed conditions. Or, worse still, the supplier of a critical product may go out of business. In such cases the project manager must choose one of two courses: (1) wail into the night; (2) find a replacement and hope that the system's architecture is flexible enough to accommodate the change. Object-oriented analysis and design will help us achieve (2), although resorting to (1) is sometimes very comforting]. For this reason, in large systems the operational hardware becomes obsolete much sooner than the software. For example, after several years of operation we may replace the displays on all the trains and in all the dispatch centers. How might this affect the existing design? If during development we kept the subsystem interfaces at a high level of abstraction, this hardware change will lead to only minor changes in the software. We would revise only the collection of procedures relating to the displays, without touching the other subsystems, which know nothing at all about the particulars of specific workstations. This is achieved because the behavior of all workstations is hidden within the Displays subsystem. Thus the subsystem acts as a wall of abstraction that shields the other clients from our difficulties arising from the diversity of displays.
Similarly, radical changes in telecommunication standards would affect our implementation in a very limited way. Our design guarantees that only the Messages subsystem is concerned with network communications. Thus fundamental changes in the network will not affect any high-level client; the Messages subsystem protects them from the whims of networking fashion.
Thus, the imaginary changes we introduced were unable to disrupt the structure of the design we created. This is a sure sign of a well-designed object-oriented system.
Comments