Opinión sobre la institución

The claimed advantages of using frameworks for application development are many. These include modularity, reusability, extensibility and Inversion of Control [52]. In this chapter we will discuss our experience using open source frameworks and the effect it has had on the development of the Joly application.

During the development process we have encountered some obstacles that have diminished the advantages that were intended by the framework.

8.4.1 Problems related to the development process

Although framework developers claim that it is feasible to develop complex applications with little development effort with the use of a framework, we have encountered some aspects that should be taken into consideration when deciding to use a framework in the development process.

When using a framework it is crucial to understand all the concepts of the framework and its architectural basis, to be able to develop an application that conforms to it. We are of the opinion that for a framework to bring benefits to the development process, it is necessary that the developers have a strong understanding of the basics of the framework and a good

knowledge of the details. Further, to acquire this type of understanding, it is necessary with hands-on experience with the chosen framework. This is because the quality of the

documentation of the various frameworks varies, and it’s often necessary to read

documentation from many different user groups to get a full description of the details of the framework. The documentation often shows signs of the writers preferences in which domain to apply the framework, and the experience the writer has with the framework in question can also be different from that of another user. For instance, when studying the Spring

framework, a lot of the documentation assumed that the reader was familiar with another framework, most often the Struts framework because it was one of the first frameworks to strike root in the Java web application field. Since neither of us had past experience with frameworks, learning a framework’s concepts by comparing them to other frameworks did not give a full understanding of what it was intended to do.

We have experienced that frameworks are hard to learn without trying them out in a real application. Thus the Joly application has been built with a “learn as you code” approach, and may be suffering from design flaws because of this.

Another problem associated with framework documentation is that open source frameworks are constantly evolving. The documentation is usually then the last artifact to be updated.

Thus the documentation of new features, and deprecated features, is poor. In these cases it is almost always necessary to refer to the API documentation, which gives little information of the use of the features.

Frameworks and patterns are claimed to be reusable software expertise. We do not question this claim because it is obvious that well established patterns, and frameworks based on those patterns, solve problems common to many application domains. However, how well the framework communicates this software expertise is more important, because the lack of such introduces side effects that can diminish the claimed advantages of the framework. For

instance, if learning the framework demands an effort that exceeds the effort of developing an application without a framework, it clearly lacks good communication and the software expertise is hard to reuse.

When the goal of starting the development of a system is a rapid development process, to get a prototype up and running as soon as possible, we do not recommend a development team with no experience in frameworks to incorporate a framework in the development process. For the DHIS development project it is more important to achieve the non-functional requirements of the system, thus teaching the development team a set of useful frameworks can be very successful. The DHIS development team in Oslo has recognized the need to teach the developers in the relevant technologies and frameworks. In 2005 the University of Oslo started a course that covers open source development and Java frameworks where the students are introduced to the different technologies by solving relevant assignments. These developers will learn the frameworks by hands-on experience and thus will be fit to use the framework in an extensible development process. Therefore, we can recommend the use of frameworks in the development of DHIS, because the claimed advantages of frameworks will probably take effect.

The problems that arise early in the development process associated with frameworks are:

Determining the applicability of a framework: The process of deciding whether a certain

framework is appropriate for the application in mind is comprehensive. In our case a full evaluation of the available frameworks would have reached beyond the scope of our study,

and thus the choice of framework had to be based on simple criteria. Consequently we can not be sure that the choice of frameworks for our application was the most suitable.

Estimating development progress: Because of the effort related to studying the frameworks

as mentioned, it is hard to estimate the development progress of a project. For a small application, a framework-based approach will on average be slower than that of a traditional approach. We are of the opinion that this will be the case even with framework experienced developers, because of the effort needed to set up and integrate the various tools. For a larger and more complex application however, this time consuming start up effort will pay off and increase the overall efficiency. A second problem is that it is hard to foresee whether a framework will support all the requirements of the application. A shortcoming of the

framework may be exposed at any time during the development and require an effort in trying to figure out a solution. By this time a considerable amount of time has probably been used to figure out the shortcoming, so in contrast to a traditional approach, a double amount of time may have been spent to resolve the problem.

Estimating application size: When developing applications using frameworks, dependent

packages may not be introduced before specific requirements are implemented. Open source frameworks often use other open source tools to solve well-known problems. Some may be included in the framework release and some are not and thus needs to be added by the developers. Also, because a framework is designed to resolve general problems, many packages may need to be included to resolve a smaller specific problem.

8.4.2 Problems related to maintenance

In chapter 5 we stated that we could customize a framework to our application by inheriting and instantiating selected framework classes. The problem with Spring being such a flexible framework is that it has a considerable amount of available classes. To consider each class in order to select the most appropriate to use in a specific scenario, became a hard task and we have probably not succeeded in always using the correct Spring classes. This may have resulted in us assigning responsibility to wrong classes (not intended to be assigned this responsibility by the Spring developers), thus not conforming to the framework. For new developers of the application, it can be hard to understand the application design if they

expect to find implementations of classes they know have the responsibility of a specific problem.

Problems we see may occur after the release of a framework-based application are:

Maintaining framework conformity: By looking at the above mentioned scenario in

reverse, an application developed by developers experienced in frameworks, may be subject to new developers not conforming to the frameworks intentions. This introduces a

maintenance problem similar to that of design patterns. If developers break a pattern it is possible that they have removed the application’s support for a non-functional requirement. The same applies to frameworks because they are based on patterns and offer

implementations that conform to them, so misusing a framework’s classes can introduce side- effects that have influence on the non-functional requirements they were intended to solve.

Maintaining framework dependencies: Using open source frameworks introduces a number

of third-party dependencies. Most frameworks incorporate one or many other frameworks or libraries to accomplish a common task. If the framework developers are not directly tied to the developing of these third-party tools, the dependencies can be difficult to maintain. A good tool for incorporating different frameworks will lessen the complications, such as the Spring framework which is designed for framework integration.

Discontinuance of requirement support: A framework can evolve in a different direction

than the application using it, possibly into a different domain, and thus not supporting the requirements of the application’s domain. This means that the framework and the application does not evolve together, inhibiting the evolution of the application or forcing the developers to maintain the framework themselves.