TQTeqVault StudySoftware Design & Principles

Labs

Hands-On Design Labs

These labs are not filler. Each one asks students to diagnose, design, refactor, diagram, test, or review software.

Lab Submission Standard

Every lab submission should include the artifact, a short explanation of design choices, and one paragraph describing what the student would improve with more time.

Lab 1

Bad Code Diagnosis

Connected lesson: Week 1 — What Software Design Really Means

Scenario: You receive a small program that works but mixes input, calculation, storage, and output in one function.

Steps

  1. Run or read the program and describe what it does.
  2. Highlight every place where two responsibilities are mixed together.
  3. Name at least three changes that would be risky in the current design.
  4. Rewrite the design as a simple module list. Do not refactor yet; just diagnose.

Deliverables

  • One-page design critique
  • List of responsibilities
  • List of likely future changes
  • Proposed module breakdown
Lab 2

Requirement Recovery

Connected lesson: Week 2 — Requirements, Constraints, and Acceptance Criteria

Scenario: A client says: “I need an app for managing campus events.”

Steps

  1. List stakeholders: students, organizers, admins, visitors.
  2. Write at least 12 functional requirements.
  3. Write at least 6 non-functional requirements.
  4. Write 5 user stories with acceptance criteria.
  5. Identify 5 assumptions and 5 constraints.

Deliverables

  • Requirements document
  • Acceptance criteria table
  • Assumptions and constraints section
Lab 3

Modular Refactor Plan

Connected lesson: Week 3 — Decomposition, Modularity, Cohesion, and Coupling

Scenario: You are given a single-file gradebook app. It reads scores, calculates grades, saves results, and prints reports.

Steps

  1. Identify every responsibility in the file.
  2. Group related responsibilities into modules.
  3. Draw arrows showing dependencies between modules.
  4. Find at least two dependencies that should be inverted or removed.
  5. Write a refactor order that avoids breaking behavior.

Deliverables

  • Responsibility list
  • Module map
  • Dependency sketch
  • Refactor plan
Lab 4

Domain Modeling with Objects

Connected lesson: Week 4 — Object-Oriented Design That Does Not Fight You

Scenario: Design an inventory system for a small campus bookstore.

Steps

  1. Identify core objects: Product, InventoryItem, Supplier, PurchaseOrder.
  2. Write the rules each object must protect.
  3. Create a class diagram.
  4. Implement at least three classes with validation.
  5. Write a short note on where composition is better than inheritance.

Deliverables

  • Class diagram
  • Starter code
  • Rule list
  • Composition explanation
Lab 5

SOLID Refactor: Reports

Connected lesson: Week 5 — SOLID Part 1: SRP, OCP, and LSP

Scenario: A ReportManager class loads data, calculates totals, formats HTML, saves files, and emails the report.

Steps

  1. List each reason ReportManager might change.
  2. Split the class into focused responsibilities.
  3. Identify one behavior that should be open for extension.
  4. Write or sketch the new interfaces/classes.
  5. Explain how the design improves testing.

Deliverables

  • Refactored design
  • Class list
  • Short SOLID explanation
  • Testability note
Lab 6

Notification System Design

Connected lesson: Week 6 — SOLID Part 2: Interfaces, Dependency Inversion, and Testability

Scenario: A campus app must send announcements by email today, SMS next semester, and push notifications later.

Steps

  1. Define a focused NotificationSender interface.
  2. Create at least two implementations.
  3. Create a service that depends on the interface, not implementations.
  4. Write a fake implementation for tests.
  5. Explain how ISP and DIP appear in your design.

Deliverables

  • Interface design
  • Implementation code or pseudocode
  • Test fake
  • Explanation
Lab 7

Clarity Refactor

Connected lesson: Week 7 — DRY, KISS, YAGNI, and Naming

Scenario: You receive code with vague names, duplicated conditions, and several unnecessary abstractions.

Steps

  1. Rename variables and methods to reveal intent.
  2. Identify duplicated knowledge vs harmless similar code.
  3. Remove one abstraction that does not serve a requirement.
  4. Write a short explanation of how the code became easier to read.

Deliverables

  • Before/after code
  • Naming improvements list
  • Removed overengineering note
Lab 8

Diagram a Workflow

Connected lesson: Week 8 — UML and Practical Design Diagrams

Scenario: Model the checkout workflow for a food ordering app.

Steps

  1. Write the workflow in plain English.
  2. Create a sequence diagram for the workflow.
  3. Create a class or component diagram for the same system.
  4. Mark one dependency that could become a problem.
  5. Explain the design improvement you would make.

Deliverables

  • Sequence diagram
  • Class/component diagram
  • Design note
Lab 9

Pattern Choice Lab

Connected lesson: Week 9 — Design Patterns Part 1: Strategy, Factory, Observer, Singleton

Scenario: A mini game needs enemies with different movement and attack styles.

Steps

  1. Identify which behavior varies.
  2. Choose Strategy or Factory where appropriate.
  3. Implement two movement behaviors.
  4. Create a factory that builds enemies from configuration.
  5. Explain one pattern you chose not to use.

Deliverables

  • Pattern implementation
  • Short pattern justification
  • One warning about overuse
Lab 10

Repository and UI Separation

Connected lesson: Week 10 — Design Patterns Part 2: Adapter, Decorator, Command, Repository, MVC/MVVM

Scenario: A task tracker stores data directly inside button click handlers.

Steps

  1. Move validation into a service.
  2. Create a repository interface.
  3. Create one in-memory repository for tests.
  4. Keep UI handlers focused on user interaction.
  5. Explain how this resembles MVC or MVVM separation.

Deliverables

  • Refactored code
  • Repository interface
  • Short architecture note
Lab 11

Make It Testable

Connected lesson: Week 11 — Testing and Testable Design

Scenario: A service has hard-coded file access and sends real emails during tests.

Steps

  1. Identify all external side effects.
  2. Introduce interfaces for external services.
  3. Inject dependencies through constructors.
  4. Create fakes for tests.
  5. Write tests for at least three important rules.

Deliverables

  • Refactored service
  • Test doubles
  • Test cases
  • Design reflection
Lab 12

Architecture Sketch

Connected lesson: Week 12 — Software Architecture Basics

Scenario: Design a course registration system for a college.

Steps

  1. Identify users and core use cases.
  2. Draw a layered architecture.
  3. Define the main API or service operations.
  4. Identify external systems such as identity, payment, or email.
  5. Write three architectural tradeoffs.

Deliverables

  • Architecture diagram
  • API/service list
  • Tradeoff explanation
Lab 13

Refactor Safely

Connected lesson: Week 13 — Refactoring, Code Smells, and Technical Debt

Scenario: You receive a working but messy invoice system.

Steps

  1. Write or identify expected behavior.
  2. Find at least five code smells.
  3. Choose one smell to refactor first.
  4. Make small changes and verify behavior after each step.
  5. Write a technical debt note.

Deliverables

  • Code smell list
  • Refactored code
  • Test/check evidence
  • Technical debt note
Lab 14

Final Design Review

Connected lesson: Week 14 — Final Design Review and Professional Presentation

Scenario: Students review each other’s capstone projects before final submission.

Steps

  1. Present the system in five minutes.
  2. Show one diagram and one code example.
  3. Explain one principle and one pattern used.
  4. Receive peer feedback on clarity and design risk.
  5. Revise final submission based on feedback.

Deliverables

  • Presentation draft
  • Peer feedback form
  • Final revision note