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: any part of a program can depend on any other, so with N components there are up to N(N−1)/2 possible dependencies. That is 45 for 10 components and 1,225 for 50. The second is change: on a typical project about a quarter of the requirements change before it ships. A good design keeps dependencies few and makes change cheap.

The subject teaches object-oriented analysis and design, following Craig Larman's textbook Applying UML and Patterns. 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. Each produces its own diagrams, 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: the GRASP principles, the GoF design patterns and architecture.

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: you need 30 of the 60, which is 60 of the 120 raw marks. 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 you can prepare a method for each one.

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.