Naming conventions for models
The only test that settles a naming argument: can somebody who was not in the room find this element in six months by typing what they would call it.
5 min readModelling practice2 of 3
01The searchability test
Naming arguments are unwinnable because both sides are arguing about taste. There is one criterion that is not taste: in six months, will somebody who was not part of this conversation find this element by typing the word they would use for it?
That question decides almost every case people actually argue about, and it decides them in the direction the conventional advice already points - which is a good sign that the convention was never arbitrary. It also has the advantage of being checkable: open the model's search box, type the word a colleague from another team would use, and see whether the element comes back.
02The conventions the test implies
| Element | Notation | What it means |
|---|---|---|
| Classifiers | Singular noun | Order, not Orders or OrderEntity. The multiplicity says there are many; the suffix says nothing. |
| Operations | Verb, then object | cancel(reason), not orderCancellation(). The class it lives on already supplies the noun. |
| Business processes | Verb phrase | Handle claim, not Claim handling. A process is something being done. |
| Services | Noun phrase | Claim assessment, not Assess claim. A service is something offered, and the difference from a process is the whole point. |
| Association ends | Role, from the far side | manager and reports, which is the only way an association between one class and itself reads. |
| Views | Audience and question | Payments - what calls the ledger beats Payments overview, which describes every view ever drawn. |
The service-versus-process row is the one that repays attention in ArchiMate specifically. The language distinguishes what an organisation does from what it offers, and naming both with the same grammar throws that distinction away at exactly the point a reader needs it.
03Acronyms, prefixes, and the things teams argue about
Acronyms: spell them out on first definition, then use them. If the business genuinely says "SLA" and never says "service level agreement", the element is called SLA and its description contains the expansion - so the search for either word finds it. The failure is an element called SvcLvlAgmt, which matches no query anybody would type.
Type prefixes: no. C_Order, IPayment, tblCustomer - the model already knows what kind of element each is and draws it differently. A prefix adds characters to every name and information to none, and it puts every class in the model under one letter alphabetically.
Language: pick one and write it down. A model with German element names and English operation names is the state teams drift into rather than choose, and it doubles every search. If the business vocabulary is not English, the model is not English - that is a coherent choice, and much better than half of one.
In one line each
- 01The test is whether a stranger finds the element by typing the word they would use.
- 02Singular nouns for classifiers; verb-then-object for operations.
- 03Verb phrase for a process, noun phrase for a service - the distinction is load-bearing.
- 04Spell acronyms out in the description; never abbreviate into something unsearchable.
- 05No type prefixes, and one language per model, written down.
04Common questions
What is the best naming convention for UML elements?
Singular nouns for classifiers, verb phrases for behaviour, and the words the business already uses rather than the words the code uses. Whichever convention you pick matters far less than whether a stranger can find the element by typing what they would naturally call it.
Should class names be singular or plural?
Singular. A class describes one instance, so Order rather than Orders - the multiplicity on the relationship is what says there are many. The plural form belongs on a database table, which is a different thing and is why the two often disagree.
Should I use the business term or the technical term?
The business term, in the model. If the business says claim and the code says case, the model says claim and records the mapping in a note. A model in code vocabulary can only be read by people who already know the code, which is the audience that needed it least.
Related reading