Domain partitioning is a process for dividing a problem domain into cohesive units before proceeding into detailed object design.
The problem domain was defined in the first two phases of the project using the use case model, the object model, and the dynamic model.
In this module, you will learn how to perform the domain partitioning process using these tools as your primary source.
After completing this module, you will be able to:
Identify the resources used for domain partitioning
Perform domain partitioning using use cases
Explain how package diagrams may be used to model domain partitions
Assign analysis classes to domain partitions
Test the domain partition for completeness
Identify and define dependencies between partitions
Combining DFD Fragments to Create Event-Partitioned System Model
Complex systems require careful and detailed analysis and design. Throw-away prototyping is particularly well suited to such detailed analysis and design, but system prototyping is not.
The waterfall methodologies can handle
complex systems, but without the ability to get the system or prototypes into user's hands early on, some key issues may be overlooked.
Although iterative development methodologies enable users to interact with the system early in the process, we have observed that project teams who follow these methodologies tend to devote less attention to the analysis of the complete problem
domain than they might if they were using other methodologies.
Domains allow partitioning of systems into collections of components that have some characteristic in common.
In this architecture a domain is a scope in which a collection of objects, said to be members of the domain, is associated with some common characteristic;
any object for which the association does not exist, or is undefined, is not a member of the domain.
A domain can be modeled as an object and may be itself a member of other domains.
It is the scopes themselves and the object associations or bindings defined within them which characterize a domain. This
information is disjoint between domains. However, an object may be a member of several domains, of similar kinds as
well as of different kinds, and so the sets of members of domains may overlap.
The concept of a domain boundary is defined as the limit of the scope in which a particular characteristic is valid or
meaningful. When a characteristic in one domain is translated to an equivalent in another domain,
it is convenient to consider it as traversing the boundary between the two domains.
Domains are generally either administrative or technological in nature. Examples of domains related to ORB interoperability issues are:
Referencing domain the scope of an object reference.
Representation domain: the scope of a message transfer syntax and protocol.
Network addressing domain: the scope of a network address.
Network connectivity domain: the potential scope of a network message.
Security domain: the extent of a particular security policy.
Type domain: the scope of a particular type identifier.
Transaction domain: the scope of a given transaction service.
The waterfall model is a breakdown of project activities into linear sequential phases, where each phase depends on the deliverables of the previous one and corresponds to a specialisation of tasks.