Architecture Design and Evaluation 2

Main ideas, concepts, and lessons

Purpose of the class (Architecture Design & Evaluation 2)

• Focuses on the architecture design method and attribute-driven design (ADD).
• Intended learning goals:
  • Understand architecture design as an activity.
  • Understand an architecture design method using a structured process.

What architecture design is

• Architecture design is a set of design activities whose expected output is an architecture model.
• The architecture model is represented in multiple views, including:
  • Structural perspective
  • Behavioral perspective

Key distinction: architecture design inputs

• Architecture design must address specific inputs called architecture drivers.
• Architecture drivers shape the architecture and include multiple categories:

Functional drivers

• Derived from functional requirements (primary business/functional needs).
• Often tied to business processes and new business value.
• Conceptual flow:
  • business model → system enables business model → functional requirements → functional drivers

Quality attribute drivers

• Derived from nonfunctional requirements, expressed as measurable qualities such as:
  • Performance
  • Availability
  • Modifiability
  • Testability
• Quality requirements must be evaluated using quality attribute scenarios.

Other necessary drivers (e.g., solution constraints)

• Technical/organizational constraints, such as what the customer/development organization mandates.
• These constraints reduce freedom: the team should not explore design alternatives that are disallowed by constraints.

Influence of system type on architecture drivers

• The architecture design approach depends on whether the system is:
  • Brownfield: modifying an existing system (architecture is constrained by current architecture).
  • Greenfield: building from scratch in a domain without known architectural guidance.

How design objectives affect depth and tradeoffs

Examples of design objectives:

• Prototype / rapid initial solution
  • Don’t over-invest in fully satisfying all quality attributes initially.
• Customer release with fixed time/cost
  • Tune quality requirements within limited resources.
• System expected to evolve after release
  • Defer/plan some quality improvements post-release.

Different objectives → different architecture drivers and priorities.

Architecture drivers from two perspectives

• Customer/business perspective
  • Typically yields functional and quality drivers.
• Solution perspective
  • Provides additional drivers (constraints/implications from implementation realities).

Architecture design knowledge reuse

• Reuse architecture knowledge from prior work via:
  • Architecture patterns
  • Reference architectures
  • Architecture tactics
• Helps the architect make better decisions efficiently.

---

Architecture evaluation concepts: scenarios and evaluation method

Why architecture evaluation is needed

• Architecture evaluation verifies architecture decisions, especially those tied to quality requirements.

Scenario-based evaluation

• The video introduces ATAM / Architecture Tradeoff Analysis Method conceptually:
  • Evaluation focuses on quality requirement-driven tradeoffs.
  • Quality scenarios are central to evaluation.

What a scenario is

• A scenario is a requirement described in a testable, unambiguous way.
• Common scenario types mentioned:
  • Use case scenarios
    • Example: remote user requests data via web; report delivered within 5 seconds.
  • Growth/adaptation scenarios
    • Example: add a new data server to reduce latency to 2.5 seconds within one person-week.
  • (Broadly) scenarios are detailed examples of concrete requirement situations.

Six components of a well-formed quality attribute scenario

Scenarios should explicitly specify six components:

• Stimulus: the condition/event that arrives at the system
  • Examples: user operation, request for modification, evolution trigger.
• Stimulus source: where the stimulus comes from
  • Examples: internal/external users, internal/external systems, sensors.
• Artifact: the system element affected (what part processes the stimulus)
  • Examples: subsystems, components, data sources, interfaces.
• Environment: context/conditions under which the scenario occurs
  • Examples: peak period, normal period, server-down conditions.
• Response: what the system does after the stimulus
  • Examples: process completes, deny access, send stop command, resume processing.
• Response measures: how success is quantified
  • Examples: completes within 30 seconds, stops within 1 second, no data loss.

Scenario composition examples

• Use case example: remote user requests report during peak → receives it within 5 seconds.
• Growth example: request to add a new data server → reduce latency to 2.5 seconds within one person-week.
• Availability/normal operation example: half the server goes down → system continues without overall availability degradation.

---

Detailed methodology: Attribute-Driven Design (ADD) steps (instructions)

What ADD is

• ADD is an iterative architecture design method based on quality scenarios and architecture drivers.
• It prioritizes requirements and progressively refines the architecture.

High-level ADD strategy

• Treat the system as a black box initially.
• Use requirement priorities to guide incremental decomposition.
• In each iteration, focus on a subset of drivers rather than all drivers at once.

Seven (7) steps of an iteration in ADD

The iteration structure:

1. Review inputs and set iteration goals
   • Identify what will be achieved in the current iteration.
2. Select an input
   • Choose one or more elements of the system to decompose.
3. Select a design concept
   • Choose design concepts that satisfy the selected input/requirements.
4. Instantiate architecture elements
   • Create/define architecture elements that embody the design concept.
5. Allocate responsibilities and define interfaces
   • Assign responsibilities to elements and define how they communicate.
6. Sketch / redesig (views / design decisions)
   • Produce sketches/views of the design (structure + runtime/behavior-related views as needed).
7. Perform analysis / verify iteration goals
   • Evaluate whether the defined design satisfies the targeted drivers.
   • Proceed to the next iteration until all drivers are covered.

How ADD uses iteration priority

• Requirements are divided into priority groups (example given conceptually):
  • highest priority
  • middle priority
  • low priority
• Architecture design work is done faster for higher-priority drivers because they drive early decomposition.

Guidance on views

The process includes sketching multiple view types, especially:

• Structural views
• Runtime/behavior views (concurrency, collaboration, runtime interactions)
• Development view (when scenarios concern modifiability)

Not every scenario requires every view—create views that support evaluation.

Analysis benefit from narrowing focus

• ADD’s benefit: focusing analysis on a subset of drivers per iteration makes evaluation feasible and targeted.

Knowledge reuse throughout ADD

Use architecture knowledge artifacts (patterns/tactics/reference architectures) when:

• selecting design concepts
• guiding decomposition
• ensuring tactics match scenario needs.

---

Example-driven explanation (garage system)

Example scenario set

• Functional drivers
  • Garage control functions.
• Quality attribute scenarios
  • Modifiability: reduce modification cost to accommodate different equipment/control methods.
  • Performance: obstacle detected → the door must stop within one second.

Iteration-based refinement shown

Iteration 1 (functional + initial quality)

• Architecture includes controllers, sensors, actuators.
• System supports extension via interfaces:
  • sensor interfaces allow adding new sensors easily.

Iteration 2 (performance/coordination refinement)

• Problem: when obstacle detected and user issues close command simultaneously, coordination is missing.
• Solution introduced:
  • add a scheduler/coordinator mechanism to enforce correct ordering:
    • deny rotation/execute stop first in emergency conditions.

Iteration progression logic

• Each iteration targets specific drivers, refining the design from:
  • simple conceptual architecture
  • to concrete mechanisms and components.

---

Speakers / sources featured

• SEI (Software Engineering Institute), Carnegie Mellon University
  • Referenced as the origin of:
    • Architecture Design and Evaluation methods
    • ATAM (Architecture Tradeoff Analysis Method) for evaluation
    • ADD (Attribute-Driven Design) as the architecture design method discussed in detail
• No individual speakers’ names are given in the subtitles (only institutions/method names are mentioned).