Develop Architecture Overview
Purpose
|
To facilitate system envisioning by exploring and evaluating high-level architectural
options.
To convey an early understanding of the high-level structure of the intended system to the
sponsor, development teams, and other stakeholders.
|
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 nonfunctional requirements of the system.
It's produced by the software architect, often in collaboration with the project sponsor, and takes the
form of an informal, rich picture storyboard 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 might be necessary to capture the architecture overview in the appropriate
sections of the Software Architecture document, so it can be formally reviewed.
At this point the architecture overview is a provisional first pass. Do not base commitments on the
architecture overview diagram until an executable architectural prototype has validated the architecture,
including design, implementation, and deployment concerns.
Consider basing the architecture on a reference architecture, other architectural patterns, or other architectural assets.
Consider whether or not you wish to refine and maintain the architecture overview diagram, to serve 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.
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, and so forth)
-
existing server environment (configuration, software versions, planned upgrades)
-
existing standards (network, naming, protocols, and so on)
Such information can be captured either textually, or in a Deployment Model.
|
Survey Available Assets
Purpose
|
To identify assets that might be relevant to the project.
To analyze the fit and gap between assets and project requirements.
To decide whether to base areas of the system on assets.
To locate and list assets that are potentially reusable on the project.
To perform a preliminary evaluation to ensure that necessary support is potentially available.
|
You need to understand the requirements of the environment for which assets are being considered, and the
system scope and general functionality required. Search through organizational asset bases and industry
literature to identify assets or similar projects. There are several types of assets to consider, such as
(but not limited to) industry models, frameworks, classes, and experience. You'll need to assess whether
available assets contribute to solving the key challenges of the current project and whether they are
compatible with the project's constraints.
You'll want to analyze the extent of the fit between asset and customer requirements, considering whether
any of the requirements are negotiable (to enable use of the asset).
Be certain you assess whether the asset could be modified or extended to satisfy requirements, and what the
tradeoffs are in terms of cost, risk, and functionality from adopting the asset.
Finally, you'll want to decide, in principle, whether to use one or more assets and document the rationale
for this decision.
|
Define the High-Level Organization of Subsystems
Purpose
|
To create an initial structure for the Design Model.
|
When the focus is on performing the architectural synthesis during inception,
this step is excluded from this task.
Normally the design model is 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, you usually focus 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 Task: Incorporate Existing Design Elements. If you're
using specific architectural patterns, the subsystems are defined around the architectural template for
that pattern.
For more on layering, see Guideline: Layering.
|
Identify Key Abstractions
Purpose
|
To get prepared for analysis by identifying the key abstractions (representation
of concepts identified during business modeling tasks when applicable
and requirement tasks) that the system must handle. |
When the focus is on performing the architectural synthesis, this step is done to the extent necessary to
guide the software architect in selecting assets for the construction of the Work Product: Architectural Proof-of-Concept and to
support representative usage scenarios.
Requirements tasks and, when applicable, Business Modeling tasks 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 Task: Use Case Analysis.
You can take advantage of existing knowledge by identifying 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 Analysis Model,
if you have one.
When you define 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 that capture many of the key abstractions
required to model the system might 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 that must be represented. [FOW97a] presents some analysis patterns that are immediately useful for
modeling business systems, but might be applicable in other contexts. Another example is the Object
Management Group (OMG), which also attempts 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
identifying 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 too much time describing entity
classes in detail at this initial stage, because there is a risk that you'll identify classes and
relationships not actually needed by the use cases. Remember that you will find more entity classes and
relationships when looking at the use cases.
|
Identify Stereotypical Interactions
This step is included only when performing Architectural Analysis (this task) as part of Activity: Perform Architectural Synthesis during
inception.
The purpose of this step is to identify those interactions, between key abstractions in the system, that
characterize or are representative of significant kinds of activity in the system. These interactions are
captured as Use-Case Realizations.
|
Develop Deployment Overview
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.
|
Develop a high level overview of how the software is deployed. For example, determine if the system needs
to accessed remotely, or has requirements that suggest distribution across multiple nodes. Some sources of
information to consider are:
- users (at locations), defined in User Profiles (in the Vision) and use
cases (in the Use-Case Model)
- organization of business data (in the Business Analysis Model and Design
Model when available)
- service level requirements (in the Supplementary Specifications)
- constraints (in the Supplementary Specifications, such as requirements
to interface with legacy systems)
If a non-trivial distributed system is required, then a Deployment Model can be used to capture the
relationship between nodes. This should include provisionally assigning components and data to nodes, and
indicate how users access components that access data. Detailed specification of nodes and connections is
deferred, except where they are important for estimating or assessing viability. Existing assets can be
used, if appropriate assets are available. Although this is the first deployment model produced in the
project, and it's produced quickly and at a high level, it might identify actual hardware and software
products if they are known, or if it's important to make these selection decisions at this time.
Validate that the deployment model supports users (especially users at remote locations if this is
required) performing typical use cases while satisfying nonfunctional requirements and constraints.
Validate that the nodes and connections are adequate to support the interactions between components on
different nodes, and between components and their stored data.
|
Identify Analysis Mechanisms
Purpose
|
To define the analysis mechanisms and services used by designers to give "life" to their
objects.
|
When the focus is on performing the architectural synthesis during inception, this step is excluded from
this task.
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 that might be expressed as mechanisms during analysis are: persistence, transaction management,
fault management, messaging, and inference engines. The common aspect of all of 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 it's deployed upon or the
implementation language. Analysis mechanisms also can be designed and implemented in a number of different
ways; generally there will 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
and there is a need for a common way of allocating resources. Analysis mechanisms, which simplify the
language of analysis, emerge from these patterns.
Identifying an analysis mechanism means you identify that a common, perhaps implicit (in that the
requirements for the system imply it), subproblem exists, and you name it. Initially the name might be all
that exists; for example, 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 deliver application functionality directly,
but exist only to support it. Very often these support classes are located in the middle or lower layers of
a layered architecture, thereby providing a common support service to all application level classes.
If the identified subproblem 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 produced this
way will be abstract, and will require further refinement through design and implementation.
For more information, see Concept: Analysis Mechanisms.
|
Review the Results
Purpose
|
To ensure that the results of architectural analysis are complete and consistent.
|
As Architectural Analysis concludes, review the architectural mechanisms, the subsystems, packages, and
classes that have been identified to ensure they're complete and consistent. As the results of
Architectural Analysis are preliminary and relatively informal, reviews should be informal as well.
Scenarios or use cases can be used to validate the architectural choices made at several levels-from the
business perspective down to the specific interactions that occur.
See Checklist: Software Architecture Document - Architectural Analysis
Considerations for more information on assessing the results of this task.
|
|