A software design technique for client--server applications

CONCURRENCY: PRACTICE AND EXPERIENCEConcurrency: Pract. Exper., Vol. 11(1), 21–42 (1999)

A software design technique forclient–server applicationsJAHANGIR KARIMI∗

Professor of Information Systems, University of Colorado at Denver, College of Business and Administration,Campus Box 165, PO Box 173364, Denver, CO, 80217-3364, USA

SUMMARYSoftware design is the process of mapping software functional requirements into a set of modulesfor implementation. In this paper, a new design technique called the concurrent software designtechnique (CSDT) is proposed. CSDT extends software design techniques, which are based onstructured analysis and design, by identifying independent concurrent tasks for implementationin multiprocessing, multitasking and the C/S environment. A case study on re-engineering alarge legacy system, implemented on mainframes as a sequential system, to a C/S environmentis presented next in order to highlight the benefits of the CSDT. Finally, this paper concludeswith a comparison of CSDT with other existing approaches and the lessons learned from theexperience with this technique. Copyright 1999 John Wiley & Sons, Ltd.

INTRODUCTION

Recently, many information systems (IS) managers have been confronted with the task ofre-engineering legacy systems to client–server (C/S) applications[1,2]. C/S computing isa system in which computer processing is split between clients and servers on a networkwith each task being assigned to the machine best suited to perform it. It offers efficientuse of processing power and increased scalability and integrity, and allows for stagedimplementation, ease of use, increased user satisfaction and high return on investment[3].However, the move from mainframes to C/S is not an easy task[1,4]. Many organizationshave not realized the expected benefits of C/S computing because of the C/S developmenttools, methodologies and core designs[5].

There are similarities between software design for C/S applications and sequential sys-tems. For both types of these systems, the activity of design involves developing a series ofmodels: processor level, task level and program level models[6]. Processor Level Mod-els are to allocate the functional requirements (represented as transforms) to processors.Task Level Models are to assign one or more transforms allocated to a given processor totasks. Finally the design activity at program level is concerned with the development ofan appropriate hierarchy of program modules and specifying the interface between thosemodules to implement the specification created at the task level.

In a C/S environment applications are partitioned into tasks. Each task can be developedand maintained separately, run on a different platform under different operating systemand different network protocol. There are six types of tasks in C/S environment: (i) userinterfaces (what the user actually sees); (ii) presentation logic (what happens when theuser interacts with the form on the screen); (iii) application logic (business rules); (iv) data

∗Correspondence to: J. Karimi, Professor of Information Systems, University of Colorado at Denver, Collegeof Business and Administration, Campus Box 165, PO Box 173364, Denver, CO, 80217-3364, USA.

CCC 1040–3108/99/010021–22$17.50 Received 13 October 1997Copyright 1999 John Wiley & Sons, Ltd. Accepted 12 June 1998

22 J. KARIMI

requests and results acceptance; (v) data integrity (such as validation, security and com-pleteness), and (vi) physical data management (such as update, retrieval, deletion andvalidation). The key to software design for C/S applications is a careful partitioning of theapplication into tasks and determining where (server or client) to store executable code andexecute the application logic. At this point of the design process, these are still consideredlogical partitioning[7] because the technical implementation design is not defined until allthe technology has been chosen. The benefits of first doing logical partitioning is that itmakes it possible to physically implement the logical tiers differently, depending on theneeds of the organization. In a three-tier C/S system, application logic is placed on a sepa-rate server, which contains the entire application or, more frequently, shares the applicationwith other servers, clients or the mainframe[8].∗

C/S systems offer distinguishing benefits, including: (i) shared resources: a server mayservice many clients at the same time and regulate their access to shared resources; (ii)asymmetrical protocols: there is a many-to-one relationship between clients and server;(iii) transparency of location: the server is a process that can reside on the same machineas the client or on a different machine across a network; (iv) mix-and-match: the ideal C/Ssoftware is independent of hardware or operating system software platforms; (v) message-based exchange: clients and servers are loosely coupled systems that interact through amessage-passing mechanism; (vi) encapsulation of services: the server is a ‘specialist’;(vii) scalability: C/S systems can be scaled horizontally (adding or removing a client) orvertically (migrating to a larger and faster server machine or multiservers); (viii) integrity:the server code and server data are centrally maintained, while clients remain personaland independent[8]. The three-tier C/S provides added flexibility by (i) making it easyto change, customize, or reuse the business rules (contained in the application server) indifferent applications; (ii) making it easy to change the application, user interface, or both;and (iii) separating the application logic from the database. Designing the application toensure that servers and clients shoulder the appropriate type and amount of processing iskey to the smooth operation of many C/S applications. Inappropriate partitioning results inserious network and application processing bottlenecks[5].

In designing software for a sequential system, developers in many organizations havebeen using structured analysis/structured design (SA/SD)[9–13] techniques. These tech-niques are well-understood and offer training support and support for analysis/designverification/validation via CASE tools[14]. SA/SD are not useful for designing concurrentsystems because the data flow diagram (DFD) does not capture the control aspects ofthe functional requirements. Recently, Hatley and Pirbhai specifications and design strate-gies have extended the SA/SD techniques by offering (i) graphic notations which make aclear distinction between data flow and control flow, and (ii) formal foundations, whichare primarily based on data/control flow and functional decomposition, and secondarilyon the finite state machine[15].† This paper describes a new design technique called theconcurrent software design technique (CSDT). Hatley and Pirbhai specification strategies

∗For example, if an order entry application is going to be used by hundreds of order entry clerks sitting on thephone all day taking orders as well as on a salesperson’s laptop, the same functionality may be needed in bothplaces, but the physical implementation will be different. There should be clear and logical boundaries betweenthe logical tiers of a multi-tier architecture, even if the tiers will be physically placed on one machine. The logicalpartitioning creates the most adaptable design[7].†Petri nets are also used for specifying systems with potential timing problems and for describing concurrent

interrelated activities[18]. However, despite their many potential benefits they are not some panaceas and sufferfrom many of the same problems associated with formal methods[19].

Copyright 1999 John Wiley & Sons, Ltd. Concurrency: Pract. Exper., 11, 21–42 (1999)

SOFTWARE DESIGN TECHNIQUE FOR CLIENT–SERVER APPLICATIONS 23

are used in CSDT to model the functional requirements. In CSDT, by analyzing data andcontrol aspects of functional requirements simultaneously, multitasking and/or parallelismsare identified in the analysis phase. CSDT helps a designer in developing the processor,task and program level models for implementation in a C/S computing environment.

In the following, first we present a background on Hatley and Pirbhai specificationstrategies for concurrent systems[15] and the principles for software design for concurrentsystems[16,17]. The processor and task level analysis and design strategies in CSDT arepresented next. Then a case study on re-engineering a large legacy application into a C/Ssystem is presented in order to highlight the benefits of the CSDT. The experience withCSDT on a variety of projects is presented next. Then CSDT is compared with otherconcurrent software design approaches that are based on the SA/SD. Finally, this paperconcludes by describing the various directions that this research is now taking.

BACKGROUND

In this Section, first the Hatley and Pirbahi specification strategies are described. Then wepresent the principle of software design for concurrent systems.

Hatley and Pirbhai’s analysis and design strategies

In structured analysis, a system’s functional requirements are modeled using data flowdiagrams (DFDs), data dictionaries (DDs) and process specifications (PSPECs). SA/SDoffers a 4 set of techniques for partitioning systems into modules and a set of criteriafor analyzing the quality of the resulting design[6,20]. DFDs model systems’ functionalrequirements using a set of transforms and data flows and/or data stores among transforms.While transforms are sometimes referred to as processes, the former term will be used hereto avoid confusion with concurrent processes.

In Hatley and Pirbhai specification techniques, control flows are represented in diagramsparallel to the data flows. These are called control flow diagrams (CFDs). The transformson the CFDs have the same name and number as their associated transforms on DFDs.Transforms on the CFDs do not represent processing of the entering control flows; this isdone in the control specifications (CSPECs). The control flow entering transforms on theCFDs do not activate/deactivate the transforms; this is also done in CSPECs. In contrast toDFDs, in which internal sources and destinations of data flows are primitive processes, theinternal sources of control flows are CSPECs. In addition the primitive control signals on aCFD are always discrete, whereas primitive data flow signals on a DFD may be continuousor discrete (usually the former). Control stores have exactly the same role in CFDs as datastores have in DFDs: they store control flows after the sources of those flows have ceasedproducing them and until it is overwritten. The control information, e.g. ‘on’ and ‘off’signals, stored in control stores may be used any time after that information is stored. Agiven store may be unique to a DFD, unique to a CFD, or used both in a DFD and in itsassociated CFD. Figure 1 shows a combination of CSPEC with its DFD and CFD.

CSPECs are associated with high-level transforms, which describe the logic that controlshigh-level system states. They do not describe detailed interaction among primitive trans-forms. Transforms that are not controlled from a CSPEC are ‘data triggered’ (see transform3 in Figure 1). They are enabled each time there is sufficient data at their inputs to performthe specified function. A CSPEC is present only where some transform control is required


24 J. KARIMI

Figure 1. CSPEC with its DFD and CFD (adopted from [20])

on an associated DFD or where some control signals are to be converted into new controlsignals. Since the control signals never flow into primitive transforms, CFD decomposi-tion always terminates before decomposition of the associated DFDs; CFD decompositionterminates in CSPEC.



The bar symbol indicates CSPEC interfaces and the control flows that enter and leaveCSPEC. Control flows flowing into a bar on a CFD must appear as inputs to the CSPEC,and control flows out of a bar must be generated in the CSPEC. CSPECs contain diagramsor tabular representations of finite state machines (FSM), i.e. state transition diagrams, statetransition matrices and tables, and decision tables, needed to represent the type of behaviorof the system. As shown in Figure 1, the control signals flowing to and from the CSPECbars on the CFDs are the inputs and outputs of the FSM. The CSPECs represent the FSMbehavior of the transforms on the CFDs, using state transitions diagrams (STDs).

In Hatley and Pirbhai analysis and design strategies, large transforms are decomposed aslong as transforms are ‘complex’. As stated by Hatley and Pirbhai[15], ‘the biggest singledifficulty in constructing a requirement’s model is perhaps knowing where to stop thedecomposition process’ and that ‘there is nothing inherent in the method to help you here’(p. 145). In these strategies, no distinctions are being made between analysis and designphases, and no explicit guidelines are provided for developing the processor level, task leveland program level models. The layers of DFD/CFD model the decomposition process. Thenumber of physical modules in this model is dependent on the depth of the decompositionin the requirement model and the number of physical entities that have to communicateat any given level of decomposition. Based on these strategies, besides adding four moremodeling perspectives to the requirement model, no distinctions are being made betweenanalysis and design phases, and no explicit guidelines are provided for developing the tasklevel and program level models. The four added perspectives are for input processing,output processing, user interface processing and maintenance or self-test processing. Anarchitecture module specification (AMS) is written for every module in this model to statethe allocation of data flow, control flow and processing to be performed by each module.When a transform is allocated to a module, all the data and control flows into or out of thattransform and all the children of that transform are allocated along with it. These strategieslack explicit design guidelines to help a designer in making the processor level, task leveland program level allocation decisions.

Concurrent software design principles

In concurrent software design, the design requirements typically consist of sets of concur-rent tasks that need to interact and synchronize with each other. Concurrent tasks do notneed to be executed in sequential order relative to each other. Task interactions include invo-cation interactions, communication interactions and resource conflict interactions[16,17].Concurrent systems may be implemented on: (i) a single processor with a multitaskingoperating system; (ii) a single processor with an implementation language that allows mul-titasking; (iii) a multiprocessor that runs several tasks concurrently; and (iv) on a group ofdistributed processors that run concurrently in a network environment.

Implementations on multiple processors may be based on either a parallel computingparadigm or a distributed C/S paradigm. Parallel computing and distributed C/S paradigmsboth have design objectives that are entirely different from single-processor concurrentimplementations. Typically software implementations based on these paradigms includemany more tasks than is typically justified by concurrence in the problem domain[17]. Asexplained by Sanden, ‘a common concurrent design error is to include unjustified taskswhich make the software inefficient and unnecessarily complex. For example, tasks thatonly make sense on parallel hardware is included in single processor concurrent systems,


26 J. KARIMI

or C/S designs are used for single-processor concurrent applications’[38].In single-processor hardware, concurrent systems are implemented with the use of a

multitasking operating system or an implementation language which allows multitasking,e.g. Ada[21,22]. In a single processor, an extra task is justified only if it can operateasynchronously since the overhead cannot be offset. In the parallel computing paradigm,multiple processors run in a time-sharing mode and allow several tasks to run concurrently.The design objective in this paradigm is to identify independent tasks that can execute inparallel in order to make the most of the parallel hardware. In this paradigm, addition ofextra tasks is justified because the overhead is offset by extra processors. Similarly, in thedistributed C/S paradigm, tasks may run concurrently on a network environment[17,23].However, in these systems, the design objective is reconfigurability. Software is partitionedinto subsystems (or transactions) that communicate via messages and/or remote procedurecalls, and the subsystems can operate either on the same or different processors (servers).A transaction becomes the fundamental unit of recovery, consistency and concurrencyin a C/S system, and the application is to provide the integrity expected in a real-lifebusiness transaction[24]. The runtime reconfigurability, however, incurs overhead andsystem response that is often unpredictable due to message queuing and frequent taskswitching. While the reconfigurability objective may be worth its overhead in interactiveenvironments, it is usually too complex for systems operating without human intervention(such as those appropriate for parallel computation). Distributed C/S computing, therefore,incurs design costs for increased control complexity[23].

A concurrent design technique, therefore, needs to explicitly consider the architectureof the hardware to avoid unnecessary overhead and design complexity[25]. It also needsto consider the relationships among transforms in order to form tasks. Otherwise, a taskmay contain functional requirements that are not in sequence and may not be completelyexecutable.

CSDT OVERVIEW

In CSDT, guidelines are proposed to identify relationships among transforms and to identifytransforms for decomposition. In addition, guidelines are proposed to assign transforms toprocessors, transforms to tasks, and then tasks to modules. At each level of decomposition,transforms are assigned to independent tasks in order to reduce coupling among tasks. Theindependent tasks then are designed using SD guidelines, and implemented as informationhiding modules. By simultaneous analyses of data and control aspects of the requirements,in CSDT the potentials for multitasking or parallelism are identified for the processor andtask level modeling phases.

CSDT analysis strategy

As shown in Figure 2(a), two transforms may have (in)dependent data and/or control flows.Two transforms have dependent data flow if there is a direct data flow between them. Twotransforms have independent data flows if they are either connected via a data store or notconnected at all. Two transforms have dependent control flows if there is a direct controlflow from a transform to another, or if they have dependent activation/deactivation via aCSPEC. Two transforms have independent control flow if they are connected via a controlstore, or if they have independent activation/deactivation. Note that when two transforms



Figure 2a. Data and control dependence among transforms

have independent data or control flows, there may be a data or control store between themand they may share data or control (see case (a) in the independent data and control flowsection of Figure 2(a)). However, data or control does not transfer immediately from oneto another.

CSDT processor level modeling strategy

In CSDT, when two transforms are both data flow and control flow dependent they aregrouped together as a task to run on a single processor (a task is defined as a group ofone or more transforms. It is ultimately implemented as one or more program modules.)When two transforms are either data flow or control flow independent, each transform isassigned to a separate task under a single controller. The controller acts as FSM. Each entryrepresents each state and each relevant control event which defines the necessary actionsand the successor table. The controller interprets the table and maintains a state variableindicating the current state. When a relevant control event has occurred, the correspondingentry is located, action is taken, and the state variable is updated. Implementation of these


28 J. KARIMI

Figure 2b. Binary data and control flow relationships among transforms

tasks on multiple processors is based on either the parallel computing paradigm or thedistributed C/S paradigm[17].

In case two transforms are both data flow and control flow independent, a higher degreeof flexibility exists for their implementation. They can either (i) be assigned to two separatetasks and be under different controllers, or (ii) be implemented on a multiprocessor or ona network of single processors, or (iii) run concurrently under multiple controllers on anetwork of single processors.

CSDT task level design strategy

As shown in Figure 2(b), there are four distinct task types based on the data and controlflow relationships among transforms: sequential, mutually exclusive, mutually dependentand coincidental.

Two transforms have a sequential relationship if they have dependent control flow anddependent data flow. For sequential transforms the second transform is activated after thefirst transform completes, and the output produced from the first transform is an input to thesecond transform. To reduce coupling among tasks and to increase tasks’ cohesion, thesetransforms can be grouped together as one task.

Two transforms are mutually exclusive if they have dependent control flow and inde-pendent data flow. In this case, one transform cannot be activated during time periods whenthe other is active. Each of the mutually exclusive transforms are assigned to a separatetask under a single controller. The controller (FSM) is to provide mutual exclusion in orderto avoid resource competition and to protect data. By doing so, the control is handled



externally as an FSM rather than internally by message switching via an intermediary task.Two transforms are mutually dependent if they have independent control flow and

dependent data flow. In this case, the two transforms can be synchronized at the executiontime. Like the mutually exclusive case, each of the mutually dependent transforms areassigned to a separate task under a single controller. The mutually dependent transforms canalso be synchronized at termination. The execution of the mutually dependent transformsproduces a combined result that is needed for the next step of processing. In this case, thesetransforms need to finish before the next transform can start because the former is waitingfor a reply from the latter.

Two transforms are coincidental if they have independent activations or deactivationsand if they have independent data flows. Each of the transforms is assigned to a separatetask and under independent controllers. Complete scheduling freedom exists for executionof these tasks. Coincidental tasks are good candidates for the parallel computing paradigmsince they are independent with respect to both data and control flows.

For example, in a C/S computing environment the tasks managed by a server may de-pend on one another or may be in coincidental relationship[23]. Generally dependenciesamong tasks consist of data dependencies or synchronization constraints (control depen-dencies). One task’s results may represent data arguments for another task in a transaction.Alternatively one task request may have to wait until another is complete because thefirst request generates a state change that is presupposed by the second (mutually depen-dent case). For example, one cannot deposit funds into a new bank account before theaccount is opened. In contrast, requests for coincidental tasks are indifferent to relativeordering, which simplifies co-ordination requirements. Further, in transaction processingapplications, transactions are generated at the client and sent to the server for processing.The server may, in turn, send one or more tasks to other servers. For a transaction to beconsidered complete, all operations must be successfully performed (mutually dependentcase). If any operation of a transaction cannot be completed, the operations that have takeneffect must be reversed using a process called commit and rollback. All the participatingapplications must adhere to the transaction integrity because a single faulty application cancorrupt an entire system[24]. A transaction that unknowingly uses corrupted initial data,which is produced by a non-transactional program, builds on top of a corrupt foundation.∗

Transaction-processing applications in the C/S environment include order entry, inventory,point-of-sale, air-traffic control, airline reservation and financial trading systems.

CSDT summary of task level modeling steps

CSDT is composed of the following steps:

1. Create a requirement model by capturing data and control flow relationships amongtransforms using DFD/CFD notations.

2. Identify the relationships among transforms on each layers (level of decomposition)of DFD/CFD.

∗In an ideal world, all C/S applications are written as transactions and transactions are managed by TransactionProcessing Monitors. The monitors specialize in managing transactions from their points of origin, which istypically on the client, across one or more servers, and then back to the originating client. The monitors are usedwhen (i) the ‘mission-critical’ application is too big to model using SQL database calls, (ii) there are more than100 clients, processing five or more transactions per minute, and using three or more servers and/or using two ormore databases.


30 J. KARIMI

3. Group transforms that are functionally related and are both data and control dependenttogether as a task.

4. Decompose transforms that are independent with respect to data and/or control flows,i.e. mutually exclusive, mutually dependent and coincidental cases, to lower leveltransforms. Repeat steps 2 through 4 until transforms are no longer independent withrespect to either data or control flows.

5. Design each task using structured design guidelines to develop a set of informationhiding and data abstraction modules.

The following case study illustrates the application of the CSDT in re-engineering anorder disbursement system, which was implemented on a network of mainframes as asequential system, to a distributed multiprocessing, multitasking and C/S environment.Although this case is substantially simplified from the actual design for the purpose of thispaper, it does serve to illustrate the main concepts of the CSDT.

CASE STUDY: ORDER DISBURSEMENT SYSTEM

The order disbursement system is currently implemented on a major information servicesnetwork that provides both national and international access to several large-scale main-frames. The mainframe systems operate as a clustered multiprocessor environment. Thecurrent implementation supports in excess of 200 users on a daily basis, using both con-versational asynchronous and non-conversational synchronous communications modes.

While the current implementation supports multiprocessing on a network of mainframes,it is also designed as a single processor and as a sequential system with all the usercommunications support provided by the mainframe operating systems. CSDT is used toconvert the order disbursement system to a distributed multiprocessor and multitaskingC/S environment. With the current growth of C/S computing such a change in design andimplementation was necessary for scalability, integrity, resource sharing and economicreasons. This case study should be of special interest to practitioners who intend to takeon similar efforts. Major concerns for implementing this system in a C/S environment arescheduling of tasks (transactions), integrity of the server code and data, and the requiredcapacity of each server.

Figures 3(a) and 3(b) represent the data and control context diagrams for the orderdisbursement system. The distributor centers (DC) orders are transmitted daily to the orderdisbursement system on the mainframe. The suppliers may request that a specific orderfile be prepared from all new orders received from DC or that a report of previouslyprepared orders be sent. The system administrator monitors several administrative taskson a daily basis. The monitoring tasks are performed in an interactive mode with theorder disbursement system on the mainframe. From the mainframe’s point of view, thissystem has a number of concurrent characteristics: (i) the mainframes may be sending andreceiving order information from a number of terminals concurrently; (ii) the mainframesneed to respond quite fast, in terms of total number of transactions per second; and (iii)the mainframes need to respond to a number of unscheduled and/or concurrent events ina precise manner (due to synchronizing order information sent and received on terminaltransmission lines).



Figure 3. (a) Data context diagram; (b) control context diagram

Level 0 DFD/CFD

In Figures 4(a) and 4(b), transform 1 is responsible for the user communication requestsand management of communication protocols. This transform has a stringent schedulingrequirement. When a phone call is received, it must be attended to without delay. When dataare being sent or received, buffering of the received data must be given a higher priority thanany other concurrent task. This ensures no loss of data. In addition, the data communicationrates affect processing load and scheduling requirements. The scheduling requirements ofthe individual sessions are constrained by the number of simultaneous users allowed. Sincethe timing of user access is not controlled, the communication manager must be capable ofhandling simultaneous calls.

Transform 2, ‘process DC orders’, is initiated by transform 1 after a DC request todisburse orders is received. Transform 2 reads the distributor orders file, performs edit


32 J. KARIMI

Figure 4. Order disbursement operations: (a) DEDO; (b) CFDO

checks and extracts order data. Upon completion of an order, the order is disbursed to thedisbursed orders file and acknowledged in the confirmation reports file. The confirmationreports file is then queued, via a confirmation control store, for transmittal to the DC.

Transform 3, ‘process supplier orders’, is initiated by transform 1 after a supplier requestto prepare current orders is received. All orders in the disbursed orders file meeting thesuppliers’ requirements are written to an orders transmittal file. This file is then available fortransmission to suppliers. Optionally, a summary report may be prepared for transmissionto the suppliers. As each order is processed, its order status is updated in the disbursed



orders file.∗ The orders transmittal file and the orders summary file are then queued, viaorders summary and orders transmittal control stores, for transmission to the suppliers.

Transform 4, ‘maintain system’, is initiated independently of the other three transforms byan administrative request or by the system administrative schedule. Transform 4 performsfour administrative tasks on a daily basis. First, any file which has been modified duringthe day is ‘backed up’ by the mainframe disk management system. Second, during theorder extraction process, each supplier causes a file maintenance process to be queued.This maintenance process checks the disbursed orders file for orders over 24 h old orcanceled orders, and deletes the orders. The 24 hours time periods are generated in thesupplier orders extraction process. When an order is deleted from a disbursed orders file, aconfirmation is sent to the DC. Third, after all daily activity has been processed, a singleprocess is executed to prepare the DC order confirmations file for the next day’s processing.Fourth, a daily system status report is prepared for the system administrator. This includesa summary of the day’s activities.

Analysis and design strategy at Level 0

Transform 4 is in a coincidental control relationship with any of the other three transforms.In addition, transforms 1 and 2 and transforms 1 and 3 are in a coincidental relationshipsince they have independent data and control flows. Transforms 2 and 3 are in a mutuallyexclusive relationship since at any given moment a user is either a distributor or a supplier.In a multiuser environment, transforms 1, 2 and 3 need to be executed concurrently.

By disregarding control in the analysis, transforms 1, 2 and 3 may be considered togetheras one task, as in the current implementation. In this implementation, the system then eitherprocesses DC or supplier requests at any given moment. However, since transforms 1,2 and 3 are in coincidental relationship, each can be assigned to an independent task.Therefore, four independent tasks (corresponding to the four transforms) are identified atthis level. This identification offers flexibility in implementation since it allows for eithera multiprocessor and multitasking implementation or a single-processor and single-taskingimplementation.

While either design may provide a workable solution, the single processor design doesnot provide much flexibility in the case of growth in the number of users. Because of thestringent scheduling requirements of transform 1, adding additional users will overload theprocessor. The second design allows a multiprocessor and a multitasking implementationeven for a single user. Based on this, processor 1 can operate on a multitasking mode,monitoring communication lines as long as scheduling requirements are satisfied andthe processor is able to handle the communication processing load. Adding additionalusers requires that only the communications manager be executed as multiple concurrenttasks. Adding more users requires multitasking implementation on the same processor, andeventually it requires additional processors. However, additional processors are neededonly when the communications manager requires additional capacity.

Therefore, CSDT has provided flexibility in design and implementation since the systemcan now be considered as a set of concurrent independent tasks and as an FSM at this

∗A supplier may have the orders extraction process performed routinely on a preset schedule. In this case,prior to extracting new orders, the status of the orders transmittal file is checked to determine if the previouslyextracted orders have been transmitted. If they have not been transmitted, new orders are added to the orderstransmittal file.


34 J. KARIMI

level. Disregarding the control flow analysis would have required the designer to allowfor a set of concurrent tasks that need to be synchronized. Accordingly, transforms wouldhave been viewed as concurrent dependent, not independent entities, and would have beendecomposed further to lower levels. Then, at the lowest level of decomposition, transformswould have been grouped together as tasks and task interface modules would have had tobe added to handle coupling among tasks. This would make the software inefficient andunnecessarily complex (see section on comparison of CSDT and other approaches). Byconsidering control at an earlier stage, however, this system is viewed as a set of concurrentindependent tasks. Therefore, it is easier to (re)design and to (re)implement this system fora multiprocessor and multitasking C/S environment.

Level 1 DFD/CFD

In CSDT, the presence of transforms that are independent with respect to data and/orcontrol flow from any other transform causes the decomposition to continue to the nextlevel. Figure 5 shows the decomposition of DFD/CFD for transform 1. Transform 1.1verifies a user request. The verified request is passed to either Schedule Processes (1.2),Queue Output (1.4) or Transmit Data (1.5). Transform 1.3, Store DC Orders, receives therequest to receive and store data. Transforms 1.1, 1.2, 1.3, 1.4 and 1.5 have independent dataflow and dependent control flow. Therefore, they are in mutually exclusive relationship.Each of these transforms are assigned to a separate task under a single controller (CSPEC)at this level.∗

Figure 6 shows the decomposition of DFD/CFD for transform 2. Transforms 2.1, 2.2have dependent data flows and dependent control flows. Therefore, these transforms arein a sequential relationship. These transforms are grouped as one task to run on a singleprocessor. The control flow shown from transform 2.2 (Figure 6(b)) is derived from data.This type of control flow is given a special name, ‘data condition’[15]. The data condition,generated in the child PSPEC of a primitive transform, does not appear as an output fromthat transform on the DFD, but does appear out of the corresponding transform on the CFD.Transform 2.3 is further decomposed at level 2.

Figure 7 shows the decomposition of DFD/CFD for transform 3, Process Supplier Orders.Since the two transforms have independent data flow and independent control flow, they arein a coincidental relationship. Each is assigned to a separate task. Independent executionof transforms 3.1 and 3.2 reduces the total time that the disbursed orders file is in use. If thetwo transforms are grouped together as one task, then they must be executed in sequentialorder. Accordingly, the disbursed orders file must be locked for the duration of the executionof each of the transforms. However, considering that new orders may be received from theDC at any time, the disbursed orders file should not be locked for a longer time period thanis necessary. Sequential implementation also requires a preprocessor to lock the disbursedorders file and to create a temporary file from the disbursed orders file.

Level 2 DFD/CFD

Figure 8 shows decomposition of DFD/CFD for transform 2.3. Transform 2.3 is decom-posed into six lower-level transforms. The DFD/CFD shows that transforms 2.3.1 through

∗Note, transform 1 is not further decomposed to the next level because further decomposition of transforms1.1, 1.2, 1.3, 1.4 and 1.5 will result in primitive transforms with sequential relationships.



Figure 5. Communications managers: (a) DFD1; (b) CFD1

2.3.6 have independent data flows and dependent control flows. Therefore, they are in mu-tually exclusive relationship with respect to each other. Each can be assigned to a separatetask under the control of CSPEC at this level. The state transition table for the CSPEC isshown in Figure 9. Each entry represents the control event and action associated with atransition from the state on the left to the state above. There is more than one transitionbetween one pair of states, so multiple entries are needed in a single element.

In summary, CSDT is a requirement analysis and design technique for software designfor concurrent client–server systems. It focuses on architectural rather than implementationissues. Although implementation issues (number and size of servers) are important, as wellas impact performance, these are considered to be secondary issues by their nature. Thearchitecture and design issues take precedence over implementation issues because baddesign creates problems in implementation and increases maintenance costs.


36 J. KARIMI

Figure 6. Process DC orders: (a) DFD2; (b) CFD2

In CSDT, by considering both data and control flows, parallelism and multitasking areidentified at the processor level and task level modeling phases. A concurrent systemis designed as a set of FSMs. This has led to more flexibility during implementation byproviding the ability to select the host for a task. This added capability has so far had severalbenefits: (i) clean separation of function based on the idea of service; (ii) specializationand easy to upgrade servers without affecting the clients as long as the published messageinterface is not changed; (iii) flexibility in implementation because of vertical and horizontalscalability; and (iv) reduced cost due to resource sharing and hardware cost advantage. Anumber of studies have projected that the gap in the relative cost of development of aC/S system as compared to a time-shared system is expected to widen further due to theemergence of new development tools for the C/S environment[26–28].

EXPERIENCE WITH CSDT

Besides the order disbursement system, the CSDT has so far been used on a varietyof projects. In designing a simulated circuit switching network controller, the CSDT



Figure 7. Process supplier orders: (a) DFD3; (b) CFD3

was effective in identifying concurrency and intermediary Ada Tasks. Although CSDTis language-independent, the introduction of the intermediary Ada tasks and monitorsmakes the design process language-dependent. The monitor tasks are used to determinethe caller/called relationships between Ada tasks. In comparison, the implementation inC or PASCAL would have required the use of executive service requests to a real-timeexecutive. The implementation in Ada, however, can make use of the Ada tasking modelwithout any service requests.

In another project, CSDT was used in designing a system for managing remote reportingof sales data for a large customer base. The analysis in CSDT resulted in three primaryindependent tasks providing the flexibility to implement the system either on a networkedmicroprocessor or in a mainframe environment. The original implementation for the threetasks was on a mainframe because of the availability of development tools on the mainframeand uncertainty with the actual data volume. Subsequently, two of the tasks have beenimplemented on a networked microprocessor, with the third task scheduled for migrationto microprocessors in the near future. The target implementation will use the mainframeonly as a store-and-forward communications manager and the microprocessors for all theintermediate processing. During the requirement analysis in this project, the existence of


38 J. KARIMI

Figure 8. Process order records: (a) DFD2.3; (b) CFD2.3

dependent control flows between transforms caused the requirements to be re-evaluated.The final specifications consisted of a set of tasks with independent control flows. Thisallowed design and implementation to be viewed as a hierarchy of FSMs from the top-level



Figure 9. CSPEC 2.3 state transition table for process order record

DFD/CFD down to the primitive tasks. As a result, the implementation choice for each taskbetween microprocessors and a mainframe had little effect on the design of the system. Outof 11 tasks, seven have the option of running either on microprocessors or on a mainframe.Of the four remaining tasks, two are implemented on the microprocessor and two on themainframe with no need for dual operation.


40 J. KARIMI

COMPARISON OF CSDT AND OTHER APPROACHES

In Ward and Mellor[29], the requirement model is modified to remove concurrency andcontinuous processing and to centralize control. Tasks are required to run on a singleprocessor because the concurrency in the requirement model is removed, and the controlis artificially centralized. This results in imposing constraints on implementation and inunnecessary tasks. As mentioned earlier concurrency criteria should be used to guard againstunnecessary tasks, and control flow analysis is particularly important in concurrent systemssince tasks are to represent concurrent independent entities[17]. The Ward and Mellorapproach has evolved into the recursive design approach[30]. The formalism underlying therecursive design approach and other object-oriented analysis and design approaches, suchas in Booch[31], the object-modeling technique (OMT)[32,37], and OOSE methods[33],is usually done by producing a meta-model of the approaches using the Unified ModelingLanguage (UML)[32]. UML fuses the concepts of Booch, OMT and OOSE. The resultis a single, common, and widely usable modeling language for users of these and othermethods.∗

In DARTS[34], decisions regarding which flows are actually data and which are usedfor control are postponed until after tasks are formed, and the interfaces between tasks areanalyzed. DARTS allows transforms to be combined into tasks based on functional or tem-poral cohesion. Control flow analysis is not a factor in grouping transforms into tasks. Onlyafter tasks are formed, a data flow between two tasks is treated as a control flow and as (i) aloosely coupled message queue, (ii) a closely coupled message/reply queue or (iii) an eventsignal. DARTS identifies many cases of real concurrency where separate tasks are justified.However, combining lower level transforms based on sequential or temporal cohesion† intoconsolidated transforms, which then become tasks, only leads to a network of functionalmodules communicating via messages. Task communication modules (TCM) handle allcases of communications among tasks. Such communications include both closely coupledand loosely coupled message communications. TCM executes concurrently within twotasks in order to ensure correct access to data. A task synchronization module is used tocontrol synchronization among tasks where no actual data transfer is needed. Postponingcontrol flow analysis, therefore, results in higher control coupling among tasks/modules indesign and implementation. Control coupling produces undesirable design because of poormodifiability and understandability[10].

In DARTS, tasks tend to execute alternatively rather than concurrently while processingmessages from each other[17]. As a consequence, concurrency is dealt with internallywithin tasks rather than modeling tasks as independent threads of events. DARTS analysisand design strategies, therefore, fail to identify independent concurrent tasks in the problemdomain or parallelism among tasks. This identification is useful for: (i) reducing the need forspecial-purpose task communication modules; (ii) taking advantage of parallelism betweentasks and implementation in a multiprocessing and a multitasking environment; and (iii)reducing the number of rendezvous in an Ada implementation. In an Ada-based designapproach for real-time systems (ADARTS), both task structuring criteria in DARTS andinformation hiding module structuring criteria are used[35]. Although control flows are

∗UML pushes the envelope of what can be done with existing methods and focuses on a standard modelinglanguage, not a standard process.†Note that in temporal cohesion unrelated functions are executed at a particular time during the processing

sequence. Activities are closely related to those in other modules, creating a tight coupling. Temporal cohesionproduces undesirable design[10].



represented on DFDs, control flow analysis was not used to identify tasks as concurrentindependent entities.

CONCLUSIONS AND FUTURE RESEARCH DIRECTIONS

CSDT extends the concurrent software design techniques, which are based on SA/SDtechniques, to increase their flexibility in design and implementation of large and complexC/S systems. In CSDT, by simultaneous analyses of DFD/CFDs, areas of possible dataand control flow independence are identified early in the analysis. Design decisions aremade based on this independence, and task allocation is justified by real concurrency inthe system functional requirements. Hence, concurrency requirements are addressed in therequirements analysis stage rather than in the design or implementation. As a result, onecan take advantage of multiprocessing and multitasking during the implementation. Withthe current growth of C/S computing, this flexibility can only grow in value.

The present research seeks to develop an integrated software environmentwhich supportsCSDT. This system will accept data, process and control requirements and will generate aset of matrices useful for checking completeness, consistency, parallelism and reachabilityof the requirements. These matrices will then be used to recommend grouping of transformsinto tasks. In the past, this approach was shown to be effective in recommending designfor sequential systems[36]. Further research is needed in order to develop the guidelinesnecessary for the system to be useful in a concurrent software design effort.

ACKNOWLEDGEMENT

I should like to thank Philip D. Hollis, of Contemporary Solution Inc., for his assistancewith this article.

REFERENCES

1. P. Aiken, A. Muntz and R. Richards, ‘DOD legacy systems: reverse engineering data require-ments’, Commun. ACM, 37(5), 26–41 (1994).

2. J. C. Brancheau, B. D. Janz and J. C. Wetherbe, ‘Key issues in information systems management:1994-95 SIM Delphi Results’, MIS Q., 20(2), 225–240 (1996).

3. D. T. Dewire, Client/Server Computing, McGraw Hill Productivity Series, 1993.4. C. B. Darling, ‘The twists and turns of client/server migration’, Datamation, (September 1996),

pp. 121-129.5. E. Kay, ‘Surprise: Your client is sinking your server’, Datamation, (February 1, 1995) 51–53

(1995).6. E. Yourdon, Modern Structured Analysis, Prentice Hall, Englewood Cliffs, NJ, 1989.7. B. Gold-Bernstein and D. Marca, Designing Enterprise Client/Server Systems, Prentice Hall

PTR, 1998.8. R. Orfali, D. Harkey and J. Edwards, The Essential Client/Server Survival Guide, 2nd edn,

Wiley, 1996.9. R. Bell, ‘Choosing tools for analysis and design’, IEEE Software, 11(3), 121–125 (1994).

10. M. Page-Jones, The Practical Guide to Structured Systems Design, Yourdon Press ComputingSeries, 2nd edn, 1988.

11. X. Song and L. J. Osterweil, ‘Toward objective, systematic design method comparisons’, IEEESoftware, 9(3) 43–53 (1992).

12. P. T. Ward, ‘How to integrate object-orientation with structured analysis and design’, IEEESoftware, 6(2), 74–82 (1989).


42 J. KARIMI

13. E. Yourdon and L. L. Constantine, Structured Design: Fundamentals of a Discipline of aComputer Program and Systems Design, Prentice Hall, Englewood Cliffs, NJ, 1979.

14. J. C. Kelly, ‘A comparison of four design methods for real-time systems’, Proceedings of NinthInternational Conference on Software Engineering, March 1987, pp. 238–252.

15. H. D. Hatley and I. A. Pirbhai, Strategies for Real-Time System Specification, Dorset HousePublishing, New York, NY, 1987.

16. J. Huang, ‘Modeling of software partition for distributed real-time applications’, IEEE Trans.Softw. Eng., SE-11(10), 1113–1126 (1985).

17. B. Sanden, ‘Entity-life modeling and structured analysis in real-time software design – a com-parison’, Commun. ACM, 32(12), (1989) 1458–1466.

18. J. L. Peterson, Petri Net Theory and the Modeling of Systems, Prentice-Hall, Englewood Cliffs,NJ, 1981.

19. Luqi and J. A. Goguen, ‘Formal methods: promises and problems’, IEEE Software, 14(1), 73–85(1997).

20. T. DeMarco, Structured Analysis and Systems Specification, Prentice Hall, Englewood Cliffs,NJ, 1979.

21. G. Booch, Software Engineering with Ada, Benjamin/Cummings, Menlo Park, CA, 1983.22. N. Nielsen and K. Shumate, Designing Large Real-Time Systems with ADA, McGraw-Hill, New

York, NY, 1988.23. R. M. Adler, ‘Distributed coordination models for client/server computing’, IEEE Computer,

28(4), 14–22, (1995).24. J. Gray and A. Reuter, Transaction Processing Concepts and Techniques, Morgan-Kaufmann,

1993.25. J. A. Stankovic, ‘Misconceptions about real-time computing: a serious problem for next-

generation systems’, Computer, 21(10), 10–19 (1988).26. P. Duchessi and I. Chengalur-Smith, ‘Client/server benefits, problems, best practices’, Commun.

ACM, 41(5), 87–94 (1998).27. J. C. McCarthy and W. M. Bluestein, ‘Is client–server cheaper?’, Forrester Research Inc.,

Cambridge, MA, (August 1990).28. A. Sinha, ‘Client-server computing’, Commun. ACM, 35(7), 77–98 (1992).29. P. T. Ward and S. J. Mellor, Structured Development for Real-Time Systems, Yourdon Press

Computing Series, Prentice Hall, Vols. I, II and III, 1985.30. S. Shlaer and S. J. Mellor, ‘Recursive design of an application-independent architecture’, IEEE

Software, 14(1), (1997) 61–72.31. G. Booch, Object Oriented Design with Applications, Benjamin/Cummings, Menlo Park, CA,

1995.32. G. Booch, J. Rumbaugh and I. Jacobson, Unified Modeling Language User Guide, Addison-

Wesley Object Technology Series, 1998.33. I. Jacobson, Object-Oriented Software Engineering: A Use Case Driven Approach, Addison-

Wesley, 1994.34. H. Gomma, ‘A software design method for real-time systems’, Commun. ACM, 27(9), 938–949

(1984).35. H. Gomma, ‘Structuring criteria for real-time system design’, Proceedings of the 11th Interna-

tional Conference on Software Engineering, ACM SIGSOFT, New York, May 1987, pp. 290–301.

36. J. Karimi and B. R. Konsynski, ‘An automated software design assistant’, IEEE Trans. Softw.Eng., SE-14(2), 194–210 (1988).

37. J. Rumbaugh, OMT Insights, SIGS Books, 1996.38. B. Sanden, Concurrent Tasks in Real-Time Software Design, Tech. Rep. 88-03, George Mason

Univ., Fairfax, VA, 1988.


A software design technique for client--server applications

Documents

Transcript of A software design technique for client--server applications