Using Software Architecture Analysis Methods

One of the observed problems with the above-mentioned software architecture analysis methods is that these approaches do not distinguish between conventional architecture concerns and architectural concerns that crosscut multiple architectural components. Using the above-mentioned software architecture analysis methods, it is possible that prospective crosscutting concerns might not be identified as aspects and ultimately remain uncertain at the software design and programming level. Such a situation will ultimately lead to tangled code in the system. The quality assurance that the architecture analysis methods attempt to confirm will still be obstructed.

To overcome this issue, B. Tekinerdogan [93] proposed the Aspectual Software Architecture Analysis Method (ASAAM). ASAAM evaluates the architectural aspects with respect to the existing software architecture design. The Software Architecture Analysis Method (SAAM) provides the foundation for ASAAM and includes an explicit mechanism for describing architectural aspects and tangled components.

ASAAM consist of 5 steps
: 

1. Candidate Architecture Development
2. Scenarios Development
3. Individual Scenario Evaluation and Aspect Identification
4. Scenario Interaction Assessment and Component Classification
5. Architecture Refactoring. The main purpose of ASAAM is to identify architectural aspects, which make it a complementary technique to other architecture analysis methods.

Another software architecture analysis method that explicitly treats concerns as first-class entities is the Concern Oriented Software Architecture Analysis Method (COSAMM). COSAMM is an iterative method for assessing and transforming software architectures. It’s inspired by the ASAAM. COSAMM makes use of Design Structure Matrices (DSMs) and Domain Mapping Matrices (DMMs). DSMs are used for concern identification and dependency analysis of architectural modules, while DMMs are used to measure scattering and tangling.

COSAMM consists of 3 phases:
 

1. Preparation Phase
2. Analysis Phase, and
3. Transformation Phase. The Preparation Phase results in the artifacts used in the COSAAM evaluation, such as candidate software architecture design and stakeholder concerns. The Analysis Phase of COSAAM involves a description and measurement of scattering and tangling of concerns and modules. The information provided during this analysis is used in the Transformation Phase, resulting in software architecture transformation.

Analyzing Software Architecture for Modifiability Using Scenario

Software modifiability is an important characteristic of software development, as software-extensive systems must be flexible with respect to evolving requirements, platforms, and other environmental pressures. Consequently, software change is inevitable, which results in software development spanning more than several years. According to G. Alkhatib, at least 60% of software lifecycle costs are associated with maintenance activities. Because of constant change, modifiability plays a key role in both current and future software technologies.

According to M.M. Lehman et al., the failure of a system to evolve results in its early decline. The environment in which software systems operate changes continuously. The expected future evolutions of these systems can be indicated if this change in the environment is properly assessed. Therefore, we must consider design solutions that can support the future incorporation of new and changed requirements. If the designed architecture is flexible enough to support different types of modifications, the required changes can be made easily. One problem, however, is the scarcity of techniques or tools that software architects can use to ensure that the ultimate goal of high modifiability has been achieved. Software architecture analysis can be performed to achieve this goal.

In software architecture analysis, the corresponding architecture of a system is analyzed to ensure that it fulfills customer requirements. Different software architecture analysis methods target different QAs, such as SAAM, ATAM, etc. The Architecture Level Modifiability Analysis (ALMA) is one such method that analyzes software architecture for modifiability.
ALMA (Architecture level Modifiability Analysis):
ALMA is a software architecture analysis approach which considers only the modifiability perspective of software architecture [67]. For a complete software architecture analysis, ALMA needs the support of certain other different architecture level analysis methods as well.

ALMA has the following characteristics:

• Focus on modifiability.
• Differentiate multiple analysis goals.
• Make important assumptions explicit.
• Provide repeatable techniques for performing the steps.

Architecture-level modifiability analysis can be used for various purposes. ALMA analyzes the following goals for architecture-level modifiability analysis: maintenance effort prediction, risk assessment, and comparison of candidate architectures.

ALMA consists of the following five steps:

1. Set goal.
2. Describe software architecture.
3. Elicit scenarios.
4. Evaluate scenarios.
5. Interpret the results.

Setting the goal: Determine the goal of the analysis is the first activity in architecture level modifiability analysis. The following mentioned goals can be chased in architecture level modifiability analysis:

• Maintenance Cost Prediction: Estimate the ultimate effort that is needed to modify the system to accommodate future changes.
• Risk Assessment: It is possible that the specified architecture is inflexible with respect to certain types of changes. This step involves identification of such possible changes.
• Software Architecture Selection: Compare two or more candidate software architectures with respect to certain requirements and select the optimal candidate.

Architecture Description: Different pieces of required information about the software architecture are collected in the second step of ALMA. The architectural information, on the basis of which the analyst evaluates the scenarios, is generally required for a modifiability analysis. Scenario evaluation consists of two steps: 1) analysis of the scenarios’ impact and 2) expressing this impact. Architecture-level impact analysis primarily serves to identify those architectural elements that are affected by a modifiability scenario. The architectural elements affected by a modifiability scenario include directly-affected and indirectly-affected components. Depending on the goal of the modifiability analysis, a measurement scale may be used to express the ultimate effect of such scenarios.

Change scenario elicitation: this step involves selecting different change scenarios to be used in the architecture evaluation step. The following two activities are involved in eliciting change scenarios:

• Identifying stakeholders to interview,
• Documenting the scenarios that result from those interviews, etc.

Change Scenario Evaluation: This step of ALMA is primarily used to evaluate the effect of the change scenarios on the candidate architecture. To evaluate change scenarios, the architects and designers need the cooperation of the analyst. The analyst determines the impact of change scenarios alongside the software architect and software designers in order to articulate the results in a manner suitable for our analysis goal. This is generally known as architecture level impact analysis. In general,

impact analysis consists of the following steps:

• Identify the affected components.
• Determine the effect on the components.
• Determine ripple effects.

The first step involves the identification of the directly and indirectly affected components that need to be modified to employ the change scenario. The second step involves the identification of the corresponding functions of the components that are affected by the changes. To determine the effect on certain components, we also need to consider the systems in the operational environment and their interfaces.

for the following reasons:

• There is a possibility for change propagation over system boundaries.
• The system may be affected by changes in the environment, or
• The environment may be affected by changes to the system.

The third step involves identification of ripple effects. These effects will occur as a result of certain modifications that are required. It is important to note that this ripple effect may be a recursive phenomenon. Since not all information is available at the architecture level, we may have to make assumptions about the occurrence of ripple effects.

Interpretation:
Once the evaluation of the change scenario is completed, the results must be interpreted, and conclusions about the software architecture are drawn. The system requirements and the goal of the analysis play a vital role in interpreting the results.

Did you like this example?

1292

54