Software Modelling & Design, drawn out

What this subject is about

Software design means deliberately choosing how a system behaves (how it responds to inputs and events) and how it is structured (which parts exist and how they collaborate). Software modelling means drawing simplified pictures of a system, called models, so that people can discuss a design, criticise it and compare alternatives before committing to code.

Design is hard for two reasons. The first is complexity. One part of a program depends on another when it uses it, so that a change to the second part can break the first. In principle any part can depend on any other, so with N components there are up to N(N−1)/2 possible dependencies, one for every pair. That is 45 for 10 components and 1,225 for 50: the number of things that can go wrong grows far faster than the program itself.

The second reason is change. Larman reports that about 25% of the requirements change during a typical project, and 35–50% on large ones. Every change ripples along the dependencies, so a tangled design that works on day one becomes expensive to change by day ninety. A good design therefore does two things: it keeps the dependencies few, and it arranges them so that a likely change touches as few parts as possible.

The subject teaches object-oriented analysis and design, following Craig Larman's textbook Applying UML and Patterns. UML, the Unified Modeling Language, is the standard set of diagram notations you will draw throughout. Analysis works out what the system must do and what the world it lives in looks like. Design decides how software objects will do it. For a shop's till, for example, analysis finds out that a cashier records each item and takes a payment; design decides which software object adds up the total. Each step produces its own diagrams or documents, called artefacts, and the map below shows how they connect. You will see a copy of it at the top of every Part, with that Part's artefacts highlighted.

Read the map from the top left. Use cases describe how people use the system. The domain model captures the concepts of the problem world. System sequence diagrams list the events an actor sends to the system, and operation contracts say what each event changes. Design then turns this into interaction diagrams (which objects send which messages), a design class diagram (the software classes that need to exist) and finally Java code. State machines describe objects whose behaviour depends on their state. Along the bottom are the ideas that guide every design decision. GRASP (General Responsibility Assignment Software Patterns) is a set of nine principles for deciding which object should do which job. The GoF design patterns are standard, named solutions to recurring design problems, from the 1990s book by the “Gang of Four” (Gamma, Helm, Johnson and Vlissides). Architecture is the large-scale shape of the system: its layers and major parts, and the decisions that are expensive to reverse.

To see the whole chain on one example, follow a single shop sale through it. The Process Sale use case says, in words, that a cashier enters each item and the customer pays. The domain model notes that the shop's world contains Sales, Items and Payments. The system sequence diagram lists the events the cashier sends, such as enterItem and makePayment, and an operation contract says that enterItem creates a new line on the sale. Design then decides, guided by GRASP, that the Sale object should create that line and add up the total; the interaction diagram draws those messages, the design class diagram lists the resulting classes and methods, and the Java code implements them. Every later Part zooms in on one link of this chain.

Where the exam marks are

The exam is on paper, on campus, with 15 minutes of reading time and 2 hours of writing. It is worth 60% of the subject and carries a hurdle, a minimum you must reach to pass the subject whatever your other marks: you need 30 of the 60, which is 60 of the 120 raw marks on the paper. You may bring two double-sided A4 pages of notes, and pencil is allowed for diagrams. The two 2021 papers have exactly the same twelve kinds of question, so the most reliable preparation is to learn a method for each kind, and the table below says which Part teaches it. Two names in it may be new. A domain class diagram is the exam's name for a domain model, a picture of the real-world concepts; a design class diagram (DCD) and a design sequence diagram (DSD) show the software classes and the messages between them.

The running examples

A handful of example systems come back again and again, in the textbook, the lectures and the exam. Meet them once here, so they feel familiar when they turn up later.

How to read this site

Each Part opens with what you'll be able to do by the end, and a copy of the map. Sections build on each other, so read a Part in order the first time. Coloured boxes mark the kind of content, so you can skim for what you need later:

Step-through diagrams have Back and Next buttons. Use them to watch a diagram being built the way you would build it in the exam, one decision at a time, with the reason for each step written underneath. "Check yourself" questions hide their answers until you click; try each one honestly before you look. In the pattern Parts, colours mean roles: the same colour always marks the same job (client, abstraction, the pattern's key class, concrete classes), in both the diagrams and the text.

If a symbol in a diagram puzzles you, the UML notation appendix draws every diagram type once in full, with every element labelled.