SYSTEMS DESIGN THROUGH THE USER INTERFACE. Jim Underwood School of Computing Sciences University of Technology, Sydney

Transcription

1 Jim Underwood School of Computing Sciences University of Technology, Sydney First Annual Conference on Information Systems Monash University, Melbourne, Australia, 6th February 1990 ABSTRACT This paper proposes a system design methodology which centres on the user interface. Compared to traditional structured methodologies the role of Data Flow Diagrams is reduced and Program Structure Charts are to some extent replaced by Panel Flow Diagrams (a type of state-transition diagram). This methodology is particularly suited to interactive and transaction processing systems. It can be used with both linear life cycle and evolutionary approaches. INTRODUCTION Early business systems design took available computing machinery and fitted it into existing information systems. As capabilities expanded the computing system came to imitate the previous bureaucratic system with humans working as intelligent peripherals. By the mid sixties it was apparent that this approach was very limiting and that methodologies were required which encouraged the design of completely new information systems. Typical of these methodologies was ADS (Avison, 1988:p.43) which stressed the merits of output driven design. Given the batch techniques used at the time ADS could be said to be a methodology based on the user interface; the users in this case were those reading the computer produced reports. Interest in the physical user interface waned in the seventies. Data base design became the issue and methods were devised to make data structures more stable, more efficient in storage and access, and more easily discussed with the users. Some techniques, such as the synthesis of relations from functional dependencies, tended to take the existing user interface as the starting point of data analysis. The second strand of the seventies was the development of structured analysis and design (Avison, 1988:pp ). This was motivated by the noble desire to reduce the size and complexity of system specifications and the less noble desire to restrict system designs to a form which could be easily translated into well structured programs (another case of making the problem fit the solution). Structured analysis takes as its starting point the data flows in the existing system. New data flows are devised and the computer system more or less ensures that these are followed by the humans. 1

2 The advent of PCs and advances in communications technology led to several complementary trends in system design. The scope of computer application in information systems increased dramatically, encouraging the complete redesign of many systems. Increasing flexibility of software made prototyping an attractive approach for analysts and designers. The technical abilities of PCs as work stations made good interface design a real possibility. And for the first time the majority of information workers became directly involved with the person-computer interface. Quite recently there has been a renewed interest in user interface design but much of this has focussed on the design of individual screens or on the ergonomics of atomic user actions such as pointing or keying. This is because program structure is usually designed first and user interaction is added whenever the program needs to consume some input or excrete some output. The user is still seen as a peripheral. The approach taken here uses the user interface design to determine external program structure. To understand this approach it is important to consider two views of the user interface. Certainly the interface is a channel through which passes not only data but also the designer's model of the enterprise and the user. The neglected view of the interface is that it is also a boundary. On one side of this boundary is the human aspect of the information system, which is just a part of the business organisation. On the other side is the computer. In classical information system design these two sides are horribly intertwined. Shneiderman (1987:pp ) points out the danger of anthropomorphism, of trying to design computer systems which behave like humans. There is equal danger in trying to design social systems which behave like computers. The design of the user-computer interface includes the negotiation of the boundary between the human system and the computer system. CLASSICAL STRUCTURED DESIGN Structured analysis and design usually begins with a data flow diagram. A typical logical DFD for a simplified system is shown in figure 1. Such a DFD has a general direction of flow from one external entity to another or a circular flow back to the original external entity. In this case we have a shorter and a longer circular flow both from customer back to customer. The longer flow is delayed until the appropriate input is d from the supplier. Files are put in more or less arbitrarily if there is no existing system. In this case the STOCK file is a permanent data store while the BACKORDER file is essentially a buffer. The exact format of computer files in a new system will be determined in a subsequent data analysis phase (see for example Gane & Sarson, 1977). This approach to design produces systems fitting J.D. Thompson's model of "long-linked" technology (quoted in Robbins, 1983:p.131), essentially the technology of mass production. Early in the design stage we decide which tasks will be automated and thus define the user machine interface. Eventually we end up with a number of isolated screens which must be gathered together into a user dialogue. 2

3 orders unfillable orders customer order record backorders fillable orders STOCK FILE BACKORDER FILE prepare details for fillable backorders goods supplier delivery FIGURE 1 - Traditional Data Flow Diagram To begin program design we must convert the linear flow of the DFD into an hierarchical structure. Common techniques used are transaction analysis which divides the programs according to the different possible inputs (a possible result is shown in figure 2), or transform analysis which attempts to find a central process to which the others may be subordinated. If we are contemplating a batch system we may implement the top level DFD as a linear flow through a sequence of separate programs and derive individual program structures from the file structures using the Jackson method (King, 1988). order processing customer order goods prepare * prepare * FIGURE 2 - Structure Chart 3

4 A REDUCED ROLE FOR THE DFD When we consider existing systems which already include a computer component, or new interactive or transaction processing systems, DFDs change their shape considerably. Figure 3 shows an alternative DFD for our sample system. All non-file data flows have been combined with BACKORDERs to create the ORDERs file. The process "record backorders" has disappeared. Since all orders are now buffered it is not necessary to consider backorders separately. "Prepare for " will simply fill those orders for which there is sufficient stock. orders customer order goods ORDERS FILE STOCK FILE supplier delivery details prepare for FIGURE 3 - Data Flow Diagram for Interactive System The striking thing about this data flow diagram is that there is no flow. There is not much data either. The typical confusion of arrows, where every process accesses every file, can be cleared up by having one big file called DATA BASE. The structure of this will be derived from data analysis. The only thing left is to draw the person-machine boundary, which in most cases will pass neatly through every bubble. In the current example we may (if our notation is sufficiently exact) wish to indicate that the process "prepare for " is completely automatic. The problem with data flows which don't flow is that nothing may ever happen. The real question is what triggers each process and DFDs deliberately avoid showing triggers. The information system designer needs to decide which processes are triggered by external inputs (e.g. a phone call or EDI message from a customer), which are triggered within the computer system (by a clock or a demon) and which are the responsibility of the human information processors. These decisions are best represented by a decision table or a simple list. If the intuition of the users is not trusted they may need to make up a set of procedures to direct their tasks. These procedures could easily be described with a "real" DFD. Using Thompson's model we can see that we are now dealing with a completely different style of information system. Depending on whether the users are processing simple 4

5 transactions or whether they are working together to produce a complex final product we have either "mediating" or "intensive" technology (Robbins, 1983:p.131). INDEPENDENT E-R MODELLING In many cases a new information system development will be supplying new functions operating on an existing data base. For large projects a new corporate data model may need to be created. In either case the data model is the first output of the system development process. Figure 4 is an E-R model of the sample system. In a complex system the data model will be the result of detailed analysis and difficult negotiation. The technical aspects of data modelling are well understood. ORDER 1 IS FOR N STOCK ITEM FIGURE 4 - Entity-Relationship Diagram If we were to draw a DFD such as that in figure 3 each process could be seen as performing a meaningful transformation on the data base. In the next section I propose a dialogue based method for describing these transformations. A classic DFD such as figure 1 contains information about the sequence of processes which must be performed. In the new approach this information is distributed; some of it may show how atomic functions are grouped into valid transactions. As far as possible the E-R model should now contain this information about data base integrity. PANEL FLOW DIAGRAMS The critical step in designing through the user interface is the creation of the dialogue structure. This usually follows the development of an E-R diagram although in some simple systems the data model could be derived from the dialogue. The dialogue must be constructed with or by the users, perhaps with the aid of a written narrative or a DFD of the proposed manual system. The dialogue can be represented with what I will call a Panel Flow Diagram (PFD). These are usually called State Transition Diagrams; the alternative name was suggested by David Moloney (1989) to avoid confusion with other uses of S-T diagrams. (Panels can be screens or windows.) A PFD for our system is shown in figure 5. 5

6 Accompanying the diagram will be a description of the business rules which need to be implemented for each panel. MAIN MENU RECEIVE ORDER RECEIVE GOODS DISPATCH GOODS FIGURE 5 - Panel Flow Diagram PFDs do not yet have a rigorous syntax. Problems arise when we wish to show the possibility of a subroutine-like excursion in a dialogue or when the path taken depends on some internal condition such as the result of a file access. The latter problem can solved by attaching labels to the arcs of the diagram and listing the meanings of these labels. A PFD does is not a particularly user friendly way of describing a dialogue. A better approach in the long run would be to extend the dialogue scripting functions in some CASE tools so that dialogues can be developed interactively. A PFD could be produced automatically for use as part of a program specification. Nielsen (1989) has experimented with using hypertext software to describe dialogues. You may have noticed that the PFD looks quite like a program structure chart and it can certainly be used by programmers for this purpose. The important difference is in the method of its construction. When designing a dialogue our foremost consideration is the needs of the users. Dialogues may be structured around different business objects, areas of geographical interest, user roles or time phases. The dialogue should reflect the conceptual framework of the users as they go about solving their problems (Dumas, 1988:p.78). When using dialogue based design the program will usually follow the same structure. TECHNIQUES FOR CONSTRUCTING PROGRAMS The dialogue based approached was used with a group of second year students at the University of Technology, Sydney. They were given an E-R diagram and a brief system narrative. As their first exercise they were asked to design a dialogue structure and screen formats, a project which they completed with reasonable success. After some discussion the E-R diagram was converted into a set of VSAM files and for the second exercise the students were asked to program the system in CICS. At this stage they came upon a mental block. Being well trained (and working in groups) they felt a need to produce a program design. Even after being allocated particular screens to "program" and producing and testing a 6

7 working system they still felt very uneasy as to where the "program" was. This was their first experience of using a transaction processing system. In a transaction processing system such as CICS there is no main application program, just a series of transactions which may or may not call each other. In this case we restricted our programming to psuedo-conversational mode, which meant that each transaction simply took one step in the dialogue. The internal program structure (CICS) had no connection with the user's problem structure. The only thing which held the application "program" together was the panel structure diagram. This became obvious as the PFD was always the first point of reference when design questions arose during programming. A similar situation would apply if the system were implemented in a Macintosh or Windows environment. The individual windows define the boundary between our user based system design (the PFD) and the computer. CONCLUSION System design through the user interface has two basic steps: design the data model and design the dialogue structure. Data flow diagrams are used only incidentally if at all. The logic which is distributed through the various panels is simple enough to express directly in psuedocode or decision tables. The primary advantage of this approach is that the system design directly reflects the user's needs when interacting with the computer. Modern interactive software environments allow direct (manual) translation from the dialogue structure to a fully functional system. The approach is neutral to the overall system development strategy. It is equally suited to a linear life cycle or to prototyping. ACKNOWLEDGEMENTS I wish to thank Kevin Cox, Dave Walker and Penny Collings, all of the University of Canberra, who taught me all I know about user based computer system deign. I have just tried to make more sense of it all. REFERENCES Avison, D.E. & G. Fitzgerald (1988) Information Systems Development Blackwell, Oxford. Dumas, Joseph S. (1988) Designing User Interfaces for Software Prentice-Hall, Englewood Cliffs. Gane, Chris & Trish Sarson (1977) Structured Systems Analysis IST, New York. King, David (1988) Creating Effective Software Yourdon, Englewood Cliffs. Moloney, David (1989) Guidelines for the Development of Information/Family User Interfaces University of Technology, Sydney (technical report in publication). 7

8 Nielsen, Jakob (1989) "Prototyping User Interfaces Using an Object-Oriented Hypertext System" Proc. NORDATA'89 Joint Scandanavian Computer Conference Copenhagen, June. Robbins, Stephen P. (1983) Organization Theory Prentice-Hall, Englewood Cliffs. Shneiderman, Ben (1987) Designing the User Interface Addison-Wesley, Reading, Mass. 8