text

Course: Programming Logic and Design
Session date: Sep 3, 2025
Participants: Amarendar Rao Thangeda, Keorapetse Nthomola, Kesaobaka, Molato Michael, Teto Tony Kgopolo
Structure of the session (highlights): discussion of assignments, modularization, abstraction, functions, main program, housekeeping tasks, and introduction to structured programming.
First assignment: to be given this week; deadline window: $5\text{ days} \le d \le 7\text{ days}$ ; compulsory for all; marks contribute to final grade.
Assessment breakdown mentioned: final examination = $60\%$ ; internal components (discussion forums, assignments, etc.) = $40\%$ .
Scoring notes mentioned by instructor:
- To perform well on the final, a high internal score is recommended.
- The instructor stated a target of $50/60\approx 90\%$ for the final, but mathematically $50/60=\frac{5}{6} \approx 83.3\%.$ The transcript records the claim that 50/60 equates to 90%; this is noted here as an apparent error in the spoken content.
Three assignments are compulsory for everyone; discussion forum completion is also required; there is potential for 4 assignments if the instructor adds one more.
Final notes: the instructor emphasized not missing assignments to avoid penalties in the overall grade and reminded about the upcoming third lesson.

Modularization (also called functional decomposition):
- Definition: dividing a large program into smaller, manageable modules or functions.
- Goal: reduce code duplication and improve readability; a main program calls modules rather than containing all logic.
- Example rationale: writing a factorial calculation 100 times would create many lines; instead, define a module (function) once and call it as needed.
- Abstraction goal: show the specification of a functionality without exposing its implementation details.
Abstraction:
- You know what a function does (e.g., compute an average) but not how it is implemented internally.
- Built-in functions in languages (e.g., average) illustrate abstraction: you use the function without knowing its internals.
Benefits of modularization/abstraction:
- Abstraction enables multiple programmers to work on different modules simultaneously.
- Code reuse: once a module exists, it can be reused in other projects or programs.
- Clear separation of concerns (what vs. how).
Common terminology used:
- Modularization ≈ Functional decomposition.
- Abstraction ≈ Specification without implementation.
Real-world analogy: using a banking system with separate modules for accounts, withdrawals, deposits, home loans, etc., each developed by different teams and reused across projects.

A module (function) consists of:
- Header: function name, parameter list, and types (the interface).
- Example naming and structure: a function named length with parameters such as two numbers (or none, if empty brackets).
- The header defines the identifier and the types of its parameters.
- Body: the sequence of statements implementing the function’s behavior.
- Return statement: marks the end of the module and provides the value back to the caller.
Parameter handling:
- Functions may have parameters or empty parameter lists (empty brackets).
- Parameters may have types (e.g., integer, float, character).
Calling a module from the main program:
- The main program is kept short: it calls the module by name with required arguments.
- This avoids duplicating code across the main flow.
Terminology in practice:
- In many languages, modules are called Functions.
- Modules can be stored in libraries and linked into the main program as needed.
Example session discussion: one module (e.g., a length function) is written once; the main program calls that module wherever needed.

The main program contains the core, high-level logic and calls modules for detailed tasks.
Modules provide refined details and can be supplied by vendors or other teams.
The main program calls modules by their names, passing required parameters, and uses the return values from those modules.
Benefits:
- Short, readable main program.
- High reusability of modules across programs and projects.
- Language-agnostic principle: the approach exists in C++, Java, etc., and modules can be reused within or across languages with adaptation.
Example scenario: a payroll or payroll-like system where a Payroll module computes salary, tax, HRA, etc., and the main program orchestrates the overall workflow by calling the Payroll module for each employee.
Abstraction vs implementation reiterated: the main program relies on the module interface (name, parameters, return type) without needing to see internal details.

Housekeeping tasks (initial setup) in the main program:
- Declare variables and constants (types and names).
- Display instructions to users and headings for reports.
- Open required files for input/output.
- Input the first data values.
Example: a hotel room-use analogy; housekeeping tasks ensure the system is ready (e.g., room status checks) before use.
Main program flow: initiate housekeeping tasks, declare variables/constants, prompt for input, call modules to perform the core work, and display results.
End-of-program tasks (cleanup):
- Display final totals or reports.
- Close files and release resources.
- Perform any final notification messages.
Real-world payroll example: a single payroll module can be called for each employee; the main program handles repetitive invocation and passes different input data each time.

Maintainability: easy to modify and extend; well-documented with code comments; modular structure.
Reusability: components written once can be reused in multiple programs.
Reliability: dependable behavior across uses and updates.
Portability: ability to run on different platforms/languages with minimal changes.
Efficiency: optimized performance in terms of time and resource usage.
It is common to also emphasize readability and clear organization as part of good design.
Documentation and comments:
- Comments are non-executable lines intended to explain the code.
- They help future developers understand what the code does and why.
- The practice of commenting supports maintainability and knowledge transfer.

Discussion from the session included an exercise on variable names and validity.
Good variable names mentioned: D, Amt (short for amount) – acceptable in many contexts if clear.
Not-good examples discussed:
- Names starting with a number (e.g., 3abc) are invalid in most languages.
- Using a keyword as a variable name (e.g., Print in Python) is problematic because it is a reserved word.
- Names containing spaces are not allowed in many languages.
Additional: ensure variable names are descriptive yet concise.
Conceptual exercise xamples (valid vs invalid):
- Valid: D, Amt, TotalCost
- Invalid: 2Total, Print,