EMPRESS Pattern-Based Architectural Analysis and Design

Design

In the context of the EMPRESS project next to the framework for requirements (cf. Section 2.1.3) also a method for pattern-based analysis and design of software ar- chitectures was developed [KB03]. The EMPRESS requirements framework already relates quality attributes to non-functional requirements, metrics, and means. Be-

yond this, in the architectural design method, scenario descriptions and patterns are related to the means and thus to the quality attributes. Abstract scenarios comprise a number of stimulus/response pairs. Concrete scenarios belong to one alternative of the abstract scenario and describe the expected behavior that is guaranteed by a pattern. Patterns are related to a certain problem, which is solved by the pat- tern, a rationale why the pattern solves the problem, and a description of the actual solution. The corresponding metamodel is depicted in Figure 2.4.

Quality Model Quality Attribute 1 * Metric 1 * 1 * subcharacteristic Means 1 * Abstract Scenario * * 1 * Stimulus Response * 1 1 * Concrete Scenario 1 * Pattern * *

Problem Rationale Solution

1 * 1 * subcharacteristic 1 * influence 1 * * * 1 * 1 * 1 * 1 * satisfies uses specializes * conflicts *

Figure 2.4: The EMPRESS metamodel for design by [KB03]

The method description includes quality models for the quality attributes per- formance, maintainability, and reliability with related metrics, means, as well as a description of patterns for reliability and safety. Besides, the EMPRESS design method describes an iterative process with seven steps:

1. Selection of scenarios and planning of the next iteration, 2. Definition of evaluation criteria,

3. Selection of means and patterns, 4. Instantiation of patterns,

6. Evaluation of the architecture; and if the architecture is not already ok, 7. Analysis of the problem and return to step 1.

Evaluation Many design methods consider architectural design as a creative pro- cess, which is for the most part based on experience. The EMPRESS method for pattern-based design is a good approach to improve this process with defined activ- ities. It is especially concerned with quality attributes. However, the several design activities of the method are described rather sketchy in comparison to the estab- lished metamodel. An open question, which remains when applying the method, is, how conflicts between quality attributes are resolved. The method implicitly con- tains the assumption that an appropriate pattern can be found by selecting means and comparing the related scenarios with the requirements. Trade-offs for quality attributes are not considered. With its steps the method has similarities to ADD combined with ATAM but without the restriction of the recursive nature. Neverthe- less, it does not contain guidance for the specification of concrete components and interfaces either. Unfortunately, only three quality attributes are described with subcharacteristics, metrics, and means in the quality model; evolvability is not in- cluded. Furthermore, there are inconsistencies with the EMPRESS framework for non-functional requirements, for example concerning maintainability. This demands for a revision and extension regarding evolvability.

2.2.5

Quasar

Quasar—an acronym for QUAlity Software ARchitecture—is an architectural design method that was developed in industrial practice [Sie04]. The method combines best practices and principles for a good component-based software architectural design. It uses so-called software categories for the identification and structuring of software components. All components are based on the standard categories 0, A, T, and R. For a specific application design, these categories are refined in a category model.

A-components are application specific but independent of technical issues. They contain the application logic and entity classes for the realization of the domain functionality. T-components cover technical knowledge about a system, and they frequently provide an application programming interface (API), for example, for database connectivity or for graphical user interface (GUI) elements. They are in-

dependent of specific application functions. Software of the category 0 is neutral con- cerning the application’s functionality and independent of technical aspects, hence, it creates no undesired dependencies. Modules, classes, and interfaces with a high degree of reusability belong to 0-software, for example, class libraries. R-software refers to representation; it establishes a connection between A- and T-components, however, minimizing the dependencies between them. This is achieved by transfor- mation, for example, to external data presentation formats like XML. Other ways of directly connecting or even mixing A and T—the so-called AT-software—are pro- hibited, because they would re-introduce stronger dependencies.

In contrast to other methods, as for example ADD, Quasar defines a fine-grained sequence of steps for the detailed specification of components and their interfaces. It was developed further in [Bod08] to establish three basic steps: component identifi- cation, interface specification, and inner structuring. These steps help to move from analysis to architectural design in a more precise way than other design methods. Evaluation Quasar can be considered as a good architectural design method for component-based design. The use of software categories helps to structure the re- quirements, and thus to bridge the gap between analysis and architectural design. The identification of components with the help of software categories results in the reduction of dependencies by a separation according to the responsibilities and the knowledge covered by the components. Moreover, the specification activities for interfaces are strongly concerned with decoupling. In this way the design according to Quasar, especially the distinction between application-specific and technology- specific software, leads to good modularization, decoupling, and separation of con- cerns. Therefore, it provides high architectural quality with some benefits for evolv- ability. However, the method does not especially consider the implementation of non-functional requirements. Nevertheless, the fine-granular design steps for com- ponent and interface specification can complement other design methods as ADD and facilitate a precise definition of rules for the establishment and maintenance of traceability links [BR09].