Disciplines > Analysis & Design > Concepts > Analysis Mechanisms
Introduction to Analysis Mechanisms
An analysis mechanism represents a pattern that constitutes a common solution to a common problem. They may show patterns of structure, patterns of behavior, or both. They are used during analysis to reduce the complexity of analysis, and to improve its 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 patterns.
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 component, or correspond to the implementation of cooperation between classes and/or components. 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 architecture.
Other typical mechanisms include:
The process for describing analysis mechanisms is:
The classes and component 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.
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 these choices.
Rational Unified Process