Software is a house.
Design is the foundation.
A simplified, memory-friendly rebuild of your Chapter 1 slides — every concept, every "Extra" note, and a mnemonic for each so nothing has to be memorized the hard way.
Foundations: Software, Engineering, SE
Three definitions everything else is built on.
WhatSoftware
A collection of instructions that let a user interact with computer hardware to perform tasks.
e.g. operating systems, word processors, browsers.
HowEngineering
A systematic process (organized & structured) where designers generate and evaluate designs to meet client objectives and user needs — inside a set of constraints.
Like a bridge: careful planning for weight, weather, environment.
IEEESoftware Engineering
Applying a systematic, disciplined, quantifiable approach to development, operation & maintenance of software.
Simply put: engineering principles applied to software.
The Software Engineering Life-Cycle
Five phases, always in this order.
Requirements
Analyzed, specified, and validated — what should the system do?
Design
Requirements become a design: architecture + detailed design.
Implementation
Design is coded into a real programming language.
Testing
Confirms the software works correctly and meets requirements.
Maintenance
Fixes faults, improves performance, or adapts after delivery.
Extra — real deployment task list per phase
- Requirements Gathering: interviews, feasibility checks.
- Design: UML diagrams, architecture blueprint.
- Implementation: writing & integrating code modules.
- Testing: unit, integration, system testing.
- Deployment: releasing to production (e.g. cloud server).
- Maintenance: patches, security updates, monitoring feedback.
Engineering Problem-Solving
Every design problem passes through 3 states.
🟦 Initial State
Problem is formulated & interpreted. Sometimes just understanding the problem is the problem.
🟧 Operational State
Once understood, you think through viable solutions — brainstorming happens here.
🟩 Goal State
Best solution is identified, evaluated, validated — the process ends here.
PuzzleThe 9-Dot Trap: Functional Fixedness
Connect 9 dots with 4 straight lines, without lifting the pencil. Most people assume lines must start/end on a dot — that assumption isn't actually a rule. This trap is called functional fixedness: limiting solutions to an object's "usual" function.
Extra — the Holistic Problem-Solving Framework
The 3 states combine into 6 concrete tasks:
Interpret the problem (Initial)
Understand & classify it.
Evaluate constraints (Initial)
Identify external limits on the solution space.
Collaborative brainstorming (Operational)
Generate multiple possible solutions.
Synthesize possibilities (Operational)
Narrow down to one acceptable solution.
Evaluate the solution (Operational)
Flaws found here send you back to brainstorming.
Implement solution (Goal)
Build it — problem-solving is complete.
Software Engineering Design
Design is both a process and a product — never confuse the two.
| Perspective | Describes | Owned by | Example |
|---|---|---|---|
| Process | Phase activities & tasks to model structure/behavior before construction | Project management | Planning, organizing, assigning tasks, timelines |
| Product | Artifacts that result from design activities | Technical team | Class diagrams, sequence diagrams |
Why Study Software Design?
Two lenses: managing the project, and building the product.
📋 Project Management lens
- Minimizes effects of requirements volatility (modular design absorbs new features)
- Increases efficiency of human resource allocation
- Prevents "one guy owns the whole system" risk
- Improves planning, organization, staffing, tracking
⚙️ Technical / Product lens
- Maps requirements → conceptual models
- Represents structure & behavior (use case, sequence diagrams)
- Identifies main components & interfaces
- Evaluates quality attributes (usability, efficiency…)
- Enables reuse across projects
- Forms the foundation for construction, testing, maintenance
5 Major Design Challenges
Complexity of modern systems makes these hard to avoid.
Requirements Volatility
Requirements grow/change during the lifecycle. Costly late — may force rework of design, verification, deployment. e.g. banking app needs new security login mid-build.
Inconsistent Dev Processes
Design process is unestablished, poorly understood, or skipped. Team A = Agile, Team B = Waterfall → nothing integrates.
Fast, Ever-Changing Tech
Designers must learn new tech (AI/ML, mobile OS updates) while keeping legacy systems interoperable, on schedule.
Managing Design Influences
Multiple stakeholders, conflicting wants. Requires trade-offs — hard in large systems. Execs want profit; security wants protection.
Ethical & Professional Practice
Design must protect users/environment under pressure. See the ACM Code of Ethics.
Extra — the ACM Code of Ethics, 3 principle groups
- Contribute to society & wellbeing: respect privacy, be honest & fair.
- Professional responsibilities: follow rules, ensure security, access resources ethically.
- Leadership principles: prioritize the public good, enhance work quality, apply ethical policies.
The Software Design Process
Requirements flow through Architecture → Detailed → Construction, wrapped in Documentation & Management.
Major vs. Supporting Activities
MAJOR
- Software Architecture
- Detailed Design
SUPPORTING
- Construction Design
- Human‑Computer Interface Design
- Design Documentation
- Management Activities
Architecture vs. Detailed Design
| Aspect | Software Architecture | Detailed Design |
|---|---|---|
| Provides | Big picture: major components, connections, quality attributes | Internal details: algorithms, data structures, workflows |
| Viewpoint | Black-box (what & how components interact) | White-box (how each is built internally) |
| Timing | Before detailed design / coding | After architecture is reviewed & approved |
| Focus | Mostly non-functional (quality) requirements | Functional requirements (exact logic & data) |
| Purpose | Communication tool for all stakeholders | Guides developers on implementation |
| Bank app example | Login System, Transaction Service, Database & how they connect securely | How Login checks credentials — encryption, API calls, error handling |
Detailed Design's Two Tasks
Task 1Component Design
Designs the internal structure & behavior of components identified during architecture — usually class & sequence diagrams (UML).
Task 2Interface Design
Specifies how components connect.
- Internal interface: between two parts inside your system. Login → Transaction Service.
- External interface: between your system and something outside. Banking app → payment gateway.
Extra — Construction Design & HCI Design
Construction Design — the lowest, most detailed level: how functions are literally coded (e.g. binary vs linear search, chosen for speed).
Human-Computer Interface (HCI) Design — optimizes the interaction between users and the software; usability, friendliness, accessibility. e.g. a login screen with clear errors and accessible button sizes.
Extra — Design Documentation & Management (why they matter)
📄 Documentation
- Starts in design phase, continues the whole lifecycle
- Records all decisions for traceability
- Used by managers, designers, developers, testers, maintainers
🗂 Management
- Plans & controls resources to hit goals
- Delivers quality designs on time, in budget
- Handles configuration & change management
The 8 Design Principles
The complete toolbox — modularization is the engine; the rest justify and refine it.
Modularization
Continuous decomposition into fine-grained components until each is small & focused. Payment Processor → Card Validator + Authorizer + Receipt Generator.
Abstraction
Focus on essential characteristics, defer unneeded detail. Guides how to modularize. Applies to data and functions (e.g. "SEND" hides the TCP handshake).
Encapsulation
Expose only what's essential, hide the rest — no more, no less. Works hand-in-hand with abstraction. Password stays private; access only via login().
Coupling
Degree of interdependence between modules. Aim low. (Full breakdown below ↓)
Cohesion
How related the tasks inside one module are. Aim high. (Full breakdown below ↓)
Separation of Interface & Implementation
Keep the stable "what" separate from the swappable "how" — lets you provide different implementations of the same interface. Not the same as encapsulation!
Completeness
The module provides all required services — no less. A comms class missing "terminate connection" is incomplete.
Sufficiency
The module provides only what's needed — no more. A messaging module shouldn't also manage user profiles.
🏠 The House Analogy, one more time
- Modularization = split the house into rooms
- Abstraction = name each room by purpose (Bedroom, Kitchen) — no need to list every detail inside
- Encapsulation = lock the rooms; hand out keys only for doors you're allowed to open
Coupling — The Dependency Ladder
Higher on the ladder = more dependency = harder to maintain. Aim as low as you can.
Extra — Good vs. Bad design, worked example
✅ Good: ShoppingCart only has addItem(),
removeItem(), calculateTotal() — all about cart management (high
cohesion), and it talks to Database/PaymentService only through an
interface (low coupling). Swap SQLite for Firebase and nothing breaks.
❌ Bad: A CartManager utility with addItemToCart(),
sendEmailToUser(), connectToDatabase() — unrelated jobs (low
cohesion) that directly create Database and EmailService objects
(tight coupling). Change the email service → forced to edit CartManager.
Cohesion — 4 Flavors
How well the tasks inside one module belong together. High cohesion = good.
Functional
All subunits contribute to one function. calculateTotal() sums cart
prices.
Procedural (Sequential)
Tasks run in steps, each step's output feeds the next. processOrder():
validate → calculate → pay.
Temporal
Tasks happen at the same time/phase, not necessarily related otherwise.
initializeSystem(): connect DB, load config, log startup — all at boot.
Communication
Tasks operate on the same data. generateStudentReport(): GPA + courses
+ grades, all from one student record.
Design Strategies & Considerations
Two ways to decompose a system, and two rules that override everything.
| Object-Oriented | Structured (Functional) | |
|---|---|---|
| Unit of decomposition | Objects (name + attributes + behavior) | Functions, top-down |
| Supports | Inheritance & polymorphism | — |
| Best for | Object-oriented languages | Non-OOP; inappropriate for OOP languages |
| Communication | Objects send messages to each other | Main program calls functions top-down |
Roles of Software Designers
Four hats, four zoom levels.
🏗️ Systems Engineer
Designs the whole development process — both software and hardware.
🧱 Software Architect
Black-box modeling of the big structure — external properties & quality attributes.
🔧 Component Designer
Internal structure/behavior of components; strong programmer, implements in code.
🎨 User Interface Designer
Designs the UI; focused on usability.
Worked Exercise — Student Registration System
Apply modularization, abstraction & encapsulation
1 · Modularization — split into fine-grained modules:
- User Management (login, registration, profile)
- Course Catalog (available courses & details)
- Registration (enrolls students)
- Payment (processes fees)
- Schedule & Timetable
- Notifications (email/SMS)
- Reports & Records (transcripts, history)
2 · Abstraction — decide what each module exposes vs. hides:
- Data abstraction: Payment module shows "Paid/Unpaid" but hides bank transaction IDs.
- Behavior abstraction: Registration offers
enrollStudent(courseID)but hides eligibility checks & DB updates.
3 · Encapsulation (Payment Module example):
- Card numbers made private
- Public methods only:
processPayment(),checkPaymentStatus() - No direct access to internal logic — only via the defined interface
Full Chapter Recap
Every mnemonic from this page, in one place.
SE definition
- S.D.Q. — Systematic, Disciplined, Quantifiable
Lifecycle phases
- Real Designers Implement, Test, Maintain (R‑D‑I‑T‑M)
Problem-solving states
- "I Own the Goal" — Initial, Operational, Goal
SE Design
- Two P's: Process + Product
5 challenges
- Rats In Fields Munch Everything (R‑I‑F‑M‑E)
Architecture vs Detail
- Black box vs. White box
8 principles
- My Aunt Ellen Cooks Chicken, Selling Complete Servings
Coupling ladder
- Crazy Cats Eat Cheese, Sometimes Drinking Nothing
Cohesion types
- Friendly Pandas Take Cookies
Considerations
- Keep it Simple, Keep it Changeable