Software Design

Top-Down Design and Stepwise Refinement

Top-down design is one of the most fundamental techniques in software engineering. Rather than trying to solve an entire problem at once, you start with a high-level overview and progressively add detail.

How Stepwise Refinement Works

1. Identify the overall problem – state what the system must do at the highest level.
2. Decompose the problem into major sub-tasks (typically 3–6 at each level).
3. Refine each sub-task by breaking it down further into smaller steps.
4. Repeat until every step is simple enough to be implemented directly in code (i.e. it cannot meaningfully be broken down any further).

Example – Library Book Loan System

• Level 0: Library Book Loan System

• Level 1: Search for Book

  Issue Book

  Return Book

  Generate Reports

• Level 2 (Issue Book): Validate Member

  Check Availability

  Record Loan

  Print Receipt

Advantages of Top-Down Design

• Makes large problems manageable by dividing them into small, well-defined tasks.
• Enables team working – different programmers can work on different modules.
• Each module can be tested independently (unit testing).
• Produces a clear structure that is easy to understand and maintain.
• Naturally leads to modular, well-organised code.

---

Structure Diagrams

A structure diagram (also called a hierarchy chart) is a graphical representation of a top-down design. It shows the system broken down into modules arranged in a tree-like hierarchy.

Rules for Structure Diagrams

• The root node at the top represents the entire system.
• Each level below shows the sub-tasks that make up the level above.
• Lines connect parent modules to their children, showing which module calls which.
• Modules at the same level are read left to right in the order they would typically execute.
• The lowest-level modules are simple enough to be coded directly.

Example: Student Report System

graph TD
    A[Student Report System] --> B[Input Data]
    A --> C[Output Reports]
    B --> D[Read Marks]
    B --> E[Validate Marks]
    C --> F[Calculate Averages]
    C --> G[Display Results]

Example: ATM System

graph TD
    A[ATM] --> B[Authenticate User]
    A --> C[Transaction Menu]
    A --> D[Print Receipt]
    C --> E[Withdraw Cash]
    C --> F[Deposit Funds]
    C --> G[Check Balance]

---

Data Flow Diagrams (DFDs)

A Data Flow Diagram (DFD) models how data moves through a system. It shows where data originates, what processes transform it, where it is stored, and where it ends up. DFDs focus entirely on data – they do not show control flow, timing, or decision logic.

DFD Symbols

Symbol	Shape	Description
External Entity	Rectangle (square)	A source or destination of data that is outside the system boundary (e.g. a customer, another system)
Process	Circle (or rounded rectangle)	A task or action that transforms data. Must have at least one data flow in and one data flow out. Labelled with a verb phrase (e.g. “Validate Order”)
Data Store	Open-ended rectangle (two parallel lines)	A place where data is held for later use (e.g. a database table, a file). Labelled with “D1”, “D2”, etc. and a name
Data Flow	Arrow (labelled)	Shows the direction data travels. The label describes what data is flowing (e.g. “Order Details”, “Invoice”)

What DFDs Do NOT Show

• The order or sequence of processes.
• Decision logic (IF/ELSE).
• Loops or repetition.
• How data is processed internally within a process.

Levels of DFDs

DFDs can be drawn at different levels of detail:

Context Diagram (Level 0):

• Shows the entire system as a single process.
• Shows all external entities and the data flows between them and the system.
• Provides a high-level overview of the system boundary.
• Contains no data stores.

Level 1 DFD:

• Expands the single process from the context diagram into its main sub-processes.
• Shows data stores used by the system.
• Shows data flows between processes, data stores, and external entities.
• Every data flow in the context diagram must appear in the Level 1 DFD.

Level 2 DFD (and beyond):

• Further decomposes individual processes from Level 1 into more detailed sub-processes.
• Used when a Level 1 process is still too complex.

Example: Online Ordering System

Context Diagram (Level 0):

• External entities: Customer, Warehouse
• Single process: Online Ordering System
• Data flows: Customer sends “Order Details” to the system; system sends “Order Confirmation” to Customer; system sends “Dispatch Request” to Warehouse; Warehouse sends “Dispatch Confirmation” to system.

Level 1 DFD might include:

• Process 1: Validate Order
• Process 2: Process Payment
• Process 3: Arrange Dispatch
• Data Store D1: Customer Database
• Data Store D2: Product Database
• Data Store D3: Order Database

Rules for Drawing DFDs

• Every process must have at least one input and one output data flow.
• Data cannot flow directly between two external entities (it must pass through a process).
• Data cannot flow directly between two data stores (it must pass through a process).
• Data cannot flow directly from an external entity to a data store (it must pass through a process).
• All data flows must be labelled.
• Processes should be labelled with verb phrases (e.g. “Calculate Total”, not “Totals”).

---

State-Transition Diagrams

A state-transition diagram (STD) models the behaviour of a system by showing the different states it can be in and the events (or conditions) that cause it to change from one state to another.

Components

Component	Representation	Description
State	Rounded rectangle or circle	A condition or situation the system is in at a particular time (e.g. “Idle”, “Processing”, “Error”)
Transition	Arrow between states	A change from one state to another, triggered by an event
Event/Condition	Label on the transition arrow	What causes the transition (e.g. “Button Pressed”, “Timer Expires”)
Action	Label on the transition arrow (after /)	What happens as a result of the transition (e.g. “/ Display Error Message”)
Start state	Filled black circle	The initial state when the system begins
End state	Filled black circle inside a larger circle	A terminal state (the system stops)

Notation for Transition Labels

Transitions are typically labelled in the form: event [condition] / action

• event – what triggers the transition (e.g. “Insert Card”)
• [condition] – optional guard condition that must be true (e.g. “[PIN correct]”)
• /action – optional action that occurs during the transition (e.g. “/ Dispense Cash”)

Example: ATM Machine

stateDiagram-v2
    [*] --> Idle
    Idle --> ReadingCard : Insert Card
    ReadingCard --> AwaitingPIN : Card Valid
    ReadingCard --> Idle : Card Invalid / Eject Card
    AwaitingPIN --> MainMenu : PIN Correct
    AwaitingPIN --> AwaitingPIN : PIN Incorrect [attempts < 3]
    AwaitingPIN --> Idle : PIN Incorrect [attempts = 3] / Retain Card
    MainMenu --> ProcessingWithdrawal : Select Withdraw
    ProcessingWithdrawal --> Idle : Sufficient Funds / Dispense Cash
    ProcessingWithdrawal --> MainMenu : Insufficient Funds / Display Message
    MainMenu --> Idle : Select Cancel / Eject Card

Example: Simple Traffic Light

stateDiagram-v2
    [*] --> Red
    Red --> RedAmber : Timer expires
    RedAmber --> Green : Timer expires
    Green --> Amber : Timer expires
    Amber --> Red : Timer expires

When to Use State-Transition Diagrams

• Modelling systems that have clearly defined states (e.g. vending machines, login systems, games).
• Showing how a system responds to different events or inputs.
• Designing user interfaces where the screen changes based on user actions.
• Modelling communication protocols.

---

Entity-Relationship Diagrams (ERDs)

An Entity-Relationship Diagram (ERD) is used to model the data that a system stores and the relationships between different data entities. ERDs are a key tool in database design.

Components of an ERD

Component	Representation	Description
Entity	Rectangle	A thing about which data is stored (e.g. Student, Course, Order). Represents a table in a database.
Attribute	Listed inside or beside the entity (sometimes in ovals)	A data item stored about an entity (e.g. StudentID, Name, DateOfBirth)
Relationship	Diamond or labelled line between entities	How two entities are related (e.g. “enrols on”, “places”)
Primary Key	Underlined attribute	The attribute that uniquely identifies each record in the entity

Types of Relationship

Relationship	Notation	Meaning	Example
One-to-One (1:1)	1 —- 1	One instance of entity A relates to exactly one instance of entity B	One person has one passport
One-to-Many (1:M)	1 —- M	One instance of entity A relates to many instances of entity B	One teacher teaches many students
Many-to-Many (M:M)	M —- M	Many instances of entity A relate to many instances of entity B	Many students take many courses

Example: School Database

erDiagram
    TEACHER ||--o{ CLASS : teaches
    CLASS }o--o{ STUDENT : attends
    TEACHER {
        int TeacherID PK
        string Name
        string Department
    }
    CLASS {
        int ClassID PK
        string Subject
        string Room
    }
    STUDENT {
        int StudentID PK
        string Name
        date DateOfBirth
    }

• One TEACHER teaches many CLASSes (1:M).
• Many STUDENTs attend many CLASSes (M:M).

Resolving Many-to-Many Relationships

Many-to-many relationships cannot be directly implemented in a relational database. They are resolved by introducing a link entity (also called a junction table or associative entity) that sits between the two entities, converting the M:M into two 1:M relationships.

Example: STUDENT M:M CLASS becomes:

erDiagram
    STUDENT ||--o{ ENROLMENT : "enrols in"
    CLASS ||--o{ ENROLMENT : "has"
    ENROLMENT {
        int EnrolmentID PK
        int StudentID FK
        int ClassID FK
        date EnrolmentDate
    }

The ENROLMENT entity would contain: EnrolmentID, StudentID (foreign key), ClassID (foreign key), EnrolmentDate.

---

Pseudocode Conventions

Pseudocode is a structured, informal way of writing algorithms that uses natural language mixed with programming-like constructs. It is not tied to any specific programming language and is used to plan and communicate algorithms clearly.

Why Use Pseudocode?

• It allows you to focus on the logic of an algorithm without worrying about syntax.
• It is language-independent, so anyone can understand it regardless of their programming background.
• It is quicker to write than actual code during the design phase.
• It can be easily translated into any programming language.

Common Pseudocode Conventions

Variable assignment:

SET total TO 0
SET name TO "Alice"

Input and output:

INPUT age
OUTPUT "Your age is: ", age

Selection (IF/ELSE):

IF age >= 18 THEN
    OUTPUT "Adult"
ELSE IF age >= 13 THEN
    OUTPUT "Teenager"
ELSE
    OUTPUT "Child"
END IF

Iteration (FOR loop):

FOR i FROM 1 TO 10
    OUTPUT i
END FOR

Iteration (WHILE loop):

SET password TO ""
WHILE password != "secret"
    INPUT password
END WHILE

Iteration (REPEAT-UNTIL loop):

REPEAT
    INPUT number
UNTIL number >= 0

Subroutines:

FUNCTION calculateArea(length, width)
    RETURN length * width
END FUNCTION

PROCEDURE displayMessage(message)
    OUTPUT message
END PROCEDURE

Arrays:

SET marks TO [45, 67, 89, 32, 78]
OUTPUT marks[0]
SET marks[2] TO 90

Key Principles of Good Pseudocode

• Use consistent indentation to show the structure of loops and selections.
• Use meaningful variable names (e.g. totalScore not x).
• Use capital letters for keywords (SET, IF, THEN, ELSE, WHILE, FOR, REPEAT, UNTIL, INPUT, OUTPUT, RETURN, FUNCTION, PROCEDURE, END).
• Keep it simple and readable – anyone should be able to follow the logic.
• Do not include language-specific syntax (e.g. do not use : or {} or Dim).

---

Flowchart Symbols and Examples

A flowchart is a diagrammatic representation of an algorithm. It uses standard symbols connected by arrows to show the flow of control through a program.

Standard Flowchart Symbols

Symbol	Shape	Purpose
Terminator	Rounded rectangle (oval)	Marks the start or end of the flowchart. Labelled “Start” or “End” (or “Stop”).
Process	Rectangle	Represents a step or action (e.g. “Set total to 0”, “Calculate tax”).
Input/Output	Parallelogram	Represents input from the user or output to the screen (e.g. “Input name”, “Display result”).
Decision	Diamond	Represents a decision or condition with two outcomes: Yes/No or True/False. Must have exactly two exit paths.
Flow line	Arrow	Shows the direction of flow from one symbol to the next.
Subroutine	Rectangle with double vertical lines on sides	Represents a call to a pre-defined subroutine (function or procedure).

Rules for Drawing Flowcharts

• Every flowchart must have exactly one Start terminator.
• Every flowchart must have at least one End terminator.
• Flow lines must have arrows showing direction.
• Decision diamonds must have exactly two labelled exit paths (Yes/No or True/False).
• All symbols must be connected – there should be no orphaned symbols.
• Flow should generally go from top to bottom and left to right.

Example: Check if a Number is Positive, Negative, or Zero

flowchart TD
    A([Start]) --> B[/Input number/]
    B --> C{number > 0?}
    C -- Yes --> D[/Output 'Positive'/]
    C -- No --> E{number < 0?}
    E -- Yes --> F[/Output 'Negative'/]
    E -- No --> G[/Output 'Zero'/]
    D --> H([End])
    F --> H
    G --> H

Example: Validate Password Entry (Loop)

flowchart TD
    A([Start]) --> B[/Input password/]
    B --> C{password = 'abc123'?}
    C -- Yes --> D[/Output 'Access Granted'/]
    D --> E([End])
    C -- No --> F[/Output 'Incorrect, try again'/]
    F --> B

Example: Calculate Sum of Numbers 1 to 10

flowchart TD
    A([Start]) --> B[Set total = 0]
    B --> C[Set i = 1]
    C --> D{i <= 10?}
    D -- No --> E[/Output total/]
    E --> F([End])
    D -- Yes --> G[total = total + i]
    G --> H[i = i + 1]
    H --> D