A CONCEPTUAL MODEL (also domain model, or in Larman's terminology just "the domain model") is a visual representation of the CONCEPTUAL CLASSES or real-situation objects in a problem domain. IT IS NOT A DATA MODEL AND NOT A SOFTWARE DESIGN. Three things it explicitly is not: · not a description of software classes — no Controller, Repository or Factory appears · not a database schema — no foreign keys, no normalisation decisions, no surrogate identifiers · not a description of responsibilities or behaviour — operations are usually omitted entirely at this stage WHAT IT CONTAINS: CONCEPTUAL CLASSES the domain concepts ASSOCIATIONS the meaningful relationships between them, with multiplicities ATTRIBUTES the data belonging to a concept WHY IT IS WORTH BUILDING: · it is the VISUAL DICTIONARY of the domain — a picture of the glossary · it is VALIDATABLE BY THE DOMAIN EXPERT, who can confirm or deny every multiplicity · it LOWERS THE REPRESENTATIONAL GAP between the software and the world it models, so the code reads like the domain · it is the raw material for the design class diagram THE REPRESENTATIONAL GAP is worth naming. If the domain talks about applications and licences but the code talks about records and rows, every conversation between a developer and a domain expert requires translation, and translations lose things. Keeping the software's vocabulary close to the domain's removes a permanent source of misunderstanding.

TWO STANDARD TECHNIQUES. 1. USE A CONCEPTUAL CLASS CATEGORY LIST — a checklist of the kinds of thing that are usually concepts. Larman's list: business transactions Payment, Application transaction line items ApplicationLine products or services LicenceType where the transaction is Register, Counter recorded roles of people or Applicant, Officer, organisations District Office places DistrictOffice, Counter noteworthy events StatusChange, Issuance (with a time or place) physical objects Licence (the card), PrintQueue descriptions of things LicenceTypeSpecification catalogues FeeSchedule containers Register, Batch things in a container Application, Licence other collaborating NationalIdService, systems PaymentGateway records of finance, work, Receipt, AuditEntry, contracts, legal matters Endorsement financial instruments Payment, Refund schedules, manuals, FeeSchedule, RegulationRef documents THE CHECKLIST'S VALUE is that it prompts categories you would not have thought of — "descriptions of things" and "noteworthy events" in particular are consistently under-identified. 2. NOUN PHRASE IDENTIFICATION — read the use cases and underline the noun phrases. Each is a CANDIDATE concept or attribute. ✔ mechanical, fast, and grounded in agreed text ✘ noisy: natural language is ambiguous, and the same concept appears under several names while one name may mean several concepts WORKED — noun phrases from UC-05 "Issue a Licence": "Officer enters the application number." "System displays the approved application and the fee due." "Officer confirms the applicant's identity." "Officer records the fee payment." "System allocates a licence number and records status ISSUED with an audit entry." "System prints the licence." "System notifies the applicant by SMS." CANDIDATES EXTRACTED: Officer, application number, System, application, fee, applicant, identity, payment, licence number, status, audit entry, licence, SMS NOW CLASSIFY THEM — this filtering is the actual skill: CONCEPTS (things with identity and their own attributes): Officer, Application, Payment, Licence, AuditEntry, Applicant ATTRIBUTES (data belonging to a concept, no identity of their own): application number → Application.applicationNo fee → Application.feeDue (derived) licence number → Licence.licenceNo status → Application.status NOT IN THE MODEL AT ALL: System — the system itself is not a domain concept; it is the thing being built identity — a process, not a thing; it appears as the outcome of Verify Identity SMS — a delivery mechanism, i.e. a solution concern, not a domain concept NEEDS A DECISION: Licence — is it the same thing as an Application whose status is ISSUED, or a separate concept? THE DOMAIN EXPERT MUST ANSWER. If a licence can be reprinted, replaced when lost, or endorsed independently of the application, it is a SEPARATE CONCEPT with its own lifecycle. Here it is: a lost licence is replaced without a new application, so Licence is separate. → this single question changes the model substantially, and it was surfaced purely by asking whether two nouns name one thing. THE ATTRIBUTE-OR-CONCEPT TEST: if you would ever need to refer to it independently, track its history, or attach further data to it, it is a CONCEPT. Otherwise it is an attribute. "status" is an attribute — but "StatusChange" (with a time and an officer) is a concept, because you need its history. That distinction is exactly what the audit requirement forces. THE "LOWER REPRESENTATIONAL GAP" GUIDELINE: when in doubt, keep the domain's own name. If officers say "endorsement", the class is Endorsement, not LicenceAttributeRecord.

DESCRIPTION or SPECIFICATION CLASSES — one of the most useful modelling insights, and regularly examined. THE PROBLEM. Suppose the model has: Licence licenceNo, issuedOn, expiresOn, category, feePaid, categoryDescription, categoryValidityYears, categoryMinimumAge Now ALL LICENCES OF CATEGORY B ARE DELETED — say none are currently issued. THE DESCRIPTION OF CATEGORY B IS LOST: its validity period, its minimum age, its fee. The system can no longer answer "what is a category B licence?" merely because none exists at the moment. THE SOLUTION — add a SPECIFICATION CLASS: LicenceCategory (the specification) code, description, validityYears, minimumAge, baseFee 1 │ describes * Licence (the instance) licenceNo, issuedOn, expiresOn, feePaid ADD A SPECIFICATION CLASS WHEN: · there is a need for a description of an item or service, independent of the current existence of any such item · deleting instances results in a loss of information that needs to be maintained, due to the incorrect association of information with the instance · it reduces redundant or duplicated information THE REDUNDANCY POINT IS PRACTICAL: without the specification class, every category-B licence stores "3 years" and "minimum age 18". Ten thousand licences hold ten thousand copies of the same fact, and changing the validity period means updating them all — or worse, updating some. THE SAME PATTERN, everywhere: ProductDescription / ProductItem FlightDescription / Flight CourseDescription / CourseOffering / Enrolment Recognising it is a large part of what distinguishes a competent domain model from a naive one. THE TRAPS: MODELLING SOFTWARE CLASSES The single most common error. A "domain model" containing ApplicationManager, DataAccessLayer or LicenceService is a design sketch wearing the wrong label, and the customer cannot validate it. THE DIAGNOSTIC from the modelling topic: could you explain this to a licence officer in their words? MISSING CONCEPTS BECAUSE THEY HAVE NO ATTRIBUTES YET A concept with no attributes identified is still a concept if the domain names it. Do not omit it because the attribute list is empty — attributes arrive later, and an omitted concept distorts the associations around it. CONFUSING A CONCEPT WITH ITS ROLE Applicant and Officer may both be Person. Whether to model Person with roles or two separate concepts depends on whether one individual can be both, and whether the domain cares. Ask; do not assume. PREMATURE ATTRIBUTES OF FOREIGN KEY TYPE Writing `Application.districtCode : String` instead of an ASSOCIATION to District. Attributes should be simple data types; A RELATIONSHIP TO ANOTHER CONCEPT IS AN ASSOCIATION, NOT AN ATTRIBUTE. This error imports database thinking into a conceptual model, and it hides the relationship from the diagram. MODELLING TIME AS AN AFTERTHOUGHT "What was the fee rate last March?" is unanswerable if District.feeRate is a single value. If the domain asks historical questions, the model needs an effective-dated concept (FeeRate with validFrom/validTo) — and discovering this early is much cheaper than retrofitting it. THE ITERATIVE REALITY: a conceptual model is built incrementally, one iteration's use cases at a time. Attempting a complete model of the whole domain up front is the analysis-paralysis failure — and unnecessary, since only the concepts touched by the next iteration need detail.