Designing Software

# Designing Software ## Objectifs et prérequis This chapter aims to equip Lower Sixth ICT students with the knowledge and skills to understand, apply, and represent software design processes. Students will learn to differentiate between software design approaches, apply structured techniques to solve problems, and represent designs using standardized notations. By the end of this chapter, learners should be able to analyze a problem, select an appropriate design approach, apply design techniques such as modularization and abstraction, and produce clear representations using tools like flowcharts, pseudocode, and structure diagrams. **Prerequisites:** Students must have completed the Lower Fifth ICT syllabus, particularly topics on problem-solving, algorithms, basic programming constructs (sequence, selection, iteration), and familiarity with pseudocode and flowchart symbols. Basic computer literacy and logical reasoning skills are assumed. --- ## I. Approaches to Software Design ### Context and Definitions Software design is the process of defining the architecture, components, interfaces, and other characteristics of a system or component. It bridges the gap between problem analysis and implementation. In the Cameroonian Anglophone education system, emphasis is placed on structured, logical approaches that are accessible to learners without prior professional software engineering experience. There are three primary approaches to software design: **top-down**, **bottom-up**, and **modular** (often considered a hybrid or extension of top-down). Each approach reflects a different philosophy in breaking down and constructing software systems. > **Top-down design** is an approach where the system is broken down from a high-level overview into progressively more detailed sub-systems and modules, starting with the main goal and decomposing it into smaller, manageable tasks. > **Bottom-up design** is an approach where design begins with the development of fundamental or low-level components, which are then integrated to form higher-level systems, often based on existing or reusable modules. > **Modular design** is an approach that divides a system into independent, interchangeable modules, each responsible for a specific function, promoting reusability, maintainability, and clarity. ### Facts, Causes, and Consequences The top-down approach was popularized in the 1970s by structured programming advocates such as Edsger Dijkstra and Niklaus Wirth, in response to the “software crisis” of the 1960s, where large software projects frequently failed due to poor planning and complexity. Its consequence is improved clarity and control during design, but it risks overlooking low-level constraints if not grounded in feasibility. Bottom-up design emerged as a practical response to the need for reuse, particularly in environments with existing libraries or hardware constraints (e.g., embedded systems in African telecommunications or agricultural monitoring devices). Its strength lies in leveraging proven components, but it can lead to inflexible or overly complex systems if integration is not carefully planned. Modular design, influenced by both paradigms, became dominant with the rise of structured and later object-oriented programming. It addresses the limitations of pure top-down or bottom-up by enabling teams to work on independent modules, facilitating parallel development and easier testing. In Cameroonian technical colleges, modular design is often taught using examples like a school management system split into modules for student records, fee collection, and timetable scheduling. ### Examples (Cameroonian and African Contexts) - **Top-down**: Designing a national voter registration system for Elections Cameroon (ELECAM). Start with the main goal: “Register eligible citizens.” Decompose into: data collection, validation, storage, issuance of voter cards, and audit. Each sub-task is further broken down (e.g., data collection → form design, field deployment, training officers). - **Bottom-up**: Developing a mobile money agent system in rural Cameroon using existing USSD and SMS gateways (like those provided by MTN or Orange). Engineers first build secure transaction modules, then integrate them into a user interface for agents, finally connecting to central banking systems. - **Modular**: A hospital management system in Yaoundé designed with separate modules for patient registration, pharmacy inventory, appointment scheduling, and billing. Each module can be updated independently (e.g., updating the pharmacy module to integrate with NAFDAC drug databases without altering the billing module). ### Vocabulary to Retain - Decomposition - Abstraction - Encapsulation - Interface - Coupling - Cohesion - Reusability - Maintainability - Scalability - Subsystem ### Example Exam Question and Plan **Question:** *Explain the top-down and bottom-up approaches to software design. Using a concrete example of a Cameroonian agricultural extension service mobile app, illustrate how each approach would be applied. Discuss one advantage and one disadvantage of each approach.* **Plan:** 1. Define top-down and bottom-up design (with > encadrés for definitions). 2. Describe the agricultural app’s purpose: provide weather forecasts, market prices, and pest control advice to farmers via SMS and USSD. 3. Top-down application: Start with main goal → decompose into user interface, data fetching, advice engine, delivery mechanism → further break down each (e.g., data fetching → weather API, market API). 4. Bottom-up application: Begin with existing components: USSD gateway (from MTN), SMS sender, weather API (e.g., from Ghana Meteorological Agency), market price database (from MINAGRI), then integrate into a cohesive app. 5. Advantages: Top-down → clarity, control; Bottom-up → reuse, faster prototyping. 6. Disadvantages: Top-down → may ignore technical constraints; Bottom-up → risk of poor integration, bloat. 7. Conclude with recommendation: modular hybrid approach often best for real-world African contexts. --- ## II. Applying Software Design Techniques ### Context and Definitions Once an approach is selected, specific techniques are applied to refine the design. These techniques ensure the software is efficient, understandable, and adaptable. They are practical tools used during the design phase to manage complexity and improve quality. > **Modularization** is the technique of dividing a system into separate, independent modules, each performing a distinct function, with minimal interaction between them. > **Abstraction** is the technique of hiding complex implementation details behind a simple interface, allowing users or other modules to interact with the system based on what it does, not how it does it. > **Structured programming** is a design technique that uses only three control structures—sequence, selection, and iteration—to build algorithms, avoiding unconditional jumps (like GOTO) to improve readability and maintainability. ### Facts, Causes, and Consequences Modularization arose from the need to manage large software systems. Its consequence is improved team collaboration, as different groups can work on different modules. However, excessive modularization can increase overhead due to inter-module communication. Abstraction is fundamental to modern computing. It allows programmers to use complex systems (like databases or networks) without understanding their inner workings. In African contexts, abstraction enables local developers to use global APIs (e.g., Google Maps, SMS gateways) to build solutions like ride-sharing apps in Nairobi or farm advisory systems in Kenya without reinventing the wheel. Structured programming was formalized in the 1960s–70s by Dijkstra, Hoare, and others. Its adoption reduced software errors significantly. In Cameroonian technical education, it remains foundational because it aligns with the pseudocode and flowchart requirements in national examinations (e.g., GCE Advanced Level ICT). ### Examples (Cameroonian and African Contexts) - **Modularization**: A Cameroon-based e-learning platform (e.g., inspired by Ubongo or Eneza Education) is divided into modules: user authentication, content delivery, quiz engine, progress tracking, and admin dashboard. The quiz engine can be reused in a health training app for community health workers. - **Abstraction**: A developer in Douala uses a payment abstraction layer (like Paystack or Flutterwave) to integrate mobile money into an e-commerce site. The developer does not need to know the specifics of MTN Mobile Money or Orange Money protocols—only how to call the abstraction layer’s “processPayment” function. - **Structured Programming**: Writing pseudocode for a program that calculates the average score of 30 students in a Lower Sixth ICT class. The algorithm uses sequence (input scores), iteration (loop 30 times), and selection (if score < 50, flag for remediation), with no GOTO statements. ### Vocabulary to Retain - Coupling (low is desirable) - Cohesion (high is desirable) - Information hiding - Top-down refinement - Stepwise refinement - Control structure - Pseudocode - Flowchart - Module specification - Refinement ### Example Exam Question and Plan **Question:** *Define modularization and abstraction. Using the example of a water point monitoring system in the Northern Region of Cameroon, explain how these two techniques are applied. Draw a simple structure diagram to show the modularization of the system.* **Plan:** 1. Define modularization and abstraction (with > encadrés). 2. Describe the system: sensors at boreholes transmit water level and quality data via SMS to a central server, which alerts technicians if levels are low or contamination is detected. 3. Modularization: Break into modules: Sensor Data Collection, SMS Transmission, Data Storage, Alert Generation, Technician Dashboard, Maintenance Log. Show low coupling (e.g., SMS module only sends data, doesn’t process it) and high cohesion (each module does one thing well). 4. Abstraction: The SMS Transmission module abstracts the details of the GSM network—technicians interact with it via a simple function like `sendAlert(message)`, without knowing AT commands or SIM card protocols. 5. Draw a structure diagram: Central controller → calls Sensor Module, SMS Module, Storage Module; SMS Module → calls GSM Abstraction Layer (hidden detail). 6. Conclude: These techniques make the system maintainable—e.g., switching from SMS to LoRaWAN only requires changing the SMS module, not the entire system. --- ## III. Representing Software Design ### Context and Definitions Representation is the act of making the software design visible and communicable through standardized notations. This allows stakeholders—developers, teachers, examiners, clients—to understand, review, and validate the design before implementation. In the Cameroonian ICT curriculum, representation focuses on accessible, low-tech tools suitable for examination conditions. > **A flowchart** is a diagrammatic representation of an algorithm or process, using standardized symbols (oval, rectangle, diamond, parallelogram) to show the sequence of steps, decisions, and inputs/outputs. > **Pseudocode** is an informal, high-level description of an algorithm that uses the structural conventions of programming languages but is intended for human reading, not machine execution. It omits language-specific syntax. > **A structure diagram** (or structure chart) is a top-down modular design tool that shows the hierarchy of modules, their relationships (calling relationships), and the data passed between them, using rectangles for modules and arrows with labels for data flow. ### Facts, Causes, and Consequences Flowcharts were popularized by Herman Goldstine and John von Neumann in the 1940s for documenting computer programs. Their consequence is visual clarity, especially for beginners. However, they become unwieldy for large systems. Pseudocode emerged as a response to the limitations of flowcharts and the need for language-independent algorithm description. It is widely used in examinations because it is fast to write, easy to modify, and focuses on logic over syntax. In Cameroonian GCE A-Level ICT papers, pseudocode is a required skill. Structure diagrams were developed in the 1970s as part of structured design methodologies (e.g., Yourdon/Constantine). They address the limitation of flowcharts in showing modular structure. Their consequence is better visualization of system architecture, particularly useful in modular and top-down designs. ### Examples (Cameroonian and African Contexts) - **Flowchart**: Designing a flowchart for a program that determines whether a student in a Cameroonian secondary school is eligible for a government scholarship based on: average score ≥ 70, attendance ≥ 85%, and no disciplinary records. Symbols: oval (start), parallelogram (input scores/attendance), diamond (decision: score ≥ 70?), rectangle (process: check attendance), etc. - **Pseudocode**: Writing pseudocode for a system that calculates the total cost of building a classroom in a rural Cameroonian village, given the number of bags of cement, price per bag, and labor cost. ``` START INPUT numBags, pricePerBag, laborCost totalCementCost ← numBags × pricePerBag totalCost ← totalCementCost + laborCost OUTPUT totalCost END ``` - **Structure Diagram**: For a school management system in Bamenda: - Main Module → calls: Student Module, Fee Module, Timetable Module - Student Module → calls: Register Student, Update Records, Generate Report - Fee Module → calls: Record Payment, Calculate Balance, Send Reminder - Data (e.g., student ID, amount paid) flows between modules via labeled arrows. ### Vocabulary to Retain - Symbol (flowchart) - Decision diamond - Process rectangle - Input/output parallelogram - Terminator oval - Arrow (flow line) - Module (structure diagram) - Data coupling - Control coupling - Hierarchy - Calling relationship - Data flow ### Example Exam Question and Plan **Question:** *Represent the algorithm for a program that calculates the Body Mass Index (BMI) of a user and classifies their health status using: (a) a flowchart, and (b) pseudocode. Use the formula BMI = weight (kg) / [height (m)]² and the classification: underweight (<18.5), normal (18.5–24.9), overweight (25–29.9), obese (≥30).* **Plan:** (a) Flowchart: - Start (oval) - Input weight, height (parallelogram) - Calculate BMI: weight / (height × height) (process rectangle) - Decision diamond: Is BMI < 18.5? → if yes, output “Underweight” → end - Else, decision: Is BMI < 25? → if yes, output “Normal” → end - Else, decision: Is BMI < 30? → if yes, output “Overweight” → end - Else, output “Obese” → end - All paths lead to End (oval) (b) Pseudocode: ``` START INPUT weight, height bmi ← weight / (height × height) IF bmi < 18.5 THEN OUTPUT "Underweight" ELSE IF bmi < 25 THEN OUTPUT "Normal" ELSE IF bmi < 30 THEN OUTPUT "Overweight" ELSE OUTPUT "Obese" END IF END ``` --- ## Synthèse du chapitre - Software design involves translating problem solutions into a structured plan for implementation. - The three main approaches are top-down (decomposition from general to specific), bottom-up (integration from specific to general), and modular (division into independent, reusable units). - Key design techniques include modularization, abstraction, and structured programming—each improving clarity, maintainability, and reusability. - Representation tools—flowcharts, pseudocode, and structure diagrams—allow designs to be communicated, analyzed, and validated before coding. - In Cameroonian and African contexts, these concepts are applied to real-world problems such as agricultural advisory systems, mobile money platforms, health monitoring, and education tools. - Effective design balances idealism with practical constraints, leveraging existing technologies where appropriate (e.g., USSD, SMS, open APIs). - Mastery of these concepts is essential for success in ICT examinations and future technological innovation in Cameroon and beyond. ---