Object Design: Interactions, Classes & Code

Where Object Design Fits

By the end of Part II you know what the system has to do: the use cases, the domain concepts, the system operations and their contracts. None of that says what the software looks like inside. Object design fills that gap. It moves us from the problem to the solution space, deciding which software objects exist, what each one is responsible for, and which messages they send each other.

Analysis, design, implementation

The lectures separate three activities. Analysis investigates the problem and the requirements; it is about making the right software, and object-oriented analysis finds and describes the concepts in the problem domain. Design is a conceptual solution that meets those requirements, and object-oriented design means "defining software objects and their collaboration". Implementation is the concrete solution: code in an OO language such as Java.

Four models: static and dynamic, analysis and design

Analysis and design each produce two kinds of model. A static model shows what exists (classes and how they relate); a dynamic model shows what happens over time (who sends which message). That gives four models, and the design pair in this Part are the software-class counterparts of the domain pair you drew in Part II.

What object design starts from

Object design does not start from a blank page. Every artefact from the earlier phases feeds it something specific, and knowing which artefact gives what tells you where to look when you are stuck.

The course concentrates on the application logic (domain) layer. Object design of that layer looks much the same whatever the technology, whereas the user-interface and persistence layers depend more on the technology chosen (see Part VIII on layers).

Three ways to go about design

Larman (ch. 14) notes that developers design in one of three ways. The course takes the middle one, with the proviso that a drawing must be worth the time it costs.

Static vs Dynamic Design Models, and Responsibilities exam

A class diagram on its own looks like a design, but it cannot tell you how anything works. This section explains what each design model captures, why you need both, and why most of the real decisions happen in the dynamic one.

Why the dynamic model matters most

Drawing an interaction diagram forces you to decide exactly which message to send, to whom, and in what order. Those are the real design decisions, and they are where you apply the GRASP principles of Part IV. Larman calls this the point where "the rubber hits the road". Novices tend to think the class diagram is the important one, and Larman lists drawing only class diagrams as a common "worst practice". His guideline is to spend significant time on interaction diagrams, not just on class diagrams.

Two views of one design

The DSD and the DCD are not two separate designs; they are two views of the same design, so each one pins down part of the other. That is why the agile modelling practice is to create several models in parallel: a few minutes on an interaction diagram, a few minutes on the related class diagram, and repeat. If you are sketching on walls, use one wall for each, side by side.

1. Every lifeline in a DSD is an instance of a class in the DCD (lineItems[i] : SalesLineItem is an instance of SalesLineItem).
2. Every message to a lifeline is an operation of that lifeline's class, with the same parameters and return type (getSubtotal() becomes +getSubtotal() : Money).
3. Every message needs visibility from sender to receiver, and the DCD records it as an association (attribute visibility, as here) or a dependency (parameter, local or global visibility). See 3.8.

Workshop 3 discussion questions

These four questions from Workshop 3 are good short-answer material. Try each before opening it.

Practical guidance: UML as sketch

Larman's approach is agile modelling, or "UML as sketch": you model to understand and communicate, not to produce documentation, so use whiteboards and model with other people. For a three-week iteration, spend a few hours (at most a day) near the start drawing UML for the hard parts, then code, and expect the code to diverge from and improve on the sketches. If you use UML tools, prefer ones that can reverse-engineer code into both class and interaction diagrams.

A text-based alternative that groups use in "what-if" sessions is the CRC card (Class–Responsibility–Collaboration): one index card per class, listing its responsibilities on the left and the classes it collaborates with on the right.

Responsibilities and responsibility-driven design

How do you decide which object does what? Responsibility-driven design (RDD) treats software objects like people who have responsibilities, "the obligations or behaviours of an object in terms of its role", and who collaborate to get work done. Responsibilities come in two kinds.

A responsibility is not a method. It is an abstraction, and methods fulfil it, either on their own or by collaborating with other objects. In the point-of-sale example, Sale knows its total becomes Sale.getTotal(), and Sale creates SalesLineItems becomes Sale.makeLineItem(...). To fulfil the first, getTotal collaborates with SalesLineItem.getSubtotal(), so Sale needs a collection attribute, List<SalesLineItem> lineItems, to keep attribute visibility to all its line items.

The link runs the other way as well. Drawing a message in a DSD is assigning a responsibility. If you draw :Sale sending create(cashTendered) to :Payment, you have decided that Sale is responsible for creating Payments. Choosing such assignments well is the subject of GRASP in Part IV.

Design Sequence Diagrams: the Notation exam

The design sequence diagram is the main dynamic design model, and the exam expects you to both read and draw one. If the notation is shaky you lose marks even when the design is right, so this section goes through it one element at a time. For a one-page summary, see the appendix.

SSD versus DSD

A DSD looks like the system sequence diagram from Part II, but it answers a different question. The SSD treats the system as a black box and asks "what events does the actor send it?". The DSD opens the box and asks "which software objects, sending which messages, carry out one of those events?".

The usual workflow is to draw one DSD per system operation in the SSD. For Process Sale that means four diagrams: makeNewSale, enterItem, endSale and makePayment.

Lifeline boxes: who takes part

Each participant is a box at the top with a lifeline running down from it. The lifeline is dashed by convention (UML 2 also allows solid), and time runs from top to bottom along it. The text in the box says exactly which object the lifeline stands for, and there are several forms to recognise.

Messages

A message is a call from one object to another, drawn as a horizontal arrow from the sender's lifeline to the receiver's. Its label has a full syntax, but most of it is optional: you may leave out the type information when it is obvious, and the parentheses when there are no parameters. Java-style syntax is acceptable too.

Different kinds of message, and the bar that goes with them, have different drawings. The figure shows all of them in one small interaction.

1. Found message. It starts at a filled black ball, meaning the sender is unspecified or outside the design. The course notation sheet calls it the "System Trigger". In a DSD it is usually the system operation from the SSD.
2. Synchronous message (a normal call): a solid line with a filled arrowhead, labelled with the message expression. The sender waits until the call returns.
3. Self message: an arrow from an activation back to the same lifeline, with a nested activation bar, here clear(). In code it is this.clear(), often a private helper.
4. Asynchronous message: a solid line with an open (stick) arrowhead; the sender does not wait. Careful when reading diagrams: sketchers often use stick arrows for ordinary synchronous calls too, so don't trust the arrowhead shape alone.
5. Execution specification bar (activation bar): a thin rectangle on the lifeline for as long as the method is on the call stack, its "focus of control". Bars are optional in UML, but the course diagrams use them, nested for self-calls.
6. Active object: a box with double vertical lines on its sides, for an object running its own thread (more below).

Returns: two legal ways exam

A call often hands a value back, and there are two equally legal ways to show it.

Workshop 3 asked whether "Time = Scheduler(1)" or "a call Scheduler(1) with a dashed reply Time" is correct. Both are correct. One exam instruction changes the choice, though.

Creation and destruction

Objects are not all there from the start; some are made during the interaction. To show creation, send the creating message to the new object's lifeline box, drawn at the height where it is created rather than at the top. The UML idiom for the message is create(...), though new or any other name is legal. In Java a create message means new plus a constructor call.

UML mandates a dashed line with a filled arrowhead for creation, but many authors draw it solid (as the course sheet does, with senderObject = create(sender)), and either is understood. Destruction is a «destroy» message and a large X that ends the lifeline. Java has garbage collection, so you rarely need it, but it is a way to stress that an object is no longer usable, such as a closed database connection.

Frames: control flow exam

A sequence diagram on its own is a straight line of calls. Frames (UML's "combined fragments") add loops and conditions. Each is a box around part of the diagram with an operator in the pentagon at its top-left, and each matches a Java construct.

public double getTotal() {          // in Order
    double total = 0;
    for (OrderLineItem li : lineItems) {
        double subtotal = li.getTotal();
        total += subtotal;
    }
    return total;
}

boolean result = service.sendMessage(...);
if (result == true) {
    successResponse();
} else {
    failureResponse();
}

public void doOne() {               // in A
    if (x > 0) {
        for (int i = 0; i < n; i++) {
            myB.doTwo();
        }
    }
}

A few rules govern how frames are written. The guard is a [boolean expression], placed over the lifeline whose state it tests. Every loop needs a condition, as Tony's Pizza stresses, so write something like loop [for each line item] or loop [i < lineItems.size]. Frames can be nested. The UML 1 style for a single conditional message, [color = red] calculate, is not legal UML 2, but it is acceptable in quick sketches.

Title your diagrams, which Tony's Pizza also stresses. Use an sd frame (for example sd Add pizza to order), and name a diagram whenever you want to refer to it from a ref. And how much detail should a DSD have? The Week 12 review lecture answered that it should reflect how the code works; if it gets too large, break it into parts with ref frames.

Iterating over a collection

Looping over a collection is so common that it has two standard drawings. Both mean the same Java.

for (SalesLineItem li : lineItems) total.add(li.getSubtotal());   // either drawing

Static methods, singletons, polymorphism, async

Static (class) method calls have no instance to send to, so the message goes to the class itself: a lifeline labelled «metaclass» Calendar. Singletons are drawn as an ordinary lifeline with a 1 in the box's corner, meaning the object is reached via X.getInstance(), which is global visibility (3.8).

Polymorphic messages are calls where the receiver's concrete class decides which method runs. There are three ways to draw them, depending on the source and on what the question tells you.

Asynchronous calls and active objects. An asynchronous call is a stick-arrow message. An active object runs its own thread, and its box has double vertical lines on the left and right (an active class is drawn the same way in a class diagram). In Java, Thread t = new Thread(new Clock()); t.start(); invokes Clock.run() asynchronously; the Thread overhead is usually left out of the diagram.

The course notation reference sheet

The course's own DSD notation sheet uses a messaging back end as its example, and you should be able to recognise every element on it: the lifelines :MessagingController (unnamed) and senderObject : User (with an object name); the system trigger (found message); method invocations; the self-call processRequest(...); the object creation senderObject = create(sender); the implicit return result = saveMessage(...); the explicit return (the dashed result); and a loop frame and an alternative frame with guards. It is redrawn below with Larman's loop and alt keywords.

The sheet draws all of this as one wide diagram. To keep the text readable it is redrawn here in two parts: the controller's view, then a zoom into what the service does when its sendMessage arrives (the second part starts with that message as a found message, exactly as Larman draws a separate diagram for a sub-interaction).

Worked example: Lucky 7 exam-style

The lecture exercise ties all this together. Use case: "Player plays a game by rolling 2 dice. System presents the outcome: win if the face values total 7, otherwise lose." In the SSD, :Player sends play to :DiceGame, which replies outcome, and the domain model has DiceGame 1 —includes— 2 Die (faceValue). Step through the lecture's DSD solution and watch each message become one line of Java.

For completeness, here is Die. Its DCD, together with DiceGame's, is in 3.5.

public class Die {
    private int faceValue;
    public void roll() { faceValue = (int) (Math.random() * 6) + 1; }
    public int getFaceValue() { return faceValue; }
}

Communication Diagrams

A sequence diagram eats horizontal space: every new object needs its own column on the right. A communication diagram shows exactly the same interaction, but as an object graph: objects can go anywhere on the page, joined by links. Because position no longer shows the order of messages, sequence numbers do instead.

The notation

The elements are few, and most of them are about how the numbers are written:

• A link is a plain line between two objects. It is an instance of an association, and it means navigation (visibility) exists. All messages, in both directions, flow along one link, rather than one line per message.
• A message is written seq: message(args), with a small arrow beside the link showing its direction.
• The first (starting) message is not numbered. Numbering it is legal, but Larman's guideline is not to, because it complicates all the numbers below it.
• Nesting is shown by prepending the number of the incoming message: 1: msg2, 1.1: msg3, 2: msg4, 2.1: msg5, 2.2: msg6.
• A self message travels along a link that loops back to the same object, for example 1: clear.
• Creation is a message such as 1: create(cashier) to the new object. Optionally tag the object {new}, or, if the message has a non-obvious name, stereotype it: «create» 1: make(cashier).
• A conditional message is written 1 [color = red] : calculate. Mutually exclusive paths are lettered, as in 1a [test1] : msg2 and 1b [not test1] : msg4, and their nested messages become 1a.1 and 1b.1.
• Iteration is written 1 * [i = 1..n] : num = nextInt, or just *. Over a collection, send 1 *: st = getSubtotal to lineItems[i] : SalesLineItem.
• Static calls, polymorphism and async work as in sequence diagrams: a «metaclass» box, separate diagrams for each polymorphic case, and a stick arrow for async.

The same interaction, both ways

The best way to see that the two diagrams are equivalent is to draw one interaction twice. Here is Larman's NextGen enterItem. The sequence diagram shows order by position; the communication diagram shows it by the numbers 1, 2, 2.1, 2.2.

The course's communication reference sheet

The course has a communication-diagram version of the messaging back end too. Its numbering, though, differs from Larman's: it numbers the found message (1*, the * marking a looping operation) and uses flat numbers 2, 3, 4, … for the service's calls. (Its 7.1b guard is printed as true, clearly a typo for false.) Use Larman's nested scheme if asked. Applied to this example it gives the diagram below.

Sequence or communication?

The two kinds of interaction diagram trade off against each other: sequence diagrams win on reading the order, communication diagrams on space.

Design Class Diagrams: the Notation exam

The DCD is the static half of the design: the blueprint a programmer types the class definitions from. Every Q7 starts with one, and markers check its notation strictly, so this section covers every element you may need to draw or read.

The class box

A class box has three standard compartments: name, attributes, operations. You may add user-defined compartments, such as "exceptions thrown" or "responsibilities". An ellipsis "…" means "more elements, not shown", whereas a blank compartment conventionally means "no members".

The two syntaxes to memorise are these:

• Attribute: visibility name : type multiplicity = default {property-string}, e.g. - quantity : Integer, middleName : String [0..1] (may be null), - MAX : Integer = 6 {readOnly}, and /total (derived).
• Operation: visibility name(parameter-list) : return-type {property-string}, e.g. + getPlayer(name : String) : Player {exception IOException}. UML 2 officially dropped the return type, but Larman says to assume the version with a return type. Java syntax is also allowed if you tell the reader.

The visibility markers map directly onto Java's access modifiers.

When no marker is shown, the defaults are that attributes are private and operations public. As Tony's Pizza puts it, "in design, attributes are generally private and methods are generally public". Several more conventions are worth knowing:

• Return types are types, not values. Write +pay() : boolean, never +pay() : success, and write void when nothing is returned.
• Static (class-level) attributes and operations are underlined, e.g. getInstance().
• An abstract class or operation has an italic name, or {abstract}, which is handier when drawing by hand. The course sheet writes «Abstract» above the class name, which is understood.
• {leaf} means final (cannot be overridden) and {readOnly} means constant. {ordered} and {unique} are properties of a collection, and user-defined property strings such as {List} are allowed.
• Constructors are shown as «constructor» SalesLineItem(desc : ProductDescription, qty : Integer), but they are often omitted because they follow from create messages. Getters and setters are usually omitted too: they are noise.
• A method body can be shown in a UML note stereotyped «method», although this mixes dynamic detail into a static diagram.

Attributes: text or association line? exam

A field whose type is another class can be drawn two ways, and both mean exactly the same Java field. The choice is about readability. Larman's guideline is to show data types as attribute text and attributes of other (non-data-type) classes as association lines, which make the connection visible. Data types are things whose identity doesn't matter: Boolean, Date/DateTime, Number/int, String, Time, Address, Color, PhoneNumber, ZIP code and enumerations.

Collections work the same way: either text with a multiplicity, or a line to the element class with the multiplicity at its end and, optionally, {ordered, List}.

Relationship lines exam

Workshop 11 warns that markers "will not be guessing or inferring" whether an arrowed line means navigation or inheritance. Both the line style (solid or dashed) and the arrowhead (open, hollow triangle, diamond) must be right. Here is every relationship with its Java meaning.

Interfaces

An interface is a class box with the keyword «interface» above the name. It holds operations only, since Java interfaces have no instance fields, and those operations are public. An implementing class is joined to it by a realisation: a dashed line with a hollow triangle, from the class to the interface. Two shorthands also exist: lollipop notation (a circle on a stick: the class provides the interface) and UML 2 socket notation (a half-circle: the class requires it). A plain dependency line pointing at an interface also shows that a class requires it.

Generalisation and abstract classes

In a DCD, generalisation means OO-language inheritance; in a domain model it only meant subset/superset of concepts. In a subclass box, list an inherited operation only if the subclass overrides or implements it; Larman's polymorphism figure, for instance, lists authorize() in both CreditPayment and DebitPayment. Exam questions may override this convention (see 3.11), so read the instruction.

Dependency exam

One class can depend on another in several ways: it may have an attribute of the supplier's type; send a message to a supplier (via an attribute, parameter, local, global or static method); receive a parameter of the supplier's type; or the supplier may be its superclass or an interface it implements. Attributes, superclasses and interfaces already have their own lines (association, generalisation, realisation), so don't add a dependency line on top of those.

public class Sale {
    public void updatePriceFor(ProductDescription d) {
        Money p = d.getPrice();   // parameter use
        // ...
    }
}
public class Foo {
    public void doX() {
        System.runFinalization(); // static call
    }
}

The course sheet's LoanService ⇢ Customer «Uses» and LoanService ⇢ Account «Uses» illustrate the same guideline: createLoan(customer : Customer) takes a Customer parameter and then gets that customer's Account into a local variable.

Composition versus aggregation

Composition (filled ◆) is a strong whole–part relationship with three properties: (1) a part belongs to only one composite at a time; (2) a part must always belong to a composite; and (3) the composite is responsible for creating and deleting its parts, so if the composite is destroyed, so are its parts. Larman's guideline is to use it when appropriate, as in Board ◆ Square, Sale ◆ SalesLineItem and Hand ◆ Finger, and not to name it, since it is implicitly "has-part". Tony's Pizza uses it for Order ◆ OrderLineItem and OrderLineItem ◆ Pizza.

Aggregation (hollow ◇) is a vague "has-a". UML gives it no distinct semantics, and Rumbaugh calls it a "modeling placebo", so Larman's guideline is don't bother using aggregation: use a plain association or composition. The course does use it, though: Tony's Pizza has Pizza ◇ PizzaStyleDescription and Pizza ◇ Topping, because a style or topping "has a life of its own", and the course sheet has LoanService ◇ Loan.

Other DCD notation

The remaining notation is less central but can turn up in a question.

• A constraint is text in braces, inside the box or in a note, possibly in OCL: size : Integer {size >= 0}, {post condition: new size = old size + 1}.
• A qualified association has a small qualifier box on the source end holding the key: ProductCatalog [itemID] → 1 ProductDescription is a Map<ItemID, ProductDescription>.
• An association class is a class box joined by a dashed line to the association: Company *—Employs—* Person with Employment {salary, startDate}.
• A singleton class has a 1 in the top-right of the name compartment, and an underlined instance and getInstance(). ServicesFactory (Part VI) is one.
• A template (generic) class has its parameter in a dashed box on the corner, bound as ArrayList<T→Square> or Java-style, squares : List<Square>.
• An enumeration has the «enumeration» keyword with its literals listed; State {Open, Locked, Closed} becomes an enum.
• An active class has double vertical lines on its sides: it runs its own thread (implements Runnable).
• A keyword is a textual adornment categorising an element, such as «interface», «actor», {abstract} or {ordered}; when sketching, <interface> or <I> are fine. A stereotype is a refinement of a modelling concept defined in a UML profile, shown in guillemets, and may declare tags, as in «authorship» author = "craig".
• A property string has the form {name1=value1, name2}, e.g. {abstract, visibility=public}. A package-qualified name is java.awt::Font (official) or java.awt.Font.

The course DCD reference: Online Banking

The course's DCD notation sheet uses an online banking system. You should be able to recognise and reproduce each element on it: an enumeration, two abstract classes, all three common visibility markers, a static attribute and method (underlined), a derived attribute, generalisations, navigable associations with multiplicities, a composition, an aggregation, two «Uses» dependencies, and an interface with two implementations.

Lucky 7's DCD

The lecture's solution gives DiceGame the attributes - die1 : Die and - die2 : Die and the operation + play() : boolean, and gives Die - faceValue : int, + getFaceValue() : int and + roll() : void, joined by the association "includes" with multiplicity 1 → 2. The slide shows the dice both as attribute text and as an association line, which Larman calls legal but redundant.

From Domain Model to DCD exam

You rarely draw a DCD from nothing: it grows out of the domain model, which keeps the representational gap low. But almost every element changes on the way from the conceptual perspective to the software one, and mixing the two styles is one of the commonest ways to lose marks. The row to remember is operations: that is the main difference.

Workshop 3 illustration. The domain model has Subject (name, subjectCode) 0..4 —taking— 0..* Student (name, studentNumber). The equivalent design classes add types and visibility and gain operations, here + quit(subject : Subject) : void.

The procedure (Tony's Pizza, week 3a)

1. Pick the classes the current use case needs. For add pizza to order: Order, Pizza, PizzaStyleDescription and Topping. Keep the domain names, so the representational gap stays low.
2. Add visibility and types to the attributes (generally private), and drop attributes this use case doesn't need; Topping's stock level, for example, belongs to inventory.
3. Firm up loose attributes. A fixed set of options becomes an «enumeration» (PizzaSize). A key-to-value lookup becomes a Map (pricing : Map<PizzaSize, Double>).
4. Add classes the domain didn't have, such as an OrderLineItem to hold a quantity on the Order–Pizza relationship: the "line item" pattern for putting attributes on an association.
5. For each association decide its navigability (who holds the reference), its rolename (the field name), its multiplicity at the target, and whether it is composition or aggregation. A many-multiplicity means a collection field, an ArrayList in Java.
6. Add methods (responsibilities), such as Order.addPizza(style, size) and Order.getTotal() : double. Use DSDs to discover and check them.
7. Walk a scenario through the classes (computing the order total, say) to check every needed method and link exists. That walk is a DSD.

Two details of this DCD are worth noticing. Pizza keeps addedToppings apart from its style's includedToppings because the price is the base price for the size plus the cost of each added topping. And strictly, enum literals are shared values, so composition (exclusive ownership) to PizzaSize is questionable; Tony's Pizza draws the enum as a composition line, but Larman would write -size : PizzaSize as attribute text, since enums are data types.

Workshop 3, Part 1 Q2: "what assumptions did you make, and where would you get that data?" Typical assumptions concern data types, visibility, which class owns which responsibility, navigability and collection types. The data can come from the use case text and other requirements, the supplementary specification, the glossary, stakeholders and domain experts, existing systems or code, and technical constraints.

Worked example: the matching DSDs

Here are the two Tony's Pizza DSDs that must agree with the DCD above. One detail shows the iterate-until-consistent loop of 3.7 in action: the DCD video first declared addPizza(...) : void, but the DSD video returns the new line item, so the DCD was updated to return OrderLineItem. Message names, parameters and return types must match the DCD.

Keeping the DSD and DCD Consistent exam

Because the DSD and DCD are two views of one design, markers check that they agree. The Workshop 3 partial solution requires that across all diagrams methods belong to the same classes, with the same parameters and result types, and the rubrics for both projects reward design models that are "consistent with the code". This checklist catches almost every inconsistency.

1. Every lifeline's class appears in the DCD.
2. Every message to a lifeline is an operation of that receiver's class (or one it inherits), with matching parameters and return type.
3. Every message implies visibility from sender to receiver. In the DCD it must be an association (attribute visibility, navigable toward the receiver) or a dependency (parameter, local, global or static).
4. Every create message corresponds to a constructor, which can be shown as «constructor».
5. The SSD's system operation is the DSD's starting message, and an operation of the receiving (controller) class.
6. Iterate: changing one diagram usually forces a change in the other.

Visibility Between Objects exam

Every arrow you draw in a DSD hides a practical question: how does the sender actually get hold of the receiver? An object can only call a method on something it has a reference to. That is what visibility is about, and getting it right is what keeps the DSD, the DCD and the code consistent.

The four kinds

There are four ways for A to see B. They differ in how long they last, how common they are, and how they appear in the DCD. In this section each kind keeps its own colour: attribute, parameter, local and global.

Each tab shows one kind as a DSD fragment, the DCD line it implies, and the Java.

public class Register {
    private ProductCatalog catalog;   // ATTRIBUTE
    private Sale currentSale;         // ATTRIBUTE

    public void enterItem(ItemID id, int qty) {
        ProductDescription desc =
            catalog.getProductDescription(id);
        currentSale.makeLineItem(desc, qty);
    }
}

public class Sale {
    private List<SalesLineItem> lineItems = new ArrayList<>();
    // PARAMETER: Sale -> ProductDescription in this method only
    public void makeLineItem(ProductDescription desc, int qty) {
        lineItems.add(new SalesLineItem(desc, qty)); // LOCAL (implicit)
    }
    public void updatePriceFor(ProductDescription d) {
        Money p = d.getPrice();
    }
}

public void enterItem(ItemID id, int qty) {
    // LOCAL: assign the returned object to a local
    ProductDescription desc =
        catalog.getProductDescription(id);
    currentSale.makeLineItem(desc, qty);
}

public void makePayment(Money cashTendered) {
    currentSale.makePayment(cashTendered);
    // GLOBAL via Singleton (preferred way)
    IAccountingAdapter acc = ServicesFactory
        .getInstance().getAccountingAdapter();
    // ...
}

Turning temporary visibility into permanent

Parameter and local visibility are commonly turned into attribute visibility. The typical case is a constructor storing its parameter in a field, as SalesLineItem does (Larman Fig. 19.4).

public class SalesLineItem {
    private ProductDescription description;
    private int quantity;
    public SalesLineItem(ProductDescription desc, int qty) {
        description = desc;   // PARAMETER -> ATTRIBUTE
        quantity = qty;
    }
}

Two more details. There is implicit local visibility: in anObject.getFoo().doBar(); the returned Foo is a temporary local with no name. And global visibility through a true global variable is possible in C++ but not in Java; the Singleton pattern is the preferred way to get it (Part VI), marked by a 1 on the lifeline.

The design consequence

When drawing a DSD, ask for each message how the sender sees the receiver. If it can't, give it visibility, then record the choice in the DCD.

Mapping Designs to Code exam

Once the two design views agree, writing the code is largely a mechanical translation: class and interface definitions come from the DCD, and method definitions come from the interaction diagrams. Larman adds a warning: expect lots of change while programming, because the diagrams are an incomplete first step.

DCD → class definitions

Each DCD element has a direct Java counterpart. Start with a single class and its association.

public class SalesLineItem {
    private int quantity;                  // -quantity : Integer
    private ProductDescription description;// association, role description
    public SalesLineItem(ProductDescription desc, int qty) {
        description = desc;                // «constructor» / create(desc, qty)
        quantity = qty;
    }
    public Money getSubtotal() {           // +getSubtotal() : Money
        return description.getPrice().times(quantity);
    }
}

Associations become fields, and the multiplicity and any qualifier decide the field's type.

class Register {
    private Sale currentSale;   // 0..1: may be null
}
class Sale {   // declare by interface, instantiate concrete
    private List<SalesLineItem> lineItems = new ArrayList<>();
}
class ProductCatalog {
    private Map<ItemID, ProductDesc> descriptions
        = new HashMap<>();
}
class Student { private Subject subject; }  // both sides,
class Subject { private Student student; }  // kept consistent

Types and inheritance map just as directly.

public interface IExpr { int eval(); }

public class Constant implements IExpr {
    private int value;
    public int eval() { return value; }
}

public abstract class Payment { /* ... */ }
public class CashPayment extends Payment { }

public enum State { Open, Locked, Closed }

// underlined + {readOnly} with a default:
public static final int MAX = 6;

The full list of rules, for reference:

Associations to code (Workshop 4 review)

The Workshop 4 review showed how each kind of association turns into fields, including how multiplicity bounds get enforced.

// directed: only Student has a field
class Student { Subject subj; }

// undirected 1-1: both, set up via constructors
public Subject(Student student) { ... }

// 0..4 <-> 0..*: a collection on each side
class Student {
    static final int MAX_SUBJ = 4;
    private Collection<Subject> subjects;
    public boolean addSubject(Subject subject) {
        if (subjects.size() >= MAX_SUBJ) return false;
        ...
    }
    public boolean removeSubject(Subject subject) { ... }
}
class Subject { private Collection<Student> students; }

The upper bound is enforced inside the add method (MAX_SUBJ = 4), while a lower bound of 1 is typically enforced by requiring the object in the constructor.

Collection classes. One-to-many relationships need a collection object (a List, a Map, an array), chosen by requirement: a Map for key lookup, a List for a growing ordered list. Larman's guideline (20.5) is to declare a variable by its interface type, not its concrete class: private List<SalesLineItem> lineItems = new ArrayList<>();. Exceptions: consider the large-scale exception strategy during design, because it has architectural impact; UML shows exceptions in property strings, e.g. {exception IOException}.

Interaction diagram → method bodies

Read top to bottom, then, the interaction diagram gives you the body of each method in the receiving class:

• An incoming message m(p) to :C becomes a method m(P p) defined in class C.
• Each outgoing message n(a) to b : B, in top-to-bottom order, becomes b.n(a);, so the sender needs visibility to b.
• r = n(a), or a reply line labelled r, becomes R r = b.n(a);.
• create(a) sent to a new x : X becomes X x = new X(a);.
• A loop [guard] becomes a for (...), and iteration over items[i] becomes for (Item i : items). alt [g] / [else] becomes if (g) {...} else {...}, and opt [g] becomes if (g) {...}.
• A self message clear() becomes this.clear();, often a private helper. A message to «metaclass» Calendar becomes the static call Calendar.getAvailableLocales();.
• A reply arrow leaving the method's activation becomes return value;.

public class A {
    private B myB = new B();  // attribute visibility
    public void doOne() {
        myB.doTwo();
        myB.doThree();
    }
}

Larman's NextGen enterItem is a bigger example, here as a communication diagram. Messages 1 and 2 are sent while Register handles enterItem, so they form Register's method; 2.1 and 2.2 are sent while Sale handles message 2, so they form makeLineItem.

// in Register
public void enterItem(ItemID id, int qty) {
    ProductDescription desc =
        catalog.getProductDescription(id);  // 1
    currentSale.makeLineItem(desc, qty);    // 2
}
// in Sale
public void makeLineItem(ProductDescription desc,
                         int qty) {
    lineItems.add(new SalesLineItem(desc, qty));
                                // 2.1 create, 2.2 add
}

Order of implementation exam

Then each class depends only on classes that already exist and have been tested, so every step compiles and can be tested in isolation. In NextGen the order is (1) Payment, (2) ProductDescription, (3) ProductCatalog, (4) SalesLineItem, (5) Sale, (6) Register, (7) Store.

Test-driven development and refactoring (Larman ch. 21)

Is it examinable? Possibly. In the Week 12 review lecture the lecturer was asked whether TDD and refactoring would be in the exam and answered possibly, because both are part of the workshop supplementary materials. So know the basics.

Test-driven development (TDD), or test-first development, is an XP practice that also suits the UP. You write the unit test before the class it tests, imagining as you write it that the code already exists. The rhythm is a little test code, then a little production code to make it pass, then more test code, and so on; you do not write all the tests first. It fits the least-to-most-coupled order naturally.

Every test method has three steps: create the fixture (the object under test), do something to it (call the method being tested), and check the results with assertions. To create Sale.makeLineItem, you first write:

public class SaleTest extends TestCase {                 // JUnit 3 style, as in Larman
    public void testMakeLineItem() {                      // idiom: testDoFoo tests doFoo
        Sale fixture = new Sale();                        // 1. create the fixture
        ProductDescription desc =
            new ProductDescription(new ItemID(1), new Money(2.5), "product 1");
        fixture.makeLineItem(desc, 1);                    // 2. exercise the method under test
        fixture.makeLineItem(desc, 2);
        assertTrue(fixture.getTotal().equals(new Money(7.5)));   // 3. check the result
    }
}

Only then do you write makeLineItem to make the test pass. Larman gives five advantages: the unit tests actually get written; writing the test first is more satisfying, so programmers test more consistently; writing the test clarifies the detailed interface and behaviour of the method (one of TDD's major benefits in practice); the growing suite gives provable, repeatable, automated verification; and it gives you the confidence to change code.

That is why it pairs with TDD: after each small step the tests prove nothing regressed, and many such steps can add up to a major design improvement. Its goals are those of good programming: remove duplicate code, improve clarity, shorten long methods, remove hard-coded literal constants. Code smells hint that the design may be poor: duplicated code, a big method, a class with many instance variables, a class with lots of code, strikingly similar subclasses, little or no use of interfaces, and high coupling between many objects. Refactorings have names, like patterns; Larman's samples are Extract Method (move part of a long method into a private helper), Extract Constant (replace a literal with a named constant), Introduce Explaining Variable (put an expression's result into a well-named temporary) and Replace Constructor Call with Factory Method (replace new with a helper that hides the details).

public void takeTurn() {
    int rollTotal = 0;
    for (Die d : dice) { d.roll(); rollTotal += d.getFaceValue(); }
    Square newLoc = board.getSquare(piece.getLocation(), rollTotal);
    piece.setLocation(newLoc);
}

public void takeTurn() {
    int rollTotal = rollDice();                           // call to the extracted helper
    Square newLoc = board.getSquare(piece.getLocation(), rollTotal);
    piece.setLocation(newLoc);
}
private int rollDice() {                                  // created by Extract Method
    int rollTotal = 0;
    for (Die d : dice) { d.roll(); rollTotal += d.getFaceValue(); }
    return rollTotal;
}

The dice-rolling loop in Monopoly's Player.takeTurn() is a distinct, cohesive unit of behaviour, so moving it into a helper makes takeTurn shorter and clearer and supports High Cohesion. (The "before" version is simply the helper inlined back.) Larman adds that the helper is only a stepping stone: in iteration 2, Pure Fabrication replaces it with a Cup class (Part IV).

public Invoice checkout() {
    Money t = this.getTotal();
    Invoice inv = new Invoice(t);
    return inv;
}

Code → Diagrams: the Exam Q7 Procedure exam

Exam Q7 runs the mapping of 3.9 backwards: you are given Java and asked to draw its DCD, and then a DSD for a given call, with concrete values. Both are mechanical if you follow a fixed procedure, and both are worth a lot of marks. The running example is the 2021 Semester 1 calculator; its full code is in 3.11, and the parts you need are shown with each stepper.

Procedure A: Java code → design class diagram

1. One box per type. Interfaces get «interface», abstract classes an italic name or {abstract}, enums «enumeration».
2. Fields with primitive or data types (int, double, boolean, String, dates) go in the attribute compartment as text, e.g. - value : int.
3. Fields whose type is another class or interface in the code become an association line: solid, open arrowhead at the field's type. At the target end put the rolename (field name with visibility, -left) and the multiplicity: 1 for a reference always set by the constructor, 0..1 if it may be null, * (or 0..*) for collections and arrays. One line per field: private IExpr left, right; is two associations. Don't repeat the field as text when the question asks for associations.
4. implements becomes a dashed line with a hollow triangle at the interface; extends a solid line with a hollow triangle at the superclass.
5. Operations are written visibility name(param : Type, ...) : ReturnType. Interface operations are public (+). Constructors use the class name, optionally with «constructor». Package-private members (no Java modifier) get ~.
6. Inherited/implemented methods: obey the question. "Omit methods which can be inferred to exist through inheritance" (2021 S1) means don't repeat them in implementing classes; "Include all methods which exist through inheritance" (2021 S2) means list them in every implementing class.
7. Dependencies. For each parameter type, local variable type or static call target that is not already an association or supertype, draw a dashed open-arrow dependency.
8. Static members are underlined, final constants get {readOnly}, and generic collections may carry {ordered, List}.
9. Check: every field appears exactly once, every arrowhead is unambiguous, every association has a rolename and multiplicity, and every attribute, parameter and return has a type.

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; }
}

Procedure B: Java code + initialisation → DSD with concrete values

1. From the initialisation code, list the object graph. Label each object varName : ConcreteClass, using the runtime class rather than the declared interface. Objects created inline with new are anonymous, e.g. :Plus.
2. The objects already exist, so put all lifelines at the top and don't draw creation. Order them left to right by first involvement.
3. Start with a found message (filled ball) to the receiver, e.g. eval().
4. Trace the code exactly, in Java evaluation order: arguments are evaluated left to right, before the call they are passed to. For each call draw a solid filled-arrow message method(args) (with concrete argument values where known) and an activation bar on the receiver.
5. For every call, draw a dashed return arrow labelled with the concrete value, then continue with the caller.
6. Don't draw operators (+, *, unary -, string concatenation) or field reads as messages: they happen inside the activation.
7. End with the return to the found-message source (the course draws it back to a ball), and give the diagram a title (sd expr.eval()).

Past Exam Q7: Worked Answers exam

Q7 is worth 23 of 120 marks in both 2021 exams. It has three parts: a DCD from code, the GoF patterns in that code, and a DSD with concrete returns. Both papers are worked in full below, each with the official answer's differences noted.

2021 Semester 1: Calculator

The code is the calculator shown in 3.10.

Q7.1 (10 marks). Draw the DCD: "as complete as possible; show Java attributes as UML associations wherever possible; omit methods which can be inferred to exist through inheritance or similar relationships."

The official answer (released 26/27 Oct) matches this in every structural point: the three interface boxes, Constant with - value : int, six dashed realisations, and five navigable associations with rolenames -expr, -left, -right and -op (twice), each with 1 at the interface end. Three details of its notation are worth copying: it puts * at the source end of every association (many expressions can share one sub-expression or operator object); it writes parameters as types only (apply(int, int)), which is enough; and it draws no constructors.

Q7.2 (5 marks): the patterns (details in Part VI and Part VII).

• Composite: the component is IExpr, the composites are BinaryExpr and UnaryExpr (they hold IExpr children), and the leaf is Constant.
• Strategy: the strategy interfaces are IBinaryOp and IUnaryOp, the concrete strategies Plus, Times and UMinus, and the contexts BinaryExpr and UnaryExpr, whose behaviour is swappable via op.

The official answer gives the same two patterns and shows the marks split: 2 for Composite and 3 for Strategy. For Composite it says that UnaryExpr, Constant and BinaryExpr share the interface IExpr and that Constant is the only atomic instance; for Strategy it says IUnaryOp and IBinaryOp are the interfaces of two different instances of the pattern. Spotting both Strategy instances is where the third mark comes from.

Q7.3 (8 marks). Given nine = new Constant(9), uexpr = new UnaryExpr(new UMinus(), nine), two = new Constant(2) and expr = new BinaryExpr(uexpr, new Plus(), two) (that is, −9 + 2), draw the DSD for expr.eval() showing returns explicitly with concrete values. The trace: BinaryExpr.eval evaluates left.eval() first, which is uexpr: it calls nine.eval() (9) then UMinus.apply(9) (−9), and returns −9. Next right.eval(): two returns 2. Finally Plus.apply(-9, 2) returns −7, which expr returns.

The official answer has the same six lifelines in the same order, the same found message (eval() : int) and the same call order. Its one notational difference is binding returns to names (e = 9, apply(e) : int, l = -9, r = 2, v = apply(l, r) : int returning -7). Either style is fine as long as every return shows its concrete value.

2021 Semester 2: Musical Director's lineup

interface ISound { String play(); }

class Duet implements ISound {
    private ISound melodyInstrument, backingInstrument;
    private IDuetMusic music;
    Duet(ISound mi, ISound bi, IDuetMusic m) { melodyInstrument = mi; backingInstrument = bi; music = m; }
    public String play() { return music.playMusic(melodyInstrument, backingInstrument); }
}
class Soloist implements ISound {
    private ISound instrument;
    private ISoloistMusic music;
    Soloist(ISoloistMusic m, ISound i) { music = m; instrument = i; }
    public String play() { return music.playMusic(instrument); }
}
class Instrument implements ISound {
    private String type;   // e.g. "Guitar", "Drums", "Vocals"
    Instrument(String t) { type = t; }
    public String play() { return type; }
}
interface IDuetMusic { String playMusic(ISound melodyInstr, ISound backingInstr); }
class Jazz implements IDuetMusic {
    public String playMusic(ISound melodyInstr, ISound backingInstr) {
        return "Jazz. " + melodyInstr.play() + " melody, " + backingInstr.play() + " backing.";
    }
}
class Rock implements IDuetMusic {
    public String playMusic(ISound melodyInstr, ISound backingInstr) {
        return "Rock. " + melodyInstr.play() + " melody, " + backingInstr.play() + " backing.";
    }
}
interface ISoloistMusic { String playMusic(ISound instrument); }
class Blues implements ISoloistMusic {
    public String playMusic(ISound instr) { return "Blues. " + instr.play() + " soloist."; }
}

Q7.1 (12 marks). Draw the DCD: "as complete as possible; show Java attributes as UML associations wherever possible; include all methods which exist through inheritance or similar relationships." This is the opposite of S1's instruction.

The official answer has the same nine boxes and six realisations, with the methods repeated exactly as instructed. It is sparser in four ways, none of which makes the model answer wrong: it draws Duet's two instrument fields as one association with multiplicity 2; its associations carry multiplicities but no rolenames (rolenames are still worth writing, since the procedure asks for them and they cost nothing); it draws no constructors, no dependency lines and, probably by oversight, no - type : String (keep it: the question says "as complete as possible"); and it names the soloist interface ISoloMusic, a slip for ISoloistMusic.

Q7.2: the patterns.

• Composite: the component is ISound, the composites Duet and Soloist (they contain ISound children), and the leaf Instrument.
• Strategy: IDuetMusic with concrete strategies Jazz and Rock (context Duet), and ISoloistMusic with Blues (context Soloist).

Q7.3 (6 marks). Given guitar = new Instrument("Guitar"), saxophone = new Instrument("Saxophone") and duet = new Duet(guitar, saxophone, new Jazz()), draw the DSD for duet.play() with concrete returns.

The official answer has the same four lifelines and call order: a found play() : String, then playMusic(Instrument, Instrument) : String (argument types rather than names, acceptable), then the two play() calls and the combined string returned twice, using decimal message numbers (1.1, 1.2, …). Don't copy its three slips: its final string reads "Classical. Guitar melody, Saxophone backing.", but the exam's Jazz.playMusic returns "Jazz. " + …, so "Jazz. Guitar melody, Saxophone backing." is correct; its numbering starts the found message at 2 and the inner call at 1, which is out of order; and it labels the strategy lifeline just Jazz, which reads as a class name, so write :Jazz.

Common Mistakes and the Marker's Checklist exam

These mistakes come from the Workshop 3, 4 and 11 review slides, the Workshop 3 partial solution, the Workshop 11 instructions and the rubrics. Read them as a checklist to run over every diagram before you hand it in.

Design class diagrams

• Don't leave attributes without types or visibility (Name), or use non-UML symbols ($cost): write - name : String and - cost : double. The Workshop 3 partial solution's checklist covers visibility modifiers, return types, UML syntax, consistency with the domain model, and appropriate allocation of responsibilities.
• Don't write a value instead of a return type (+pay() : success): write +pay() : boolean.
• Give every association multiplicities, rolenames and a clear navigability arrow, pointing from the class holding the field.
• Avoid ambiguous arrowheads; markers will not guess. Generalisation and realisation use a hollow triangle; navigation and dependency an open stick arrowhead; realisation and dependency are dashed.
• Don't show the same field twice (text and line) when asked for associations, and don't draw primitives (int, String) as association lines.
• Don't miss one of two fields declared together (left, right). Two role-named lines is clearest and is what the official S1 answer does; the official S2 answer merged two fields into one association with multiplicity 2, so a single line is accepted when its multiplicity counts both.
• Don't ignore the instruction about inherited methods: omit them in S1-style questions, include them in S2-style ones.
• Don't forget the interface operations, and don't put fields into «interface» boxes. Constructors are optional: neither official 2021 answer draws them, though including them does no harm.
• Don't leave dependency lines missing for parameter, local or static use, or add them redundantly where an association already exists.
• Avoid domain-model habits in a DCD (no operations, no types, association names instead of rolenames, no navigability), and the reverse, design habits in a domain model (types, methods, software classes; see Part II).

Design sequence diagrams

• Don't draw a return as a solid line, or leave it unlabelled: returns are dashed with an open arrowhead.
• Don't put actor stick figures or :System in a design SD; start with a found message.
• Label lifelines name : Class or :Class. With concrete objects, use the runtime class, not the declared interface. Don't let one lifeline silently stand for a whole collection (use items[i] : Item in a loop). The one accepted shortcut, from the Workshop 11 partial solution (Part IX), is a lifeline named for the collection, such as zoneList : ZoneUnit, receiving messages prefixed with * and a note saying "* denotes that the function is run on all elements".
• Don't send messages to a class that has no such method in the DCD, or with parameters and return types that differ from it.
• Don't draw a loop or alt frame without a guard: every loop needs a condition, and alt compartments need guards or [else].
• Draw created objects at their creation height, not at the top; conversely, don't draw creation for objects the question says already exist.
• Follow Java's left-to-right argument evaluation, or the call order will be wrong, and don't leave out nested activations.
• Don't forget the diagram title or sd frame.

General

• Avoid inconsistency between the SSD, DSD, DCD and code. The Workshop 3 partial solution checks it, and so does the "design models are consistent with the code" rubric criterion.
• Exam diagrams are hand-drawn: use pencil and eraser, draw arrowheads deliberately, keep the layout uncluttered, and state any assumptions (Workshop 11). The Workshop 11 partial solution adds that your models may differ from the official ones depending on your assumptions, and its DCD shows the expected habit of justifying each difference from the domain model in a note.

Slides versus textbook

In the exam, follow Larman, but recognise the forms the course uses.