2.1 The System Model

We build an executable UML model for each subject matter, or domain, in the system. To establish the domains, we gather requirements expressed as use cases and sort them, based on their vocabularies, into the various subject matters in the system.

Requirement-gathering and domain identification go together. Sometimes we know what the domains are and build use cases against them, and sometimes we have use cases but have to work out what the domains are. Typically, of course, it's a mixture of the two, so we iterate between the two activities.

2.1.1 Domain Identification

Each domain is an autonomous world inhabited by conceptual entities. The conceptual entities in one domain require the existence of other conceptual entities in the same domain, but they do not require the existence of identified conceptual entities in other domains.

Each domain, except for the application, provides services to other domains, and each domain can make use of other domains. We show the domains and the relationships between them on a domain chart (Figure 2.1). Ancillary notes define the meaning of each element on the chart.

Figure 2.1. Domain Chart

Each package symbol on the domain chart represents a domain, and the dotted lines are domain dependencies. The example domain chart shows an online bookstore relying on the existence of a web GUI. However, the online bookstore has no knowledge of the concepts housed by the web GUI; in fact, the web GUI could be replaced by any other user interface, even the Vulcan mind-meld. Domain dependency is a different beast from compilation dependency between packages, so we give it a different name, a bridge.

A domain may be too big for a single team, in which case we may divide it into parts called subsystems, which we also represent as packages. Subsystems may explicitly make use of concepts from other subsystems in the same domain because boundaries between subsystems are essentially arbitrary, selected for convenience and the manageable size of the resulting subsystems.

2.1.2 Use Cases

The functional, or behavioral, requirements on the system can be expressed textually or more formally in terms of use cases.

Systems respond to requests from actors, and each collection of responses, an interaction, is a use case. Each use case is a set of behavioral requirements placed on the system by the role played by the actor.

Initial use cases may span several domains. In our bookstore example, a use case to place an order will affect the application, a user interface, a database to capture the order, and so on. To build an executable UML model for a domain, each use case should be expressed solely in terms of the vocabulary of that domain. Hence, we would frown on the use case "Select a book to purchase from a pull-down menu," because it mixes up what is being done ("Select a book to purchase") with the mechanism used to make it happen ("Select an arbitrary item from pull-down menu"). Rather, these should be represented as separate use cases for the book store and for the user interface.

The vocabulary used in the expression of the use case should match the vocabulary of the associated domain. Hence, the use case "Select a book to purchase from a pull-down menu" would be acceptable if "book" and "pull-down menu" were both concepts in the same domain. Consequently, as you work the use cases, it can change your view of the domains, and vice versa.

Use cases help establish the domains for which we build executable UML models. Use cases also provide us with the vocabulary we need to be able to build appropriate abstractions in each domain.

2.1.3 Iterating the System Model

The domain chart provides the highest-level view of the system. Consider a very simple system with a small application and a limited number of services, such as a user interface, and with no layering of the content of the application. Creating the initial domain chart might take one hour, and it would be updated once or twice throughout the project's lifetime.

At the other end of the spectrum, consider an application with a great deal of layering and a good number of services, such as messaging or decision support. Creating an initial picture of the system may take a day or two and require monthly updates as the interfaces between the layers become better understood.

By design, domains are semantically autonomous of one another, so we can build domain models for each one independently, but when we have limited resources, we need to select which domain(s) to model first. Select the domain(s) based both on available expertise and on the relative risk of being surprised by a unexpected requirement.

Unexpected requirements can come about when one domain provides services to another. An incomplete understanding of the domain requesting the service can lead to incomplete requirements for the domain providing the service. When in doubt, model the domain requesting the service in preference to the one providing it.

Sometimes when building the class models it becomes clear that the whole domain is at the wrong level. This should trigger revisiting the domain chart.