Partitioning the Analysis Model

22.2.1 Partitioning the Analysis Model

One of the fundamental analysis principles (Chapter 11) is partitioning. In OO system design, we partition the analysis model to define cohesive collections of classes, rela-

The concepts of tionships, and behavior. These design elements are packaged as a subsystem. coupling and cohesion

In general, all of the elements of a subsystem share some property in common. (Chapter 13) can be

They all may be involved in accomplishing the same function; they may reside within applied at the

the same product hardware, or they may manage the same class of resources. Sub- subsystem level. Strive

to achieve good systems are characterized by their responsibilities; that is, a subsystem can be iden- functional

tified by the services that it provides [RUM91]. When used in the OO system design independence as you

context, a service is a collection of operations that perform a specific function (e.g., design subsystems.

managing word-processor files, producing a three-dimensional rendering, translat- ing an analog video signal into a compressed digital image).

As subsystems are defined (and designed), they should conform to the following design criteria:

? What

• The subsystem should have a well-defined interface through which all com-

criteria

munication with the rest of the system occurs.

guide us in the

• With the exception of a small number of “communication classes,” the

design of

classes within a subsystem should collaborate only with other classes within

subsystems?

the subsystem. • The number of subsystems should be kept low. •

A subsystem can be partitioned internally to help reduce complexity. When two subsystems communicate with one another, they can establish a

client/server link or a peer-to-peer link [RUM91]. In a client/server link, each of the subsystems takes on one of the roles implied by client and server. Service flows from server to client in only one direction. In a peer-to-peer link, services may flow in either direction.

When a system is partitioned into subsystems, another design activity, called lay- ering, also occurs. Each layer [BUS96] of an OO system contains one or more sub- systems and represents a different level of abstraction of the functionality required to accomplish system functions. In most cases, the levels of abstraction are deter- mined by the degree to which the processing associated with a subsystem is visible to an end-user.

CHAPTER 22

OBJECT-ORIENTED DESIGN

For example, a four-layer architecture might might include (1) a presentation layer (the subsystems associated with the user interface), (2) an application layer (the sub- systems that perform the processing associated with the application), (3) a data for- matting layer (the subsystems that prepare the data for processing), and (4) a database layer (the subsystems associated with data management). Each layer moves deeper into the system, representing increasingly more environment-specific processing.

Buschmann and his colleagues [BUS96] suggest the following design approach for layering:

? 1. Establish layering criteria. That is, decide how subsystems will be grouped in

How do I

create a

a layered architecture.

layered design?

2. Determine the number of layers. Too many introduce unnecessary complex- ity; too few may harm functional independence.

3. Name the layers and allocate subsystems (with their encapsulated classes) to

a layer. Be certain that communication between subsystems (classes) on one layer and other subsystems (classes) at another layer follow the design phi- losophy for the architecture. 8

4. Design interfaces for each layer.

5. Refine the subsystems to establish the class structure for each layer.

6. Define the messaging model for communication between layers.

7. Review the layer design to ensure that coupling between layers is minimized (a client/server protocol can help accomplish this).

8. Iterate to refine the layered design.