Conceptual Modeling

Introduction

To create a logical and physical relational data model, and a class design model, that is flexible and extensible enough to allow applications to evolve without major changes, we must start by modeling business. Specifically, modeling entities and their relationships, along with specialized attributes and associations such as inheritance. The artifact that captures reality in a very close way is the Domain Model.

But unlike the definition available in Wikipedia, I’m focusing on the Rational Unified Process (aka RUP) that says:

“Incomplete business object model, focuses on explaining products, deliverables, or events that are important to the business domain. Such a model does not include the responsibilities people carry.”

Still, this definition is broad and leaves room for many interpretations. According to RUP, incomplete means that we are modeling business partially, without process models or business use cases. As a complement, we have the following definition from Martin Fowler:

“Visual representation of conceptual classes or objects from the real world in a domain of interest.”

Wait, this definition is broad too. To be even more clear, we just represent business entities, their relationships and attributes. The definition of an entity is also from RUP:

“In business modeling, business entities represent objects that business workers access, inspect, manipulate, produce, and so on.”

It’s very important to know that we are modeling business, so it’s the current real world. But with those definitions, we can model anything.

How to model a domain

The creation of a domain model is structured in the following steps:

1. List all candidate conceptual classes or entities
2. Represent entities in a domain model
3. Add associations between conceptual classes
4. Add multiplicity
5. Add attributes

I’m going to detail all steps in one model. The modeling language will be Unified Modeling Language (aka UML) as it is closely related to RUP and have all semantic elements to achieve the desired expressivity level. For the sake of completeness, the steps will include an example in a specific domain described as follows:

In a health sampling area, patients who must take exams are now received on a first-come, first-served basis or by scheduling. Each patient is called by a sample collector, who prepares all the necessary elements according to the patient’s clinical record and their need for tests. These elements are: supplies, tubes and necessary containers, according to the type of examination. For each tube or container used in a sample, the collector labels it to establish its origin and destination. Finally, the samples are delivered for dispatch to the corresponding laboratory, awaiting analysis and results.

List all candidate conceptual classes or entities

Here we can use the category list of conceptual classes to identify them in the domain of interest. This list can be extended as needed.

Additionally, we must apply the cartographer’s strategy:

• Use existing names in the territory (domain)
• Exclude irrelevant features (entities, associations, attributes, etc)
• Do not add things that are not there (don’t invent things)

For instance, our domain model in a clinical context will have the following candidate conceptual classes:

Represent entities in a domain model

Now it’s time to diagram the identified entities in a domain model. This can be achieved by using UML class diagram in a simplified way: without data types, qualifiers and visibility indicators. The following rationale applies to representation:

• All the elements that control the stock are conceptualized as Clinical Supply (syringe, etc).
• The purchased units for each stock controlled element are conceptualized as Clinical Supply Purchase Unit (100 units per box, etc).
• The container in which comes the purchased units are conceptualized as Clinical Supply Container (bag, box, etc).
• Where clinical supplies are discarded is conceptualized as Canister.
• Hospital and External Laboratory are conceptualized as Company.
• All definitions for exams are conceptualized as Exam along with Clinical Supplies per Exam.
• For exams order’s record are conceptualized as Exam Order and Exam Order Entry.
• For patients schedule’s records are conceptualized as Patient Appointment, Exam Taking and Exam Order Entry Status Definition.
• The external laboratory services purchase order is conceptualized as Purchase Order, Purchase Order Entry and Purchase Order Entry Status Definition.
• Exam Results won’t be conceptualized. Instead when critical exams results are ready, the sample collection manager will be notified. This fact is a Exam Taking record.

The following figure shows the domain entities represented in a UML class diagram simplified, with associations, attributes and multiplicity:

Conclusion

By creating a domain model we achieve a deeper, better and shared understanding of the domain that is being represented. We can also communicate our ideas and thoughts about that domain thanks to the model. Normally it is a tool that complements very well with user stories or use cases and allows UI prototyping too.

Modeling the domain directs the logical and physical modeling of a relational data model. This can be achieved by following the 8 steps of the algorithm designed by Elmasri Navathe. A good class design model can be diagrammed starting with the domain model, following some steps too and, finally, you have to assign responsibilities using GRASP patterns.