Appendix

UML Notation at a Glance

Every kind of diagram the subject uses, drawn once in full with every symbol labelled. Use this page as a quick reference while you read the Parts, and as a model of what a complete, correct diagram looks like in the exam.

A.1

Class Diagrams: Lines and Arrowheads

A class diagram is boxes joined by lines, and almost all of the meaning is in the line style and the arrowhead. There are seven combinations to know. Learn them as pairs: solid or dashed line, and which of four ends it has (none, open arrow, hollow triangle, diamond).

The seven relationships. The diamond always sits at the whole end; the triangle always points at the more general thing; an open arrow points the way a reference or call goes.

A complete domain model

This is the subject's own notation-reference example (a university club), redrawn. A domain model shows real-world concepts, their attributes and the associations between them. It has no methods and no arrowheads on associations, because it describes the world, not software.

Everything a domain model can contain. Association names with reading arrows (◂ Attends: a Member attends Events), multiplicities at both ends (1..4 subjects), generalisation trees drawn with one shared triangle, an association class (Appointment, joined by a dashed line, because the date belongs to the pairing of member and position) and a note. Attributes are plain names, optionally with a simple type such as Dollar.

A complete design class diagram

A design class diagram (DCD) describes software classes. Compared with the domain model it adds a third compartment for methods, visibility markers (+ public, - private), types, and navigability arrows with role names that become fields in code.

Reading a DCD. Three compartments: name, attributes, operations. -quantity: Integer is a private attribute; +getTotal(): Money is a public method returning Money. An arrow from Register to Sale labelled currentSale means Register holds a Sale currentSale field, and {ordered} on lineItems means a List. Attributes that are references to other classes are shown as arrows, not repeated inside the box.

Element	Domain model (conceptual)	Design class diagram (software)
Boxes are	real-world concepts	software classes and interfaces
Attributes	plain names, simple data types only	visibility, name and type: `-price: Money`
Methods	never	yes, with parameters and return types
Associations	plain lines with a name and reading arrow	navigable arrows with a role name (the field)
Multiplicity	at both ends	at least at the arrow end

A.2

Sequence Diagrams

A sequence diagram shows who sends which message to whom, in what order. Each participant gets a box at the top with a dashed lifeline running down; time flows downward; each message is a horizontal arrow from sender to receiver. The subject uses two kinds: the system sequence diagram (SSD), which treats the whole system as one black box, and the design sequence diagram, which opens the box and shows the software objects inside.

System sequence diagram (SSD)

An SSD has exactly two kinds of participant: the external actor (a stick figure) and :System as one black box. Solid arrows with filled heads are system events the actor sends; dashed arrows are returned information. A loop frame repeats its contents while its guard holds.

Design sequence diagram

The design version keeps the same notation and adds activation bars (the thin rectangles showing when an object is busy), self-calls, object creation and more kinds of frame. The numbered badges are explained below the diagram.

Design sequence diagram notation, using the NextGen POS makePayment operation (the shortfall branch is illustrative).

Found message. A message whose sender is not shown starts at a filled dot. In a design diagram, the first message is usually the system operation from the SSD arriving at a controller.
Activation bar. A thin rectangle on a lifeline shows the period when that object is executing a method (including waiting for the methods it calls).
Self-call. An object calling its own method: the arrow loops back, and a second, nested activation bar starts. t := getTotal() means the returned value is stored in t.
Loop frame. loop in the corner tag, with a guard in square brackets saying how often it repeats.
Creation. The create(...) message points at the new object's box, which is drawn at the height where it is created rather than at the top. Its lifeline starts there.
Alt frame. Mutually exclusive alternatives (if / else), separated by a dashed line, each with its own guard. opt is the one-branch version (an if with no else).
Return. A dashed line with an open arrowhead. It is optional in design diagrams; the t := ... form usually says the same thing more compactly.

A.3

Use Case Diagrams

A use case diagram is a context picture: it shows the system boundary, the actors outside it, and the names of the use cases inside it. The real requirements are in the use case text; the diagram is just the table of contents.

Use case diagram notation. Actors stand outside the boundary box; use cases are ovals named with a verb phrase. A plain line means "takes part in". «include» points from the base use case to the shared piece it always uses; «extend» points from the optional extension to the use case it extends. A computer system acting as an actor is often drawn as a box with «actor».

A.4

State Machine Diagrams

A state machine shows the life of one object (or system): the states it can be in, and the events that move it from one state to another. A transition is labelled event [guard] / action, and each part is optional.

State machine notation (the subject's ATM notation-reference example). Filled dot: initial state. Bullseye: final state. Rounded boxes: states. Active is a composite state containing its own sub-machine with its own initial state; cardRemoved leaves the whole composite. pinEntered [incorrect] is a self-transition with a guard; / scanCard is an action done during the transition; entry / showMenu is an internal activity done on entering the state.

A.5

Communication Diagrams

A communication diagram shows the same messages as a sequence diagram, but the objects can sit anywhere on the page. Because position no longer shows the order, every message carries a sequence number. Objects are joined by links (plain lines), and every message between two objects travels along their one link, with a small arrow beside it showing its direction.

The same makePayment interaction as in A.2, drawn as a communication diagram. The first message is not numbered. A message sent while handling message 1 is numbered 1.1, the next one at that level 1.2, and a message sent while handling 1.1 is 1.1.1. The * marks iteration, and {new} marks an object created during the interaction. Object names are underlined because they are instances.

	Sequence diagram	Communication diagram
Strength	Order is obvious: read top to bottom. Richest notation (frames).	Compact: objects can go anywhere, easy to sketch and change.
Weakness	New objects go on the right, so it grows wide.	You must read the numbers to see the order.

A.6

Package Diagrams

A package diagram groups classes into packages (folders drawn with a tab) and shows which packages depend on which. It is the usual way to draw a layered architecture. Packages can be nested. When a package's contents are drawn inside it, its name goes in the tab.

Layers as packages. Dashed arrows are dependencies: the UI layer depends on the Domain layer, and the Domain on Technical Services, never the other way. Inside Domain, Sales depends on Pricing. Part VIII explains why the arrows must point downwards.

A.7

Glossary

Every key term in the subject, in one place. The last column says which Part teaches it.

Term	Meaning	Part
Abstract Factory	A factory interface for creating families of related objects; each concrete factory produces one consistent family.	VI
Activation bar	The thin rectangle on a lifeline in a sequence diagram, showing when that object is executing a method.	III
Actor	Something with behaviour outside the system that interacts with it: a person, an organisation or another computer system. Primary, supporting or offstage.	I
Adapter	Converts the interface of an existing class into the interface a client expects, so incompatible classes can work together.	VI
Aggregation	A hollow-diamond whole–part association. UML gives it no precise meaning, so Larman recommends avoiding it.	II
Alt frame	A sequence-diagram frame holding mutually exclusive alternatives (if / else), each with a guard.	III
Architectural factor	A requirement with significant influence on the architecture, usually a quality such as reliability or performance; recorded in the factor table.	VIII
Association	A relationship between classes that indicates a meaningful, lasting connection; named with a verb phrase and given multiplicities.	II
Association class	A class attached to an association by a dashed line, holding attributes that belong to the link itself (e.g. Appointment between Member and Position).	II
Attribute	A logical data value of an object. In a domain model, attributes should be simple data types; anything complex is a class joined by an association.	II
Builder	Separates the step-by-step construction of a complex object from its representation, so the same steps can build different results.	VI
Cohesion	How strongly related and focused one element's responsibilities are. High Cohesion keeps it so.	IV
Communication diagram	An interaction diagram that shows objects as a graph joined by links, with numbered messages instead of a time axis.	III
Composite	Treats individual objects and groups of objects uniformly, by giving the group the same interface as its parts; used for tree structures.	VII
Composite state	A state that contains its own nested state machine.	V
Composition	A filled-diamond whole–part association: each part belongs to one whole at a time and is created and destroyed with it.	II
Conceptual class	A real-world idea or thing in the problem domain, shown in a domain model; it has a symbol, an intension (definition) and an extension (instances).	II
Controller	GRASP: the first object beyond the UI layer that receives and coordinates a system operation; either a facade controller or a use-case controller.	IV
Coupling	How strongly one element is connected to, knows about or relies on others. Low Coupling keeps it low.	IV
Creator	GRASP: give class B the responsibility to create A if B contains, records, closely uses or has the initialising data for A.	IV
Decorator	Attaches extra responsibilities to an object dynamically by wrapping it in objects with the same interface.	VI
Dependency	A dashed arrow showing that one element uses another (a parameter, local variable or static call) without holding a field for it.	II
Design class diagram (DCD)	A class diagram of software classes, with attributes, methods, types, visibility and navigable associations.	III
Design sequence diagram	A sequence diagram of software objects sending messages to carry out a system operation.	III
Domain layer	The layer of software objects representing domain concepts and fulfilling the application's logic; its classes are inspired by the domain model.	VIII
Domain model	A visual representation of conceptual classes, their attributes and associations in the problem domain. No methods, no software classes.	II
Elaboration	The second UP phase: the core architecture is built and tested and most requirements are discovered and stabilised.	I
Event (state machine)	A significant occurrence that can trigger a transition, such as cardInserted.	V
Facade	A single simplified interface to a subsystem, hiding its internal classes from clients.	VI
Factory	An object (a Pure Fabrication) whose job is to create other objects, hiding complex creation logic.	VI
Factory Method	Defines a method for creating an object but lets subclasses decide which class to instantiate.	VI
Fully dressed use case	The most detailed use case format: scope, level, stakeholders and interests, preconditions, success guarantee, main success scenario, extensions and more.	I
FURPS+	The requirement categories: Functionality, Usability, Reliability, Performance, Supportability, plus implementation, interface, operations, packaging and legal constraints.	I
Generalisation	An is-a relationship between a general class and a more specific one, drawn with a hollow triangle; must satisfy the 100% and is-a rules.	II
GoF patterns	The 23 design patterns catalogued by the “Gang of Four” (Gamma, Helm, Johnson, Vlissides), in creational, structural and behavioural groups.	VI
GRASP	General Responsibility Assignment Software Patterns: nine principles for assigning responsibilities to objects.	IV
Guard	A boolean condition in square brackets that must be true for a transition (or a sequence-diagram fragment) to happen.	V
Inception	The first UP phase: a short look at vision, scope and feasibility. Not a requirements phase.	I
Indirection	GRASP: assign a responsibility to an intermediate object to mediate between others, so they are not directly coupled.	IV
Information Expert	GRASP: give a responsibility to the class that has the information needed to fulfil it.	IV
Iterative development	Building the system in a series of short, fixed-length iterations, each producing tested, integrated, executable software.	I
Layer	A coarse grouping of classes, packages or subsystems with a cohesive responsibility, such as UI, Domain or Technical Services.	VIII
Lifeline	The dashed vertical line below a participant in a sequence diagram, representing it over time.	III
Logical architecture	The large-scale organisation of the software classes into packages, subsystems and layers.	VIII
Model-View Separation	Domain objects must not know about or directly call UI objects; the UI depends on the domain, not the reverse.	VIII
Multiplicity	How many instances of one class can be associated with one instance of another, e.g. 1, , 0..1, 1...	II
Navigability	An arrow on an association in a DCD showing which object can send messages to (has visibility of) the other.	III
Observer	Lets subscriber objects register with a publisher and be notified when an event happens, without the publisher knowing their concrete classes.	VII
Operation contract	A description of a system operation's preconditions and postconditions: instances created or deleted, attributes changed, associations formed or broken.	II
Package diagram	A UML diagram grouping elements into packages and showing the dependencies between them.	VIII
Polymorphism	GRASP: when behaviour varies by type, assign it to the types themselves using polymorphic operations, instead of testing the type.	IV
Protected Variations	GRASP: identify points of predicted variation or instability and wrap a stable interface around them.	IV
Pure Fabrication	GRASP: invent a class that does not represent a domain concept, to achieve high cohesion and low coupling (e.g. a persistence store).	IV
Quality scenario	A short, measurable statement of a quality requirement, in the form stimulus and measurable response.	VIII
Representational gap	The gap between how we think about the domain and the software that represents it. Naming software classes after domain concepts keeps it low.	II
Responsibility	A contract or obligation of a class: either doing (creating, calculating, coordinating) or knowing (its data, related objects, derived values).	IV
Singleton	Ensures a class has exactly one instance and provides a global point of access to it, usually a static getInstance().	VI
State	A condition of an object at a moment in time, between events.	V
State machine diagram	A diagram of the states of an object and the transitions between them triggered by events.	V
Strategy	Defines a family of interchangeable algorithms, each in its own class behind a common interface, chosen at run time.	VII
Supplementary Specification	The UP artefact recording requirements not captured in use cases, mainly non-functional ones (the URPS+ of FURPS+).	I
System operation	An operation the system offers as a black box, triggered by a system event from an actor; shown in an SSD.	II
System sequence diagram (SSD)	A sequence diagram showing, for one use case scenario, the events actors send to the system as a black box, and the system's replies.	II
Technical memo	A record of one architectural decision: the issue, a solution summary, the factors, the solution, motivation, unresolved issues and alternatives considered.	VIII
Template Method	Defines the skeleton of an algorithm in a superclass method, letting subclasses override particular steps.	VII
Transition	A relationship between two states, triggered by an event: when the event occurs (and the guard holds), the object moves to the target state.	V
Unified Process (UP)	Larman's iterative software process, with phases Inception, Elaboration, Construction and Transition, and disciplines such as Requirements and Design.	I
Use case	A collection of related success and failure scenarios that describe an actor using the system to achieve a goal.	I
Use case diagram	A context diagram of the system boundary, the actors and the names of the use cases; the text holds the actual requirements.	I
Visibility	The ability of one object to see or refer to another: attribute, parameter, local or global visibility.	III