Software design

Software design turns the requirements specification into a blueprint for construction: the overall architecture, the decomposition into modules, how control flows between them, and how they are deployed on hardware. Good design makes software easier to build, test and change. This topic covers the design process and core principles, architectural decisions and styles, distributed and client–server architectures, real-time design and component-based software engineering. MCQs usually test definitions — cohesion, coupling, architectural styles, tiers.

Key concepts

Design process: a sequence of refinements — architectural design (subsystems and relationships) → abstract specification of each subsystem → interface design → component design → data-structure design → algorithm design. Outputs include design models and documentation.

Design concepts

• Abstraction: focus on essentials (procedural, data, control abstraction).
• Refinement: stepwise elaboration from high level to detail (top-down).
• Modularity: dividing into separately addressable modules.
• Information hiding: modules hide internal details behind interfaces (Parnas).
• Functional independence: high cohesion + low coupling.
  • Cohesion (best to worst): functional, sequential, communicational, procedural, temporal, logical, coincidental.
  • Coupling (best to worst): data (no direct coupling is ideal), stamp, control, external, common, content.
• Others: architecture, patterns, separation of concerns, refactoring.

Design models: data/class design, architectural design, interface design and component-level design (also deployment design). In structured design: data flow diagrams converted to structure charts; in OO design: class, sequence and deployment diagrams.

Design heuristics (rules of thumb): increase cohesion and reduce coupling; keep the scope of effect of a module within its scope of control; reduce high fan-out and aim for higher fan-in (reuse) in deeper levels; avoid pathological connections (jumping into the middle of a module); keep interfaces simple and consistent; define modules with predictable behaviour.

Architectural design decisions: which architecture style or reference architecture to use; how the system is distributed; how it is decomposed into modules; control strategy; how the design will be evaluated and documented. Choices are driven by non-functional requirements: performance (localise critical operations, few large components), security (layered, critical assets in inner layers), safety, availability (redundancy), maintainability (fine-grained, replaceable components).

System organisation (structuring) styles

• Shared repository: subsystems exchange data through a central database (e.g. CASE toolsets, IDEs).
• Client–server: services provided by servers, used by clients over a network.
• Layered (abstract machine): each layer provides services to the layer above (e.g. OSI model).

Modular decomposition styles

• Object-oriented: loosely coupled objects with well-defined interfaces.
• Function-oriented pipelining (pipe and filter): data flows through a sequence of transformations (batch processing, compilers).

Control styles

• Centralised control: one subsystem controls others — call-return (top-down subroutine model) or manager model (one process controls concurrent processes).
• Event-based control: subsystems respond to external events — broadcast (events sent to all, interested ones respond) or interrupt-driven (handlers for real-time events).

Reference architectures: abstract, domain-level architectures used as a standard for comparison, e.g. the OSI 7-layer reference model, the ECMA CASE reference model.

Multiprocessor architecture: the system runs as processes on several processors, often under a scheduler; used in real-time and large systems.

Client–server architectures

• Layers: presentation, application processing (business logic), data management.
• Two-tier: thin client (presentation only on client; server does logic and data) or fat client (logic on the client).
• Three-tier / multi-tier: presentation, application server, database server on separate machines — more scalable.

Distributed object architectures: no client/server distinction; objects provide services to each other through middleware called an object request broker (e.g. CORBA, Java RMI, DCOM). Flexible and scalable but complex.

Inter-organisational distributed computing

• Peer-to-peer (P2P): decentralised, every node can be client and server (file sharing, blockchain).
• Service-oriented architecture (SOA): loosely coupled services published and discovered via standard interfaces (web services, SOAP/WSDL, REST), possibly by different organisations.

Real-time software design: correctness depends on timing as well as results. Hard real-time (missing a deadline is a failure — air-bag control) vs soft (degradation — video streaming). Designed as stimulus–response systems with periodic and aperiodic stimuli; architecture typically sensor processes → computation → actuator processes. Uses real-time OS, priority scheduling and state machines. Patterns: monitoring and control, data acquisition.

Component-based software engineering (CBSE): building systems by composing independent, reusable components with well-defined interfaces (provides and requires interfaces) running in a component model/middleware (EJB, .NET, COM). Process: outline requirements → identify candidate components → modify requirements to fit components → architectural design → compose and integrate. Benefits: reuse, faster delivery; issues: trust, requirement compromises, component evolution.

High-yield points

• Cohesion best → worst: functional, sequential, communicational, procedural, temporal, logical, coincidental.
• Coupling best → worst: data, stamp, control, external, common, content.
• Thin client: processing on the server; fat client: processing on the client.
• Event-based control: broadcast and interrupt-driven; centralised: call-return and manager.
• Distributed objects communicate through an object request broker (e.g. CORBA).

Worked example

Module M holds a file-reading routine, a date formatter and an e-mail sender, grouped only because they were written together. Module A passes a flag telling module B which branch to execute. Name the cohesion and coupling.

1. Unrelated functions grouped arbitrarily → coincidental cohesion (the worst).
2. Passing a control flag that steers another module's logic → control coupling.

Fix: split M into functionally cohesive modules; let B decide its own logic so only data is passed (data coupling).

Exam tips

• Aim for high cohesion, low coupling. Best cohesion: functional; worst: coincidental. Best coupling: data; worst: content.
• Thin client → most processing on the server; fat client → processing on the client.
• Broadcast and interrupt-driven are event-based control; call-return and manager are centralised.
• OSI is the classic example of a reference and a layered architecture.
• Hard real-time: deadlines are absolute.

Exam-style questions

From Calmon's question bank, which has 25 questions on this topic.

1. Which design concept states that the design should hide the details of implementation and present only essential features?

• A. Cohesion
• B. Coupling
• C. Abstraction
• D. Modularity

Answer: C. Abstraction lets a designer specify what a component does while suppressing how it is implemented.

2. In Sommerville's classification of event-driven control models, in which model is an event sent to all sub-systems, and any sub-system programmed to handle that event responds to it?

• A. Manager model
• B. Call-return model
• C. Interrupt-driven model
• D. Broadcast model

Answer: D. In the broadcast model an event is broadcast to all sub-systems and whichever sub-system can handle it does so. Call-return and manager models are centralized control styles; the interrupt-driven model passes interrupts to a specific handler.

Practise ACtE08 questions →