To account for the new model elements in the organization of the Design Model.
To re-balance the structure of the Design Model where necessary.
As new elements have been added to the Design Model, re-packaging the elements of the Design Model is often necessary.
Repackaging achieves several objectives: it reduces coupling between packages and improves cohesion within packages in
the design model. The ultimate goal is to allow different packages (and subsystems) to be designed and developed
independently of one another by separate individuals or teams. While complete independence is probably impossible to
achieve, loose coupling between packages tends to improve the ease of development of large or complex systems.
A 'flat' model structure (where all packages and subsystems reside at the same conceptual level in the system) is
suitable for a small system; larger systems need an additional structuring tool called 'layering' (see Guideline: Layering). Layering rules define restrictions on allowed relationships
between certain types of packages. These rules recognize that certain dependencies should not exist: application
functionality should not be directly dependent on specific operating system or windowing system services - there should
be an intermediate layer containing logical operating system and windowing services that insulate the application
functionality from changes in low-level implementation services. Layering provides a way to reduce the impact of
change: by enforcing rules which restrict the dependencies between packages and subsystems, reducing the degree of
coupling between packages and subsystems, the system becomes more robust. It tolerates change.
As new model elements are added to the system, existing packages may grow too large to be managed by a single team: the
package must be split into several packages which are highly cohesive within the package but loosely coupled between
the packages. Doing this may be difficult - some elements may be difficult to place in one specific package because
they are used by elements of both packages. There are two possible solutions: split the element into several objects,
one in each package (this works where the element has several 'personalities', or sets of somewhat disjoint
responsibilities), or move the element into a package in a lower layer, where all higher layer elements may depend upon
As the system grows in complexity, a larger number of layers will be needed in order to have a maintainable and
understandable structure. More than 7-10 layers, however, are unusual in even the largest systems, since complexity
increases and understandability decreases with the number of layers.
An example of layering, including middle-ware and System-software layers, is shown below:
Sample package layering for a Java/Web-based application. Note: the dependencies on the TCP/IP package would not
normally be explicitly modeled as the use of TCP/IP services is encapsulated within the Java VM, java.rmi and the Web
Browser. They are depicted here only for illustration.
Assign responsibilities for the subsystems and layers to individuals or teams. Each package or subsystem should be the
responsibility of a single person (if its scope is small) or a team (if its scope is large).