Over the past few years I have been involved in product development projects to build Standard Software Packages off-the-shelf, rather than in building ‘one-of-a-kind’ systems. Lot of effort had to be invested to make the packages adaptable and maintainable over time. For Standard Software Packages ‘Design for Maintenance’ is absolutely crucial from 2 perspectives:
First of all, a Standard Software Package must be adaptable to a company’s specific needs, which can be seen as a case of maintenance. Change is almost for sure as soon as the Package is getting deployed into a specific environment. And only rather simple changes in functionality of the system can be done without changing source code.
Second, a Standard Software Package must be maintained, independently from adaptations that have occurred on top of it at a customer site. A new release of the package (the ‘base product’) must be of minimal impact for the installed system that has been adapted. Since the number of installations (and therefore the rip effects) can be large ‘Design for Maintenance’ is even more important than for one-of-a-kind systems. Continuity over releases is essential.
How can we cater in our system’s Architecture and Design for Maintenance?
As always, ‘separation of concerns’ is the first answer that comes to mind. It must be identified what is flux and what will be stable in the application domain over time. Parts that are likely to be changed must be identified and separated from those that are stable, through solid interfaces. Designing ‘everything’ for change - be it maintenance or adaptation - is not economical or may be even impossible.
Identifying what’s flux and what’s stable in the application domain is definitely the hardest part. It can be seen as a (business) analysis task, rather than a software engineering discipline. Tremendous domain expertise is necessary to do a good job here.
Once the hotspots are identified, software design principles can be applied to ensure that these variable parts can be changed easily. And here, Object Technology is extremely powerful to implement a maintainable system.
As often stated, it is not Object Technology per se that makes a piece of software easy to maintain or ready for reuse. It is the underlying Architecture and Design that enables this. To ensure ‘good design’ Design Principles must be brought in place that govern the specific Design across the board.
The following Design Principle is a useful guideline for building software that is maintainable and adaptable:
Define interfaces to components as a set of abstract classes and a subsystem facade which provides access to instances of those classes.
This Design Principle can be implemented in all object oriented languages, although in slightly different ways. The principle above has been set up for an implementation in C++ where pure abstract classes can be used to implement an interface. In Java where the concept of interfaces are built in in the language, those are used instead of abstract classes.
In more detail, the Design Principle imposes the following Design (see also Figure 1):
Figure 1
The Design Principle caters for maintenance and adaptations in the following way:
Minor changes to the existing ‘original’ functionality can be done by sub-classing an Exposed Class, outside the component. This guarantees stability of the core and flexibility for change. Enhancements are implemented in new additional methods, alterations in behavior are done by overwriting existing methods in the new subclass.
From time to time, when more major changes are necessary in the ‘core’ (inside the component), the new release does (typically) not require a re-implementation of the adaptations outside the ‘core’. As long as interfaces remain the same, the code in the subclasses will still work. Only if new functionality of the new release shall be used the subclasses (or the clients thereof) need to be changed.
In a nutshell, we the Design Principle helps to implement a ‘two level’ maintenance cycle:
This allows that the change requests and enhancements of an existing system can managed more efficiently. ‘First level’ maintenance is done outside the core system, and maintenance in the core may or may not affect the minor changes. The decoupling of minor and major changes allows for flexibility on one hand side and for continuity on the other.
The Design Principle is especially useful for Standard Software Packages: It enables adaptations for a specific environment without affecting the core and makes upgrading to a new major release far less painful.
Steffen Schaefer is a consultant with IBM’s Object Technology Practice. He has 10 years of experience with OT and is specialized on architecture and methodology for medium-large scale projects.
To participate in this workshop please read the Call for Participation