An ASSOCIATION is a relationship between conceptual classes indicating a MEANINGFUL AND INTERESTING CONNECTION. WHICH ASSOCIATIONS ARE WORTH RECORDING? Larman's guidance: include those for which KNOWLEDGE OF THE RELATIONSHIP NEEDS TO BE PRESERVED for some duration — the "need-to-know" associations. Not every conceivable pairing. THE COMMON ASSOCIATIONS LIST — a checklist analogous to the concept category list, in rough priority order: A is a PHYSICAL OR LOGICAL PART OF B A is PHYSICALLY OR LOGICALLY CONTAINED IN B A is a DESCRIPTION OF B A is a LINE ITEM of a transaction B A is KNOWN/LOGGED/RECORDED/CAPTURED in B A is a MEMBER OF B A is an ORGANISATIONAL SUBUNIT OF B A USES OR MANAGES B A COMMUNICATES WITH B A is RELATED TO A TRANSACTION B A is a TRANSACTION RELATED TO ANOTHER TRANSACTION B A is NEXT TO B A is OWNED BY B A is an EVENT RELATED TO B THE HIGH-PRIORITY ONES, worth applying first: A is a part of B · A is contained in B · A is recorded in B These three catch most of what matters in a business system. NAMING AN ASSOCIATION: use a VERB PHRASE that makes the relationship readable as a sentence, formatted Class-VerbPhrase-Class. Applicant ─── Submits ──▶ Application Officer ─── Records ──▶ Payment A diagram whose associations are unnamed forces every reader to guess the meaning. "Application ─── District" could be "belongs to", "was issued in", or "is valid in" — three different rules. MULTIPLICITY IS THE PART THAT MATTERS MOST. It states a constraint that will be enforced, and it must be read in both directions: Applicant 1 ────── * Application "one Applicant submits zero or more Applications" "one Application is submitted by exactly one Applicant" A CRITICAL SUBTLETY: MULTIPLICITY DEPENDS ON THE MOMENT you ask, and on the scope of interest. Is it "an Application has 0..1 Licence" or "1"? → 0..1, because an application has no licence until issued. Choosing 1 would forbid the entire pre-issuance lifecycle. Is it "a Counter has * Officers" or "0..1"? → depends on whether you care about "who is at this counter right now" (0..1) or "who has ever worked it" (*). ASK WHAT QUESTION THE SYSTEM MUST ANSWER. MULTIPLE ASSOCIATIONS BETWEEN THE SAME TWO CLASSES are legitimate and often necessary: Officer ─── Reviews ──▶ Application Officer ─── Issues ──▶ Application These are different relationships with different rules — a reviewing officer and an issuing officer may be required to be different people, which is a genuine control (separation of duties). One association could not express that. ROLE NAMES clarify each end where the class name is not enough: Person [supervisor] ─── manages ──▶ [subordinate] Person Self-associations require role names to be readable at all. NAVIGABILITY (the arrowhead) is a DESIGN concern, not an analysis one. In a conceptual model, leave associations undirected — deciding which object holds a reference to which is a visibility decision belonging to design (ACtE0805).

An ATTRIBUTE is a logical data value of an object. WHICH ATTRIBUTES TO INCLUDE: those for which the requirements suggest or imply a need to REMEMBER INFORMATION. If no use case needs it and no report shows it, it does not belong in this iteration's model. THE PRIMARY RULE, and it is worth stating as a rule because it is broken constantly: ATTRIBUTES SHOULD BE PURE DATA VALUES — Boolean, Date, Number, String, Time, and domain-specific simple types such as Money, PhoneNumber, PostalCode, SocialSecurityNumber, ProductCode. A RELATIONSHIP TO ANOTHER CONCEPT IS AN ASSOCIATION, NOT AN ATTRIBUTE. THE CLASSIC VIOLATION, and why it is wrong: ✗ Application applicationNo : String districtCode : String ← this is a relationship officerId : String ← so is this ✔ Application ── belongs to ──▶ 1 District Application ── issued by ──▶ 0..1 Officer WHY IT MATTERS RATHER THAN BEING PEDANTRY: · the foreign-key version HIDES the relationship, so the diagram no longer shows the domain's structure · it loses the MULTIPLICITY — a String cannot express "exactly one" versus "zero or more" · it imports a DATABASE IMPLEMENTATION TECHNIQUE into a conceptual model, which is the "no design decisions" discipline broken · in code it produces `getDistrictCode()` followed by a lookup, instead of `getDistrict()` — the representational gap widening DATA TYPE VERSUS CONCEPT — the judgement that decides whether something is an attribute or a class of its own. Make it a NON-PRIMITIVE CLASS (a value object) rather than a plain String when: · it is composed of SEPARATE SECTIONS — a phone number, a person's name with title · there are OPERATIONS associated with it, such as validation — a citizen ID with a checksum · it has other ATTRIBUTES — a promotional price with a start and end date · it is a QUANTITY WITH A UNIT — money with a currency, which is the standard example · it is an ABSTRACTION of one or more types with some of these qualities — an item identifier WORKED — why Money is not a Number: amount : double ← wrong twice over (a) floating point cannot represent 0.01 exactly, so repeated addition drifts; currency needs a decimal or integer-minor-units representation (b) a bare number carries no CURRENCY, so adding NPR to USD is a compile-time-invisible error money : Money { amount : Decimal, currency : Currency } → now `add` can refuse mismatched currencies, and the rounding rule lives in one place. THE TYPE PREVENTS A CLASS OF DEFECT, which is the argument for value objects generally. DERIVED ATTRIBUTES, marked with a leading /: Application appliedOn : Date / age : int (computed from appliedOn) / feeDue : Money (computed from District.feeRate and the licence category) RECORDING SOMETHING AS DERIVED IS A REAL DECISION: it says the value must never be stored independently, which prevents the defect of a stored total disagreeing with its inputs. If the derivation is expensive it may be CACHED in design — but that is a design decision, made later, and the model still records that it is logically derived. ATTRIBUTES THAT DO NOT BELONG IN A CONCEPTUAL MODEL: · foreign keys and surrogate identifiers, per the rule above — unless the identifier is a real-world one the domain uses, like a licence number, which IS a legitimate attribute · `createdAt` / `updatedAt` audit columns, unless the domain genuinely asks about them · flags that duplicate derivable information — `isPaid : Boolean` when the presence of a Payment association already says it. Duplicated state is state that can disagree with itself.

A FIRST-CUT MODEL, then the questions that fix it. The questions are the technique. FIRST CUT, drawn from the use cases alone: Applicant Application - citizenId : String 1 * - applicationNo : String - fullName : String ────── - appliedOn : Date - districtCode : String - status : String - fee : double - officerId : String - isPaid : boolean THE INTERROGATION — six questions and what each changed: Q1 "Can one application have two applicants — a joint application for a company vehicle?" A: yes, for commercial licences. → multiplicity changes from 1 to 1..*, and this is a substantial change: every screen, query and validation assuming a single applicant is affected. FOUND IN A CONVERSATION rather than in integration testing. Q2 "Is districtCode the applicant's home district or the office where they applied?" A: they can differ — you may apply anywhere. → TWO separate associations were hiding inside one attribute: Applicant ── resides in ──▶ 1 District Application ── lodged at ──▶ 1 DistrictOffice This is exactly the failure the foreign-key rule predicts: an attribute concealed a relationship, and concealed that there were two of them. Q3 "Is status just a value, or do you need its history?" A: an auditor must see every change with who and when. → status remains an attribute (the current value) AND a new concept appears: Application ◆── * StatusChange - from, to : Status - changedOn : Instant - changedBy : Officer Q4 "Is the fee always the same for a given category?" A: it varies by district, and the rates changed in July. → `fee : double` was wrong three times: it is Money not double; it is derived not stored; and the rate is EFFECTIVE-DATED: FeeRate - category, district - amount : Money - validFrom, validTo : Date Application./feeDue is derived from the FeeRate in force ON THE APPLICATION DATE — not the current rate, which would silently reprice historical applications. This is the "modelling time as an afterthought" trap, caught. Q5 "Which officer is officerId — who reviewed it or who issued it?" A: they must be different people. → two associations, and a CONSTRAINT worth writing on the diagram: {reviewedBy ≠ issuedBy} A separation-of-duties control, now visible in the model instead of buried in code. Q6 "What does isPaid mean if a payment was refunded?" A: it should reflect the current settled state. → the flag is DELETED. It duplicates information already present in the Payment association, and the refund case proves the two can disagree. `/ isPaid` becomes derived, or the question is answered by asking the payments. THE REFINED MODEL: Applicant Application - citizenId : CitizenId 1..* * - applicationNo - fullName : PersonName ─────── - appliedOn : Date │ - status : Status │ resides in / feeDue : Money ▼ 1 / isPaid : Boolean District ◆ ▲ 1 │ * │ lodged at StatusChange DistrictOffice ◀──── 1 * ──── Application Application ── reviewedBy ──▶ 0..1 Officer Application ── issuedBy ──▶ 0..1 Officer {reviewedBy ≠ issuedBy} FeeRate - category, district, amount, validFrom, validTo COUNT THE OUTCOME: 6 questions changed 1 multiplicity, split 1 attribute into 2 associations, added 2 concepts, deleted 1 attribute, corrected 1 data type, and surfaced 1 business constraint. NONE OF IT REQUIRED CODE, AND ALL OF IT WOULD OTHERWISE HAVE BEEN FOUND DURING TESTING OR AFTER RELEASE. That ratio is the argument for conceptual modelling.