The Architecture Design Process

the architectural view of software development is composed of a predesign phase, a domain analysis phase, a schematic design phase, and a design development phase. The focus of each phase is on a different, but possibly overlapping, set of problems. In the predesign phase, the architect is concerned mostly with forming and understanding the enterprise context in which an application will exist. This is represented by a model that depicts the system as an entity within a community of other entities, such as other software systems and human users. During the domain analysis phase, the application requirements are analyzed and structured. In particular, the requirements are those around the problem domain but not specific to the domain of software itself, such as user interface or HCI-related requirements. During the schematic design phase, the architect begins to develop the solution models such as identifying the modules of the system and the design rules that establish the boundaries between modules. Modules are discrete units of design work that rely on shared information and also have hidden information. Finally, during the design development phase, the architecture is refined and possibly multiple variations are created in order to explore the best fi

The basic architecture design process is composed of these steps:

Understand the problem.

Identify design elements and their relationships.

Evaluate the architecture design.

Transform the architecture design.

The first step is arguably the most crucial because it affects the quality of the design that follows. Without a clear understanding of the problem, it is not possible to create an effective solution.

In the second step, we identify design elements and their interdependencies. In the early phases of the design project, we perform a naive functional decomposition of the application, which establishes a baseline for future design tasks and design transformation. An example of this method can be seen in Jan Bosch's Design and Use of Software Architectures, which focuses on product-line architectures for real-time and embedded software systems. In Bosch's model, this step is called functionality-based architectural design (Bosch, 2000).

The third step involves assessing the architecture for conformance to architectural quality attribute requirements. The functional behavior of the application cannot be ideally tested from an architectural decomposition. However, many other quality attributes can be assessed by inspecting the design or by implementing prototypes of the architecturally significant component interactions.

The fourth step involves the application of design operations to transform the architecture design into a new design that addresses the quality attribute requirements better than the previous design. The phase may be repeated multiple times and even performed recursively


Identifying Design Elements and Their Relationships



In this step, we establish a baseline decomposition that initially splits the system based on functional requirements. The decomposition can be modeled using a design structure matrix (DSM), which represents the dependencies between design elements without prescribing the granularity of the elements. A first draft of this model could be created during the predesign phase, and then revised during subsequent steps.



Evaluating the Architecture


The third step involves evaluating the architectural design to determine if it satisfies the architectural requirements. The design is evaluated in order to gather qualitative measures or quantitative data, both of which are metrics



Transforming the Architecture



This step is performed after an evaluation or informal assessment of the architectural design. If the architectural design does not fully satisfy its quality attribute requirements, then it must be changed until it does satisfy them. However, instead of starting from scratch, we can take the existing design and apply design operators to it in order to transform it. The new version of the design is then assessed and the process continues until a satisfactory design is achieved. Sometimes you may need to reverse (undo) operations that were already applied and go down a different design path. You may also be creating several candidate designs at the same time. Starting with an initial root design (perhaps a single monolithic module), you may create a directed graph of designs. Each node represents a design decision path. Some paths may merge, in which case the application of design operations are commutative. In this case, you may transform some of the designs and eliminate ones that are obviously not going to transform well based on the requirements.

A design is transformed by applying design operators, styles, or patterns. There are two types of design operators: those that affect the modular architecture and those that affect the component architecture. There are six modular operators (Baldwin, 2000):

Splitting a design into two or more modules

Substituting one design module for another

Augmenting the system by adding a new module

Excluding a module from the system

Inverting a module to create new interfaces (design rules)

Porting a module to another system

Similar to the modular operators are design operators. The basic design operators identified by Bass (Bass, 1998) are:

Decomposition of a system into components.

Replication of components to improve reliability.

Compression of two or more components into a single component to improve performance.

Abstraction of a component to improve modifiability and adaptability.

Resource sharing, or the sharing of a single component instance with other components to improve integrability (the ability to integrate applications and systems), portability, and modifiability.

Modular and design operators are very similar. The modular operators are concerned with the module view of the system: those units of individual design and development that primarily affect the nonoperational qualities. The design operators are concerned with the runtime component view of the system, which are those units of execution that primarily affect the operational qualities