The
problem domain[1] was defined during
project initiation[2] and
problem analysis[3]. The results of this work were captured in a set of models: the use case model, the object model, and the dynamic model. These models form the baseline for the partitioning decisions. The models each reveal something different about the problem domain.
The use case model describes what the users expect to see when they interact with the finished system. These expectations are expressed as goals, like “withdraw money” and “transfer funds.” These goals imply functionality. For example, the user must be able to provide the bank account number and the amount of money to withdraw. The use cases provide the basis for functional partitioning.
The object model defines the resources of the problem domain. These resources are the information that the system must manage in order to support the use cases. The use cases may create or alter the resources.
At the very least, the use case must have access to the information that the objects own. Consequently, the object model is partitioned to coincide with the functional partitions.
The dynamic model includes two types of interaction diagrams: the
sequence diagram[4] and the
collaboration diagram[5]. Both diagrams illustrate how objects talk to one another. The interaction diagrams describe the communication between the participating objects and thus provide valuable information about the attributes and interfaces of the participating domain objects. When the object model is partitioned, the associations between objects must be preserved because they translate into dependencies between partitions.