LARMAN CD MODULES

Module 6

Building Domain Models

Introduction

At this point in the CD Modules we have created our Use Cases in text and perhaps the odd Use Case Diagram. We have also had a quick look at the System Sequence Diagram (SSD). In this Module, Larman discusses building domain models.

What is a Domain Model?

The Big Idea:

A Domain Model is a visual dictionary created through the business modelling discipline. The idea behind this discipline is to model concepts in a domain in a visual form. It is a classic OO A/D activity where we apply principles for the identification of concepts, attributes and associations.

Why produce a Domain Model?

A Domain Model is a good tool for reducing our "representational gap" and reducing complexity. We can create software solutions that reflect how we think/perceive concepts in the real world domain. For example, if we think of a "book" in the real world domain, we can also think of a book in Software Objects Land. It appeals to a conceptual model of how we think about the real world and therefore, reduces time and effort to understand software for a domain.

The Domain Model is inspired by our Use Case Model and in turn, serves as input to our Design Model.

What a Domain Model IS NOT:

A Domain Model is NOT a diagram of Software Objects. For example, a "Sale" in a Domain Model represents our concept of a sale in the real world; it does not represent a Sale.java class.

How do we create a Domain Model?

General Idea:

The idea is to first identify domain concepts. For this we have the following strategies:

• Use a common concepts list
• Identify nouns and phrases - these are possible domain candidates
• Study and apply models from others, for example, analysis patterns in a number of well known domains

Common Concepts List:

Initial Domain Model from Use Cases:

Identify Important Associations:

At this point in time, our Domain Model shows only the Domain Concepts that we have extracted from our Use Cases. Our Domain Model can now grow to include Associations as well as concepts.

Associations are the relationships that exist between two or more concepts. For example, the following diagram shows the association, or relationship, between a Sale and a Sales Line Item:

The association should be given a meaningful name and be shown in the form <noun, verb-phrase, noun>. Note that the association is bi-directional, that is we read it from left to right: "A Sale contains zero or more Sales Line Items", or right to left: "zero or more Sales Line Items are contained a Sale".

This introduces us the the multiplicity value in the Domain Model. The multiplicity value indicates the legal number of instances of one type that can be related to the other type:

* (read zero or more/many)

1...* (read one or more)

0...1 (read zero or one)

40 (read exactly 40).

The following is a list of some important associations:

• is part of - physically A is part of B
  • is line item - Sale Line Item part of Sale
• contained - A is contained in B
  • a book is contained in a library
• is member of - A is a member of B
  • cashier is a member of a store
• is policy - A is a policy related to B
  • a loan policy related to a book
• is organisation subunit - A is an organisational subunit of B
  • a department is an organisation subunit of a company

Showing Concepts as Roles:

When identifying associations, each end of the association is a role. Each end must have a multiplicity value and can also have an optional name. For example, in our Domain Model, a noteworthy concept such as "Person" can be given an optional name "Customer".

So Many Concepts, so Many Associations......:

Its easy to see that our Domain Model diagram can become very confusing. After all, if you have 20 domain concepts you could have an association line to 19 other concepts. So, what is worth showing?

Worth it:

If you need to preserve the memory of a relationship (that is, you need to know for a duration of time) then that association is worth showing. For example, we need to know what Sales Line Items are associated with a particular Sale for the duration of the sale.

Not Worth it:

If the relationship is not noteworthy under the particular domain of the system, then don't show it. For example, a relationship between a manager and a cashier may be noteworthy under the Human Resources Domain, but does is not noteworthy when it comes to the actual POS domain.

Finally, Show the Attributes and we're done (well, not quite):

In the Domain Model we can show noteworthy bits of information in the terms of a domain concept's attributes. For example, if we had a concept "Office", we could show the "room no." of the office, which is indeed noteworthy. However some rules to follow:

• Simple data types only (ints, strings etc OK, but no complex objects, please)
• No Foreign keys!

But are we finished with the Domain Model? No. The Domain Model is a living document. It serves as input into the design model but then the design model can highlight changes required to the Domain Model and so on.

The Domain Model Diagram:

Home

Module 1 | Module 5 | Module 6 | Module 7 | Module 8 | Module 9

Module 10 | Module 12 | Module 13 | Module 14