10.3. Evolution and 10.4. Maintenance of the inventory tracking system

10.3. Evolution

Release management

Now that we have fully defined the architectural framework of the inventory tracking system, we can proceed to its incremental development. Let us first select the most important transactions in our system (its vertical slice) and release a product that at least simulates the execution of the transactions.

As an example, let us settle on three simple transactions: entering a new customer into the database, adding a product, and accepting an order. In implementing these transactions we will, to one degree or another, touch upon practically all of the architectural interfaces. If we can successfully get through this key stage, then we will go on to issue releases in the following order:

• Modifying or deleting customer data; modifying or deleting product data; modifying an order; queries about customers, orders, and products.
• Integration of all similar transactions associated with suppliers: creating an order and issuing an invoice.
• Integration of all the remaining transactions associated with the warehouse: producing reports and issuing shipping tickets.
• Integration of all the remaining transactions associated with accounting: receipt of payment.
• Integration of all the remaining transactions associated with shipping.
• Integration of all the remaining transactions associated with planning.

With an overall system design schedule of 12 to 18 months, a working release of the program must be issued every 3 months. By the end of that period all of the transactions needed for the system to work will have been covered.

In Chapter 6 we already mentioned that the key point in such a strategy is the identification of risk, and so for each release we find the most dangerous spot and work it through aggressively. For client/server applications this is connected, first and foremost, with testing capacity and scalability as early as possible (so as to find the system's bottlenecks as soon as possible and do something about them). At the same time, each release should include transactions from different functional elements of the system - then there will be less chance of running into surprises.

Figure 10-1. The network of the inventory tracking system.

Application generators

In building applications such as an inventory tracking system it is necessary to produce a great many screen forms and reports. For large systems this work is not so much difficult as it is large in volume and monotonous. For this reason application generators based on fourth-generation languages (4GL) are quite popular today. The use of these languages does not contradict the ideas of object-oriented design. On the contrary, when applied correctly, 4GL languages make it possible to simplify the writing of code substantially.

Fourth-generation languages are used to generate screen forms and reports. From specifications they create executable code for forms and reports. We integrate this code into our system by "wrapping" it by hand in a thin object-oriented layer. In this way the code generated by the 4GL becomes part of the class structure, which the remaining parts of the application can use without paying any attention to how it was created.

Such an approach allows us to take advantage of 4GLs while preserving the illusion of a fully object-oriented architecture. Moreover, fourth-generation languages are themselves subject to the strong influence of object-oriented programming technology and include application programming interfaces (APIs) for object-oriented languages such as C++.

The same strategy can also be used in implementing the user's dialog with the system. Writing programs for modal and modeless dialogs is tedious, since we have to cover a mass of small details. It is better not to write such code by hand [One can take pleasure in the very process of writing object-oriented programs, but it is far more important to concentrate on the requirements of the problem at hand. This means that one should avoid writing new code wherever possible. Application generators and GUI builders greatly facilitate this. The development environments we described in Chapter 9 provide another important example of this kind], but instead to use GUI builders, which allow one to "draw" dialog boxes. Having obtained the finished code, we wrap it in an object shell, include it in our application, and obtain a system with a clear separation of responsibilities.

10.4. Maintenance

Client/server systems are rarely ever finally completed. It is not that we can never say of a system that it is now stable. It is simply that the system must evolve together with the business in order to remain useful.

We can point out some directions of modernization that are likely for the inventory tracking system:

• Provide customers with the ability to work with the system over communication channels.
• Automatically generate individual product catalogs for consumer groups or even for individual customers.
• Fully automate all functions, eliminating the warehouse workers and most of the personnel working in receiving and shipping.

Analysis shows that all of the modifications listed are connected more with social and political risk than with technical risk. The flexible object-oriented architecture of the system allows the customer to use every degree of freedom in order to adapt to a constantly changing market.