Architectural Analysis

1
Chapter 33

• Architectural Analysis

2
Architectural Analysis

• The identification and resolution of the systems
  non-functional requirements in the context of the
  functional requirements.
• Includes identifying variation points and
  probable evolution points.
• E.g., security in the context of processing
  sales reliability and fault tolerance when
  contacting remote services adaptability and
  configurability requirements for business rules.

3
Steps in Architectural Analysis

• Identify and analyze non-functional requirements
  that have an impact on the architecture.
• architectural factors or drivers, or
  architecturally significant requirements.
• Recorded in Supplementary Specification.
• Analyze architecturally significant factors,
  exploring alternatives and creating solutions
  that resolve the impact on the architecture.
• architectural decisions

4
Quality Scenarios

• The non-functional quality attributes often have
  significant influence on architecture.
• E.g., reliability, performance, customizability.
• Quality scenarios define measurable (or
  observable) and verifiable responses.
• E.g., performance, MTBF.
• Format ltstimulusgt ltmeasurable responsegt
• E.g., When a remote service fails, reestablish
  connectivity with it within 1 minute of its
  detected re-availability, under normal store load
  in a production environment.

5
Software Architecture Document (SAD)

• Describes the major ideas in the architecture,
  including the decisions of architectural
  analysis. (see p. 656)
• Learning aid for developers who need to
  understand the system.
• Technical memo record of alternative solutions,
  decisions, influential factors, motivations for
  noteworthy issues.
• A.k.a. issue cards or architectural approach
  documents
• Recording motivation or rationale is important.

6
Priorities for Architectural Decisions

• Inflexible constraints, including safety and
  legal compliance.
• E.g., tax policies.
• Business goals.
• E.g., has qualities and features attractive to
  department stores in Europe (multi-currency
  support, customizable business rules).
• All other goals.
• Can often be traced back to directly stated
  business goals.

7
Separation of Concerns

• A large-scale way of thinking about low coupling
  and high cohesion at an architectural level.
• Cross-cutting concerns issues with wide
  application or influence in the system.
• E.g., data persistence, security.
• Modularize the concern into a separate component
  and invoke its services.
• Use a decorator object that wraps the inner
  object and interposes the service.
• Use post-compilers and aspect-oriented
  technologies. (e.g., AspectJ).