Last updated: May. 3, 2006

Identify Analysis Mechanisms:

• In order to better understand what an analysis mechanism is, we have to understand what an architectural mechanism is.

• An architectural mechanism represents a common solution to a frequently encountered problem. It may be patterns of structure, patterns of behavior, or both. Architectural mechanisms are an important part of the "glue" between the required functionality of the system and how this functionality is realized, given the constraints of the implementation environment.

• Support for architectural mechanisms needs to be built in to the architecture. Architectural mechanisms are coordinated by the architect. The architect chooses the mechanisms, validates them by building or integrating them, verifies that they do the job, and then consistently imposes them upon the rest of the design of the system.

• Architectural Mechanism Categories:

  • Analysis mechanisms (conceptural): capture the key aspects of a solution in a way that is implementation-independent. They either 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.

  • Design mechanisms (concrete): are more concrete. They assume some details of the implementation environment, but are not tied to a specific implementation (as is an implementation mechanism).

  • Implementation mechanisms (actual): specify the exact implementation of the mechanism. Implementation mechanisms are bound to a certain technology, implementation language, vendor, or other factor.

• Analysis mechanisms are used during analysis to reduce the complexity of analysis and to improve its consistency by providing designers with a shorthand representation for complex behavior.

• Sample Analysis Mechanisms:

  • Persistency: A persistent object is one that logically exists beyond the scope of the program that created it . The need to have object lifetimes that span use cases, process lifetimes, or system shutdown and startup, defines the need for object persistence. Persistence is a particularly complex mechanism. 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 that 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.

  • Communication (IPC and RPC): Examples of communication mechanisms include inter-process communication (IPC) and inter-node communication (a.k.a. remote process communication or RPC). RPC has both a communication and a distribution aspect.

  • Message routing

  • Distribution

  • Transaction management

  • Process control and synchronization (resource contention)

  • Information exchange, format conversion

  • Security

  • Error detection/handling/reporting

  • Redundancy

  • Legacy Interface

• Examples of Analysis Mechanism Characteristics:

  • Persistency mechanism: For all classes whose instances may become persistent, we need to identify:

    • Granularity: Range of size of the persistent objects

    • Volume: Number of objects to keep persistent

    • Duration: How long to keep persistent objects

    • Access mechanism: How is a given object uniquely identified and retrieved?

    • Access frequency: Are the objects more or less constant; are they permanently updated?

    • Reliability: Shall the objects survive a crash of the process, the processor; the whole system?

  • Inter-process communication mechanism: For all model elements that need 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

  • Legacy inter mechanism:

    • Latency

    • Duration

    • Access mechanism

    • Access frequency

  • Security mechanism:

    • Data granularity: Package-level, class-level, attribute level

    • User granularity: Single users, roles/groups

    • Security Rules: Based on value of data, on algorithm based on data, and on algorithm based on user and data

    • Privilege Types: Read, write, create, delete, perform some other operation

• 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 across different designers. For example, storage, persistency, database, and repository might all refer to a persistency mechanism. Inter-process communication, message passing, or remote invocation might all refer to an inter-process communication mechanism.

  • Draw a map of the client classes to the analysis 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, part size, and performance.

  • Model using collaborations: Once all of the analysis mechanisms are identified and named, they should be modeled through the collaboration of a "society of classes." Some of these classes 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.

• Selected analysis mechanisms for the Course Registration System:

  • Persistency: A means to make an element persistent (that is, exist after the application that created it ceases to exist).

  • Distribution: A means to distribute an element across existing nodes of the system.

  • Security: A means to control access to an element.

  • Legacy Interface: A means to access a legacy system with an existing interface.

Identify Key Abstractions:

• The purpose of this step is to "prime the pump" for analysis by identifying and defining the key abstractions that the system must handle. These may have been initially identified during business modeling and requirement activities. However, during those activities, the focus was on the problem domain. During analysis and design, our focus is more on the solution domain.

• What are key abstractions:

  • A key abstraction is a concept, normally uncovered in Requirements, that the system must be able to handle.

  • Sources for key abstractions:

    • Domain knowledge

    • Requirements

    • Glossary

    • Domain Model, or the Business Model (if one exists)

• Defining key abstractions:

  • Define analysis classes: The purpose of this step is not to identify a set of classes that will survive throughout design, but to identify the key abstractions the system must handle. Do not spend much time describing analysis classes in detail at this initial stage, because there is a risk that you might identify classes and relationships that are not actually needed by the use cases. Remember that you will find more analysis classes and relationships when looking at the use cases.

  • Model analysis classes and relationships on class diagrams:

    • Include a brief description of an analysis class

  • Map analysis classes to necessary analysis mechanisms

• Key abstractions for the Course Registration System:

Create Use-Case Realizations:

• What is a Use-Case Realization?

• The value of Use-Case Realizations:

  • Provides traceability from Analysis and Design back to Requirements

  • The Architect creates the Use-Case Realization

  • For each Use Case in the Use-Case Model, create a use-case realization in the Design Model. The name for the use-case realization should be the same as the associated use case, and a realize relationship should be the same as the associated use case, and a realize relationship should be established from the use-case realization to its associated use case.

Checkpoints (for designer):

• General:

  • Is the package partitioning and layering done in a logically consistent way?

  • Have the necessary analysis mechanisms been identified?

• Packages:

  • Have we provided a comprehensive picture of the services of the packages in upper-level layers?

• Classes:

  • Have the key entity classes and their relationships been identified and accurately modeled?

  • Does the name of each class clearly reflect the role it plays?

  • Are the key abstractions/classes and their relationships consistent with the Business Model, Domain Model, Requirements, Glossary, etc.?