Object Oriented Design with UML Interaction Models

Formalize — what changes from analysis to design:

• Domain model (analysis): names key domain objects and associations. No methods. Black-box view — we care about what exists.
• Design model (design): white-box view. We define a collection of software objects — runtime entities that hold state and offer behaviour — whose collaboration fulfills the stated requirements.

For each software object we define:

• State — its attributes, the values it remembers (for example UserAccount.fineBalance, BookCopy.status).
• Behaviour — its methods, the operations it can perform and expose to others.
• Collaboration — messages sent over links to get work done.

A class is the definition for a family of such objects. In the conceptual class diagram no methods were shown; in design, methods are the primary addition. The complete design is described as three compartments per class: class name | attributes | methods — ready to hand to a programmer or to a tool that generates skeleton code.

Crucially, software objects are inspired by domain objects but not identical to them. Iterative development expects revision: as we draw interaction diagrams and discover missing responsibilities, we revisit earlier decisions, rename, merge, or add conceptual objects.

Core idea: A design is not a pile of classes; it is a flowing exchange among objects over time. Visualizing that exchange is the hardest part, because time and collaboration are dynamic, not static.

Two needs arise:

1. A notation to show interaction. Unified Modeling Language (UML) provides the standard visual language — sequence diagrams for time order, communication diagrams for structural organization, plus class diagrams and state charts for the static and lifecycle views (see 9.4).
2. Principles to justify choices. Many arrangements can implement the same requirement. A good design is workable, optimal for the context, explainable, and rational. Principles — rules analogous to theorems and proofs — let us argue methodically that a choice will hold across situations before any code is written. Without them a novel design carries no guarantee; with them we can evaluate alternatives on coupling, cohesion, and responsibility assignment (GRASP) rather than on taste.

Formalize:

A pattern — a named pairing of a recurring problem and a general solution that works in many situations — is not copy-paste code; it is a template we customize to our specific context. Two major collections frame the design portion of this course:

• Gang of Four (Gamma et al.) — 23 object-oriented patterns. A widely referenced catalogue covering creational, structural, and behavioural problems (for example Strategy, Adapter, Observer, Factory). Originally described in C++ but language-independent.
• GRASP (Larman) — nine patterns/principles for responsibility assignment. GRASP (General Responsibility Assignment Software Patterns) teaches who should do what and how to use inheritance, composition, and aggregation wisely. The nine are: Creator, Controller, Information Expert, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, Protected Variations. Five are treated in this lecture block; four follow in the next class. GRASP is best viewed as a learning aid that names basic, classic principles — expert designers recognise the ideas even without the names.

Both collections will be studied across the design portion, applied while sketching interaction diagrams and while coding.

Formalize — from vague to precise: The session asked "What is the advantage of reusing a solution?" Answers offered were "reduce redundancy," "save time," "improve productivity." The professor refined this: reducing redundancy alone is vague — duplicated code can be removed without improving the design. The precise benefits are:

• Saves time and lifts productivity: less invention, less testing of already-solved logic.
• Builds shared vocabulary: a team that knows Creator, Expert, or Publisher-Subscriber can communicate a design decision in a short sentence and review it quickly.
• Supplies a guarantee: any reusable solution that has already worked elsewhere carries evidence. Reusing it means reusing that evidence. The design becomes explainable: we can point to a known pattern and say why it fits. This is the engineering and mathematical stance — we can claim in advance that the design will work because it rests on proven principles, just as a theorem rests on its proof.

The theorem-proof analogy: a theorem is trusted because a proof has been checked; a pattern is trusted because many prior applications have been checked. Neither removes the need to adapt carefully, but both shift confidence from "hope it works" to "we have reason to believe it will."

Reusability also shortens iteration (less redrawing), reduces representational effort (names already understood), and makes reviews tractable: a reviewer asks "did you apply Creator here?" rather than re-deriving the whole logic.

Formalize:

• An object — a runtime entity that holds state and offers behaviour — carries its own attribute values and the operations that manipulate them. For example a UserAccount with userID: String, loanCount: Integer, fineBalance: Money, and operations such as authenticate(), canBorrow().
• A class is the definition that describes a family of such objects — the template for their attributes and method signatures.

During design we decide the state each software object will maintain and the set of methods it will expose. Attributes may grow compared to the conceptual model (adding dueDate, issuedDate, or status needed for implementation), and methods are now supplied in full. Responsibilities — the things an object is asked to do — are assigned as methods. An object moves through different states as attribute values change, and different operations become relevant in different states (for example a BookCopy that is available vs. issued vs. overdue exposes different allowed actions).

The black-box view: callers rely on the interface guarantee (pre/post-conditions) and never need to inspect internal data structures.

Formalize: An object-oriented system is fundamentally an interactive system. Objects achieve a larger purpose by interacting, sending messages to one another. A message — the name of a service requested from another object together with any information needed to perform it and any result returned — is the means of collaboration. In implementation, "send a message" most often means "make a method call and optionally receive a return." No hidden coordinator is needed; objects call each other directly over declared links (instances of associations).

Responsibility-driven design is the discipline of assigning methods by asking "who should do what?" based on information ownership and existing duties.

CRC cards (Classes, Responsibilities, Collaborators) — a paper index-card technique by Beck and Cunningham — support brainstorming: for each class we list what it is responsible for and which collaborators it needs to complete that responsibility. Playing through scenarios with CRC cards helps identify missing objects and clarifies whether the current object set is sufficient before committing to diagrams.

Formalize: A representational gap is the distance between concepts in the real world and their counterparts in software. Object orientation aims for a low representational gap: keeping real-world names and ideas in the software so the model stays close to reality, which aids understanding and keeps the system aligned with what users recognise. Analysis, design, and programming all use objects, so the same conceptual tool runs through every phase. We take inspiration from reality, translate domain objects into software objects, and refine them so the gap narrows while acknowledging that software objects are still abstractions, not literal real-world things.

In Larman's terms (T1, Ch. 17), low representational gap connects the Domain Model to the Design Model: if the domain has Sale and SalesLineItem, the design can meaningfully have software classes with those names, but we remain free to add purely software inventions (for example ProductCatalog singleton, Payment factory) where they improve cohesion and coupling.

Formalize — dynamic vs. static:

• An interaction diagram is the dynamic view that shows how objects exchange messages over time to realize a system operation. Every message sent to an object corresponds to a method on that object that will handle the request. Taken together, the message flows for all system operations define the method contracts of the whole design. Method contracts (operation contracts on post-conditions, inspired by T1 Ch. 11) may be used to specify the effect of each operation more precisely.

Two complementary forms express the same interaction, with a trade-off (T1 Ch. 15, T7 Ch. 7-8):

• Sequence diagram — time ordering along vertical lifelines with activation (execution specification) bars. Read top-to-bottom.
• Communication diagram — also called a collaboration diagram — emphasizes structural organization: objects as nodes, links as lines, messages annotated with numbering that recovers time order. More space-efficient on walls.

Use interaction diagrams as the core design view for exploring logic and behaviour. In agile whiteboard practice (T1 Ch. 14), the most challenging, interesting design work — "where the rubber hits the road" — happens while drawing these dynamic diagrams, not the class diagram.

Why they define methods: drawing verify(cardID) from System → UserAccount forces us to decide that UserAccount needs a method verify(cardID: String): AuthResult. The diagram is the decision.

Formalize:

• A class diagram is the static view. Once the interaction view has defined methods and needed associations, the complete set of classes with attributes and methods can be drawn together. A complete class diagram — including method signatures with parameters and return types — can be turned into code through tooling or used as a blueprint for implementation skeletons (T1 Ch. 16; T7 Ch. 5).

• A state transition diagram or state chart / state machine diagram (UML state machine, see T1 Ch. 29, T7 Ch. 9) models the dynamic behaviour inside a single object. It identifies distinct states the object can occupy, the events that cause transitions, and the operations active in each state. While interaction diagrams show between-object collaboration, state charts show within-object lifecycle.

Example given in lecture: a fan may be in an Off state or a Running / On state, with events switchOn / switchOff that switch between them. For software, a Loan might be in requested → issued → overdue → returned states, an Order in new → paid → shipped → delivered. State charts help identify the events (which become messages) and the methods that handle them, and they connect back to dynamic behaviour across the system where objects move from one state to another as messages are exchanged.

Relationship between the three views:

• Interaction → discovers needed methods and links.
• Class → records the resulting signatures and associations.
• State chart → constrains which methods are valid when, preventing illegal transitions (for example return() only from issued).

Formalize:

• A message is the communication specification between objects that conveys information with the expectation that some activity will follow. Plain description from the session: "the name of the service requested by the calling object." Alongside the service name, a message may carry parameters — the information required to execute the service — and a return value — the result sent back to the caller. In implementation, messages are most often realized as procedure calls or method calls. Spoken phrasing "send a message" therefore means "make a method call and optionally receive a return."

• A link is a connection among objects over which messages can flow. Semantically it is an instance of an association defined at class level (T1 Ch. 15, T7 Ch. 8). An association declared at class level becomes one or more links between specific object instances at runtime. A message should only be sent where a link exists — that is, where the design has declared a structural relationship that justifies communication. This enforces the idea that collaboration is not accidental; it follows declared associations that were partly identified in the conceptual class diagram and are now materialized in the design.

• Responsibility-driven design (RDD) — the metaphor that software objects are like people with responsibilities who collaborate — is the discipline of assigning methods by asking "who should do what?" Each message assignment is a decision about which object is best placed to carry a responsibility, based on the information it holds and its existing duties. GRASP principles (Information Expert, Creator, Low Coupling, High Cohesion, etc.) make that question answerable methodically.

Reconciled syntax (UML interaction expression): Verbal forms from the session — "total is the written value and integer is the written type", "you give an assignment total is the message", "v assigned buffer get", "thermostate dot set temperature" — and "parameters with the colon separation with the data type and the return type also you can mention" — reconstruct to the standard UML message expression (T1 Ch. 15, p. 227):

$$return=message(parameter:parameterType):returnType$$

where parentheses are omitted if there are no parameters and type information may be omitted if obvious. This was verified against T1 Ch. 15 and T7 Ch. 7. The four idioms from the lecture are instances of this schema.

Typed assignment (Pascal-like notation) — "total with type Integer receives the result of getTotal":

$$\text{total}:\text{Integer}:=\text{getTotal}()$$

where $\text{total}\in \text{Integer}$ is the receiving variable that will hold the result, $\text{getTotal}:()\to \text{Integer}$ is the message or operation requested, and $:=$ denotes assignment of the returned value to the caller. In UML wall-sketch style this is written as total : Integer := getTotal(); the colon before the type follows the name : Type convention. The form d = getProductDescription(id:ItemID) : ProductDescription in T1 is the same idea.

Buffer retrieval — "call the method associated with the buffer object and return the next value so as a circular list circular buffer dot get":

$$v:=\text{buffer.get}()$$

where $\text{buffer}$ is the holder object (in the example a circular buffer or circular list), $\text{get}:()\to \text{Value}$ is the operation, and $v$ is the local variable receiving the next value. More explicitly with types: v : Value := buffer.get() : Value.

Thermostat temperature setting — "call the method associated with the thermostate object that sets the temperature":

$$\text{thermostat.setTemperature}(t)$$

where $\text{thermostat}$ is the target object, $\text{setTemperature}:\text{Temperature}\to ()$ is the setter operation, and $t:\text{Temperature}$ is the temperature parameter; paired getter and setter methods of this style are used to set and read state (thermostat.getTemperature() : Temperature).

General message signature pattern that subsumes these cases:

$$\text{receiver.operation}(p_1:T_1,p_2:T_2):T_{\text{return}}$$

where $\text{receiver}$ is the target object (or class for a static call, see 9.8), $\text{operation}$ is the service name, each $p_i:T_i$ names a parameter and its type, and $T_{\text{return}}$ names the type of the returned value when one exists. When the message is a pure signal, the return type is absent. Example with two parameters: register.addItem(id: ItemID, qty: Integer): Boolean.

Formalize (T1 Ch. 15, T7 Ch. 7):

• A sequence diagram shows message dispatch across a timeline. Each participating object or actor has a vertical dashed (or solid per UML 2) lifeline that represents its existence over time. The lifeline box at the top names the participant using the name : Type notation (e.g., a : Sale, :Sale for anonymous, sales[i] : Sale for a selected collection element).

• A thin rectangle over the lifeline — the activation box (UML 2: execution specification bar) — shows when that object is actively processing a call, informally when the operation is on the call stack (focus of control). The bar is optional when wall-sketching but automatic in CASE tools.

• Messages are drawn as horizontal arrows between lifelines in chronological order from top to bottom. The time aspect is implicit in that vertical order; reading downward follows the execution. A filled arrow head denotes a synchronous (blocking) call, an open stick arrow an asynchronous call (see 9.8). The starting message is a found message (solid-ball origin) whose sender may be unspecified.

• A return (reply) can be shown either as result := message() or as a dashed return arrow closing the activation.

• Flow of control or thread of control is the action sequence that threads through these messages. A sequence is a collection of messages dispatched one after another, potentially with branching (alt/opt frames) or iteration (loop frames). The diagram makes visible which object initiates each call, which object handles it, and how control returns to the caller.

Formalize — when numbers are needed:

Verbal forms captured: "you can give some flat numbering or procedural numbering when you are one after the other" and "numbering is required" versus "you don't need any numbering" depending on the diagram variant, and "flat sequencing as one two three four or nested sequencing as 1.1 1.2".

• In sequence diagrams: numbering is optional because time is already encoded vertically. If used, it should follow procedural (nested) convention.
• In communication diagrams: numbering is required to recover order because spatial layout carries no time.

Options, verified against T1 Ch. 15 (pp. 241–243) and T7 Ch. 8:

• Flat numbering: $1,2,3,4$ — a simple total order.
• Procedural or nested numbering: $1,1.1,1.2,\mathrm{1.2.1},2$ — reveals nesting: messages $1.1$ and $1.2$ are sent as part of handling message $1$. Procedural numbering is popular because one high-level request naturally decomposes into several subsidiary messages needed to fulfill it.
• Multi-thread / conditional path variants: separate top-level numbers or letters such as 1a / 1b distinguish concurrent threads or mutually exclusive conditional paths (see 9.8 for alt handling).

Guideline (T1): Do not number the starting message in communication diagrams; it simplifies subsequent nesting. Nesting is shown by prepending the incoming message number to the outgoing number.

The session stressed: "please use comments when you are drawing your diagrams" for ambiguity, but for ordering in sequence diagrams you may rely on vertical position alone.

Reconciled formulation (verified against T1 Fig. 15.27–15.28, T7):

General sequence pattern, described verbally as "flat numbering" and "nested sequencing":

$$1:{\text{op}}_1(),1.1:{\text{op}}_{1.1}(),1.2:{\text{op}}_{1.2}(),2:{\text{op}}_2()$$

where each $k$ or $k.j$ labels a message in execution order, and dotted suffixes indicate that the dotted messages are dispatched inside the handling of their parent message. This is procedural nesting. The unnumbered starting message msg1 may be present before 1: msg2 (T1 guideline).

A purely flat alternative of the same flow would be labelled:

$$1:{\text{op}}_1(),2:{\text{op}}_{1.1}(),3:{\text{op}}_{1.2}(),4:{\text{op}}_2()$$

but the nested form preserves the causal parent-child structure that the flat form loses. In UML communication diagrams, 1: create(cashier) → :Register → :Sale with nested 1.1: ... illustrates this (T1 Fig. 15.26–15.27).

Multi-thread/conditional extension:

$$1a[cond]:{\text{op}}_a(),1b[\text{not }cond]:{\text{op}}_b(),2:\text{next}()$$

where letters a, b mark mutually exclusive paths at the same sequence level (see 9.8).

All forms above are the standard UML sequencing verified in enrichment docs; lecture's "flat vs nested" phrasing maps directly to this.

Formalize (T1 Ch. 15, T7 Ch. 8): A communication diagram — earlier name collaboration diagram — stresses the structural organization of objects and the links that join them. Instead of vertical time, the layout places objects as nodes (boxes) and draws links as lines annotated with numbered messages (arrows showing direction). The same lifecycle concepts as in sequence diagrams apply: construction via a create message (optionally stereotyped <<create>>), destruction via <<destroy>> / X where applicable, flow of control through the numbering, and self-messages (a link to itself) where an object does internal work such as recalculate().

Key structural property: links are instances of associations identified earlier (during domain or design class modelling). An association declared at class level (e.g., Sale —* SalesLineItem) becomes one or more links between specific object instances at runtime (sale:Sale — sli1:SalesLineItem). Only over such a link may a message be passed. Multiple messages, in both directions, flow along the same single link — the link is like a road allowing two-way traffic; it is not duplicated per message (T1 Fig. 15.23–15.24). This connection between static associations and dynamic links keeps the two views consistent.

Unlike sequence diagrams, time is not implicit. Order is recovered solely by the numbering (see 9.6.2). Hence placement of boxes is free in two dimensions, which is the diagram's space-economy advantage on walls.

Formalize: Well-structured interactions are those that are efficient, simple, adaptable, and understandable — criteria the lecture stressed for evaluating candidate message arrangements:

• Efficient — avoids unnecessary message round-trips (for example asking UserAccount once for a combined AuthResult rather than three separate calls for authentication, loan count, and fine).
• Simple — messaging is regular and easy to follow; nesting reflects natural decomposition.
• Adaptable — leaves room to vary behaviour without broad rewiring (e.g., adding a new loan rule touches only LoanPolicy, not every client).
• Understandable — a newcomer can read the diagram and grasp why each message exists, because each answers an Information Expert / Creator rationale.

Related distinction (lecture vocabulary): concrete or prototypical objects refers to objects drawn directly from the real-world domain (e.g., BookCopy, Borrower) versus conceptual or abstract data type objects introduced purely for software organization, such as specification objects, policies, or coordinators with no physical counterpart. Both kinds may appear together; the conceptual ones are justified when they improve cohesion and reduce coupling, even though they widen the representational gap locally to narrow it globally.

Design evaluation therefore asks: does distributing checks to UserAccount and Catalog yield better structure than routing everything through one LibrarySystem coordinator?

Formalize — the two cardinal GRASP evaluation principles (T1 Ch. 17, Larman):

• High cohesion — each object or class has a focused, single-purpose set of responsibilities. Cohesion informally measures how functionally related the operations of a software element are and how much work it does. A Sale that knows its total via SalesLineItem collaborators is cohesive; a MonopolyGame that itself does database access, number generation, and UI work is not.

• Low coupling — objects depend on as few other objects and as little of their internals as possible. Coupling measures how strongly one element is connected to, has knowledge of, or depends on others; when the depended-upon element changes, the dependant is affected.

They are linked: a low-cohesion object with many unrelated responsibilities naturally collaborates with many others, creating high coupling.

Most interaction designs are assessed against these two. A design that routes all library checks through one overloaded LibraryManagementSystem coordinator would be low cohesion and tightly coupled (every rule change touches the coordinator and many clients). A design that distributes checks to the objects that naturally own the information — asking UserAccount for fine and limit checks (Expert), Catalog for availability (Expert), LoanFactory or Loan for creation (Creator) — tends toward high cohesion and low coupling and is preferred all else equal.

Participants were asked to review these principles during the pause because the next block (9.8 onward) applies them to decide iteration, guards, and object creation placement.

Formalize (T1 Ch. 15, T7 Ch. 7–8): Two simple visual rules were stressed and are the foundation for all detailed notations that follow:

1. Object vs. class notation — the colon: An object box shows naming as name : Type, for example $a:\text{Sale}$ or $s1:\text{Sale}$. Before the colon is the object name (instance identifier); after is the class (type). If only a type is shown (:Sale) it represents an anonymous object. If a selector is shown (sales[i] : Sale or lineItems[i] : SalesLineItem) it denotes one element selected from a collection. Before the colon → object; after → type.

A box showing only a class name with no colon — e.g., ProductCatalog or Calendar or Math — denotes the class itself (more precisely, an instance of a metaclass Class), meaning a static / class-level call. This distinction matters for ProductCatalog.getInstance() (static) vs. aCatalog.getProduct(...) (instance).

1. Links before messages: Before sending a message, a link must exist between the two objects (association instance). The link is the precondition for communication; showing a message without a justifying link is a review fault.

Every message may list parameters with types after a colon — op(p1: T1, p2: T2) : TReturn — and a return type may be declared as in $\text{total}:\text{Integer}:=\text{getTotal}()$. Message numbering supplies order, and where an assignment results, the notation shows the receiving variable, the type, and the operation (d := getProductDescription(id: ItemID) : ProductDescription per T1).

Reconciled formulations (verified against T1 Ch. 15 Figs. 15.16–15.17, 15.31–15.32; T7):

Iteration with unknown count, described verbally as "iterations are shown by in star so number of sales line item would be there in a particular sale so one sale will have number of sales line item that you can show as an iteration no recurrence value" and "if you know the recurrence value you can show within brackets this is your guard condition so one to n" and options "you can use i colon one to n and you can use star any one is fine":

Unbounded iteration (star alone):

$$\ast :\text{createSalesLineItem}()\text{or}\ast :\text{process}(\text{item})$$

where $\ast$ preceding the message denotes "for each element in the associated multi-object." In communication diagrams this appears as 1 *: st := getSubtotal (less precise shorthand, see T1 Fig. 15.31). It means "repeat without stating the bound" — the collection size is unspecified or not important.

Bounded iteration with recurrence value / guard form:

$$\ast [i:=\mathrm{1..}n]{\text{salesLineItem}}_i.\text{computeSubtotal}()$$

or equivalently with explicit assignment guard:

$$\ast [i:\mathrm{1..}n]\text{(shorthand)}$$

and the concrete T1 style with full message:

$$1\ast [i=\mathrm{1..}n]:\text{num}:=\text{nextInt}()$$

where $i$ is the iteration variable ranging over $1$ to $n$, $n$ is the number of items, and the bracketed guard indicates the repetition condition. In sequence diagrams the same is shown as a loop frame with guard [i < lineItems.size] and an action box i++ (T1 Fig. 15.16). An alternative concrete cap noted verbally as "you can say that only 10 items maximum you can add" would reconstruct as $[i:=\mathrm{1..10}]$ or $[\mathrm{1..10}]$ depending on openness; keeping the range open as $[\mathrm{1..}n]$ leaves the count unspecified.

Conditional / guarded messaging, described verbally as "conditional messaging as the guard messages guard conditions if it is true then only message would be sent if it is a new sale then only a create new sale message would be sent" and "usually exclusive messages you can send based on the conditions not or true so either this one or this one would be executed":

$$[isNewSale]\text{createSale}()$$

$$[x>0]\text{processPositive}()\text{vs}[\text{not }x>0]\text{processNonPositive}()$$

where each bracketed condition is a guard; the guarded message is dispatched only when the guard evaluates to true. In UML 2 sequence diagrams a single conditional is shown with an opt frame whose guard is placed over the lifeline (T1 Fig. 15.13); mutually exclusive paths use an alt frame with guards such as [color = red] vs. [else] (T1 Fig. 15.15). In communication diagrams guards are inline: 1 [color = red]: calculate (T1 Fig. 15.29) and with path letters 1a [test1]: msg2 vs. 1b [not test1]: msg4 (T1 Fig. 15.30).

Unconditional messages carry no guard and are dispatched regardless:

$$\text{updateCatalog}()$$

Self-message for internal processing, described verbally as "message to self whenever you are doing something clearing itself or calculating or processing some work you can send a message to self":

$$\text{self}.\text{recalculate}()\text{drawn as a loopback arrow on the same lifeline}$$

In communication diagrams this is a link to itself with 1: clear (T1 Fig. 15.25); in sequence diagrams a nested activation bar.

Comments for ambiguity removal, described verbally as "notation for comment is your folded rectangle" and "for removing any ambiguity in the diagrams you need to specify that in the comments so please use comments when you are drawing your diagrams":

\text{comment : } \fbox{\parbox{...}{\text{all 10 messages go to the same SalesLineItem vs each to a distinct item}}}

where the folded-corner rectangle (UML note) is placed adjacent to the ambiguous region with a dashed lead line. The precise idiom for iteration-over-collection uses a note to clarify whether the batch of messages fans to one collection object or to $n$ distinct element objects (see 9.8.3).

Synthesis — all message types that may appear in a design (expanded from T1 Ch. 15):

• Signal — a one-way notification that some activity happened, modelled as a message without expecting a return, e.g., "send a signal that this has happened just triggering some particular thing." Notation: open or filled arrow without return assignment.
• Call — invocation of an operation that may return a value, the most common form. Example: d := getProductDescription(id).
• Create — instantiation via <<create>> stereotype or new/create message; "new also can be used but create message is very common." Creation is typically assigned to the participant that holds the most information needed to initialize the new object (Creator principle). Shown as dashed arrow with filled head in sequence diagrams; 1: create(cashier) in communication diagrams.
• Destroy — deletion of an object; signalled by <<destroy>> and X at end of lifeline. Relevant outside automatic garbage collection contexts (C++), or to indicate logical end-of-usefulness (closed connection).
• Self-call — internal processing on the same object, drawn as a loopback arrow / nested activation. Example: Sale.recalculateTotal().
• Return — dashed arrow carrying a value back to the caller, closing the activation. Can also be shown as result := message().
• Static / class message — ClassName.operation() to a box with no colon, indicating a call on the class/metaclass object.
• Guarded / iterated messages — any of the above prefixed with [guard] or * [i=1..n] per 9.8.2.

A single interaction may contain all of these: a create, several guarded calls, an iteration with *, a self-call, and a destroy.

Formalize — what "complete" means for handover:

A design must be complete — sufficient for a programmer to implement without guessing. That means:

• Every required object (including conceptual helpers like Sale, Payment, FinePolicy where justified) appears.
• Every link needed for messaging is present — each arrow is justified by an association/visibility.
• Every guard and iteration count is stated or deliberately left open with an explicit unbounded star (*) — not omitted by accident.
• Every conditional vs. unconditional message is explicit ([guard] present or absent deliberately).
• Any residual ambiguity — notably whether a batch of messages targets one instance or many distinct instances — is closed by a folded-rectangle comment (UML note) with a dashed lead line to the ambiguous region.

The session stressed "please use comments when you are drawing your diagrams" to eliminate the question of whether a batch of messages targets one instance or many, and to note side conditions — in plain words: "no diagram is complete without an unambiguous diagram." Comments are not decoration; they are part of the contract.

Completeness checklist (used in reviews):

• Object boxes have correct colon notation (name : Type vs. Class for static).
• Parameters and return types are typed (p: Type : Return).
• Links exist for every message.
• Iteration (*, * [i=1..n]) and guards ([cond]) cover all branching.
• Creation/destroy lifecycle shown where relevant.
• Folded comment present where fanning ambiguity exists.

Conventions that keep diagrams readable (aligned with T1/T7):

• Procedural numbering: top-level messages numbered $1,2,3$ and their internal delegations numbered $1.1,1.2$ and so on, including $2.1,2.2$ for the next decomposition (e.g., 1: enterItem, 1.1: getProductDescription, 1.2: create SalesLineItem, 2: getTotal, 2.1: getSubtotal). This makes delegation visible and keeps branching readable.
• Alternative flows: exclusive guarded messages ([cond] vs. [\text{not } cond] or 1a vs. 1b branches) show that only one of a set executes. In sequence diagrams these sit inside alt / opt frames.
• Unconditional messages: no guard bracket is needed — their absence means unconditional; do not add [true].
• Creation as a step: where a message creates an object, it conceptually counts as the next sequential step (for example as the third or fourth message in the operation's flow) so its new lifeline starts at the point of creation, not at the top of the diagram. Subsequent messages that involve the new object only appear after its creation point.

Synthesis — where this lecture's ideas land in practice:

• UML interaction modelling as the dynamic backbone: Teams document every system operation (e.g., borrowBook, enterItem, makePayment) as a sequence or communication diagram that shows time-ordered message flows over declared links, with explicit control over iteration (*, * [i=1..n]), guards ([cond], alt/opt), and branching. These diagrams define the methods; the class diagram then records them.