An analysis mechanism represents a pattern that constitutes a common solution to a common problem. Analysis mechanisms
may show patterns of structure, patterns of behavior, or both. They are used during analysis to reduce the complexity
of analysis, and to improve consistency by providing designers with a short-hand representation for complex behavior.
Mechanisms allow the analysis effort to focus on translating the functional requirements into software concepts without
bogging-down in the specification of relatively complex behavior needed to support the functionality but not central to
it. Analysis mechanisms often result from the instantiation of one or more architectural or analysis
Analysis mechanisms are primarily used to represent 'placeholders' for complex technology in the middle and lower
layers of the architecture. By using the mechanisms as 'placeholders' in the architecture, the architecting effort is
less likely to become distracted by the details of mechanism behavior. As an example, the need to have object lifetimes
span use cases, process lifetimes, or system shutdown and start-up defines the need for object persistence. Persistence
is a particularly complex mechanism, and during analysis we do not want to be distracted by the details of how we are
going to achieve persistence. This gives rise to a 'persistence' analysis mechanism which allows us to speak of
persistent objects and capture the requirements we will have on the persistence mechanism without worrying about what
exactly the persistence mechanism will do or how it will work.
Analysis mechanisms are typically, but not necessarily, unrelated to the problem domain, but instead are "computer
science" concepts; as a result they typically occupy the middle and lower layers of the architecture. They provide
specific behaviors to a domain-related class or subsystem, or correspond to the implementation of cooperation between
classes and/or subsystems. They may be implemented as a framework,
Examples include mechanisms to handle persistence, inter-process communication, error or fault handling, notification,
and messaging, to name a few.
However, as more analysis patterns are established in various domains, the partial or complete
instantiation of these in analysis mechanisms will lead to these mechanisms appearing in the upper layers of the
For all classes whose instances may become persistent, we need to identify:
Granularity: Range of size of the objects to keep persistent
Volume: Number of objects to keep persistent
Duration: How long does the object typically need to be kept?
Retrieval mechanism: How is a given object uniquely identified and retrieved?
Update frequency: Are the objects more or less constant; are they permanently updated?
Reliability: Shall the objects survive a crash of the process; the processor; or the whole system?
For all model elements which need to communicate with components or services executing in other processes or
threads, we need to identify:
Latency: How fast must processes communicate with another?
Synchronicity: Asynchronous communication
Size of message: A spectrum might be more appropriate than a single number.
Protocol, flow control, buffering, and so on.
Other typical mechanisms include:
Process control and synchronization
The process for describing analysis mechanisms is:
Collect all analysis mechanisms in a list
The same analysis mechanism may appear under several different names across different use-case realizations,
or different designers. For example, storage, persistency, database, and repository
might all refer to a persistency mechanism. Or inter-process communication, message passing, or
remote invocation might all refer to and inter-process communication mechanism.
Draw a map of the client classes to the analysis mechanisms
The classes and subsystems identified need to be mapped onto the identified Analysis Mechanisms: the arrows
indicate that the class utilizes the mechanism. It is not uncommon for a client class to require the services
of several mechanisms.
Identify Characteristics of the Analysis Mechanisms
To discriminate across a range of potential designs, identify the key characteristics used to qualify each
analysis mechanism. These characteristics are part functionality, and part size and performance.
Model Using Collaborations
Having identified and named the analysis mechanisms, they should, ultimately, be modeled 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 mechanism is common enough, perhaps patterns exist 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.
Analysis mechanisms are documented in the Artifact: Software Architecture Document. As the software
architecture matures, the Artifact: Software Architecture Document includes a relationship (or
mapping) of analysis mechanisms to design mechanisms to implementation mechanisms, and the associated rationale for