Session 5

This session turns the Level-1 DFD of Session 4 into a design: a structure chart from one main controller down to the eight modules of the Railway Reservation System (RRS), a specification for every module, and exact signatures for the functions that other modules call. Modular design is the step where the system stops being a description and starts being a plan that a programmer can implement one piece at a time. A good split has modules that each do one job (high cohesion) and share as little as possible (low coupling). The same eight modules are estimated in Session 2, drawn as processes in Session 4, and coded in Session 13, so the names here must match those pages.

Objectives

• Draw a structure chart for the RRS from a main controller down to sub-functions.
• Write a module specification (purpose, inputs, outputs, callers, callees, data stores) for all eight modules.
• Judge the design using cohesion and coupling, with examples from the RRS.
• Define the interface of the five most important functions as signatures with parameter tables.
• Record the design decisions taken and the alternatives rejected.

Problem Statement

Session 5: Develop a modular design for RRS.

Concept

What a module is

A module is a named unit of the program with one responsibility, a defined interface (what goes in, what comes out) and hidden internals. In Python a module is a file or a group of functions; in C it is a .c file with a header. The RRS has eight modules, fixed in Session 1, and each one maps to exactly one Level-1 DFD process from Session 4.

Structure chart

A structure chart shows which module calls which. The top box is the controller that starts the program (the menu in Session 13). Boxes below it are the modules; boxes below those are the sub-functions inside each module. An arrow means “calls”. Data passed along a call is written on the arrow in the module specification table, not on the chart, so the chart stays readable.

Cohesion

Cohesion is how strongly the parts of one module belong together. From worst to best: coincidental, logical, temporal, procedural, communicational, sequential, functional. Aim for functional cohesion: every function in the module contributes to one task. A module named “Utilities” that holds date formatting, PNR generation and report printing is coincidental cohesion and a sign of a bad split.

Coupling

Coupling is how much one module depends on the inside of another. From best to worst: data, stamp, control, common (shared global data), content (one module edits another’s code or data directly). Aim for data coupling: modules pass only the values they need as parameters and get results back as return values. Common coupling through a global variable is the mistake to watch for in a small Python program, because it is the easiest thing to write.

Design decisions

A design is a set of choices. Write each one down with the alternatives you rejected and the reason. In the viva you are asked why, not what.

Structure Chart

                              +----------------------+
                              |   RRS Main Controller |
                              |   (menu, role check)  |
                              +-----------+----------+
                                          |
   +----------+----------+----------+-----+-----+----------+----------+----------+
   |          |          |          |           |          |          |          |
   v          v          v          v           v          v          v          v
+------+  +--------+  +--------+  +-------+  +--------+  +-------+  +-------+  +-------+
| 1    |  | 2      |  | 3      |  | 4     |  | 5      |  | 6     |  | 7     |  | 8     |
| User |  | Train  |  | Search |  | Book- |  | Cancel |  | Pay-  |  | Noti- |  | Re-   |
| Mgmt |  | and    |  | and    |  | ing   |  | and    |  | ment  |  | fica- |  | ports |
|      |  | Sched. |  | Avail. |  |       |  | Refund |  |       |  | tion  |  |       |
+--+---+  +---+----+  +---+----+  +---+---+  +---+----+  +---+---+  +---+---+  +---+---+
   |          |           |           |          |           |          |          |
   | register | add_train | search_   | validate | lookup_   | initiate | send_    | occupancy
   | login    | add_route | trains    | _request | pnr       | _payment | booking_ | _report
   | logout   | add_      | check_    | allocate | compute_  | confirm_ | confirm  | revenue_
   | get_role | schedule  | avail-    | _seats   | refund    | payment  | send_    | report
   |          | set_fare  | ability   | generate | promote_  | fail_    | cancel-  | cancel-
   |          | cancel_   | compute_  | _pnr     | waitlist  | payment  | lation   | lation_
   |          | schedule  | fare      | save_    | record_   | issue_   | send_    | report
   |          |           |           | booking  | refund    | refund   | schedule |
   |          |           |           |          |           |          | _change  |
   +----------+-----------+-----------+----------+-----------+----------+----------+

Cross-module calls (arrow = "calls"):
   4 Booking      ---> 3 check_availability, 3 compute_fare
   4 Booking      ---> 6 initiate_payment, 6 confirm_payment
   4 Booking      ---> 7 send_booking_confirm
   5 Cancellation ---> 6 issue_refund
   5 Cancellation ---> 7 send_cancellation
   2 Schedule     ---> 7 send_schedule_change
   Main           ---> 1 login (before any other module)

Module Specifications

Cohesion and Coupling in this Design

Cohesion

The two modules a marker looks at hardest, Booking and Cancellation, are functionally cohesive. Notification is the weakest at logical cohesion, and it is kept small so that this does not matter.

Coupling

Data coupling, the best kind, occurs at every cross-module call:

• Booking calls check_availability(schedule_id, travel_class) and receives an integer. Booking does not read the Seat table itself.
• Booking calls initiate_payment(pnr, amount, mode) and receives a payment_id and status. Booking never sees the gateway response.
• Cancellation calls send_cancellation(pnr) and receives a delivery flag. Notification looks up the mobile and email itself.

Stamp coupling occurs once: Booking passes the whole passenger list (a list of dictionaries with name, age, gender, berth_preference) to allocate_seats. This is accepted because the function needs every field to match berth preference to berth type.

Control coupling was removed: an early draft had send_notification(pnr, kind) where kind was a flag that chose the message. It is replaced by three functions (send_booking_confirm, send_cancellation, send_schedule_change) so the caller does not steer the callee’s logic.

Common coupling was avoided in one specific place. The obvious Python shortcut is a global current_booking dictionary that Booking fills, Payment reads, and Notification reads again. Instead, book_ticket returns the pnr, and Payment and Notification each receive the pnr as a parameter and read the Booking store themselves. The only shared state is the persistent data stores, accessed through named load and save functions, never through module-level variables.

Interface Definitions

The five functions below are the ones other modules or the main controller call. All parameters are passed by value; all results are return values. Errors are raised as exceptions named in the last row of each table.

search_trains

search_trains(from_station, to_station, run_date) returns list of schedule

check_availability

check_availability(schedule_id, travel_class) returns available_count

book_ticket

book_ticket(schedule_id, travel_class, passengers, user_id) returns pnr

initiate_payment

initiate_payment(pnr, amount, mode) returns (payment_id, status, txn_ref)

cancel_ticket

cancel_ticket(pnr, user_id, reason) returns refund_amount

Design Decisions

Viva Questions

• Q: What is the difference between a structure chart and a DFD? A: A DFD shows data movement between processes; a structure chart shows which module calls which and is a design artefact, not an analysis one.
• Q: Which RRS module has the highest cohesion and why? A: Booking: every sub-function is a step in creating one booking, which is functional cohesion.
• Q: Give one example of data coupling in the RRS. A: Booking calls check_availability(schedule_id, travel_class) and receives only an integer.
• Q: Where could common coupling have crept in, and how was it avoided? A: A global current_booking dictionary shared by Booking, Payment and Notification; avoided by returning the pnr and passing it as a parameter.
• Q: Why is the refund rule not in the Payment module? A: The rule depends on hours before departure, which Cancellation computes; Payment only records money movement.
• Q: Why does book_ticket reject a schedule after departure? A: Business rule: a schedule cannot be booked after departure; the check is at the entry to Booking so no later step sees a departed schedule.
• Q: What kind of coupling is passing the whole passenger list to allocate_seats? A: Stamp coupling; accepted because every field is used.
• Q: What does the main controller do besides show a menu? A: It calls login first and dispatches only the menu options the returned role is allowed to use.
• Q: How many modules does the design have, and where else do the same eight appear? A: Eight; in the Session 2 function point count, the Session 4 Level-1 DFD, and the Session 13 program.

Common Mistakes

• Drawing the structure chart with data flows on the arrows, which turns it back into a DFD. Data goes in the module specification table.
• Inventing a ninth “Database” or “Utility” module. Data stores are not modules; they appear in the “Data stores touched” column.
• Using module names that differ from Sessions 1, 2 and 4. The examiner cross-checks; use the same eight names.
• Writing signatures without types and constraints. book_ticket(a, b, c, d) earns nothing; the parameter table is the deliverable.
• Claiming “low coupling” without an example. Name the call, the parameters, and the return value.
• Leaving the design decision table with a chosen column but no alternatives. A decision with no alternative is not a decision.

Session Summary

• Structure chart with the main controller, eight modules, and sub-functions, plus the box and arrow legend table.
• Module specification table with all eight rows filled.
• Cohesion table and coupling notes with at least three named examples, including the avoided global variable.
• Five interface definitions with parameter tables.
• Design decision table with at least six rows.