Aspectual Software Architecture Analysis Method

Software architecture analysis methods aim to predict the quality of a system before it has been developed. In general, the quality of the architecture is validated by analyzing the impact of predefined scenarios on architectural components. Hereby, it is implicitly assumed that an appropriate refactoring of the architecture design can help in coping with critical scenarios and mending the architecture. There are however also concerns at the architecture design level which inherently crosscut multiple architectural components, which cannot be localized in one architectural component and which, as such, can not be easily managed by using conventional abstraction mechanisms. We propose the Aspectual Software Architecture Analysis Method (ASAAM) to explicitly identify and specify these architectural aspects and make them transparent early in the software development life cycle. ASAAM introduces a set of heuristic rules that help to derive architectural aspects and the corresponding tangled architectural components from scenarios.

ASAAM builds on the Software Architecture Analysis Method (SAAM) and applies scenarios to identify aspects. ASAAM is complementary to SAAM and includes explicit mechanisms for identifying architectural aspects and the related tangled components.  

It appears that there are several similarities between aspects and scenarios. First, aspects are crosscutting concerns, that is, concerns that interact over many components. In the same way, (indirect) scenarios also require changes to several components and can be said to ‘crosscut’ components. Second, aspects are relative to the problem description and the given decomposition of the design. Similarly, the categorization of scenarios into direct and indirect scenarios is completely dependent on the problem description and the given architecture design. Based on these observations we think that scenarios provide potential architectural aspects.

The basic activities for the ASAAM are illustrated in the following Figure.

Figure 1. Activities of ASAAM

ASAAM, like the SAAM, takes as input a problem description, a requirements statement and architecture descriptions. In addition to developing a candidate architecture and scenarios, ASAAM comprises the following steps:

1. Candidate architecture development

A (candidate) architecture design is provided that will be analysed with respect to the required quality factors and potential aspects.

2. Develop scenarios

This is similar to SAAM. Scenarios from various stakeholders are collected, which represent both important uses and anticipated uses of the software architecture.

3. Individual scenario evaluation and aspect identification

Scenarios are firstly categorized into direct and indirect scenarios. Complementary to SAAM, the scenario evaluation also searches for potential architectural aspects. The application of the heuristic rules will result in a further classification of the scenarios into direct scenarios, indirect scenarios, aspectual scenarios and architectural aspects. Aspectual scenarios are derived from direct or indirect scenarios and represent potential aspects. By aspect domain analysis the corresponding aspect for the scenario is searched and described.

4. Scenario interaction assessment and component classification

The goal of this step is to assess whether the architecture supports an appropriate separation of concerns. This includes both non-crosscutting concerns and crosscutting concerns, i.e. aspects. For each component both direct and indirect components are analyzed and categorized into cohesive component, tangled component, composite component, or ill-defined component.

5. Refactoring of architecture

Based on the scenario interaction assessment and component classifications a refactoring of the architecture is proposed. The refactoring can be done using conventional abstraction techniques, such as design patterns, or using aspect-oriented techniques. The architectural aspects and the tangled components are explicitly described in the architecture.

SAAM considers the set of scenarios to be complete when the addition of a new scenario no longer disturbs the architecture design. However, there is a risk that for a given set of scenarios this process will never be completed, that is, the architecture will need to be disturbed all the time. This may even the case if all the architectural components in the system are modular. The reason why the set of scenario analysis will not be completed is the fact that a scenario might include a potential architectural aspect. As we have described before, an architectural aspect is a concern that crosscuts across multiple architectural components.

In the ASAAM we have defined a set of heuristic rules to categorize scenarios into direct scenarios, indirect scenarios and architectural aspects. The heuristic rules are expressed using conditional statements in the following form:

IF <condition> THEN <consequent>

The condition part includes an artifact that is analyzed. In this context, an artifact is a work product in the software architecture design process. The basic artifacts in ASAAM are as follows:

ARCHITECTURE
PROBLEM DESCRIPTION
SCENARIO
ASPECT
COMPONENT.

As we will see, each of these artifacts are further specialized into intermediate representations to support the software engineer in processing the heuristic rules of ASAAM. The consequent part of each rule includes an action, which usually includes a transformation of an artifact to another artifact.

Figure 2. Scenario artifact diagram

The above Figure shows the scenario artifact diagram of ASAAM, which defines the relations among the heuristic rules and the scenario artifacts. The rounded rectangles represent artifacts, the labeled arrows the heuristic rules. The bold rounded rectangles represent the artifacts that are finally delivered. In the individual scenario analysis and aspect identification process the delivered artifacts are the following:

Direct Scenario, describes a scenario that can directly perform the provided scenarios. 

Indirect Scenario, describes a scenario which requires some changes to the component that it interacts with.

Aspectual Scenario, a direct or indirect scenario which is scattered over different architectural components and which cannot be captured in a single component.

Architectural Aspect, a well-defined concern transformed from an aspectual scenario based on the domain models derived from a domain analysis process.

The heuristic rules for scenario evaluation in ASAAM are shown in Figure 3. The rules are numbered from R0 to R6 and include the manipulation of the artifacts shown in the scenario artifact diagram in Figure 2 .

Figure 3. Heuristic rules for scenario evaluation

After scenarios have been classified ASAAM focuses on scenarios at individual components. Figure 4 shows the component artifact diagram in ASAAM which shows the relation between the various corresponding heuristic rules and the intermediate forms of component artifacts. ASAAM delivers the following type of components (bold rounded rectangles in the figure):

Cohesive Component, which is a component that is well defined and performs semantically close scenarios.

Composite Component, a component consisting of several sub-components that each perform a semantically close set of scenarios.

Tangled Component, a component that performs an aspectual scenario which is either directly or indirectly performed by the component.

Ill-defined Component, a component that includes semantically distinct scenarios but which cannot be decomposed or does not include an aspectual scenario.

Further, the artifacts Component, and Tentative Tangled Component represent the intermediate artifacts that help to identify the above four types of components. The heuristic rules R7 to R18 are shown in Figure 7.

Figure 4. Component artifact diagram