The Exam

The Exam at a Glance exam

You can only prepare well for a paper whose shape you know. The good news is that this subject's exam has a very stable shape: the two 2021 papers ask the same twelve kinds of question, in a different order and about different scenarios. So the strategy of this whole Part is to prepare by question type, not by memorising particular answers.

The basic facts below come from the 2021 cover sheets, the Week 1 subject overview and the Week 12 review lecture.

The 2021 papers also carry a disclaimer: "question types, and their weightings may vary across different years." That is one more reason to learn a method for each type rather than a list of answers.

Where the 120 marks go

The chart lists every question type in the two 2021 papers, with its question number in each paper and its marks. The bars are coloured by the kind of work the question asks for, and the strip at the bottom adds them up.

The same information as a table, with where to revise each type:

What the two papers teach you

Putting the two 2021 papers side by side gives five lessons, and each one changes how you should revise.

1. The same 12 sub-question types appear in both semesters. Only the order and the scenarios change, so prepare a fixed method for each type (9.4).
2. Some MCQs are reused word for word. S1 Q1.2 is S2 Q1.4 (noodle soup), and S1 Q1.8 is S2 Q1.7 (Self-guided Co.). That is one more reason to know all 20 in 9.6.
3. About 65 of the 120 marks are for hand-drawn UML, as the chart shows, so fluent notation is the single biggest lever on your mark.
4. Instructions change between years. S1 Q7.1 says to omit methods inherited through inheritance or interfaces, while S2 Q7.1 says to include all of them. Read every bullet under a question before you draw.
5. Notation has to be unambiguous. The Workshop 11 worksheet says markers "will not be guessing or inferring" whether an arrow is navigation or inheritance. The same worksheet says to make reasonable assumptions and list them explicitly.

What the official answers add

The official sample answers to both 2021 papers were released on 26–27 October. Reading them together gives five further lessons; the details are in each worked answer in Parts I–VIII.

1. The official answers are leaner than the guide's. Their domain models have no abstract markers or conceptual data types, their SSDs have no return arrows, their DCDs have no constructors, and their architecture memos have one short point per heading. Everything extra the guide adds is correct, but when time runs short you can drop it without losing marks.
2. Some notation points are stated outright. Associations in a domain model "need to be named" and "cannot be anonymous" (S2 Q4). In an SSD "the return type is not necessary" (S1 Q3), and the system's internal work is drawn as self-calls. In a design sequence diagram, binding returns to names (l = -9, then apply(l, r)) is as good as writing concrete arguments.
3. Some marks breakdowns are published. In Q7.2, S1 gives 2 marks for Composite and 3 for Strategy; S2 gives one mark per class named as implementing the Component interface, and at most 1 mark for Strategy if you find only one of its two instances.
4. Two of the guide's MCQ answers were wrong. The official answers to 2021 S2 Q1.1 and Q1.9 are Polymorphism and Composite, not Strategy (9.6). The other 18 agree.
5. The official answers have slips of their own, such as display(PopCorn) in the vending machine SSD, a "Classical." return string in the S2 Q7.3 diagram, and no initial state in the S1 Q5 state machine. Learn from their structure, not their typos.

Check yourselfYou scored 34/40 on the projects and workshops and 58 of the 120 marks on the paper. Do you pass?

No. The exam is worth 60% of the subject, so 58/120 on the paper scales to 29/60, which is below the 30/60 exam hurdle. You needed at least 60 raw marks. A strong project mark doesn't help, because the hurdles are separate: 20/40 on projects and workshops, 30/60 on the exam, and 50% overall.

Check yourselfQ7.1 asks for a DCD of the given code. Why should you read every bullet under it before drawing anything?

Because the instructions change between years. In 2021 S1 the bullets said to omit methods that can be inferred through inheritance or interfaces; in 2021 S2 they said to include all of them. Drawing the S1 way on the S2 paper (or the reverse) loses marks for a diagram that is otherwise correct.

Time Budget and Reading-Time Plan exam

The problem with a 2-hour paper is not knowledge but time: a diagram drawn by hand always takes longer than you expect, and a question you never reach scores nothing. The fix is a budget decided in advance. The paper gives 120 minutes for 120 marks, about 1 minute per mark. Spend less than that on the MCQs and bank the time for the diagrams; the time saved also pays for a review at the end.

Using the 15 minutes of reading time

During reading time you can think but not write, so the trick is to do all the deciding now and leave only the writing for later. Use the 15 minutes in four blocks, as the top bar of the figure shows.

1. 0–2 min: leaf through the whole paper. Match each question to its type in the table of 9.1 and note its marks.
2. 2–6 min: decide all 10 MCQs in your head, using the cue table in 9.6. They are short, and deciding them now makes the writing-time pass quick.
3. 6–11 min: read the Java code question (Q7). It is the densest page and worth 23 marks. Identify each interface and its implementers, which fields become associations, and which patterns are present. Then trace the requested call (for example expr.eval()) in your head and work out the concrete return values.
4. 11–15 min: read the numbered-sentence questions (domain model, state machine) and work out the classes or states sentence by sentence. Then read the architecture scenario and choose your two architecturally significant requirements, one functional and one non-functional, each tied to a sentence number.

Check yourselfIt is minute 50 of writing time and your domain class diagram, started at minute 32, is only half done. What should you do?

The domain model's budget (15 min) ran out at minute 47, so stop, leave space, and move on to the state machine. Come back in the review time or with time saved elsewhere. Half a diagram already earns marks for the sentences it covers; finishing it now would eat into the next 15-mark question, and a question you never reach scores nothing.

Check yourselfWhy spend minutes 6–11 of reading time on Q7 rather than, say, the architecture question?

Q7 is the densest page and the biggest single block (23 marks), and most of its work is thinking, not writing: spotting interfaces and implementers, deciding which fields become associations, naming the patterns, and tracing the call to get the concrete return values. All of that can be done without a pen, so reading time is exactly when to do it. The architecture question also gets thought (choose your two ASRs in minutes 11–15), but its marks are mostly for written points that need writing time anyway.

What to Put on Your 2 Double-Sided A4 Pages

Four sides of notes sounds like plenty until you try to fit a whole subject on them. The problem is not space but speed of finding: in the exam you will glance at your notes in the middle of drawing something, and you need the answer in seconds. So organise them by what you will be doing when you need them, not by lecture week, and prefer pre-drawn skeletons you can copy over prose. The plan below gives one side to each job.

Side 1: Patterns

This side is for choosing and naming patterns, so you will use it for the MCQs, for Q7.2 (patterns in the code), for the describe-the-class question and for the Composite DCD. Give all 9 GRASP principles one line each, with the problem and the solution. For each GoF pattern taught (Façade, Decorator, Builder, Adapter, Singleton, Factory, Composite, Strategy, Observer and Template Method) note the problem, the solution, the roles, the code cue and the textbook example; for Strategy, say, the example is POS pricing. Add the cue-word table and the confusable pairs from 9.6, and one line listing the recycled MCQs (noodle soup is Decorator, Self-guided is Façade, and so on).

Side 2: Structure notation

This side is for drawing class diagrams correctly: the domain model, the DCD and the Composite DCD. Start with an arrow legend covering association, navigable association, generalisation (solid line, hollow triangle), realisation (dashed line, hollow triangle), dependency (dashed open arrow), aggregation (hollow diamond) and composition (filled diamond). Add multiplicities (1, 0..1, *, 1..*, 2..*), role names, the association class, the derived attribute /x, «interface», underlined static members, visibility + - #, and attribute and operation syntax.

Include a domain versus design checklist (no methods, visibility, programming-language types or navigation in a domain model) and the Java-to-UML mapping rules. Finish with mini-skeleton DCDs for Composite, Decorator, Strategy, Observer, Adapter and Façade, plus the Singleton code; 9.9 draws all seven.

Side 3: Behaviour notation

This side is for drawing dynamic diagrams. For the SSD, note the actor stick figures, the :System lifeline, system events with parameters, dashed returns, notes and self-calls, and the loop/alt/opt/ref frames. For the design sequence diagram, note lifeline naming (name : Type, :Type, «metaclass»), the found message, activation bars, the x = msg() return syntax versus a dashed reply, the create message and the self-call.

For the state machine, note the initial and final states, the event [guard] / action label, entry/, exit/ and do/, the superstate (nested states), the choice pseudostate with [else], and history H. For the use case, note the brief, casual and fully dressed headings, extension numbering (3a, *a, 3-6a), the actor kinds, and the Boss, EBP and Size tests.

Side 4: Architecture and templates

This side is for Q6 and the templated answers. Start with one line on the UP phases and what inception and elaboration each produce, since the Week 12 review opens with them (Part I). Then give the definitions of architecture, architectural analysis (its goal and steps) and ASR, and the priority order: inflexible constraints, then business goals, then other goals. Add the FURPS+ list, noting that Larman puts security under Functional, and the lecture's list of functional ASRs (auditing, licensing, localisation, mail, online help, printing, reporting, security, system management, workflow).

Write out the 6 factor-table columns and the 7 technical-memo headings with one filled mini-example, and the layers (UI / Application / Domain / Technical Services / Foundation) with strict versus relaxed layering. A one-line solution kit per common ASR (security, configurability, reliability, usability, auditing, time-to-market) belongs here too (Part VIII). Finally, copy in the templates for the brief use case and describe-the-class questions (9.7), and the time plan from 9.2.

Check yourselfA friend's notes follow the lecture order: Week 1 on side 1, Week 2 on side 1, and so on. What goes wrong in the exam, and how does the side-per-job layout fix it?

In the exam you look things up by task: "what does a realisation arrow look like?" while drawing a DCD, or "which pattern is 'different interfaces'?" while doing an MCQ. In week order, class-diagram notation is spread across the domain-model week, the design week and the pattern weeks, so you hunt across three sides. With one side per job, everything you need for drawing a class diagram is on side 2, everything for choosing a pattern is on side 1, and so on.

The Question-Type Playbook exam

Because the same twelve question types come back every year, the best use of revision time is to fix one method per type and rehearse it until it runs on autopilot. For each type below you get what is being tested, the steps to follow, what markers look for, and a small picture of what a full-marks answer looks like. The full worked answers live in the topic Parts, which each recipe links to.

1. Pattern MCQ 2 marks each

This tests whether you recognise the design problem each GRASP principle or GoF pattern solves. The stems are short stories, and the story is mostly decoration: one phrase in it names the problem.

1. Find the problem phrase and ignore the story around it.
2. Map the cue to a pattern, using the cue table in 9.6.
3. If two options survive, pick the more specific one that solves the whole problem (for example, Composite over Decorator when the stem describes a tree). Be careful with Strategy versus Polymorphism: the official answer to 2021 S2 Q1.1 chose Polymorphism for behaviour that changes with a person's role, so pick Strategy only when the stem describes interchangeable algorithms.
4. Never leave it blank.

All the marker looks for is a single CAPITAL letter in the box. Revise the patterns in Part IV, Part VI and Part VII.

2. Brief use case and alternate scenario 5 marks

This tests the use case formats, the three kinds of actor, a goal at the level of an elementary business process (EBP), essential (technology-free) style, and how extensions are structured. Revise in Part I; the full template is in 9.7.

1. Pick an EBP-level goal and name it verb–noun.
2. Name the human primary actor, the person who actually operates the system under discussion.
3. Name at least one non-human supporting actor that provides a service to the system (payment authorisation, mapping, email).
4. Write one paragraph of the main success scenario in which the supporting actor actually appears.
5. Write the alternate scenario as a condition the system can detect, then the handling, then where it rejoins the main scenario or how it ends.

Markers look for actors that are named and typed, a brief format that really is a single paragraph, a supporting actor that is actually used, steps free of UI and technology details, and an extension with a condition, handling and an ending.

3. System sequence diagram 10 marks

This tests the system's black-box behaviour for one scenario: who sends which system event, in what order, with which values. Revise in Part II.

1. List the actors. There are often two humans, for example a customer plus a technician or attendant.
2. Draw the actor lifelines and the :System lifeline.
3. Walk the scenario sentence by sentence, drawing one system event per actor input, named at the level of intention, with concrete parameters.
4. Draw returns as dashed arrows with concrete values.
5. Show internal behaviour with notes or self-calls, as instructed.
6. Use frames only for repetition or alternatives that are actually in the scenario.

Markers check that there are only actor and System lifelines, that every step of the scenario appears, that the given interface operation names are used, that parameters and the values the scenario fixes are present, and that the time order is correct. Both official 2021 answers draw the system's internal work as self-calls, show no dashed returns at all (the values the scenario fixes go in notes such as "has to return false"), and one numbers its messages 1, 1.1, 2, … So step 4 is good practice rather than a requirement.

4. Domain class diagram 15 marks

This tests conceptual classes, attributes, associations, multiplicities, generalisation and association classes. Revise in Part II.

1. Go sentence by sentence and tick each one off.
2. For each noun, decide: a simple value becomes an attribute, and a thing with identity or relationships becomes a class.
3. Move shared attributes into a superclass (generalisation).
4. Make each relationship a named association with multiplicity at both ends.
5. Data that belongs to a link goes in an association class, and a computed value becomes a /derived attribute.
6. On a last pass, delete every software artefact.

Markers check that every sentence is represented and that there are no methods, visibility, programming-language types (int, String[50]), navigation arrows or software classes; conceptual data types like Date or Money are fine. They also check that associations are named and have multiplicities, and that the generalisation notation is correct.

5. Domain-level state machine 15 marks

This tests states, events, guards, actions, superstates and the choice pseudostate. "Domain level" means the labels are things that happen in the world, not method calls. Revise in Part V.

1. Pull out the states (conditions of waiting or doing) from each sentence.
2. Add the initial pseudostate.
3. Label transitions event [guard] / action.
4. Model "At any stage …" as an enclosing superstate with one outgoing transition.
5. Model "Continue as before" with a history state, or with explicit return transitions.
6. Model "If … continue, else …" with guards or a choice pseudostate, plus self-transitions.
7. Trace the description through your diagram.

Markers look for an initial state, every sentence covered, correct label syntax, no contradictory or overlapping guards, superstates used, and domain terms rather than method code.

6. Architecture 6.1: ASRs and architectural analysis 10 marks

This tests whether you can define architectural analysis and apply it to a case. Revise in Part VIII.

1. Choose a functional ASR (a cross-cutting service such as security/access control, auditing/records, payment, printing or reporting) and cite its sentence number.
2. Choose a non-functional ASR (usability, reliability, performance, supportability/configurability) and cite its sentence number.
3. Define architectural analysis: identify the factors that influence the architecture, understand their variability and priority, and resolve them.
4. Say why it matters: it reduces the risk of missing a critical factor, focuses effort on high-priority requirements, and aligns the product with business goals.
5. Say why each ASR is significant: its wide impact on structure, how hard it is to retrofit, its high priority (a legal or safety constraint outranks a business goal) and its variability.

Markers look for a correct functional/non-functional classification, a justification tied to this case, and the definition and importance of architectural analysis stated. One factor-table row earns a bonus.

7. Architecture 6.2: technical memo 10 marks

This tests the memo structure and a reasoned architectural argument. Revise in Part VIII. Fill in five headings:

• Under Factors, give the ASR, a measurable quality scenario and its priority.
• Under Solution, give concrete decisions (layers or packages, patterns, technologies).
• Under Motivation, trace each decision back to each factor.
• Under Unresolved issues, list the open risks and questions.
• Under Alternatives, give 1–2 options and why each was rejected.

Markers want an answer specific to the case (invented details are fine, but they must be plausible), a clear chain from factor to decision to benefit, and all five headings filled.

8. Java code → design class diagram 10–12 marks

This tests mapping code to UML. Revise in Part III.

1. Draw one box per class or interface, marking interfaces «interface».
2. A field whose type is a class or interface becomes a navigable association, with a role name equal to the field name and a multiplicity (a collection gives *). Primitives and String become attributes.
3. implements becomes a dashed line with a hollow triangle, and extends a solid line with a hollow triangle.
4. Give the operations with parameter types, return type and visibility.
5. Follow the instruction on inherited methods.
6. Underline static members.

Markers look for a complete diagram, associations rather than attribute text, correct arrowheads, role names and multiplicities, and consistency with the code. Here is the 2021 S1 calculator code and its DCD.

public interface IBinaryOp { int apply(int left, int right); }
class Plus  implements IBinaryOp { public int apply(int left, int right) { return left + right; } }
class Times implements IBinaryOp { public int apply(int left, int right) { return left * right; } }

public interface IUnaryOp { int apply(int value); }
class UMinus implements IUnaryOp { public int apply(int value) { return -value; } }

public interface IExpr { int eval(); }

public class BinaryExpr implements IExpr {
    private IExpr left, right;
    private IBinaryOp op;
    BinaryExpr(IExpr l, IBinaryOp o, IExpr r) { left = l; op = o; right = r; }
    public int eval() { return op.apply(left.eval(), right.eval()); }
}
public class UnaryExpr implements IExpr {
    private IExpr expr;
    private IUnaryOp op;
    UnaryExpr(IUnaryOp o, IExpr e) { op = o; expr = e; }
    public int eval() { return op.apply(expr.eval()); }
}
public class Constant implements IExpr {
    private int value;
    Constant(int v) { value = v; }
    public int eval() { return value; }
}

9. GoF patterns in the code 5 marks

This tests recognising patterns and their roles. For each pattern, give its name and a mapping from each role to a class. Look for 2–3 patterns, using the code-cue table in 9.7. Markers want every evident pattern named, with its roles mapped to actual classes and methods. For the calculator above the full-marks answer is:

The mark split comes from the official answer; spotting both Strategy instances is where the third Strategy mark comes from. In 2021 S2 the scheme gave one mark per class named as implementing the Component interface ISound, and at most 1 mark for Strategy if you found only one of its two instances. Revise in Part VI and Part VII.

10. Design sequence diagram with concrete returns 6–8 marks

This tests whether you can follow the code's runtime collaboration exactly. Revise in Part III.

1. Name the lifelines var : Type, using the variable names from the initialisation code. This matters when there are two instances of the same class (nine : Constant, two : Constant).
2. Start with a found message to the receiver.
3. Follow the code exactly, in Java's evaluation order (arguments left to right).
4. Give every call an activation bar and a dashed reply labelled with its concrete value.

Markers look for calls going to the right objects in the right order, correct return values, and the final result shown. The initialisation for 2021 S1 Q7.3 was:

// Set expr to -9 + 2
IExpr nine = new Constant(9);
IExpr uexpr = new UnaryExpr(new UMinus(), nine);
IExpr two = new Constant(2);
IExpr expr = new BinaryExpr(uexpr, new Plus(), two);

11. Describe the Java class 5 marks

This tests the pattern's problem and solution, an application, and usage code. The method is simply to fill in the seven-part template in 9.7. Markers look for the pattern named with its problem and solution, an account of how this code realises it, a plausible application, and code that compiles and calls the class correctly. The model answers to S1 Q8 (a Singleton Counter) and S2 Q3 (a Strategy ITaxAmount family) are in Part VI and Part VII.

12. Composite DCD 7 marks

This tests applying Composite to a recursive or part–whole structure. Revise in Part VI and Part VII.

1. Define the Component (an interface or abstract class) with the query operation (countBlack(), getSailorCount(), sail()).
2. Add the Leaf classes.
3. Add the Composite class, aggregating Components (diamond on the composite end, with multiplicity), plus add() if needed.
4. Encode the specific constraints, such as exactly 4 quadrants, or a flagship plus a scout plus 0..* others.
5. Label the pattern and its roles with a note or stereotype.

Markers look for correct component, leaf and composite roles, children typed as the Component, the right multiplicities, the operations present, and the pattern named. 2021 S1 Q9 asked for a design for huge black-and-white images stored as a quadtree: each square region is black, white or outside the image, or is divided into exactly four quadrants (NE, SE, SW, NW), and the query is "how many black pixels?". Both designs below earn full marks.

Check yourselfAn SSD question gives you a class with public operations +select(Product) and +reset() and private ones -price(Product) and -error(). How does each kind appear in your SSD?

The public operations are the external system events: draw them as solid messages from the actor who triggers them (select from the customer, reset from the technician), with the given names and concrete arguments. The private operations are the system's internal work, so draw them as self-calls on the system lifeline (or as notes): price(potatoChips), error(). This is exactly how the official 2021 S1 Q3 answer is drawn (9.5).

Check yourselfIn Q7.3, why does two.eval() come after the whole of uexpr's work, and not interleaved with it?

Because BinaryExpr.eval() computes op.apply(left.eval(), right.eval()) and Java evaluates arguments left to right, each one completely. So left.eval() (that is, uexpr, including its calls to nine and :UMinus) must return −9 before right.eval() starts, and apply runs only after both. Drawing the order wrongly is one of the listed marking points.

Check yourselfA student's Composite DCD has Divided holding four associations to Black. What is wrong, and what is the fix?

The children are typed as a Leaf class, so a divided quadrant could only contain black squares, and never white, outside or further divided quadrants. The whole point of Composite is that the children are typed as the Component (Quadrant or IBWImage), so a composite can hold leaves and composites alike and the recursion works. Point the four associations at the Component.

Past-Exam Map: Key Decisions and Traps exam

Each long question turns on a handful of decisions, and those decisions are where the marks are won or lost. The table gathers them for all twelve long questions of 2021; the diagrams below draw the ones that are easiest to get wrong. The full worked answers are in the topic Parts.

SSDs

2021 S1 Q3, the vending machine. The scenario: the customer gets an error after selecting potato chips ($1.85); a technician fixes the problem and presses the internal reset; the customer then buys the chips with a $2 coin. The question gives the machine's interface as a class, and the key is to read it correctly. The public (+) operations select(Product), insert(Coin), cancel(), reset(), dispensingComplete() and refundingComplete() are the external messages. The private (−) operations available(), display(), price(), value(), error(), dispense() and refundCoin() become self-calls or notes. Step through the official-style answer:

2021 S2 Q5, the fuel dispenser, is drawn in full in 9.4. Its decisions: two actors again, the Customer and the Service Attendant; the external card-payment system either as a supporting-actor lifeline or as a self-call "process payment" (the official answer uses the self-call); concrete values throughout; and both availability results shown, which the official answer does with notes ("has to return false", "has to return true").

Domain models

2021 S1 Q4, tutoring. Six things decide this one: a superclass for the shared personal details, a second level for the kinds of staff, the tutoring association attached to tutors only (attaching it to all staff would break the 100% rule, since admin staff don't tutor), a session class, a derived session count, and how to record that a tutor is senior or junior. The official answer and the guide differ on the last point, and both earn the marks.

2021 S2 Q4, the car saleroom, is drawn in 9.4. Its decisions are the two-level hierarchy (Person → Customer, Employee → SalesRepresentative, Mechanic), transmission as an enumeration attribute (the official answer notes that subtypes would also be accepted), three named associations to Car with 0..1 ends that cover unsold cars, and "favourite car" kept as a plain attribute favouriteCar of Customer, as the official answer does. A second association Customer * Has-as-favourite 0..1 Car is possible, but the attribute is the safe choice; state your assumption either way. The official answer names each association in both directions ("sold by", "owned by", "maintained by").

State machines

2021 S1 Q5, the Mars CO₂ filter. The text: the system monitors regular updates current(co2); above max_co2 it filters CO₂ out until the level reaches max_co2 − upper_threshold; below min_co2 it adds CO₂ until min_co2 + lower_threshold; while running it may detect a fault, reset, and then "continue running as before"; and "at any stage" an emergency shuts it down until safe_restart, after which it returns to "normal monitoring". The garage door (S2 Q8) is drawn in 9.4.

Architecture

2021 S1 Q6, Sportsy (an app for Australian sports clubs). The functional ASR is sentence 4, a detailed record of all financial transactions: auditing/transaction logging, a legal constraint and so the top priority, cutting across fees, purchases, event payments and merchandise (3a, 3d, 3e). The non-functional ASR is sentence 5, usable by diverse users: usability, which suggests several clients and Model-View Separation. Two alternatives are also acceptable: payments (3e) through Adapters to external gateways, or sentence 6, short time to market, a schedule constraint that pushes towards buying or reusing rather than building. The official answer picks the same two, and its memo logs intent and outcome through an Observer to a cloud log server (9.4).

2021 S2 Q6, Doctar (an app for GP clinics). Following the official answer and FURPS+, the functional ASR is sentence 5, secure, confidential storage, because FURPS+ files security under Functional, and the non-functional ASR is sentence 4, per-clinic branding and contact configuration (Supportability: configurability), which implies a multi-tenant product and data-driven configuration. The guide used to classify these the other way round, which contradicted the official answer. Printing prescriptions (3e) is an acceptable alternative functional ASR. Don't pair the doctors-only rules (3d/3e) with S5, because the two overlap. The official memo is on secure storage: an encryption component behind a Façade, with access control left as an unresolved issue. Full answers: Part VIII.

The Java code question

2021 S1 Q7, the calculator, is worked in 9.4: Composite (IExpr Component, BinaryExpr/UnaryExpr Composites, Constant Leaf) plus Strategy (IBinaryOp, IUnaryOp; Plus, Times, UMinus; contexts BinaryExpr, UnaryExpr). In the DCD, left and right are two separate associations to IExpr, each with multiplicity 1 and its own role name, exactly as in the official answer, which also puts * at the source end and draws no constructors. The trace in short:

uexpr.eval() → nine.eval() returns 9
             → UMinus.apply(9) returns −9
             → uexpr returns −9
two.eval()   returns 2
Plus.apply(−9, 2) returns −7
expr.eval()  returns −7

2021 S2 Q7, the musical lineup. Again the patterns are Composite (Component ISound; Duet and Soloist hold ISounds; Leaf Instrument) and Strategy (IDuetMusic with Jazz and Rock; ISoloistMusic with Blues; contexts Duet and Soloist). Because Soloist wraps a single ISound and is itself an ISound, it can also be argued to be a Decorator, so mention this as an aside; the official answer names only Composite and Strategy. This paper said to include inherited methods, so repeat play() in every implementer and playMusic(...) in Jazz, Rock and Blues. The official DCD draws Duet's two fields as one association with multiplicity 2; two role-named lines are equally good. The trace of duet.play() is below. The official diagram's return string says "Classical." by mistake, so trust the code.

duet.play() → Jazz.playMusic(guitar, saxophone)
            → guitar.play()    returns "Guitar"
            → saxophone.play() returns "Saxophone"
            → Jazz returns "Jazz. Guitar melody, Saxophone backing."
duet.play() returns the same string

Composite DCDs

2021 S1 Q9, the quadtree, is drawn both ways in 9.4. 2021 S2 Q9, the fleet: vessels (Ship, Yacht, Ferry) each have a number of sailors and a length and can sail; ships have a name and ferries a passenger capacity; a fleet has an admiral's ship, a scouting yacht and any number of other vessels; the queries are "how many sailors?" and "make the whole fleet sail". The design question is whether Fleet should be a subtype of Vessel.

Check yourselfIn the CO₂ filter, a student draws one Resetting state whose reset complete transition goes back to Monitoring. Which sentence does this violate, and what are the two acceptable fixes?

Sentence 5: after the reset the filter "immediately continues running as before the fault", meaning in the same mode (filtering out or adding in). Going to Monitoring loses that. Fix 1 (guide): reset complete → a shallow history pseudostate H inside Running, which resumes whichever substate was active. Fix 2 (official answer): two reset states, Resetting (out) and Resetting (in), each returning to its own mode.

Check yourselfFor Doctar (2021 S2 Q6), a student classifies "secure, confidential storage" as non-functional. Is that wrong?

Under the convention the official answer uses, yes: FURPS+ files security under Functional, so secure storage (sentence 5) is the functional ASR and the per-clinic branding configuration (sentence 4, supportability/configurability) is the non-functional one. If you use a different convention, state the classification you are using; misclassifying without saying so is a listed mistake (9.8).

Q1 MCQs: All 20 Answers with Reasoning exam

Q1 is 20 marks of pure recognition: each stem describes a design problem, and you write the letter of the pattern that best deals with it. Two of the twenty were reused word for word, and the Week 12 review re-ran eight of them as live polls, so this is the most predictable part of the paper. This section gives you the tools first, a cue-word table and the confusable pairs, and then all twenty questions to try yourself.

Cue words → pattern

The table maps the wording of a question to the pattern that solves the problem it describes. Note that the first row names a problem, Low Cohesion, rather than a pattern you would apply.

Confusable pairs

Most wrong MCQ answers come from a handful of pairs of patterns that look alike. The two most important pairs differ in their structure, so they are drawn below.

The answer key

2021 Semester 1

Try each one before opening the answer. The stems are shortened; the options are in the paper's order.

S1 Q1.1A team leader, Leslie, finds that a new team member, Jessie, has created a class used like this: whenever Jessie is unsure where to put a method, it goes into this class. How does Leslie explain the problem to Jessie?

1. Pure Fabrication
2. Controller
3. High Coupling
4. Low Cohesion
5. Façade

D · Low Cohesion. A class that collects unrelated methods is the definition of low (functional) cohesion: its responsibilities are not related or focused, so it is hard to understand, maintain and reuse. Pure Fabrication is the tempting wrong answer because the class is invented, but Pure Fabrication requires a highly cohesive set of responsibilities, and a grab-bag is the opposite. High Coupling will probably follow, but it is a side effect, not what is wrong with the class itself.

S1 Q1.2An online noodle-soup ordering system: the customer chooses a size, soup type and noodle type, then may add any ingredients from a long list. The system must produce a list of all ingredients, all allergens, a reheating time and a price.

1. Low Coupling
2. Decorator
3. Indirection
4. Factory
5. Observer

B · Decorator. The base soup is wrapped by any number of ingredient decorators. Each implements the same interface and adds its own contribution to getIngredients(), getAllergens(), getReheatTime() and getPrice() before delegating to the object it wraps. Factory is tempting because an order is being "built", but creation is not the problem: adding optional behaviour and data at run time is. Low Coupling and Indirection are general principles, not a solution.

S1 Q1.3A sports-reporting company publishes periodic updates. How can it make the information available to many kinds of consumer, who may only be interested in certain sports or teams and want the information as soon as it is available?

1. Controller
2. Adaptor
3. Observer
4. Façade
5. Composite

C · Observer. This is publish–subscribe. Consumers register with the publisher (a sport or team feed) for the topics they care about and are notified when an update arrives. The publisher knows them only through a listener interface, which keeps coupling low. Adaptor and Façade deal with interfaces and subsystems, not with change notification; Controller handles UI system events.

S1 Q1.4A regulator wants to test the software drivers of autonomous vehicles in one common simulated environment. How does it deal with each driver having been developed with a different interface?

1. Observer
2. Controller
3. Façade
4. Strategy
5. Adaptor

E · Adaptor. The stem says outright that each driver has a different interface. One adapter per driver converts its interface into the common one the simulator expects. Strategy is tempting because drivers are interchangeable "algorithms", but Strategy assumes they already share a common interface; Adapter is what makes them share one. Façade simplifies a complex subsystem; it does not unify many different interfaces.

S1 Q1.5How can a simulation framework make the simulated time-of-day available throughout the framework?

1. Factory
2. Strategy
3. Observer
4. Façade
5. Singleton

E · Singleton. There must be exactly one simulation clock, and every part of the framework needs a global point of access to it: SimClock.getInstance().getTime(). Observer is tempting because time changes, but Observer would push change notifications; the problem here is a single, globally accessible instance.

S1 Q1.6Go Analytics analyses sales for subscribing companies, with different calculations based on different advanced techniques. What analysis a customer gets depends on their membership level: comprehensive for Platinum, much simpler for Silver.

1. Singleton
2. Strategy
3. Façade
4. Observer
5. Adaptor

B · Strategy. The analysis techniques are related, interchangeable algorithms (for example PlatinumAnalysis and SilverAnalysis, both implementing IAnalysisStrategy). The right one is attached to the customer's context, typically chosen by a Factory. Façade is tempting because the analytics are "advanced", but the problem is choosing between algorithms, not hiding a subsystem. Adaptor does not apply: there are no incompatible interfaces.

S1 Q1.7A game engine needs a damage model in which an explosion or fire damages many related targets at once: a building, the people in it, and the objects they carry. How can this be done without making the design too complex?

1. Composite
2. Observer
3. Façade
4. Strategy
5. Adaptor

A · Composite. A building contains people, who contain objects: a part–whole tree. A damage(amount) call on the building forwards recursively to its children, so the engine treats one target and a group of targets the same way. Observer is tempting because of the word "events", but Observer broadcasts a notification to registered listeners; it does not model containment or propagate damage down a hierarchy.

S1 Q1.8Self-guided Co. has proprietary and complex route- and trip-planning subsystems behind its apps. A new system for tourists will use them in limited circumstances: shortest walking directions from a small set of stop-over points to a site chosen from a predefined set.

1. Controller
2. High Cohesion
3. Façade
4. Adapter
5. Polymorphism

C · Façade. The new system needs a simplified, limited interface onto existing complex subsystems: a single point of contact that wraps them. Adapter is tempting, but nothing says an interface must be converted to match an expected one; the aim is simplification, not conversion. Controller handles UI system events.

S1 Q1.9Modular Homes assembles houses from standard rooms. Customers will be able to choose properties (colour scheme, quality of fit-out) that apply to the whole house, to some rooms, or to a single unit such as a cupboard.

1. Composite
2. Information Expert
3. Decorator
4. Singleton
5. Controller

A · Composite. House contains rooms, which contain units: a part–whole hierarchy. setProperty(p) on any node applies to that node and everything below it, so the ordering system treats one unit and a whole house uniformly. Decorator is tempting because the properties sound like "added features", but a decorator adds behaviour to one wrapped object; it does not apply something across a containment tree.

S1 Q1.10A point-of-sale system queries products and prices from a central database over SOAP; a local SQL database now stores them temporarily. The POS must transparently use the remote database when available, or the local one if it can't connect.

1. Controller
2. Singleton
3. Observer
4. Strategy
5. Factory

E · Factory. ambiguous Larman's NextGen POS solves this exact requirement (ch. 36, failover to local services). His solution is "location transparency using service lookup": an Adapter served up from a ServicesFactory, with a smart (redirection) Proxy for reconnection; apart from the proxy, "Adapter and Factory are used." The Week 10 technical-memo example repeats this. Adapter and Proxy are not options, so Factory is the one the course supports: the client asks the factory for an IProductsAdapter and receives the SOAP or the SQL implementation without knowing which. Strategy (D) is the strong alternative, since the two sources are interchangeable implementations behind one interface; choose Factory because the problem is which object the POS gets to talk to, decided by hidden logic, not a family of business algorithms. The official answer confirms Factory.

2021 Semester 2

S2 Q1.1Intelligent Agency is modelling a person who can have multiple characteristics (roles), and whose behaviour changes in different scenarios depending on the role they are playing.

1. Factory
2. Strategy
3. High Cohesion
4. Polymorphism
5. Information Expert

D · Polymorphism. ambiguous official answer; the guide once said B This is the problem GRASP Polymorphism names: when related behaviour varies by type, give the responsibility to the types themselves (here, role types with a common interface), using polymorphic operations instead of conditionals on the role. The guide used to argue for Strategy, because a person switches roles at run time. That is not absurd, but the stem describes no algorithm or policy plugged into a context, only behaviour varying with the role, so the examiners chose the principle. Lesson: "behaviour that varies with type or role" points to Polymorphism; Strategy needs interchangeable algorithms. Factory, High Cohesion and Information Expert don't address varying behaviour.

S2 Q1.2MakeUp Inc.'s web/mobile sales system has one module, MakeUp_RequestHandler, that handles all requests from mobile or browser. It is very complex: besides sales it handles enquiries, the loyalty program and coupon validation.

1. Information Expert
2. Observer
3. Controller
4. Composite
5. Strategy

C · Controller. A textbook bloated controller: one facade controller receives every system event and does the work itself. The Controller pattern's own remedy (Larman ch. 17) is use-case controllers (for example SaleHandler, EnquiryHandler, LoyaltyHandler, CouponHandler) that delegate to domain objects. Information Expert is tempting because delegating to experts is part of the cure, but the question is about how system requests are received and coordinated, which is Controller's job.

S2 Q1.3A machine checks whether beverage containers meet a standard specification, using sensor data. A coder has written several experimental programs that use the data in different ways. How can each program's accuracy be evaluated against a set of tests describing the specification?

1. Strategy
2. Controller
3. Composite
4. Observer
5. Adaptor

A · Strategy. ambiguous Each program is a different algorithm for the same task, deciding whether a container meets the specification. Put each behind a common interface, such as ISpecChecker.meetsSpec(SensorData), and the test harness can plug in each one in turn and run identical tests. Adaptor is the main rival: if the programs had incompatible interfaces you would wrap each in an adapter, but unlike S1 Q1.4 nothing says their interfaces differ. Observer is tempting because of the sensors, but distributing readings is not what is asked. The official answer confirms Strategy.

S2 Q1.4The noodle-soup ordering system again (identical to S1 Q1.2): base soup, any number of extra ingredients, and lists of ingredients and allergens, a reheating time and a price.

1. Adaptor
2. Observer
3. Strategy
4. Decorator
5. Controller

D · Decorator. The same question as S1 Q1.2, with a different letter. Strategy is the extra distractor here: Strategy swaps one algorithm, whereas this problem stacks any number of optional additions.

S2 Q1.5John must add a feature to a rocket company's large system that reports the vibration in the cargo bay at launch. He is trying to decide which part of the code should be responsible for it. How should he start?

1. Information Expert
2. Singleton
3. Polymorphism
4. Composite
5. Observer

A · Information Expert. Information Expert is the basic starting principle for assigning responsibilities: give the responsibility to the class that has the information needed to fulfil it (here, the cargo-bay or sensor objects holding the vibration data). Observer is tempting because of sensor readings, but the question is about assigning a responsibility. Singleton and Composite don't address that.

S2 Q1.6Victoria's state government is headed by one Premier. How can the Premier be represented in the design of a system that models the state government?

1. Façade
2. Factory
3. Strategy
4. Singleton
5. Observer

D · Singleton. Exactly one instance, with a single point of access. Factory or Façade would only matter if creation were complex or a subsystem needed hiding. (In practice Larman would warn against making a domain concept a singleton, because premiers change over time, but the question asks for the pattern that fits "exactly one".)

S2 Q1.7Self-guided Co. again (identical to S1 Q1.8): complex route- and trip-planning subsystems, used by a new system in limited circumstances.

1. Adaptor
2. Singleton
3. Controller
4. Façade
5. Strategy

D · Façade. The same question as S1 Q1.8. Here Adaptor (A) and Controller (C) are the distractors.

S2 Q1.8Great Autos' website: the customer selects a car and a transmission type, then optional customisations (paint colour, engine power, fuel type, roof rack …). From the selections the site must list all features, estimated fuel use and range, price and tax.

1. Decorator
2. Indirection
3. Factory
4. Low Coupling
5. Façade

A · Decorator. Each customisation wraps the base car and adjusts each computed value (features, fuel use, range, price, tax) before delegating. Factory is tempting because a configured car is being created, but the problem is accumulating optional additions. Indirection and Low Coupling are principles, not the solution.

S2 Q1.9Awesome Car Cleaning offers one standard package. It now wants customers to choose hand or machine washing, whether the car is vacuumed, and whether the outside is waxed.

1. Factory
2. Composite
3. Façade
4. Strategy
5. Singleton

B · Composite. ambiguous official answer; the guide once said D The company is replacing one fixed package with a package assembled from individual services: a wash (by hand or by machine), plus a vacuum and a wax if wanted. A cleaning package is a whole made of service parts, and the package and each service can share one interface (getPrice(), perform()), so the system prices or performs a custom package exactly as it would one service. The guide used to choose Strategy, treating each option as an alternative way of performing a step, and argued the selection was flat rather than a tree. That was the wrong call: a one-level part–whole structure is still Composite, and the stem stresses combining services into one package. Decorator would also have suited optional add-ons, but it is not offered; Factory, Façade and Singleton don't address the problem.

S2 Q1.10A tic-tac-toe game has nine buttons for the squares. Pressing one generates an event message that must be handled so the back end records the move. Which pattern makes sure the event is handled correctly?

1. Controller
2. Decorator
3. Factory
4. Strategy
5. Composite

A · Controller. A UI event must be handed to the first object beyond the UI layer, which coordinates the system operation (for example GameController.makeMove(square)), so the UI never updates the domain directly. That is Controller by definition. The other options don't deal with routing UI events.

Short Questions: Model Answers and Templates exam

The two 5-mark questions are the cheapest marks on the paper, because their answers have a fixed shape. If you copy the template onto your notes and fill it in, you can finish each in five minutes and bank the time for the diagrams.

Brief use case template

Use case: <Verb-Noun goal>            (brief format)
Primary actor (human): <role that operates the system>
Supporting actor(s) (non-human): <external system providing a service to the SuD>
Offstage actor (optional): <has an interest, not involved>
<One paragraph: actor's trigger → system responses → supporting actor
 service used → goal achieved.>

Alternate scenario (would be extension Na of the fully dressed form):
<Condition the system can detect>: <handling steps>; <resumes at step N /
 use case ends with ...>.

The template is built to satisfy four rules from Part I:

• A brief use case is a terse one-paragraph summary, usually of the main success scenario (Larman ch. 6).
• The primary actor has their goal fulfilled by using the system, so if staff enter the data on the customer's behalf, the staff member is the primary actor (Larman's point about the cashier versus the customer).
• A supporting actor provides a service to the system, for example "the automated payment authorization service."
• An extension has two parts, a condition and its handling: write the condition as something the system can detect, and say where the scenario merges back or that it ends.

2021 S1 Q2: computer game subscription

A second acceptable extension is: at any time, the System detects it cannot reach the Payment Authorization Service; the System tells the Gamer to try again later, and the subscription is not activated.

The official answer chooses a different use case, a reminder that any sound user goal earns the marks. Its use case is Download a Subscriber-Only Game, assuming the customer is authenticated and has an active subscription. In the main scenario the customer picks a subscriber-only game from the catalogue, the System checks the subscription with an external Subscription Management Service, and on success it enables the download, shows its progress and confirms when the game is ready. In the alternate scenario the check fails because the subscription has expired: the service reports the failure, the System tells the customer access is restricted and offers renewal, and if the customer renews, the check is retried and the use case resumes.

Both answers have a human primary actor, a named external service that visibly does something, and an alternate scenario that fails at that service, is handled, and either resumes or ends. The official one is shorter and states its assumptions on one line. Notice, though, that its assumption ("an active subscription") sits awkwardly with an alternate scenario in which the subscription has expired: if you write an assumptions line, make sure your alternate scenario doesn't contradict it.

2021 S2 Q2: furniture removalist

This scores well because the actors are labelled with their kinds, the goal passes the EBP test (one person, one place, measurable business value), both supporting actors actually appear in the paragraph, the steps contain no UI details, and the extension has a detectable condition, handling and an ending.

The official answer is very close, which confirms both the goal and the exception. Its use case is Book a move service, assuming the customer is authenticated and has given valid contact details. The customer enters the addresses, the preferred date and an estimate of the furniture volume. The System gets an estimated cost from a Pricing Engine, checks mover availability with a Scheduling System, and shows the available time slots and the price. The customer confirms, the System sends a payment request to a Payment Gateway, and once payment is confirmed it finalises the booking and notifies a Dispatch System and the customer. In the exception, the Scheduling System reports that no movers are free on the requested date; the System tells the customer and offers other dates or cancellation, and if the customer picks a new date, availability is checked again and the use case resumes.

"Describe this Java class" template

A "describe this class" answer has seven parts, in this order. The fully worked model answers for S1 Q8 (Singleton Counter) and S2 Q3 (the Strategy ITaxAmount family), with usage code, are in Part VI and Part VII.

1. Pattern. Open with "This class implements the ⟨name⟩ pattern (GoF), a ⟨creational / structural / behavioural⟩ pattern."
2. Problem. Give the pattern's problem statement in one sentence.
3. Solution. Give the pattern's solution statement in one sentence.
4. How this code realises it. Map each pattern role to the code's elements (constructor, static field, interface, implementations).
5. What the class itself does. Describe its behaviour in one or two lines.
6. Application example. Name a concrete system where it would be used, and say why the pattern helps there.
7. Usage code. Write a few lines of Java that compile against the given class, with comments showing the results.

Recognising a pattern from code

For Q7.2 and the describe-class question, look for these cues in the code; each one points to a pattern.

Check yourselfA student's alternate scenario reads: "The user clicks Cancel on the payment screen." Name two things wrong with it.

First, it is written in UI terms ("clicks", "screen") instead of essential, technology-independent style. Second, it has no handling and no ending: an extension needs a condition, what the system does about it, and either where it resumes or that the use case ends. A better version: "The Customer cancels during payment: the System releases the reserved truck and crew, and the use case ends with no booking or charge."

Check yourselfA class implements ISound and has exactly one field of type ISound, whose play() it calls and adds to. Which pattern does the code-cue table suggest, and why might the Composite answer also be right?

One field of the same interface type, called and added to, is the Decorator cue. That is exactly the aside for Soloist in 2021 S2 Q7. But Soloist also sits in a structure where Duet holds two ISounds and Instrument is a leaf, so as part of that part–whole design it plays the Composite role, which is what the official answer names. Mention Decorator as an aside, and lead with the patterns the whole design shows.

Common Mistakes by Artefact exam

Most lost marks come from a short list of repeated slips. The evidence for this list comes from the workshop review slides, the partial solutions, the Workshop 11 worksheet and Larman. For each artefact there is a checklist, and where a mistake is visual, a bad/good pair.

Use cases

• Writing UI or technology details ("clicks the Submit button") instead of essential, technology-independent steps. The Workshop 1 checklist asks: "Is each step technology-independent?"
• Writing a "use case" that fails the Boss, EBP or Size tests, such as Log in, or a manager's approval step written as its own use case (Workshop 2 review).
• Choosing the wrong primary actor: the beneficiary instead of the person who actually operates the system.
• Calling an offstage party a supporting actor, when a supporting actor must provide a service to the system.
• Leaving out the supporting actor when the question explicitly asks for one, or naming one that is never used in the steps.
• Writing a fully dressed template when brief was asked for. It wastes time, and brief means one paragraph.
• Writing an alternate scenario without a detectable condition, or without saying where it resumes or that it ends.
• Mixing steps at different levels of abstraction.
• Focusing on the use case diagram instead of the text, which Larman calls a common novice mistake.

Domain class diagrams

• Putting software artefacts in the domain model, which was the biggest issue in the Workshop 2 partial solution and the Workshop 11 revision slide: visibility modifiers, methods, navigation arrows, data types (String[50], int) and software classes (TransactionLogger, NOSQL DB Adapter).
• Using an attribute where an association is needed, such as "foreign-key" IDs instead of an association line. Larman says to relate conceptual classes with associations, not attributes.
• Drawing associations without names or multiplicities. The official 2021 S2 answer says outright that associations "need to be named" and "cannot be anonymous".
• Leaving out a superclass for shared attributes, or drawing the generalisation triangle at the wrong end.
• Putting data that clearly belongs to one link on a class instead of in an association class. Judge this carefully, though: for the senior/junior tutor in 2021 S1 Q4, the official answer puts Experience : {junior, senior} on the tutor class, so a plain attribute was accepted there.
• Not marking computed values as /derived.
• Skipping a numbered sentence. The project rubric's tip is to make each class and relationship map directly to an element of the description.

System sequence diagrams

• Drawing internal objects. An SSD shows only the actors and the system as a black box, because it visualises a use case scenario, whereas a design sequence diagram visualises software objects (Workshop 3 review).
• Using technical or UI event names instead of events at the level of intention. The Workshop 2 review says the name "shows the intent for the action not the method".
• Leaving out parameters, or missing the concrete values the scenario gives (prices, coins). Dashed returns are good practice, but both official 2021 SSDs leave them out and put the key values in notes instead.
• Forgetting the second actor (technician, attendant).
• Ignoring the operation names provided in the given system interface.
• Drawing a login step when nothing special happens at login. Login can be assumed (Workshop 2 and 3 solutions).
• Using data names that don't match the domain model; the Workshop 2 solution uses the same class and attribute names.
• Drawing alt frames for paths not in the scenario, when an SSD here shows one scenario.
• On return values, note that both t = scheduler(1) written on the call and a separate dashed reply arrow are valid UML (Workshop 3 review). Use whichever the question implies, and be consistent.

Design class diagrams

• Writing a field of class type as attribute text when the question says "show Java attributes as UML associations wherever possible".
• Leaving multiplicities off those associations, or losing a field: two fields of the same type (left and right) need either two role-named lines, as in the official S1 answer, or one line whose multiplicity counts both, as in the official S2 answer (2). Role names are good practice, though the official S2 answer omits them.
• Mixing up realisation (dashed line) and generalisation (solid line), or leaving out «interface».
• Ignoring the instruction about inherited methods (omit or include).
• Leaving out visibility, parameter types or return types. The Workshop 3 checklist covers visibility modifiers, return types, UML syntax and consistency with the domain model.
• Drawing a DCD that is inconsistent with the sequence diagrams: methods must belong to the same classes, with the same parameters and result types (Workshop 3 solution).
• Not underlining static members (Singleton).

Design sequence diagrams

• Leaving out concrete return values when the question explicitly asks for them.
• Using anonymous lifelines when there are two objects of the same class, instead of the variable names from the initialisation code (nine : Constant, two : Constant).
• Sending calls to the wrong object, or in an order different from the code's evaluation order.
• Leaving out activation bars or reply arrows, or using the wrong arrowheads (a synchronous call has a filled arrowhead; a reply is a dashed line).
• Forgetting the starting found message.
• Drawing the construction code when only the call was asked for.

State machines

• Naming states after events or actions ("Press button") instead of conditions ("Opening", "WaitingForCoin").
• Not writing transition labels as event [guard] / action, or placing guards inside states.
• Leaving out the initial pseudostate.
• Handling "at any stage" by forgetting some states, instead of using one superstate transition.
• Not modelling "resume as before".
• Missing self-transitions where the text says "continue waiting".
• Writing overlapping guards, which make the machine non-deterministic.
• Putting implementation detail (method calls, enumerations, code) in a domain-level diagram.
• Using a state machine where behaviour does not depend on state. The lecture says to use them for state-dependent objects with complex behaviour.

Patterns

• Naming a pattern without saying which classes play which roles, when Q7.2 explicitly asks for the elements involved.
• Mixing up Adapter and Façade, Decorator and Composite, Controller and Façade, or Factory and Creator (the confusable pairs in 9.6).
• In a Composite, typing the children as the leaf class instead of the Component interface. Other Composite slips: leaving out the aggregation from Composite to Component, or add() and the recursive operation, and not labelling the pattern when the question says "make it clear which pattern".
• Writing a Singleton without a private constructor or static getInstance(), or overusing it. The Workshop 11 slide warns that its global access causes problems.
• Using Pure Fabrication as an excuse for a dumping-ground class.
• Giving only the pattern name in "describe" questions, when you need the problem, solution, application and runnable usage code.

Architecture

• Picking a "significant" requirement that is a single local feature, with no explanation of its broad structural impact.
• Misclassifying a requirement as functional or non-functional. Know the FURPS+ convention that security counts as Functional, which is how the official Doctar answer classifies it (with branding configurability as the non-functional one), or state the classification you are using.
• Describing architectural analysis without its definition, its purpose (reducing risk, focusing on priorities, aligning with business goals) and its steps: identify and analyse the factors, which produces the factor table, then resolve them, which produces the technical memo.
• Writing a generic technical memo that could fit any system. The memo must name the case's factor and concrete decisions (layers, and patterns such as Adapter + Factory, Proxy and Observer), with motivation that traces each decision back to the factor, real unresolved issues, and alternatives with reasons for rejecting them.
• Mixing up the logical architecture (layers and packages) with deployment or networking concerns. Workshop 10 is explicit: "Not networking / OS considerations".

Spot the errorA domain model has a class Booking with attributes bookingDate, customerID and truckID. What would a marker deduct for, and what should you draw instead?

customerID and truckID are foreign-key attributes: they relate concepts with attributes, which Larman says not to do. Draw Customer and Truck as classes and connect them to Booking with named associations with multiplicities at both ends (for example Customer 1 makes ▸ * Booking). Keep bookingDate as a plain attribute.

Spot the errorA design sequence diagram for expr.eval() has lifelines :Constant and :Constant, and its last arrow is a dashed line labelled apply(-9, 2). Two problems?

First, the two constants are anonymous, so a reader cannot tell which call goes to 9 and which to 2: name them from the initialisation code, nine : Constant and two : Constant. Second, a call is a solid line with a filled arrowhead; a dashed line is a reply. apply(-9, 2) should be solid, followed by a dashed reply labelled -7.

Last-Day Revision Checklist

The day before the exam is for checking, not learning. Check four things: that you can state the key definitions, draw the notation from memory, sketch the pattern skeletons quickly, and run each question-type procedure. Tick through the lists below; anything you can't do in a sentence or a quick sketch is what to revise tonight.

Definitions to state in one sentence exam

• Requirements and use cases (Part I): OOA versus OOD; iterative and evolutionary development, with the UP phases (inception, elaboration, construction, transition) and what inception and elaboration each produce; FURPS+. The use case and the scenario (use case instance), the three actor kinds, the brief, casual and fully dressed formats, essential style, the Boss, EBP and Size tests, and «include» and «extend».
• Analysis models (Part II): domain model and conceptual class, with association, multiplicity, generalisation, association class and derived attribute. The SSD and system event, and the operation contract with its preconditions and postconditions (instances created or deleted, attributes modified, associations formed or broken). Low representational gap.
• Design (Part III): responsibility (doing versus knowing) and RDD; the four kinds of visibility (attribute, parameter, local, global); coupling and cohesion. Since the Week 12 review says they may be examined, also TDD and refactoring, with a few code smells and named refactorings.
• Patterns (Part IV, VI, VII): all 9 GRASP problem/solution pairs: Creator, Information Expert, Low Coupling, High Cohesion, Controller (facade versus use-case controller, and the bloated controller), Polymorphism, Indirection, Pure Fabrication and Protected Variations (variation point versus evolution point). The GoF problem/solution pairs for Façade, Decorator, Builder, Adapter, Singleton, (Concrete) Factory, Composite, Strategy, Observer and Template Method, and how GRASP generalises them (Adapter, for example, is Indirection plus Pure Fabrication, using Polymorphism).
• State machines (Part V): state, event, transition, guard, transition action, nested (super)state and choice pseudostate.
• Architecture (Part VIII): software architecture and architectural analysis (definition and goal), the architecturally significant requirement, and the priority order: inflexible constraints, then business goals, then other goals. The factor-table columns (Factor; Measures & quality scenarios; Variability; Impact; Priority; Difficulty/risk) and the technical-memo sections (Issue; Solution summary; Factors; Solution; Motivation; Unresolved issues; Alternatives considered). The logical architecture, layers, strict versus relaxed layering, and the package diagram.

Notation to draw quickly from memory

• Class diagrams: all 7 relationship lines and which end gets the arrowhead or diamond; multiplicity, role names, navigability, association class, /derived, «interface», underlined static and + - #; name : Type attributes and op(p : T) : R operations (appendix A.1).
• Domain versus design: what to remove in a domain model, and what to add in a DCD.
• SSD: actors, :System, system events with parameters, dashed returns, notes, and loop/alt/opt/ref frames (A.2).
• Design sequence diagram: lifeline name formats, the found message, activation bars, replies with values, create, the self-call, frames, and the singleton 1 marker.
• State machine: initial and final states, event [guard] / action, entry/, exit/ and do/, the superstate with inherited transitions, choice with [else], and history H (A.4).
• Use case diagram: the system boundary, primary actors on the left and supporting actors on the right, and «include» / «extend» (A.3).
• Package diagram with dependencies between layers.

Seven skeletons in under 2 minutes each

Be able to draw these from memory. They are also exactly what belongs on side 2 of your notes.

And the Singleton code, in Larman's preferred lazy form, from Part VI:

public class ServicesFactory {
    private static ServicesFactory instance;
    private ServicesFactory() {}
    public static synchronized ServicesFactory getInstance() {
        if (instance == null) instance = new ServicesFactory();
        return instance;
    }
}

Procedures to rehearse once more

• The 12 question types in the playbook in 9.4.
• One full run from Java code to DCD, patterns and sequence diagram on each 2021 code question, checking the return values against 9.5 (−7, and "Jazz. Guitar melody, Saxophone backing.").
• Each of your 2021 answers against the official answers summarised in the worked sections.
• The Workshop 11 CatchAll exercises against the official partial solution (9.11), since that workshop was built as exam practice.

Check yourselfWithout looking: what are the six factor-table columns and the seven technical-memo sections?

Factor table: Factor; Measures & quality scenarios; Variability; Impact; Priority; Difficulty/risk. Technical memo: Issue; Solution summary; Factors; Solution; Motivation; Unresolved issues; Alternatives considered. (In the exam's 6.2 answer, the five headings that carry the marks are Factors, Solution, Motivation, Unresolved issues and Alternatives.)

What the Week 12 Review Lecture Said exam

The Week 12 lecture, Review & Exam Information, is the only official word on this semester's exam, so it is worth knowing exactly what it said. It summarises the key topics and then answers students' questions. It opens with a disclaimer: the review may not cover every important detail, so don't revise from it alone. Instead, review the lecture slides, the workshop supplementary materials, the workshop exercises, the Tony's Pizza case study and the recommended reading, and aim for a good understanding of the key areas so you can craft the best answer you can in the time. The format facts are in 9.1.

Scope

Asked what topics will be in the exam, the short answer was that all the key topics mentioned in the review can be examined. Here they are, with the Part of this site that covers each.

The long answer to the scope question was that the exam's key focus is the subject's two learning objectives: to "apply the knowledge of modelling and design to solve computing problems" and to "evaluate and apply appropriate choices of software tools in the modelling and design process". Your answers should demonstrate both, which in practice means justifying your modelling and design choices, not just drawing them.

Code. Reading code may come up, and writing code may too, but only as snippets. Coding is not the subject's core focus, but code shows how effective a design is, so you should be able to recognise and produce code structures that relate to design patterns and principles. The code in each pattern section (Parts VI–VII), the code-to-diagram procedures (Part III) and the code-cue table in 9.7 cover this.

The Q&A, question by question

What this means for your preparation

These four points are the guide's own reading of the lecture, not something the lecture said.

1. The 2021 question types in 9.1 are still the best map of the paper, but add the use case diagram as a possible question: the review showed 2018 S1 Q8, "draw a use case diagram" for the Pennand ATM, with its official answer (Part I).
2. The eight MCQs re-polled in the lecture are 2021 S1 Q1.2–Q1.9 (9.6), so pattern-recognition MCQs remain central.
3. Spend less time on component-diagram notation and cloud technology, and a little time on the TDD and refactoring vocabulary.
4. Justify every choice. The focus on "evaluate and apply appropriate choices" rewards saying why: which GRASP principle, pattern or quality attribute motivates each design decision.

Check yourselfA classmate puts a PersistenceFacade class in their domain model "because the system needs to save things". Using the Week 12 Q&A, what do you tell them?

A domain model holds classes that are meaningful to the stakeholders and not related to an implementation. A persistence façade is a software class invented for design reasons, a Pure Fabrication, and the lecture said such a class is never in the domain model. It belongs in the design model (Technical Services layer).

Workshop 11 Revision Case Study: CatchAll exam

Past papers test each artefact on a different scenario. Workshop 11, Getting a Better GRASP on Design, does something closer to what the Week 12 review hinted at: one case study of exam size, modelled end to end. It is the nearest thing in the course to a full practice exam on one case, and the worksheet asks you to draw everything by hand and quickly, with correct notation and your assumptions listed.

The official partial solution, now on Canvas, covers Exercises 1 to 4; it gives no answer to Exercise 5 (start-up). It opens by repeating that your solutions should be hand-drawn and that your models may differ from it, depending on the assumptions you made. Read it as one good answer, not the only one. Everything below is that official solution redrawn, with the guide's notes on what to copy and what not to.

The case

StopEm Enterprise's CatchAll security system is modular. Each Zone Unit covers an area of a building and connects up to 6 sensors, up to 2 cameras and up to 2 flasher/sounders, and a Central Control Unit supports up to 16 zone units. There are three kinds of sensor: infrared detectors, movement detectors, and configurable movement detectors that can ignore most pets. If a sensor in an active zone goes off, every flasher and sounder in every zone is activated and every registered Monitor is alerted through the smartphone app. A Monitor can view and control one camera at a time, reset the alarm, and switch zones on or off. Entering a 6–8 digit code on the app or the keypad starts a countdown, during which active zones beep, and then arms the system; entering it again disarms the system and silences any alarms.

Part B also asks you to use, and point out, four GRASP patterns: Polymorphism, Pure Fabrication, Indirection and Protected Variations.

Exercise 1: domain class diagram

The official domain model has nine concepts plus two abstract sensor classes. Step through it, built up the way you would build it from the text.

Exercise 2: design class diagram

The official design model shows how a domain model turns into a design, and it justifies each change in a note, which is exactly what the worksheet asks for. Compare it with Exercise 1:

• CatchAll System and the Central Control Unit are merged into one class, CatchAll_Central, because the distinction "is not important as they are one-to-one".
• The sensor subclasses disappear: the design does not need to distinguish kinds of sensor, and configurability may be a purely hardware setting, such as a knob on the sensor.
• The enumerated states become booleans with initial values (system_active : boolean = false, is_on : boolean = true), every class gains an id, and visibility and operations appear.

Exercise 3: state machines

The official answer draws two state machines, one per stateful design class, and works at the design level: the events are the classes' operations and the actions are assignments to their attributes. The central unit's machine is simple.

The zone unit's frame contains two independent machines, each with its own initial state: in effect, two orthogonal regions. One tracks arming; the other tracks whether the zone is switched on or off.

Exercise 4: design sequence diagram

The scenario: William is working late in the office; a movement detector sets off the alarm; Jessica is alerted on the app, and she responds in a way that keeps the building secure while letting William keep working. The solution notes that this is really four sequence diagrams in one: the trigger, the alert, the reset, and switching off William's zone while re-arming the rest.

Exercise 5: start-up (no official answer)

No answer is given for the start-up sequence. A reasonable answer, in the guide's suggestion, shows the central unit creating its zone units and monitors, and each zone unit creating its sensors, cameras and flasher/sounders, with create messages inside loop frames (each create arrow pointing at the new object's box, drawn at the height where it is created).

Check yourselfWhy does the DCD make central unit ↔ zone unit and zone unit ↔ sensor navigable in both directions, but central unit → monitor only one way?

Navigability follows the messages. The central unit sends to zone units (reset(), activate()) and a zone unit calls back up to raise the alert; a zone unit resets its sensors and a sensor calls its zone unit when triggered. So both of those links need visibility both ways. Monitors are only ever sent alerts (alert(int)); nothing in the design needs a monitor to call the central unit through that link, so one direction is enough.

Check yourselfIn the domain model the zone unit's state is zone_state : {active, inactive}, but in the design it is is_active : boolean = false. Is either wrong for its level?

No; each fits its level. A domain model uses conceptual attributes, so an enumerated value in the world's own words is right, and there must be no programming-language types. A DCD is a software model, so a Java-style boolean with visibility and an initial value is right there. Neither uses subclasses for states, which is the mistake to avoid at both levels.

Check yourselfFix the official diagram's deactivateZone() message so that it matches the DCD. Which lifelines and which operation?

Jessica acts through the app: Jessica → jessApp (she switches the office zone off), then jessApp → ccu : switch_zone(officeZone, false), the central unit's +switch_zone(zone_unit, boolean) operation, then ccu → officeZone : switch_zone(false), the zone unit's +switch_zone(boolean). Every message is now an operation of its receiver.