Listing Vault SE322 · chapter 01 · Introduction to Software Design and Architecture

Chapter 01 — Introduction to Software Design and Architecture

Foundations: what software engineering claims to be, where design sits in the lifecycle, who the architecture serves, and what separates an architectural decision from a detailed one.

01chapter
—lists
—total items
01

Introduction to Software Design and Architecture

15 lists

IEEE Definition — Keywords 3 + 3

A systematic, disciplined, quantifiable approach to software development, operation and maintenance.

The approach

  • Systematic — repeatable and reviewable
  • Disciplined — follows agreed practice, not taste
  • Quantifiable — measurable against stated targets

Applied to

  • Development
  • Operation
  • Maintenance

SDLC Phases 6

  1. Requirements
  2. Design
  3. Implementation
  4. Testing
  5. Deployment
  6. Maintenance

Engineering Problem Solving 6

  1. Initial state
  2. Goal state
  3. Constraints
  4. Candidate solutions
  5. Evaluation of candidates
  6. Implementation

Why Study Design 3

  1. Defects are cheaper to remove before construction
  2. Costly decisions are easier to reverse on paper
  3. Cost of change grows roughly by an order of magnitude per phase

Architecture Addresses 3

The three things an architecture description is about.

  1. Elements — the parts the system is built from
  2. Externally visible properties — provided services, performance, resource use
  3. Relationships — how the elements are connected and interact

Architecture vs Detailed Design compare

ArchitectureDetailed Design
ScopeSystem-wide structuresIndividual components and collaborations
OutputElements, visible properties, relationshipsClasses, interfaces, algorithms, data structures
Cost to reverseExpensive, affects many teams and qualitiesLocal and cheaply replaced
ExampleSplit the shop into catalog, cart and payment services over HTTPInside the cart, a HashMap keyed by SKU and a Strategy per discount rule

Managing Complexity 3

  1. Abstraction
  2. Decomposition
  3. Separation of concerns

Stakeholders & Their Concerns 5

  1. Users — usability, reliability
  2. Developers — modifiability
  3. Operators — deployability, observability
  4. Business — time to market, cost, market position
  5. Maintainers — testability, comprehensibility

Viewpoint vs View 2

  1. Viewpoint — frames particular concerns and says what to show and for whom
  2. View — the resulting representation of the system from that viewpoint

Architectural Drivers 4

The small set of requirements with major architectural influence.

  1. Business goals
  2. Functional requirements (only the few that are architecturally significant)
  3. Quality attributes
  4. Constraints — mandated technology, regulation, budget, legacy integration

Design Process Activities 5

  1. Understand requirements and context
  2. Decompose around responsibilities and change boundaries
  3. Define structures, responsibilities and interfaces
  4. Record decisions, rationale, assumptions and rejected alternatives
  5. Validate early with scenarios, prototypes, reviews and risk analysis

Attribute-Driven Design (ADD) Iteration 5

  1. Choose an element to decompose
  2. Pick the driving requirement for this round
  3. Select tactics and patterns
  4. Allocate responsibilities and define interfaces
  5. Verify, then start the next round

Qualities of Good Design 6

  1. Correctness
  2. Simplicity
  3. Cohesion
  4. Low coupling
  5. Information hiding
  6. Evolvability

Design Challenges 5

  1. Volatile, changing requirements
  2. Inconsistent development processes
  3. Rapidly changing technology (AI/ML adds fast-moving constraints)
  4. Competing design influences and conflicting quality goals
  5. Professional and ethical obligations as real constraints

Essential vs Accidental Complexity 2

  1. Essential — comes from the problem itself and cannot be designed away
  2. Accidental — comes from our chosen solution and is the part we can remove