The framework development process.
There are some documented methodologies for developing a framework. Most of them, however, admit the fact that the goal is to identify abstractions with a bottom-up approach: start by analyzing existing solutions and be able to generalize from them. Regarding the adoption of a framework development process
It’s important to keep in mind that any framework usually starts as a white box framework and ideally evolves into a black box. It is also important to understand that developing a framework is more difficult than developing an 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 of developing frameworks and software in general.
The ideal consists of three basic phases. First analyze the domain of the problem, 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, using it to solve the examples.
This ideal is impossible to follow completely for two main reasons: it is very difficult and time consuming to do a thorough domain analysis, analyzing all possible existing examples; and old applications work so that there is no financial incentive to convertthem to use the new software. Thus, a less-than-ideal-but-good way to develop a framework is the first to take two applications in the domain that is supposed to be solved using the framework; make sure that, at least some of the developers on the team have developed applications for this particular domain; and the project is divided into three groups: a group-framework, which both gives and takes software, considers how other applications would reuse the framework and developsdocumentation and training; and two groups of applications that try to reuse as much software as possible and complain about how difficult reuse is.
In [Bosch et al., 1999] the authors give a (albeit complementary) different view of the framework development process. First they distinguished two different activities in framework development: core framework design and internal framework increments. The core design of the framework comprises both abstract and concrete classes in the domain. Concrete classes are intended to be invisible and transparent to the end user (for example, a basic storage utility) while abstract classes are either intended to be invisible, or to be used through subclasses. On the other hand, internal increments build additional classes that form a series of class libraries. They capture common implementations of the core design of the framework and they can be either subclasses representing common achievements of concepts captured by the superclasses or a collection of classes representing the specification for the complete instantiation of the framework in a particular context. The final application built from the framework consists of some core drawings of the framework, the internal increments of the framework and an application-specific "increment".
In this model, the main stages of development are:
(1) the development phase of the framework is usually the most effort consuming phase and is intended to produce a reusable design in a particular domain;
(2) use of the framework or instantiation phase where applications are developed;
(3) the evolution of the framework and maintenance phase.
A number of activities can be identified in the first phase of development, namely domain analysis, architectural design, framework design, execution framework, testing the framework with an application test. When determining the domain scope there is a problem of choosing the correct size: If the structure is too large, many experts may be needed in the team and the process may become expensive and long; if the framework is too narrow, may need to be adapted for each new app that comes up. Since the framework can be used in many ways, sometimes unknown, 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 use phase, the main activities involved are: domain analysis, architectural design, framework design, framework execution, testing the framework with an application test. At this stage there is an important issue to be addressed. If an error in the framework is found when developing an application: who will fix the error in the framework? and, if the applications that are working and are not apparently affected by this error update to the latest version of the framework?
It is also interesting to take a look at how a company, such as Ericsson’s Swiss framework models in the development process. Ericsson Software Technology Frameworks has a model methodology that is instantiated with each new framework project and can be summarized in the following guidelines (see [Landis and Niklasson, 1995]): A list of requirements in at least two applications must 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 of the framework design. Information should be collected from as many sources as possible. Requirements and use cases should be separated into specific-framework 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 domain of the framework should be introduced and then they should have the same name in the static model. Existing solutions should be examined and large frameworks should be structured in sub-frameworks. A static model for each application must be developed, then the introduction of abstractions common to various applications for the framework. Using graphical project notations should be presented clearly to all project members. Subsystems should have high cohesion and low coupling. Finally existing frameworks should be studied trying to reuse both the design as possible.
And according to the aforementioned Taligent, the process of developing frameworks must observe four important guidelines that can be understood as a summary of the previous list [Adair, 1995]:
• Derive frameworks from existing problems and solutions.
• Develop small frameworks with focus.
• Build frameworks that use an iterative process driven by customer participation and prototyping.
• Treat frameworks as products, providing documentation and support, and planning for distribution and maintenance.
And related to the framework development process it is finally interesting to note that as Opdyke points out [Opdyke, 1992, Opdyke and Johnson, 1990] one of the main features of a framework is that it is designed to be refined, good structures are usually the result of many design iterations and a lot of work involving structural changes sometimes.
Source: Here is the original text of this humble translation where you can find more information about frameworks.
You need to know how to develop software in all aspects, with professionalism and experience. You cannot do something like this without having a great mastery of all the development techniques and understanding the real need for what you want to solve. Very few people have these characteristics. The overwhelming majority will only consume them. http://answall.com/q/17501/101
– Maniero
It is not so wide. Since they have suspended, I will summarize in a comment: to) You need a problem that can be solved by a framework, and a deep knowledge of this problem. It is more important to know the problem well than to know the solution techniques beforehand. b) Make sure that there is no optimal solution to the problem yet; make a flexible solution because you cannot predict 100% of the use you will make of it; accept help. c) Use the libraries that solve subsets of the general problem your framework aims to solve, if they are good enough for your purpose.
– Caffé
@Caffé thank you very much man!! Helped a lot !!
– Pena Pintada