A MODEL is a SIMPLIFIED REPRESENTATION of reality, created to help us understand, communicate about, or predict the behaviour of something complex. THE DEFINING PROPERTY IS OMISSION. A model that included everything would be as complex as the thing itself and therefore useless. A map of a city that showed every brick would be the size of the city. THE VALUE OF A MODEL IS IN WHAT IT LEAVES OUT, and choosing what to omit is the modelling skill. WHY WE MODEL SOFTWARE — four reasons: 1. TO MANAGE COMPLEXITY. Humans reason about roughly seven things at once; a system has thousands. A model presents one manageable view. 2. TO COMMUNICATE. A model is a shared artefact that developers, analysts and customers can all point at. Code cannot serve this role because most stakeholders cannot read it. 3. TO REASON BEFORE BUILDING. You can find a flaw in a model for the cost of a discussion; the same flaw in code costs a rewrite — the cost-of-change curve from the design unit. 4. TO CAPTURE DECISIONS. A model records what was decided and often why, which is what a maintainer needs years later. THE FUNDAMENTAL PRINCIPLES OF MODELLING (Booch, Rumbaugh, Jacobson): · the choice of what models to create has a profound influence on how a problem is attacked and how a solution is shaped · every model may be expressed at different levels of precision · the best models are CONNECTED TO REALITY · no single model is sufficient — every non-trivial system is best approached through a small set of nearly independent models THAT LAST PRINCIPLE IS THE 4+1 INSIGHT from the design model topic: several views, and scenarios to tie them together. A MODEL vs A DIAGRAM — a distinction students often miss: the MODEL is the underlying set of elements and their relationships — the semantic content a DIAGRAM is one VIEW of part of that model, a projection Several diagrams can show the same model from different angles, and a change to the model should be reflected in every diagram that shows the affected elements. This is why modelling tools maintain a repository rather than a folder of pictures, and why hand-drawn diagrams drift out of consistency with each other.

THE TWO MODELS THAT MATTER MOST IN OBJECT-ORIENTED WORK, and the line between them: THE ANALYSIS MODEL — "WHAT" Describes the PROBLEM DOMAIN. It is written in the vocabulary of the users and the business, and deliberately contains NO implementation decisions. · classes correspond to real-world concepts: Applicant, Licence, Payment, Officer · attributes are named but often untyped · no visibility markers, no technical infrastructure · the question it answers: what things exist in this business, and how do they relate? ALSO CALLED the conceptual model, the domain model, or the essential model. THE DESIGN MODEL — "HOW" Describes the SOLUTION. It adds everything needed to implement: · types, visibility, multiplicities, exceptions · solution-domain classes with no business counterpart: controllers, repositories, factories, caches · solution-domain attributes: the `version` field for optimistic locking from the design model topic · the technical layers: user interface, persistence, infrastructure THE TEST FOR WHICH SIDE SOMETHING BELONGS ON: could you explain this element to a licence officer in their own vocabulary? "Applicant" yes; "ApplicationRepository" no. The first is analysis, the second is design. WHY KEEP THEM SEPARATE? · the analysis model can be VALIDATED BY THE CUSTOMER, who can confirm "yes, an application does have exactly one applicant" — they cannot validate a repository pattern · the analysis model OUTLIVES the design. The business concept of a licence application will still be true after three technology migrations, so the analysis model is the stable, reusable asset. · mixing them means implementation decisions get made during analysis, before enough is known — and get frozen because they are embedded in the agreed document THE COMMON FAILURE: an "analysis model" full of technical classes, produced by developers thinking about implementation. The symptom is a diagram the customer cannot read, which means the validation step is impossible and the model's main purpose has been lost. THE THREE MODELLING PERSPECTIVES (Steve Cook and John Daniels), useful for knowing what a diagram is claiming: CONCEPTUAL describes the domain concepts themselves, independent of any software SPECIFICATION describes the interfaces of the software, not the implementation IMPLEMENTATION describes the classes as they will be coded The SAME class diagram notation is used for all three, which is a genuine source of confusion — a reader must know which perspective is intended. Label your diagrams.

MODELLING HAS A COST, and the honest question is how much is worth paying. A WORKED JUDGEMENT — four situations, same team: (a) A 3-CLASS UTILITY, one developer, two days' work. Modelling cost: 2 hours to draw and review. Benefit: essentially none. Three classes fit in one head. VERDICT: don't model. Write the code. (b) A 40-CLASS SUBSYSTEM, four developers, three months. Modelling cost: ~3 days of design work and review. Benefit: the four developers can work in parallel because the class boundaries and interfaces are agreed. Without the model they must either work sequentially or continually renegotiate interfaces. QUANTIFY IT: if a missing interface agreement causes each developer 2 hours of rework per week over 12 weeks: 4 developers × 2 h × 12 weeks = 96 hours = 12 days against 3 days of modelling. A 4× return, and that excludes the integration failures. VERDICT: model the class structure and the interfaces. (c) A DOMAIN NOBODY ON THE TEAM UNDERSTANDS — insurance underwriting, say. Benefit: the model is the vehicle for LEARNING the domain and for having the domain expert correct you. Here the model's value is the CONVERSATION it enables, not the diagram it produces. VERDICT: model, and expect to redraw it three times. The redrawing is the work, not waste. (d) A SYSTEM THAT WILL BE MAINTAINED FOR 15 YEARS BY PEOPLE NOT YET HIRED. Benefit: the model is the only orientation a newcomer will have. Code tells you what happens; a model tells you what the parts are and why. VERDICT: model, and — critically — KEEP IT CURRENT or delete it. THE PRINCIPLE ACROSS ALL FOUR: MODEL WHERE THERE IS SOMETHING TO DECIDE OR SOMETHING TO AGREE. Model to think, model to communicate, model to remember. Do not model to satisfy a process. THE FAILURE MODES: THE MODEL THAT DRIFTS The diagram says one thing and the code says another. A stale model is WORSE THAN NO MODEL, because a reader trusts it and is misled. The two honest options are to keep it current or to delete it — and deleting an obsolete diagram is a genuine improvement, not a loss. ANALYSIS PARALYSIS Modelling continues because it is comfortable and produces visible artefacts, while no code exists and no feedback has been obtained. The diagnostic: has the model changed anything about what we will build? If several days of modelling have produced no decision, stop and build something. MODELLING EVERYTHING AT UNIFORM DETAIL A 200-class diagram covering an entire system is unreadable and therefore communicates nothing. Model the hard parts in detail and the easy parts not at all — the same risk-proportionate principle as the SQA plan. THE DIAGRAM AS DOCUMENTATION SUBSTITUTE A class diagram shows structure and cannot express WHY a structure was chosen. The rationale — the alternatives rejected and the reasons — is prose, and it is the part maintainers most need. A folder of diagrams with no explanatory text is a common and frustrating handover. THE TEST OF A GOOD MODEL, in one question: DOES SOMEONE MAKE A DIFFERENT DECISION BECAUSE OF IT? If yes, it earned its cost. If it merely restates what the code already says, it is documentation debt that will drift and mislead.