Datasheet

Designing Applications
19
❑ Performance Considerations
❑ Calculation Methods
But design is not just about establishing an immutable set of blueprints. Successful applications
are normally those where the application designers have designed for change.
Designing for Change
The concept of "Designing for Change" was first discussed by David Parnas in the early 1970s.
It is a principle that recognizes the fact that, however good the analysis has been, there will
frequently occur during the lifetime of a project a number of influences that will necessitate
change to occur after the initial design has been completed. It might be a change in the legal or
business environment in which the customers operate, a change in available technology, or
simply a change in understanding on the part of either the customer or the developer. The
purpose of designing for change is to ensure that these changes can be accommodated into the
project with the minimum possible disruption or delay.
Three of the most important techniques involved in designing for change are described below:
Identify Volatile Areas
Some issues are more liable to change than others during a development project. These include
business rules, file formats, sequences in which items will be processed, and any number of other
difficult design areas. The first step is to identify all such volatile areas and document them.
Use Information Hiding
Once these issues have been listed, you can employ information hiding. The principle here is to
wrap up, or encapsulate, these volatile issues in a module or procedure that hides, or partitions
off, the complexity or volatility of the processes involved. These modules or procedures should
have an interface that can remain the same, irrespective of any changes that may occur within
the module or procedure as a result of any of the influences we identified earlier. If a change
occurs, it should only affect that module or procedure. Other modules that interact with it
should not need to be aware of the fact that anything has changed. This is often called "black
box" coding, in that "stuff goes in" and "stuff comes out" but what happens in the box is hidden.
For example, you might be designing an application that is used for sending out pre-renewal
reminder notices to customers prior to the expiry of their insurance policies. Perhaps a business
rule states that pre-renewal notices are to be sent out 2 months before expiry. This is just the
type of rule that could easily change and a good design will account for this. Accordingly, a
procedure could be written which encapsulated that rule and which was invoked whenever
various parts of the application needed to know when the reminder should be sent. Changes to
the business rule would only need to be incorporated in a single procedure; the procedure
would still be invoked in the same way and yet the effects of the change would be available
throughout the application. We will look at this subject in more detail when we examine the use
of classes in Access in Chapter 13.