How do I validate the class diagram for a given domain?

Question

I am working on car dealership business domain model/UML class diagram.

I am new to modeling, so I would like to know how to validate the class diagram. It's very important for me to have an appropriate, if not 100 percent correct, class diagram to use further development (use cases, etc.).

Is it possible to build a completely incorrect model? Or are there only appropriate and less appropriate models?

If I have a Customer associated with SalesTeam modeling a customer being served by SalesTeam, is that wrong? I have seen in examples of Customer being associated with Order, Order with ItemOrder and ItemOrder with ItemInventory. Where the SalesTeam or Staff is associated with Order.

How do I validate my model and relationships?

Answer 1

The short answer is that this is not very important.

Use your domain class diagrams to keep a note of what you think is in the domain, that is all. It is not your god, and it will not hurt you to change it as you go.

Answer 2

Domain experts should help you to validate the domain model.

As far as validating the specific relationships, as you develop the model further and investigate the collaborations between objects you will discover more and different relationships. You will need to revisit the domain model often during your analysis and development.

I don't think it matters that it's 'correct' up front (i.e. before you move onto looking at use cases and further analysis), only that it is useful - it gives you a conceptual model of the problem and what the main classes involved are. It isn't going to be finished until the software is no longer being developed or maintained.

If it represents the way you view the problem right now, it's good enough for you to start further analysis. Revise it as your view of the problem changes and you learn more.

Answer 3

To validate domain models, do the following.

1. Write use cases. During the writing, make sure you're using nouns and verbs in a consistent way. To be sure that your nouns make sense, be sure to record notes in the domain model.

2. Walk through each use case, following along on your domain model. At the entities there? Relationships required for navigation? Attributes of each entity?

Since it's a domain model, try to avoid describing things as classes -- they're usually real-world entities.

For example "customer entity in direct relationship with sales team entity" is something you'll learn from the use cases. For example, customers are associated with orders, but the order is created by the sales team. So, you have two navigation paths between customer and order: direct and via the sales team. Both appear (to me) to be true.

You must compare your domain model with your use cases to be sure both agree.