The design model: five element sets

Two dimensions, not one list

The design model is the complete set of work products design produces — the software equivalent of an architect’s drawings, which begin with a rendering of the whole house and are refined until they say where each pipe runs. It is best read in two dimensions at once. The process dimension records the evolution of the model as design tasks are executed: architecture is settled first and sets the stage, interface and component-level design typically proceed in parallel after it, and the deployment model is usually delayed until the design is otherwise complete. The abstraction dimension records the level of detail: each element of the requirements model is transformed into a design equivalent and then refined iteratively downward. The boundary between the analysis and design models sits somewhere in that second dimension, and it is a blend rather than a line — sometimes the distinction is crisp, often the analysis model simply thickens into design.

That is why the same UML diagrams appear on both sides. A class diagram, a sequence diagram, an activity diagram: all of them exist in the requirements model and reappear in the design model. What changes is that the design versions carry implementation-specific detail, and that architectural structure and style, the components inside that architecture, and the interfaces between components and the outside world are now what the diagrams are about.

The five element sets

• Data elements. The data model, refined from the user’s view of information down to implementation-specific representations — data structures at component level, a database schema at application level. In many systems the architecture of the data shapes the architecture of the software that processes it, which is why data design is not a junior partner.
• Architectural elements. The overall view: subsystems, usually derived from the analysis packages, and their relationships. Derived from three sources — knowledge of the application domain, specific requirements-model elements such as use cases and analysis classes, and the availability of architectural styles and patterns.
• Interface elements. Three kinds, and answers routinely name only one. The user interface, the external interfaces to other systems, devices and networks, and the internal interfaces between design components. External interface design needs definitive information about the entity on the other side, and should include error checking and security.
• Component-level elements. The full internal description of each component: data structures for all local data objects, algorithmic detail for all processing that occurs within it, and an interface giving access to its operations.
• Deployment-level elements. How functionality and subsystems are allocated to the physical computing environment. Drawn in descriptor form first — naming environments without pinning configurations — and refined into instance form later, when the specific hardware is known.

The principles that govern all five

A handful of design modelling principles do most of the work in practice. Every element of the design model should be traceable to the requirements model. Always consider the architecture first — it constrains interfaces, data structures, control flow, testability and maintainability, so component-level questions come after it, not before. Data design matters as much as processing design. Interfaces, internal and external, must be designed with care, because the way data flows between components governs error propagation. Component-level design should be functionally independent and components should be loosely coupled. And the design model must be understandable, because its purpose is to communicate to people who will code, test and maintain — a design nobody can read has failed at the only job it has, however correct it is.

Worked example — the BorrowBox design model as a table of contents

Here is what the five element sets actually contain for BorrowBox, one artefact each. Data: the catalogue schema — Tool, ToolCopy, Locker, Reservation, ReturnRecord — plus the decision that a ToolCopy row is the unit of loan rather than a Tool, which is a data-design decision with consequences everywhere. Architectural: a layered app (presentation over services over persistence), a data-centred catalogue at the core, and an event channel out to the locker estate — three styles cohabiting in one system, each chosen for a different reason. Interface: the scan screen for the member; the locker vendor’s message contract as the external interface, with a validity window and error paths for a door that never confirms; and the internal contract by which ReservationService asks FeePolicy what is owed. Component-level: FeePolicy fully specified — its local rate table, the algorithm from return timestamp to charge, and the single operation it exposes. Deployment: the member’s Android phone, the locker controller in the street cabinet, and the depot server, with the subsystems allocated across them — in descriptor form, because we have not yet chosen the controller’s hardware.

Read that list back and notice what it gives you: a complete answer to "what is in a design model?" that is grounded in one system rather than recited from a chapter — which is exactly the shape the definition question rewards.