Activity: Architectural Analysis
Purpose
|
|
| Steps | |
| Input Artifacts: | Resulting Artifacts: |
| Frequency: Once per iteration, with most work occurring in the early iterations; later iterations visit the activity primarily to validate and adjust the analytic aspects of the architecture. | |
| Worker: Architect | |
| Concepts: Distribution Patterns, Analysis Mechanisms, Concurrency, Layering | |
Define
modeling conventions 
Purpose
|
Architectural patterns and mechanisms, as well as the design in general are represented in a number of different ways: with descriptive texts, formal languages, diagrams (including class, sequence, collaboration, and activity diagrams, among others).
Modeling conventions are documented in the Artifact: Design Guidelines; the format and style for the architectural description is defined in the Architectural Representation section of the Artifact: Software Architecture Document.
Define the high-level organization
of subsystems
Purpose
|
| Guidelines: Layering |
The design model is normally organized in layers. The number of layers is not fixed, but varies from situation to situation.
During architectural analysis, focus is normally on the two high-level layers, that is, the application and business-specific layers; this is what is meant by the "high-level organization of subsystems." The other lower-level layers are in focus during architectural design, refer to the Activity: Architectural Design for more information.
Identify analysis mechanisms
Purpose
|
An analysis mechanism represents a pattern that constitutes a common solution to a common problem. They may be 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 are usually unrelated to the problem domain, but instead are "computer science" concepts. 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.
Identify
key abstractions
Purpose
|
| Tool Mentor: Documenting the analysis classes in Rational Rose™. |
Requirements and Business Modeling activities usually uncover key concepts that the system must be able to handle; these concepts manifest themselves as key design abstractions. Because of the work already done, there is no need to repeat the identification work again during Activity: Use Case Analysis. To take advantage of existing knowledge, we identify preliminary entity analysis classes to represent these key abstractions on the basis of general knowledge of the system, such as the Requirements, the Glossary, and in particular, the Domain Model, or the Business Model, if you have one. While defining the key abstractions, also define any relationships that exist between entity classes. Present the key abstractions in one or several class diagrams, and create a short description for each.
The analysis classes identified at this point will probably change and evolve during the course of the project. The purpose of this step is not to identify a set of classes that will survive throughout design, but to identify the key concepts the system must handle. Don't spend much time describing entity classes in detail at this initial stage, because there is a risk that you identify classes and relationships that are not actually needed by the use cases. Remember that you will find more entity classes and relationships when looking at the use cases.
Create use-case realizations
Purpose
|
| Guidelines: |
| Tool Mentor: Using Rational Rose™ to Create Use-Case Realizations |
Use Cases form the central focus of most of the early analysis and design work. To enable the transition between Requirements-centric activities and Design-centric activities, the Artifact: Use-Case Realization serves as a bridge, providing a way to trace behavior in the Design Model back to the Use-Case Model, as well as organizing collaborations in the Design Model around the Use Case concept.
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 trace dependency should be established from the use-case realization to its associated use case.
Review the Results
Purpose
|
| Check-points: Architectural Analysis |
As Architectural Analysis concludes, review the architectural mechanisms, the subsystems, packages and classes that have been identified, to ensure that they are complete and consistent. As the results of Architectural Analysis are preliminary and relatively informal, reviews should be informal as well.
