Concepts:
Analysis Mechanisms
Topics
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.
- 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
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 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.
- 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.
Copyright
© 1987 - 2001 Rational Software Corporation
| |
|
Disciplines >
Analysis & Design >
Concepts >
