7.1 Components for flexibility

Component-based development is concerned with building extensible families of software products from new or existing kits of components. The latter may range in scale from individual classes to entire (wrapped) legacy systems or commercial packages. Doing this has hitherto proved an elusive goal for software developers. The trick is to realize that we need to define the interface protocols of objects in such a way that they can be plugged together in different ways. The number of interfaces needs to be small compared to the number of components. To improve flexibility these interfaces should permit negotiation in the same way as with facsimile machines or clipboard interfaces in Microsoft's OLE and the like.

 

Figure 46 Plug-points add flexibility.

An example may suffice to explain the point. Consider an hotel support system that is originally written for a small chain of Scottish hotels. The original is a great success and pays for itself quickly. But the price of success is rapid expansion and the company now acquires several more hotels in England, Wales, France and Germany. In Scotland rooms are always allocated to new arrivals on the basis of the empty room nearest the reception desk - to save visitors wearing out their shoes walking long distances. But the spendthrift and gloomy English want peace and quiet more than these savings; so that rooms are allocated alternately, to leave empty rooms separating occupied ones when the hotel is not full. The Germans allocate rooms with French widows first. The different states involved also have different rules about wage payments. The system is amended piecemeal and soon there are several versions to maintain: one with nearest desk allocation and French payment rules, another with least-recently-used room allocation and UK staff payment laws and an ad hoc patch for management christmas bonuses in Ireland and the Netherlands, and so on. A maintenance disaster of some proportion!

A considerable improvement on arbitrary modification is shown in Figure 46. There is a basic framework, which does everything that is common between the requirements of all the hotels. Each separate variable requirement has been moved into a plug-in component: for example, there are different room-allocators; and different staff payment components. This arrangement makes it much easier to maintain and manage variants of the system. We separate the rôles of the framework-designer and the designers of the plug-in components - who are not allowed to change the framework.

This makes it very clear that the most suitable basis for choosing components is that they should correspond to variable requirements. This is a key rule which people sometimes forget, while still claiming to be doing component-based development.

One problem is that it is not always easy to foresee what requirements will be variable in the future. The best advice we can give here is as follows.