Activity:  Architectural Analysis

Architectural analysis focuses on defining a candidate architecture and constraining the architectural techniques to be used in the system. It relies on gathering experienced gained in similar systems or problem domains to constrain and focus the architecture so that effort is not wasted in 'architectural rediscovery'. In systems in which there is already a well-defined architecture, architectural analysis may be omitted; architectural analysis is primarily of benefit when developing new and unprecedented systems.

Develop Architecture Overview

The architecture overview is created early in the lifecycle of a project, possibly as early as the inception phase . It reflects early decisions and working assumptions on implementing the Vision, as well as decisions concerning the physical and logical architecture and non-functional requirements of the system. It is produced by the designer, often in collaboration with the stakeholders. It takes the form of an informal, rich picture, story-board, or iconic graph. Conceptually, it illustrates the essential nature of the proposed solution, conveying the governing ideas and including the major building blocks. The level of formality of the architectural overview is project dependent. For example, in a large, high-ceremony project, it may be necessary to capture the architecture overview in the appropriate sections of the Software Architecture Document, so that it may be formally reviewed.

At this point the architecture overview is a provisional first pass. No commitments should be based on the architecture overview diagram until the high level Deployment Model and Implementation Model have been developed and validated.

Refine the architecture overview diagram to maximize its effectiveness as a communication vehicle.

Many systems are constrained to be developed and deployed in an existing environment of hardware and software; for these, the designer will gather information about the current environment and capture it in the Deployment Model. For example, in an e-business system development, the following information is pertinent:

• Existing network logical and physical design
• Existing databases and database design
• Existing Web environment (servers, firewalls etc.)
• Existing server environment (configuration, software versions, planned upgrades)
• Existing standards (network, naming, protocols etc.)

Survey Available Assets

Understand the requirements of the environment for which assets are being considered. Understand the system scope and the general functionality required. Search through organizational asset bases, industry literature, to identify assets or similar projects. There are several types of assets to be considered, such as, but not limited to, industry models, frameworks, classes, and experience. Assess whether available assets could contribute to solving the key challenges of the current project, and are compatible with its constraints.

Analyze the extent of fit between asset and customer requirements. Consider whether any of the requirements are negotiable (to enable use of the asset).

Assess whether the asset could be modified or extended to satisfy requirements. Assess the trade-offs in cost, risk and functionality from adopting the asset.

Decide in principle whether to use one or more assets, and document the rationale for this decision.

Identify Key Abstractions

Requirements activities usually uncover key concepts that the system must be able to handle; these concepts manifest themselves as key design abstractions. Because of the work already done, there is no need to repeat the identification work again during the Use Case Analysis activity (Activity: Use Case Analysis). To take advantage of existing knowledge, we identify preliminary entity analysis classes to represent these key abstractions on the basis of general knowledge of the system, such as the Requirements and the Glossary. While defining the key abstractions, also define any relationships that exist between entity classes. Present the key abstractions in one or several class diagrams, and create a short description for each. 

The purpose of this step is not to identify a set of classes that will survive throughout design, but to identify the key concepts the system must handle. Don't spend much time describing entity classes in detail at this initial stage, because there is a risk that you identify classes and relationships that are not actually needed by the use cases. Remember that you will find more entity classes and relationships when looking at the use cases.

Identify Analysis Mechanisms

Analysis mechanisms can be identified 'top-down' (a priori knowledge) or 'bottom-up' (discovered as you go along). In the 'top-down' mode, experience guides the designer to know that certain problems are present in the domain and will require certain kinds of solutions. Examples of common architectural problems which may be expressed as mechanisms during analysis are: persistence, transaction management, fault management, messaging, and inference engines. The common aspect of all these is that each is a general capability of a broad class of systems and each provides functionality that interacts with or supports the basic application functionality. The 'analysis mechanisms' support capabilities required in the basic functional requirements of the system, regardless of the platform deployed upon or the implementation language. Analysis mechanisms also generally can be designed and implemented in a number of different ways; there will generally be more than one design mechanism corresponding to each analysis mechanism, and perhaps more than one way of implementing each design mechanism.

'bottom-up' approach is where analysis mechanisms are ultimately born: they are created as the designer sees, perhaps faintly at first, a common theme emerging from a set of solutions to various problems: there is a need to provide a way for elements in different threads to synchronize their clocks, there is a need for a common way of allocating resources. From these patterns emerge analysis mechanisms which simplify the language of analysis.

The identification of an analysis mechanism is to identify that a common, perhaps implicit (in that the requirements for the system imply it), sub-problem exists, and to name it.  Initially the name may be all that exists, e.g.  the designer recognizes that the system will require a 'persistence mechanism'.  Ultimately, this mechanism will be implemented through the collaboration of a 'society of classes', some of which do not directly deliver application functionality, but exist only to support it. Very often, these 'support classes' are located in the middle or lower layers of a layered architecture, thus providing a common support service to all application level classes.

If the identified sub-problem is common enough, perhaps a pattern exists from which the mechanism can be instantiated - by binding existing classes and implementing new ones as required by the pattern. An analysis mechanism so produced will be abstract, and require further refinement through design and implementation.

For more information, see Concepts: Analysis Mechanisms

Create Use-Case Realizations

Use Cases form the central focus of most of the early analysis and design work. To enable the transition between Requirements-centric activities and Design-centric activities, the Artifact: Use-Case Realization serves as a bridge, providing a way to trace behavior in the Design Model back to the Use-Case Model, as well as organizing collaborations in the Design Model around the Use Case concept.

Create a Use-Case Realization in the Design Model for each architecturally significant Use Case. The name for the Use-Case Realization should be the same as the associated Use Case, and a "realizes" relationship should be established from the use-case realization to its associated use case.

Identify Stereotypical Interactions

The purpose of this step is to identify those interactions, between key abstractions in the system, which characterize (i.e. are representative of) significant kinds of activity in the system. These interactions are captured as Use-Case Realizations.

Review the Results

As Architectural Analysis concludes, review the architectural mechanisms, the subsystems, packages and classes that have been identified, to ensure that they are complete and consistent. As the results of Architectural Analysis are preliminary and relatively informal, reviews should be informal as well. Scenarios from the important use cases should be used to validate the architectural choices made at several levels, from the business perspective down to the specific interactions that occur.