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
follows:
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
profiles.
|
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 built.
|
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 Work Product: Design Model
as part of their respective design tasks.
|
|