Section 4.2. EXAMPLE: SOCIAL SECURITY SERVICES

4.2. EXAMPLE: SOCIAL SECURITY SERVICES

We first present a simple example to illustrate the issue of composing and reusing multiple concerns in object-oriented programs when the requirements evolve. The example is a simplified version of the pilot study conducted in [17]. Due to the evolving business context, the initial software has undergone a series of modifications. We use a change scenario to explain the concepts and the application of the CF approach.

4.2.1. An Overview of the Application

The context of the example is a (Dutch) government-funded agency that is responsible for the implementation of disability insurance laws. As illustrated in Figure 4-1, the agency implements five tasks. Task RequestHandler creates a case for clients. Cases are represented as documents. RequestDispatcher implements the initial evaluation and distribution of the requests to the necessary tasks. A request can be dispatched to MedicalCheck, Payment, and/or Approval. MedicalCheck is responsible for evaluating a client's degree of disability. Payment is responsible for issuing bank orders. Approval is the (management) task of approving the proposed decisions, such as rewarding or rejecting a claim. Once a request is forwarded by RequestDispatcher, the further processing and routing of documents between tasks is a responsibility of the participating tasks. We would like to emphasize that Figure 4-1 only shows a small part of the actual system [17].

Figure 4-1. Tasks in the example system.

4.2.2. The Software System

The implementation of the system is based on a set of tasks and a number of documents. For now, assume that tasks and documents are implemented using classes. Each client request results in the creation of a document instance. Depending on the document type and input from the client, the document is edited and sent to the appropriate tasks (objects). Each involved task processes the document according to its specific needs.

As shown in Figure 4-2, class Document is the abstract root class of all document types. Every document inherits its attributes and methods (a number of getters and setters and several additional methods, e.g., for accessing the status of the document, or for printing and mailing it). Class Document has several subclasses. For example, ClaimDocument is used to represent the clients' claims. Its attributes are typically writtenthrough the appropriate methodsby various tasks as the document is processed.

Figure 4-2. Part of the class hierarchy of documents that represent client requests.

As shown in Figure 4-3, the interface TaskProcessor declares the basic methods for all tasks. The method process() accepts a document as an argument and starts the task processing for the document; this might be a partially or fully automated process. In the cases where human interaction is required, an "editor" UI tool is opened that presents the document and offers a task-specific interface to perform the manual part of processing. This is handled by the method startEditor(). Typically the last action of a task consists of forwarding the document to the next task(s); this is handled by the method forward(). The actual selection of all permitted tasks in the given state of the system has been factored out into the method selectTask(); the method forward() has the responsibility of choosing one of the permitted tasks.

Figure 4-3. Class definitions for tasks.

These methods must be defined by classes that implement this interface. Figure 4-3 shows some classes for different tasks. Each of these may inherit (task-specific) methods from different superclasses; this is not shown in the figure.

RequestHandler implements the front-end of the office. For example, if a client wants to issue a claim, this task creates an object of ClaimDocument, retrieves the necessary client data, and opens an editor for the document object. The responsible clerk can then perform actions specific for RequestHandler. When the task is completed, the clerk selects a subsequent taskfrom the permitted onesand forwards the document. This causes the invocation of method process() on the next task, with the document passed as an argument.

In this system, new activities are introduced by creating a new structural document class. (In the actual system from which this example has been derived, there were approximately 30 different document types.)