Software Engineering: Assessing Alternative Architectural Design | An Architecture Trade-Off Analysis Method | Architectural Complexity | Architectural Description Language | An Architectural Design Method

Assessing Alternative Architectural Design

Design results in a number of architectural alternatives that are each assessed to determine which is the most appropriate for the problem to be solved.
Two different approaches for the assessment of alternative architectural designs.

(1) The first method uses an iterative method to assess design trade-offs.
(2)The second approach applies a pseudo-quantitative technique for assessing design quality.

An Architecture Trade-Off Analysis Method

The Software Engineering Institute (SEI) has developed an architecture trade-off analysis method (ATAM) that establishes an iterative evaluation process for software architectures.
The design analysis activities that follow are performed iteratively.
1. Collect scenarios : A set of use cases is developed to represent the system from the user’s point of view.
2. Elicit (Bring out) requirements, constraints, and environment description. This information is determined as part of requirements engineering and is used to be certain that all stakeholder concerns have been addressed.
3. Describe the architectural styles/patterns that have been chosen to address the scenarios and requirements.
The architectural style(s) should be described using one of the following architectural views…

Module view for analysis of work assignments with components and the degree to which information hiding has been achieved.
Process view for analysis of system performance.
Data flow view for analysis of the degree to which the architecture meets functional requirements.

4. Evaluate quality attributes : Quality attributes for architectural design assessment include reliability, performance, security, maintainability, flexibility, testability, portability, reusability, and interoperability.
5.Identify the sensitivity of quality attributes to various architectural attributes for a specific architectural style. This can be accomplished by making small changes in the architecture and determining how sensitive a quality attribute, say performance, is to the change. Any attributes that are significantly affected by variationin the architecture are termed sensitivity points..
6. Critique (Assess) candidate architectures (developed in step 3) using the sensitivity analysis conducted in step 5.
The Software Engineering Institute (SEI) describes this approach in the following manner

Once the architectural sensitivity points have been determined, finding trade-off points is simply the identification of architectural elements to which multiple attributes are sensitive. For example, the performance of a client-server architecture might be highly sensitive to the number of servers (performance increases, within some range, by increasing the number of servers). . . . The number of servers, then, is a trade-off point with respect to this architecture.

Architectural Complexity

A useful technique for assessing the overall complexity of a proposed architecture is to consider dependencies between components within the architecture.

These dependencies are driven by information/control flow within the system. Zhao suggests three types of dependencies:

Sharing dependencies represent dependence relationships among consumers who use the same resource or producers who produce for the same consumers.
For example, for two components u and v, if u and v refer to the same global data, then there exists a shared dependence relationship between u and v.
Flow dependencies represent dependence relationships between producers and consumers of resources
Constrained dependencies represent constraints on the relative flow of control among a set of activities. For example, for two components u and v, u and v cannot execute at the same time (mutual exclusion), then there exists a constrained dependence relationship between u and v.

Architectural Description Language

Introduction:

The architect of a house has a set of standardized tools and notation that allow the design to be represented in an unambiguous, understandable fashion.

The software architect can draw on Unified Modeling Language (UML) notation, other diagrammatic forms, and a few related tools, there is a need for a more formal approach to the specification of an architectural design.

Architectural description language (ADL) provides a semantics and syntax for describing a software architecture.

Hofmann and his colleagues suggest that

An ADL should provide the designer with the ability to decompose architectural components,
Compose individual components into larger architectural blocks,
Represent interfaces (connection mechanisms) between components.

Once descriptive, language based techniques for architectural design have been established, it is more likely that effective assessment methods for architectures will be established as the design evolves.