Activity: Architectural Analysis

Purpose To define a candidate architecture for the system, based on experience gained from similar systems or in similar problem domains. To define the architectural patterns, key mechanisms and modeling conventions for the system. To define the reuse strategy To provide input to the planning process
Steps Develop Architecture Overview Survey Available Assets Define the High-Level Organization of Subsystems Identify Key Abstraction Develop High Level Deployment Model Identify Analysis Mechanisms Create Use-Case Realizations Identify Stereotypical Interactions Review the Results
Input Artifacts: Glossary Vision Use-Case Model Supplementary Specifications Reference Architecture Design Guidelines Software Architecture Document Design Model	Resulting Artifacts: Use-Case Realization Deployment Model Design Guidelines Software Architecture Document Design Model
Frequency: Once per iteration, with most work occurring in the early iterations; later iterations visit the activity primarily to validate and adjust the analytic aspects of the architecture.
Role: Software Architect
Concepts: Distribution Patterns Analysis Mechanisms Concurrency Layering

Workflow Details:

Analysis & Design

Define a Candidate Architecture

Perform Architectural Synthesis

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 (in Workflow Detail: Perform Architectural Synthesis). 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 software architect, often in collaboration with the project sponsor. 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.

Consider basing the architecture on a reference architecture, other architectural patterns, or other architectural assets.

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 software architect 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:

Survey Available Assets

Purpose

To identify assets that might be relevant for the project.
To analyze the fit and gap between assets and project requirements.
To decide whether to base areas of the system on assets.
Locate and list assets that are potentially reusable on the project. Perform a preliminary evaluation to ensure that necessary support is potentially available.

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.

Define the High-Level Organization of Subsystems

The design model is normally organized in layers - a common architectural pattern for moderate to large sized systems. The number of layers is not fixed, but varies from situation to situation.

During architectural analysis, focus is normally on the two high-level layers, that is, the application and business-specific layers; this is what is meant by the "high-level organization of subsystems." The other lower-level layers are considered in Activity: Incorporate Existing Design Elements. If other architectural patterns are being used, the subsystems will be defined around the architectural template.

Identify Key Abstractions

Requirements and Business Modeling 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 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, the Glossary, and in particular, the Domain Model, or the Business Object Model, if you have one. 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. Depending on the domain, and the novelty of the system, analysis patterns, which capture many of the key abstractions required to model the system, may already exist. Use of such patterns (which should already have been successfully employed in the domain) will considerably ease the intellectual burden of identifying the important concepts which must be represented. [FOW97a] presents some analysis patterns that are immediately useful for modeling business systems, but which may be applicable in other contexts. Another example is the Object Management Group (OMG™), which is also attempting to define interfaces and protocols for many domains, through the work of its Domain Technology Committee and associated task forces. Inevitably this work leads to the identification of important abstractions in the domain.

The analysis classes identified at this point will probably change and evolve during the course of the project. 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.

Develop High Level Deployment Model

Purpose

To provide a basis for assessing the viability of implementing the system
To gain an understanding of the geographical distribution and operational complexity of the system
To provide a basis for early effort and cost estimates

Using the architecture overview developed previously, a high level deployment model is now developed.

The deployment model must be capable of supporting users at locations performing use cases which access components which access data, while and satisfying non-functional requirements and constraints. Components are provisionally placed on nodes. Validate that the nodes and connections are adequate to support the interactions between components on different nodes, and between components and their stored data.

If the relationships between the prime drivers are complex, it may be worthwhile to identify deployment units and to produce deployment unit matrices at this point (rather than later).

Detailed specification of nodes and connections is deferred, except where they are important for estimating or viability assessment.

Although this is the first deployment model produced in the project, and is produced quickly and at a high level, it may identify actual hardware and software products if these are known, or if it is important to make these selection decisions at this time.

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 software architect 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.

The 'bottom-up' approach is where analysis mechanisms are ultimately born: they are created as the software architect 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 software architect recognizes that the system will require a 'persistence mechanism'. Ultimately, this mechanism will be implemented through the collaboration of a 'society of classes' (see [BOO98]), 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.

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 (identified in Activity: Prioritize Use Cases). 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.