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

StructureShowsAnswers
ModuleImplementation units and their dependenciesWhat can a developer change, and what breaks?
Component-and-connectorRuntime elements and their interactionsWhat is running, and how does it talk?
AllocationSoftware mapped to hardware, teams, files, environmentsWhere 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

ViewServesTypical diagrams
LogicalEnd usersClass, collaboration, sequence
ProcessIntegratorsActivity models
DevelopmentProgrammersComponent, package
PhysicalSystem engineersDeployment
Scenarios (+1)All of them — validates the other fourUse 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