Read this note first: any slide or box labelled “Extra” is the instructor’s own explanation or example, added on top of the textbook material. It is meant to make the definitions concrete, and it is fair game in quizzes.

The chapter covers weeks 1–2 and gives the vocabulary used for the rest of SE322: what design is, why it is hard, how the design process is organised, and the principles used to judge a design.

The house analogy: a building can look finished and still crack later if the foundation is weak. In software the “cracks” are bugs, crashes and code that is painful to change.

The foundation of software is its architecture (the big structure) and the design principles used inside it. The whole course is about building that foundation on purpose instead of by accident.

Software engineering was named in 1968 because large projects of the 1960s kept running late, over budget or failing outright. The answer was to build software with the planned, measured methods of traditional engineering.

The lecture moves from the general to the specific: what software engineering is, then design viewed as problem solving, then what design is and why we study it.

Next come the challenges that make design hard and the process (the activities designers carry out).

It ends with the fundamentals: principles, strategies and considerations. These are the tools you will apply in every later chapter, so they get the most slides.

Software is the set of instructions that lets a user make the hardware do useful work: operating systems, word processors and browsers are all software.

Engineering is a systematic process: designers generate and evaluate designs whose functions meet the clients’ objectives and the users’ needs while respecting constraints (cost, time, laws, hardware). The bridge example makes the point: you plan for weight and weather before you build, and software needs the same planning.

Keep user and client apart. The user is whoever actually works with the software; the client is whoever pays for it. A hospital buys a system (client) that nurses use every day (users), and the two may want different things.

The IEEE definition is the one to memorise word for word: software engineering is the application of a systematic, disciplined, and quantifiable approach to the development, operation, and maintenance of software, in short, applying engineering principles to software. IEEE is the professional body that publishes such standards.

Systematic means the work is organised as a coherent body of ideas and is methodical: there is a plan and a procedure, not improvisation.

Disciplined means a set of rules governs the work, and the team actually follows them (coding standards, review steps, approval rules).

Quantifiable means you can measure the deliverables: how many requirements are done, how many defects were found, how long a response takes. If you can’t measure it, you can’t tell whether it is improving.

The Extra example: agile methods run in short iterations with regular checks, which is one practical way to be systematic, disciplined and measurable at the same time.

Requirements: find out what is needed, then analyse, specify and validate it. Everything later depends on this being right.

Design turns the requirements specification into a software design, which has two levels: the architecture (major parts and how they connect) and the detailed design (the inside of each part). This course lives in this phase.

Implementation writes the code, using the requirements, the architecture and the detailed design together.

Testing checks that the software behaves correctly and meets the specified requirements.

Maintenance changes the software after delivery: fixing faults, improving performance, or adapting it to a new environment. It is usually the longest and most expensive phase, which is why designs are judged by how easy they are to change.

Design gives a team a shared plan: who builds which part and how the parts fit. That is how it lets teams work in a disciplined way and keeps the product aligned with its specification.

Designing is constant problem solving: engineers identify problems, evaluate options and propose solutions throughout the phase, not just once at the start.

Hence the slide’s conclusion: a good designer must first be a good problem solver, and that skill comes from practice over time. The next slides look at how problem solving works and where it goes wrong.

An expanded life cycle with an example for each phase. Requirements: identify and document needs, check feasibility and completeness (example: interviewing users). Testing (top right): unit, integration and system tests, often automated.

Design creates the blueprint: the architecture plus the detailed design of how components interact (example: UML diagrams).

Implementation translates the design into code modules and integrates them into one system.

Deployment is a phase this slide adds that slide 6 does not list: releasing the software into the target environment, e.g. putting a web app on a cloud server.

Maintenance continues after release: fix bugs, add features, adapt to new requirements, and watch performance and user feedback (example: security patches).

Problem solving in design passes through three states. Knowing which state you are in tells you what activity is appropriate.

Initial state: the problem is formulated and interpreted. Often the hardest part is understanding the problem itself (what exactly does the client need?).

Operational state: once the problem is understood, you think about it and possible solutions appear. This is where creativity and alternatives matter, and where functional fixedness (slide 11) does the most damage.

Goal state: a solution has been identified, evaluated and validated. Problem solving ends here.

The classic nine-dot puzzle: connect all nine dots with four straight lines without lifting the pencil or retracing a line.

Read the rules again: nothing says a line must start or end on a dot, or stay inside the square. The real constraints are only the four listed. The puzzle is hard because most people add a constraint that isn’t there, which is the point of the next slide.

Most students assumed each line must begin and end on a dot. The requirements never said so; it was an assumption they brought with them.

Functional fixedness: you only see an object (or a component, or a technique) in the role you are used to, so solutions that use it differently never occur to you. It is a limit of the designer’s thinking, not a property of the software.

The remedy is deliberate: attempt the problem several times, from different viewpoints and unusual angles (“think outside the box”). The possible solution on the right only works because its lines leave the square.

It matters most in the operational state, the state where alternative solutions are generated (slide 9).

A holistic approach looks at the whole system and how its parts interact. Here the three states are fused into one framework of six tasks that fits engineering problems at every stage.

Initial state tasks: interpret the problem and evaluate the constraints.

Operational state tasks: collaborative brainstorming, synthesizing (summarising) the possibilities, and evaluating the solution.

Goal state task: implement the solution.

Interpreting the problem (initial state): understand what is being asked and classify it, for example as a known kind of problem with known solutions.

Evaluating constraints (initial state): find the external limits (budget, deadlines, platforms, regulations) that set the bounds of the “solution landscape”. Note the link to slide 10: only real constraints belong here, not assumed ones.

Collaborative brainstorming (operational state): the team proposes as many different solutions as it can before judging them.

Synthesizing the possibilities (operational state): narrow the ideas down and choose one acceptable solution.

Evaluating the solution (operational state): test the chosen idea. A flaw found here sends you back to brainstorming, so the framework is a loop, not a straight line.

Implementing the solution happens in the goal state, once a suitable solution has been found.

The formal definition has two halves. (1) Design is a process: identifying and evaluating the architectural and detailed models needed to build software that meets its functional and non-functional requirements.

(2) Design is also the product of that process: the design diagrams and documents it produces. When someone says “show me the design”, they mean the product; when they say “we are in design”, they mean the process.

Because the word covers both meanings, industry uses “design” for the process and the product interchangeably. Exam questions often ask which perspective a statement belongs to.

Process perspective: the activities and tasks needed to model the software’s structure and behaviour before construction. This is mostly a project-management concern: the management team plans, organises and assigns the design tasks and lines up schedule and resources.

Product perspective: the artifacts that design produces, such as class diagrams and sequence diagrams. This is mostly a technical concern: the technical team creates the actual models that define structure and behaviour.

Section divider. The next two slides answer the question from both perspectives introduced on slide 15: project management (process) and technical (product).

First reason set: the project-management (process) perspective.

Good design minimises the effect of requirements volatility. In a modular design a new feature, such as multi-language support, is added to one module without disturbing the others.

It makes human resource allocation efficient: once components are defined and documented, the manager can give each one to a developer with the right skills.

It protects the project from depending on “one guy” who owns the whole system in his head. If the design is written down, the project survives that person leaving.

Overall, design improves the four management functions: planning, organisation, staffing and tracking.

Second reason set: the technical (product-development) perspective. The online-store example runs through all six points.

Requirements are mapped to conceptual models: “product listing, cart, checkout” become user-interface diagrams and flowcharts the team can reason about.

Models show the system’s structure and behaviour, e.g. a use case diagram for user interactions and a sequence diagram for the order of steps in a purchase.

The main components and interfaces are identified: catalogue, cart, payment gateway, authentication.

Design gives a way to evaluate quality attributes (usability, efficiency…) before code exists, such as checking how many steps checkout takes.

Designed solutions can be reused: the payment-gateway module can serve other e-commerce projects.

Design is the foundation for construction, testing and maintenance: the database schema and API design guide coders, testers and maintainers alike.

Requirements volatility: the requirements change while you build. A banking app that started simple must suddenly add advanced login security late in development.

Inconsistent development processes: teams don’t follow the same design process. One team uses Agile, another Waterfall, and integration gets delayed.

Fast, ever-changing technology: platforms and libraries change constantly; new iOS and Android versions force quick updates just to keep the app working.

Managing design influences: stakeholders pull in different directions; executives want profit features while the security team wants stronger protection.

Ethical and professional practices: protecting customer data and privacy even under deadline pressure.

Requirements volatility is growth or change in the requirements during the project’s development life cycle. Some change is normal; the challenge is designing so it does not wreck the project.

The later a change arrives, the more it costs. Early on, a change edits a document; late on, it edits finished work.

Why: the design, the verification (test) plans and the deployment plans were all built on the old requirements, so each has to be reworked. This is the reason good design (slide 17) tries to isolate the parts most likely to change.

In the design phase, the process is the set of activities that bridges the gap between requirements and construction.

Examples of those activities: architectural and detailed design, design reviews, setting quality evaluation criteria, design change management and version control, and adopting design tools.

The challenge is that in many companies this process is not well established, is poorly understood, focuses on one activity (say the user interface) while ignoring others, or is not done at all.

The house analogy: one team follows a plan, another works without one, one builds doors before the walls exist. In software, Team A uses Agile, Team B uses Waterfall, nobody agreed on design rules, and the pieces don’t fit at integration time.

The technology used to design and build software keeps evolving to offer new capabilities. AI and machine learning are today’s obvious example.

The chatbot example shows the cost: before integrating an AI chatbot into customer service, developers must learn ML algorithms, data preparation and model training, and still make the bot work with existing customer databases.

Designers are expected to understand and use new technologies all at the same time, which creates demand for designers who learn quickly.

Why it is hard: learning takes time while the project deadline doesn’t move, and the new technology must interoperate with old legacy systems that can’t simply be replaced.

A project has many stakeholders (users, clients, managers, security, operations), and each has needs that pull the design their way: one wants performance, another usability, another security.

Some of those needs conflict, and each stakeholder is convinced they are right. Stronger security can make the system slower or harder to use, for instance.

The designer has to make trade-offs that satisfy each stakeholder as far as possible, without the decision harming the project as a whole.

This is especially difficult in large-scale systems, where there are more stakeholders and every decision touches more parts.

Design decisions affect the environment and people who use the software: privacy, safety, accessibility, energy use. Designers are responsible for those effects.

Designers must show strong ethical and professional practices so that the systems they produce are high quality, not just finished on time.

That takes leadership: influencing and negotiating with stakeholders and motivating the team. It is hard because management, customers and peers all apply pressure, often toward cutting corners.

The ACM Code of Ethics and Professional Conduct is the reference example. Its general principles include contributing to society and well-being (respect privacy, be honest and fair), professional responsibilities (follow rules, ensure security), and leadership principles (put the public good first).

A reminder from slide 14: design is both a process and a product. This part of the lecture is about the process.

A software design process is a set of activities that specify how resources (people, tools, time) work together to produce design products.

The products are things like use cases, class diagrams and other UML models, and design documents.

The design process has two major activities: software architecture and detailed design. These two are the heart of the course (architecture in chapters 2–4, detailed design in 5–7).

And four supporting activities: construction design, human-computer interface design, software design documentation, and management activities. Construction design and HCI design sound “major” but are listed as supporting; that is the usual trap.

Software architecture is the macro-design approach: it creates models that show the quality and the function of the whole system, at the level of big parts rather than code.

Its models are black boxes: each component is described by what it does and how it connects, not by its insides. That is enough to evaluate the system’s projected quality and functions early.

It is designed from multiple perspectives (views), so stakeholders with different backgrounds can each check that their concerns are addressed. Chapter 2’s 4+1 views come from this idea.

It defines the major structural components and interfaces of the system.

It focuses on the quality aspects (performance, security, availability…) before detailed design or construction begins, because quality is hard to add later.

It is a tool for communication, reasoning and analysis, and it lays the foundation for all later work in the life cycle.

Detailed design focuses on the internals of the components and interfaces that architecture identified.

It begins after the architecture is specified, reviewed and judged complete enough. Starting detailed design on a shaky architecture means redoing it.

It is a white-box approach: it opens each component and designs its internal structure and behaviour.

It refines the architecture until the whole design (architecture + detailed design) is complete enough for construction to begin.

Focus: detailed design is mostly about functional requirements (what the system does), while architecture is mostly about non-functional, quality requirements.

Provides: architecture gives the big picture (major components, how they connect, key quality attributes); detailed design gives the internal details of each component (algorithms, data structures, workflows).

Viewpoint and timing: architecture is the black-box view and comes first; detailed design is the white-box view and starts after the architecture is reviewed and approved.

Focus and purpose: architecture targets mostly non-functional requirements and is a communication tool for all stakeholders; detailed design targets functional requirements and tells developers how to build each part.

Banking example: architecture defines the UI, login system, transaction service and database and how they interact securely; detailed design says how the login checks credentials (encryption, API calls, error handling) and how transactions and queries work.

Component design: architecture only identifies the major components; component design creates their internal structure and behaviour. In object-oriented systems it is drawn in UML as class diagrams, sequence diagrams and so on. Chapter 5 is mostly this.

Interface design: specifying the interfaces between components, meaning the exact operations and data they exchange.

Interfaces can be internal (between two parts inside your system: the login system tells the transaction service “user authenticated, allow transactions”) or external (between your system and an outside one: the banking app calls a third-party payment gateway).

Wedding-dress analogy for component design: each part of the dress (bodice, skirt, sleeves) is designed in detail. In software: the internal details of each component (classes, attributes, methods).

For interface design: making sure all the parts connect and fit smoothly into one dress. In software: how components interact (method calls, data flow between modules). A beautiful bodice that doesn’t attach to the skirt is a failed design.

Why document the design? It records every design decision (and its reason) for future reference, keeps the project consistent and traceable (each design element can be traced back to a requirement), and lets developers, testers and maintainers understand the system without asking the original designer.

Why manage the design? Management coordinates the team and handles design changes, plans, tracks and controls the design process, and keeps the project on time, within scope and on budget.

Construction design is the lowest level of detailed design: it models and specifies how individual functions are implemented. It is the step right before code.

Its main work is the analysis and design of algorithms, chosen for correctness and efficiency.

The example: once a “search” feature is designed, construction design decides whether it uses binary search (fast, needs sorted data) or linear search (simple, slower), based on speed and performance.

Human-computer interface design applies general usability principles to optimise the interface between people and the computer: the UI should be easy to learn, friendly and efficient.

The login-screen example lists concrete decisions: clear error messages, buttons of a proper size, and accessibility for all users (screen readers, colour contrast). These are design decisions, made before coding, not cosmetic touches added at the end.

Documentation starts in the design phase and continues through the whole life cycle, because the design keeps changing and the documents must keep up.

It is essential for large, complex systems, where no single person can hold the design in their head, and it supports both development and maintenance.

Its readers are managers, designers, developers, testers and maintainers, so it must contain all the design details each of them needs.

It is more than writing: it covers documenting, validating (checking the documents are correct) and managing the design documents.

Design management plans and controls resources so the design activities meet their goals.

In the design phase that means delivering quality designs on time and within budget, and evaluating design quality from both the management view (cost, schedule) and the engineering view (standards, correctness).

Configuration management controls changes to the design: which version is current, who changed what, and how improvements are approved. It is critical in large projects where many people edit the same design.

The design phase is made of several activities, and each has one or more tasks (for example, detailed design = component design + interface design).

The rest of the semester follows this map: how to carry out the major activities (architecture, then detailed design and patterns) and how to document them.

Ideally all design work would happen inside the design phase. In practice design activities are spread across the life cycle.

Most design effort is still in the design phase, but some design definitely happens elsewhere: during requirements (for example sketching an architecture to check feasibility) and during construction (low-level design decisions made while coding).

Systems engineer: designs the overall development process of the whole system, including both its hardware and software parts.

Software architect: designs the software with a mostly black-box approach, concerned with the external properties of components that determine quality and support the later design of functional requirements.

Component designer: designs the internal structure and behaviour of the components found during architecture. These designers usually have strong programming skills, since they often implement their own designs.

User interface designer: designs the UI and is skilled at increasing usability.

The fundamentals come in three groups. Principles are the rules used to judge a design: modularization, abstraction, encapsulation, cohesion and coupling, separation of interface and implementation, sufficiency and completeness.

Strategies are the two overall ways to decompose a system: object-oriented or structured (functional).

Considerations are two goals to keep in mind at every decision: minimise complexity and design for change.

Modularization keeps decomposing the system into smaller components until they are fine-grained. Each module handles one part of the functionality and can be developed, tested and maintained independently.

It is one of the most important principles because it keeps the system manageable in every phase of the life cycle.

Splitting the design splits everything else with it: each module gets its own requirements, its own code and its own test cases. That is why one good decomposition helps the whole project.

The result is a design that is easier to understand, and so easier to develop, maintain and reuse.

Fine-grained means each component is small and specific: it has one narrow, focused responsibility, which makes it easier to understand, test and reuse.

Example: instead of one big Payment Processor module, use smaller ones such as Card Validator, Payment Authorizer and Receipt Generator. Each can be changed or reused without touching the others.

Modules keep the complexity of a large program manageable: you reason about one module at a time.

They isolate errors: a fault is usually confined to one module, so it is easier to find and fix.

They eliminate redundancy: shared logic is written once in a module instead of copied in many places.

They encourage reuse: a well-defined module becomes a library other programs can use.

Overall a modular program is easier to write, read and modify.

Modularization tells you to split the system, but not where to split it. Splitting at random produces modules that make no sense. Something has to guide and justify the cuts.

Abstraction guides it: each module should represent one essential concept and hide the unnecessary details, so modules are meaningful and focused.

Encapsulation completes it: once a module’s essential face is decided, its internals are protected so other modules can only use the agreed operations.

Abstraction focuses on the essential characteristics of an entity, in its current context, and defers the unnecessary details to later.

Modularization says what must be done (split the system); abstraction says how to do it well. Modularizing in an ad-hoc way, without abstraction, gives incoherent designs that are hard to understand and maintain.

Abstraction applies to data (show only the attributes that matter) and to functions/behaviour (show only the essential operations). Slide 46 explains each.

Example: the payment gateway hides how payments are processed; the shopping cart just calls a simple “request payment” interface.

Functional (procedural) abstraction simplifies reasoning about an operation made of many steps. “Computer 1 SENDS a message to computer 2” stands for: look up the server, open a TCP/IP connection, send, wait for the reply, close the connection. The word SEND lets you think about the operation without the steps.

Data abstraction simplifies reasoning about the structure of data. In the same sentence, MESSAGE is a data abstraction: you can talk about sending a message long before deciding its fields (header, body, encoding), which are deferred to later design stages.

Abstraction hides details, so an entity is easier to use: you call sort() without knowing the algorithm.

It lets you design the general framework (the overall solution) first and postpone the details, which matches the move from architecture to detailed design.

Because users depend only on the abstraction, you can replace an implementation with a better one later without changing them.

Encapsulation gives access to an entity’s services by exposing only the information needed to use them, and hides how the services are carried out.

Applied to data, it gives access to exactly the data needed, no more, no less.

Abstraction and encapsulation work together: abstraction decides what is essential and hides the rest; encapsulation then enforces it, revising the abstraction so only the essential information is reachable. In that sense encapsulation forces good abstractions.

In object-oriented code it is done with private attributes and public methods: a user’s password is never read directly, only used through login() or register().

Purpose: abstraction hides unnecessary details and shows only the essential features; encapsulation hides the internal implementation and restricts direct access to data.

Focus: abstraction is about what a class or module does; encapsulation is about how its data and methods are accessed and protected.

Implementation: abstraction is achieved with abstract classes, interfaces or simplified models; encapsulation with access modifiers (private, public, protected) and getter/setter methods.

Examples: a payment module that shows only processPayment (abstraction); a password stored privately and reachable only through controlled methods (encapsulation).

The diagram chains the three principles: modularization splits the system into modules, abstraction decides each module’s essential characteristics, and…

…encapsulation enforces that each module exposes only that essential information. Remember the order: split, focus, protect.

Modularization example: an e-commerce system split into Login, Product Catalog, Cart and Payment modules, each easier to build, test and maintain.

Abstraction example: the Payment module shows processPayment() and hides the ten internal steps it takes.

Encapsulation example: card details inside Payment are private; other modules can only send data through methods like pay().

The memory aid: modularization = split the house into rooms; abstraction = name each room by purpose without showing everything inside; encapsulation = lock the rooms and hand out keys only for the doors you may open.

The exercise applies modularization to an online student registration system: decompose it into fine-grained modules, each with one responsibility.

Then discuss abstraction for those modules, both data abstraction (which data each module exposes) and behaviour abstraction (which operations it offers).

Finally pick one module and discuss how to encapsulate it: what becomes private and which public operations remain. Slide 53 gives a model answer.

A model decomposition into seven modules: user management, course catalog, registration, payment, schedule and timetable, notifications, and reports and records. Each has one clear job.

Data abstraction: the Payment module shows whether a fee is paid and hides the bank transaction IDs.

Behaviour abstraction: the Registration module offers enrollStudent(courseID) and hides how eligibility is checked and the database is updated.

Encapsulation for Payment: card numbers are private, the public methods are processPayment() and checkPaymentStatus(), and other modules can only go through that interface.

Coupling is the manner and degree of interdependence between modules: how much one module relies on another.

It is a measurement: the higher the coupling, the stronger the dependency, so a change in one module is more likely to force changes in another.

Aim for low coupling. Loosely coupled modules can be changed, tested and reused separately.

Content coupling is the most severe type: one module modifies or relies on the internal data or code of another (e.g. directly changing another class’s private field). Any change inside the second module can break the first.

Common coupling: modules depend on a shared common area, such as global variables. Change the global, and every module that uses it may change behaviour, which makes faults hard to trace.

External coupling: two modules share an externally imposed data format, communication protocol or device interface. If the external format changes, both modules must change.

Control coupling: one module controls the flow of another by passing it information on what to do, for example a flag like mode = PRINT_OR_SAVE. The receiver’s behaviour now depends on the caller’s decisions.

Stamp coupling: modules share a composite data structure but each uses only part of it, such as passing a whole student record to a function that needs only the ID. The function now depends on the whole record’s structure.

Data coupling: modules share only the data they need, through parameters (pass the ID, not the record). This is the acceptable form of coupling.

No coupling: modules do not communicate at all.

Order from worst to best, as on slides 55–57: content, common, external, control, stamp, data, none.

High coupling lowers quality in two ways: reusability drops (a module can’t be taken elsewhere without its partners) and maintainability drops (a change ripples into dependent modules).

As coupling rises, so does the complexity of managing and maintaining the design units, because you have to understand several modules to change one.

Cohesion is the manner and degree to which the tasks performed by one module are related to each other.

It measures how well a design unit’s parts belong together to achieve a particular task. A cohesive module is easy to name in a few words.

High cohesion is good, low cohesion is bad. Together with slide 54 this gives the golden rule: low coupling, high cohesion.

Functional cohesion (the best): every part of the unit contributes to one single function.

Procedural (sequential) cohesion: the tasks are steps done in order to achieve the unit’s purpose, often the output of one step feeding the next.

Temporal cohesion: the tasks are grouped because they run at the same time (e.g. at start-up), not because they are related.

Communication(al) cohesion: the tasks produce or consume the same data.

calculateTotal() sums the prices in a cart: every line serves one task, so it is functional cohesion.

processOrder() validates the order, then calculates the cost, then processes payment: steps in sequence, so procedural (sequential).

initializeSystem() opens database connections, loads configuration and logs the start-up time: unrelated tasks grouped because they happen at program start, so temporal.

generateStudentReport() calculates GPA, lists courses and prints grades, all from the same student record: communicational.

Good design: ShoppingCart has addItem(), removeItem() and calculateTotal(), all about managing the cart, so cohesion is high.

It reaches the database and payment service only through an interface, so coupling is low: switching from SQLite to Firebase doesn’t break the cart.

Bad design: CartManager mixes addItemToCart(), sendEmailToUser() and connectToDatabase(), three unrelated jobs, so cohesion is low.

It also creates the Database and EmailService objects itself, so coupling is tight: changing either service means editing CartManager.

Separation of interface and implementation: design each module so that a stable interface (what it offers) is identified and kept separate from its implementation (how it does it).

It is not the same as encapsulation. Encapsulation hides the implementation details; this principle separates them, so the interface exists on its own.

The payoff: different implementations of the same interface can be provided and swapped (a PaymentGateway interface with Visa and PayPal implementations) without affecting the code that uses the interface.

Completeness measures whether a design unit provides all the services it needs to achieve its intent: no less.

Example: a communication class is complete only if it can establish and terminate a connection and send and receive messages. Missing any one makes it incomplete.

Sufficiency measures whether the unit provides only the services sufficient for its intent: no more. Completeness asks “is anything missing?”, sufficiency asks “is anything extra?”.

Example of insufficiency in the opposite sense: a messaging module that also manages user profiles has taken on a service outside its purpose. The banking example on the slide shows completeness: the transfer and history requirements must both appear in the design.

Modularization = decompose into separate modules.

Abstraction = separate the what from the how.

Encapsulation = information hiding.

Coupling = dependency between modules; cohesion = how related the tasks in a module are. Separation of interface and implementation = one interface, possibly several implementations.

Completeness = every required service is there; sufficiency = only the services needed. A one-line definition of each is a likely short question.

The object-oriented strategy expresses a system or component as objects and the connections between them, so the decomposition is by objects rather than by functions.

Every object has a unique identity (a name), a state (its attribute values) and well-defined behaviour (its operations).

It supports inheritance and polymorphism and suits object-oriented languages such as Java. Chapters 5–7 use this strategy throughout.

The structured (functional) strategy decomposes a system into single-purpose, independent modules using an iterative top-down approach: start with the whole function and keep breaking it down.

It focuses on the functions the system must provide, their decomposition into smaller functions, and the modules that implement them.

It is inappropriate for object-oriented languages because it is centred on functions, not objects. It fits procedural languages such as C.

Minimise complexity: design is fundamentally about reducing complexity, and every decision should take that into account.

When two design options compete and both meet the requirements, choose the one that is less complex (fewer parts, fewer dependencies).

Design for change: software will change, so design with extension in mind. Several techniques (modularity, interfaces, the principles of chapter 5) help achieve this.

The exercise: draw a mind-map of the chapter’s topics and how they relate, and upload it to the Moodle forum. The value is in the connecting lines, not in listing terms.

It is required at the end of every chapter, so it doubles as a revision sheet before each exam.

Any mind-mapping tool works: XMind, Miro or draw.io. Put the central topic (software design) in the middle and branch to problem solving, process, challenges, principles and strategies.

The summary repeats the seven topics of slide 3. A good check: for each one, can you give the definition and one example without looking?

The next chapter starts the first major design activity: software architecture.

The detailed summary, first half: SE definitions and phases, problem solving (states, functional fixedness, the holistic approach), design as process and product, why study design.

The five challenges: requirements volatility, inconsistent processes, fast-changing technology, managing design influences, ethics.

Second half: the design process, with its major activities (architecture, detailed design) and supporting activities (construction design, HCI design, documentation, management).

The eight principles, from modularization to sufficiency.

The two strategies (object-oriented, structured) and the two considerations (minimise complexity, design for change).