Software Engineering-System Design Process

System design develops the architectural detail required to build a system or product. The system design process encompasses the following ...

System design develops the architectural detail required to build a system or product. The system design process encompasses the following activities:

• Partition the analysis model into subsystems.
• Identify concurrency that is dictated by the problem.
• Allocate subsystems to processors and tasks.
• Develop a design for the user interface.
• Choose a basic strategy for implementing data management.
• Identify global resources and the control mechanisms required to access them.

• Design an appropriate control mechanism for the system, including task management.
• Consider how boundary conditions should be handled.
• Review and consider trade-offs.

Partitioning the Analysis Model

One of the fundamental analysis principles  is partitioning. In OO system design, we partition the analysis model to define cohesive collections of classes, relationships, and behavior. These design elements are packaged as a subsystem.

In general, all of the elements of a subsystem share some property in common. They all may be involved in accomplishing the same function; they may reside within the same product hardware, or they may manage the same class of resources. Subsystems are characterized by their responsibilities; that is, a subsystem can be identified by the services that it provides . When used in the OO system design context, a service is a collection of operations that perform a specific function (e.g., managing word-processor files, producing a three-dimensional rendering, translating an analog video signal into a compressed digital image).

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

• The subsystem should have a well-defined interface through which all communication with the rest of the system occurs.
• With the exception of a small number of “communication classes,” the classes within a subsystem should collaborate only with other classes within 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. 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 layering, also occurs. Each layer of an OO system contains one or more subsystems and represents a different level of abstraction of the functionality required to accomplish system functions. In most cases, the levels of abstraction are determined by the degree to which the processing associated with a subsystem is visible to an end-user.

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 subsystems that perform the processing associated with the application), (3) a data formatting 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 suggest the following design approach for layering:

1. Establish layering criteria. That is, decide how subsystems will be grouped in a layered architecture.
2. Determine the number of layers. Too many introduce unnecessary complexity; 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 philosophy for the architecture.
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.

Concurrency and Subsystem Allocation

The dynamic aspect of the object-behavior model provides an indication of concurrency among classes (or subsystems). If classes (or subsystems) are not active at the same time, there is no need for concurrent processing. This means that the classes (or subsystems) can be implemented on the same processor hardware. On the other hand, if classes (or subsystems) must act on events asynchronously and at the same time, they are viewed as concurrent. When subsystems are concurrent, two allocation
options exist: (1) Allocate each subsystem to an independent processor or (2) allocate the subsystems to the same processor and provide concurrency support through operating system features.

Concurrent tasks are defined  by examining the state diagram for each object. If the flow of events and transitions indicates that only a single object is active at any one time, a thread of control has been established. The thread of control continues even when one object sends a message to another object, as long as the first object waits for a response. If, however, the first object continues processing after sending a message, the thread of control splits.

Tasks in an OO system are designed by isolating threads of control. For example, while the SafeHome security system is monitoring its sensors, it can also be dialing the central monitoring station for verification of connection. Since the objects involved in both of these behaviors are active at the same time, each represents a separate thread of control and each can be defined as a separate task. If the monitoring and dialing activities occur sequentially, a single task could be implemented.

To determine which of the processor allocation options is appropriate, the designer must consider performance requirements, costs, and the overhead imposed by interprocessor communication.

The Task Management Component

Coad and Yourdon suggest the following strategy for the design of the objects that manage concurrent tasks:

• The characteristics of the task are determined.
• A coordinator task and associated objects are defined.
• The coordinator and other tasks are integrated.

The characteristics of a task are determined by understanding how the task is initiated. Event-driven and clock-driven tasks are the most commonly encountered. Both are activated by an interrupt, but the former receives an interrupt from some outside source (e.g., another processor, a sensor) while that latter is governed by a system clock.

In addition to the manner in which a task is initiated, the priority and criticality of the task must also be determined. High-priority tasks must have immediate access to system resources. High-criticality tasks must continue to operate even if resource availability is reduced or the system is operating in a degraded state.

Once the characteristics of the task have been determined, object attributes and operations required to achieve coordination and communication with other tasks are defined. The basic task template (for a task object) takes the form

Task name—the name of the object
Description—a narrative describing the purpose of the object
Priority—task priority (e.g., low, medium, high)
Services—a list of operations that are responsibilities of the object
Coordinates by—the manner in which object behavior is invoked
Communicates via—input and output data values relevant to the task

This template description can then be translated into the standard design model (incorporating representation of attributes and operations) for the task object(s).

The User Interface Component

Although the user interface component is implemented within the context of the problem domain, the interface itself represents a critically important subsystem for most modern applications. The OO analysis model  contains usage scenarios (called use-cases) and a description of the roles that users play (called actors) as they interact with the system. These serve as input to the user interface design process.

Once the actor and its usage scenario are defined, a command hierarchy is identified.The command hierarchy defines major system menu categories (the menu bar or  tool palette) and all subfunctions that are available within the context of a major system menu category (the menu windows). The command hierarchy is refined iteratively until every use-case can be implemented by navigating the hierarchy of functions.

Because a wide variety of user interface development environments already exist, the design of GUI elements is not necessary. Reusable classes (with appropriate attributes and operations) already exist for windows, icons, mouse operations, and a wide variety of other interaction functions. The implementer need only instantiate objects that have appropriate characteristics for the problem domain.

The Data Management Component

Data management encompasses two distinct areas of concern: (1) the management of data that are critical to the application itself and (2) the creation of an infrastructure for storage and retrieval of objects. In general, data management is designed in a layered fashion. The idea is to isolate the low-level requirements for manipulating data structures from the higher-level requirements for handling system attributes.

Within the system context, a database management system is often used as a common data store for all subsystems. The objects required to manipulate the database are members of reusable classes that are identified using domain analysis or are supplied directly by the database vendor. A detailed discussion of database design for OO systems is beyond the scope of this book.

The design of the data management component includes the design of the attributes and operations required to manage objects. The relevant attributes are appended to every object in the problem domain and provide information that answers the question, “How do I store myself?” Coad and Yourdon  suggest the creation of an object-server class “with services to (a) tell each object to save itself and (b) retrieve stored objects for use by other design components.”

As an example of data management for the sensor object discussed as part of the SafeHome security system, the design could specify a flat file called “sensor.” Each record would correspond to a named instance of sensor and would contain the values of each sensor attribute for that named instance. Operations within the objectserver class would enable a specific object to be stored and retrieved when it is needed by the system. For more complex objects, it might be necessary to specify a relational database or an object-oriented database to accomplish the same function.

The Resource Management Component

A variety of different resources are available to an OO system or product; and in many instances, subsystems compete for these resources at the same time. Global system resources can be external entities (e.g., a disk drive, processor, or communication line) or abstractions (e.g., a database, an object). Regardless of the nature of the resource, the software engineer should design a control mechanism for it. Rumbaugh and his colleagues suggest that each resource should be owned by a “guardian object.” The guardian object is the gatekeeper for the resource, controlling access to it and moderating conflicting requests for it.

Intersubsystem Communication

Once each subsystem has been specified, it is necessary to define the collaborations that exist between the subsystems. The model that we use for object-to-object collaboration can be extended to subsystems as a whole. Figure illustrates a collaboration model. As we noted earlier in this chapter, communication can occur by establishing a client/server link or a peer-to-peer link. Referring to the figure, we must specify the contract that exists between subsystems. Recall that a contract provides an indication of the ways in which one subsystem can interact with another.

The following design steps can be applied to specify a contract for a subsystem :

1. List each request that can be made by collaborators of the subsystem. Organize the requests by subsystem and define them within one or more appropriate contracts. Be sure to note contracts that are inherited from superclasses.

2. For each contract, note the operations (both inherited and private) that are required to implement the responsibilities implied by the contract. Be sure to associate the operations with specific classes that reside within a subsystem.

3. Considering one contract at a time, create a table of the form shown in figure.

 For each contract, the following entries are made in the table:

Type—the type of contract (i.e., client/server or peer-to-peer).
Collaborators—the names of the subsystems that are parties to the contract.
Class—the names of the classes (contained within a subsystem) that support services implied by the contract.
Operation—the names of the operations (within the class) that implement the services.
Message format—the message format required to implement the interaction between collaborators.

Draft an appropriate message description for each interaction between the subsystems.

4. If the modes of interaction between subsystems are complex, a subsystem- collaboration diagram, illustrated in figure is created.

The collaboration graph is similar in form to the event flow diagram. Each subsystem is represented along with its interactions with other subsystems. The contracts that are invoked during an interaction are noted as shown. The details of the interaction are determined by looking up the contract in the subsystem collaboration table