Roles and Activities > Developer Role Set > Software Architect > Identify Design Mechanisms
Analysis mechanisms provide conceptual sets of services which are used by analysis objects. 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 objects 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.
Proceed bottom-up and make an inventory of the implementation mechanisms (see Concepts: Design and Implementation Mechanisms) that you have at your disposal:
Determine where existing implementation mechanisms can be used and where new implementation mechanisms need to be built.
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 role of the Software Architect in this activity 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
mechanisms, and details regarding their use, should be documented in the Artifact:
Design Guidelines specific to the project. 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
Rational Unified Process