17  Domain Conceptual Models

Domain conceptual models are highly effective for learning and clarifying key concepts and terminology of the application domain. They are typically represented as UML class diagrams, supplemented by a glossary. This chapter presents the notation and detailed guidelines for creating effective domain conceptual models.

17.1 In a Nutshell

What

A domain conceptual model defines the types of entities in the world, along with their attributes and associations. It uses a graphical notation that is a subset of UML class diagrams.

Figure 17.1 shows a portion of a domain conceptual model for an ambulance dispatching system.

Figure 17.1: Portion of a domain conceptual model for an ambulance dispatching system

This model includes three entity types:

  • Emergency Call, with attributes date and time;
  • Incident, with attribute location; and
  • Ambulance, with attributes location and status.

It includes three associations:

  • Reporting: an emergency call reports an incident;
  • MobilizedTo: an ambulance may be mobilized to an incident; and
  • AtIncidentLocation: an ambulance may be at some incident location, attending to the incident.

Why

In requirements engineering, domain conceptual model serves two main purposes:

  1. To understand stakeholders’ concepts and terminology;
  2. To define a common terminology (a shared language) for everyone involved - from business stakeholders to the software development team.

Many misunderstandings in software development result from imprecise and inconsistent terminology:

  • People use different words for the same concept (synonyms) or the same word for different concepts (homonyms).
  • Some terms lack a clear definition, or their meaning shifts depending on context.

Often, people are unaware of these inconsistencies, which exacerbates misunderstandings and creates unnecessary conflicts.

A well-defined conceptual model, supported by a glossary, is an effective solution to these challenges:

  • The process of elaborating the model helps you learn the application domain’s concepts and terminology;
  • The shared language reduces misunderstanding and improves collaboration with stakeholders.
  • The model enables the software development team to better understand the domain, facilitating software design, implementation, verification, and evolution.

The primary purpose of a domain conceptual model is to identify, name, and define the key concepts in the application domain—not to design the software itself. While domain conceptual models can support software design—particularly in object-oriented design, domain-driven design, model-driven dngineering, and some low-code platforms—their primary use in requirements engineering is independent of these contexts. To create a high-quality domain conceptual model, even within these contexts, it’s best to initially disregard all software design considerations.

Who

Software engineers–including requirements engineers and the software development team–are the primary producers and consumers of these models, particularly in their graphical form (the UML class diagrams).

For many stakeholders, class diagrams appear overly technical and intimidating, so they are rarely shared with them. In contrast, the supporting glossary of terms is far more accessible. It provides a clear, shared vocabulary that all stakeholders can understand and use effectively.

When

Domain conceptual models are valuable throughout all stages of requirements engineering and software development. We begin constructing a domain conceptual model and glossary during the foundation phase, expand them in the exploration and formulation phases, and maintain them during the evolution phase.

17.2 Concepts and Notation

Notation Summary

Table 17.1: Domain Conceptual Models – Notation Summary
Concept Graphical Notation Meaning
Entity A “thing” with distinct and independent existence
Entity Type E is a set of entities {\(e_1, ..., e_n\)}, called instances of E, that share common characteristics.
Association R is a relation between E1 and E2 (R ⊆ E1 X E2).
Attribute attr is a function from E to T, where T is the attribute’s value type (attr: E → T).
Value Type T is a set of possible values. A value v is immutable and has no distinct identity.
Specialization Every instance of E1 is an instance of E2.

Entities

Definition: Entity

An entity is a “thing” with a distinct and independent existence.

Figure 17.2 shows some entities in an ambulance dispatching system.

Figure 17.2: Entities in an ambulance dispatching system.

Key observations about this definition:

  1. An entity’s existence can be physical (e.g. an ambulance, a student, a classroom) or conceptual (e.g. an incident, a class, a university).
  2. An entity’s distinct and independent nature implies that it has a unique, immutable identity (e.g. ambulance 1, ambulance 2, etc.) that does not refer to other entities.
  3. An entity’s characteristics (i.e. its attribute values and association links to other entities) may change over time (e.g. an ambulance location may change, or it may be mobilized to different incidents at different times).
  4. Describing something as an entity is a modelling choice—a particular way of viewing the world–not a claim about ultimate reality. It means that, for the purposes of the model, we agree to treat this “thing” as having a distinct and independent existence.

Individual entities are not explicitly represented in the domain conceptual model. They are atomic elements described by the model, but they do not appear explicitly within the model.

Entity Types

Definition: Entity Type

An entity type represents a set of entities that share common characteristics. The entities in that set are called instances of the entity type.

Figure 17.3 show three entity types in the ambulance dispatching world:

  • Ambulance represents the set of all possible ambulances;
  • Incident represents the set of all possible incidents;
  • Emergency Call represents the set of all possible emergency calls.
Figure 17.3: Three entity types and their sets of instances

When the context is clear, we can say “entity” as a shorthand for entity type. For example, we can say that the model in Figure 17.1 has three entities.

Naming Guidelines

When naming an entity type:

  • Use a countable noun or noun phrase in singular form.
  • Capitalize all words (with or without space between them).

Examples:

  • Ambulance (a countable noun),
  • Emergency Call or EmergencyCall (a countable noun phrase).

A noun X is countable if you can count: “one X, two Xs, three Xs, etc.” For example, “one ambulance, two ambulances”. Non-countable nouns (like water, rain, air, pollution, money) cannot be counted or put into plural form. If you say “one water, two waters”, you’re counting bottles or glasses of water, not water itself.

Verbalization

Verbalizing a domain conceptual model–that is, describing it in spoken or written words–can help validate the model with stakeholders and test the validity of concepts names.

Entity types are verbalized using the following sentence pattern:

The entity type E is the set of all possible es.

For example, if E is Ambulance, the sentence would be:

The entity type Ambulance is the set of all possible ambulances.

The verbalization helps validate the entity type name. For the name to be valid, the sentence must be grammatically correct and make sense.

Defining Entity Types

To avoid ambiguity and reduce the risk of misunderstanding, each entity type should include a brief definition characterizing its instances. For example:

Entity Ambulance
Definition: A vehicle used for responding to medical emergencies.

Entity Incident
Definition: An event that may require an emergency ambulance response.

Entity Emergency Call
Definition: An call to the emergency service numbers (999 or 112).

These definitions form part of the model’s glossary of terms.

Definition Guideline:

An efficient way to define entity types is to follow Aristotle’s genus-differentia pattern: state the broader category (genus) the entity type belongs to, then specify the distinguishing features (differentia) that set its instances apart from others in that category. For example:

  • An ambulance is vehicle (genus) used for responding to medical emergencies (differentia).
  • An incident is an event (genus) that may require an emergency ambulance response (differentia).
  • An emergency call is a call (genus) to the emergency service numbers (999 or 112) (differentia).

Associations

Definition: Association

An association is a relation between entity types. An association link is an ordered list of entities satisfying this relation at a given time.

Figure 17.4 shows two associations:

  • MobilizedTo between Ambulance and Incident
  • Reporting between Emergency Call to Incident

The bottom of the figure shows association links that hold at a given time. The links may change over time. For example, amb_2 currently mobilized to inc_1 may later be mobilized to inc_2.

Figure 17.4: Associations and association links in the ambulance dispatching world

Notes:

  1. Mathematically, an association is a relation.
    • A binary association R: E1 -> E2 corresponds to a relation \(R \subseteq E1 \times E2\), where association links are pairs \((e1, e2) \in R\).
    • An association can be N-ary (with N \(\geq\) 2). A ternary association R: E1 -> E2 -> E3 corresponds to a relation \(R \subseteq E1 \times E2 \times E3\), where association links are triplets \((e1, e2, e3) \in R\).
    • An association can relate the same entity type more than once. For example, Parent: Person -> Person.
  2. In domain conceptual models, the arrow indicates the reading direction and order of entity types in an association. This differs from standard UML notation, where the arrow represents navigability—an implementation concern irrelevant to requirements engineering. In standard UML, the reading direction is either indicated by an arrowhead next to the association name or implied by the default left-to-right/top-to-bottom reading direction of Western languages (see Figure 17.5). While this book uses association arrows to indicate reading direction, many other sources follow the standard UML notation.
(a) In domain conceptual models, the arrow denotes the reading direction and order of entity types (not navigability!).
(b) In standard UML Notation, the reading direction is shown by an arrowhead beside the association name, which can be omitted if the direction is left-to-right or top-to-bottom.
Figure 17.5: Two Notations for Specifying the Order of Entity Types in Associations

Naming Guidelines

When naming a binary association, use one of the following:

  1. A state verb phrase, in the third person singular.
  2. An action verb phrase, in the present participle or past participle (i.e. for regular verbs, the base verb + -ing or -ed, respectively).
  3. Any phrase that makes a state verb phrase if prefixed by ”is” or “has”.

Capitalize all words (with or without space between them).

A state verb is one that describe a state (e.g. “is”, “has”, “contains”) rather than an action (e.g. “reports”, “mobilizes”, “arrives”).

For example:

  • [Emergency Call] Is Reporting [Incident] (a state verb phrase)
  • [Ambulance] Mobilized To [Incident] (an action verb phrased in the present principle)
  • [Ambulance] At Scene Of [Incident] (makes a state verb phrase if prefixed by “is”)

Verbalization

To verbalize a binary association R: E1 -> E2, use the following sentence structure:

an e1 (is | has) R some e2.

For example:

  • “An emergency call is reporting some incident.”
  • “An ambulance is mobilized to some incident.”
  • “An ambulance is at the scene of some incident.”

More specific verbalization pattern can be used when the association has multiplicity constraints (see Section 17.2.4.4).

Caution: Avoid Naming Associations with Present-Tense Action Verbs!

To create useful domain conceptual modelling, it is essential to understand that an association link represents a static relation that holds between entities at given times–not an action performed by an actor on an object.

For example, an association link in MobilizedTo: Ambulance -> Incident indicates that an ambulance is currently mobilized to an incident. This link represents a static relation between the ambulance and the incident–one that holds at the present moment, may hold at other times, and will not hold at others. It should not be confused with the action of mobilizing the ambulance to the incident, which creates that link.

To avoid conflating associations with actions, refrain from using action verbs in the present tense as association names. For instance, instead of modelling the association between an author and their books as:

it is better to model it as:

The association name Writes: Person -> Book is ambiguous: it could imply that the person is currently writing the book, rather than being the author of a book that is in progress or already published. Using Is Author Of aligns better with domain terminology and clarifies that the association relates a person to books—whether published or planned. More importantly, it helps avoid a common mistake in conceptual modelling: confusing associations (which denote a state) with actions (which denote a state transition). We will discuss this issue further in Section 17.4 - Common Mistake #3.

Association Roles

In addition to its name, an association can also be labeled with roles—domain terms that describe the role of each entity in the association.

On the association line, the roles are displayed next to their corresponding entity types (Figure 17.6):

Figure 17.6: A generic binary association with roles

Mathematically, each role defines a function that is derived from R:

  • role2: E1 -> set[E2] maps each e1 the set of e2s linked to e1 by R (\(role2(e1) = \{ e2 | (e1, e2) \in R\}\)).
  • role1: E2 -> set[E1] maps each e1 the set of e1s linked to e2 by R (\(role1(e2) = \{ e1 | (e1, e2) \in R\}\)).

Naming Guidelines:

  • A role must be a noun phrase, in either singular or plural form.
  • Roles follow the same format as attributes (see below):
    • The first word is in lower case.
    • Subsequent words are separated using either camelCase or snake_case.

Roles are verbalized as follows:

  • The role2 of an e1 is the set of e2s linked to e1 by R.
  • The role1 of an e2 is the set of e1s linked to e2 by R.

For example, Figure 17.7 defines two roles on the Is Author Of association:

Figure 17.7: Roles in the Is Author Of association

Their verbalization are:

  • The bibliography of a person is the set of books they authored.
  • The authors of a book are the set of persons who authored the book.

Implicit Roles and Nameless Associations

For associations linking distinct entity types (E1 \(\neq\) E2), roles are optional. When a role is not explicit, the entity type has an implicit role derived from its name in lower case–i.e. role2 = e2 and role1 = e1.

For a binary association linking the same entity type (i.e. R:E1 -> E1), at least one role must be explicitly defined.

An association may be nameless provided that at least one of its roles is explicit.

Defining Associations

Without a clear definition, an association may be interpreted differently by different people. To avoid ambiguity, it is essential to provide a concise and precise definition that clarifies its meaning. These definitions form part of the model’s glossary of terms.

Definition Guidelines

To define an association, consider the following guidelines and patterns:

Guideline Definition Pattern
Define the association as a condition on the linked entities’ characteristics (attributes and other associations). An [e1] is [R-linked] to an [e2] when [CONDITION on e1 and e2 attributes and other associations].
Define the association in terms of link creation and termination conditions. An [e1] is [R-linked] to an [e2] when [CREATION CONDITION]. The [R-link] persists until [TERMINATING CONDITION].
State which actors determine the existence of an association links (i.e., who holds the ground truth about the link). Whether an [e1] is [R-linked] to an [e2] is determined by [actor].

Examples.

For the first definition pattern:

Association AtIncidentScene: Ambulance -> Incident
Definition: An ambulance is at the incident scene when it is stopped at or near the incident’s location, and its paramedics team is attending to the incident.

For the second definition pattern:

Association AllocatedTo: Ambulance -> Incident
Definition: An ambulance is allocated to an incident when the central control room (a human dispatcher or the computer-aided dispatch software) assigns it to respond to the incident. The allocation persists until either:

  • the paramedics complete the assignment (including patient handover to a hospital and ambulance cleaning, if needed), or
  • the central control room cancels the assignment before the ambulance arrives at the scene (e.g., if the ambulance is no longer needed or is re-allocated a higher-priority incident).

Association MobilizedTo: Ambulance -> Incident
Definition: An ambulance is mobilized to an incident when the paramedics team is en route to the incident. It remains mobilized until the paramedics complete or abandon the assignment.

Some associations have no termination condition—once created, the link persists indefinitely. For example, BiologicalParent: Person -> Person. In such cases, the termination condition can be omitted, or the definition may state that the link is permanent.

The third definition pattern is used in addition to the other patterns to clarify which actor determine the link existence. For example:

Association AllocatedTo: Ambulance -> Incident
Definition:
An ambulance is allocated to an incident when […].

Whether an ambulance is allocated to an incident is determined by the central control room.

Association Mobilized: Ambulance -> Incident
Definition:

An ambulance is mobilized to an incident when […].

Whether an ambulance is mobilized to an incident is determined by the ambulance paramedics team.

Defining associations may seem unnecessary when the name already appears meaningful and unambiguous (e.g., Reporting: Emergency Call -> Incident). While omitting definitions in such cases may be acceptable, doing so risks overlooking hidden ambiguities or edge cases. Ultimately, the decision to invest time in writing definitions should balance the required effort against the likelihood and impact of potential misunderstandings.

Multiplicities

Association multiplicities specify how many association links each instance of an entity type can participate in at any given time.

For a binary association R: E1 -> E2, the multiplicity of E1 is expressed as min:max, with the following meaning:

  • At any given time, each instance of E1 is linked through R to at least min instances of E2.
  • At any given time, each instance of E1 is linked through R to at most max instances of E2.

In the UML notation, the min:max multiplicity values for an entity type are shown on the opposite side of the association line:

Figure 17.8: UML “look across” notation for multiplicities in binary associations

Common multiplicities values and verbalization are:

Multiplicity Meaning Verbalization (for E1 multiplicity)
0:1 At most one At any given time, an e1 is linked to at most one e2.
1:* At least one At any given time, an e1 is linked to at least one e2.
1:1 Exactly one At any given time, an e1 is linked to exactly one e2.
0:* Any number At any given time, an e1 is linked to any number of e2 (including zero).

For example, Figure 17.9 shows multiplicities for the AtIncidentScene association which connects ambulances to incidents they are currently attending.

Figure 17.9: Multiplicities for AtIncidentScene connecting ambulances to incidents

Notes:

  • In requirements modelling, multiplicities should only be used to specify domain properties—facts that are always true by definition or due to natural laws. They should not be used for desired or assumed properties that could potentially be violated. Such properties must instead be explicitly stated as goals, requirements, or assumptions. For example, the statement “A flight seat should not be assigned to more than one passenger” expresses a goal and should not be modeled as a multiplicity constraint.
  • The UML “look across” notation for multiplicities contrasts with the Entity-Relationship (ER) “same side” notation, where multiplicities are written next to their entity type. For example, in the ER notation, the 0:1 multiplicity for Ambulance in Figure 17.9 would be displayed next to Ambulance instead of being displayed on the other side next to Incident. In this book, we adopt the more widely used UML “look-across” notation, despite its inapplicability to n-ary associations when n>2.

N-ary Associations (with N > 2)

N-ary associations (where N > 2) are much less common than binary associations. They are often harder to understand, and the same domain concepts can often be modeled more clearly using binary associations. Therefore, I recommend avoiding N-ary associations when the same concept can be expressed more clearly without them. Nevertheless, they are sometimes required and it is important to understand what they are and how to represent them.

N-ary associations where N > 2 are represented using a diamond with lines to the connected entity types, as in Figure 17.10.

Figure 17.10: A generic ternary association with the “diamond” notation

In Figure 17.11, the Intervention association connects an ambulance and team of paramedics to an incident when the ambulance is at the incident location and paramedics providing assistance.

Figure 17.11: Ambulance intervention as a ternary association

The min:max multiplicity constraints for an entity type E participating in an N-ary association R have the following meaning:

  • At any given time, each instance of E is involved in at least min association links in R.
  • At any given time, each instance of E is involved in at most max association links in R.

This interpretation is consistent with the meaning of multiplicity constraints in binary associations given above.

In the diagram, the multiplicity constraints of an entity in an N-ary association are shown on the same side as the entity type—-unlike in binary associations, where multiplicity constraints are shown on the opposite side.

For example, the multiplicity constraints in Figure 17.11 have the following meaning:

  • At any given time, each ambulance is involved at most one intervention (0:1).
  • At any given time, each paramedics team is involved in at most one intervention (0:1).
  • At any given time, each incident can be involved in any number of intervention (0:*). It could have any number of ambulance and paramedics teams at the scene, providing support.

Many n-ary associations can be represented using only binary associations. For example, we could model the relations between ambulance, paramedics team and incident of Figure 17.11 using binary relations as in Figure 17.12:

Figure 17.12: Alternative to using the ternary association of Figure 17.10

Aggregation and Composition

UML includes two special types of associations—aggregation and composition—which have predefined names and meanings. For domain conceptual modeling, I prefer to avoid these generic (and often ambiguous) associations and use domain-specific associations instead. However, feel free to use them if they are appropriate for your context.

Attributes and Value Types

Definition: Attributes and Value Types
  • An attribute att: T on entity type E is a function \(att: E \to T\), where T is the attribute value type.
  • A value type T is a set of values {v1, …, vn}. Unlike an entity, a value v has no distinct identity and does not change over time.

Figure 17.13 show two ambulance attributes, location and status together with the declaration of their value types.

Figure 17.13: Attributes and Value Types

An entity’s attribute value may change over time. For example, Table 17.2 shows the attribute values of ambulances amb1 and amb2 at times t0 and t1:

Table 17.2: Attribute values for two ambulances at two time points
Time t0 Time t1
amb1.location = loc1 amb1.location = loc3
amb1.status = "mobilised" amb1.status = "at scene"
amb2.location = loc2 amb2.location = loc2
amb2.status = "available" amb2.status = "allocated"

Attributes on Associations

Associations can also have attributes.

Definition: Attributes on Associations
  • An attribute att: T on an association R is a function that maps every association link in R to a value in T.

Figure 17.14 shows the IsAttending association with two attributes.

Figure 17.14: An Association with two attributes

Mathematically, this association and its attributes define:

  • a relation IsAttending \(\subseteq\) Ambulance \(\times\) Incident
  • a function arrivalTime: Ambulance \(\times\) Incident \(\to\) Time
  • a function departTime : Ambulance \(\times\) Incident \(\to\) Time

Naming Guidelines

For attributes:

  • For a non-Boolean attribute, use a noun phrase in the singular or plural form.
  • For a Boolean attribute, use a phrase in the form isX or hasX.
  • Attribute names must start with a lower case. Use either:
    • Camel case: subsequent words capitalized and joined without separators (eg. arrivalTime), or
    • Snake case: all words in lowercase, separated by underscores (e.g. arrival_time).

For value types:

  • For value types, use a singular noun or noun phrase with all capital letters (e.g. DATE, POSTCODE, LOCATION).
  • For Boolean value types, unless stakeholders are familiar with the term Boolean, use explicit and familiar values such as TRUE/FALSE or YES/NO.

Examples:

Verbalization:

To verify that attribute names are valid, check whether the following sentences make sense:

  • For a non-boolean attribute att: “an e has an att” (e.g. “An ambulance has a location”) or, if the attribute is optional, “an e may have an att” (e.g. “a person may have a middle name”).
  • For a Boolean attribute: “an e is X or not” or “an e has X or does not have X”.

Defining Attributes

An attribute can be defined within the textual specification of the entity type or association it belongs to, as follows:

Entity Ambulance

Definition: A vehicle used for responding to medical emergencies and managed by the ambulance service.

Attributes:

  • location: LOCATION — The ambulance’s current location.
  • status: AMBULANCE_STATUS — The ambulance’s current operational status, as determined by the ambulance paramedics:
    • Available – Ready to be mobilized to an incident.
    • Mobilized – En route to an incident but not yet on-site.
    • AtScene – Actively providing care at the incident location.
    • LeftScene – Departed the incident location but not yet available.
    • OutOfService – Unavailable due to maintenance, breakdown, or other reasons.

Specifying which actor determines the attribute’s value is often necessary to clarify its meaning. In the example, the ambulance status refers to the actual status determined by the ambulance paramedics–not the status recorded in the computer aided dispatch software.

Specialization

Definition: Specialization

An entity type E1 is a specialization of entity type E2 means that every instance of E1 is also an instance of E2.

Since E1 is a specialization of E2, every instance of E1 inherits all attributes of E2, and can participate in all associations where E2 is involved.

The graphical notation uses a solid line with a hollow arrowhead pointing to the general entity type.

Specialization notation: E1 is a specialization of E2 (the IsA label is optional)

If an entity type has multiple specializations, the arrowheads can be combined, as in Figure 17.15.

Figure 17.15: Ambulance Specializations

Glossary

A domain glossary can be derived from the textual specifications for all entity types and associations.

There is no standard format for these textual specifications or the domain glossary itself.

When shared with business stakeholders, the domain glossary may exclude modeling keywords to present domain terms and definitions in a more conventional manner. For example:

Glossary of Terms

Ambulance

A vehicle used for responding to medical emergencies.

An ambulance has the following attributes:

  • location: The ambulance’s current location.
  • status: The ambulance’s current status, as determined by the ambulance paramedics:
    • Available – Ready to be mobilized to an incident.
    • Mobilized – En route to an incident but not yet on-site.
    • AtScene – Actively providing care at the incident location.
    • LeftScene – Departed the incident location but not yet available.
    • OutOfService – Not available due to maintenance, breakdown, or other reasons.

AtIncidentScene links ambulances to incidents

An ambulance is at the incident scene when it is stopped at or near the incident’s location, and its paramedics team is attending to the incident.

…

17.3 Modelling Guidelines

Although most software engineers and computer science students are familiar with the notation, many struggle to create effective domain conceptual models. This section provides guidelines to simplify the process. Once mastered, conceptual modeling becomes far easier—and immensely rewarding.

General Guidelines

Remember the model’s purpose and audience. The primary goal of a domain conceptual model is to clarify domain concepts. The model should:

  • facilitate communication with stakeholders;
  • help the development team understand the application domain’s concepts and terminology.

The following general guidelines support these goals.

Focus on the Domain, Not the Implementation

  • Model the world, not an object-oriented design of the software.
  • Avoid implementation-specific concerns.

Model the Essence of the Domain

  • Focus on timeless concepts rather than specific technologies.
  • Model domain concepts as if capturing them across time.

The essence of the domain is independent of technologies and remains the same across time. To identify this essence, think about the domain as it was in the past (before computers), as it is today (with current technology), and as it might be in the future (regardless of technological changes). This will help you identify timeless concepts that are independent of specific technologies.

For example, the fundamental concepts of ambulance dispatching remain the same whether dispatching is done manually, semi-automatically, or fully automatically, and whether ambulances are horse-drawn carriages, human-driven vehicles, or autonomous units operated by paramedic robots.

Give Equal Attention to the Glossary and the Diagram

The glossary is often more accessible and beneficial to stakeholders than the diagram. Think of the diagram as a visual organization of the glossary.

Writing definitions can be challenging and tedious, but the process often uncovers critical ambiguities and misalignments in stakeholders’ concepts and terminology. If these issues go unnoticed, they can cause significant problems and miscommunication throughout the project.

Do not expect domain experts to provide well-formed definitions, or to agree on definitions. Clarifying concepts is part of the software engineering work.

Avoid getting stuck in debates over terminology. Instead:

  • Identify when two terms refer to the concepts (synonyms).
  • Recognize when a term has different meanings in different contexts. Techniques such as organizing the model by viewpoints or bounded contexts can help manage this, though these are beyond the scope of this chapter.
  • Handle disagreements diplomatically by acknowledging differing interpretations. Do not rush to impose a resolution–give stakeholders time to adapt to new terminology and perspectives.

Model Creation Guidelines

This section outlines guidelines for developing a domain conceptual model.

Include Only Concepts Relevant to Goals and Scenarios

A key challenge when creating a domain conceptual model is deciding what to include and exclude. To guide this decision, follow these principles:

  • Include all domain concepts necessary to describe:
    • Desired behaviours (e.g., goals, requirements, domain scenarios).
    • Undesired behaviours (e.g., obstacles, negative domain scenarios).
  • Exclude concepts irrelevant to these behavioural descriptions.

In other words, a domain conceptual model should only contain concepts needed to express the properties and scenarios relevant to the domain. Therefore, it is often derived from—or developed alongside—other models, such as domain scenarios, goal models, and requirements formulations.

Derive Concepts from Goals and Scenarios

Since a domain conceptual model should include all concepts necessary to describe domain goals and scenarios, an effective way to construct it is to derive those concepts directly from the goals and scenarios.

Example: Consider the following domain goal:

“An ambulance must arrive at the incident scene within 14 minutes after the first call reporting the incident.”

Figure 17.16 includes all domain concepts relevant to this goal while excluding unrelated ones:

Figure 17.16: Domain concepts related to the goal “An ambulance must arrive at the incident scene within 14 minutes after the first call reporting the incident.”
  • “An ambulance …” → Refers to the entity type: Ambulance.
  • ” … must arrive at the incident scene …” → Refers to:
    • the association AtIncidentScene: Ambulance -> Incident, and
    • the entity type Incident.
  • “… within 14 minutes after the first call reporting the incident.” → Refers to:
    • The entity type Emergency Call.
    • The association Reporting: Emergency Call -> Incident.
    • The 14-minute requirement refers to the duration between:
      • the time of the first call reporting the incident (time on Emergency Call), and
      • the arrival time of the first ambulance at the scene (arrivalTime on the AtIncidentScene association).

Reveal Implicit Concepts to Improve Goals Formulation

Domain conceptual models are often developed alongside goals and requirements—rather than being derived from them.

Initial expression of goals or requirements are often vague, relying on imprecise terminology. Key domain concepts and terms may be implicit in the original wording. By explicitly identifying these concepts, we can uncover which domain concepts are relevant to the stated property. Once these concepts have been uncovered, the original goal or requirement can be reformulated into a more precise and well-grounded statement.

Example: Consider the following informal statement about ambulance dispatching–it might be something a stakeholder says during an elicitation workshop or interview:

“When a call comes in, the person handling the call will figure out which ambulance is best to deal with the issue.”

To reformulate this statement, we first identify the implicit domain concepts:

  • “When a call comes in” → Refers to an entity type: Emergency Call.
  • “The person handling the call” → Refers to a standard role: Call Handler (an actor).
  • “Figure out which ambulance is best to deal with the issue” → Implies several key concepts:
    • The issue is an Incident.
    • The best ambulance likely means the nearest available ambulance, thereby implicitly referring to:
      • The incident’s location.
      • The status and location of all ambulances.
  • “Figuring out which ambulance” → Refers to the action of allocating an ambulance to the incident, thereby referring to an association AllocatedTo linking ambulances to incidents.

Thus, we relate the original statement with the following domain concepts:

Figure 17.17: Domain concepts implied in the statement “When a call comes in, the person handling the call will figure out which ambulance is best to deal with the the issue.”

(Note: The actor Call Handler is not part of this model—it appears instead in the actor table of the context diagram–see Chapter 16.)

Using these domain concepts, we reformulate the original statement into the more precise sentence:

“When an emergency call reports an incident, the call handler allocates the nearest available ambulance to the incident.”

This process of deriving domain concepts from a vague formulation is commonly used to refine the expression of goals and requirements.

Derive the Model Incrementally

A common and efficient way to construct a domain conceptual model is to build it incrementally—deriving concepts sentence by sentence.

If you’re working with goal modeling, start by defining a goal, then derive relevant concepts from it, and improve the goal’s formulation based on those concepts. As you refine the goal into subgoals, extract concepts from each subgoal and, if needed, improve their formulation using the derived concepts (see Figure 17.18).

Figure 17.18: Deriving domain concepts from goals: an intertwined process

The same approach applies to scenarios: derive domain concepts one scenario at a time, and within each scenario, one step at at time.

Model Validation Guidelines

This section describes the key tasks involved in validating a domain conceptual model.

Check Completeness and Relevance with Respect to Goals and Scenarios

Evaluating the completeness and relevance of a domain conceptual model must always be done in relation to a specific set of domain goals and scenarios. In this step, we verify the following:

  • Completeness: The model includes all concepts referenced in the domain goals and scenarios.
  • Relevance: The model omits any concepts not mentioned in the domain goals or scenarios.

In other words, a domain conceptual model should always be assessed in the context of the goals and scenarios it is intended to support. Without this context, it is meaningless to judge whether the model is complete or whether all included concepts are relevant.

Validate the Model against Concrete Instances

A domain conceptual model can also be validated by testing it against concrete instance–entities and association link–that the model should be able to represent. The concrete instances may be part of a domain scenario or stand alone.

Consider again the model in Figure 17.1 shown at the start of the chapter and reproduced here:

We can validate this model by assessing whether it can describe all instances in the following scenario:

  1. An incident occurs at 10 Downing Street.
  2. A first emergency call reports the incident at 9:00.
  3. A second emergency call reports the incident at 9:03.
  4. A third emergency call asks for progress about the incident at 9:10.
  5. An ambulance arrives at the incident scene at 9:12.
  6. A second ambulance arrives at the incident at 9:15.

The first three steps can be represented by the model:

  • Step 1 refers to Incident and its location attribute.
  • Steps 2 and 3 refer to Emergency Call, its time attribute, and its Reporting association with Incident.

However, the fourth step introduces a new consideration. Here, an emergency call asks for progress about an ongoing incident. Is this situation covered by the model? Can we say that this third emergency call is linked to the incident through the Reporting association? That seems incorrect because the call is not reporting the incident—it is requesting an update. Therefore, we may need to introduce a new association, EnquiresAbout: Emergency Call -> Incident, between emergency calls and incidents.

Finally, steps five and six reveal another missing concept. These steps refer to the time at which an ambulance arrives at the incident scene, suggesting the need for an arrival_time attribute in the AtIncidentScene association.

Verbalize The Model

Another way to validate a domain conceptual model is to verbalize it (using the verbalization patterns of Section 17.2) and check whether the sentences are both grammatically correct and represent the domain accurately.

For example, verbalizing the model in Figure 17.1:

  • The entity type Emergency Call is the set of all emergency calls.
  • An emergency call has a date and time.
  • An emergency call is reporting at most one incident.
  • The entity type Incident is the set of all incidents.
  • An incident has a location.
  • (etc.)

This approach provides a quick way to verify that concept names are meaningful and understood by stakeholders. It is effective for validating concept names but less effective at revealing missing concepts. It should therefore be used as a complement—not a replacement—for validating the model against concrete instances and ensuring it captures all the concepts required to define the domain goals and scenarios.

Common Modelling Dilemmas

There are several common modelling dilemmas that students and beginners face when developing conceptual models. These are typical situations in which they need to make modelling decisions but are unsure how to proceed. One of the most frequent dilemmas is choosing an appropriate association name. The guidance on naming associations in Section 17.2.4.1 was written to address this challenge. This section provides guidance on how to address other common dilemmas.

Choosing Between an Association and an Entity Type

A common dilemma is deciding whether to represent a concept as an association or an entity type.

For example, consider a customer renting a car. This concept could be modelled in two ways (see Figure 17.19):

  1. As an association Renting: Customer -> Car
  2. As en entity type Car Rental with separate associations linking each car rental to a customer and a car.
Figure 17.19: Dilemma: Should car rental be modelled as an association or an entity type?

Figure 17.20 shows the general case of this dilemma.

Figure 17.20: The Association vs Entity Type Dilemma

Mathematically, the difference is as follows:

  • If you model a concept C as an association C: E1 -> E2, then for any two entities e1 and e2, there can be at most one association link (e1, e2) in C.
  • If you model C as an entity type, you can have multiple instances of C between e1 and e2.

Another crucial difference:

  • If you model C as an association C: E1 -> E2, the association can have attributes but cannot participate in other associations.
  • If you model C as an entity type C, it can have attributes and participate in associations.

Example:

  • If we model car rental as an association Renting: Customer -> Car, there can be at most one Renting link between customer_x and car_y. Even if the customer rents the same car multiple times (e.g., returns it and rents it again), our model would still represent both rentals with the same link (customer_x, car_y).
  • If we model car rental as an entity type Car Rental, each rental is a distinct instance. Thus, two separate Car Rental entities would exist for customer_x renting car_y on different occasions.

In this case, modelling car rental as an entity type is the better choice because:

  • It more accurately reflects the domain (a customer renting the same car multiple times are distinct rentals).
  • It allows for clearer modeling of a car rental’s attributes (pickup_time, return_time) and associations (PickupStation, ReturnStation: Car Rental → Rental Station).

Guideline

When deciding whether to model a concept C as an association C: E1-> E2 or an entity type C with associations to E1 and E2.

  • Model C as an association if:
    • your model does not need to distinguish multiple instances of C linking the same entities e1 and e2, and
    • your model does not need associations involving C.
  • Model C as an entity type if:
    • your model needs to distinguish multiple instances of C linking the same entities e1 and e2, or
    • your model requires associations linking C.

Simple Test: To decide whether your model needs to distinguish multiple instances of C, ask:

Does it make sense to count the number of C instances between e1 and e2?

  • If yes (e.g. counting rentals between a customer and a car), model C as an entity type.
  • If no, model C as an association.

Trade-off: Accuracy vs Simplicity. The decision also depends on your model’s audience and purpose:

  • In early phases (foundation, exploration, decision), you might prefer simplicity and model C as an association-even if an entity type would be more accurate. In such cases, consider adding a note to the association’s textual specification to indicate this simplification.
  • In the later phases (formulation, quality assurance), you might prioritize accuracy by extending the model to include C as an entity type. In some cases, your model might include both an association C_verb: E1 -> E1 and entity type C_noun.

Choosing an Attribute Value Type

Another common dilemma is selecting an appropriate value type for an attribute.

For example, in the car rental domain, this might involve choosing the value type for a car’s odometer_reading (mileage) and the distance_travelled during a rental. It might also involve choosing the value type for a customer’s name and passport_number.

A common beginner’s mistake is to use to a predefined programming data type, such as int, float, double, decimal, string, and boolean. These programming data types are rarely meaningful to stakeholders. For numerical attributes in particular, they obscure important information–such as whether the car’s odometer_reading is expressed in miles or kilometers. Moreover, selecting a programming data type is an implementation decision that should be guided by domain requirements, not made prematurely before those requirements are fully understood.

A better approach is to reuse or define a domain data type:

  • For numerical attributes, consider specifying either a unit or an abstract data-type that encapsulates and supports multiple unit representations. For example, instead of odometer_reading: decimal, use KM or MILES, depending on whether the reading is given in kilometers or miles. Alternatively, use an abstract data type such as DISTANCE that can support multiple units. For unit-less attributes, use appropriate mathematical types such as WHOLE_NUMBER, INTEGER, REAL_NUMBER.
  • Instead of a generic string type, consider a more informative, domain-specific type. For example:
    • For a car’s registration number, use VEHICLE_REGISTRATION_NUMBER or LICENSE_PLATE_NUMBER.
    • For an ambulance’s operational status, use status: AMBULANCE_STATUS.
    • If the attribute truly represents free-form text, use a type like TEXT rather than string.
  • For Boolean attributes, since many stakeholders may not be familiar with the term “Boolean”, consider using TRUE/FALSE or YES/NO instead.

Deciding between Value Type and Entity Type

Another common dilemma is deciding whether to model a concept as a value type or an entity type.

For example, consider a free-floating car rental system, where users can pick up and drop off cars anywhere within a city, without returning them to a fixed station. Each rental has a pick-up location and a drop-off location. The question is whether the concept of Location should be modeled as a value type or an entity type. The resulting models are shown in Figure 17.21.

Figure 17.21: Dilemma: Modelling Location as a value type or an entity type.

There are two crucial differences between a value type and an entity type.

  1. Difference in Meaning: an entity is a “thing” with a distinct and independent existence whose characteristics may change over time. In contrast, a value is immutable—if it changes, it becomes a different value. For example, the number 5 is a value; if it changes, it is no longer 5. An ambulance, however, is an entity: its location and status may change over time while it remains the same ambulance.
  2. Difference in Modeling: an entity type can have attributes and participate in associations, whereas a value type is only used as the type of an attribute. A value type cannot have attributes or participate in associations. Because a value is immutable, it does not make sense to define attributes or associations on value types.

In this case, Location should be modelled as a value type because:

  • a geospatial coordinate cannot change without being a different coordinate, and
  • a geospatial coordinate does not have attribute or participate in associations.

In a different situation–if rentals must be picked up and dropped off at designated rental stations with fixed locations, typically at airports, train stations, and city centers–we would introduce an entity type Rental Station with a location attribute, as in Figure 17.22. In this model, Location remains a value type, not an entity type.

Figure 17.22: Modelling Rental Station as an entity type

Here, Rental Station must be an entity type because:

  • a rental station might have characteristics that change over time, and
  • we need our model to support Car Rental attributes (e.g. number_cars_available: COUNT) and associations (e.g. PickUpLocation: Car Rental -> Rental Station).

Guideline: To decide whether a concept C should be modelled as a value type or entity type:

  • Model C as an entity type if:
    • Its instances have a distinct identity that persists over time, even as their characteristics (attributes or associations) change.
    • You need to define attributes or associations for C.
  • Model C as a value type if:
    • Its instances are immutable—changing any characteristic results in a different value.
    • You do not need to define attributes or associations for C; it is only used as the type of an attribute.

17.4 Common Mistakes

This section discusses common mistakes that occur in domain conceptual models created by students or novice modellers.

Mistake 1: Failing to Use Established Domain Terminology

A common mistake is relying on computer science jargon or inventing new terms, instead of using standard domain-specific terminology.

Figure 17.23 illustrates an incorrect model alongside a corrected version.

Figure 17.23: DON’T: use computer science jargon; DO: use domain terms

In cases where established domain terminology is lacking, it may be necessary to introduce new concepts and terms. When doing so, ensure that the new terms describe phenomena in the application domain using language that is meaningful to domain stakeholders.

Mistake 2: Modeling the Implementation Instead of the Domain

Another common mistake is polluting the domain conceptual model with implementation concerns—such as adding methods to entity classes or including implementation-specific classes. This often results in models that are overly large, complex, and difficult to understand.

Avoiding this mistake is straightforward once you remember that the model’s purpose is not to produce an object-oriented design of the software (which can be done separately), but to define the domain’s core concepts and terminology. To keep the model simple and meaningful for stakeholders:

  • Do not include object-oriented design classes—such as event publishers, event handlers, adapters, UI controllers, thread controllers, or exception types.
  • Do not add methods to entity types—deciding which class performs which function is an implementation concern, not a requirements engineering task.

Mistake 3: Modelling Actions as Associations

A common mistake is to model an actor’s actions as associations. This leads to two main problems:

  1. It pollutes the domain conceptual model with information that belongs in other models, such as domain scenarios or context diagrams.
  2. It often results in a domain conceptual model where the actual associations are missing.

For example, consider this brief system description for an ambulance dispatching system:

When an emergency call is received, the Computer Aided Dispatch (CAD) system shall:

  1. direct the call to a call handler;
  2. allow the call handler to record details about the reported incident;
  3. support the call handler in allocating an ambulance to the incident.

Figure 17.24 shows a domain conceptual model derived from this description that illustrates the mistake:

Figure 17.24: Common Mistake: Modelling Actions as Associations

This model includes relevant entity types–Emergency Call, Incident and Ambulance–but its associations represent actions, not static association links between entities. It includes information about which actor performs which actions, which is irrelevant in a domain conceptual model. In larger models, such information is not only irrelevant but also harms understandability. Finally, this model lacks the actual associations among the relevant entity types.

Figure 17.25 shows a more appropriate domain conceptual model derived from this system description. Note how this revised model does not specify which actors controls the association links (e.g., which actor allocates emergency calls to call handlers or ambulances to incidents). Such information would instead by captured in the context diagram.

Figure 17.25: Fixing the Mistakes in the Domain Conceptual Model of Figure 17.24

While Figure 17.24 illustrates an extreme case in which all associations are problematic, the same mistake can occur in models where only a few associations represent actions while others represent genuine static links.

This mistake has two main causes:

  1. Learners’ initial difficulties in understanding the differences and complementary roles of domain conceptual models, context diagrams, and domain scenarios. This mistake is closely related to the confusion between context diagrams and domain conceptual models discussed in Section 16.4.3.
  2. Longstanding heuristics for generating a domain conceptual model from natural language, which suggest extracting noun phrases as candidate entity types and verb phrases as candidate associations. When applied uncritically—whether by humans or automated model extraction tools—such heuristics tend to produce models riddled with this mistake.

To avoid this mistake, revisit the advice on distinguishing context diagrams from domain conceptual models in Section 16.4.3, and complete the exercises at the end of this chapter (coming soon).

Mistake 4: Using an Entity Type as Attribute Value Type

Another common mistake is using an entity type as the value type of an attribute. In early literature on object-oriented design, this is also referred to as “using attributes as pointers”.

Figure 17.26 illustrates this mistake. At the top of the figure, the mobilization of an ambulance to an incident is incorrectly modeled as an attribute mobilizedTo, which refers to the Incident entity type. The correct approach is to model this relationship as an association Mobilized To: Ambulance -> Incident, as shown at the bottom of the figure.

Figure 17.26: Common Mistake: Using an Entity Type as Attribute Value Type. Resolution: Replace the attribute by an association.

This mistake is easy to detect and correct: whenever an attribute’s value type refers to an entity type, it should be replaced with an association.

17.5 Notes and Further Reading

This chapter’s description of domain conceptual modelling is partly based on the presentation of object models in the KAOS goal-oriented method in Chapter 10 of Axel van Lamsweerde’s book (Lamsweerde 2009). A brief overview of the KAOS object model can also be found in my PhD thesis (Letier 2001).

The presentation here simplifies certain aspects of the KAOS object model and refines the modelling guidance. These refinements are informed by my own experience as well as by research on practitioners’ pain points (Valle, Sales, Guerra, Daneva, Guizzardi, et al. 2025) and students’ difficulties (Rosenthal, Strecker, and Snoeck 2023) in developing domain conceptual models. The research on practitioners’ pain points addresses many more issues than those discussed in this chapter.

The naming guidelines and verbalisations are adapted from the work of Aguilera, Gómez, and Olivé (Aguilera, Gomez, and Olive 2013), with minor modifications, most notably the addition of more specific and restrictive guidance on association names.

How to manage large domain conceptual models is critical in practice but has been omitted from this chapter.

  • To manage model size, one effective approach is to slice the domain conceptual model by goals—that is, by showing only the domain concepts related to a goal, its subgoals, and associated domain scenarios (Lamsweerde 2009).
  • To handle complex domains where key terms vary in meaning depending on context, two related techniques can be used: viewpoints from requirements engineering research (Finkelstein et al. 1992; Kotonya and Sommerville 1996), and bounded contexts from domain-driven design (Evans 2004; Vernon 2016). Both approaches make explicit the context to which a model applies, enforce terminological consistency within each context, and allow terms to have different meanings in different contexts. Relationships between contexts—such as mappings or translations—can then be defined to clarify how concepts relate across context or viewpoint boundaries.

Another important omission is the reuse of established domain conceptual models. Many domains have well-established conceptual models or ontologies that can—and sometimes must—be reused rather than being developed from scratch. Some industries have standard conceptual models that you must take into account.

Researchers are exploring the use of machine learning and large language models (LLMs) to generate domain conceptual models from natural language statements, e.g. (Arora et al. 2019; Saini et al. 2022; Chen et al. 2023; Bragilovski et al. 2025). The future practical utility of these tools may depend on their ability to support an incremental, interactive process in which domain conceptual models are developed alongside improvements to the natural language statements, as outlined in our modelling guidance. This process would also involve generating and negotiating suitable concept definitions—-one of the most challenging yet crucial aspects of conceptual modelling in practice (Valle, Sales, Guerra, Daneva, Silva Santos, et al. 2025).

Given that LLMs can generate plausible yet often flawed domain conceptual models, it is crucial for students to develop model evaluation skills alongside model creation skills (Snoeck and Pastor 2025).