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.

Examples of Analysis Mechanisms   

• Persistency
  
  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?


• Inter-process Communication
  
  For all model elements which needs to communicate with objects, 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:
  
  
  • Message routing
  • Process control and synchronization
  • Transaction management
  • Information Exchange
  • Security
  • Redundancy
  • Error reporting
  • Format conversion

Describing Analysis Mechanisms   

The process for describing analysis mechanisms is:

1. 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.




2. Draw a map of the client classes to the analysis mechanisms



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.




3. 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.




4. 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.