A method of design for adaptable/modular user interfaces

AA00001827_00001.pdf

PAGE 1

A METHOD OF DESIGN FOR ADAPTABLE/MODULAR USER INTERFACES by Lyle Richard Tyler University of Colorado, 1990 A thesis submitted to the of the Graduate School of the Univer9ity of Colorado at Denver in partial fulfillment of requirements for the degree of Master of Science Electrical Engineering 1992 '.

PAGE 2

This thesis for the Master of Science degree by Lyle Richard Tyler has been approved for the Department of Electrical Engineering by Gita Alaghband Marvin Anderson \\I 25/ qz_ Date

PAGE 3

Tyler, LyleRichard (M.S., Electrical Engineering) A Method :ofi Design for Adaptable/Modular User Interfaces Thesis di:rected by Professor Gita Alaghband I ABSTRACT As computer systems become more complex the user intetfaces have beCome equally complex to use the advanced capabilities of the new computers. The devel'opment of these new user interfaces consumes a considerable amount of time and money. One solution to the problem of the cost and time invovled in software development is to develop am6dular user interface. A modular user interface has the advantage of being adaptable to the user of the software application. The modular user interface also has the advantage of being reusable 1or different software applications. This I reusability limits the need to develop a new user interface: for every new software application. By combining the message passing technique of the object driented approach with the ease of use of the structured data analysis approach, a new method i i i

PAGE 4

! for develop:ing a modular user interfaces can be created.:. q, this new method, called the modified ; method, the: message passing technique is restricted to four message types. This restriction increases the process independance by reducing the :1 ; combi nat 1'oni of messages between processes. The modified ;method also allows the software .engineer to : i develop program with the more popular and 1l,. : widely u$ed1 computer that are currently in use. o The method is one possible solution to f. the the high cost of software however, further research and is needed to create a standardized for developing modular user interfaces. This accurately represents the content of the thesis. I recommend its Gita Alaghband iv

PAGE 5

This thesis is dedicated to my parents for all their support and:patience while I reached for my dreams.

PAGE 6

CONTENTS CHAPTER 1 I NTRODVCTION ................................ 1 What Is a User Interface? 2 I Early Years of User Interfaces 3 The. User and the User Interface 6 Modular Programming 8 s .......................... 9 summary . . . . . . . . 1 0 2. USER' INTERFACE SPECIFICATION REQUIREMENTS 13 RequirementsAnalysis 14 Analysis of User Needs 15 Types of Users and User Needs 16 Functional Requirements Analysis 17 Basic User Interface Functions 18 Desigri Objectives Analysis 20 Ad apt ab i 1 i 1 t y ... ........... 21 MOdularity ............. .................... 22 ConClusions .................................. 23 3. PRELIMINARY DESIGNS 24 of Software Design 25 The Structured Data Analysis Approach 25 The :object Oriented Approach 29 vi

PAGE 7

the:Modified Method ..................... 33 Using: the Modified Method .................... 35 Data Control Diagrams ........... 35 Transformation Bubbles .......... 43 Summar.y ...... ..... 45 4. FINAL SPECIFICATIONS ................ 46 Procedure Chart Design ...................... 46 .. .......... ; ............ 48 Sitep 1: Review ......................... 48 Step 2: Analysis ....................... 48 siep 3: First Level Factoring .............. 49 Step 4: Second Level Factoring ........... 52 5: Refinements ....................... 55 co:hes ion ................................. 56 Co.upl i ng ............................. 57 Cod .i.ng: .......................... 58 2 Pseudocode ............. ....... .. 59 t a D i ct ion a r y 61 Summa r;y 6 3 5. ENHANCEMENTS ................... ....... 64 the User Interface ............... 65 SteR 1: Interface Matching ................. 65 Step 2: Development and Testing ............ 68 vii

PAGE 8

Step 3: Recompiling ....................... 72 summary ................................. 13 6 ONS .................. 7 5 APPENDIX A. of the AMUI ......................... 79 B. Data Control Diagrams of the AMUI ............ ao C. Level 1 Pseudocode of the AMUI ............... 87 D. Procedure Charts of the AMUI ................ 90 '' E. Proiess Descriptions of the AMUI ......... 96 F. Level 2 Pseudocode of the AMUI .............. 102 G. Data Dictionary of the AMUI. ................ 113 I H. Interface Matrix of the AMUI ................ 118 I. ANSI C Code of the AMUI ................... 121 GLOSSARY .......... -........ 1 38 BIBLIOGRAPHY .............. II I 14Q viii

PAGE 9

FIGURES Figure 1 .1. Command and Query Interface Example ............ 4 1.2. Simple :Menu Interface ...................... .4 1 .3. Graphi6al User Interface ... 2.1. Software Description of the AMUI. ............. 19 3.1. Data Flow Diagram Notation .................. 26 3.2. General Form of Data Flow Diagram ............. 27 3.3. Refinement ................... 3.4. Attribute Inheritance by Objects .............. 30 3.5. Operation Inheritance by Objects ............ 31 3.6. Level 0 Data Control Diagram of the AMUI .... 36 3.7. Level 1 Data Control Diagram of the AMUI ...... 38 3.8. Level 2 Data Control Diagram of the AMUI ...... 41 3.9. Full Level 1 Data Control -Diagram of the AMUI .. ................................. 42 3.10.Level 1 Pseudocode of Input Processor ........ 43 4.1. of Information Flow es ....................... .......... 50 4.2. First Procedure Chart Mapping .......... 51 4.3. First Level Factoring of Function Data Control Diagram .................. 53 4.4. Second 'Level Factoring of Procedure Charts ... 54 4. 5 .. Cohes i o.n Spectrum ............................. 56 4.6. Spectrum ............................. 57 ix

PAGE 10

4.7. Level 2 Pseudocode of Function Processor ...... 60 I 4.8. Data Format ........................ 61 4.9. Data Dictionary Description Notation .......... 61 4.10.Data Dictionary of Funct;on Processor ....... 62 5.1. General Form of Interface Matr;x .............. 66 5.2. Matrix for the AMUI ............... 67 i 5.3. Prodess Description and Pseudocode of Input Processor for the AMUI ..... 69 5.4. Process Description and Pseudocode of Newmac Command for the AMUI .................. 71 X

PAGE 11

TABLES Tables 1 .1. Everyday Forms of User Interfaces ............. 2 1.2. Advantages of Graphical Interfaces ....... 5 1.3. Categories of Computer Users ................ 7 2.1. Functional Requirements of the AMUI ..... 20 2.2. Design Objectives of the AMUI .............. 23 3.1. Categories of Information ................. 32 3.2. Specification Requirements of the AMUI ........ 39 xi

PAGE 12

CHAPTER 1 INTRODUCTION As computer systems become more complex the user int$rfaces have become equally complex to use the capabilities of the new computers. The of these new user interfaces consumes .:a considerable amount of time and money. To reduce the cost and time involved in the development of the new user interfaces a new method of softwre design must be A new method for designing an adaptable and modular user interface is developed and presented in this paper. This new method, called the modified method, provides the software engineer with the ability to produce more modular user interfaces than other known.methods. An example implementation of the modified method in developing a user interface for the UNIX operating system is used to aid in the understanding of the design method. Before a user interface can be designed an of what a user interface is and what a 1

PAGE 13

user interface does must first be gained. In this chapter, we: discuss the purpose of the user interface and how it manages the dialogue between the user and the computer. What Is a User Interface? A user! interface is a device that assists the user in operating a machine. User interfaces exist in many different forms and for many different applications. Many of the user interfaces that people use in every day life are listed in Table 1.1. TABLE 1.1 EVERYDAY FORMS OF USER INTERFACES 1. Automobile instrument panel. 2. Calculator keyboard and display panel. 3. Control panel for automated assembly plant. 4. switch. 5. Microwave oven control panel. 6. Telephone keypad. 7. TV and;VcR remote control devices. The user interface is used as an interpreter between the'user and the machine. In the operation of a computer system the way that people convey information: is different from the way that computers convey information. Information from the computer is displayed by the user interface in a manner that can be easily read by the user. While input from 2

PAGE 14

the user transformed by the user interface into a f6rm that the computer can handle. I As computer systems have become more advanced the types ot interaction styles has grown. At first i the interaction style was a simple command line I interface, a graphical interaction style is used. Even: with the creation of graphical user interfaces many of today's computer systems still use the obsolete interaction techniques of 20 years ago. [ 1] Years of User Interfaces Today ?omputers are used in a broad number of different applications by different people each day. These range from word processing and ; data base to computer programming. In I each application it is the user interface that allows the user to instruct the computer to take the action desired. The user interface is also I responsiblejto display the information in a format. In the!early days of computing, user interfaces i were based on a command and query interface. The input to the computer was mainly textual commands 3

PAGE 15

and the computer would respond in preprogrammed An example of such a interface is shown in Figure 1,. 1 These forms of i nt erf aces were hard to learn and provided the user with little information. [1) FIGURE 1.1 COMMAND AND QUERY INTERFACE EXAMPLE >comp{l e: program1. c -o program. exe COMPILATION LINE 23 MISSING IN LINE ABOVE By a simple menu to the command and query an improvement to the interaction was made. this type of interface a list of selections is displayed that the user can choose from. An of a menu interface is shown in Figure 1 This interface provides more informatfon;to the user but can be tedious in that several levels of menus can exist. The user may have to make several selections before the required command fs displayed.[1) As computers become more advanced and hardware FIGURE 1 SIMPLE MENU INTERFACE 1 D I R,ECTORY 2. DISPLAY TEXT FILE 3 RUN PROGRAM 4. OTH.ER oPTIONS 5. EXIT ENTER SELECTION: 4

PAGE 16

more complex, improvements in output display and input are made. The output displays of today have higher resolution and are capable of displayihg more colors then the earlier designs. The input devices of now include the lightpen, and voice command interaction in addition to the keyboard. To take advantage of the new hardware the user interface now uses the graphical style of interaction. In the graphical user a user selects a function displayed I on the by a mouse or other pointing device. This form of interface provides several advantages that are 1ited in Table 1.2.[1] An example of a graphical user interface is shown in Figure 1.3. TABLE 1 ADVANTAGES OF GRAPHICAL INTERFACES 1. Display of different forms of information s i miJ 1t aneous 1 y. 2. Pull down menus allow the user to select from different tasks. 3. Int,eraction efficiency is increased by the ability to display graphical icons. these user interfaces is based on how is displayed and how user interaction with the tomputer is handled; however, not all user interface work for all users. There are different 5

PAGE 17

FIGURE 1.3 USER INTERFACE FOe Edit Run Compile <11dio.h>: tnai"O ,. program converts Fllhrenl'teit degrees 10 Celsiua de;reea */ float fahr,cel; int battom,1tlp;inc111ment; Help on Help Options Contenta ndex opio S.arcl't Shift-F1 Ctr1-F1 increment = 1 0: fahrl:=l::lottom; printi("F llhl1innelt -: Cel1iu1 while (tlhr < = 1tlp) Help il a aenaltiVe utility 1hllt aDCMI 1h1 uaer to aeeroh by key word or by a epiC&: function. i eel = (S.cvQO)*(PIIhr-32) pnn1f r"!E.S!fi,::a 1t\n',ta fllhr=fahr -t:inc111ment; Help wane by typing in 1h1 ward or function you wich to find and then pre - for e keyword search or return for a full of 1he function. types of users and each user has different needs-and skill A knowledge of the types of users that use dbmputers will give an understanding of the complexities involved in user interface design. The User and the User Interface There are many different users each of which have diffetent skill levels and experience in dealing with :computers. The users of computer systems ommonly broken down into three categories listed in Table 1.3.[2] Each type of user requires the user interface 6

PAGE 18

TABLE 1.3 CATEGORIES OF COMPUTER USERS NOVICE: Users that have no knowledge of linguistic conventions that the operator must know to communicate with an interactive system. INTERMEDIATE: Users that have good knowledge of t;ask domain of the computer system but trouble remembering linguistic conventions. EXPERT: Users that have good knowledge both of the task domain of the computer system and of the linguistic conventions. to have different abilities. The novice user requires 'the user interface to be easy to learn and easy to use. The expert user requires the user interface to be quick and efficient on executing commands. The intermediate user requires a balance between t;he requirements of the novice user and the expert A review of software engineering and the specific user requirements for a modular user interface are discussed in Chapter 2. The classification of a user applies to the user of a single system only. For example, the expert uiermay be a novice user on another system and a novice user may be an intermediate user on another system. To accommodate the needs of each user on a system, the user interface must be adaptable to the user. This requires that the user 7

PAGE 19

be programmed in a modular fashion. A modular user interface has the advantage of being adaptable to the users needs. This limits the need of developing .a new user interface for each user. Modular Programming The cost of developing software systems has become increasingly high over several years. The reason for the high cost of software system development is that software engineering is centered on custom software.[3] A solution to this cost is to modular programs. Modular programs can be used in several different applications with little or no modifications. If the user interface is assembled from components then, the components of the user interface can be changed to match the new application. A large part of the expense to develop new software packages lies in the design of the user interface .. BY using an existing user interface the development cost is reduced. If the user interface is in a modular fashion then, with a

PAGE 20

modification the user interface can be added to the developing software package. To develop a modular user interface a software development method must be followed. A review of two such software development methods is presented in Chapter 3. These two software development methods are difficult to use in the development of modular interfaces. A solution is to combine the two methods into a new method called the modified method. The new software development method, the modified method, is presented in Chapters 3 and 4. Enhancements Enhancement of software systems is a major concern of many software engineers today. Modification of a currently existing custom software system can cause the failure of the system, howexer; in modular programs modifications can be made with fewer risks. In a modular program each procedure is independent of the others. This independence allows for the easy modification or changing of a procedure without effecting other procedures. In a custom 9

PAGE 21

software system the modification of a procedure can cause a failure because, the procedures are dependant upon one another. With the user interface as the primary device for controlling a computer system, modification to the system requires a modification to the user interface. A modular user interface can be modified with little development time and at a lower cost. The enhancements of a modular user interface using the method developed in this paper are described in Chapter 5. Summary The development of user interfaces has become increasingly important over the past 20 years. The user interface is seen as the most important part of a program. It is the user interface that helps the user control the computer and interpret the information from computer. When computers were first introduced the main users were computer programmers, therefore; the concern for a comfortable user interface did not exist. With the introduction of the personal computer and the increase in the number of users, 10

PAGE 22

the need,td produce a comfortable user interface began to arise. Today .computers are used in every aspect of life, from computer programming to balancing a checkbook. The type of computer user varies from the user to the expert user with each type of user different computing needs. The of a user interface to fit the needs of each user has become increasingly important as have become more advanced. To improve the development of the user interface and to increase the ability to adapt the user interface to the changing computer world a method to create a modular user interface was introduced. The ability to develop modular user interfaces decrease the cost and time of developing new user interfaces. By using an existing user interface from one software system and adding it to another, the development time is reduced. Enhancements to a modular uet interface can be made cheaper than enhancement$ to a custom made user interface. Today there are several methods for developing modular programs; however, no one method is better 11

PAGE 23

than another. The research into methods of modular programming will continue and until a standard is developed the high cost of software engineering will continue to rise. 12

PAGE 24

CHAPTER 2 SPECIFICATION REQUIREMENTS Ther:-e are many different users of computer systems, :ea'ch of whom has different skill levels and experienqe :in dealing with computers. The users of are commonly broken .down into the three Of novice, intermediate, and expert. Each of a computer system needs the user interface tb have different capabilities. The novice requires the user interface to be. easy I to 1 earn easy to use. The expert user requires the user interface to be quick and efficient in executing The intermediate user requires the user interface to have a balance of capabilities between the: requirements of the novice user and the requirements of the Thepr9cedure to determine how to meet the need of the uier: is called the specification requirements. The specification requirements are separated into the requirements analysis and the design obje9tives analysis. The requirements 13

PAGE 25

analysis fqcuses on what the user interface does while the design objectives analysis focuses on how the user interface is designed. A review of and the specification requirements of a modular user interface are discussed in this chapter. Th& specification requirements of a modular user are different from those of a customed'designed user interface. This difference requiresa method of software engineering to be designed that will ensure the correct modeling of the modu}ar' user interface. The development of this method is presented in Chapters 3 and 4. Requirements Analysis The analysis is used to specify the func,ions and performance of the user interface. The analysis is based on an analysis of the needs. of the user, and an analysis of the basic functional processes of a user interface. Without a requirements analysis even the most well designed user can be a failure for the user and the 14

PAGE 26

The i n:format ion from the requirements ana 1 ys is will be qompined to create a model of the user interface. The requirements analysis is divided into the .analysis of the user needs and the functionl requirements analysis. Each analysis is used to gain an understanding of what the user interface is to be and how it is to function. User Needs With the user being the final judge of the effectiveness of the user interface the understanding of the needs of the user becomes more important. For the software engineer to design a user interface that will assist the user in the use of the computer, the software engineer must first understand the user. For many user interfaces the types of users cannot be determined at the time of design. For example in the UNIX operating system the number of users can be extremely large; therefore, the determination of the types of users is extremely complex. The solution to the problem is to study each of the 'three types of users and attempt to determine the needs of each user. 15

PAGE 27

In this phase of the design emphasis is placed on determining the needs of the users only. The design objectives analysis will attempt to find a way to meet the needs of each user. Types of users and user needs. The novice user requires a user interface that is easy to use and easy to learn. A novice user must learn the system commands.and how to navigate through the system. This that the system commands be easy to remember and learn. The display of information must be easy to read and easy to understand. The expert user requires the user interface to have commands that are easy to obtain and efficient. An expert uer is already proficient in the use of the system, therefore; the expert user needs commands that can increase productivity. The display of information must be concise and efficient. The intermediate user needs a balance between the requirements of the expert user and the novice user. An intermediate user needs commands that are easy to use and commands that can increase productivity. The display of information must be 16

PAGE 28

balanced efficiency and readability. Functional Analysis The functional requirements analysis is a procedure the software uses to separate functionality from implementation. The functionality is the user interface commands while the is the realization of the commands. It is not possible to determine all the commands that a user may require for a user interface at the time of design. One solution to this is to separate the commands of a user interface into different categories and attempt to develop commands from them. The ability to add commands after the' user interface is designed is discussed in the design objectives analysis. In this phase of the design emphasis is placed on determining the what the user interface will do. The design objectives analysis will determine how the functions and design of the user interface are to be It also determines how to meet the needs of the user. 17

PAGE 29

Basic user interface functions. The basic functions of a user interface can be divided into five categories: communication, macro commands, undo-redo commands, on line help, and default values.[4] The communication functions provide the basic form and method of how the user and the computer interact .. These functions control how interaction with the user is done. The macro command functions are commands that are composed of different existing commands. These types of commands increase the proficiency of the user when uing the user interface. The undo-redo command functions are commands that allow the user to recover from errors or slip ups. Thesetypes of commands protect the user from damaging commands and mistakes. The online help functions the user with information on the system and commands. This function is useful as reminder when the user has forgotten a command or as a simple teaching tool. The default value functions assist the user by reducing :the number of time the user must specify a 18

PAGE 30

value. functions allow the user to personalize the user interface. Using these categories the software engineer can define the commands of the user interface from the software description. The software description is an explanation of the purpose of the user interface and a definition of the type of functions that the user is to perform. This software description is written in english and is generally' abroad definition of the user interface. For example, the software description for an adaptable modular user interface for the UNIX operating system, called the AMUI, is given in Figure 2.1. By using the above categories a group of commands .can be developed for the AMUI. These FIGURE 2.1 SOFTWARE DESCRIPTION OF THE AMUI A user. interface is t6. be designed will allow users of different skill levels and experience to use the.UNIX operating system with an equal effectiveness. This requires that the user interface be able to mimic other operating systems. The user interface must also be able to be used on different versions of the UNIX o.s. as well as different machines. The input/output display must be adaptable and changeable to suit the needs af the user. The addition of new commands must be easy and quick to reduce the cost of redesigning the 19

PAGE 31

commands are determined by using the above to analyse the software description shown in Figure The commands developed from the analysis of the software description for each category shown in Table 2.1. TABLE 2.1 FUNCTIONAL REQUIREMENTS OF THE AMUI Communication functions 1. Ability to mimic other operating systems. 2. Execution of new commands not found on the UNIX o.s. 3 .. Execution of standard UNIX system commands. Macro functions 1. Command that execute many commands. Undo-Redo functions 1. History of last ten commands entered. Help functions 1. Context sensitive help. Design Objectives Analysis The design objectives analysis is used to determine how the functions of the user interfa6e I areto be implemented. The software engineer uses the design objectives analysis to match the function requirements to the needs of the user. Most of the needs of the user are accomplished by how the functions work. Other needs can be met by how the user interface is designed. 20

PAGE 32

The design objectives analysis of a modular user interface is divided into the areas of adaptability and modularity. Adaptability concentrates on the ability of the user to change to the needs of the user and the changes of the capabilities of the system. Modularity on how the user interface can be changed to meet the requirements of adaptability. Adaptability To the needs of each of the three types of users the user interface must be able to be configured to meet the needs of the individual user. Some: of the needs of each user can be met by the command functions of macro commands and default values commands. The macro commands function can meet each type of users need for different styles of .commands. The ; ability to 9reate macro commands can meet the need of the efficiency for the expert user, while regular commands can meet the need of ease of use for the novice user; 21

PAGE 33

Modularity With the rising cost of developing new software packages the need to be able to assemble new software packages from existing components increasingly important. The need for each type of user needing different amounts and styles of information can be accommodated for by designing the input/output of the user interface to be modular. With a modular input/output the user interface can be changed from an input and output interaction format for a novice user to one for an expert user. For example, a novice user may require the need for an in'teractive input that uses the mouse while the expert user needs an interactive input that uses a pen light. The two types of interaction must be able to function in a reasonable amount of response time. Since not all the needs of the user can be anticipated at the time of the design, there must exist the ability to create new commands. The addition of new commands means that functional processing must also be modular in design. 22

PAGE 34

By analyzing the software description shown in Figure 2.,1 the modularity design objectives are shown in Table 2.2. These design objectives focus primarily upon how the user interface is to be designed .. TABLE 2.2 DESIGN OBJECTIVES OF THE AMUI 1. Operating system independent. 2. Device independent. 3. Easy. change of input/output displays 4. Easy addition of new commands. Conclusions The requirements is an iterative process. The model of the user interface can never be final because the software engineer can never know all the needs of the user or all the commands that are required. the specification requirements of a modular User interface are defined, the design of the modular user interface may begin. The specificatibn requirements allow the software engineer to model the user interface and the user. By modeling'the user interface the software engineer can a better software system by building an of the system. 23

PAGE 35

CHAPTER 3 PRELIMINARY DESIGNS The cost of developing user interfaces has increased over several years. The reason for this high cost of user interface development is that software.engineering is centered on creating custom software rather than assembling software from existing components. A solution to this cost is to develop a method that allows a software engineer to create a modular user interface. A modular user interface has several advantages over a custom designed user interface. One advantage is that a modular user interface can be used in several different applications with little or no modifications. A second advantage is that a modular user interface can be to fit new requirements with little redesign time. A third advantage is that a modular user interface can be upgraded with new procedures and old procedures can be changed without affecting other procedures in the user interface. 24

PAGE 36

In this chapter a brief review of the structured data analysis approach and the object oriented approach is presented. The combination of these two methods into a new method, called the modified method, and its application to the development of a modular user interface are also presented. Methods of Software Design are currently two major methods of software design: the structured data analysis approach and the object oriented approach. By combining these two methods a new method of software design for the development of modular user can be created. The Structured Data Analysis Approach The structured data analysis approach is a software engineering method that concentrates on modeling the software in the information domain. In the structured data analysis approach the flow of information is modeled using an item called the data flow diagrams. This model is used to aid in the understanding of how information flows through the 25

PAGE 37

software. 3.1 shows the graphical notation that is used in the data flow diagrams. [1] An external input or is represented by rectangle, that is, items that generate information for the system or that receives information from the system and are not to be modeled. The function that transforms the information is shown by a circle. The flow of information is shown by arrows, and the data storage is represented by the double lines. As information moves through a software system, the information is transformed by functions from an input to form an output. The flow of the FIGURE 3.1 DATA FLOW DIAGRAM NOTATION D 0 / EXTERNAL INPUT/OUTPUT TRANSFORM BUBBLE INFORMATION FLOW DATA STORAGE 26

PAGE 38

data through the transformations is represented in a graphical notation called the data flow diagram. Figure 3.2 shows the general form of a data flow diagram. FIGURE 3.2 GENERAL FORM OF DATA FLOW DIAGRAM EXTERNAL; INPUT EXTERNAL INPUT EXTERNAL OUTPUT EXTERNAL OUTPUT The data flow diagram shown in Figure 3.2 is called the Level 0 data flow diagram or the fundamental system model. The Level 0 data flow diagram is used to represent the entire software system as a single unit with all inputs and outputs shown by incoming and outgoing arrows. Different levels of det4il of the system can be represented by the different levels of the data flow diagram. As the Level 0 data flow diagram is refined into the lower levels other transforms and information flow paths are revealed. Each transform function is expanded into more 27

PAGE 39

transform functions that reveal more detail on how the data flows through the program. The data flow diagrams are refined until a .complete model of the transformation of data the software is achieved. The refining of the transforms into lower levels is shown in Figure 3.3. In Figure transform TO is refined into transforms T1 through T5, and transform T4 is refined into transforms T41 through T42. While each refinement of the transform function occurs the information flow maintains the same input and output. FIGURE 3.3 TRANSFORM REFINEMENT 28

PAGE 40

In the structured data ana 1 ys is approach the data flow diagrams assist the software engineer in the understanding of the flow and transformation of data in a software system. However, the data flow diagram usually causes confusion, because the data flow diagram is misinterpreted as a flow chart that is normally used in software design. Also, the use of the data analysis approach in designing modular programs is difficult to implement because of multiple types of data that is passed between procedures. The Object Oriented Approach The object oriented approach is a software engineer i.ng i met hod that con cent rates on the data objects used by procedures. The data objects are modeled by an object that has a name, attributes and any operations that may be performed on the attributes. [1] To model a data object the first step is to define a class of objects. Once the class is defined a set of attributes can be defined for a class. Then a set of operations that can be performed on the attributes that change the 29

PAGE 41

attributes are defined. The attributes of a class are inherited by the objects that are members of that class. For example, consider the class furniture, a set of attributes defined for this class are cost, dimensions, weight,location, and color. Each attribute is applied to the object chair and table as shown in Figure 3.4. As new objects are added to a class they take on the attributes of class. Once the attributes are defined, a set of operations are developed. For example, the attribute 'location' can have an operation performed FIGURE 3.4 ATTRIBUTE INHERITANCE BY OBJECTS CLASS: FURNITURE Cost Dimension Weight CHAIR Location Color Cost Dimension Weight Location Color 30

PAGE 42

on it, like. move, that would modify its value. The operations bf a class also are inherited by the objects that are members of that class as shown in Figure 3.5. In developing a software system, using the object oriented approach, the software engineer separates the nouns in the software definition into seven categories of information. Each category FIGURE 3.5 OPERATION INHERITANCE BY OBJECTS CLASS: FURNITUAE Cost Dimension Weight Location Color. OBJECT: CHAIR Buy Cost Sell Dimension Weigh Weight Move Location Color Buy Sell Weigh Move 31

PAGE 43

specifies the area of the information domain that can be classified as an object. The seven categories are listed in Table 3.1. TABLE 3.1 CATEGORIES OF INFORMATION External entities that produce or consume information to be used by the system Things Items that are part of the information domain Occurrences or events Items: that occur within the context of the system operation Roles Items: played by people who interact with the Organizational units Group items that are relevant to a system Places that establish the function of the system Structures Items that define a class or objects. Communication between objects is handled by the use of a message. One object passes a message that specifies an operation in another object that needs to be performed on a set of data. For example, object A needs object B to operate command OP10 that exists in object B on data C. The message is of the form: message:(B,OP10,). This form of 32

PAGE 44

message passing allows the software engineer to design modular software, because the communication between objects is of a generic template form. This generic template of communication creates a between the procedures. The object oriented approach allows the software engineer to develop a modular program; however, approach is sometimes difficult to understand and to implement. In a software system ,, it is difficult to determine the classes of objects and their association to one another. Also, It can never be certain that all the attributes and operations of an object have been defined. The Method Both the methods of structured data analysis approach object oriented approach can be used to develop a:m9dular user interface, however; the implementation of the two approaches can be difficult. In the structured data analysis approach the multiple data types make the development of independent'procedures difficult. In using the object approach the classes and attributes of objects cannot be fully defined for a user 33

PAGE 45

interface. A solution to this problem is to combine the message passing template of the object oriented approach .with data flow diagrams of the structured data analysis approach and create the modified method. The modified method is similar to the structured data analysis approach in that it is a method to model the information flow through a system. However, unlike the structured data analysis method, the modified method concentrates on the control domain as well as the information domain. The model used in the modified method is called the data control diagram. The data control diagram uses the same notation of the dataflow diagram, but; the implementation of the notation is different. The bubble represents the transformation of data, the square represents an external input/output, the arrow represents the flow of data and the double line represents the data storage. In the data flow diagrams the data is transformed by a bubble and then it passes to another bubble. The data flow diagrams place emphasis on the flow of data through the program and 34

PAGE 46

little concern with the function of the bubbles. In a data control diagram the function of the bubble is as important as the flow of data through the program, because; the function of the bubble will determine. how the data flows. The data control diagrams are more like the flow charts that software engineers are more familiar with. Using the Modified Method The use of the modified method in developing a modular user interface is similar to the structured data analysis method; however, some differences : exist can make the modified method confusing. To understand the use of the modified method an example of a user interface for the UNIX operating system is presented. Developing Data Control Diagrams The first step in developing a modular user interface after the specification requirements has been accomplished is to develop the data control diagrams. The development of the data control diagrams begins like the data flow diagrams with the definition of the Level 0 diagram. For example, the 35

PAGE 47

Level 0 data control diagram for the AMUI in Chapter 2 is shown in Figure 3.6. FIGURE 0 DATA CONTROL DIAGRAM OF THE AMUI USER INPUT FROM USER COMMANDS TO SYSTEM UNIX OPERATING SYSTEM SCREEN DISPLAY MESSAGES At this level the user interface is described as a single bubble. This bubble i the representation of whole user interface that connects the computer, the user, the screen and the system, together. Beforefurther factoring of the Level 0 data control diagram can begin the components of a user interface must be defined. By definition the user interface tkes input from the user and transforms 36

PAGE 48

it into commands the system understands and then takes information from the system and transforms it into something the user understands. The user interface also supplies information to the user on commands and the function of the user interface. From this definition it can be determined that a user interface has four main components. The four components are the input processor, the output processor, the function processor, and the help processor. These components for the example are shown as a Level 1 data control diagram in Figure 3.7. Looking at this figure it can be seen that the inputs and outputs remain consistent with the Level 0 data diagram. At this level in the design the form of the message passing template must be determined. For the user interface to be modular the main components must have a single form of. message passing similar to integrated circuits in a computer. These message templates will be the only forms of communication between processes in the system. For example, the message templates for the AMUI is of the form:(command, command_string) and (message). 37

PAGE 49

FIGURE 3.7 LEVEL 1 DATA CONTROL DIAGRAM OF THE AMUI INPUT FROM USER (a) FIRST _COMMAND, FULL_ COMMAND COMMANDS TO SYSTEM (c) DISPLAY MESSAGES (b) MESSAGE MESSAGE 38

PAGE 50

The is to have a maximum of four types of message templates in the program. This allows for a minimum number of combinations of forms that the messages can have. The fewer the combinations of messages passed between the processes the higher the independence of the processes. The independence of processes is discussed in Chapter 4. factoring of the bubbles depends on the specification requirements. The specification requirements specify how the four main bubbles are to be factored into further levels. For example, table 3.2 ihows the specification requirements of the AMUI as determined from Chapter 2. TABLE 3.2 SPECIFICATION REQUIREMENTS OF THE AMUI Functional requirements 1. Ability to mimic other operating systems. 2. Execution of new commands not found on the UNIX o.s. 3. of standard UNIX system commands. 4. Command that execute many commands. 5. History of last ten commands entered. 6. Context sensitive help. 7. values that specify the terminal and the system that the user is mimicking. Design objectives 1. Operating system independent. 2. independent. 3. Easy change of input/output displays 4. Easy addition of new commands. 39

PAGE 51

From this list of specification requirements it can be determined that the function processor is divided further into four bubbles as shown in Figure .8. The message templates previously defined wi11 be used by the sub bubbles for communication to modularity in the user interface. Also the design objectives state that the input and output processes must be easily changed; therefore, further factoring of the input and output processors is unnecessary. For the example the input and output processors will be factored into input and A replacement of these processes is covered in Chapter 5. The factoring of the user interface continues in this manner until all bubbles have reached their minimum level. The minimum level of a transformation bubble is determined when the transform function has a single input and a single output. The full Level 1 data control diagram for the AMUI is shown in Figure 3.9. The intermediate data control diagrams of the user interface are in Appendix B. In each level of the data control diagrams it. can be seen that the data 40

PAGE 52

FIGURE 3.8 LEVEL 2 DATA CONTROL DIAGRAM OF THE AMUI FIRST_ COMMAND, FULL_COMMAND (d) UNIX_ COMMAND FULL_STRING STRING 41 COMMANDS TO SYSTEM (g)

PAGE 53

FIGURE FULL LEVEL 1 DATA CONTROL DIAGRAM OF THE AMUI UNIX_CMND COMMANDS TO SYSTEM UNIX_CMND UNIX OPERATING SYSTEM DATA BASE 42

PAGE 54

flow from the upper level is carried on to the next level. Defining Transformation Bubbles Once the factorization of the user interface has been completed the next step in the design of a modular interface is the definition of the transformation bubbles. The definition is in English and. explains briefly the purpose and the function of the bubble. This definition is called the Level 1 pseudocode. The Level 1 pseudocode is a description of the transformation bubbles in a narrative text form of the process. algorithm. For example, the Level 1 pseudocode of the input processor of the AMUI is given in Figure 3.10. The Level 1 pseudocode of the other processes are listed in Appendix c. The Level 1 pseudocode is used to an overall understanding of the function of the user interface. FIGURE 3.10 LEVEL 1 PSEUDOCODE OF INPUT PROCESSOR The input processor collects the input from the user and separates the first command from the rest of the command line to form two strings of information: a command and a command line. This information is then passed onto the next process. 43

PAGE 55

The.Level 1 pseudocode is only done for the lowest level transform bubbles. With the factorization of the transformation bubbles into lower levels of abstraction .the definition of the lower levels define the upper levels of the data control diagrams. In the. structured data analysis approach another of pseudocode is required; however, the moditied method only requires the first level of abstracti.on at this stage of design. The reason for this difference is that in the modified method like the data analysis method the actual processes do not correspond one to one with the I transformation bubbles. A second level pseudocode is too close to the actual cQding stage of the design to be of any use at this stage. The modularity of the design and the the message passing to two or less formats make the coding of the process impossible at this design stage. The development of a Level 2 pseudocode is discussed in Chapter 4. 44

PAGE 56

Summary There are two major software engineering methods for designing software systems: the structured data analysis approach and the oriented,approach. Both methods have advantages and disadvaniages in developing modular programs. To compensate Jor the disadvantages a new method that combines the techniques of both the structured data approach and the object oriented approach was developed. The new method, called the modified method, allows the software engineer to develop modular programs efficiently than other methods. Using the graphical notation of the data analysis approach and the message passing template feature of the object oriented approach the modified method the software engineer to develop a modular user interface. 45

PAGE 57

CHAPTER 4 FINAL DESIGN SPECIFICATIONS In this chapter the modified method will be used to clevelop the final design specifications of a modular user interface. The development of the procedure charts and the development of the program code of a modular user interface from the preliminary design specifications are presented. Procedure Chart Design Before the coding of the modular user interface can begin, a second level modeling of the user interface be done. This second level modeling, called procedure chart design, refines the transformation bubbles of the data control diagrams into the procedures of the modular user interface. The first step in the procedure chart design is the determination of the central transformation bubbles in the data control diagrams. The central transformation bubbles are the main transform functions that perform all the main computation of the user interface. The determination of the 46

PAGE 58

central transformation bubbles is accomplished by separating the bubbles into the three categories of incoming flow, transform flow, and outgoing flow. The intoming flow and the outgoing flow are transforms that allow the central transforms to communicate to the external world. The incoming flow converts data flowing into the system into an internal form while the outgoing flow converts data leaving the system from an internal form to an external form. The incoming flow transforms actually do not perform any function but simply convert data from one formto another. The information contained in the data remains the same. The transform flows perform the main functions '' I nd operations of the user interface. In a transform flow the information is analyzed and decisions or actions are taken based on the information. contained within the data. In some instances the actual information in the data is changed by the transform flow. Once the transformation bubbles have been separated into the three different categories of information flow, the next step is to map the data 47

PAGE 59

control diagrams to a program template called a procedure chart. This procedure, called transform analysis, the requirements analysis and the actual coding of the user interface together. Transform Analysis The procedure for mapping the data control diagrams to' the procedure charts is separated into five steps:. review, analysis, first level factoring, second leve) factoring, and refinement. Each step of the design is to ensure the proper design of the user interface. Step 1: Review The first step in the design is a review of the specification requirements and the data control diagrams. This review is to ensure that the factorization of the data control diagrams are completed. If the data control are not completed, the final design specifications cannot be accurately defined. Step 2: Analysis The second step in the design is an analysis of the data control diagrams to determine which bubbles 48

PAGE 60

are the incoming and outgoing flows and which ones are the transform flows. This step is to determine which processes are the main processes and which processes the subordinate processes. At the separat i on points a transform boundary is p 1 aced. The point where a transform boundary is placed is where the transform functions and the input and output intersect. Transform flows are bubbles that either make decisions, perform operations or that change the information contained in the The input and output functions change the of the data: however, they do not change the information contained in the data. An example of the placement of transformation boundaries for the AMUI is shown in Figure 4.1. Step 3: First Level Factoring The.third step in the.development of the final design specifications is the mapping of the data control diagrams into the Level 1 procedure chart. This mapping, called the first level factorization, converts the preliminary designs into the program blueprint. The Level 1 procedure chart shows the contr-ol 49

PAGE 61

FIGURE 4.1 DETERMINATION OF INFORMATION FLOW CATEGORIES r-----1 I I I I I UNIX_CMND COMMANDS TO SYSTEM // / / "' ., -----, \ \ \ \ I I I I I I I I I I I t I r I : I I DATA BASE t ----1 I I I I UNIX_ CMND ........ ..... .... -.-" ........ -_...., ___ UNIX OPERATING SYSTEM --.... ...l'JI'I--50 __ ... --

PAGE 62

for the dncoming, the transform, and the outgoing of processing. The subcontollers are all controlled :by a main controller that coordinates the flow of information through the system. Figure 4.2 illustrates the mapping of a data control diagram into a 1 procedure chart, the control modules used generic. FIGURE 4.2 FIRST LEVEL PROCEDURE CHART MAPPING INCOMING TRANSFORM OUTGOING FLOW FLOW FLOW ',i_........., ----r,.-INPUT CONTROLLER MAIN CONTROLLER TRANSFORM CONTROLLER OUTPUT CONTROLLER The procedure chart is based on a top-down format. Th.at is the top modules perform mostly control whi ,1 e the bottom modules perform mostly input /out put processing and operations. In the design of the procedure chart there may be many 51

PAGE 63

levels of riontrollers for each of the generic control modules. The first level factoring of the data control diagram shown in Figure 4.1 is shown in 'Figure .. The complete factoring of the AMUI into procedure charts can be found in Appendix D. Each proceudure represents the actual program process tha:t is to be developed for the user interface Step 4: Sedond Level Factoring Once the data control diagram has been mapped to a Level 1 procedure chart the next step is to map the individual transform bubbles into the program procedure This step completes the conversion of the preliminary design of the user interface into the program blueprint. The of the transform bubbles begins at the boundaries and moves outward along the information flow pat.hs. Each level of the data control diagrams is mapped into the procedure charts. the example of Figure 4.2 the second level factoring is illustrated in Figure 4.4. As can be seen in Figure 4.4 the mapping of the data control diagram transform bubbles into the 52

PAGE 64

FIGURE FIRST LEVEL FACTORING OF FUNCTION PROCESS DATA CONTROL DIAGRAM FULl._ COMMAND INPUT' CONTROlt.ER DATA BASE MAIN PROCESS CONTROLLER FUNCTION PROCESS CONTROLLER / MESSAGES UNIX COMMANDS PROCESS SYSTEM COMMANDS UNIX OPERATING SYSTEM 53

PAGE 65

FIGURE sECOND LEVEL FACTORING OF PROCEDURE CHARTS. INCOMING 'FLOW MAIN CONTROLLER may not be one to one. Transform bubbles may be combined into one procedure or a single bubble may be expanded. into several procedure. Once module is created a description 54

PAGE 66

explainirig its function is made. These descriptions are a refinement of the process descriptions of the bubbles done in the preliminary design The narrative describes module data stored by the module, a procedural narrative and a description of any restrictions or special features of the module. The process for the AMUI are in Appendix E. The process descriptions are a more descriptive explanation of the function of the process than the Level 1 pseudocode. Step 5: The ,transform analysis is an iterative process; the procedure chart developed may need several revisions before an adequate design is achieved. In a modular user interface the procedure chart must have a high independence among modules, called cohesion, ahd a low complexity of communication between modules, called coupling. To achieve this the first 4 steps may need to be repeated several times. 55

PAGE 67

Cohesion. A spectrum may be used to represent cohesion as. shown in Figure 4. 5. There are seven general types of cohesion: coincidental, logical, temporal,. communicational, sequential, and functional. FIGURE 4.5 COHESION LOW COINCID.ENTAL LOGICAL TEMPORAL PROCEDURA!COMMUNICATIONAL FUNCTIONAL HIGH SPECTRUM MULTI-FUNCTIONAL BAD 1 GOOD SINGLE FUNCTIONAL Each type of cohesion is a measurement of the functional association between procedures. Coincidental cohesion is where a procedure performs a set of tasks that are unrelated. Logical cohesion is where a procedure performs a set of tasks that are logiclly associated for example, grouping all the input and output tasks together. Temporal is where procedures must be executed in the same amountof time. Procedural cohesion is where procedures must be executed in a specific order because they are related. Communicational cohesion is where a group of procedures concentrate on one type of data. Functional cohesion is where 56

PAGE 68

procedures perform one task each. In designing a modular user interface the modified method allows the software engineer to achieve a high cohesion level due to the message passing template. The message passing template makes use of communicational cohesion in that the modules use the same data types. Coupling. As with cohesion a spectrum may be used to represent coupling, as shown in Figure 4.6. There are seven types of coupling: no direct coupling, data coupling, stamp coupling, control coupling, external coupling, common coupling and content coupling. FIGURE 4.6 COUPLING LOW NO DIRECT COUPLING DATA COUPLING STAMP COUPLING CONTROL COUPLING EXTERNAL COUPLING COMMON COUPLING CONTENT COUPLING HIGH SPECTRUM SIMPLE COMMUNICATION GOOD I BAD COMPLEX COMMUNICATION Each type of coupling is a measurement of the style of that occurs between procedures. No direct coupling occurs when procedures are sub procedures of different superior 57

PAGE 69

procedures. Data coupling is when procedures communicate with simple data types. Stamp coupling is when a pbrtion of a data structure is passed between procedures. Control coupling is when procedures pass flags to one another. External coupling is when procedures are communicating to external devices; though external coupling cannot be fully eliminated in some systems, it should be limited to minimum of procedures. Common coupling is when two or more procedures have access to a global data storage. Content coupling is where one procedure has access to another procedure's local data storage. In the modified method the use of the message passing template allows the software engineer to design a user interface that has low coupling. The Modified.Method uses simple data types in the message templates, this is a form of data coupling. Coding The final stage of the design of a user interface is the development of the Level 2 pseudocode, the data dictionary and the generation of the program code. Once these items have been 58

PAGE 70

developed the user interface may be constructed in any computer language the software engineer may use. Level 2 Pseudocode The Level 2 pseudocode is a description of the function of. the procedures written in a structured English. The software engineer can use any pseudocode that fits the following requirements. A pseudocode must have: 1. A syntax for structured constructs, data declarations, and modularity characteristics. 2. A language that can describe processing features freely. 3. The ability to describe data declarations efficiently. 4. The ability to call and define subprograms. For example, using AMUI, the Level 2 pseudocode of the functional processor and its sub processes are shown in Figure. 4.7. The full Level 2 pseudocode for the AMUI is in Appendix F. The Level 2 pseudocode is a very low level type of pseudocode because the process descriptions are used to explain the function of the processes. 59

PAGE 71

FIGURE LEVEL 2 PSEUDOCODE OF FUNCTION PROCESSOR FUNCTION BEGIN SET seafchpar TO 0; OPENFILE amui.cmd FOR READING; READFILE amui.cmd INTO cmd; WHILE (9md; ENDOFFILE) AND .(searchpar 1) DO IF cmd = first_prt THEN TO 1; ENDIF; READFILE amui.cmd INTO cmd; ENDWHILE; CLOSEFILE amui.cmd; IF searchpar = 1 THEN CALLPROCEDURE (UI CMD) WITH full_prt, first_prt, IF message[O] done THEN CALLPROCEDURE (OUTPUT) WITH message; ENDIF;' ELSE OPENFILE' mimick.cmd FOR READING; READFILE:mimick.cmd INTO cmd; WHILE ENDOFFILE) AND (searchpar 2) DO READFILE mimick.cmd INTO mimick; IF cmd = first_prt THEN SET searchpar TO 2; ENDIF; READFILE mimick.cmd INTO mimick; ENDWHILE; CLOSEF.ILE mimick.cmd; IF searchpar = 2 THEN CALLPROCEDURE (MIMICK_CMD) WITH full_prt, minHck; ELSE : CALLPROCEDURE (SYSTEM_CMD) WITH full_prt; ENOIF; ENDIF; END; 60

PAGE 72

Data Dictionary In addition to the Level 2 pseudocode an item called a data dictionary is developed. The data dictionary is a list of the storage variables used in.the procedures. This list includes their names, aliases, data types, and their function within the program. The data dictionary is used to keep track of the information in the user interface. The general form of a data dictionary is shown in Figure 4.8. FIGURE 4.8 DATA DICTIONARY FORMAT NAME: primary name of variable ALIASES: other names of variable WHERE USED/HOW USED: listing of processes that use the variable and how they use it. DESCRIPTI0N: notation for representing content The notation used for the description is shown in Figure 4.9. Expansion of the description continues until each item is represented as simple items such as letters or numbers. FIGURE 4.9 DATA DICTIONARY DESCRIPTION NOTATION = + [ : ] m{ }n ( ) is composed of and or repetition of from m to n data comment 61

PAGE 73

The dictionary for the variable in the processor is shown in Figure 4.10. The data dictionary for the AMUI is in Appendix G.; The data dictionary is used by the software to determine how data is stored and used in: the user interface. FIGURE 4.10 .. DATA DICTIONARY OF FUNCTION PROCESSOR NAME: ALIASES: WHERE USED/!10W USED: DESCRIPTION: full cmd none function processor (variable is used to pass information between processes) full cmd = string of characters characters= [a:b: ... A:s: ... Z] With procedure chart and the data dictionary finished the software engineer can generate code for the user interface. The coding of the user translates the design into the programming language. Any structured programming: language can be used to develop the user interface. The program code, written in the ANSI c computer with a complete description of the program:for the AMUI is in Appendix I. 62

PAGE 74

Summary The final design specification is a method by which engineer links the preliminary I' design specifications and the program code. The data control diagrams are mapped to a program procedure chart by transform analysis. The program procedure chart is used as a blueprint of the structure Qf the user interface. The:'t ransform ana 1 ys is separates the informatfori flow into the categories of incomihg, outgoing arid transform. This separation allows the software :en:gineer to map groups of transformation bubbles control modules .. _Further factoring develops :a program procedure chart that can be used to gene ra.t e: the program code of the user i nt erf ace. Theprocess of developing a well designed user interface is an iterative process. It is intended that the.techniques presented in this chapter be used in successions to produce a final model. 63

PAGE 75

'I I! ,I I I ., I "! : I I ,, CHAPTER 5 ENHANCEMENTS of existing software systems is a I major consern in software engineering today. With faster and having more i capab i 1 it i!es the enhancement of existing software is needed advantage of the new capabilities 6f the However, modification of existing '! software systems can cause the failure of the system I I because, the software was never designed for I enhancements. In a modular program enhancements can ', be made a risk to the system. I With the user interface as the primary device I for a computer system, modification of the requires modification of the user 'I interface.!f modular user interface can be modified or changed[with little development time and at a I lower cost'to the software developer. ,, In this chapter the method for modifying a ::i ,:I modular interface developed with the modified met hod is present e.d. The addition of a new I! I 64 ii

PAGE 76

procedure'and the changing of the input procedure is : Enhancing the User Interface I 'I The m:odification of the modular user interface was brieflY presented in Chapter 3. are two major of modifications that can be made to a I: user The two modifications are the change of Jhe input/output interaction and the r I addition or change of commands. In the modified i method there are minor differences in how new procedures; added to the user interface. There:lar.e three steps to modify a modular user I interface that was designed using the modified ll method: inil:er'face matching, development and testing, 'i and recompiling. These methods are used to ensure the proper]1cohnection of a new procedure to the user interface. Step 1: Interface Matching l li The fi'rst step in the modification of modular i user interface is the interface matching. This step :1: is used the incoming arguments of the new procedure t:o the outgoing arguments of the existing 65

PAGE 77

I I user interface. The device used to match the ,,i the user interface and the new procedure:rs called the interface matrix. The interface matrix is a table that shows the 1: arguments 1:that each procedure uses to communicate ; with the procedures. The form of the ,. interface matrix is shown in Figure 5.1. The .I procedures, wi'th incoming arguments are listed along I' the top and the left side of the table are proceduresithat have outgoing arguments. This I divides table into a set of squares. In each square arguments passed between the two ,i procedures:; are 1 i st ed. These arguments are crossed II referencedlwith the data dictionary to gain an ,, understanding, of how the procedures communicate. I In Figure 5.1 it can be seen that the argument :i II that is passed from procedure 2 to procedure 3 is an 'I FIGURE 5.1 .!:GENERAL FORM OF INTERFACE MATRIX II TO FROM PROCEDURe'l1 PROCEDUREi!2 ''I PROCEDURE113 "I 'i PROCEDURE N/A ARRAY ARRAY 1 PROCEDURE 2 PROCEDURE3 STRING INTEGER N/A INTEGER STRING N/A 66

PAGE 78

I '! I, integer. data types for the arguments are ill implied by Figure 5.1, the arguments are usually variable The variable names can be cross :; to the data dictionary to determine the I I exact data type and format that is used. Using the I I the AMUI the interface matrix can be illustrated in I ... Figure 5.2. : FIGURE 5.i INTERFACE MATRIX FOR THE AMUI .:To MAIN FUNCTION UI COMMAND FROM I CONTROLLER CONTROLLER I INPUT' FULL_STR, N/A N/A CONTROLL,ER FIRST_STR i FUNCTION N/A N/A FULL_PRT, CONTROLL,ER FIRST_PRT I UI N/A MSG N/A CONTROLL,ER MAIN !j N/A FULL_CMD, N/A I ., FIRST_CMD I In 5.2 it can be seen that the arguments il I that are passed between the Input Controller I procedure the Main procedure are the FULL_STR found in I ,, a1nd _,, 'I the I ol These two variables can be data dictionary where the data types can be The full interface matrix of 1: AMUI can be found in Appendix H. The interface ,, matrix shows how the processes communicate in the ,I ,. 67 I I. I

PAGE 79

[i I II II : I! I! !\ :_ I li I user intefjface. If input procedure was to be developed, it would to output two arguments that are the same as FWLL1STR and FIRST STR. The use of the variables.iial:o will have t: be the same for the 'i with existing program. The of a new command to the user that the new procedure accepts I li ,, the arguments FULL PRT and FIRST PRT and return the II li argument ,FG. These arguments are through the user controlling process and are processed the correct command subprocedure. I'' 'I II I 'I .. I, Step 2: and Testing I' : Once types of the input and output 'I variables been established the new procedure can be For example, the process description ![. and the filrst1 procedure pseudocode. o_f a menu driven I input for the AMUI are shown in Figure II 5.3. All procedures can be found in Appendix li i F. These propedures are to replace the input I li procedure that is currently used in the AMUI. !I 68

PAGE 80

i FIGURE 5.3 PROCESS DESCRIPTION AND PSEUDOCODE OF MENU INPUT PROCESSOR FOR THE AMUI Menu Driven Input Processor: This:.process first displays the level 1 menu on the The level 1 menu gives the user five options. !iThe five options are: 1. System Utilities. 2.. F i 1 e :Uti 1 it i es. 3. Tools. 4. Line. 5. : The System Utilities are UNIX commands perform functions on the operating system. File Utilities are UNIX commands that perform fl:(nctions on files. The Tools are commands that the user to perform other actions. The Command Line is the direct input of the user commands ihto the command line. The Exit is the termination of the user interface. The System Utilities menu contains five opti6nsJ The five options are: 1: 1. Command History. 2. Jobs. 3. Change Directory. 4. Make :Directory. 5. The Utilities menu contains four options. The four options are: 1 List 'F i 1 es. 2. Copy 'i=i les. 3. Move ;if i les. 4. Remove File. The Tools menu contains four options. The four options ar'e: 1. Display Files. 2. Password. 3. He 1 p. : 4. VI Editor. When the user selects an option from the second level the associated UNIX command is placed in the string;FU:LL_CMD. If the command requires additional::information from the user like a file name then the user interface processer indicates to :I i .I I 69

PAGE 81

I the user what information is needed. The additional is concatenated to the string FULL CMD. The first i: wo:rd in the string FULL_CMD is then copied into the FIRST_CMD. The strings FULL_CMD and FIRST_CMD::are then returned to the calling procedure:. I MENU_INPUT(full_str,first_str) BEGIN SET i TQ 0; WRITE TO screen,"\n1. Operating System I ,' Utilities\n2. File Uitlities\n3. 'I Tools\n4. Command Line\nS. Exit\n"; WRITE TO screen,"Enter number:"; READ keY,board, ch1; IF ch1 1 THEN CALL ;PROCEDURE os_ut il WITH full_st r; ELSEIF = 2 THEN CALL PROCEDURE file_util WITH full_str; = 3 THEN CALL tools WITH full_str; Gh1 = 4 THEN get_input WITH full_str; ELSE[I F ch 1 = 5 THEN S,ET"full_str TO "exit"; END IF ENDI ENDIF ENDIF :: END IF WHILE (full_str '\0') DO SET TO i + 1 ; ENDWHI LE\; IF (i =:LENGTH OF STRING(full_str)) THEN SET f i:rst_st r TO fu ll_st r; ELSE .1 SET TO FIRST i CHARACTERS OF ENDIF; END; 70

PAGE 82

The I I : I I' ,, process 'I description and the pseudocode of command I the new for the AMUI is shown in Figure 5.4. This procedure is to be connected to the user ol I interface1i1command control procedure. 1;, :I Testing of the new procedures can be done by an test program. The test program :I FIGURE PROCESS DESCRIPTION AND PSEUDOCODE OF NEWMAC COMMAND FOR THE AMUI Newmac: :I This drocess receives two strings from the calling pr!ocedure. The first string contains the macro that1 to be added and the second string contains command that is associated with the macro. ;! The file is first searched for the new macro to that there will not be a duplicate macro to the file. If the macro is added to the file an error code is returned to the calling procedure.;: If the macro does not exist in the file then fi rstl string and the second string are added to the macro .:[tile. !I Procedure :1: NEWMAC BEGIN ... 1 OPENFILE\macros FOR reading/writing DO \ READFLLE macros INTO macro,temp UNTIL macro = ENDOFFILE OR macro = newmacro IF macrd[= ENDOFFILE THEN -WRITE !FILE macro WITH new_macro,new_command RETURN i ( 1) ELSE RETURN! (0) ENDIF I END ,I i I, i! I I 71

PAGE 83

I 'I ,, .i passes to the new procedure and tests from the procedure to ensure that the procequre will interface correctly with the fhe arguments used by the test program are the same that are sent to the procedure from the act ua 1 sys:t em. I 'I Step 3: 1 i ng the new procedures have been developed and tested, they can be attached to the user interface. The method by which the new procedure is connected to the existing user interface depends on the structured language that is used to develop the ,. user and where the new procedure is to be used. Th! language that was used to develop the ,, AMUI was ANSI C because of the number of systems I ,, that have compilers. The complete program of the :I AMUI in ANSI C can be found in Appendix I. :i When replcing an existing procedure no 'I to the existing software is needed; however, if a: new command procedure is added then I the may need to be new command procedure. For of the inpJt procedure with i 72 'I I I .I I modified to accept the example, the replacement the new menu input

PAGE 84

:i ., 'I procedure, on 1 y requires that the procedures be II swapped. The addition of the new command to the ,I AMUI that the new command procedure be added to user interface command controller I The command also must be added to the "I command file for the AMUI to know the command II type. : ,I ., !I !i Summary A software engineer cannot know all the needs I'' il of every user at the time of design. A way to meet ,;I ., the needs,1i of every user is to design a modu 1 ar user I interfaceU The modular user interface has the advantage!!of being able to be adapted to different :I software dackages with little development time. I once the modular user interface is ,, I' designed the software engineer must be able to 11! 1 modify it ., If a 'user i nt e,rface is designed using the tl modified method, modification is a simple matter. :I I The new is matched to the existing user i interface:py using the interface matrix. Then the new proced\u re is tested ext e rna 11 y to the system and finally 1 inked i I ,I i I I into the user interface. Some 73

PAGE 85

modificaton, of the user interface may be needed the type of modification being made. Using the modified method a user interface can I be that is a core unit. That is, a software package that can be added to or expanded upon to the software package. This type of I user can be changed to match the needs of 'I the user and may never become obsolete. I 74

PAGE 86

' :I .i \I 'I i I !' I CHAPTER 6 CONCLUSIONS Withilthe increasing costs of software .! 'I developmerit method to produce software I "I applicati,ns both faster and cheaper is needed. Software applications of today are custom designed 1.1 I for this custom manufacturing I cost of the development of the !I software A solution to reduce the cost of 'I software is to begin developing modular I software II Modul:ar .software applications have the ,I 'II advantage of.being reusable; while, customed :I designed applications can only be used for I one problem. With a modular program enhancements ,I and can be made it to be in a I different application. The enhancements of custom il software syst ems is cost 1 y and can sometimes resu 1t II I in the fai,lure of the system, because, the custom I I designed sbftware system is not designed to be I changed. : : I .. I ;[ 0 ,J I ., ,I 75

PAGE 87

I 'I .i One major component that every software I I appl1cat1on has in common, and that can be made II reusable the user interface. The use of an II existing dser interface as a reusable unit can reduce th' cost and time involved in the development i :r of the applications. For a software tl ::I engineer be able to reuse a user interface is I must be designed in a modular fashion. I A interface that is modular in nature has the of being able to be changed to meet Jl, :I the needs!of the user. Every need of the user ;I cannot at the time of the design and 'li the same for different types of users ,I I requires different type of user With a :I modular usrr interface the format of the interaction can be to suit the user. This change can be I !I without a major redisign of the .:I I interface ,i 'I There! are currently two methods for developing 'il a modular 'program, the structured data analysis :: approach and the object oriented approach. The ,, structured,! data analysis method is easy to use in developing:1custom programs but is difficult to I I .. I I 76 I 'I

PAGE 88

' implement':;n developing modular programs. The 'I object method is to use in developing standard and modular programs; however I the oriented method produces highly 'i I programs because of a generic message passing By combining both methods a method to ,, ,,, develope modular programs easily can be achieved. < ,I The methods, called the modified method, combines the ease of use of the structured data analysis method with the generic message passing of the object oriented method. The resu 1 t i is a met hod that is easy to use and 1 earn I I and that developes highly modular programs. By using the modified method a user interface with a high degre!e of modularity can easily be designed. 1: The rri'odified method is just one software development approach that can be used tG develop a ., modular usr interface. The modified method still allows varience by the software engineer in the design,of the user interface. Further research I is needed before a standardized method of developing i :r modular user interfaces is achieved. I I 77

PAGE 89

areas of research may include the 'I 'I development .I of a standard operating system, or the developmel')t of a standard programming language. A standard system or programming languag will allow software engineers to develop a ,, of predesigned software modules. Each of I ,l!i these modyles may be used to piece together a software that can be transported between computer systems. I possible research area may be in the applicatio'n of the modified method to develop I, modular other than a modular user The use of the modified method to develop modular programs would be similar to II its use in the development of a modular user interface .. II afe only a few possible areas of research i I and more areas may open up as research continues. ,, Software is a relatively young science and the research is just beginning. ,, 78

PAGE 90

APPENDIX A l PURPOSE OF THE AMU I This appendix contains the definition of the I AMUI. The following paragraphs give a brief explanation to the purpose of the user interface ,. that was Used as an example for design in this ,, I paper. The purpose states the basic functions and I the considerations of the AMUI. I User Purpose: A interface is to be designed that will allow 6f different skill levels and experience to user the UNIX operating system with an equal The user interface is to supplement the hell by adding new functions and capabi 1 it i1es The of the user interface are for it to be to add new commands to the system easily at a low cost to the software engineer. The input interaction must also be able to be modified bY the software engineer to adapt it to the different users and their needs. The user interface also ibe able to mimic other operating systems like the MS-DOS operating system. Additional ,, requirements of the user interface are for it to be hardware 'operating system independent. The must have an interactive help function that can have new help messages added and have a key.Word search capability. This help function be to be accessed from the user i nt e rf ace :and from the standard she 11 ; therefore, the help must be an independent process. The help must also be fast and efficient. 79

PAGE 91

I I I! APPENDIX B \.; .. 1 :: DATA CONTROL DIAGRAMS OF THE AMUI I ., The.bictures in this appendix are the data control of the AMUI f6r the UNIX operating system. The procedure used in developing these diagrams :1 s out 1 i ned in Chapter 3. :I LEVEL 0 DATA CONTROL DIAGRAM USER INPUT FROM USER ,, 'i I I COMMANDS TO SYSTEM UNIX OPERATING SYSTEM 80 SCREEN DISPLAY MESSAGES

PAGE 92

I I I ; I I !I ,. i (a) FIRST COMMAND, FULL COMMAND I I I : COMMANDS TO SYSTEM (c) MESSAGE 81 (b)

PAGE 93

: I I I : I LEVEL 2 DATA CONTROL DIAGRAM: REFINEMENT OF INPUT PROCESSOR KEYBOARD INPUT I 1 : :kEYBOARD 'I,NPUT ...! i I i I I I I i! [ i .. ; I \ ,, I i ., I I : I I I i I INPUT MACRO FULL_COMMAND 82 FIRST COMMAND, FULL_COMMAND FIRST COMMAND, FULL _"COMMAND

PAGE 94

:i i LEVEL 2 ,DATA CONTROL DIAGRAM: REFINEMENT OF FUNCTION PROCESSOR I FIRST_ GpMMAND, FULL COMMAND 'I I (d) I i' UNIX COMMAND ;i : I I FULL_SffiiNG STRING 83 COMMANDS TO SYSTEM (g) (f) DATA BASE

PAGE 95

LEVEL 2 CONTROL DIAGRAM: REFINEMENT OF HELP PROCESSOR I 'I ,, :I ,I I I 'I I MESSAGE MESSAGE ARGUMENT WORD

PAGE 96

' ,,, I LEVEL 2 hATA CONTROL DIAGRAM: REFINEMENT OF OUTPUT PROCESSOR I I ii' :i 'I II I .,I 'l,j i I li II ,. ':I I II ![ : I 1 :! I I I I ,, MESSAGE FORMA TIED MESSAGE 85 MESSAGE DISPLAY MESSAGE

PAGE 97

I FULL LEVEL 1 DATA CONTROL DIAGRAM '1: ,I UNIX_CMND I I COMMANDS TQ SYSTEM I :,_1 ....oil------;I UNIX OPERATING SYSTEM 86 DATA BASE

PAGE 98

: I I I APPENDIX C LEVEL 1 PSEUDOCODE OF THE AMUI I This1appendix contains the Level 1 pseudocode of the AMUI. The Level 1 pseudocode is a brief of the purpose of each bubble in the data cont'rol diagrams. The procedure used in ,, [I this pseudocode is outlined in Chapter 3. ,, I The'[ Level 2 data control diagrams were used to develop separate Level 1 pseudocode procedures. I. Collect Input: This collects the input from the keyboard and. p 1 aces it in a string that is passed onto the Che'ck for Macro process. All null inputs are ignored. Check For,Macro: This checks the input to see if it is a macro. If the input is a macro, then it is passed onto the Con1vert Macro process. If the input is not a macro, it is passed onto the Generate Command process. :! convert Macro: This process converts the input that is a macro into a command or series of commands that the user understand. thisnew command input is then to the Generate Command process. I Generate Command: This process takes the input string and separates: the first command from the rest of the string. generates two strings with one string as the firstilcommand and the second string as the full input Both strings are sent to the Process Commands 'I 87

PAGE 99

:i i !I Process Commands: This checks the first string to if the command is one of four types of commands: a !UNIX operating system command, a MS-DOS operating! system command, a user interface command or a request. To determine the type of command the proc.ss reads two files, the first file contains the MS-DOS commands with the equivalent UNIX operating1system commands and the second file contains the user interface commands. If the command is a MS-DOS command, then both second st'hng and the UNIX equivalent command is sent to the Process Mimic Commands process. If the command is a user interface command, then the second string is sent to the Process UI Commands process. 1 If the command neither a MS-DOS command or a user command, then it is a UNIX operating system and the second string is sent to the Process System Commands process. If the command is a HELP request, then the second stih ng is separated into the command and the argument.1 The argument is passed onto the Check Type process. Process SYst1em Commands: This :process takes the second string and submits it to the:UNIX operating system for processing. I Process Mimic Commands: This command takes the UNIX. equivalent command and replace$ it with the first command in the full input This string is then sent to the Process System Commands process. I Process UI Commands: This lprocess processes all current and future user commands. Check Type: This ;process checks the argument to determine what of help is requested. If the argument is empty, then the Talk To Help process is activated. If the is not empty then the argument is passed onto 'the Find Help process. 88

PAGE 100

'I I! ., Talk to Help: This 'process activates an interactive help process gets a search word from the user, checks the word to see if help is available and then passes itronto the Get Help process. The process is repeated the user types in 'exit'. Find He 1 p;: This process checks the argument to see if a help message exists for the argument and then passes it onto the Get Help process. Get Help:! This process gets the help message for the argument and then passes it onto the Generate Message If no help exists for the argument, an message is passed onto the Message process. Generate This manipulates the message into the correct format to be displayed on the screen. This new is sent onto the Display Message process. 1 I Display This displays the messages on the screen. I' 89

PAGE 101

i I I 'li :1 APPENDIX D PROCEDURE CHARTS OF THE AMUI The diagrams in this appendi.x are the procedure i I charts of' the AMUI for the UNIX operating system. I, The used in developing these procedure :! charts is'outlined in Chapter 4. I! I FIRST LEVEL FACTORIZATION OF DATA CONTROL DIAGRAMS ,I 'I .I USER I II I I i INPUT FROM USER I I I I USER INTERFACE SCREEN DISPLAY MESSAGES 1 COMMANDS TO SYSTEM UNIX OPERATING SYSTEM 90

PAGE 102

I I! :! SECOND LEVEL FACTORIZATION DATA CONTROL DIAGRAMS :I ,, I INPUT. I DATA BASE CENTRAL CONTROLLER UNIX OPERATING SYSTEM 91 OUTPUT CONTROLLER

PAGE 103

I 'I 1; "THIRD LEVEL FACTORIZATION DATA CONTROL DIAGRAMS 'I I, I FULL_COMMAND INPUT CONTROLLER i"'i I ,I I DATA BASE I .. MAIN PROCESS CONTROLLER 1 FIRST_COMMAND, FUU._COMMAND OUTPUT CONTROLLER FUNCTION PROCESS CONTROLLER MESSAGES l PROCESS SYSTEM COMMANDS UNIX COMMANDS UNIX OPERATING SYSTEM 92

PAGE 104

i I i 1: FOURTH LEVEL FACTORIZATION OF DATA CONTROL DIAGRAMS :! ,i INPUT CONTROLLER -il FUl(SmiNG, a PROCESS Ul MAIN PROCESS CONTROLLER FIRST_COMMANO, ,. DISPLAY 1 FULL COMMAND FUNCTION PROCESS CONTROLLER CHANGE MACRO OUTPUT CONTROLLER t DISPLAY MESSAGE MAIN HELP COMMANDS MESSAGE J"'uMx COMMANDS I DATA BASE i ,I ,[ 'I i I I I \ PROCESS \ SYSTEM PROCESS COMMANDS...-----..1 MIMIC UNIX OPERATING SYSTEM 93 COMMANDS

PAGE 105

i FIFTH FACTORIZATION OF DATA CONTROL DIAGRAMS ,, ,, I FIND HELP ,, I I i' I I 'I ., ARG MAIN HELP GET HELP l DISPLAY MESSAGE 94 TALK TO HELP ARG

PAGE 106

I ;j I SIXTH II I LEVEL FACTORIZATION OF DATA CONTROL DIAGRAMS MESSAGE -.. I 'I FIND HELP I II ,I I ;I 1l 1l li I 'I i I II ,. I ,I I I ,I ,J i II :I : I ,I I ,I 'I ,I : _I ARG \jl". MAIN HELP CHECK HELP TALK TO HELP INTERACTIVE HELP -\ ... GET HELP DISPLAY MESSAGE 95 I DISPLAY W ... MESSAGE

PAGE 107

I I I APPENDIX E :! PROCESS DESCRIPTIONS OF THE AMUI This contains the process descriptions I I! of the stfucture charts. The process are a description of the functions of the procedures ir the AMUI. The procedure used to develop these process descriptions is discussed in I Chapter Main Process Controller: This first calls the Input Controller procedure.ito collect the input into two strings. String1 c'ont:ains the entire command line. String2 contains the first command of the command line. St ri ng2 is checked to see if it is a macro. String2 contains a macro a file that contains the macros and their equivalent commands is searched 1or the macro i.n String2. When the macro is found the equivalent command or series of commands :is ,placed into String1 and the first command into String2. The procedure then calls the Function Process procedure with the two strings as 1: Input Conirdller: This collects the input from the keyboard places this input into String1. This string is'then searched for the first space i nd i cat i ng t'he separation of the first command from the commahd arguments. This first command is then I' copied into String2. two strings are returned to the calling procedure:. I Function :Process Controller: This ;prqcedure determines the type of process that was :ante red by the user. There are three possible of commands that the user can enter I, I 96

PAGE 108

I I I into the interface: a user interface command, a mimic command, and a UNIX operating system command. I'! I Since'the user interface must have the ability to add new commands the way in which the user interface!!'! recognizes commands must be flexible. To this the user interface commands and the mimic commands have been placed in files. If a new command then the is added to the user interface and the command is added to the file. To determine the type of command the function controllet f'irst searches the file containing the user intefface commands for the command in String2. If the is found, then the function controlle!r p,asses String1 and String2 to the Process UI Commanas procedure. A message indicating the state of the execution is returned from the Process Ul and is passed onto the output Controllet procedure to be displayed on the screen. If the cbmmand is not found in the file user interface commands, then the file contain;ing the mimic commands is searched for the command in the String2. If the command is found in this file, then the command that is associated with the command is placed in String2. Then String1 and String2 are passed to the Process Mimic Commands procedure. If th cpmmand is not found in the file the mimic commands, then String1 is passed toithe Process System Commands Procedure. the Interactive Help Utility is to be an 1ndependent program the command to call the Help Utility can be placed in the Process System Commands procedure or the Process UI Commands procedureJ I Process UI Commands: The Ul commands procedure determines the user function that is to be perfdrmed by the user The procedure looks at String2 and the corresponding procedure. String1 is passed'ito the appropriate procedure as an I' argument. If there is an error in the processing of the user command, then a message is returned i ., 97

PAGE 109

to the calling procedure that will be displayed on 11 I the screen .. I Process Commands: This :procedure converts the m1m1c command into the approbriate UNIX Operating System commands. The conversidh of the command is accomplished by the UNIX command in String2 with the first command of String1. string1 is then sent to the Process System I Commands 1procedure as an actual UNIX command to be processedi. Process System Commands: This procedure submits the UNIX system commands that the iuser typed in to the UNIX operating system for execution. This is accomplished by simply passing the icommand directly onto the operating system. i. ,i Output Controller: This 1brqcedure receives a message from calling and displays the message I screen. .I Main Help: the on the This procedure receives input from the command line, it can either be called with or without arguments:. :If the procedure is called without arguments;, then the Talk to Help procedure is called .. ff the procedure is called with arguments, then the arguments are passed onto the procedure Find for processing. II Talk to Help: This 'brocedure calls the Interactive Help procedure which returns a word typed in by the user. This word! is passed onto the Check Help procedure and the message is returned. This message is then sent: to the Display Message procedure to be d i sp 1 aye d. on the screen. This is repeated until the user types in the word 1'exit' at which time the user will end the help session. I 98

PAGE 110

I ;j ,, Interacti:ve Help: This jprocedure collects the input from the user as a word: and passes it onto the calling procedure. II Find Help: This iprocedu re takes the argument passed to it and then .:passes it onto the Check He 1 p procedure that returns the help message. The help message is then onto the Display Message procedure to be displayed' on the screen. I. Check Help: This procedure receives a word as input and converts :h .to upper case. A file is then searched tor the word to determine if there is a help message availablei for the word. The search file contains the main 'word and a group of keywords that are With the main word. If the word is a key word, then the main words that the keyword is associated with are placed in a list and returned as II a help message. I If there is a help message available for the word, then the word is passed onto the Get Help procedure]. :rhe help message is returned from the Get He 1 p :procedure and is passed onto the ca 11 i ng procedure;. Get He 1 p :1i This procedure receives a word from the calling procedu rei and then searches a f i 1 e containing he 1 p messages the word. If the word is found, then the help message is read from the file and returned to the calling procedure. I Display Message: This receives a message from the calling and displays this message on the screen. Update Macro: This receives two strings from the calling p;rocedure. The first string contains the macro to be added and the second string contains the command that is associated with the macro. 99

PAGE 111

i I The macro file is first searched for the new macro to ensure that there will not be a duplicate macro added to the file. If the macro exists in the file, error code is returned to the calling If the macro does not exist in the file then firt and the second string are added to the macro'' file. ;I Menu Driven Input Processor: This11procedure first displays the level 1 menu on the screen. The level 1 menu gives the user five options. r!The five options are: 1. System Utilities. 2. File.fut'ilities. 3. Tools. 4. Line. 5. Exit!: The Operating System Utilities are UNIX commands perform functions on.the operating system. th File Utilities are UNIX commands that perform on files. The Tools are commands that allow the user to perform other actions. The Command Ljne is the direct input of the user commands .into the command line. The Exit is the termination of the user interface. The System Utilities menu contains five options. The five options are: 1. History. 2. Acti've Jobs. 3. Chanige ,Directory. 4. Make: Di.rectory. 5. Directory. The 'File Utilities menu contains four options. The four bptions are: 1: Lisfi Files. 2 Copy i F i1l es. 3. Move F ;. 1 es. 4. Remo.ve 1Fi 1 e. The tools menu contains four options. The four options 1. Display Files. 2. Change 'Password. 3. He 1 P1 4. VI Ed ito r. 'I Wheri' the user selects an option from the second level menus ,the associated UNIX command is placed in 100

PAGE 112

i i ,, the FULL_CMD. If the command requires additional information from the user like a file name then'1 the user interface processor indicates to the user information is needed. The additional informati:on ';s concatenatedto the string FULL_CMD. The first; word in the string FULL_CMD is then .copied into the iSt ring FIRST _CMD. The strings FULL_CMD and FIRST_CMD' are then returned to the calling 1 01

PAGE 113

' I I I :I APPENDIX F I LEVEL 2 PSEUDOCODE OF THE AMUI This contains Level 2 pseudocode of the AMUI nd the interactive help programs. The [ 'II format in the pseudocodes is discussed in Chapter : The used in the pseudocode is I present edi for reference. [I PSEUDOCODE TERMINOLOGY I I Procedure :calling with arguments: I CALL WITH arguments; I Reading input device: READ name> INTO ; INTO ; [ Printing to butput device: WRITE TO ,