Understanding the core concepts and their interrelationships is the foundation of any software system. Misunderstandings or misconceptions about these concepts can lead to system failure. To avoid such pitfalls, it’s crucial to communicate the conceptual system using a model. This model serves as a common language for professionals from different fields to discuss the core functionality and data of the system.

Conceptual modeling is a powerful tool for understanding and communicating complex systems. It allows us to visualize the relationships between different concepts and see how changes in one concept can affect others.

To demonstrate the power of conceptual modeling, we’ll use the Concept D/D language, which I wish was used more pervasively. You may be familiar with ER modeling. Concept D/D has similatities to it. The difference is that the latter also helps you understand meaning of the concepts within the current system. We’ll use an example to illustrate.

The Role of Conceptual Modeling

In practical terms, conceptual modeling can be used to:

  • Improve communication: Concept D/D diagrams provide a visual language that can be understood by professionals from different fields. This can improve communication and collaboration, helping to ensure that everyone is on the same page.
  • Identify potential problems: By visualizing the relationships between different concepts, Concept D/D can help us identify potential problems or bottlenecks in a system. This can allow us to address these issues early on, before they become more serious.
  • Simplify complex systems: Complex systems can be difficult to understand and manage. Concept D/D can help to simplify these systems, making them easier to understand and work with.
  • Support decision-making: Concept D/D can provide a clear and concise overview of a system, supporting decision-making processes. This can be particularly useful in fields like project management, where understanding the big picture is crucial.

In this post, we’re going on a journey into the heart of conceptual modeling. We’ll be exploring a model that I’ve actually helped a client work with in real life: the Camping Area Management system. It’s a system that, like all systems, is made up of concepts and their interrelationships. And just like in any software project you might be working on, understanding these core concepts and their relationships is crucial to avoid any misconceptions that could lead to failure.

Conceptual modeling doesn’t describe the concrete software architecture. Instead, it serves as a reference when defining different parts of the actual architecture. It includes all the conceptual parts of the system, ensuring a precise description that helps avoid misconceptions later on, when it is more expensive to fix.

Concept D/D

The diagram format presented here is a less formal version of Concept D/D, intended to make the usage of the tool as lightweight as possible. That is to say, I do not strictly adhere to all visual conventions of the original language here.

Concept D/D is a visual language that has

  • expressivity that helps all parties understand what the intention of the system is
  • sufficient formality such that it is rather straightforward to convert into application logic and relational data models – rules exist to do this systematically too, if needed

The simple core rule key to understanding these diagram is as follows: Each concept X in the diagram is defined by all of the elements Y below it, pointing to that concept X. That is, the arrows pointing up always have the base meaning of “Y defines X”.

The Heart of the System: Main Concepts

Imagine, if you will, a camping area. Picture the tents, the campfires, the families enjoying their time together. Now, let’s look at this scene through the lens of our (simplified) conceptual model.

At the top level, we have the concept of a Camping Area Management system. This system is defined by two concepts: “Purchase” and “Sellable”. When a customer buys goods or services, that’s a “Purchase”. Anything the camping site can sell, whether it’s a gas bottle or a boat rental, is a “Sellable”.

Let’s delve a little deeper into these concepts. A “Sellable” item has properties like “Price”, “VAT” (Value Added Tax).

When a customer makes a “Purchase”, they pay a certain price and the purchase is recorded with the date and time. Each “Purchase” includes the “Price Paid” and the “Date and Time” of the purchase. It’s also linked to the “Sellable” item that was purchased.

The dashed lines here indicate a formula: Price paid is can be calculated by adding up Price of the Sellable plus the VAT. Of course, this formula could also include things like Discounts, etc.

Bringing It All Together: The Complete Model

Note that Purchase is also defined by the Sellable (green arrow). This connection answers the question “What is being bought?” (i.e. it points to the identity of the current item purchased). In a more comprehensive model, also a Customer concept with all its details could be added here, storing the answer to the question “Who is buying?”.

Sellables also exist at the camping site “on their own”, so Sellable defines both the Camping Site and the Purchase. For clarity, the separate arrow from Sellable to purchase is green, to denote that it is an additional definition.

A Sellable can be a “Service”, like a sauna turn, or a camping site location rental. Or it can be a “Product”, like a gas bottle or an ice cream. For clarity, the arrows below Sellable have an annotation that shows that a Sellable is either a Service OR Product.

Practical Uses of Concept D/D

I hope you can see how having such a common understanding about the relationships and contents of concepts can help stakeholders identify any confusion and point it out.

Having a clear conceptual model can help everyone involved understand the system better. It creates a common language that professionals of different fields can use to discuss the core functionality and data of the system.

This model can facilitate moving on to more concrete architectural and relational database design phases. It’s a tool that can bring clarity and alignment to your team, and I hope it serves you well in your project.

This can be particularly useful in fields like software development, where understanding these relationships is crucial for building efficient and effective systems.

In conclusion, conceptual modeling is a powerful tool for ensuring the success of a software system. It provides a clear and precise understanding of the system’s core functionality and data, helping to avoid costly misconceptions and misunderstandings. Whether you’re working on a software system for a house construction project or any other complex project, conceptual modeling is an essential step in the process. By defining each concept in detail and understanding their interrelationships, we can create a robust and efficient system that meets our needs and expectations.

Any comments are welcome for this post, I always aim to make it easier to comprehend! Please contact me with any thoughts.

Further reading

Hannu Kangassalo:

Markopekka Niinimäki:


Leave a comment

Your email address will not be published. Required fields are marked *

Comment moderation is enabled. Your comment may take some time to appear.