Patterns for Understanding Frameworks

The introduction of reuse in a software development process implies splitting the traditional software life cycle into two interrelated cycles: one focused on developing reusable assets, and another focused on searching and reusing reusable assets already developed.

A framework is a reusable design together with an implementation. It consists of a collection of cooperating classes, both abstract and concrete, which embody an abstract design for solutions to problems in an application domain [JF88][Deu89][FS97b].

In the particular case of framework-based application development, the traditional life cycle can be organized in: a framework development life cycle devoted to build frameworks, corresponding to the abstraction phase of software reuse; and an application development life cycle (also known as framework usage) devoted to develop applications based on frameworks, corresponding to the selection, specialization, and integration phases of software reuse.

Although the activities of framework development and application development are often separate and assigned to different teams, the knowledge to be shared between them is large, as the design of a framework for a domain requires considerable past experience in designing applications for that domain.

In application development, frameworks act as generative artefacts as they are used as a foundation for several applications of the framework’s domain. This contrasts with the traditional way of developing applications, where each application is developed from scratch. The most distinctive difference between the traditional and the framework-based development of applications is the need to map the structure of the problem to be solved onto the structure of the framework, thereby forcing the application to reuse the design of the framework. The positive side of this is that we don’t need to design the application from scratch. But, on the other hand, before starting application development, we need to understand the framework design, a task that sometimes can be very difficult and time-consuming, especially if the framework is large or complex, and is not appropriately accompanied with good documentation or training material.

The figure above shows a simplified view of framework-based application development that relates the artefacts, activities, and roles most relevant for the topic of the patterns presented in this paper – framework understanding. Because understanding frameworks is of major importance for application developers, in the figure, the activity is assigned exclusively to that role, but in fact it can be also relevant for framework selectors, original framework developers (especially of large frameworks), framework maintainers, and developers of other frameworks, although not with the same degree of importance.

In relation to the other activities depicted, there are pattern languages addressing their own challenges and problems, of which we refer “Evolving frameworks: A pattern language for developing object-oriented frameworks” [RJ96], regarding design, implementation and evolution activities, and also “Patterns for Documenting Frameworks” [AD05b][AD06][AD07], regarding documentation activities.

Therefore, this paper contributes patterns to a pattern language focusing on problems of understanding frameworks (white-box, black-box or gray-box), which must be properly managed before being able to use frameworks effectively.

White-box frameworks rely heavily on inheritance and dynamic binding in order to achieve extensibility. Although white-box reuse is the hardest way to use a framework, it is by far the most powerful.

Black-box frameworks are the easiest to use, because they are structured using object composition and delegation rather than inheritance. On the other hand, black-box frameworks are the most difficult to develop, because they require the definition of the right interfaces and hooks able to anticipate a wide range of application requirements.

Most real-world frameworks combine black-box and white-box characteristics, being thus called gray-box frameworks. They allow extensibility both by using inheritance and dynamic binding, as well as by defining interfaces. Gray-box frameworks are designed to avoid the disadvantages of black-box frameworks and white-box frameworks.

Although some of the problems here addressed could also be common to large or complex software systems, frameworks are specifically designed to be easy to reuse, thus adding special needs from the point of view of learning and understanding.

The pattern language comprises a set of interdependent patterns aiming to help users become aware of the problems that they will typically face when starting to learn and understand frameworks. These patterns are targeted for framework users especially novices. The patterns were mined from existing literature, lessons learned, and expertise on using frameworks, based on previous studies and literature reviews of the authors on the topic [Agu03][Flo12].

The pattern language outlines a path commonly followed when learning and understanding a framework. As many frameworks can be very difficult to learn and understand, completely or in detail, these patterns aim to expose the tradeoffs involved in the process of understanding a framework, and to provide practical guidelines on how to balance them to find the best learning strategy for each specific person (learner or framework user) and context.

The problems addressed by the patterns are basically raised by the following questions:

• What do I need to understand about the framework to accomplish my task? What kind of knowledge do I need? More concrete or abstract? At code level, design level, documentation level?
• How can I acquire the knowledge I need? Which learning strategy should I adopt? Which one is best for my needs?
• Which kinds of tools can I use to gather, organize, explore and preserve the knowledge I value most?

According to [But98], framework reuse can be divided into categories according to the re-user’s interests, whether a framework selector, an application developer, a framework maintainer, or a developer of other frameworks. These categories range from selecting, instantiating, flexing, composing, evolving and mining a framework. For the scope of the pattern language presented in this paper, only the most commonly used will be addressed: selecting, instantiating and evolving.

To describe the patterns, we have adopted Christopher Alexander's pattern form: Name-Context-Problem-Solution-Consequences [(:ref:AIS77]. We’ve also added a Rationale section and a See also section, where known uses and further reading directions can be found. Before going to the details of each pattern, we will briefly overview the pattern language with each pattern’s intent and a map (Figure below) showing their relationships.

SELECTING A FRAMEWORK . This pattern allows deciding whether or not to select a framework, after evaluating its appropriateness for an intended application domain.

INSTANTIATING A FRAMEWORK . This pattern shows how to learn about instantiating a framework in order to implement an application.

EVOLVING A FRAMEWORK . This pattern shows what steps should be taken to learn how to evolve a framework.

DRIVE YOUR LEARNING . This pattern shows how to plan your learning process throughout the task of understanding a framework.

KNOWLEDGE KEEPING . This pattern shows how to preserve the acquired knowledge about a framework.

UNDERSTAND THE APPLICATION DOMAIN . This pattern enables the learner to know what is the application domain covered by the framework.

UNDERSTAND THE ARCHITECTURE . This pattern shows the learner how to find architectural knowledge about the framework.

UNDERSTAND THE DESIGN INTERNALS . This pattern tells the learner how to look for knowledge about the design internals of the framework.

UNDERSTAND THE SOURCE CODE . This pattern helps to understand how to identify where in the source code are the important parts that enable the developer to implement the application.