Next: Frameworks generate metamodels Up: Frameworks Previous: Classification of frameworks
There are quite a few documented methodologies for developing a framework. Most of them, though, admit the fact that the objective is to identify abstractions with a bottom-up approach: start by examining existing solutions and be able to generalize from them. When adopting a framework development process it is important to take into account that any framework will usually start as a white-box framework and ideally evolve into a black-box one. It is also important to understand that developing a framework is more difficult than developing and application because users must be able to understand many design decisions. For this reason it is even more important to follow good design practices and principles.
In [Johnson, 1993] the author explains the difference between the ``ideal'' and the ``good'' way to develop frameworks and software in general. The ideal consists on three basic phases. First analyze the problem domain, learning abstractions and collecting examples of programs to be built. Then design abstractions that can be specialized to cover all the examples and derive a theory to explain these applications. And finally test the framework by using it to solve the examples. This ideal is impossible to follow thoroughly for two main reasons: it is very difficult and time consuming to do an exhaustive domain analysis, analyzing all the possible existing examples; and old applications work so there is no financial incentive to convert them to use new software. So a less-than-ideal-but-good way to develop a framework is to first pick two applications in the domain that are supposed to be solved using the framework; make sure that at least some of the developers in the team have developed applications for that particular domain; and divide project into three groups: a framework group, which both gives and takes software, considers how other applications would reuse the framework and develops documentation and training; and two application groups that try to reuse as much software in the framework as possible and complain about how hard it is to reuse.
In [Bosch et al., 1999] the authors give a different (though complementary) overview of the framework development process. First they distinguish two different activities in framework development: core framework design and framework internal increments. Core framework design comprises both abstract and concrete classes in the domain. The concrete classes are intended to be invisible and transparent to the end user (e.g. a basic storage utility) while the abstract classes are either intended to be invisible or to be used through subclassing. On the other hand framework internal increments build additional classes that form a number of class libraries. They capture common implementations of the core framework design and they can be either subclasses representing common realizations of the concepts captured by the superclasses or a collection of classes representing the specification for a complete instantiation of the framework in a particular context. A final application built from the framework consists of some core framework designs, the framework internal increments and an ``application-specific increment''.
In this model, the main phases in the development are: (1) a framework development phase that is usually the most effort-consuming phase and is aimed at producing a reusable design in a particular domain; (2) a framework usage or instantiation phase where applications are developed; and (3) a framework evolution and maintenance phase.
A number of activities can be identified in the first development phase, namely domain analysis, architectural design, framework design, framework implementation, framework testing an application testing. When determining the domain scope there is a problem of choosing the correct size: if the framework is too large, many specialists maybe needed in the team and the process may become long and expensive; if the framework is too narrow it may have to be tailored for every new application that comes up. Since the framework may be used in many, sometimes unknown ways, it may simply not be feasible to test all aspects of the framework. Since the framework relies on some parts implemented by the user it may be impossible to test completely before its release.
In the framework usage phase, the main activities involved are: domain analysis, architectural design, framework design, framework implementation, framework testing an application testing. In this phase an important question is to be faced. If an error in the framework is found when developing an application: who is going to fix the error in the framework? and, should the applications that are working and are apparently not affected by this error upgrade to the latest release of the framework?
It is also interesting to take a look at how a company such as the Swiss Ericsson models the framework development process. Ericsson Software Technology Frameworks have a template methodology that is instantiated with every new framework design and that can be summarized in the following guidelines (see [Landis and Niklasson, 1995]): A list of requirements on at least two applications should be provided together with a list of requirements on the framework. A list of future requirements should also be provided. The project team should include members with knowledge of each application and a member with knowledge on framework design. Information should be gathered from as many sources as possible. Requirements and use cases should be separated into framework-specific and application-specific and they should also be divided into functional and non-functional. High-level abstractions should be identified, preparing for the identification of the framework. But only abstractions that are in the framework domain should be introduced and afterwards they should be named the same in the static model. Existing solutions should be examined and large frameworks should be structured into sub-frameworks. A static model for each application should be developed then introducing abstractions common to several applications into the framework. Using graphical notations the project should be presented clearly to all project members. Subsystems should have high cohesion and little coupling. Finally existing frameworks should be studied trying to reuse as much design as possible.
And according to the previously mentioned Taligent, the process for developing frameworks must observe four important guidelines that can be understood as a summary of the previous list [Adair, 1995]:
2004-10-18