Advanced Domain Modeling

Abox versus Tbox

UML is only one of many languages for modeling domains. For example, we can simply write down all of the facts about a domain using formulas. This is essentially what Euclid did for the domain of geometry.

A collection of formulas describing a domain is called a knowledge base or ontology.

Ontologies are often divided into two parts: Abox and Tbox.

The Tbox is the terminology component of a domain model. It defines the vocabulary of the domain.

The Abox is the assertion component of a domain model. It collects together specific facts about the domain.

For example, compare the statements:

S1: A student is a person who is currently enrolled in a school.
S2: Ted Williams is a student at Boston University.
S3: Bill Ding is a student at Boston University.

S1 is a TBox statement, while S2 and S3 are Abox statements.

The Abox component must be compliant with the Tbox component. In other words, no Abox statement should use vocabulary not defined in the Tbox, nor should it use Tbox terminology in a way that is inconsistent with the constraints placed on these terms by the Tbox.

In a UML domain model, TBox statements are usually captured by a class diagram containing only classes, associations, and generalizations. Abox statements are usually captured by an object diagram. An object diagram is a class diagram containing objects and the links between them.

For example, here is the Tbox component of the educational domain:

Here is the Abox component:

Domains, Sub-domains, and Domain Dependencies

A domain model can be divided into models of sub-domains.

This can be shown by a package diagram. Recall that a package is a named collection of classes, objects, and sub-packages. A package diagram is a class diagram that shows packages and the dependencies between them. A dependency between two packages is represented by a dashed arrow. More specifically, dashed arrow from package A to package B indicates that package A uses some of the items contained in package B. We say that A imports from B or that B exports to A.

Here are a few examples:

A Design Principle

Avoid cycles in a package diagram. This can lead to cyclical dependencies that can be hard to resolve during the implementation phase.

Often cycles in the package diagram can be resolved by picking a package in the cycle and factoring it into two packages, one containing the components that are causing the cycle. For example, the following diagram contains a cycle:

This can be resolved by factoring the elements in p1 used by p3 into a package p1':

Attributes versus Associations

Should a property of a class be modeled as an attribute or an association? For example, a transaction, such as a purchase, has properties date, amount, and id. We can model these as attributes:

Alternatively, we can model these as associations:

Note that the endpoints of an association can also be named. This is the name used by the class to refer to the property. For example, a transaction will refer to the associated money object as "amount", the associated String object as "id", and the associated Date object as date. The default name of an endpoint is the name of the class.

One guideline is to think of a domain model as consisting of domain-specific classes, and foundational classes:

The foundation package might contain general utility classes such as these:

String, Date, Person, Integer, Float, List, Money

Note that these classes are usually domain-independent.

Usually foundation type properties appear as attributes, while domain-specific properties appear as associations.

Beware: what might be foundational for one domain might be domain-specific in another. For example, Date might be regarded as domain-specific in the domain of scheduling, while Money might be domain-specific in the finance domain.

Vaules versus References

An object has attributes. For example, a Person object has attributes name, dob, ssn, and phone number. A date object has attributes day, month, and year. The current value of these attributes, taken together, is the object's state.

For example, consider the following two objects:

The state of p1 is:

name = Bill Smith
ssn = 555-55-5555
phone = 333-4444
dob = bastilleDay

The state of bastilleDay is:

day = 14
month = July
year = 1789

An object is stateless, non-mutable, or is a value object, if its state is constant. Otherwise we say the object is stateful, mutable, or is a reference object.

In the example above, p1 is a reference object because its state can change. In particular, the phone number attribute can change. On the other hand, bastilleDay is a value object.

Having multiple copies of a value object representing the same real world object is rarely a problem, but having multiple reference objects representing the same real world object can lead to synchronization problems.

For example, look at the following objects:

Asking if the occupant of Versailles has the same birth date as the king of France shouldn't cause a problem assuming two dates are equal if their attribute values are equal. Asking for Louis Burbon's phone number can be a problem, because there are two objects representing Louis. Because the phone number can change, it's possible that the phone numbers disagree if one is updated but not the other.

Recall an earlier example:

Note that Money and Date can be shared by multiple transactions. This is because they are value objects. There is no need to have multiple objects representing the same date since they can't be changed.

Strings may or may not be mutable. (In Java they are non-mutable, in C++ they are mutable). In any case, logic demands that identifiers be unique, so sharing an identifier doesn't make sense in this example.

Enumerations

An enumeration is a class with a small number of constant instances. Usually new instances can't be created and existing instances can't be thrown away. The instances, called enumeration literals, can be listed in the class icon.

Association Classes

Consider the relationship "Person X owns N shares of Company Y". Where will N be stored? N is neither an attribute of Company nor Person. In cases like this we can represent links as objects. These link objects are instances of association classes:

During the implementation phase an association class might be translated into Java as follows:

public class Company { ... }

public class Person {
private List<Owns> invstments;
public void add(Company c, int shares) {
investments.add(new Owns(c, this, shares);
}
// etc.
}

class Owns {
private Person owner;
private Company company;
private int shares;
public Owns(Company c, Person p, int num) {
comnpany = c;
person = p;
shares = num;
}
// etc.
}