The UNIFIED MODELING LANGUAGE is a general-purpose visual modelling language for specifying, visualising, constructing and documenting the artefacts of a software system. It is an OMG standard. UML IS A LANGUAGE, NOT A METHOD. It gives you notation; it does not tell you what order to do things in or which diagrams to draw. The method is separate — the Unified Process is one method that uses UML, but so is any other. ITS ORIGIN: three competing methods converged in the mid-1990s — Booch's method, Rumbaugh's Object Modeling Technique (OMT) and Jacobson's Objectory (which contributed use cases). UML 1.1 was adopted by the OMG in 1997; UML 2.x is current. THE FOURTEEN DIAGRAM TYPES, in the standard two-way split: STRUCTURE DIAGRAMS — what the system IS CLASS classes, attributes, operations and relationships. The most used diagram in all of UML. OBJECT a snapshot of instances at one moment — useful for explaining a tricky structure with a concrete example COMPONENT components and their provided/required interfaces (the CBSE lollipop and socket) DEPLOYMENT nodes, artefacts and the physical topology PACKAGE grouping and dependencies between groups COMPOSITE the internal structure of a class, STRUCTURE with parts and ports PROFILE extending UML itself with stereotypes and tagged values BEHAVIOUR DIAGRAMS — what the system DOES USE CASE actors, use cases, system boundary ACTIVITY workflow with decisions, forks and joins — the closest thing to a flowchart STATE MACHINE the states of one object and the events that cause transitions INTERACTION DIAGRAMS, a sub-family: SEQUENCE messages between participants, ordered down the page. Second-most used diagram. COMMUNICATION the same interaction shown as a graph of links (formerly "collaboration") TIMING state against time, for real-time work INTERACTION how several interactions compose OVERVIEW WHICH ONES ARE ACTUALLY USED: in practice, class and sequence diagrams dominate, with use case, state machine, activity and deployment appearing where they earn their place. The other seven are specialised. KNOWING THAT IS PART OF USING UML WELL — drawing all fourteen for one system is the "modelling everything at uniform detail" failure from the modelling topic. THE THREE WAYS UML IS USED (Fowler's distinction, and it resolves most arguments about UML): UML AS SKETCH informal, selective diagrams to explore or communicate an idea. Drawn on a whiteboard, often discarded. THE DOMINANT USE. UML AS BLUEPRINT detailed diagrams intended to specify the code completely, from which code is written or generated. UML AS PROGRAMMING the model IS the source; code is LANGUAGE generated and the diagram is edited (MDA). Rarely successful in practice. Most criticism of UML is really criticism of the blueprint and programming-language uses. As sketch it remains genuinely useful.

THE CLASS BOX, three compartments: ┌─────────────────────────────┐ │ LicenceApplication │ ← name (bold, singular) ├─────────────────────────────┤ │ - applicationNo : String │ ← attributes │ - appliedOn : LocalDate │ │ - status : Status │ │ / age : int │ ← / = derived │ + MAX_FEE : Money {readOnly}│ ├─────────────────────────────┤ │ + submit() : void │ ← operations │ + approve(o : OfficerId) │ │ - assertTransition(s) │ │ + count() : int │ ← underlined = static └─────────────────────────────┘ VISIBILITY MARKERS — memorise these: + public visible to all - private visible only within the class # protected visible to the class and its subclasses ~ package visible within the same package OTHER ADORNMENTS: italic class name = ABSTRACT class italic operation = abstract operation underlined member = static (class-scope) «interface» = a stereotype naming the kind {readOnly}, {ordered} = property strings/constraints / before a name = a DERIVED attribute (computed, not stored) — a genuinely useful notation that many people miss RELATIONSHIPS — the notation and, more importantly, the meaning: ASSOCIATION ──────────── A structural relationship: instances of one class are connected to instances of another. Adorned with a name, multiplicities and optionally role names and navigability arrows. Applicant 1 ──── submits ────▶ * Application MULTIPLICITY, read at the FAR end: 1 exactly one 0..1 zero or one (optional) * zero or more 1..* one or more 2..5 between two and five READING RULE: "one Applicant submits zero or more Applications; one Application is submitted by exactly one Applicant." AGGREGATION ────────────◇ (hollow diamond) A whole/part relationship where the part CAN EXIST INDEPENDENTLY of the whole and may be shared. Department ◇──── * Employee An employee survives the department's dissolution. COMPOSITION ────────────◆ (filled diamond) A stronger whole/part relationship: the part BELONGS TO EXACTLY ONE WHOLE and its lifetime is controlled by the whole. Application ◆──── * ApplicationLine Delete the application and its lines go with it. THE TEST: if the whole is deleted, must the part be deleted too? Yes → composition. No → aggregation. (In practice UML's aggregation is weakly defined and many authors advise using only composition and plain association. Know both for the exam; prefer clarity in practice.) GENERALISATION ────────────▷ (hollow triangle, solid line) An inheritance/is-a relationship, arrow pointing to the SUPERCLASS. Officer ◁──── CounterOfficer REALISATION - - - - - - -▷ (hollow triangle, dashed) A class implements an interface. DEPENDENCY - - - - - - -▶ (open arrow, dashed) A weaker relationship: one element uses another, typically as a parameter or local variable, without holding a reference. ASSOCIATION CLASS a class attached to an association by a dashed line, holding attributes OF THE RELATIONSHIP itself. Officer ──── Application │ «assoc» Assignment assignedOn, role Use it when the relationship has its own data. This is the notation people reach for a workaround instead of learning. QUALIFIED ASSOCIATION a key in a small box at one end, indicating lookup by that key: Register [applicationNo] ──── 0..1 Application which maps directly to a Map in code.

THE LICENCE SYSTEM, as a class diagram in text: «interface» Notifier + notify(a : Application) : void △ ┆ (realisation) ┌───────┴────────┐ SmsNotifier EmailNotifier Applicant Application - citizenId : String 1 * - applicationNo : String - fullName : String ───────── - appliedOn : LocalDate - dateOfBirth : Date submits - status : Status / age : int {derived} / feeDue : Money {derived} + submit() : void + approve(o : OfficerId) ◆ │ 1 │ * StatusChange - from : Status - to : Status - changedOn : Instant Officer (abstract) District # officerId : String * 1 - code : String {2 digits} + name() : String ──────── - name : String △ serves - feeRate : Money │ ┌────┴─────┐ CounterOfficer ReviewingOfficer Application * ──── 1 District (belongs to) Officer * ──── * Application └── association class Assignment - assignedOn : Instant - role : AssignmentRole NOW READ WHAT IT ASSERTS, decision by decision — this is the skill being examined: 1. Applicant 1 —— * Application, so an applicant may have MANY applications but an application has EXACTLY ONE applicant. A joint application is impossible in this model. If the business allows one, the model is wrong. 2. Application ◆—— * StatusChange is COMPOSITION: status history belongs to the application and dies with it. That is a claim with an audit consequence — recall from the configuration and audit topics that the trail must be retained. If applications are ever deleted, composition is the wrong choice and the history must be aggregated or stored separately. 3. `/ feeDue` is DERIVED — computed from the district's feeRate and the application type, not stored. This prevents the classic defect of a stored total drifting out of agreement with its inputs. 4. Officer is ABSTRACT (italic), so no plain Officer can be instantiated; every officer is a counter or reviewing officer. That is a modelling decision worth being deliberate about — it forbids an officer who is neither. 5. Officer * —— * Application with an ASSOCIATION CLASS. A many-to-many with its own data cannot be expressed with attributes on either end: "when was this officer assigned to this application, and in what role?" belongs to the PAIR. Without the association class you would invent an `Assignment` class anyway, which is exactly what it is. 6. Notifier is an «interface» with two realisations, so the system can gain a third notification channel by adding a class — the polymorphism benefit from the development cycle topic, visible in the diagram. WHAT THE DIAGRAM CANNOT TELL YOU, and this matters: · the ORDER in which anything happens (that is a sequence diagram) · which state transitions are legal (that is a state machine) · any non-functional requirement · why these choices were made rather than others — the rationale, which is prose THE DISCIPLINE OF READING A CLASS DIAGRAM: walk every multiplicity aloud in both directions and ask whether the business agrees. Most modelling errors are multiplicity errors, and they are cheap to find this way and expensive to find in a database schema.