Citation
A method of design for adaptable/modular user interfaces

Material Information

Title:
A method of design for adaptable/modular user interfaces
Creator:
Tyler, Lyle Richard
Publication Date:
Language:
English
Physical Description:
xi, 140 leaves : illustrations ; 29 cm

Subjects

Subjects / Keywords:
Computer interfaces -- Mathematical models ( lcsh )
Computer interfaces -- Mathematical models ( fast )
Genre:
bibliography ( marcgt )
theses ( marcgt )
non-fiction ( marcgt )

Notes

Bibliography:
Includes bibliographical references.
General Note:
Submitted in partial fulfillment of the requirements for the degree, Master of Science, Electrical Engineering.
Statement of Responsibility:
by Lyle Richard Tyler.

Record Information

Source Institution:
University of Colorado Denver
Holding Location:
Auraria Library
Rights Management:
All applicable rights reserved by the source institution and holding location.
Resource Identifier:
28557875 ( OCLC )
ocm28557875
Classification:
LD1190.E54 1992m .T84 ( lcc )

Downloads

This item is only available as the following downloads:


Full Text

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 , ; I WRITE , ; I i Sett1ng value of a variable: SET name> TO ; ., Loops: I WHILE clause> DO; ENDWHILE; ,i DO; WHILE ; DO; UNTIL ; I 102 I ol

PAGE 114

Conditional r: IF THEN; ENDIF; .,J USER INTERFACE PSEUDOCODE: Procedure) FUNCTION BEGIN; I SET searchpar TO 0; .cmd FOR reading; READF I LE; i amiJ i cmd INTO cmd; WHILE ( cmd END OF FILE) AND (searchpar 1) IF cmd:1= first_prt THEN SET searchpar TO 1; ENDIF;!I READFILE amui.cmd INTO cmd; ENDWHILE;:. CLOSEFILE amui.cmd; IF searchpar = 1 THEN ,, CALL PROCEDURE ui_cmd WITH full_prt, first_prt, : message; IF done THEN CALL PROCEDURE output WITH message; ENDIF :/ ELSE .: OPENFIUE mimic.cmd FOR reading; READFIUE mimic.cmd INTO cmd; WHILE (cmd .END OF FILE) AND (searchpar 2) DO mimic.cmd INTO mimic; IF cmd = first prt THEN SET searchpar TO 2 ENDIF READFILE mimic.cmd INTO mimic; ENDWHIUE; CLOSEFILE mimic.cmd; IF = 2 .THEN CALL:!PROCEDURE mimic cmd WITH full prt,mimic; 1'1 ELSE CALLiPROCEDURE system_cmd WITH full_prt; ENDIF; i ENDIF; END; 103 I'

PAGE 115

. I i ; I INPUT BEGIN :: SET i TOIO; DO WRITE : to 'screen, "c: \"; READ INTO full_st r; WHILE LSNGTH OF STRING full str = 0; 'I -WHILE (full str[i] ') AND (full str[i] 'I' '\0') I' DO SET i TO i + 1; IF i = i LENGTH OF STRING full str THEN SET TO full_str; ELSE i SET '!f i r]St_st r TO FIRST i CHARACTERS OF full_st r; ENDIF : ENDWHILE: END; 1 1 MACRO BEGIN i/ FOR reading; DO 'i READFILE :macros INTO amui cmd; 11 I -WHILE END OF FILE AND first_str[O] macro; IF amui = END OF FILE THEN SET ffrst str TO "not found" ELSE SET tirst_str TO amui_cmd; SET temp TO amui_cmd; SET TO temp + "; SET TO temp+ &full_str[1]; SET full str TO temp; !I ENDIF I CLOSEFILE macro; END; 11 I Procedure: MAIN BEGIN DO CALL input WITH full_cmd, first_cmd; IF first....:.cmd "exit" THEN IF > 0) AND (first_cmd[O] < 27) THE: N I 104

PAGE 116

I I 0 I CALL PROCEDURE macro WITH full_cmd,first_cmd; END IF CALL PROCEDURE function WITH full_cmd, first_cmd; ENDIF WHILE fist_cmd "exit"; END; Procedure: MIMIC_CMD BEGIN :: SET i TO.O; SET n TOiO; WHILE full_string[i] '# AND full_string[i] DO SET i 71"0 i + 1; ENDWHI LE; i IF i = LENGTH OF STRING full string THEN SET new_cmd TO string; ELSE SET SET SET SET END IF n,TO LENGTH OF STRING string; new_cmd TO string; new cmd[n] TO' -' &new_cmd[n+1] TO &full_string[i+1]; CALL PROCEDURE system_cmd WITH new_cmd; END; Procedure: NEWMAC BEGIN OPENFILE macros FOR reading/writing; DO READFILE, macros INTO macro,temp; UNTIL = END OF FILE OR macro = new_macro; IF macro = END OF FILE THEN WRITEFILE macro, new_macro,new_command; RETURN (1); ELSE RETURN ( 0); ENDIF; END; Procedure,: OUTPUT BEGIN SET count TO 0; SET n TO 0; 105

PAGE 117

,, 1: i WHILE message[count] "/*" DO SET n LENGTH OF STRING message[count]; IF = THEN SET TO '/0'; ENDIF ; I WRITE screen, message[count]; I SET TO count+ 1; ENDWHI LE'; END; Procedure: SYSTEM_CMD 'I BEGIN :, CALL SYS:TEM un i x_cmd; END; UI_CMD BEGIN II IF string = "ddir" THEN SET msg[O.] TO "This command has not been implemented yet"; SET msg[1] TO"/*"; ENDIF ;I ,[ IF st ri n:g = "newmac" THEN SET ms,g [0] TO "This command has not been :! 1 implemented yet"; SET ms.g[1] TO"/*"; ENDIF; END; HELP UTIUiTY PSEUDOCODE: ., CHECK HELP BEGIN SET TO 0; SET couht 'TO 0; CALL PROCEDURE cnvt_upcase WITH arg; OPENFIL:E "cmmnd.hlp" FOR reading; cmmnd.hlp INTO word; WHILE w:ord1 END OF FILE AND searchpar 1 DO IF ar;g =: word THEN SET'searchpar TO 1; READFILE cmmnd.hlp INTO nextword; WHiLE nextword "/*" DO IF 'next word = arg THEN 106

PAGE 118

.. : I SET searchpar TO 2; c!_string[count] = word; SET count TO count +1; END IF :READFILE cmmnd.hlp INTO next_word; ENDWHILE; I ENOl F:i ; cmmnd.hlp INTO word; ENDWHILE; CLOSEFI'LE cmmnd.hlp; IF sear.chpar = 0 THEN = "No HELP available"; d_ s t r 1 n g [ 1 l = "I* ; ELSE tF searchpar =1 THEN : CALL PROCEDURE get_help WITH arg,d_string; ELSE IF searchpar = 2 THEN 1 d string[count] = "/*"; ENDIF END IF ENDIF; 1 END; i I Procedu re: CNVT _UPCASE BEGIN ,[ SET c TO 0; SET n Tp LENGTH OF STRING wrd; FOR c FROM 0 TO n BY 1 SET temp[c] TO TOUPPER(wrd[c]); I' ENDFOR;: SET wrd1 TO temp; SET wrd[n] TO '\0'; END; i ,I DSP _MSG BEGIN SET count TO 0; SET n To 0; I WHILE "/*" DO SET n : TO LENGTH OF STRING mesS4Qe[count]; IF = '\n' THEN SET: message[count][n-1] TO '\0'; ENOl F;i TO screen WITH message[count]; SET count TO count + 1 ; ENDWHIL!E 107

PAGE 119

END; Procedure: FIND_HELP I BEGIN [ 1 CALL PROCEDURE check_help WITH arg,msg; CALL dsp msg WITH msg; END; I I Procedure,': GET_HELP BEGIN SET coJnt TO 0; OPENFIUE amui.hlp FOR reading; READFIUE amui.hlp INTO temp; WHILE t !!3mP. END OF FILE AND cmmnd temp DO DO READFILE amui.hlp INTO temp; WHILE;: temp "/*" READFILE amui/hlp INTO temp; ENDWHILE; ,, IF temp= cmmnd THEN READFiLE amui.hlp INTO in_string; WHILEi in_string and in_string "/*\n" DO SET, hip[count] TO in string; SETj cqunt TO count +-1; amui .hlp INTO instring; ENDWH'I LE SET hhp[count] TO "/*"; ENDIF CLOSEFILE 'amui.hlp; END; : I INTERACT_HELP BEGIN DO j 'I I WRITE: TO screen WITH "\nHELP>"; READ .keyboard INTO request; WHILE LENGTH OF STRING request = 0; END I Procedure! : MAIN BEGIN IF argc:;: = 11 THEN CALL 'PROCEDURE talk_to_help WITH ; ELSE CALL 'PROCEDURE find_help WITH argv[1]; 108

PAGE 120

END IF END; ,i .! Procedure1 : TALK_TO_HELP BEGIN CALL get help WITH "HELP",msg; CALL PROCEDURE dsp-msg WITH msg; I CALL PROCEDURE interact help WITH argument; WHILE "exit"-AND argument "EXIT" DO CALL :PROCEDURE check_he 1 p WITH argument, msg; CALL dsp msg WITH msg; CALL !PROCEDURE interact_help WITH argument; ENDWHILE; END; I i MENU INPUT CONTROLLER PSEUDOCODE: ,., ,, FILE_UTIL(string) BEGIN ; WRITE TO screen, "1. List files\n2. Copy file\n3. Move file\n4. Remove file\n"; WRITE ro screen, "Enter number:"); READ INTO ch3; IF ch3 k 1. THEN SET TO "ls"; ELSE IF ch3 = 2 THEN ,, I BEGlN WRITE TO screen, "Enter the file name.\n"; i! CALL PROCEDURE get input WITH temp; SET string To "cp -;;-; I APPEND temp TO string; APPEND TO string; WRITE TOscreen, "Enter the target name.\n"; CALL ,PROCEDURE get_input WITH temp; APPEND temp TO string; END;, ELSE F = 3 THEN BEGIN WRITE TO screen, "Enter file name.\n"; 'CALL PROCEDURE get_input WITH temp; SET string To "mv "; temp TO string; APPEND TO string; ,WRITE TO screen, "Enter the target I \ name. n ; 109

PAGE 121

! I PROCEDURE get_input WITH temp; temp TO string; EN'D I t IF ch3 = 4 THEN BEGIN TO screen, "Enter file name.\n"; tALL PROCEDURE get_input WITH temp; SET string To "rm "; APPEND temp TO string; ,,, ENO; ENDI. F; ENDIFI ; ENDIF; : ENDIF : : END; Procedure: GET_INPUT(word) BEGIN DO i BEGIN 1 WRITF screen, "Input:"; READJ keyboard INTO word; END : I WHILE LENGTH OF STRING = 0; END; 'I I Procedure: MENU_INPUT(full_str,first_str) BEGIN i SET i T:9 WRITE T : O 0; screen,"\n1. Operating System Utilities\n2. File Utilities\n3. Tools\n4. Command Line\n5. Exit\n"; WRITE Tb number:"; READ INTO ch1; IF ch1 1 THEN CALL; os_util WITH full_str; ELSE tF Ch1 = 2 THEN PROCEDURE file_util WITH full_str; ELSE : IF ch1 = 3 THEN CALL PROCEDURE tools WITH full_str; IF ch1 = 4 THEN CALL PROCEDURE get input WITH full_str; ELSE IF ch1 = 5 THEN;SET full str TO "exit"; 110

PAGE 122

. .; ,, I I I .I I 'i, ENqiF; ENDI: F; ENOl F ; ENDIF;: I ENDIF; : i WHILE ( .1full_str[i] :t:' ')AND (full_str '\0') DO SET i i TO i + 1 ; ENDWHILE; lF (i OF STRING(full_str)) THEN SET TO full_str; ELSE !1 SET :first str TO FIRST i CHARACTERS OF irull_str; ENDIF I END; '1 I OS_UTIL(word) BEGIN I WRITE tp screen, "\n1. Command History\n2. Active : 1 Jobs\n3. Change Di rectory\n4. i Make Directory\n5. Remove i I Di rectory\n"; WRITE to screen, "Enter number:"; READ keyboard INTO ch2; IF ch2 b 1 THEN SET TO "history"; ELSE ch2 = 2 THEN SE"PI wqrd TO "jobs"; IF ch2 = 3 THEN BEGIN ;wRITE TO screen, "Enter directory name.\n"; t I PROCEDURE get_1nput WITH temp; SET word TO "cd APPEND temp TO word; ELSE IF ch2 = 4 THEN BEGiN ::WRITE TO screen, "Enter directory ,. \ .. ; name. n ; ]CALL PROCEDURE get_input WITH temp; ; SET word TO "mkdi r "; temp TO word; END ELSE IF ch2 = 5 THEN BEGIN : I I I 111

PAGE 123

:iwRITE TO screen, "Enter directory 1 name.\n"; [ CALL PROCEDURE get_input WITH temp; 1j SET word TO "rmdi r "; ,1APPEND temp TO word; I ENIDIF I, ENDIF; ENDI.f::; ENDIF;:1 ENDIF; 1 END; I I TOOLS(str) BEGIN WRITE n) screen, "1 Di sp 1 ay f i 1 es\n2. Change password\n3. Help\n4. VI Editor\n"; READ INTO ch4; IF ch4 1 THEN BEGINI[ WRI1TE :TO screen, "Ente r file name.\n"; CALt PROCEDURE get_input WITH temp; SET I st.r To "cat "; APP,END, temp TO st r; END; ;J I ELSE It ch4 = 2 THEN SET r' TO "passwd"; ELSE IF ch4 = 3 THEN SET!I str TO "help"; ELSE! IF ch4 = 4 THEN sE :GIN RITE TO screen, "Enter file name.\n"; I' PROCEDURE get_input WITH temp; SET str To "vi 1'. +PPEND temp TO str; EN.D; ENDIF.; I ENDIF;:! ENDIF; I END; : 1 I ,I I I I I ,, ,! 112 I :1 I J I

PAGE 124

APPENDIX G .I DATA DICTIONARY OF THE AMUI This appendix contains the data dictionary for I the AMUI the interactive help utility. The procedure used to develop this data dictionary is discussedr in Chapter 4. i DATA DICtiONARY FOR USER INTERFACE: ,' NAME: !: amui_cmd ALIASES: ; NONE WHERE USED/HOW USED: change_macro (input) QESCRIPTION: amui_cmd = array of characters 1 characters= Z] I' NAME: c ALIASES: il NONE WHERE USEp/HOW USED: change_macro (input) DESCRIPTlpN: c = [-32768 -1 :o:1 .. 32767] NAME: cmd ALIASES: :: NONE WHERE USED/HOW USED: function controller (input) :1 DESCRIPTION: cmd = array of characters : characters= [a .. z:A .. Z] 'I NAME: 1 i rst_cmd first_str,first_prt,string, WHERE USED/HOW USED: main (internal) input_controller (input) change_macro (internal) function_controller (internal) process_ui_cmd (internal) process_mimic_cmd (internal) I first_cmd =string of characters characters= [a .. z:A .. Z] I ,i NAME: 1 fpt r ALIASES: f pt r2 WHERE USEP/HOW USED: change_macro (input) function controller (input) '[. 113

PAGE 125

'I i ,I DESCRIPTI:ON: fptr = pointer pointer= [0 .. 65536] NAME: full cmd ALIASES: rrull=st r, full_prt, full_st ring, uni x_cmd WHERE USED/HOW USED: main (internal) .: input_controller (output) I I :i change_macro (internal) function_controller (internal) process_ui_cmd (internal) process_mimic_cmd (internal) process_system_cmd (output) I; full_cmd =array of characters NAME: i ALIASES: :; count WHERE USEP/HOW USED: input_controller (internal) '!I process_mimic_cmd (internal) DESCRIPT!bN: i=[-32768 .. -1 :o:1 32767] I NAME: ; LENGTH II ALIASES: 1 NONE WHERE USED/HOW USED: i DESCRIPTION: LENGTH I NAME: LINES ALIASES: ; NONE process_ui_cmd (constant) function_controller (constant) output_controller (constant) = 81 WHERE USED/HOW USED: function controller (constant) DESCRIPTiipN: LINES=75 NAME: : ALIASES: NONE WHERE USED/HOW USED: change_macro (input) MACRO = [-32768 .. -1 :o: 1 .. 32767] I NAME: message ALIASES: msg WHERE USED: function_controller (internal) process_ui_cmd (internal) output_controller (output) DESCRIPTION: I message = double array of characters characters= [a .. z:A .. Z] 114

PAGE 126

NAME : I m:i m i c ALIASES: i: NONE WHERE USEID/HOW USED: function_controller (input) DESCRIPTION: mimic= array of characters characters = [a .. z: A .. Z] I NAME: '[ n ALIASES: il NONE WHERE USED/HOW USED: process_mimic_cmd (internal) 'i output_controller (internal) DESCRIPTI0N:' n = [-32768 .. -1 :o: 1 .. 32767] 'I NAME: i l new cmd ALIASES: :1 NONE WHERE USED/HOW USED: process_mimic_cmd ,, DESCRIPTION:, new_cmd = array of characters : 1 characters= [a .. z:A .. Z] I NAME: :1 P1ROMPT ALIASES: : N,ONE WHERE USEJ]>/HOW USED: input_controller (constant) DESCRIPTI0N :' PROMPT="\nc: \>" i[ NAME: 1[ s:EARCHPAR ALIASES: l: NONE WHERE USEID/H'OW USED: function controller (internal) DESCRIPTION: SEARCHPAR = [-32l68 .. -1 :o:1 .. 32767] I i Name : I TEMP ALIASES: !I NONE WHERE USEID/HOW USED: change macro (internal) DESCRIPTI0N: TEMP = array of characters i characters= [a .. z:A .. Z] I I DATA DICTIONARY OF HELP UTILITY. ii NAME: ,[ a:rgc ALIASES: i[ NONE WHERE USED/HOW USED: main (input) t DESCRIPTION: argc = [-32768 .. -1 :o:1 .. 32767] I i,l NAME: [' argument ALIASES: :. airg, request ,cmmnd WHERE USEID/HOW USED: talk_to_help (internal) interact_help (input) I 115

PAGE 127

, DESCRIPTION: check_help (internal) get_help (internal) argument = array of characters characters= [a .. z:A .. Z] NAME: argv ALIASES: arg WHERE USED/HOW USED: main (input) find_help (internal) DESCRIPTION: argv = array of pointers pointer= [0 .. 65536] NAME: count ALIASES: j c WHERE USED/HOW USED: check_help (internal) cnvt_upcase (internal) DESCRIPTlbN: count = [-32768 .. -1 :o:1 32767] NAME: I fpt r ALIASES: NONE WHERE USED/HOW USED: check_help (input) .[ get_help (input) DESCRIPTION: fptr = pointer ; pointer= [0 .. 65536] NAME: in_string ALIASES: I NONE WHERE USED/HOW USED: check_help (input) : get_he 1 p (input) DESCRIPTION: in_string = array of characters characters= [a .. z:A .. Z] NAME: LENGTH ALIASES: NONE WHERE USED/HOW USED: talk_to_help (i.nternal) check_help (internal) find_help (internal) dsp_msg (internal) DESCRIPTION: LENGTH = 81 ,r NAME: LINES ALIASES: .l NONE WHERE USED/HOW USED: talk_to_help (internal) 1 find_help (internal) DESCRIPTION: LINES = 75 116

PAGE 128

.I ,I I :i I, NAME: 'i msg ALIASES: i message,hlp,d_string WHERE USED/HOW USED: talk_to_help (internal) [ get_help (internal) dsp_msg (output) : 1 check_help (internal) DESCRIPTION: msg = array of strings string = array of characters characters= [a .. z:A .. Z] NAME: I n I ALIASES: NONE WHERE USED/HOW USED: cnvt_upcase (internal) ., .,, dsp_msg (internal) n = [-32768 .. -1 :o:1 .. 32767] I I NAME : :! PROMPT ALIASES: ': NONE WHERE USED/HOW USED: interact_help (output) DESCRIPTIIbN :' PROMPT = "\nHELP>" i NAME: ,;J ALIASES: 1 NONE II WHERE USED/HOW USED: check help (internal) t1 DESCRIPTION: searchpar =[-32768 .. -1 :o:1 32767] NAME: .1 temp ALIASES: ;i NONE WHERE USED/HOW USED: cnvt upcase (internal) temp = characters characters= [a .. z:A .. Z] NAME: : word ALIASES: [ nE!Xt_word, temp .. WHERE USED/HOW USED: check_help (input) get_help (input) DESCRIPTI9N: word = array of characters characters= [a .. z:A .. Z] 117

PAGE 129

:! i I II I I i APPENDIX H INTERFACE MATRIX OF THE AMUI appendix contains the interface matrix for the AMUI '!and the interactive help utility. The 11: ., lj procedure; used to develop this interface matrix is 'I .I discussed! i'l Chapter 5. '!I 'I TO CHANGE FUNCTION INPUT FROM 'I MACRO CONTROLLER CONTROLLER CHANGE :! N/A N/A N/A ,, MACRO I I FUNCTION! N/A N/A N/A CONTROLL:.!ER INPUT N/A N/A N/A MAIN ,.1 FULL_CMD FULL_CMD N/A I I FIRST CMD FIRST CMD OUTPUT N/A N/A N/A CONTROLll.;ER 'I PROCESS:' N/A N/A N/A MIMIC I I COMMAND$; PROCESS! N/A N/A N/A SYSTEM ,. COMMANDS, PROCEssi'ui' N/A MSG N/A I COMMAND$ ,I .i 118

PAGE 130

:! TQ MAIN OUTPUT PROCESS FROM li CONTROLLER MIMIC CMOS CHANGE !I FULL_STR N/A N/A MACRO FIRST STR I' N/A MESSAGE FULL_PRT CONTROL4.ER FIRST PRT INPUT I, FULL_STR N/A N/A CONTROLI..:ER FIRST STR MAIN 'II N/A N/A N/A :r I, I' OUTPUT I N/A N/A CONTROLLER I N/A N/A PROCESS : N/A MIMIC :I COMMANDS PROCESS ; N/A N/A N/A SYSTEM ,, I COMMANDS! I PROCESS UI N/A N/A N/A I COMMANDS: 119 li I

PAGE 131

I :I TO PROCESS PROCESS UI FROM SYSTEM CMOS COMMANDS CHANGE I N/A N/A MACRO j FUNCTION FULL_PRT FULL_PRT FIRST_PRT INPUT N/A N/A CONTROLLER 'I MAIN i N/A N/A 'I I OUTPUT ,1! N/A N/A I CONTROLEER: PROCESS .i NEW_CMD N/A MIMIC il I COMMAND PROCESS I] II N/A N/A SYSTEM 1 COMMANDS: I il PROCESS ;i!JI N/A N/A COMMAND$; '! I ,I 120 ,!

PAGE 132

II :I 1: ., i APPENDIX I ANSI C CODE OF THE AMUI /* This i:s the AMUI written in ANSI C. The following procedures are the procedures used in thai example user interface.*/ #include 'I #define PFWMPT "\nc:\>" #define LINES 75 #define 81 ,. void inpJt_controller(); void change_macro(); i nt updat']e_macro(); void fundtion_controller(); void ck_cmd(); void em_cmd (); void void main() I* main control 1 procedure/ { : } statib char full_cmd[81],first_cmd[14]; I two communication vairables */ do { I input from user ! [check if user entered "exit" *I if Jstrcmp(first_cmd,"exit") !=0) { check if user entered macro command *I I if ((tirst_cmd[O] > 0) && (first_cmd[6] < 27)) ;, tf macro .command then change to UNIX command *I Change_macro(full_cmd, fi rst_cmd); I user input */ fun'ct i'on_cont ro 11 er ( fu ll_cmd, f i rst_cmd); } I } ,] I input from user until "exit" *I while: (s.trcmp(first_cmd, "exit") :I I 121 user enters 1-0) -.

PAGE 133

,! 1.: : I void I This is the procedure that controls all the input between the user and the user interface I ; char fulllstr[]; char } { : i nt: i ; ,, i =O:; do 1 { printf( "%s" ,PROMPT); I/* get input string from the user */ gets(full_str); } I* .;ignore .any returns on an empty 1 ine I I I F i 11 d t he f i r s t o c c u ran c e of a space T h i s space is the separation point between the tirst command and the rest of the string */ whit:le.((full str[i] !=' ') && (full str[i] != I' = i + 1; /*count how many characters there :I are before the space *I if Hi==strlen(full_str)) I* ::if the command is the only thing in the string copy it to the variable first str */ I -:.st r;cpy( fi rst_st r, full_st r); else { I I* first command to variable first str and append the null character*/ .strncpy(first_str,full_str, i ); tirst_str[i]='\0'; } void I* This ;:s the procedure that changes the macro commands :1int,o the UNIX commands */ char ful,Lstr[]; char first_str[]; { I FILE *Ipt r; char temp[81],amui_cmd[14]; 122

PAGE 134

} il I
PAGE 135

} II 'I of file is reached/* '[ i if !(strcmp(cmd,first_prt)==O) { command is found in file */ ; } 'I I* c l'ose f i 1 e *I I fcl os;e( f.pt r); } !i if (searchpar == 1) { ,j : I* is a user interface command */ I* if process accomplished the function without incident. If a problem occured the returned message to the user *I if (s1trc'mp(message[O], "done") != 0) oulput_controller(message); .I II } else { I* ;file that contains the mimic commands */ if ((.fpt'r2=fopen("mimick.cmd","r")) !=NULL) } { i[ whiile(l(fscanf(fptr2,"%s",cmd)!= EOF) && !: ( searchpar = 2)) { :1 /:I sc,an f i 1 e unt i 1 command is found or unt i 1 lithe end of the file is reached */ :1 fscanf(fptr2, "%s" ,mimick); :, if' ( st rcmp( cmd, f i rst_prt )==0) 'i searchpar=2; } ;[ ; I* file */ I, ( fclose fptr2); I } I i if == 2) I* :if command was found it was a m1m1 c command *l else .i I* Oth:arwise the command is a UNIX command */ probess_system_cmd(full_prt); I I 124 :I

PAGE 136

'I :I 'I I 'i ,, .I void I* This processes the commands that t6 the user interface. *I char full: string[]; char strirng[]; char msgq][LENGTH]; { ,, if (stlrcmp(string,"ddir") == O) { i command has not been imp 1 ement1ed yet ) ; s t p y ( ms g [ 1 ] "1 ) ; } if (stlrcmp(string,"newmac") -0) { :, command has not been imp 1 ementied: yet"); st r;cpy ( msg [ 1 J "I ") ; I } } 'I i :I void are I* This converts the mimic commands into associ1ated UNIX command and then calls the process_system_cmd *I char char s t r i In g [ ] ; { 'i char cmd[SO]; i nt i 'n!;-i=O; the n=O ,, I* pbsition of first occurance.of a space *I while C[(full_string[i] !=' ') && ( full_string[i] '!='\0')) i =i +11; i f ( i =:= s t r 1 en ( f u 1 l_s t r i n g ) ) I* If mimic command is the only word in the stri:ng replace it with the UNIX command *I cmd,string); I -else { 'i I* Otiherwise replace the m1m1c command at the of the string with the UNIX command :: */ ,I i I 125

PAGE 137

} ,, ti !I I I I n=st rl'!l en (string); st rq)'y ( new_cmd I string); neW Cmd[n]:' I -I' J st ( &new_cmd [ n+1 ] &fu ll_st ring [ i + 1 ] ) ; } i I I* pass the new command string .onto pro:ess_syst em_cmd *I processLsystem_cmd(new_cmd); I I the procedure void proc!es!?_syst em_cmd ( un i x_cmd) I* This passes the UNIX commands onto the operaiHng system to be processed *I char unixLcmd[]; { 'i } I* command onto operating system I cmd); I I .j! void I* This is the procedure that controls all the outpu(i interaction between the user and the user interf,ace */ 'I char [][LENGTH]; { ji tnt count1n; 'II i count=Oi; n=o; I I exists as an array of strings*/ while (strcmp(message[count],"I*")!=O) { : } I* length of message string/ if (message[count][n-1] == '\n') I* if: the messag_e string terminates in a return replace the return will the null character I I message[count][n-1]=1\0'; I* message string on the screen I putsCmessage[count]); 'I I* dtsplay next message I count:Fcount+1; t'b the new command NEWMAC for the user written in ANSI C. *I ,, 1! I "' 126

PAGE 138

I I II i nt new_command) I* This iils the new command procedure that is added to the user interface as discussed in the paper. This pr:;ocedure allows the user to add a new macro command user interface macro file. */ int new_macro; char []; { 'I FH.iE *fpt r I' cha'r temp[14]; macro,c; :open fi 1 e *I "a"); do 1 to see if macro already exists in the macro f i 1 e I :: c=fscanf(fptr, "%d %s" ,macro, temp); != EOF) && (new_macro !=macro)); EOF) :1 If the end of the file was reached I before the command was found then the i macro command is a new macro command. I Put the new macro command into the 'I file./ 1fpri nt f ( fpt r, "%d %s "., new_macro, I new_ command); a 1 to indicate that the command : was succefuly placed in the file */ (1); } :1 e 1 s!e !V return a -1 to indicate that the macro :[ :command already exists in the file */ :return (-1); } II ,. I* The procedures are the new input procedure for the user interface in ANSI C *I "I void I* This p;rocedure controls the input interaction between the user and the user interface */ char fulilsir[]; char { !: I 'I I 'I ,I 127

PAGE 139

} I ,I i I I d i int1ch1,i; -or. .' /;Display the level one menu I pr;:htf("\n1. Operating System Utilities\n2. :i File Utilities\n3. Tools\n4. Command i1 Line\n5. Exit\n"); prfhtf("Enter number:"); I* selection from the user */ scanf("%d" &ch1) I I J f I* .icheck the selection *I swi:t ch ( ch1 ) { } case 1: il os_ut i 1( full_st r); 'I break I case 2: :: file_util(full_str); break; case 3: tools(full_str); :! break; case 4: i.i get input(full str); i break; qase 5: :' strcpy(full str,"exit"); 1ibr.eak; I* ,separate the first word in the string and ,place it into the variable first str *I whi}e ((full_str[i] !=' ') && (full_str[i] != i '\0')) i = i + 1; ,I if :(i==strlen(full str)) 1 st.rcpy(first_str,full_st.r); el se { I i); .first_str[i]='\0'; } I void os Util(word) I* Thisiis the menu input procedure for the commands that w'ork on the operating system *I char word[]; II 'I I. I i ,,, ,, 128

PAGE 140

{ } I int char temp[81]; I* level two menu *I Command History\n2o Active Jobs\n3o 1; Change Di rectory\n4 o Make Di rectory\n5 o I Remove Di rectory\n"); number:"); -I* get user selection *I scanf (; "%d", &ch2); *I user selection *I switch(ch2) { 'I .i } case 1: st rcpy(word, "hi story"); break; ciise 1 2: :1 strcpy(word,"jobs"); 1 break; case 3: I I printf("Enter directory nameo\n"); 1 get_input(temp); 1 : s.trcpy(word,"cd "); I I ll break; case 4: 'I directory name.\n"); .: get_,nput(temp); !j st rcpy( word, "mkdi r "); I strcat(word,temp); li break; dise 5: I printf("Enter directory nameo\n"); !1 get_input(temp); '' st rcpy(word, "rmd.fr "); strcat(word,temp); 1! break I li void file_util(string) I This the menu input procedure for the commands that work on files *I I char s t r ;In g [ ] ; { ;, int sh3; I I I I il i [ 129

PAGE 141

' I char :!t:emp[81]; I* level two menu I List files\n2. Copy file\n3. Move i fi le\n4. Remove fi le\n"); print;rf( "Enter number:"); I* user selection *I scanf{"%d",&ch3); I* user selection *I switdh(ch3) { :! 1: ; i strcpy(string,"ls"); H bneak; case 2: :I p r i n t f ( En t e r t he f i 1 e name \ n ) ; : 1 get_input(temp); strcpy(string,"cp "); :: strcat(string,temp); J strcat(string,'' "); : i p r ; n t f ( En t e r t he t a r get name \ n ) ; :1 get_input(temp); ; 1 s t rca t ( s t r i n g t em p ) ; 11 break; case 3: printf( "Enter file name. \n"); :: get_ input (temp); :, strcpy(string,"mv "); i strcat(string,temp); :: strcat(string," "); :i printf( "Enter the target name. \n"); :il : strcat(string,temp); ': break; c 'ase 4: :j printf("Enter file name.\n"); get_ input (temp); 1 strcpy(string,"rm "); : st.rcat ( string, temp); ,:break; } !i } I I void too ( st r) I* This the menu input procedure for the commands that the user to perform functions */ char st r ; I I 130

PAGE 142

I' 'I i I I { "I } i nt ich4; temp[81]; I* the level two menu *I Display files\n2. Change :: password\n3. Help\n4. VI priritf("Enter number:"); I* selection from the user *I scanif ( "%d", &ch4); I* dheck the selection of the user I* swi 1i:ch ( ch4) { : case 1 I I 'printf("Enter file name.\n"); :;get_ input (temp); S t r c p y ( s t r cat ) ; ''1st rcat ( st r, temp); .:1break I I cas.e 2: break; cas:e 3: break; I cas1e 4: 1printf("Enter file name.\n"); input (temp); } 1st r c p y ( s t r v i ) ; rcat ( st r, temp); break; I ,i void I* This collects *I :1 the input from the user char word I[]; { i char .j:lummy; I* empty buffer *I dummy!= getchar(); do '1 { I* get user input *I printf("Input:"); gets(word); 'i 131

PAGE 143

:j II I ,I } 1l .'1 1 ![ while(strlen(word)==O); II } I' I* This is the HELP Utility program for the example user written in ANSI c. The fdllowing procedures are the procedures in HELP Utility for the example user *I #i ncl ude.!i[ #include' #define RROMPT "\nHELP>" #define LINES 75 #define LENGTH 81 I void interact_help(); void void check_help(); void dsp_lmsg(); void find_help(); void void i main(argc,argv) I This is the main controlling procedure for the HELP This procedure collects ihput directly' from the command line. *I int argc;; I* this variable indicates how many 1 ; arguments are in the command line *I char I this variable. contains the { } :! arguments in the command line I i[ i f Uirgc == 1 ) I* If there is only one argument in the line indicates that the user wants an tp the HELP Utility. I t k_to_he 1 p(); else:. I* If there is more then one argument in the command line then find the help associated w1:th the word f1:nd_help(argv[1]); i, void talk_to_help() I* This procedure is the input procedure that 'I 132

PAGE 144

I ti I ,, :I II I .I contrdls all the interaction between the user and the HELP Utility */ { II char .:1argument [81]; } char '1msg [LINES] [LENGTH]; I* the message that explains how the HELP ub 1 it y operates I* p( "HELP" ,msg); I* Display the message *I I* gt input from the user *I I* to see if user wants to leave the HELP Ut!i 1 ity *I ((strcmp(argument,"exit") != 0) && 1i ( st rcmp( argument," EXIT") = 0)) { ,, user doesn't want to leave the HELP get the help message and display lit and continue to get input from the user. :, *I } ,I void chectk_help(arg,d_string) I* This checks the input from the user a file that contains key words that are with UNIX commands. *I char arg[i] [LENGTH]; { FILE +fptr; char :word[20],next_word[20],in_string[80]; int search_par=O; count'=o ,, I* convert all inputs to upper case *I ''I I* file *I fptr:.fopen( "cmmnd.hlp", "r"); while, ((fscanf(fptr,"%s",word) != EOF) && { 1 ( search_par = 1 ) ) i .I 1 ': 133

PAGE 145

} I 'I I I* file until word is found or until file is reached */ if :1 ( st rcmp( arg, word )==0) f/* word is a command */ ;.:search_par=1 ; el$e { i search the list of associated key words I' I I ( fpt r, "%s", next_word); le(strcmp(next_word, "/*") !=0) t :i } I* add word to list of commands */ Search par=2; 'st rcpy( d_st ring [count], word); 'count=count+1; I I read next word from file */ 1 fscanf(fptr,"%s",next_word); ll } I' } : I* file */ f c 1 ( f pt r) ; if ( { ,1 I* was not found in file */ HELP available"); st ( d_st ring [ 1 ] "I*" ) ; } else r if (search_par==1) I* word is command, get message for the command */ I get_help(arg,d_string); I 1i e 1 se if ( search_par==2) i I I ,i I ,I I* word is a key word, return list of associated commands to key word */ strcpy(d_string[count],"/*"); void cnvtlupcase(wrd) I* This converts the word to upper case /* I I I : I 134

PAGE 146

,I char wrdh; { ifi } char i nt c 'n; I' I' c=O; ,, I* get length of word *I for(c=0c
PAGE 147

} 'I I 'I skip the message */ ll%sll ,temp); whi1le != 0); } if ==0) { :: lilif.the word is found read in the message :,from the file *I whiile ((fgets(in_string,-SO,fptr) !=NULL) && 1 1! ( st rcmp( i n_st ring, II /*\n") =0)) { ,, tr9PY(hlp[count],in_string); c;ount =count+ 1 ; } !' } ,, I* cllose file */ f c 1 o ( f p t r ) ; il I void findlhelp(arg) I* this controls the non interactive between the user and the HELP Utility 111 */ char arg flb; I { !I char } II I* get1 help message for the word the user entered */ II checkjhelp(arg,msg); I* help message */ dsp msg(msg); Ll' I I .! void dspLmsg(message) I* This controls all output interactin between the HELP Utility and the user.*/ char message[][LENGTH]; { !J int :I count:::,p; n=O; I I* Thel message is an array of strings */ wh i 1 e 1 st rcmp (message [count] II I*") =0) { 'I I 136

PAGE 148

} I* get length of message string *I if (message[count][n-1] == '\n') I* if message string ends in a return replace the return with a null character *I message[count][n-1]='\0'; I* message 6n the screen *I puts(message[count]); I* 9rt next message string *I } cou:r=count+1; il :I I I 137 I

PAGE 149

.. ,I I ;I GLOSSARY I GRAPHICAE DISPLAY: Type of display format that uses pictures:'to display information. ICON: GrJphical picture displayed on the screen that an application or function. !: INTERPRET:ER: A program that converts one form of into another form. i! CONVENTIONS: Commands and functions that are used lito operate a computer program. II MOUSE: device that is composed of a rolling ball on t1he bottom and two or three buttons on the top of I, SYSTEM: Central controlling program of a computer 'II OPERATOR:! User of computer system. ,. I POINT AND! CLICK: An operation performed by the user by moving! tne pointing device to a specific location and pressling the left button of a mouse. il POINTING1DEVICE: Graphical icon that represents the current pbsition of user input on the display. 'I li PSEUDOCODE: A verbal representation of a computer program in structured or standard English. '! I PULL DOWNi MENU: A menu that is diplayed at the top of the when the user selects an icon or keyword. '! I 'i QUERY: Ari action taken by the computer system to I indicate Ito the user an input is required. I'! ,] SOFTWARE A person who develops software packages ,!i '!I SOFTWARE 1ENGINEERING: A method by which software packages !are deve 1 oped. ',.! ; 'I I I I. ,[ 138 .. I ll' :I

PAGE 150

' J :I SOFTWARE SYSTEM: A program or a collection of programs are executed on a computer system to perform or set of actions. 'I II STRUCTURED :LANGUAGE: A communication language that is formed by loops. TEMPLATE: object that is useq to develop a software package. I I ; TRANSFORM: A function that takes an input and changes it form an output I \ .. I 'I I I I I I I I I i I .: I I i I I I

PAGE 151

I BIBLIOGRAPHY i I 1. R. s. Pressman, Practiticiner's Approach, Third Edition, New York: McGraw 1992. I 2. L. Bass J. Coutaz, Developing Software for I the User!Interface, Reading Mass.: Addison-Wesley, 1':991. 3. D. A. M. R. Groves, F. R. A. Hopgood, and J. R. User Interface Management and Design, Berlin; Rew york: Springer-Verlag, 1991. 4. A. Silber!chatz, J. Peterson, and P. Galvin, Systems Concepts, Third Edition, Reading.Mass.: Addison-Wesley, 1991. II 5. K. Rosen, R. Rosinski, and J. Farber, Unix System V 4: An Introduction, New York: Osborne McGraw-Hi,l, 1990. I ll 6. L. J. Arthur, Unix Shell Programming, New York: John Wiley & Sons,Inc., 1990. 'I 7. P.E. Bouf.he, Unix for VMS Users, Cambridge, MA: Digital 1990. I' I 8. B. and D. Ritchie, The C Programming Edition, Englewood Cliffs, NJ: 1988. I 'I 9. c. B. CHifford, "An Approach to Novice Design in the Unix Environment", Univers.it& of Colorado at Denver, 1987. I i I I I I !'I I I I' I I ; 0 140 :1, t