Domain Class Model

Domain class model defines the real-world classes and the relationship between them. In our previous content, we have studied that during the software development process the domain modelling occurs at the analysis phase.

Domain analysis figures out real-world objects from the problem statement that are important from the application point of view by creating the domain model.

Domain model figure outs three aspects of the real-world objects:

1. The static structure of the object by creating a domain class model.
2. Interaction between the objects by creating domain interaction model.
3. Life cycle histories of the objects by creating the domain state model.

In this section, we will discuss the domain class model and its modelling elements in brief.

What is Domain Class Model?

Domain class model is the first model created during analysis because it is easier and convenient to define static entities which are independent of the application and are more stable in the progression of the software development.

To create the domain class model, the information is gathered from the problem statement, related applications, expert’s knowledge, business interviews, documents etc… You must not rely entirely on the provided problem statement as not even a business expert can provide a precise problem statement.

Now, the problem is how to create a domain class model?

To create a domain class model, you have to perform the following steps:

1. Identify real-world classes.
2. Compose a data dictionary.
3. Identify the association.
4. Identify attributes.
5. Optimize classes using inheritance.
6. Test the access path to verify that they produce a sensible result.
7. Iterate to model to resolve the ambiguities.
8. Revise the level of abstraction.
9. Group classes to form packages.

It is impossible to construct the entire software at once and develop every aspect uniformly. The first constructed model always has flaws and it is refined with several iterations. We will discuss each step of constructing a domain class model in detail.

1. Identifying Classes

Find the classes for real-world objects. An object could be a real-world physical entity like a person, furniture, country and many more as well as a conceptual real-world entity like route, transaction, cost. Make it clear you must figure out classes that are relevant to the application.

You can’t find all the classes from the problem statement you have to exercise your general knowledge to extract classes. The figure below shows the standard way of choosing classes.

Don’t think too much to figure out the classes, just note down the classes that occur in your mind. At the initial stage don’t indulge in practising inheritance.

Now, from your class collection, you have to eliminate the unnecessary and incorrect classes. For this, you can use the following guideline.

• Eliminate the redundant classes by reserving one class with the most expressive name.
• Eliminate the irrelevant classes that have nothing to do with the problem. You need an expert’s judgment for this as it would cause the problem if the eliminated class is important.
• Eliminate the vague classes that have ill-defined boundaries and are broader in scope.
• Names describing the property of the object must be listed as attributed. But if the property is independently too important then list it as a class, not as attributes. Same is with the operation, i.e. if the operation has some of its own properties then it should be modelled as a class.
• The name of the class should reflect its nature, not the role it plays in association with the other classes.
• Also, eliminate the names that are implementation construct.
• Ignore the classes that can be derived from other classes.

2. Preparing Data Dictionary

The name of the class can be interpreted in many ways. So, prepare a dictionary for every name. You can write the information in a paragraph that describes the class, its attributes, operations and associations. You can also note down the scope of the class in the current scenario and also about its limitations.

3. Identifying Associations

Now, when we have a set of classes its time to identify the structural relationships between them. Association can be identified as a verb or verb phrases in the problem statement.

It is represented by communication (DealsWith), ownership (has, PartOf), physical location (PartOf, ContainedIn, NextTo), Condition (WorksFor, Manages). Just note down all the relationship and don’t try to refine relations too early.

After collection all kind of relations it times to eliminate and discard the unnecessary associations. For these follow the guidelines below.

• If you have eliminated certain class then eliminate its association or redefine it for other class.
•  Eliminate the association that is beyond the scope of the application.
• An association should be a perpetual relationship, not a temporary event. In the problem, statement association is sometimes expressed as an action.
• Decompose the associations between three or more classes into a binary association, retaining every information.
• Eliminate the association that can be defined with other association.
• The derived association may not add information but they are important for designing the class model.
• Association must be named carefully as the name define what the situation is?
• Association end names are not required if there is a single and well-defined association between a pair of classes. When there is multiple association between the classes association end name must be described precisely.
• Add qualified association when the object needs to be identified in a specific context.
• Add multiplicity to the association but don’t try to refine too much as multiplicity changes during the analysis.
• In case you find any missing association add that missing association.
• Don’t spend much time in distinguishing between association and aggregation. As aggregation is also an association but, with some extra conditions.

4. Identifying Attributes

For every class, identify the common nouns that describe the properties of the object in the application domain. Attributes are not much described as classes and association.

Do not spend too much time in identifying attribute. Only consider attributes important from the applications point of view. Name attributes in a meaningful sense. Figure out the attributes on the association, this attribute defines the relationship between two objects instead of defining the property of the individual object.

After listing out attributes its time to eliminate the unnecessary and incorrect attribute.

• Eliminates the attributes whose independent existence is important from the application point of view, consider that attribute as an object.
• Restate the attribute as a qualifier, if its value is depending on a certain situation.
• A name is considered as an attribute if its value doesn’t depend on the particular context and need not be unique in a set.
• Eliminate the attribute whose only concern is to identify the object as class model implicitly include an identifier.
• If the attribute presents value for the links then it is the attribute of association.
• Attributes defining the internal state of the object that are not visible to the outside world then eliminate those attributes.
• Attributes that are not affecting the behavior of an object must be eliminated.
• Restate boolean attributes as enumeration.

5. Refining inheritance

We have left the task of generalizing and reorganizing the classes while identifying the classes. Generalizing the classes help in reusing the class models.

We can implement inheritance among the classes in two directions:

• Bottom-up: It is generalizing the classes by discovering the common attributes, associations and operation and defining it in the superclass.
• Top-down: It is specializing the classes by refining the features of the superclass in the subclasses.

6. Testing Access Paths

Now its time to trace the domain class model to see that it answers for every possible user question. If you find that the model does not provide answers to some useful questions then it indicates that some information is missing from the model.

7. Iterating Class Model

Software is never developed at once it passes through many iterations to resolve ambiguities in it. Similarly, the class model doesn’t get perfect in one pass. While iterating the class model you have to find the missing answers for the questions you get in testing the access path stage.

8. Shift Level of Abstraction

In the first pass, you have been focusing on the problem statement to figure out classes and associations. But this is not enough you have to raise the level of abstraction at each iteration.

9. Grouping Classes into Packages

After discovering classes, identifying the association between them, listing attributes for classes now, we have to group the classes that are more closely related to each other in packages.

Classes in different packages are less closely related to each other. It is not that you can not repeat classes in different packages. Packages could be reused if your previous problem is similar to the current one.

If your new problem statement is similar to the previous one but more advance you can extend the packages. It is based on your judgment if you want to reuse the packages or build a new model.

So, this is all about the technique to construct a domain class model. We have leant about what is the domain model? What’s the use of a domain class model? How to construct the domain class model?