Ch 06: Solving Really Big Problems
Source: Head First Object-Oriented Analysis & Design | Pages: 314-357
🎯 Learning Objectives
Master object-oriented analysis and design principles for building flexible, maintainable software.
📚 Key Concepts
Large-scale design
Feature lists
Use case diagrams
Breaking down complexity
📖 Detailed Notes
This chapter focuses on practical OOA&D principles and techniques for real-world software development.
1. Large-scale design
Essential for mastering object-oriented analysis and design.
Key Principles:
Focus on creating flexible, maintainable software
Apply OO thinking to real-world problems
Use proper analysis before implementation
2. Feature lists
Essential for mastering object-oriented analysis and design.
Key Principles:
Focus on creating flexible, maintainable software
Apply OO thinking to real-world problems
Use proper analysis before implementation
3. Use case diagrams
Essential for mastering object-oriented analysis and design.
Key Principles:
Focus on creating flexible, maintainable software
Apply OO thinking to real-world problems
Use proper analysis before implementation
4. Breaking down complexity
Essential for mastering object-oriented analysis and design.
Key Principles:
Focus on creating flexible, maintainable software
Apply OO thinking to real-world problems
Use proper analysis before implementation
💡 Three Key Takeaways
Large-scale design - Core principle for this chapter
Feature lists - Applying concepts in practice
Use case diagrams - Industry standards and approaches
✅ Self-Check Questions
What are the main OOA&D concepts covered in this chapter?
How do these principles improve software design?
Can you apply these concepts to a real project?
What are the trade-offs of different design approaches?
🔄 Quick Revision Checklist
📝 Practice Exercises
Apply the chapter concepts to your current project
Create diagrams and models using the techniques learned
Review existing code and identify improvement opportunities
Discuss design decisions with your team
🔗 Related Topics
Software architecture patterns
Design principles and best practices
UML diagrams and modeling
Agile development practices
For complete details, case studies, and examples, refer to Head First OOA&D, pages 314-357.
Chapter 6: "My Name is Art Vandelay"
"Solving Really Big Problems"
Overview
This chapter shifts focus from small, self-contained apps (like dog doors and guitar inventories) to large, complex systems. It introduces a new case study: a strategy game framework. The core lesson is how to handle "The Big Problem" by breaking it down into smaller, manageable pieces using Domain Analysis and Use Case Diagrams.
Case Study: Gary's Games (The Mission)
Gary wants to build a Game System Framework (GSF).
The Goal: A generic framework that game designers can use to build different types of strategy games (e.g., historical battles, sci-fi simulations).
The Complexity: Unlike the previous examples, this system has no concrete "items" yet—it's a tool to make games. The requirements are vague and broad.
The 3 Steps to Solving Big Problems
When faced with a massive system, don't try to solve it all at once.
Listen to the Customer (Gather Features):
Get a "Vision Statement" or a list of features.
Identify what the system is supposed to do.
Figure out "What" you are building (Domain Analysis):
Understand the "Game Domain."
Identify the big modules and how they relate.
Break it Down (Use Case Diagrams):
Split the system into smaller logical parts.
Identify Actors and Use Cases.
Step 1: Features & The Vision
Gary provides a list of high-level features for his framework:
Supports different terrains (snow, desert, swamp).
Supports different time periods (sci-fi, fantasy, medieval).
Supports different units (troops, tanks, wizards).
Key Insight: A "Feature" is a high-level requirement. It describes what the system supports, not necessarily a specific step-by-step interaction (like a Use Case).
Step 2: Domain Analysis
Domain Analysis is the process of understanding the "world" your software lives in. It helps you speak the same language as the customer.
Identify Key Concepts: In a strategy game, what are the universal concepts?
Board: The grid where the game happens.
Tile: A single square on the board (holds terrain).
Unit: The soldier/tank/piece that moves on the board.
"What is the system like?"
Is it like Risk? Is it like Civilization?
"What is the system NOT like?"
It’s not a First Person Shooter (FPS). It’s not a real-time twitch game.
Step 3: Use Case Diagrams (The Blueprint)
A Use Case Diagram provides a visual overview of exactly what your system can do and who interacts with it. This is your "Big Picture" view before you dive into coding classes.
Components of a Use Case Diagram
The System Boundary: A big box representing your application. Everything inside is your code; everything outside is the "world."
Actors: Stick figures outside the box.
Role: Anyone (or anything) that interacts with the system.
Example: "Game Designer" (the person using the framework to make a game), "Player" (the end-user).
Use Cases: Ovals inside the box.
Role: A distinct goal or task the actor performs.
Example: "Create New Game," "Modify Board," "Save Game."
Lines: Connect Actors to the Use Cases they trigger.
Actors in Gary's Framework
Game Designer: The primary user. Uses the framework to create the game (sets up the board, defines units).
The Game (System Actor): Sometimes the "Actor" isn't a human. The Game itself might trigger actions, like "Manage Turn" or "Move Unit" (AI).
Key Concepts & Definitions
Domain Analysis
Definition: The process of identifying the classes and objects that exist in the problem domain (the real-world context of the software).
Why do it: It prevents you from inventing terms that don't make sense to the customer. If the customer calls it a "Unit," don't call it a "Soldier" in your code if it could also be a Tank.
The "Big Problem" Strategy
Don't code yet. If you start coding a massive system immediately, you will get lost.
Divide and Conquer. Break the system into modules (e.g., Board module, Unit module, Game Engine module).
Iterate on Design. Sketch out the modules and how they interact before writing the detailed logic.
Features vs. Requirements
Feature: A high-level description of a system capability (e.g., "Supports multiple terrains").
Requirement: A specific, testable constraint or function (e.g., "The board must be a grid of X by Y tiles").
Use Case: A specific interaction scenario (e.g., "Designer places a swamp tile on the board").
Chapter Summary (Bullet Points)
Big problems require big pictures. Use visual tools like Use Case Diagrams to understand the scope before diving into details.
Understand the Domain. You can't write good software for a domain (like Strategy Games) if you don't understand the terminology and rules of that domain.
The "System" is an Actor. Sometimes your own system triggers events (like time limits or AI moves). "The Game" can be an actor in your Use Case Diagram.
Modules help organization. Group related classes into modules (packages). This keeps your architecture clean.
Don't panic. When faced with a huge requirements document, just start identifying the nouns (Domain Analysis) and the goals (Use Cases).
Last updated