Categorize Clients of Analysis Mechanisms
Analysis mechanisms provide conceptual sets of services which are used by Analysis
Classes. They offer a convenient short-hand for fairly complex behaviors which will ultimately have to be worried
about, but which are out of scope for the analysis effort. Their main purpose is to allow us to capture the
requirements on these yet-to-be designed services of the system without having to be concerned about the details of the
service provider itself.
Now we must begin the refine the information gathered on the analysis mechanisms. The steps for doing this are as
Identify the clients of each analysis mechanism. Scan all clients of a given analysis mechanism, looking at the
characteristics they require for that mechanism. For example, a number of Analysis
Classes may make use of a Persistence mechanism, but their requirements on this may widely vary: a class which will
have a thousand persistent instances has significantly different persistence requirements than a class which will have
four million persistent instances. Similarly, a class whose instances must provide sub-millisecond response to instance
data will require a different persistence approach than a class whose instance data is only accessed through ad-hoc
queries and batch reporting applications.
Identify characteristic profiles for each analysis mechanism. There may be widely varying characteristics
profiles, providing varying degrees of performance, footprint, security, economic cost, etc. Each analysis
mechanism is different - different characteristics will apply to each. Many mechanisms will require estimates of the
number of instances to be managed, and their expected size in terms of the expected number of bytes. The movement of
large amounts of data through any system will create tremendous performance issues which must be dealt with.
Group clients according to their use of characteristic profiles. Form groups of clients that seem to share a
need for an analysis mechanism with a similar characteristics profile; identify a design mechanism based on each such
need. These groupings provide an initial cut at the design mechanisms. An example analysis mechanism, "inter-process
communication", may map onto a design mechanism "object request broker". Different characteristic profiles will lead to
different design mechanisms which emerge from the same analysis mechanism. The simple persistence mechanism in analysis
will give rise to a number of persistence mechanisms in design: in-memory persistence, file-based, database-based,
distributed, etc. The design mechanisms are refinements of the analysis mechanisms, based on different characteristic
Inventory the Implementation Mechanisms
Proceed bottom-up and make an inventory of the implementation mechanisms (see Concept: Design and Implementation Mechanisms) that you have at your disposal:
Mechanisms offered by a middleware product or component framework.
Mechanisms offered by operating systems.
Mechanisms offered by a component.
Mechanisms offered by a class library.
Legacy code (see also Task: Incorporate Existing Design Elements)
Special purpose packages: GUI builder, Geographical Information System, DBMS, etc.
Determine where existing implementation mechanisms can be used and where new implementation mechanisms need to be
Map Design Mechanisms to Implementation Mechanisms
Design mechanisms provide an abstraction of the implementation mechanisms, bridging the gap between Analysis Mechanisms
and Implementation Mechanisms. The use of abstract architectural mechanisms during design allows us to consider how we
are going to provide architectural mechanisms without obscuring the problem-at-hand with the details of a particular
mechanism. It also allows us to potentially substitute one specific implementation mechanism for another without
adversely affecting the design.
Determine the ranges of characteristics. Take the characteristics identified for the design mechanisms to
determine reasonable, economical, or feasible ranges of values to use in the candidate-implementation mechanism.
Consider the cost of acquisition for purchased components. For candidate implementation mechanisms, consider the
cost of acquisition or licensing, the maturity of the product, relationship with the vendor, support, etc. in addition
to purely technical criteria.
Conduct a search for the right components, or build the components. You will often find that there is no
apparently suitable implementation mechanism for some design mechanisms; this will trigger a search for the right
product, or identify the need for in-house development. You may also find that some implementation mechanisms are not
used at all.
The choice of implementation mechanisms is based not only on a good match for the technical characteristics, but also
on the non-technical characteristics, such as cost. Some of the choices may be provisional; almost all have some
risks attached to them: performance, robustness, and scalability are nearly always concerns and must be validated by
evaluation, exploratory prototyping, or inclusion in the architectural prototype.
Document Architectural Mechanisms
The role of the Software Architect in this task is to decide upon and validate these mechanisms by building, or
integrating them, and verifying that they do the job, then consistently impose them upon the rest of the system design.
The software architect role collaborates with the process engineer role to document the mechanisms and details
regarding their use in project-specific design guidelines. See Task: Prepare Project Specific Guidelines. The relationship (or
mapping) of analysis mechanisms to design mechanisms to implementation mechanisms, and the associated rationale for
these choices, should be documented in the Software Architecture Document. The mechanisms themselves are Design
Model elements (such as Design Package, Design Class, and Design Subsystem) which are detailed in Artifact: Design Model as part of their respective design tasks.