Listing Vault SE322 · chapter 02 · Software Architecture

Chapter 02 — Software Architecture

Structures, views, requirements engineering, the 4+1 model, architectural decisions, interfaces and the architecture lifecycle.

02chapter
—lists
—total items
02

Software Architecture

16 lists

The Three Structure Categories 3

Structure Shows Answers
Module Implementation units and their dependencies What can a developer change, and what breaks?
Component-and-connector Runtime elements and their interactions What is running, and how does it talk?
Allocation Software mapped to hardware, teams, files, environments Where does it live, and who owns it?

Why Structures Cannot Be One Diagram 2

  1. One module can map to many runtime components
  2. One component can span many modules

A Viewpoint Defines 4

  1. Conventions and notation
  2. Stakeholders
  3. Concerns addressed
  4. Modeling rules

Requirements Engineering Activities 5

  1. Elicitation
  2. Analysis
  3. Specification
  4. Validation
  5. Management

Elicitation Techniques 4

  1. Interviews
  2. Facilitated meetings
  3. Observation
  4. Scenarios

Requirements Analysis Includes 4

  1. Classification
  2. Prioritization
  3. Negotiation
  4. Conceptual modeling

Properties of a Good Requirement 6

  1. Specific
  2. Consistent
  3. Correct
  4. Attainable
  5. Complete
  6. Verifiable

Requirement Classifications 2 × 2

  1. Imposed — from outside: law, standards, corporate policy
  2. Derived — consequences the team infers from imposed ones
  3. Product-oriented — about the delivered system
  4. Process-oriented — about how the system is built

Kruchten 4+1 Views 5

View Serves Typical diagrams
Logical End users Class, collaboration, sequence
Process Integrators Activity models
Development Programmers Component, package
Physical System engineers Deployment
Scenarios (+1) All of them — validates the other four Use cases, textual flows

ADR Contents 5

  1. Context
  2. Decision
  3. Alternatives considered
  4. Consequences
  5. Status

ADR Status Values 4

  1. Proposed
  2. Accepted
  3. Deprecated
  4. Superseded

Interface Contract Covers 6

  1. Syntax
  2. Semantics
  3. Protocols
  4. Errors
  5. Timing
  6. Versioning

The Two Sides of an Interface 2

  1. Provided — the services this element offers
  2. Required — what it needs from others; document only the provided half and you hide half the coupling

Making Semantics Checkable 3

  1. Preconditions
  2. Postconditions
  3. Invariants

Architecture Lifecycle Activities 6

  1. Analysis
  2. Synthesis
  3. Documentation
  4. Implementation
  5. Evaluation
  6. Governance

Erosion vs Drift 2

  1. Erosion — the code violates the intended structure
  2. Drift — the design evolves and the documentation does not follow