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.
Patterns and Transformations 
Background 
As a "solution template for a recurring problem that has proven useful
in a given context" (taken from the Glossary definition), the idea
of a pattern is quite general: the application (instantiation) of a pattern
so defined may require many model changes, depending on the specificity and
scale of the problem solved. The application of patterns, and thus the instantiation
of mechanisms, viewed this way, occurs through model
transformation
. For example, in one of the mechanisms defined above, security, any pattern
that is the basis for a security mechanism is likely to be pervasive and require
changes that differ from model element type to element type. The definition
of the security pattern may well be found in a
UML Profile
, which is a standardized way to capture stereotypes, tagged values,
and constraints, that define and constrain a particular technology, discipline,
domain or other area of modeling concern. This is, in essence, the same as a
platform
(see
Concepts: Model-Driven Development and Model Driven
Architecture®
); so the idea of one or more transformations implementing "patterns-in-the-large"
is applicable here.
In this view, the relationship between pattern (in-the-large) and transformation
can be illustrated as follows:

However, the common experience of many is that a pattern is a more constrained
thing. It is, in this view, a kind of transformation (it is applied to a source
model, and its application results in a changed model), but the change is elaborative,
is applied locally (perhaps in one of several steps) and the source and target
models remain at almost the same broad level of abstraction. You may even regard
them as the same model. For example, you can apply a pattern in the form of
a parameterized collaboration to a Design Model and, provided the pattern is
not technology-specific, still claim that the result is a Design Model. This
is mirrored in the RUP when we speak of Analysis Patterns, Design Patterns and
Implementation Patterns (Idioms). In this view, the relationship between pattern
and transformation (now shown as an abstract class) is visualized as follows:

This more specific usage of patterns is explored further below.
As Software Architects, we would like to continue working at a high level of
abstraction and, having identified and characterized the required analysis mechanisms
and their supporting patterns (large and small), use automated transformation
to implement them. Ultimately, as we progress through analysis and design, our
hope is to automate as much of the model transformation as possible before finally
making the jump to code with our UML models still at a high level of abstraction,
not simply direct reflections of the code.
Approaches to Transformation 
In Concepts: Model-Driven Development and Model
Driven Architecture®, we outline a number of approaches to transformation
(see How is Transformation
Performed?
). To give a concrete example, Rational Software Architect supports an approach
based on a combination of type mappings (for example, determining how the source
model's classes, their attributes, operations and relationships affect the target
elements), and source model marking, both enabled by profiles.
This approach recognizes that the source model does not usually contain enough
information to completely guide the transformation through type mapping. The
Software Architect may add marks, such as stereotypes defined in a profile,
to the source model to completely specify the transformation. These marks, which
represent target platform concepts, are not part of the source model, but overlay
it. The rules that drive the transformation are derived from the target platform
definition, for example, from an associated profile, and from mapping of types
used in the source to types used in the target.
Having established the transformation rules and marked the source, the transformation
can proceed. Rational Software Architect goes further and allows parameters
to be supplied to the transformation, for example, to specify information that
cannot be derived from the profile or associated marks. An additional benefit
of making model changes in this systematic way is that a record of the transformation
is produced and saved. This preserves strong traceability information from source
model to target model.
Again, to give some concrete examples, Rational Software Architect reifies
the general concept of transformation in
transforms
and patterns
. The definitions offered are those used by Rational Software Architect.
Transform 
A transform is "a transformation optimized for batch processing, primarily
across metamodels, models and levels of abstraction". The application
of a transform typically results in the production of an obviously distinct
model, for example, a textual code model from a UML model. This is a significant
jump, with a notational change as well.
Pattern 
A pattern is "a transformation that is optimized for interactive,
piecewise elaboration primarily in a single metamodel and within the same level
of abstraction, and often within the same model". By this definition,
the result of the application of a pattern on a UML model remains a UML model,
perhaps a somewhat more elaborate one, but one which is recognizably at the
same level of abstraction.
The relationship between transformation, pattern and transform refines the
previous diagram as follows:

Another consequence of this more rigorous approach is that profiles and the
transformations that are derived from them become important entities in their
own right. The Software Architect will hope to leverage, through reuse, the
work done in preparation of a transformation. It is expected that libraries
of transformations will be created so that one-off transformations are the exception.
Such libraries should be searchable or browsable by the transformation's properties,
so that, for example, the Software Architect can easily match them to the identified
characteristics of the required analysis mechanisms.
More information on the performance of transformation using Rational Software
Architect may be found in various Rational Software Architect tutorials and
samples, including:
Tutorial:
Applying the XYZ Pattern
Tutorial:
Extending Patterns
Sample: Model
for Pattern Application
Sample: Pattern
Sample: Pattern
to Extend
Tutorial:
Design: Transform Model to Code
Tutorial:
Design: Transform Model to Model
Sample: Apply
Transform
Sample: Building
a First Transform
Sample: Build
a Model to Model Transform
Sample: Create
a Transform that Generates Text
Sample: Deploy
a Transform to other Rational Software Architect Users
| |
|