Program Design
IS 436 — Chapter 10
What We're Learning
Big idea: Before any code is written, an analyst creates a detailed game plan for programmers.
This chapter = how to build that game plan.
This chapter = how to build that game plan.
- Turn a logical diagram into a physical plan with real tech details
- Draw a structure chart — a map of every program piece
- Write a program spec — instructions for each piece
- Use pseudocode — plain-English logic steps (no coding language needed)
- Understand event-driven programming — programs that react to things that happen
Logical vs. Physical — What's the Difference?
Logical DFD
Answers: "What does the system do?"
Like a restaurant menu —
it lists "Burger, Fries, Soda"
but says nothing about how they're made.
Answers: "What does the system do?"
Like a restaurant menu —
it lists "Burger, Fries, Soda"
but says nothing about how they're made.
Physical DFD
Answers: "How will we build it?"
Like the kitchen recipe —
exact ingredients, cooking steps,
who grills and who assembles.
Answers: "How will we build it?"
Like the kitchen recipe —
exact ingredients, cooking steps,
who grills and who assembles.
Example
Logical says "Save customer data."
Physical says "INSERT CustomerID (int), Email (varchar 100), SignupDate (date) into the MySQL Customers table."
Physical says "INSERT CustomerID (int), Email (varchar 100), SignupDate (date) into the MySQL Customers table."
The Physical Model — 3 Things It Adds
① Real technology — not just "a database," but which database and where.
Example "We use PostgreSQL on Amazon RDS" instead of just "data store"
Example "We use PostgreSQL on Amazon RDS" instead of just "data store"
② Exact data formats — what shape is every field?
Example Phone number →
Example Phone number →
(###) ###-#### |
Price → decimal(10,2) |
Date → YYYY-MM-DD
③ Who does what — human or computer?
Example 🧑 Cashier scans items (human step)
🖥️ System looks up prices and calculates tax (automatic step)
A dotted line on the diagram separates the two sides.
Example 🧑 Cashier scans items (human step)
🖥️ System looks up prices and calculates tax (automatic step)
A dotted line on the diagram separates the two sides.
Physical DFD — Simple Rules
Rule 1 — Don't start from scratch.
Keep every shape from the logical DFD. Just add details on top.
Keep every shape from the logical DFD. Just add details on top.
Rule 2 — Replace vague names with real ones.
Example "order info" becomes "OrderID, CustomerID, ItemList, TotalPrice, OrderDate"
Example "order info" becomes "OrderID, CustomerID, ItemList, TotalPrice, OrderDate"
Rule 3 — Add technical steps that only coders care about.
Example Add a "Write to Error Log" step that runs every time a payment fails — this wasn't in the logical DFD.
Example Add a "Write to Error Log" step that runs every time a payment fails — this wasn't in the logical DFD.
Rule 4 — Label who or what runs each process.
Example "Verify Age" → handled by the AgeVerification microservice, not a human
Example "Verify Age" → handled by the AgeVerification microservice, not a human
5 Steps to Build the Physical DFD
1
Label who runs each process
Write the person's name or system name inside or next to each process bubble.
Example "Process Payment" → Stripe API (automated)
Write the person's name or system name inside or next to each process bubble.
Example "Process Payment" → Stripe API (automated)
2
Draw the human-machine boundary
A dotted line: everything above = human, everything below = computer.
Example Customer fills form (human) → system saves it (computer)
A dotted line: everything above = human, everything below = computer.
Example Customer fills form (human) → system saves it (computer)
3
Add technical processes
Error logs, temp files, session tracking — invisible to users, essential for developers.
Error logs, temp files, session tracking — invisible to users, essential for developers.
4
Replace vague data labels with real field names
Example "user info" → UserID (int), Username (varchar 50), PasswordHash (char 64)
Example "user info" → UserID (int), Username (varchar 50), PasswordHash (char 64)
5
Update the shared data dictionary
Record every change so the whole team uses the same definitions.
Record every change so the whole team uses the same definitions.
Side-by-Side: Logical vs. Physical DFD
Left = logical (what the system does). Right = physical (how it's built). Spot the new labels, dotted boundary line, and exact field names on the right.
Designing Programs
After the physical DFD is done, the analyst designs how each program module will work.
Analogy: The physical DFD is the city map. Program design is the detailed blueprint for each individual building.
Goal: Hand programmers a complete plan so they can build the system without asking any questions.
Three main tools:
① Top-down, modular approach → ② Structure chart → ③ Program specifications
① Top-down, modular approach → ② Structure chart → ③ Program specifications
Top-Down, Modular Approach
Start with the big picture. Keep breaking it into smaller pieces until each piece does exactly one thing.
Example — Amazon "Place Order"
Level 1: Place Order
Level 2: Validate Cart | Charge Card | Send Confirmation Email | Update Inventory
Level 3 (under Charge Card): Check Card Details | Contact Bank | Record Transaction
Level 1: Place Order
Level 2: Validate Cart | Charge Card | Send Confirmation Email | Update Inventory
Level 3 (under Charge Card): Check Card Details | Contact Bank | Record Transaction
Why it helps: Each small piece can be built, tested, and fixed independently.
If the email module breaks, the payment module still works fine.
If the email module breaks, the payment module still works fine.
The Structure Chart
A diagram that shows all program modules arranged like a family tree — who calls who, and what data is passed.
Think of it like
A company org chart.
CEO = top module (controls everything)
Managers = mid modules (coordinate)
Workers = bottom modules (do the actual work)
A company org chart.
CEO = top module (controls everything)
Managers = mid modules (coordinate)
Workers = bottom modules (do the actual work)
3 types of logic it shows:
Sequence — do A, then B, then C
Selection — if discount? yes/no
Iteration — repeat for every item in the cart
Sequence — do A, then B, then C
Selection — if discount? yes/no
Iteration — repeat for every item in the cart
Structure Chart — Example
Top box = the main controller. It calls the boxes below it. Those boxes call the ones below them. Labels on arrows show what data moves between boxes.
What Do the Symbols Mean?
Rectangle = one module (one job)
e.g., "Calculate Tax"
e.g., "Calculate Tax"
Arrow = a module calling another
Parent always calls child — never the other way
Parent always calls child — never the other way
Open circle on arrow = data being passed
e.g., "cartTotal" flows down to "ApplyDiscount"
e.g., "cartTotal" flows down to "ApplyDiscount"
Filled circle on arrow = a yes/no flag
e.g., "paymentOK = true" sent back up to parent
e.g., "paymentOK = true" sent back up to parent
Diamond = an if/else choice
e.g., only call "SendSMS" if phone number exists
e.g., only call "SendSMS" if phone number exists
Curved arrow = a loop
e.g., repeat "ProcessItem" for every item in cart
e.g., repeat "ProcessItem" for every item in cart
How to Build a Structure Chart — 4 Steps
1
Start with the top module — the main function of the program.
Example "Process Online Order" is the top box.
Example "Process Online Order" is the top box.
2
Break it into sub-modules — keep splitting until each box does ONE thing.
Example "Process Online Order" → "Validate Cart" + "Charge Payment" + "Send Email" + "Update Stock"
Example "Process Online Order" → "Validate Cart" + "Charge Payment" + "Send Email" + "Update Stock"
3
Draw the call arrows — parent always calls child. Never the other way around.
Example "Process Order" calls "Charge Payment."
"Charge Payment" does NOT call "Process Order."
Example "Process Order" calls "Charge Payment."
"Charge Payment" does NOT call "Process Order."
4
Label arrows with what's passed
Example Going down: cartItems, customerID | Coming back up: paymentSuccess (true/false)
Example Going down: cartItems, customerID | Coming back up: paymentSuccess (true/false)
Design Quality #1 — Cohesion
Cohesion = is each module focused on one job?
High cohesion = good. Low cohesion = bad.
❌ Low Cohesion (Bad)
One module called "HandleEverything":
• validates the login form
• sends a welcome email
• saves to the database
• generates a PDF receipt
If the email breaks, it might take down the whole login. Impossible to test one piece at a time.
One module called "HandleEverything":
• validates the login form
• sends a welcome email
• saves to the database
• generates a PDF receipt
If the email breaks, it might take down the whole login. Impossible to test one piece at a time.
✅ High Cohesion (Good)
Four separate modules:
• ValidateLoginForm()
• SendWelcomeEmail()
• SaveUserToDatabase()
• GeneratePDFReceipt()
Email breaks? Fix only that module. The others keep working.
Four separate modules:
• ValidateLoginForm()
• SendWelcomeEmail()
• SaveUserToDatabase()
• GeneratePDFReceipt()
Email breaks? Fix only that module. The others keep working.
Design Quality #2 — Coupling
Coupling = how much do modules depend on each other?
Loose coupling = good. Tight coupling = bad.
❌ Tight Coupling (Bad)
PrintReceipt() goes into the database itself to get the order data.
If the database table changes, PrintReceipt() breaks — even though printing has nothing to do with the database structure.
PrintReceipt() goes into the database itself to get the order data.
If the database table changes, PrintReceipt() breaks — even though printing has nothing to do with the database structure.
✅ Loose Coupling (Good)
ProcessOrder() fetches the data, then passes only what PrintReceipt() needs:
Now you can change the database however you want — PrintReceipt() never notices.
ProcessOrder() fetches the data, then passes only what PrintReceipt() needs:
orderTotal, itemList.Now you can change the database however you want — PrintReceipt() never notices.
Design Quality #3 — Fan-In & Fan-Out
Fan-In = how many modules call a given module.
High fan-in = good — that module is being reused a lot!
Example FormatCurrency() is called by the Cart page, the Receipt page, and the Admin Dashboard.
One module. Three places. Zero duplication.
High fan-in = good — that module is being reused a lot!
Example FormatCurrency() is called by the Cart page, the Receipt page, and the Admin Dashboard.
One module. Three places. Zero duplication.
Fan-Out = how many modules a given module calls.
Keep fan-out ≤ 7. More than that = the module is doing too much.
Example "ProcessOrder" that calls 10 sub-modules is too complex.
Fix: split it into ValidateOrder() (calls 4) + FulfillOrder() (calls 5).
Keep fan-out ≤ 7. More than that = the module is doing too much.
Example "ProcessOrder" that calls 10 sub-modules is too complex.
Fix: split it into ValidateOrder() (calls 4) + FulfillOrder() (calls 5).
Simple rule: A good module is called by many, calls few.
Structure Chart Quality Checklist
- Reuse modules wherever possible — write it once, call it from many places.
Bad: copy-pasting the same email logic into 4 modules. Good: one SendEmail() module called by 4 modules. - Aim for high fan-in — shared utility modules should be called by many.
- Max 7 children per module — if a module calls 10 others, split it up.
- One job per module — if you can't name it in 3–4 words, it's doing too much.
- Pass only what's needed — don't send 20 fields when the module uses 2.
e.g., don't pass the whole customer object to PrintReceipt() if it only needs customerName. - Use what you receive — if a module gets a value, it should actually use it.
- Flags flow upward — a child tells the parent "success/fail," not the other way.
e.g., CheckStock() returns "inStock = true" up to ProcessOrder(). - Each module has a reasonable size — not 1 line, not 500 lines.
Program Specifications — What Are They?
After the structure chart, you write a detailed instruction sheet for every single module.
Analogy
The structure chart is the floor plan of an apartment building.
The program spec is the instruction sheet for each apartment — what appliances go where, how the wiring works, what each switch does.
The program spec is the instruction sheet for each apartment — what appliances go where, how the wiring works, what each switch does.
The goal: A programmer picks up the spec and writes the code with zero questions for the analyst.
No single standard format — every company has its own template.
But all good specs cover the same 6 things (next slide).
But all good specs cover the same 6 things (next slide).
What Goes in a Program Spec?
| Section | Simple question it answers | Example |
|---|---|---|
| Module Info | What is this module called? | Name: ValidateLogin | Language: Python | Author: A. Chen |
| Trigger / Event | When does this run? | Runs when the user clicks the "Log In" button |
| Inputs | What data comes in? | username (text, max 50 chars), password (text, max 100 chars) |
| Outputs | What does it return? | loginSuccess (true/false), errorMessage (text) |
| Pseudocode | What is the step-by-step logic? | Written in plain English — next slides |
| Special Rules | Any business rules? | Lock the account after 5 failed attempts |
What is Pseudocode?
Pseudocode = plain English logic.
It's not a real programming language. It's the thinking written out before coding starts.
Why use it?
You focus on the logic, not semicolons and brackets.
A Python dev and a Java dev can both read the same pseudocode and build the same thing.
You focus on the logic, not semicolons and brackets.
A Python dev and a Java dev can both read the same pseudocode and build the same thing.
Common words:
Indent each level. Indentation = structure.
BEGIN / ENDIF / THEN / ELSE / ENDIFWHILE / ENDWHILEFOR EACH / ENDFORREAD / WRITECALL / RETURNIndent each level. Indentation = structure.
Pseudocode Example: User Login
BEGIN ValidateLogin
READ username, password
IF username is empty OR password is empty THEN
WRITE "Please fill in all fields"
RETURN loginSuccess = FALSE
ELSE
CALL CheckDatabase(username, password)
IF match found THEN
WRITE "Welcome, " + username
RETURN loginSuccess = TRUE
ELSE
ADD 1 to failedAttempts
IF failedAttempts >= 5 THEN
WRITE "Account locked — too many attempts"
ENDIF
RETURN loginSuccess = FALSE
ENDIF
ENDIF
END ValidateLogin
READ username, password
IF username is empty OR password is empty THEN
WRITE "Please fill in all fields"
RETURN loginSuccess = FALSE
ELSE
CALL CheckDatabase(username, password)
IF match found THEN
WRITE "Welcome, " + username
RETURN loginSuccess = TRUE
ELSE
ADD 1 to failedAttempts
IF failedAttempts >= 5 THEN
WRITE "Account locked — too many attempts"
ENDIF
RETURN loginSuccess = FALSE
ENDIF
ENDIF
END ValidateLogin
No real code. Just logic. Any programmer can turn this into Python, Java, C# — whatever the project uses.
Pseudocode Example: Shopping Cart Total
BEGIN CalculateCartTotal
READ cartItems, isMember
SET total = 0
FOR EACH item IN cartItems
SET total = total + (item.price × item.quantity)
ENDFOR
IF isMember = TRUE THEN
SET total = total × 0.90 ← 10% member discount
ENDIF
WRITE "Your total: $" + total
RETURN total
END CalculateCartTotal
READ cartItems, isMember
SET total = 0
FOR EACH item IN cartItems
SET total = total + (item.price × item.quantity)
ENDFOR
IF isMember = TRUE THEN
SET total = total × 0.90 ← 10% member discount
ENDIF
WRITE "Your total: $" + total
RETURN total
END CalculateCartTotal
FOR EACH = iteration (loop). IF = selection (choice). Together inside one module = high cohesion — this module does one job: calculate the total.
Textbook Pseudocode Example
Notice the indentation — it makes nesting clear at a glance, just like real code.
Full Program Specification (Textbook)
One document = module info + trigger + inputs/outputs + pseudocode. Programmers use this to write the code.
Event-Driven Programming
Most programs don't run from top to bottom. They wait… then react when something happens.
Analogy
A smoke detector doesn't beep all day.
It listens 24/7. The moment it detects smoke (event), it triggers the alarm (handler).
Your app works the same way.
It listens 24/7. The moment it detects smoke (event), it triggers the alarm (handler).
Your app works the same way.
Event = something that happens
• User clicks a button
• A timer goes off
• A file arrives
• A database record changes
• User clicks a button
• A timer goes off
• A file arrives
• A database record changes
Event Handler = the module that reacts
It sits idle until the event fires.
Then it runs automatically.
Your program spec must say: "This module runs when ___."
It sits idle until the event fires.
Then it runs automatically.
Your program spec must say: "This module runs when ___."
Event-Driven: Real App Examples
| What happens (Event) | Triggered by | Module that runs (Handler) |
|---|---|---|
| User clicks "Place Order" on Amazon | Button click | ValidateAndSubmitOrder() |
| Uber driver accepts your ride | Driver taps "Accept" in the app | NotifyRider() + StartLiveTracking() |
| Credit card is declined | Bank returns "failed" response | ShowErrorMessage() + LogFailedAttempt() |
| Netflix auto-plays next episode | Timer fires at end of credits | LoadNextEpisode() |
| Product goes out of stock | Inventory drops to 0 (DB trigger) | SendRestockAlert() + HideAddToCartButton() |
Every row = one event + one handler. Your program spec documents this "when X happens, run Y" relationship for every module.
Chapter 10 — Full Workflow
1
Physical DFD — Take the logical DFD. Add real tech, exact field names, the human-machine boundary, and technical steps.
Example "Store Order" → "INSERT OrderID, CustomerID, TotalPrice into MySQL Orders table"
Example "Store Order" → "INSERT OrderID, CustomerID, TotalPrice into MySQL Orders table"
2
Structure Chart — Draw the program like an org chart. Each box = one module. Arrows show calls. Labels show data.
Example "ProcessOrder" calls "ValidateCart", "ChargeCard", "SendEmail", "UpdateInventory"
Example "ProcessOrder" calls "ValidateCart", "ChargeCard", "SendEmail", "UpdateInventory"
3
Program Specifications — Write a spec for every module: what triggers it, inputs, outputs, pseudocode, special rules.
Example Spec for "ChargeCard": triggered by order confirmed; input: cardToken, amount; output: chargeSuccess (true/false)
Example Spec for "ChargeCard": triggered by order confirmed; input: cardToken, amount; output: chargeSuccess (true/false)
4
Hand off the Program Design Document — Bundle everything together. Programmers build the system from this alone.
If the document is good, programmers never need to ask a single question.