Domain Models & System Sequence Diagrams

Analysis and the Domain Model exam

Before you can design software, you have to understand the problem it solves. Object-oriented analysis (OOA) is that step: it investigates the problem and the requirements, and records what it finds in three artefacts. Design comes afterwards and creates a solution. A handy slogan is that analysis is about "doing the right thing", while design is about "doing the thing right".

The three artefacts are not independent; each feeds the next. Everything starts from the use case text (Part I). The nouns in it suggest conceptual classes for the domain model, and the actor steps in it suggest the system events of the SSD. The diagram below traces the flow, following Larman's Figs. 9.1, 10.1 and 11.1.

The domain model supplies the vocabulary of the project: the class and attribute names that SSD parameters, contracts and the glossary all reuse. Later, in design, it also inspires the names of software classes in the domain layer. That keeps the representational gap low (the distance between how people think about the domain and how the code is written; see Part III). The SSDs identify the system operations, and each one becomes a message to a controller object when design starts (Part IV, Controller). The contracts then describe what each system operation does to domain objects.

What a domain model is

In the Unified Process (UP) the term means real-situation conceptual classes, not software objects. A domain model is drawn as a UML class diagram with no operations, seen from a conceptual perspective, and it may show only three things: conceptual classes, the associations between them, and their attributes. Larman calls it a visual dictionary of the domain's noteworthy abstractions, vocabulary and information content. You could write the same information out as glossary text, but a picture shows the relationships far better.

In the UP the domain model is a specialisation of the Business Object Model that focuses on one domain, such as point-of-sale (POS). It is started and mostly finished during elaboration. It is also optional and partial: you model only the concepts that the current iteration's scenarios need, and spend a few hours at most. Aiming for a waterfall-style "complete and correct" model leads to analysis paralysis.

What a domain model is not

Because the model describes the real domain, anything that belongs to the software must stay out of it. This is the single most important rule of the topic, so here is the full list, with a typical mistake and the reason each is wrong.

Check yourselfA classmate's domain model contains a class Episode with - title : String and + makeStreamable() : boolean, and a class NOSQL DB Adapter. List every problem.

Four problems. The - and + are visibility markers, which are a software concept. String and boolean are programming types; write just title. makeStreamable() is an operation, and responsibilities are only assigned in design. NOSQL DB Adapter is a software artefact, not a concept from the streaming domain, so it must go entirely.

Check yourselfWhy does an exam marker give credit to a domain model that differs from the model answer?

Because there is no single correct domain model. A model is judged on whether it captures the essential abstractions for the stated requirements. If your choice differs (say, a class where the answer has an attribute) and you justify it, typically with a short note, it still earns marks.

Finding Conceptual Classes

The boxes of a domain model are conceptual classes, and the hardest part of the exam question is deciding which nouns deserve a box. This section gives you a precise idea of what a conceptual class is, then three techniques for finding them and a special kind, the description class, that beginners almost always miss.

Symbol, intension, extension exam · quotable

Informally, a conceptual class is an idea, thing or object in the domain. More formally, Larman describes a conceptual class by three aspects. They are worth learning word for word, shown here for Sale.

Three strategies for finding classes exam

The category list is a checklist of the kinds of thing that usually turn out to be classes. For business systems, start with transactions, because they involve money and are therefore critical. The examples come from the POS, Monopoly and airline domains.

Noun phrase identification is quick, but mapping nouns to classes is not mechanical, because natural language is ambiguous. The stepper below runs it on the POS Process Sale scenario and shows each of the pitfalls as it arises: synonyms, nouns that are only attributes, software terms, and implicit concepts that the category list has to supply.

Naming and scope guidelines

Check yourselfA library text says: "Patrons borrow books. The system stores each loan in a database and shows the due date on screen." Which nouns become classes, and which do you drop?

Classes: Patron (keep the library's own word: mapmaker), Book, and Loan (a noteworthy event with a time). Attribute: the due date belongs to Loan (and can be derived from the start date and loan duration, as in §2.6). Drop: "system", "database" and "screen" are software terms.

Description classes

Here is a trap the noun list will not warn you about. A description class holds information that describes something else, independently of whether any instances of that thing currently exist. Larman calls this the Item-Descriptor pattern. Its job is to stop information vanishing when the things it describes are deleted.

The same split turns up everywhere once you look for it. A FlightDescription holds the route and flight number, while a Flight is one specific date and time; the routes still exist even if every flight is cancelled. A mobile plan description (the "gold package") is separate from a package that has actually been sold. And in the course's Tony's Pizza case study, a PizzaStyleDescription holds the style name, the prices per size and the standard toppings, whereas a Pizza is an actual pizza added to an order, which the customer may customise with extra toppings.

The case-study video explains each modelling decision, and every one of them is a rule you will meet again in this Part:

• orderNumber is an attribute because it is just a number or string.
• /totalPrice and Pizza /price are derived: a pizza's price comes from its style's price for the chosen size, plus any added toppings.
• Order–Pizza is 0..* because an order may contain only drinks.
• Pizza–Topping is 0..5 because the requirements allow "up to five additional toppings".
• Style is a class, not an attribute. A style has its own attributes (prices) and associations (toppings), so it is too rich to be text.
• deliveryFee [0..1] is an optional attribute, because pickup orders have no delivery fee.

Check yourselfAn airline keeps flight number QF1 (Sydney to London) on its timetable, and also tracks the QF1 that departs on 3 March. Draw the two classes and the association.

FlightDescription {number, plus the route} 1 —Describes— * Flight {date, time}. The route and number belong to the description because they exist even if every QF1 flight is cancelled; the date and time belong to the individual flight. This is the same split as ProductDescription/Item.

Check yourselfWhy is a pizza's style modelled as a class in Tony's Pizza rather than a pizzaStyle : text attribute?

Because of the richness test: the style has attributes of its own (prices per size) and associations of its own (its standard toppings). Anything with its own attributes or associations is too rich to be an attribute and must be a class. pizzaStyle : text is listed among the mistakes markers penalise.

Attributes

Once you have the boxes, you need to decide what goes inside them. Attributes record the plain values the domain needs to remember. Most of the marks in this area are lost through one confusion, between something that is a value and something that is a thing, so that is where this section spends its time.

For example, a POS receipt shows the date and time and the store's name and address, so the model needs Sale.dateTime, Store.name and Store.address. If nothing in the requirements needs a value, leave it out.

Notation

Attributes go in the second compartment of the class box. The full UML syntax is visibility name : type multiplicity = default {property}, but a domain model uses only a small part of it. There are no visibility markers: Larman assumes attributes are private and doesn't draw them, and the course says to remove them.

Attribute or class? The most common mistake exam

Larman's two examples show the guideline at work. Should a sale have an attribute store, or should Store be a class? A store is a legal entity that occupies space, not a piece of text, so it is a class. In the same way, rather than writing Flight.destination, make Airport a class and associate them with Flight Flies-to Airport, because an airport is a huge physical thing.

The converse also holds. If a noun really is just a number or a string with no structure of its own, keep it as an attribute: in Tony's Pizza, an order number and an address string are examples. And Tony's Pizza supplies a second test, the richness test: if the noun has its own attributes or associations, as a pizza style has prices and toppings, it must be a class.

Check yourselfAttribute or class? (a) a student's year level; (b) the school a student attends; (c) a car's paint colour; (d) the pizza style of a pizza.

(a) Attribute: a number. (b) Class, in the guide's tutoring answer: a school is an organisation, not text (the Store/Airport rule). A plain school attribute is also defensible if nothing else about schools is needed, and the official answer uses one, so state your assumption. (c) Attribute: colour is a data type. (d) Class: a style has its own prices and toppings, so it fails the richness test for an attribute.

Data types only; relate concepts with associations

Attribute types should be data types: Boolean, Date/DateTime, Number, Character, String/Text, Time, Address, Colour, PhoneNumber, ZIP/postcode, UPC/SKU, and enumerations such as size : {small, large}. What makes something a data type is that its unique identity is not meaningful: values are compared by value, not by identity. Data-type values are also usually immutable.

It follows that you should relate conceptual classes with an association, not an attribute. In particular, use no attributes that represent foreign keys exam. Attributes such as currentRegisterNumber, customerID and carID are relational-database habits. How a relationship is implemented (a foreign key, a pointer, …) is a design decision, which Larman defers to avoid "design creep". The same goes for an attribute typed by another concept, such as Cashier.currentRegister : Register.

When a "number or string" deserves its own data-type class

Some values look primitive but have structure. Larman's Table 9.3 says to model such a value as a new data-type class if it:

You can show such a type either inside the attribute compartment (itemID : ItemID) or as its own box joined by an association. Both are fine, so choose based on what you want to emphasise. Quantities and units deserve special care: "price = 13" is meaningless without a unit, so write amount : Money (Money is a Quantity whose unit is a currency), or model a Quantity —Is-in— Unit structure.

Check yourselfSpot the errors: Order { orderID : int, customerID, total : 13 }.

int is a programming type (drop it, or use a domain type). customerID is a foreign key: replace it with an association Customer 1 — * Order with a verb-phrase name. total : 13 has no unit; a total is a quantity, so write total : Money, and since it can be computed from the order's contents it should be /total. orderID itself is acceptable, because it identifies the order itself (like employeeID in the car saleroom answer), not another class.

Associations

Classes on their own are a list of words; associations turn them into a picture of how the domain hangs together. The skill is choosing which relationships to draw, then labelling each one fully: a name, a reading direction when needed, and a multiplicity at both ends.

When to show an association exam

Include two kinds. First, "need-to-remember" associations: relationships whose knowledge must be kept for some time, anywhere from milliseconds to years. A Sale must remember its SalesLineItems, or you could not reconstruct the sale or print a receipt; a Piece must remember which Square it is on. Second, associations suggested by the Common Associations List below.

Leave out transient facts. "The dice total indicates the square to move to" and "a cashier looked up a product description" are both true, but neither needs remembering afterwards. And be parsimonious: n classes can have n(n−1)/2 associations, so 20 classes could have 190 lines, and too many lines become visual noise.

Notation and naming exam

The line is plain. An association is inherently bidirectional: you can logically traverse it from either end, so you never put navigability arrowheads on domain associations. The name is capitalised, sits near the middle of the line, and follows the format ClassName-VerbPhrase-ClassName, so it must read as a meaningful sentence: "Sale Paid-by CashPayment", "Player Is-on Square". The reading-direction arrow ▸ or ◂ is a small filled triangle beside the name; it says nothing about navigation or visibility and is optional.

Multiplicity exam

Multiplicity defines how many instances of class A can be associated with one instance of class B, at a particular moment (not over time). To read it, look at the number written next to class B: it answers "for one A, how many Bs?"

The words "at a particular moment" matter. A used car can be resold many times over its life, but at any moment it is Stocked-by one dealer. Likewise Married-to is 0..1 in a monogamous jurisdiction, even though a person may marry several times in sequence.

Check yourselfTranslate into multiplicities: "A club member is enrolled in at least one but no more than four subjects; a subject has any number of members."

Member * —Enrolled-in— 1..4 Subject. The 1..4 goes next to Subject, because it answers "for one Member, how many Subjects?", and the * goes next to Member. This is exactly the course's University Club notation example.

Several associations between the same two classes

Two classes can have several distinct relationships. Each is a separate, separately named line; never merge them into one line with two names.

Roles and role names

Each end of an association is a role, which can have a name, a multiplicity and (in design only) navigability. A role name is a lowercase word at the line end describing the part the object plays: Flight * —Flies-to— 1 City can carry the role name destination at the City end. Use one only when the role is unclear; if you omit it, the default is the class name in lower case. In a design class diagram role names become attribute names (Part III).

There are two ways to model human roles, each with its own advantage, shown side by side below.

Check yourselfA student draws Person ──pays for──▶ Item. Name two separate problems.

(1) The arrowhead is a navigability arrow, a design notation; domain associations are plain lines (a small ▸ beside the name is the only arrow allowed). (2) It skips the intermediate concepts: a person pays for items through a transaction (Sale/Payment) made up of line items, which the category list says to model first. This exact example is on the Workshop 11 revision slide. Also check the name is capitalised with multiplicities at both ends.

Generalisation and Specialisation exam

Many domains contain "kinds of" things: kinds of payment, kinds of staff, kinds of person. Generalisation lets you say what they have in common once, on a superclass, and what is special about each kind on its subclasses. Both past exams opened with exactly this: "for all persons … for students we also … there are two kinds of staff".

Its benefits are economy of expression, less repeated information and better comprehension; later it also leads to software inheritance hierarchies that reduce duplicated code. But remember that these are conceptual classes: "inheritance" is a software mechanism and plays no part in domain modelling, and the conceptual hierarchy may or may not be mirrored in the design.

The relationship has two equivalent definitions. By intension, a superclass definition is more general (more encompassing) than a subclass definition. By extension, thinking of classes as sets, all members of a subclass set are members of the superclass set.

The 100% rule and the Is-a rule exam · quotable

A correct subclass must satisfy both rules. In practice that means an attribute or association that applies to every subclass is placed once, on the superclass, while one that applies to only some subclasses must go down to those subclasses. If only tutoring staff tutor, the Tutors association must attach to TutoringStaff, not Staff.

When to create a subclass exam

A correct partition is not automatically a useful one. Larman's example is Customer split into MaleCustomer and FemaleCustomer: legal, but useless for a POS system. So you also need a motivation.

The flip side is when to create a superclass: when the potential subclasses are variations of a similar concept, they conform to the 100% and Is-a rules, and they share an attribute or an association that can be factored out. CashPayment, CreditPayment and CheckPayment all have an amount and all Pay-for a Sale, so a superclass Payment holds both.

The counter-example: kinds that differ only by a value

The lecture's library text says "Students, staff and guests … the only difference is a different borrowing limit." These user kinds have no extra attributes, no extra associations and no different handling; only the value of the limit differs. So do not subclass.

Don't over-generalise either. Larman's authorisation-transaction example shows that ever-finer levels of subclassing add complexity without improving understanding, so stop at the level that adds value.

Abstract conceptual classes exam

So if a Payment could exist that is none of Cash, Credit or Check, Payment is not abstract. Mark an abstract class by writing its name in italics or adding {abstract}; in handwritten exams write {abstract}, because italics are hard to see. It is worth showing because it constrains which classes can have direct instances, which clarifies the domain rules.

Don't model changing states as subclasses

An object moves between states over its life, but it can never change its class. So states such as "unauthorised" and "authorised" must not become subclasses. Instead, associate the concept with a state hierarchy, or leave states out of the domain model and show them in a state machine (Part V).

Check yourselfA car saleroom text says "a car has transmission type (either automatic or manual)". Subclasses or attribute?

An enumeration attribute, transmission : {automatic, manual}. AutomaticCar and ManualCar would have no extra attributes, associations or handling, so none of the "when to subclass" criteria holds. This is what the official answer does, though it adds a note that subtypes would also be possible, so markers accept them as an alternative.

Check yourself"For all persons we need their name. For students we also need their year level. For staff we also need when they joined." Should Person be abstract?

Yes, if every person of interest is either a student or a staff member: then every member of Person is also a member of a subclass, which is the definition of abstract. Write {abstract} under the name. (The official 2021 S1 answer didn't mark it, so it is correct but optional.)

Check yourselfWhich two rules must every correct subclass satisfy, and what is the quick test for the second?

The 100% rule (the whole superclass definition, all its attributes and associations, applies to the subclass) and the Is-a rule (every member of the subclass set is a member of the superclass set). Test the Is-a rule by saying "Subclass is a Superclass" aloud.

Association Classes, Composition and Other Refinements

Sometimes a plain line cannot say enough. A piece of data may belong to the link between two things rather than to either thing, or a link may be a strong whole–part bond. This section covers those two refinements, then the smaller ones from Larman ch. 31: derived elements, time intervals, qualifiers, reflexive associations and packages.

The problem association classes solve

Authorisation services assign each store a merchant ID, and a store has a different merchantID for each service. Where does merchantID live? Not in Store, because a store has many values. Not in AuthorizationService either, because a service has one per store. The value really belongs to the pair (Store, AuthorizationService), that is, to the association itself.

Larman gives three clues that you need one: an attribute is related to an association rather than to either class; instances of the class have a lifetime dependency on the association; or there is a many-to-many association with information about the association itself. That last one is the classic clue: whenever you see a many-to-many line, look for a lurking association class.

Check yourselfA university records, for each student in each subject, the final mark. A student takes many subjects and a subject has many students; each student takes each subject once. Model the mark.

Student * —Enrolled-in— * Subject with an association class Enrolment {finalMark}. The mark belongs to the pair, not to the student (who has many marks) or the subject (which has many). Because each pair occurs once, an association class is valid. If students could repeat a subject, you would reify Enrolment as an ordinary class instead.

Aggregation versus composition

UML has two kinds of whole–part relationship. Aggregation (shared aggregation) is a vague "whole–part" link to which UML gives no meaning distinct from a plain association; Rumbaugh calls it a "modeling placebo". Composition (composite aggregation) is a strong whole–part relationship with three rules:

1. A part belongs to only one composite at a time.
2. The part must always belong to a composite: there are no free-floating fingers.
3. The composite is responsible for creating and deleting its parts; if it is destroyed, its parts are destroyed or moved to another composite.

Show composition when the part's lifetime is bound within the composite's (a create–delete dependency), there is an obvious physical or logical whole–part assembly, some properties propagate from composite to parts (such as location), or operations propagate (destruction, movement, recording). The benefit is clarity about whether a part can exist on its own; in design it also identifies the Creator, since the composite creates its parts (Part IV), and it signals cascading deletes and copies. Still, leaving composition out of a domain model is not a serious error, and debating aggregation wastes exam time.

Derived elements

A derived attribute or association can be computed from other information. It is marked with a / prefix, as in /total or /quantity.

For example, Sale /total is derived from the line items and product prices, and SalesLineItem /quantity can be derived from the number of associated Items. Tony's Order /totalPrice and Pizza /price are derived. In the tutoring exam question, "the number of tutoring sessions they have been involved in" becomes Student /numberOfSessions, derived from the count of linked sessions. When the exam text explicitly asks for such a quantity, show it, with the slash.

Time intervals

Information is often valid only for a period. Larman uses this to fix an iteration-1 error: if a SalesLineItem used the current price in ProductDescription, changing the price would rewrite old sales. One fix is to copy the price into the line item at the time of sale. A more robust fix keeps a price history, shown on the left below. The library example from the lecture, on the right, has the same flavour: a Loan between User and Item with start and finish dates (or a returned? flag). Because the library tracks the complete history of loans, and the same user can borrow the same item many times, a Loan must be a class. Its due date can be derived from the start and the loan duration.

Qualified and reflexive associations

A qualifier is a small box attached to the class at one end of an association, holding an attribute such as itemID. It selects objects at the far end by that value, which usually reduces the far multiplicity from many to one. In a domain model it communicates how things are distinguished in the domain, not a design decision about lookup keys, so use it sparingly: it easily slides into "design-think". A reflexive association links a class to itself, and role names are essentially required, because otherwise the two ends cannot be told apart.

Packages

Large domain models can be split into UML packages (tabbed folders) such as Domain::Core, Payments, Products and Sales. A class shown in a package that does not own it is written Package::Class. Group elements that share a subject area, sit in the same class hierarchy, take part in the same use cases, or are strongly associated. This is rarely examined for domain models; package diagrams are covered in Part VIII.

Domain-model notation cheat-sheet exam

Finally, how does a domain model differ from a design class diagram (DCD, Part III)? A DCD adds operations, navigability arrows, visibility, software types and software-only classes (controllers, adapters, interfaces), and it may restructure associations into attributes. The appendix draws one of each side by side.

Check yourselfComposition or not? (a) Board and Square in Monopoly; (b) Library and Book; (c) Order and OrderLine.

(a) Yes: each square is part of exactly one board and is created and destroyed with it (Larman's Board 1 ◆— 40 Square). (b) Doubtful: books can be transferred to another library or withdrawn without the library ending, so a plain association is safer ("if in doubt, leave it out"). (c) Yes: transaction line items are parts of their transaction, like Sale 1 ◆— 1..* SalesLineItem.

Check yourselfAn exam text says "we need to know the number of orders each customer has placed". How do you show it?

As a derived attribute Customer /numberOfOrders, alongside the association Customer 1 —Places— * Order it is computed from. The text asks for the quantity explicitly, so show it with the slash rather than leaving it implicit.

The Exam Method: Numbered Sentences → Domain Class Diagram exam · 15 marks

Everything so far comes together in one exam question. You get a short passage with numbered sentences and the instruction: "The passage below describes a … domain. The sentence numbering is provided … Draw a domain class diagram modelling the elements of the description." It is worth 15 marks in both past papers. The project rubric's tip applies directly: each class and relationship should map to an element of the problem description. So the method works sentence by sentence and finishes by ticking off every sentence number.

The eight steps

1. Read every sentence and annotate it. Nouns are candidate classes or attributes; verb phrases linking two nouns are candidate associations. "Kinds of", "types of" or "for all X … for Y also" signal generalisation. "For each [pairing] we need …" points to an attribute of a relationship, an association class. "The number of …" or "total …" signals a derived attribute, and "either A or B" an enumeration.
2. Classify each noun as class or attribute, using the number-or-text rule and the richness test. Merge synonyms; drop out-of-scope and software nouns. Give each class a singular name in the domain's own vocabulary.
3. Build the hierarchies. Put common attributes on the superclass. Check each subclass passes the 100% and Is-a rules and has at least one "when to subclass" motivation; if kinds differ only by a value, use an attribute or enumeration. Mark a superclass abstract if every instance must be one of the subclasses.
4. Place each attribute on the most general class it applies to 100%. Never repeat an inherited attribute in a subclass. Data types only; no IDs that link to other classes.
5. Add associations for each relationship phrase, attached at the most specific class that 100% participates (TutoringStaff, not Staff). Name each with a verb phrase, add a reading direction if the layout is ambiguous, and put multiplicity at both ends, derived from words like "one", "any number", "at least one", "up to five", "more than one". Where the text is silent, choose a reasonable value and note the assumption.
6. Find information that belongs to a relationship. If each pair is linked at most once, use an association class; if the same pair can repeat, or more than two parties are involved, use a reified event/transaction class.
7. Add derived attributes, marked /, wherever the text asks for a computable quantity.
8. Check against every sentence and clean up. Tick off each sentence number. Remove all design notation (operations, visibility, arrows, String/int, foreign keys), and add a note for each assumption.

Worked example A: 2021 S1 Q4, the tutoring domain

The passage, with its sentence numbering:

1. For all persons of interest in the domain, we need to know their name, address, phone number, and date of birth.
2. For students we also need to know their year level, school, and the number of tutoring sessions they have been involved in (see below).
3. For staff we also need to know when they joined our organisation.
4. There are two kinds of staff: Tutoring staff and Admin staff.
5. Tutoring staff members tutor students: we need to track which staff members were involved in tutoring a student and, for each, whether they were a senior or junior tutor.
6. Each time students are tutored by staff members (students may be tutored by more than one tutor at a time, e.g. senior plus junior in training, or second tutor for a large class), we need the date/time, and activity type for that session.

Step through the stepper below. The banner shows the sentence being modelled; the gold outline marks what that sentence added. Sentence 5 is dealt with after sentence 6, because the association class it calls for sits on the session association that sentence 6 creates.

The official answer official answer, released 26/27 Oct

The official answer is simpler than the stepper's model, and comparing the two shows how much detail the 15 marks really need.

It differs in four places, and each of the stepper's choices is still defensible if you say why:

• Senior/junior is an attribute of the tutor, not an association class.
• School is a plain attribute of Student. The School class is fine but not needed for the marks.
• Abstract superclasses are not marked. Marking Person and Staff abstract is correct but optional.
• The student's multiplicity on the session is 1..* (every student has attended at least one session), with * students per session. The stepper reads it the other way: at least one student per session, possibly none per student. Both readings fit the text; the safest answer states its choice in a note.

Check yourselfWhy can't "each time students are tutored … the date/time and activity type" be an association class on Student — TutoringStaff?

Because an association class has exactly one instance per pair of linked objects, and the same student and tutor meet in many sessions. Each session needs its own date/time, so the session must be reified as a full class, TutoringSession, with ordinary associations to both sides.

Worked example B: 2021 S2 Q4, the car saleroom

The second past paper uses the same structure:

1. For all persons in the domain, we need to know their name, address and phone number.
2. For the customer we also need to know their budget, favourite car, and credit score.
3. For employees we also need to know their employee ID.
4. There are two kinds of employees, Sales Representatives and Mechanics.
5. Sales Representatives have a target number of sales per month, and can sell cars. Mechanics have a salary, a certain number of years of experience, and maintain cars in the saleroom.
6. A car has transmission type (either automatic or manual), a paint colour, and specific engine power. A car is purchased by one customer, who can own any number of cars.

The official answer official answer, released 26/27 Oct

The differences from the stepper's model are all matters of judgement:

• Favourite car is a plain attribute of Customer. Has-as-favourite is a defensible reading, but the attribute is safe and needs no long justification.
• Multiplicities. The official answer uses 1 at the rep and customer ends, describing cars that have been sold; 0..1 also covers unsold cars. For maintenance it has each car maintained by 0..1 mechanic, where the stepper has many-to-many; the text doesn't decide this, so either is fine with an assumption.
• No abstract markers and no conceptual data types. Both are correct additions, not requirements.

Check yourselfA new sentence 7 is added: "For each sale we need the date and the price paid." What changes?

Now a Sale transaction class is justified (business transactions are the first category on the list): Sale {date, price : Money} linked to Customer, Car and SalesRepresentative with named associations. It replaces the direct Purchases and Sells lines, since the sale now records who bought what from whom. Without such a sentence, adding Sale would break the mapmaker rule.

Reading the course's notation-reference example (University Club)

The course's notation reference draws a University Club model that shows almost every element the course expects in one diagram. It is redrawn in full in the appendix; be able to name each element:

Common Domain-Model Mistakes exam

These are the mistakes that cost marks. The evidence comes from the Workshop 2 "NetFlicks" critique, the Workshop 11 revision slide, the Tony's Pizza videos and Larman. Use the list as a final check on your own diagram before you hand it in.

1. Design or software elements, which the workshop calls the "biggest issues": visibility markers, methods, navigability arrows, programming types and software concepts (full table in §2.1).
2. Missing association names or multiplicities. The Workshop 11 diagram had two unlabelled arrows into TransactionLogger.
3. Foreign-key attributes, such as personID used to link, or itemID inside another class's box, instead of an association.
4. A complex concept as an attribute (destination, store, pizzaStyle : text), or the reverse: making a plain number or text into a class.
5. Unjustified subclasses: kinds that differ only by a value, states modelled as subclasses, and subclasses that break the 100% rule because an association sits on the superclass.
6. Repeating inherited attributes in subclasses, or leaving common attributes in the subclasses instead of on the superclass.
7. Skipping an intermediate concept. The Workshop 11 example has Person —pays for→ Item, which bypasses the transaction (Sale/Payment) and the line item that the category list says to model first.
8. Weak association names, such as "Has", "Uses" or "Relates-to".
9. Hollow-diamond aggregation everywhere. Use a plain association, or composition only when its three properties hold.
10. Not covering every sentence, or adding things that are not in the text (the mapmaker rule).
11. Leaving out multiplicity bounds the text states, such as "up to five", "at least one" or "1..4".

Mistakes 1, 4, 5, 8 and 9 already have bad/good pictures earlier in this Part. The gallery below shows the remaining ones side by side.

Check yourselfFind five mistakes: Member {+name : String, memberID, kind} with subclasses GoldMember and SilverMember (no attributes), and Member ──Has──▶ Loan with no multiplicities. The text says "gold and silver members differ only in their fee".

1. + is a visibility marker.
2. String is a programming type.
3. GoldMember/SilverMember differ only by a value: replace them with an enumeration such as level : {gold, silver} (and a fee attribute); the existing kind attribute even duplicates them.
4. The arrowhead is navigability; domain associations are plain lines.
5. "Has" is a weak name, and multiplicities are missing at both ends.

memberID on Member itself is fine: it identifies the member, it is not a foreign key.

System Sequence Diagrams exam · 10 marks

The domain model is static: it shows everything at once. Now we turn to behaviour: what the system does in one scenario, seen from the outside. Software must be designed to handle the events that arrive at it, so the first job is to list those events precisely. That is what a system sequence diagram does.

Why draw one

Larman says a system reacts to three things: external events from actors (human or computer), timer events, and faults or exceptions. An SSD makes the system events (input events) explicit, and each one implies a system operation, the system's handler for that event. Taken together, the system operations of all use cases form the system's public interface, which you can draw as a single class System. The 2021 S1 exam's Vending_Machine class is exactly such an interface: its public (+) operations are the system operations.

SSDs feed later work: they are input to operation contracts, to the glossary (for parameter and return details) and especially to object design. Throughout, they describe what the system does without saying how.

Relation to use cases and the UP

An SSD is derived from a use case and visualises one scenario, one path through it, so there is one SSD per scenario. Draw one for the main success scenario of each use case, plus any frequent or complex alternative scenarios, and only for the current iteration; each takes from a few minutes to half an hour. SSDs belong to the UP Use-Case Model and are created mostly in elaboration.

Notation exam

The diagram below is Larman's inter-system version of Process Sale (ch. 32, lecture slide 35), with the system as :NextGenPOS and three supporting actors. The numbered badges are explained underneath.

1. Diagram name. A title, or an sd ScenarioName frame around the diagram. Always name it.
2. Primary actor on the left: a stick figure labelled :Cashier. The colon means an anonymous instance of that role; a named instance such as steve:Customer is allowed but unusual. Other human actors (:Technician) are more stick figures; include every actor who sends an event in the scenario.
3. The system: one lifeline box, :System or a name like :NextGenPOS or :VendingMachine. It is a black box: internal objects never appear. Each lifeline is a dashed line, and time runs downward.
4. Supporting (secondary) actors and other systems on the right, as boxes marked «actor». Inter-system events go from the system to them.
5. System event: a solid line with a filled arrowhead, labelled operationName(parameters); a synchronous message from an actor to the system.
6. Return: a dashed line with an open arrowhead back to the actor, labelled with the returned data. Optional if nothing is returned.
7. Frames: loop [guard] repeats; every loop needs a guard, otherwise it never ends (loop(n) is allowed). alt [cond1] … [else] gives mutually exclusive branches separated by a dashed line; opt [cond] runs only if the guard holds; ref ScenarioName pulls in a separate diagram framed sd ScenarioName.
8. Inline return form: reply = requestApproval(request) on the call is an alternative to a dashed return (Workshop 3 shows both). The external call is drawn as an ordinary synchronous message, an abstraction of whatever protocol is really used.

Three more elements complete the kit: a note (dog-eared box with a dashed connector) for assumptions, state changes and internal behaviour; a self-call from :System back to itself, which is the course convention for essential internal behaviour (explained below); and optional activation bars, which the course notation reference shows.

Naming system events and parameters exam

Name events at the level of intent, not the physical input device or medium, and start each name with a verb, because system events are commands or requests. The workshop review slide puts it this way: "Events should remain abstract/non-technical, show the intent for the action not the method."

Parameters carry the information the system needs, and they use the same names as the domain model. As the Workshop 2 solution says, "If you need a data element which is not present in the domain model, you should go back and add it to that model." Returns are what the actor perceives (a description, total, receipt or balance), abstracted from the presentation medium. And when an interface is given, as with the exam's Vending_Machine class, use its exact operation names and parameter types.

Two things stay out. Don't model login: authentication is assumed unless something special happens, because users rarely log in for just one activity and it clutters the diagram (Workshop 2 solution, Workshop 3 review). And put long explanations in the glossary, not the SSD; what a "receipt" contains is an example.

The exam convention: notes and self-calls exam

A pure Larman SSD shows only events that cross the boundary. But both past exam SSD questions add the instruction: "Include all external method calls, and use notes and/or self calls to describe internal … behaviour essential to the scenario." So in this course an SSD contains three kinds of content, and it is still a black box:

Method: scenario → SSD exam

1. Identify the single scenario and write its name as the title or in an sd frame.
2. Identify the participants. Primary actor on the left; any other human actors; exactly one :System; external systems and devices on the right as «actor».
3. Walk through the scenario step by step. For each action the system must respond to, draw a system event (solid arrow, intent-level name, parameters). For each output the actor perceives, draw a dashed return. For each request to an external system, draw an arrow to that «actor», with its reply dashed.
4. Add essential internal behaviour as self-calls and/or notes, including state changes.
5. Add frames: loop [guard] for "repeat until …", alt/opt for branches the scenario leaves open, ref for sub-flows drawn elsewhere. For a fully specified concrete scenario (as in the exams), draw the path linearly: don't add alt branches the scenario doesn't take, and draw repeated attempts twice.
6. Check that every message crosses the boundary (except self-calls), that names match the given interface or domain model, and that the question's concrete values appear (prices, coin value). Check arrow directions, dashed returns, and a guard on every frame.

Worked example: POS Process Sale (Larman Fig. 10.2, lecture)

This is the standard cash-only Process Sale scenario. Step through it to see each line of the use case turn into a message, or into nothing.

Worked example: Tony's Pizza "Place Order", with a ref frame

The Place Order main success scenario is steps 1–4 followed by "repeat steps 1–4 until done", so those steps sit inside a loop. Alternative 2a, "Customer edits pizza toppings", is a subfunction use case, so it gets its own diagram, pulled in with a ref frame.

sd stands for "sequence diagram" (the video calls it a "sub diagram"). Mermaid can only mark the ref frame with a note, which is why the guide's sketches look different; on paper, draw it as above.

Worked example: Myki Quick Top-up (lecture exercise)

1. Traveller taps Myki card; machine displays balance.
2. Traveller selects the top-up amount.
3. Traveller pays by tapping a credit card.
4. Traveller taps the Myki card again to load the top-up; machine displays the new balance.

Check yourselfA student's SSD for an ATM has the events insertCard(), pressKey(5), pressKey(0), pressOK(). Rewrite them.

These name the physical device, not the intent. At the level of intent: enterCard(cardNumber) (or similar) and withdrawCash(amount), with the amount as a parameter rather than one event per key press. Names start with a verb and use domain-model vocabulary.

Check yourselfWhy are steps 1 and 6 of Process Sale missing from its SSD?

Neither involves the system. "Customer arrives" and "Cashier tells Customer the total" happen between people in the real world, so no event crosses the system boundary and there is nothing for the system to handle.

SSD Exam Questions and Common Mistakes exam

Both past papers set a 10-mark SSD question with the same shape: a machine, a short behaviour description, and one concrete scenario that goes wrong and then right. This section works through both, compares each with the official answer, and ends with the mistakes that cost marks.

2021 S1 Q3: the vending machine (10 marks)

The question gives the system interface as a UML class, Vending_Machine:

Vending_Machine
  - selected : Product
  - state : {waitingForSelection, waitingForCoin, refundingCoin, dispensingProduct, outOfOrder}
  ------------------------------------------------------------------
  - available(Product) : boolean        + cancel() : void
  - dispense(Product) : void            + dispensingComplete() : void
  - display(Product) : void             + insert(Coin) : void
  - error() : void                      + refundingComplete() : void
  - price(Product) : int                + reset() : void
  - refundCoin() : void                 + select(Product) : void
  - value(Coin) : int

Reading the interface. The public (+) operations are the external system operations, each invoked by something outside the system: the customer invokes select, insert and cancel; the technician invokes reset; the dispenser and coin-return hardware invokes dispensingComplete and refundingComplete (it sits outside the controlling system, so it is a non-human actor). The private (−) operations are internal behaviour, drawn as self-calls. price and value return int, presumably cents, so $1.85 is 185 and a $2 coin is 200. error() is private because the fault arises inside the machine.

2021 S2 Q5: the fuel dispenser (10 marks)

No interface is given, so you must invent intent-level operation names and keep them consistent. There are three actors: :Customer (primary, left), :ServiceAttendant (a second human actor whose manual actions are system events) and, on the right, «actor» :CreditAuthorizationService, which makes "the machine processes the payment" visible as an inter-system call (a self-call processPayment(...) plus a note is an acceptable simpler alternative). Internal behaviour (checking the tank level, dispensing, computing the total, printing) is shown as self-calls. The first attempt fails and the second succeeds, drawn in sequence with no alt frame, because the scenario is fully specified. Litres are not given, so the total is shown as litres × $1.60 with an illustrative value.

Check yourselfIn the vending scenario, why must select(potatoChips) appear twice, and why is there no alt frame for a low-value coin?

After reset() the machine returns to its initial state, waitingForSelection, so the first selection is lost and the customer must select again. There is no alt frame because the scenario is fully specified: the coin is $2 and the price $1.85, so the low-value branch never happens. For a concrete scenario, draw the path linearly.

Check yourselfAn interface lists + insert(Coin) and - value(Coin) : int. How does each appear in the SSD?

insert is public, so it is an external call: a solid arrow from the customer to the system, named exactly insert(...). value is private, so it is a self-call on the system lifeline, ideally with its result shown (→ 200) or noted.

Common SSD mistakes exam

1. Opening the black box. Lifelines such as :Sale, :ProductCatalog or :Database belong to a design sequence diagram. As Workshop 3 puts it, "a system sequence diagram visualises a use case, while a design sequence diagram visualises interactions between software objects."
2. Physical, UI-level or implementation names: scan, clickOK, tapCard, pressButton, HTTP POST. Snake_case (as in the workshop solution) is tolerated, but camelCase verbs follow Larman.
3. Not using the given operation names or parameter types when an interface is provided.
4. Missing actors: forgetting a second human actor (technician, attendant). An external device or service may be drawn as an actor, but both official answers show that work as self-calls, so it is optional.
5. Wrong arrow styles: solid lines for returns, returns pointing at the system, or messages to an actor that are really that actor's own actions.
6. Frames without guards, or loops and alts that don't match the scenario; don't use alt for paths the concrete scenario never takes.
7. Mixing several scenarios in one SSD, or not naming the diagram.
8. Showing login or other routine steps that add nothing.
9. Omitting concrete values given in the question (prices, coin value), or the essential internal behaviour the question asks for via notes or self-calls.
10. Inconsistent names with the domain model: parameters whose names don't match its classes and attributes.

Check yourselfAn SSD has a dashed arrow labelled selectFuel(diesel) from :System to :Customer. What is wrong?

Two things. The customer sends the selection, so the arrow must go from the customer to the system; and a system event is a solid line with a filled arrowhead. Dashed lines with open heads are for returns only.

Operation Contracts lower exam priority

An SSD names each system operation but says nothing about what it does to the domain. An operation contract fills that gap: it states precisely which domain objects exist, change and get linked once the operation has run. Contracts appear in the course slides only in the UP artefact diagram, and no past exam asks for one, so know the definition, the sections and the postcondition kinds, and use contracts as a thinking tool for "what must the design achieve?"

The four sections

Postconditions: photographs of the stage

By definition, postconditions describe changes in the state of objects in the domain model. They are observations true after the operation, not actions performed during it. Larman's stage-and-curtain analogy makes this concrete: photograph the stage, close the curtain, run the operation, open the curtain and photograph again. The postconditions are the differences between the two photos. The stepper does exactly that for enterItem(100, 5).

The five kinds of postcondition

Larman lists five kinds, grouped into three categories:

When to write contracts. Only for complex or subtle system operations whose effects are unclear from the use case; Larman's example is an airline addNewReservation. If developers understand the operation without one, skip it; Larman notes that most POS contracts are educational only. To create them: (1) identify the system operations from the SSDs, (2) write contracts for the complex ones, (3) describe their postconditions using the five kinds.

Two examples

The POS contract for enterItem, the one the stepper photographed, written out in full:

Contract CO2: enterItem
Operation:        enterItem(itemID : ItemID, quantity : integer)
Cross References: Use Cases: Process Sale
Preconditions:    There is a sale underway.
Postconditions:   - A SalesLineItem instance sli was created.            (instance creation)
                  - sli was associated with the current Sale.            (association formed)
                  - sli.quantity became quantity.                        (attribute modification)
                  - sli was associated with a ProductDescription,
                    based on itemID match.                               (association formed)

And an exam-style contract written against the tutoring domain model from §2.7:

Contract: recordTutoringSession
Operation:        recordTutoringSession(dateTime, activityType, students, tutorsWithRoles)
Cross References: Use Cases: Record Tutoring Session
Preconditions:    The students and tutoring staff involved are known to the system.
Postconditions:   - A TutoringSession ts was created.
                  - ts.dateTime became dateTime; ts.activityType became activityType.
                  - ts was associated with each Student in students.
                  - For each (tutor, role) in tutorsWithRoles, a TutorParticipation tp was
                    created linking tutor with ts, and tp.role became role.
                  (Student./numberOfSessions is derived, so no postcondition updates it.)

Link to design. Postconditions tell the designer which objects must be created and linked, which feeds the GRASP Creator and Information Expert decisions (Part IV). "sli was created and associated with the Sale" suggests that Sale creates SalesLineItem.

Check yourselfFix these postconditions for makePayment(amount): "Create a Payment. Set its amount."

Past tense, passive, named instance, and don't forget the link: "A Payment instance pmt was created. pmt.amountTendered became amount. pmt was associated with the current Sale." The original is written as actions (imperative) and forgets the association, the most common mistake.

Check yourselfWhy does the tutoring contract have no postcondition updating /numberOfSessions?

Because it is a derived attribute: it is computed from the student's linked sessions. Forming the link between the session and each student already changes the count, so stating it separately would be redundant.

One-Page Summary for Your Notes Sheet

You may take two double-sided A4 pages into the exam. This is the material from this Part that earns its place on them.