Activity: Architectural Analysis

Purpose

 To define the architectural patterns, key mechanisms and modeling conventions for the system.
 To define the reuse strategy
 To provide input to the planning process

Steps

 Define modeling conventions

 Define the high-level organization of subsystems
 Identify analysis mechanisms
 Identify key abstractions
 Create use-case realizations
 Review the results

Input Artifacts: Resulting Artifacts:

 Use Case Model  updated Software Architecture Document

 Supplementary Specifications  updated Design Model
 Glossary  Design Guidelines
 Business Model  Use-Case Realizations
 Software Architecture Document
 Design Model
 Design Guidelines

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

 To ensure that the representation of the architecture and design are consistent across teams and iterations.

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

 To create an initial structure for the Design Model

 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

 To define the architectural patterns and services used by designers to give "life" to their objects.

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

 To "prime the pump" for analysis by identifying the key abstractions (representation of concepts identified during
business modeling and requirement activities) that the system must handle.

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
  To create the Design Model artifacts used to express the behavior of the use cases.

Guidelines:

 Use-Case Realization

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

 To ensure that the results of architectural analysis is complete and consistent.

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.

 Use Case Model

The use-case model is a model of the system's intended functions and its
environment, and serves as a contract between the customer and the developers.
The use-case model is used as an essential input to activities in analysis, design,
Use-Case Model and test.
UML representation: Model, stereotyped as «use-case model».

Worker: System Analyst

Sample Reports: Use-Case-Model Survey

More information: Guideline: Use-Case Model

 Purpose
 Properties
 Timing
 Responsibility

Purpose

The following people use the use-case model:

 The customer approves the use-case model. When you have that approval, you know the system is what the customer wants. You
can also use the model to discuss the system with the customer during development.
 Potential users use the use-case model to better understand the system.
 The architect uses the use-case model to identify architecturally significant functionality.
 Designers use the use-case model to get a system overview. When you refine the system, for example, you need documentation on
the use-case model to aid that work.
 The manager use the use-case model to plan and follow up the use-case modeling and also the subsequent design.
 People outside the project but within the organization, executives, and steering committees, use the use-case model to get an
insight into what has been done.
 People review the use-case model to give appropriate feedback to developers on a regular basis.
 Designers use the use-case model as a basis for their work.
 Testers use the use-case model to plan testing activities (use-case and integration testing) as early as possible.
 Those who will develop the next version of the system use the use-case model to understand how the existing version works.
 Documentation writers use the use cases as a basis for writing the system's user guides.

Properties

Property Name Brief Description UML Representation

Introduction A textual description that serves as a brief Tagged value, of type "short text".
introduction to the model.
Survey Description A textual description that contains Tagged value, of type "formatted text".
information not reflected by the rest of the
use-case model, including:
· Typical sequences in which the use cases
are employed by users.
· Functionality not handled by the use-case
model.
Use-Case Packages The packages in the model, representing a Owned via the association "represents", or
hierarchy. recursively via the aggregation "owns".
Use Cases The use cases in the model, owned by the Owned recursively via the aggregation
packages. "owns".
Actors The actors in the model, owned by the -"-
packages.
Relationships The relationships in the model, owned by the - " -
packages
Diagrams The diagrams in the model, owned by the -"-
packages.
Use-Case View The use-case view of the model, which is an -"-
architectural view showing the significant
use-cases and/or scenarios.

Timing

The use-case model primarily sets the functional requirements on the system, and is used as an essential input to analysis and
architectural design. It can be used early in the inception phase to outline the scope of the system, as well as during the elaboration
phase. The use-case model is refined by more detailed flows of events during the construction phase. The use-case model is
continuously kept consistent with the design model.

Because it is a very powerful planning instrument, the use-case model is generally used in all phases of the development cycle.

Responsibility
A system analyst is responsible for the integrity of the use-case model, and ensures that the use-case model as a whole is correct,
consistent, and readable. The use-case model is correct when it describes the system's functionality, and only this functionality.

Note that details of use-case packages, use cases, actors, relationships, and diagrams are the responsibilities of the corresponding use-
case specifier. For more information, refer to Worker: Use-Case Specifier. The use-case view is the responsibility of an architect. For
more information, refer to Worker: Architect.

 Supplementary Specifications
The Supplementary Specifications capture the system requirements that are not
readily capturable in the use cases of the use-case model. Such requirements
include:
Supplementary
Specifications  Legal and regulatory requirements and application standards.
 Quality attributes of the system to be built, including usability, reliability,
performance and supportability requirements.
 Other requirements such as operating systems and environments,
compatibility requirements, and design constraints.

Worker: System Analyst

Template: Supplementary Specification template

 Purpose
 Brief Outline
 Timing
 Responsibility
 Tailoring

Purpose

The following people use the Supplementary Specifications:

 The system analyst creates and maintains the Supplementary Specifications, which serve as a communication medium between the
system analyst, the customer, and other developers.
 Designers use the Supplementary Specifications as a reference when defining responsibilities, operations, and attributes on classes,
and when adjusting classes to the implementation environment.
 Implementers refer to the Supplementary Specifications for input when implementing classes.
 The manager refers to the Supplementary Specifications for input when planning iterations.
 The testers use the Supplementary Specifications to verify system compliance.

Brief Outline

Supplementary Specifications should list the requirements that are not readily capturable in the use cases of the use-case model. For a
more detailed outline, see the IEEE recommended practice for software requirements specifications [IEEE Std 830-1993]. Following
is a sample outline.

1. Functionality
List functional requirements are general to many use cases.

1.1 <Functional Requirement One>

2. Usability
Include all of those requirements that relate to, or affect, the usability of the system. Examples include ease-of-use requirements
or training requirements that specify how readily the system can be used by its actors.
 2.1 <Usability Requirement One>

3. Reliability
Specify any requirements concerning the reliability of the system. Quantitative measures such as mean time between failure or
defects per thousand lines of code should be stated.

3.1 <Reliability Requirement One>

4. Performance
Outline the performance characteristics of the system. Include specific response times. Reference related use cases by name.

4.1 <Performance Requirement One>

5. Supportability
Indicate any requirements that will enhance the supportability or maintainability of the system being built.

5.1 <Supportability Requirement One>

6. Design Constraints
Indicate in this section any design constraints on the system being built.

6.1 <Design Constraint One>

Timing

Supplementary Specifications go hand-in-hand with the use-case model, implying that:

 They are initially considered in the inception phase, as a complement to defining the scope of the system.
 They are refined in an incremental fashion during the elaboration and construction phases.

Responsibility

A system analyst is responsible for producing the Supplementary Specifications, which is an important complement to the use-case
model. The Supplementary Specifications and the use-case model should together capture a complete set of requirements on the
system.

 Glossary

The Glossary defines important terms used in the project.

Glossary
Worker: System Analyst

Template: Word template

 Purpose
 Brief Outline
 Timing
 Responsibility
 Tailoring
 Tool Mentors
Purpose

There is one Glossary for the system. This document is important to many developers, especially when they need to
understand and use the terms that are specific to the project.

Brief Outline

1. Introduction

Present any information the reader might need to understand the document in this section. This document is used to define
terminology specific to the problem domain, explaining terms which may be unfamiliar to the reader of the use-case
descriptions or other project documents. Often, this document can be used as an informal data dictionary, capturing data
definitions so that use-case descriptions and other project documents can focus on what the system must do with the
information. This document should be saved in a file called Glossary.

2. Definitions

The terms defined here form the essential substance of the document. They can be defined in any order desired, but generally
alphabetic order provides the greatest accessibility.

1. aTerm

The definition for aTerm is presented here. As much information as the reader needs to understand the concept should be
presented.

2. anotherTerm

The definition for anotherTerm is presented here. As much information as the reader needs to understand the concept should
be presented

3. aGroupOfTerms

Sometimes it is useful to organize terms into groups to improve readability. For example, if the problem domain contains
terms related to both accounting and building construction (as would be the case if we were developing a system to manage
construction projects), presenting the terms from the two different sub-domains might prove confusing to the reader. To solve
this problem, we use groupings of terms. In presenting the grouping of terms, provide a short description that helps the reader
understand what aGroupOfTerms represents. Terms presented within the group should be organized alphabetically for easy
access.

1. aGroupTerm

The definition for aGroupTerm is presented here. As much information as the reader needs to understand the concept should
be presented

2. anotherGroupTerm

The definition for anotherGroupTerm is presented here. As much information as the reader needs to understand the concept
should be presented

4. aSecondGroupOfTerms

1. yetAnotherGroupTerm

The definition for the term is presented here. As much information as the reader needs to understand the concept should be
presented
2. andAnotherGroupTerm

The definition for the term is presented here. As much information as the reader needs to understand the concept should be
presented.

Timing

The Glossary is primarily developed during the inception and elaboration phases, because it is important to agree on a
common terminology early in the project.

Responsibility

A Worker: System Analyst is responsible for the integrity of the Glossary, ensuring that:

 The Glossary is produced in a timely manner.

 It continuously is kept consistent with the results of development.

Tailoring

In some projects the glossary will be the only artifact used to capture the business domain of the project. This is when neither
business modeling nor domain modeling is performed.

If the context of the business modeling effort is much different than a following software engineering effort, you may need to
produce one Glossary specific to the business modeling effort. That Glossary would then be the responsibility of the Business-
Process Analyst.

 Business Model
The business object model is an object model describing the realization of
business use cases.

Business Object Model

UML representation: Model, stereotyped as «business object model».

Worker: Business-Process Analyst

Optionality: Can be excluded.

Sample Reports: Report: Business Object Model Survey

More information: Guideline: Business Object Model

 Purpose
 Properties
 Timing
 Responsibility
 Tailoring

Purpose

The following people use the business object model:

 The business-process analyst is responsible for the integrity of the model.

 The business designer documents details about responsibilities people carry and "things" produced or used by the business in this
model.
 The system analyst uses this model as input for identifying system actors and system use cases.
 The designer uses this model as input for identifying classes in the analysis and design models.

Properties

Property Name Brief Description UML Representation

Introduction A textual description that serves as a Tagged value, of type "short
brief introduction to the model. text".
Organization The packages in the model, Owned via the association
Units representing a hierarchy. "represents", or recursively via
the aggregation "owns".
Business Workers The business worker classes in the Owned recursively via the
model, owned by the packages. aggregation "owns".
Business Entities The business entity classes in the -"-
model, owned by the packages.
Relationships The relationships in the model, -"-
owned by the packages.
Business Use- The business use-case realizations -"-
Case Realizations in the model, owned by the
packages.
Diagrams The diagrams in the model, owned -"-
by the packages.

Timing

A business object model is created during inception and finalized during the elaboration phase.

Responsibility

A business-process analyst is responsible for the integrity of the business object model, ensuring that:

 The organization units correctly represent the structure of the business.

 The collection of business workers together cover all responsibilities in the business.
 The collection of business entities together cover all "things" produced and used in the business.

Tailoring

You can choose to develop an "incomplete" business object model, focusing on explaining "things" and products important to the
business domain. Such a model does not include the responsibilities people carry, and is often referred to as a domain model. In such a
case, you would stereotype the model as «domain model» instead of «business object model».

 Software Architecture Document

The Software Architecture Document provides a comprehensive architectural
overview of the system, using a number of different architectural views to depict
different aspects of the system.
Software Architecture
Document
Worker: Architect
 Template: MS-Word™ template, SoDA™ Template

 Purpose
 Brief Outline
 Timing
 Responsibility
 Tailoring
 Annotated Outline

Purpose

There is one Software Architecture Document for the system. This document is particularly important to the following people:

 It is the primary artifact created and maintained by the architect, and serves as a communication medium between the architect
and other developers.
 Designers for a reference when creating use-case realizations, or defining responsibilities, operations, and attributes on classes,
and when adjusting classes to the implementation environment.
 Implementers, as input when implementing classes.
 Managers for input when planning iterations.
 Design Model
The design model is an object model describing the realization of use cases, and
serves as an abstraction of the implementation model and its source code. The
design model is used as essential input to activities in implementation and test.
Design Model
UML representation: Model, stereotyped as «design model».

Worker: Architect

Reports: Design-Model Survey

More information: Guidelines: Design Model

 Purpose
 Properties
 Timing
 Responsibility

Purpose

The following people use the design model:

 The use-case designer to see what classes and objects are available at a specific time.
 The designer to get a comprehensive picture of the design.
 The architect to get a comprehensive picture of the software architecture.
 The tester to plan tests and follow up test results.
 The manager to plan and follow up the design work.
 The people looking at the next evolution cycle to get a full picture of the design.
 o Design Guidelines
Describes the design and implementation guidelines.

Design Guidelines
Worker: Architect
Template: Word template

 Purpose
 Brief Outline
 Timing
 Responsibility
 Tailoring
 Annotated Outline

Purpose

Design Guidelines is a product of architecture definition. Many people will need this document because it describes the guidelines to
be followed during design, architectural design, and implementation.

 It is an artifact created and maintained by the Architect, and serves as a communication medium between the Architect and other
developers.
 Designers will use it as a reference when defining operations on design classes, and when adjusting design classes to the
implementation environment.
 Package owners will use it as a reference when describing dependencies between packages.
 Implementers will use it as a reference when implementing design classes.
 Reviewers will use it as a reference when reviewing the software architecture, design model, and implementation model. This
resolves a lot of debate regarding the quality of the artifacts produced.
 Newcomers to the project will use it to understand what is being produced.