The association of requirement patterns to software patterns enables the possibility to make the transition from the requirements level, to the architectural one. This mapping process consists in selecting the most appropriate software pattern, to support a certain requirement pattern. This selection process is performed by analyzing how the software patterns support the requirement patterns.
2.7.1
Selecting Patterns for Requirements
The selection of the appropriate software patterns to support an architecture can be performed by analyzing the requirements information. This is only natural, since requirements describe the desired features in the final solutions, and patterns contain a set of contributions to the solutions in which they are integrated. Usually, the selection of software patterns, based in requirements specification, is performed through manual processes [46, 18].
Of special interest is the systematic approach presented by Bass et al. to select patterns, in order to support usability [4]. High level requirement specifications are decomposed into smaller components (scenarios), which can be analyzed at a lower level. Patterns are characterized by
2.7. FROM REQUIREMENT PATTERNS TO SOFTWARE PATTERNS 35
their benefits to usability, and the composition process consists in selecting the most appropriate benefits to support a certain scenario. Bass et al. approach, despite being designed to support usability (patterns), can be adapted to support software and requirement patterns. Decomposing the patterns to lower level components, enables the possibility to compare their concerns and contributions, thus, supporting a matching process.
In order to have an automated process, it remains to provide a systematic approach to analyze the relations between requirement patterns concerns and software patterns contributions.
2.7.2
Relating Requirements
In the Non-Functional Requirements (NFR) area it is possible to find several works addressing the interactions among several requirements (see [86] for a survey). It is known that requirements interact between them, not only affecting the final solution, but also other existing require- ments [17, 118]. A special kind of interaction is the conflict. Conflicts denote contradictory concerns among different requirements, meaning that when a requirement is set, it conflicts with the objective of other requirements defined in beforehand [33, 9].
The identification of conflicts between requirements is based in the objectives of each requirement, and how each contributes to the solution. Mairiza et al. present a systematic approach to analyze conflicts between requirements [85]. In that approach, requirements are described by their types, and their interactions are analyzed. Such results in a table of conflicts, as presented in Table 2.2. In the table, the symbol X means an absolute conflict, * a relative conflict and O no conflict. The conflicts for the remaining relationships (empty cells) are unknown.
Table 2.2: Example of conflicts between requirements (adapted from [85]).
NFRs Functionality Interoperability Maintainability Performance Portability
Functionality O * *
Interoperability X
Maintainability * O X
Performance * X X * X
Portability X
The methodologies to analyze conflicts on non-functional requirements can be adapted to support the analysis of conflicts in patterns. If patterns are described at the same level of abstraction (corresponding to the NFRs types), it is then possible to generate a similar approach to clearly define the interactions between patterns, achieving then a systematic approach. It remains then to formally specify, at the same level, characteristics of both kinds of patterns (i.e. requirement and software), in order to support one such approach.
2.7.3
Forces
Software patterns can be described by their low level impact in the solutions. In the patterns community, there is a term to describe those low level characteristics, the forces. The term force is used to denote (c.f. Buschmann [15]): “any aspect of the problem that should be considered when solving it, such as Requirements (what the solution must fulfill), Constraints (things to consider), and Desirable properties (that the solution should have)”.
In general, forces represent the pros and cons of adopting a specific pattern. They may com- plement or contradict each other. For instance the extensibility of a system might contradict minimization of its source code, since a generic solution tends to be more complex in terms of code. In Buschmann’s words [15], “forces are the key to solving the problem. The better they are balanced, the better the solution to the problem”. Software pattern catalogs tend to describe the forces (e.g. intent) for each cataloged pattern [15, 41]. The application of different patterns, and the effects of the forces on the resulting application, are usually presented in a tabular format, where for each force is shown the impact on other forces. This format is usually called the forces matrix.
Requirements patterns, can also be described by the forces that compose them. Specifically, it is possible to analyze their goals, which can be characterized by their forces, similarly to non functional requirements [46].
2.7.4
Discussion
It is possible to find several approaches to map requirement patterns to software patterns. Ex- isting works focus in the analysis of low level aspects of both requirements and patterns, in order to perform their matching. However, approaches tend to not formalize the information, therefore presenting hard to automate approaches. In the non-functional requirements area, approaches have been proposed that relate requirements by their contribution (either positive or negative to other requirements) in order to analyze their conflicts, and produce a conflicts table. Describing requirements at the same abstraction level is also proposed to enable their comparison.
Based in the presented approaches, it is proposed to analyze the viability of specifying require- ment and software at the same level of abstraction. Of special interest are the forces, which can be used in order to analyze conflicts, and support an automated process. The objective to have a mapping process from requirements to software patterns consists then in selecting the most appropriated software pattern, based in its contribution for the requirement pattern.