Smalltalk and Object Orientation: an Introduction - Free

20.3 Design phase
The aim of the analysis phase is to identify what needs to be done and not how it is done. The design
phase takes the models produced by the analysis and considers how the requirements can be achieved. It
is broken down into two sub-phases. The first, called the system design, breaks the overall system down
into components called subsystems, while the second, called the object design, moves the models
produced towards the implementation.
20.3.1 System design phase
The subsystem architecture provides the context within which the more detailed design decisions, made
during the object design, are performed. The subsystem decomposition defines an architecture which
can be used as the basis by which the detailed design can be partitioned among a number of des igners,
thus allowing different designers to work independently on different subsystems. The steps used to
generate this architecture are:
1. Organizing the system into subsystems.
2. Identifying concurrency inherent in the problem.
3. Allocating subsystems to processors and tasks.
4. Choosing an approach for management of data stores.
5. Handling access to global resources.
6. Choosing the implementation of control in software.
7. Handling boundary conditions.
8. Setting trade offs between competing priorities.
Of course not all these steps will be important for all applications. For example, a batch oriented, purely
serial process, probably cannot have much concurrency imposed on it.
20.3.1.1 Breaking the system into subsystems/packages
Most systems will be comprised of a number of subs ystems, for example, a payroll system might
possess a file subsystem, a calculation subsystem and a printing subsystem. A subsystem is not an
object nor a function, but a package of classes, associations, operations, events and constraints that are
interrelated and that have a reasonably well -defined and (hopefully) small interface with other
subsystems. The package notation in the UML can be used to represent subsystems.
A subsystem (or package) is usually characterized by the common (or associated) set of services that
it provides. For example, the file package would provide a set of services to do with creating, deleting,
opening, reading and writing files. The use case model may be useful in identifying such common
services.
Each package therefore provid es a well defined interface to the remainder of the system which
allows other packages to use its facilities. Such a specified interface also allows the internals of the
package to be defined independently of the rest of the system (i.e. it encapsulates th e package). In
addition, there should be little or no interactions between objects within the package and objects in
another package (except via the specified interfaces).
Packages can be hierarchical and may be involved in client-server or peer to peer relationships with
other packages. Client -server relationships are easiest to implement and maintain as one package
responds to requests from another package and returns results. In peer to peer relationships both
packages must be capable of responding to r equests from the other. This can result in unforeseen
circularities.
20.3.1.2 Identifying concurrency
Concurrency can be very important for improving the efficiency of a system. However, to take full
advantage of concurrency the system must be designed around the c oncurrency inherent in the
application. This can be done by examining the dynamic model for objects which receive events at the
same time or perform any state transitions (and associated actions) without interacting. Such transitions
166