Unit 1: Structured English, Detailed Design, and Modularization

1. Introduction

After creating Data Flow Diagrams (DFDs), data dictionaries, and decision tables/trees, the analyst must specify the internal logic of each primitive process in a way that programmers can implement directly.

Structured English – A limited, structured form of English that describes process logic using sequences, decisions, and iterations. It is precise yet readable.

Detailed Design – The phase where we define the internal workings of each module: algorithms, data structures, interfaces, and error handling.

Modularization – The principle of breaking a system into small, independent, reusable modules with high cohesion and low coupling.

These three together form the bridge from analysis specifications to programming code.

---

2. Structured English

2.1 What is Structured English?

Structured English (also called pseudocode or structured pseudocode) is a formal, restricted subset of English used to describe the logic of a process. It uses only:

• Sequence – simple statements in order.
• Decision constructs – IF-THEN-ELSE, CASE.
• Iteration constructs – DO WHILE, REPEAT UNTIL, FOR.
• Block structure – indentation or keywords (BEGIN/END, IF/ENDIF).

Important: Structured English avoids natural language ambiguities (e.g., “fast”, “sometimes”) and uses only standard constructs that map directly to programming languages.

![Structured English Constructs Placeholder]()

2.2 Structured English vs. Other Specifications

Guideline: Use Structured English for sequential algorithms and loops; use decision tables when the logic has 3+ independent conditions.

2.3 Structured English Constructs

2.3.1 Sequence
Write statements in order, each on a new line. Use assignment (←) to indicate setting a value.

READ Customer_ID
CALCULATE Discount = Subtotal * 0.10
PRINT Discount

2.3.2 Decision (IF-THEN-ELSE)

IF condition THEN
    statements
ELSE
    other statements
ENDIF

Example:

IF Customer_Tier = "Gold" THEN
    Discount = Subtotal * 0.15
ELSE
    Discount = Subtotal * 0.05
ENDIF

Nested IFs are allowed, but use indentation:

IF Membership = "Gold" THEN
    IF Order_Total >= 100 THEN
        Shipping = 0
    ELSE
        Shipping = 5.99
    ENDIF
ELSE
    Shipping = 9.99
ENDIF

2.3.3 Multiple Selection (CASE)
When a single variable has many possible values, use CASE.

CASE Payment_Method
    "Credit Card": Fee = 0
    "PayPal":     Fee = 0.50
    "COD":        Fee = 5.00
    OTHERWISE:    Fee = 0
ENDCASE

2.3.4 Iteration (Loops)
DO WHILE – test at the beginning:

SET Counter = 1
DO WHILE Counter <= 10
    PRINT Counter
    Counter = Counter + 1
ENDDO

REPEAT UNTIL – test at the end (executes at least once):

REPEAT
    READ Input_Value
UNTIL Input_Value > 0

FOR – when the number of iterations is known:

FOR each Product in Order_Line_List
    Total = Total + Product.Quantity * Product.Unit_Price
ENDFOR

2.3.5 Blocks and Nesting
Use indentation to show block structure. Optionally use BEGIN / END.

BEGIN
    READ Customer_Record
    IF Customer_Record.Status = "Active" THEN
        PROCESS Order
    ELSE
        PRINT "Inactive customer"
    ENDIF
END

2.4 Example: Structured English for a Withdrawal Process (ATM)

Process: Withdraw cash from an ATM.

BEGIN Withdrawal
    READ Card_Number, PIN
    CALL Validate_Card(Card_Number, PIN) -> Valid_Flag, Account_Balance
    IF Valid_Flag = False THEN
        PRINT "Invalid card or PIN"
        RETURN
    ENDIF
    READ Requested_Amount
    IF Requested_Amount > Account_Balance THEN
        PRINT "Insufficient funds"
        RETURN
    ENDIF
    IF Requested_Amount > Daily_Limit THEN
        PRINT "Daily limit exceeded"
        RETURN
    ENDIF
    CALL Dispense_Cash(Requested_Amount)
    Account_Balance = Account_Balance - Requested_Amount
    CALL Update_Balance(Account_Balance)
    CALL Print_Receipt(Requested_Amount, Account_Balance)
    PRINT "Take your cash"
END

2.5 Advantages & Limitations

---

3. Detailed Design

3.1 What is Detailed Design?

Detailed Design is the phase in SAD where we take the logical specifications (DFDs, data dictionary, structured English) and produce physical design specifications that programmers can implement. It focuses on:

• Module design – internal algorithms and data structures.
• Interface design – how modules call each other and exchange data.
• Error handling – what happens when things go wrong.
• Data storage design – file structures, database schemas.
• User interface design – screens, reports, dialogues.

![Detailed Design Inputs/Outputs Placeholder]()

3.2 Inputs to Detailed Design

3.3 Outputs of Detailed Design

• Module specifications – for each module: name, purpose, inputs, outputs, algorithm (structured English), local data.
• Structure chart – showing module hierarchy and calls (see modularization).
• Interface specifications – parameter lists, shared data areas.
• File/database design – normalized tables, indexes, access methods.
• Test plans – unit test cases derived from module logic.

3.4 Detailed Design Example

Module Name: Calculate_Order_Total

Purpose: Compute the total amount for an order including discounts, taxes, and shipping.

Inputs:

• Order_Line_List (array of Product_Code, Quantity)
• Customer_ID

Outputs:

• Grand_Total (decimal)
• Itemized_Receipt (list of line totals)

Algorithm (Structured English):

BEGIN Calculate_Order_Total
    Subtotal = 0
    FOR each Line in Order_Line_List
        CALL Get_Unit_Price(Line.Product_Code) -> Unit_Price
        Line_Total = Line.Quantity * Unit_Price
        Subtotal = Subtotal + Line_Total
        ADD Line_Total to Itemized_Receipt
    ENDFOR
    CALL Get_Customer_Tier(Customer_ID) -> Tier
    CALL Calculate_Discount(Subtotal, Tier) -> Discount_Amount
    After_Discount = Subtotal - Discount_Amount
    CALL Calculate_Tax(After_Discount) -> Tax_Amount
    CALL Calculate_Shipping(Subtotal, Customer_Address) -> Shipping_Cost
    Grand_Total = After_Discount + Tax_Amount + Shipping_Cost
    RETURN Grand_Total, Itemized_Receipt
END

Error handling: If Get_Unit_Price fails (product not found), set unit price to 0 and log error.
Local data: Subtotal, After_Discount, Tax_Amount, Shipping_Cost, Line_Total.

---

4. Modularization

4.1 What is Modularization?

Modularization is the process of decomposing a system into modules – independent, replaceable units that each perform a single function. It is the core principle of structured design.

Module: A logically separate part of a system with well‑defined inputs, outputs, and internal logic (e.g., a function, procedure, subroutine, or method).

4.2 Goals of Modularization

4.3 Principles of Good Modularization

4.3.1 High Cohesion
Cohesion measures how strongly the elements inside a module are related. High cohesion is desirable.

![Cohesion Levels Placeholder]()

Goal: Aim for functional cohesion – one module does one thing and does it well.

4.3.2 Low Coupling
Coupling measures the degree of interdependence between modules. Low coupling is desirable.

![Coupling Levels Placeholder]()

Goal: Use data coupling – modules communicate only through well‑defined parameters.

4.4 Structure Charts

A structure chart is a diagram that shows the hierarchy of modules and their calls. It is the design‑phase counterpart of the DFD but focuses on control flow (which module calls which) rather than data flow.

![Structure Chart Order Placeholder]()

4.4.1 Symbols

• Rectangle: Module (named with verb phrase)
• Arrow (line): Call (control passes from top to bottom)
• Small arrow with label: Data flow (parameters)
• Lozenge (diamond): Condition (decision)
• Curved arrow: Loop (iterative call)

4.4.2 Structure Chart vs. DFD

4.5 Stepwise Refinement (Top‑Down Design)

Stepwise refinement is the process of starting with a high‑level module and repeatedly decomposing it into smaller modules until each module is simple enough to code.

Example – Order System:

• Level 0: Process_Order
• Level 1: Decompose into Validate_Customer, Calculate_Total, Process_Payment, Generate_Shipping
• Level 2: Decompose Calculate_Total into Get_Prices, Apply_Discount, Compute_Tax, Add_Shipping
• Level 3: Compute_Tax might be a single module (no further decomposition)

---

5. Integrating Structured English, Detailed Design, and Modularization

These three concepts work together in the design workflow:

1. Modularization – Identify the modules (from DFD processes, using cohesion/coupling principles). Draw a structure chart.
2. Detailed design – For each module, define its interface (inputs, outputs, local data).
3. Structured English – Write the algorithm for each module using the constructs described.
4. Iterate – Refine modules and algorithms until each module can be coded in 1–2 pages of code.

5.1 Example Walkthrough: Payroll System

Context: A DFD process “Calculate Net Pay” receives Gross Pay and Deductions and returns Net Pay.

Step 1 – Modularization:
We decide to break “Calculate Net Pay” into three modules:

• Calculate_Tax (input: Gross Pay; output: Tax)
• Calculate_Other_Deductions (input: Gross Pay; output: Other Deductions)
• Compute_Net_Pay (inputs: Gross Pay, Tax, Other Deductions; output: Net Pay)

Step 4 – Structured English for Calculate_Tax:

BEGIN Calculate_Tax
    IF Gross_Pay <= 1000 THEN
        Tax_Rate = 0.10
    ELSE IF Gross_Pay <= 3000 THEN
        Tax_Rate = 0.15
    ELSE
        Tax_Rate = 0.20
    ENDIF
    Tax_Amount = Gross_Pay * Tax_Rate
    RETURN Tax_Amount
END

---

6. Best Practices for Detailed Design

---

7. Summary and Key Takeaways

• Structured English is for specifying internal logic (Sequence, Decision, Loop).
• Detailed Design transforms logical models into implementation specifications.
• Modularization breaks systems into independent, cohesive modules.
• Structure charts provide a physical view of module hierarchy and control flow.
• Always aim for High Cohesion and Low Coupling.