Concepts: Analysis Mechanisms
Topics
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 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 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 architecture.
- 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 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:
- Message routing
- Process control and synchronization
- Transaction management
- Information Exchange
- Security
- Redundancy
- Error reporting
- Format conversion
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 these choices.
| |
|