Topics

Introduction to Analysis Mechanisms To top of page

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.

Examples of Analysis Mechanisms To top of page

  • 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

Describing Analysis Mechanisms To top of page

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
  3. Diagram showing relationships between Classes and 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.

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

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

Application of Analysis Mechanisms To top of page

Patterns and Transformations To top of page

Background To top of page

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:

This diagram shows a transformation as something that is derived from a pattern-in-the-large (and can then be used to implement it).

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 diagram shows the notion of pattern, as we have restricted it, as a subclass of the abstract class transformation.

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 To top of page

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 To top of page

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 To top of page

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:

This diagram adds transform as a subclass of transformation.

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

 

Rational Unified Process   2003.06.15