DeLineEtAl97

PublicReengineering Wiki

The authors report on their experiences of converting a batch system to one that incorporates an interactive user interface. The specific application is a CASE tool, but their descriptions are pretty generic. Batch systems have a predetermined order of computational steps and this is little need to cleanly decouple stages or to incrementally repeat steps. Response time and the ability to run independent concurrent jobs are generally not a concern. they accept one or more complete input and produce one or more complete outputs before terminating. they may have intermediate, transient results. human intervention in generally not expected or accepted. Once the process begins, there is no need for external influence. Interactive systems, on the other hand, do expect humans to participate throughout computation. they can have internal control, ie user is prompted for each piece of information in turn, or external control where the user is confronted with a form and can enter and update info in any order. The use the term "work product" to describe the shared data between the input and output. A batch system is invoked for a single job and lasts a relatively short time. An interactive application can be invoked for multiple jobs, eg word processors can act on multiple documents at any one time, and the session can last indefinitely. No internal data structures persist between batch invocation, eg even a small change to the input stream necessitates a re-run of the job, where as incremental changes can be made to the interactive work product. The batch system's input is fixed at invocation and therefore must be complete, however, the interactive system can create and modify inputs at any time and must be tolerant of missing or incomplete data. The structured form of the batch input means that the computation can be well structured into sub-computations or phases. Because the user drives the interactive inputs, less assumptions can be made about the ordering or repetition of the computation. The interactive system may be required to support modifications and deletions of portions of the work product - functionality not required of the batch application. The batch system generally reports on errors in the inputs and can either tolerate or terminate - reporting its actions to a log. The interactive system can be designed to prevent errors, eg menus with predefined options. In addition, the interactive system should generally recover from errors and allow the user to correct the input. Also the information in and context of the error messages needs to be different, eg line numbers may not be relevant to the interactive message. Early on in the reengineering, strategic architectural decisions need to be made. The choices are to have a shared data presentation between the computation and the UI, ie state driven. This is useful if the two parts of the system are closely coupled and provides fast response. Alternatively, if the two are not so closely coupled, an external shared data repository can be used, but this introduces a performance penalty. Another option is to have discrete action driven operation. This means the two components communicate via function calls, messages or events to notify the system of changes to the data representation. An example would be for one component to call API functions supplied by the other component. This permits looser coupling between the UI and the computational sub-system. A special case would be where the shared data is encapsulated into an object. Here the operations of the object provide a common, symmetrical API for the UI and computational subsystem. This approximates to data sharing and can insulate the computational subsystem from changes in the UI. Another issue is memory management. Since batch applications are seldom persistent and do not incorporate delete operations, they do not have to avoid memory leaks or track and reuse memory. However, interactive systems can be long lived and can provide editing facilities they need to manage themselves carefully to avoid running out of free memory. With incremental systems, the re-computation and processing of partial data can lead to the invocation of code in new contexts and the entry assumptions made by batch code may longer hold. These scenarios all need checked. Since the batch systems functionality can be expressed as monolithic processes, eg input, computation, output, the individual functionality called for by th interactive UI needs to be excised from the code and made available as individuals computations. The data needs to be structured to handle multiple work products. For instance, the same code may be independently used for different work products during the same session and data for each needs to be differentiated to avoid corruption.

• Start Here in this Web
• Categories
• Index
• Recent Changes
• FAQ