Hello, I’m back once again with a post about IT. If you thought it’s related with my thesis you guest it! We handed our thesis in some 4 weeks ago with great success. However all the advisory board and the judges suggested us to improve some very specific parts of it so it gets good enough to apply for honors. So this post has to do with the concept framework and the things it involves. It’s important to note that I write about frameworks with a technical domain, and that non-technical domain frameworks require a different approach in their development process.

What is a Framework?

According to “Design Patterns” (E. Gamma et al., Addison-Wesley, 1995) a framework is “a set of cooperating classes that make up a reusable design for a specific class of software”. However, as we can see later in this post, the framework is not only classes, therefore I would say:

Among the components of a framework we find loads of documentation, tools, usage examples, source code and of course classes (assuming that we are working with an OO

Why use a Framework?

There are many reasons for considering using frameworks, however this is my top 5:
1- Frameworks offer solutions to common problems in a specific area. That means that someone else faced the same requirements that your project has, and not only once, therefore that person created a framework so he could have all that common and low level functionality in a single place where it’s easy to maintain, improve and reuse. Thanks to this effort users of the framework can focus on their application’s specific and unique requirements.
2- Frameworks are bug-free. We wish this were fully true, but is not. However framework developers commit to a continuous maintenance, improvement and bug cleaning of their frameworks (especially the ones managed by open source communities). This is something that would require a company’s best resources to keep up due the abstraction level and strategic role of a framework.
3- Frameworks can be customized. They can and must be customizable otherwise they would constrain their usage very much. This customization is done through extensibility of the classes and components.
4- Frameworks rely on design patterns. The nature of a framework tells that it will be shared and studied by as many people as users (developers) can the framework get to use itself. Then, it’s required to use design approaches of easy understanding by the users: well known patterns (this is an example of a patterns’ listing).
5- Frameworks are well documented. Again, framework users need to be able to understand every single issue in the framework, and beside design patters, we’ll find documentation in the form of models, examples and even source code. It’s important to notice: they all must be synchronize and updated to the latest change in the the framework.

There are also some cons when using frameworks
1- Code Bloat. When a framework covers a broad domain or when the application doesn’t take full advantage of the framework there are loads of unused code, that at some point can be loaded in memory and ultimately decrease the performance of the application.
2- Time-trade in comparing and learning frameworks. It takes a big deal of time to find the right framework to use. This time is spent in evaluating and learning about the different frameworks. Some authors say this time can equal the time spent in design and coding of the project’s own solution. However a short analysis of the matter shows that:
– This time will be shorter every time (and the decision lead to the same frameworks) as the company specializes in certain domain for applications.
– The continuous development of the framework by the community is an asset to the company. Which means improvement of the frameworks without spending time in analyzing, designing and implementing these improvements in-house (taking into account all the input from different projects that a public framework receives).
3- Late learning of the framework. The up-front time spent in learning the framework is never enough to get to know every single detail of it. So it’s the case there are very specific situations where a framework makes assumptions about what should have been done before and what should happen next. This things happen to be not very well documented. The case is worse when the framework restricts certain task to be only implemented the way the framework defines it and not leaves a way for the user to do it his way.

Characteristics

– Involves a number of components: It could be abstractions like classes, interfaces and data types; also script files, configuration files and others.
– The components work together: Each of the components is related with one or more of the others. And in other of accomplish each task some of them have to collaborate.
– The components and what they do are reusable: A framework provides backbone business logic (common to several scenarios and conveniently customizable) involving many of the components in the framework, state or stateless. This logic and the components involved are reusable.
– Imposes a methodology: It’s structure makes it necessary to work in certain way to set it up, the obtain references to objects, etc. This influences the development methodology used to develop the application to some degree. When the framework plays the central role in the entire application the framework’s methodology shapes the project’s methodology (ie: the development of web applications with JSF requires the UI developer to fully use the framework in contrast with developing with plain JSPs).
– Focus on the application requirements: Once well understood and spike tested, the framework allows the developers to focus on the implementation of the application requirements.
– Addresses a specific area: It must address a limited domain, otherwise its development and maintenance would be very expensive or it ends up being very general that gives not significant value to the users. Focused frameworks try to deal with a limited scope and make it easy to extend the framework if needed.
– Provides extension points: This is the way for providing limited-scope frameworks with mechanisms for their further development by any user.
– Heavily rely on design patterns: As a framework is used and is suppose to be easily understood by many people, it’s convenient to have a design based in widely known patterns. This way developers can understand better every design decision and purpose, very necessary for the customization and extension processes.

Framework -vs- Library

A framework is different to a library because the library is a collection of classes (functions is a non-OO environment) and interfaces that are not necessarily related to each other, can work separately and can work with completely different domains.

Framework Development

The development process of a framework is very much the same than developing any other kind of software project. However there are some specific things to them:
– Documentation: The development process must stress the user-friendly documentation as this goes to the user along with the framework binaries or source code. This documentation is more extensive than in other projects and it’s necessary to be fully synchronized with the implementation. Usage samples (source code of a facade application using the framework) are considered being part of the documentation therefore must be included in the development process.
– Testing: As frameworks are suppose to be bug-free extensive testing is required in many ways. Also, as the framework is adopted by users, it’s important to establish ways to get feedback (as bug reports, features requests or even code patches) as the everyday usage of the framework is the best test procedure. However a minimum level of quality is required before any major version release, for this purpose unit testing and test cases are the de-facto standard.

References
– Carey J., Carlson B. Introduction to Developing Object-Oriented Frameworks. http://www.awprofessional.com/articles/article.asp?p=27123&rl=1
– E. Gamma et al. Design Patterns. Addison-Wesley, 1995