Purpose
|
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 it equally.
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).
|