Section 1 · Introduction to Software Design
On this page 7 headings
Learning goals: Explain what a design achieves; distinguish components, interfaces, data structures and algorithms; apply the criteria for good design.
Design begins after we understand the problem, but before implementation. This lecture asks what the design process produces and how we recognise a useful result.
From Requirements to Software Design
Design is a way of organising the code you will implement and providing a structure to the software system.
Similarly, software design identifies components, their responsibilities, and how they communicate. Design does not itself mean that the final software is already coded. It provides a structure that guides implementation and later maintenance.
Four Outcomes of the Design Process
This lecture describes four outcomes of the design process. Components (often called modules) bring together related functions and data to perform a well-defined job. Interfaces specify how those components exchange requests, results, and information. Data structures organise what a component stores, such as a list of inventory items. Algorithms describe the steps that operate on that data.
For example, an inventory module may expose a method to view stock, store product quantities in a suitable structure, and use an algorithm to decide whether a product is in stock. A complete design needs more than a list of screens: it must explain responsibilities, communication, data, and processing.
Recall: Can you name all four outcomes without looking?
High-Level Architecture and Internal Detail
Components and interfaces are the key elements of high-level software design, known as software architecture. Once the architecture is decided, we move to lower-level design details. The most popular notation for representing a high-level design is UML (Unified Modelling Language), which can describe different views — a user’s view, a functionality view, a messages view and so on.
Detailed design zooms inside a module. Within Inventory, developers must choose how to represent stock records and what sequence of actions handles add, view, or delete operations. High-level and detailed design are complementary: internal algorithms should respect the contracts agreed at the architectural level.
Seller Stories Become Software Components
From requirements and user stories we identify common functionalities, group them into tasks, and these form components: Catalogue Management, Inventory Management, Payment Tracking, Order Tracking, Sales Tracking, Customer Feedback.
Notice the distinction: 'View Inventory' is a user-visible capability, while Inventory Management is the component responsible for supplying it. A feature may use several components, and one component may support several related features. The designer's job is to allocate responsibility sensibly instead of creating arbitrary modules for every screen or button.
Seller Portal: The Six Main Modules
The Seller Portal example organises its functionality into six major components: Catalogue Management, Inventory Management, Payment Tracking, Order Tracking, Sales Tracking, and Customer Feedback. Their responsibilities differ, but together they support the seller's workflow.
The arrows in this picture mean the modules interact through intended interfaces. They do not mean every module must access every other module's internal data. Real implementations may refine the grouping, but the purpose of the illustration is to show how a large application becomes understandable by separating concerns.
Four Qualities of Good Software Design
Correctness — correctly implement all functionalities; ensured by capturing requirements that are not ambiguous, not conflicting and complete. Efficiency — resources (time, space, cost) managed well; choose the development framework according to the application (client-server vs mission-critical); an embedded system must work under limited memory.
Maintainability — easy to change; requirements change during design or after release (new requests, upgrades), and we don’t want to redesign the software from scratch. Understandability — everyone in the development team can follow the design; otherwise they can’t implement it, leading to bugs and higher development and maintenance costs.
Quick revision and self-check
Question: What is the difference between design and implementation?
Answer: Design is the plan/structure; implementation is the code built from it.
Question: Name the four design outputs.
Answer: Components, interfaces, data structures, algorithms.
Question: List four qualities of good software design.
Answer: Correctness, efficiency, maintainability, understandability.