- Email: [email protected]
Reducing graphics programming effort through structured support
Comput. & Graphics, Vol. I. pp. 191-193 Pergamon Press, 1975. Primed in Great Britain
REDUCING GRAPHICS PROGRAMMING EFFORT THROUGH STRUCTURED SUPPORT* RICHARD A. LEWALLEN+ Department of Mathematical Sciences and Computer Center, Clemson University, Clemson, South Carolina, U.S.A. Abstract--This paper describes a method for structuring graphics support which simplifies the programming of
interactive applications, while improving their portability by providing a device-independent interface. The primary objective is to ease the task of the application programmer in developing applications which use interaction and graphics. Common graphics functions which are used by several applications are generalized and defined in terms of transition tables. User actions become inputs, system wait points become states, and system responses are pointed to by table outputs. A suitable modification is applied to each of the generalized graphics functions to tailor it to be used by a particular application. The lower cost of the new graphics hardware developed in recent years has removed one of the constraints which prevented computer graphics from reaching the potential predicted for it in the 1960's [1]. However, the difficulty of developing good graphics application programs continues to restrict the growth of this field. Coupled with this difficulty is the need for program modification when a new graphics device is acquired or the program needs to be run elsewhere. This paper describes a method for structuring interactive graphics support which reduces the programming effort required and simplifies application development, while providing the application program with a device-independent interface. The primary objective is to ease the task of the application programmer in developing applications which will operate interactively. BACKGROUND
A number of previous studies have addressed the difficulty of programming computer graphics applications, attempting to simplify the programming process. This section briefly reviews these efforts. The DESIGNPAD program [2, 3], developed at the IBM Watson Research center, provides an interdisciplinary design and program-solving facility which accepts symbolic diagram input and provides graphic output. For problems which can be represented as labeled block diagrams, DESIGNPAD offers a powerful and elaborate graphics interface. However, this is the only class of problems considered, and no capability is provided for dealing with other types of applications. Although the primary emphasis in most graphics research has been on handling display images and manipulating the display and analysis data structures, the problem of specifying the interaction between the user and the system has received some attention, notably by Newman[4]. His Network Definition Language (NDL) allows problem-oriented languages, defined as statediagrams, to be compiled into interactive programs. While *Paper presented at the Conference on Computer Graphics and Interactive Techniques, 15-17 July 1974, sponsored by the University of Colorado Computing Center and ACM/SIGGRAPH. tPresent address: Daliel International Corporation, Greenville, SC, U.S.A.
solving the problem of specifying user-display interaction, NDL still required the programmer to code the individual graphic actions. The state-diagram approach was also used at the National Security Agency in implementing the Advanced Interactive Display Systems (AIDS) [5]. The user-computer interaction is specified via the WHEN Interactive Specification Statement, which serves as an extension of the state table: WHEN IN STATE n, IF condition a, THEN ... response... A precompiler generates FORTRAN statements, which are then compiled and executed. This approach has been well received by application programmers, many of whom now write reasonably complex interactive programs in a matter of days rather than weeks. However, the programmer must still specify the details of this graphic-related operations. At the General Motors Research Laboratories, a somewhat novel approach to the graphics programming problem has been implemented [6,7]. In order to provide a uniform working environment for all console users, all displays adhere to a common screen format. A package of functional evaluations and subroutines, called operators, allows transformations and other geometric operations to be performed. The console user transmits arguments to an operator by associating stylized parameters in the operator pictogram with actual parameters in his problem, shown in the work area of the screen. The Operator Programming Language (OPL) permits the operators themselves to be programmed at the screen in the same way that the application user solves his problem. The operator programmer has access to a set of operators which add symbols to a logic diagram and build the structure which will be used by the interpreter during execution. Since operators can call other operators, allowing large structures be build up in a modular fashion, the operator programmer appears to be roughly equivalent to an application programmer. Although released from having to code these operations by using OPL, the operator still must do effectively the same thing at the console. 191
192
RICHARDA.
Another system which permits specification of interactive graphics procedures at the display console was developed at the RAND Corporation[8]. Known as POGO (Programmer-Oriented Graphics Operation), it provides capabilities for speeding-up the construction of an interactive graphics interface. Included are standard control pages for frequently-performed operations (e.g. input and output), questionnaire displays for specifying program arrays and variables, and a DESIGN program to assist the user in designing his own control pages. While not being completely automatic (the user still has to do a certain amount of FORTRAN coding), POGO has cut significantly the control page development time for actual applications. However, as with AIDS and OPL, the programmer still must specify the details of the graphics interaction. In fact, all these approaches share, to a certain degree, the same drawbacks associated with standard graphics support (graphics macro-facilities or subroutine packages). When compared with conventional devices (card readers, printers, etc.) programmed with a higher-level language, the task of specifying graphical input and output is vastly more difficult. A programmer who wishes to include graphics in his application would like to do this with no more difficulty than he encounters when using more conventional devices. A step in this direction was taken by Day at the IBM Systems Research Institute[9]. An elaborate interactive plotting package was developed which was intended to be used in conjunction with a user-written analysis program. This would allow the application program to be deviceindependent, since all device-oriented operations could be confined to a separate module. By having a systems programmer implement the graphics module, the application writer could be freed from the details of programming the user interface. It was further suggested that certain of these graphics modules, which performed fairly common functions, might be used by a number of applications. The plotting package was an example. Given a suitably defined set of such modules, an installation might be able to support many applications which had standard requirements for graphics support. The latter suggestion led to the work reported here. Rather than pre-defining standard graphics functions and making them available for use by application programmers, this investigation sought to answer the following question: Given a set of graphics requirement for a number of applications, is it possible to define generalized graphics functions which satisfy each application's specific requirements?f10] DESCRIPTION OF METHOD
The fundamental assumption of this method is that applications should be analyzed from the viewpoint of the application programmer. What are the interactive functions he wishes to have performed by the display subsystem? Once these have been identified, a clean separation can be made between the computational functions and those which deal strictly with interaction and graphics.
LEWALLEN
Given the set of applications which are to be implemented, a study is made of the interactive functions required. (The term function here refers to the use of the graphics device in some phase of the application, such as the input of an electrical circuit diagram, rather than to an individual operation such as responding to the selection of a particular component.) After several applications have been considered, clusters of graphics functions with a great deal of commonality begin to develop. For each of these clusters of similar graphics functions, a generalized interactive support module is defined, which can be modified by a suitable transformation to satisfy each of the particular applications which will use it. Such a generalized graphics module is called a standard
function. The mechanism used for the definition of a standard function is the transition table of a state diagram. The procedure follows: (1) The set of possible user actions is listed and each action is assigned a number. This list becomes the input set. (2) The set of wait points is listed, numbered, and becomes the state set. (3) The system responses are listed, numbered, and become the output set. (4) The next-state and output entries in the transition table are filled in for each valid input/state combination. The above procedure completely specifies the logical behavior of the standard function. Frequently, a given entry (either next-state or output) in the transition table is dependent on which application is using the standard function. Thus, the set of modifications to the transition table should be listed for each application. Each set of modifications can be used to map the generalized standard function into a graphics support module which is tailored to a particular application. A conceptual view of this process is illustrated in Fig. 1. Up to this point, only the definition of the standard function has been accomplished. Since the application interface to the standard function has been defined, the
A P P L1
M O D I Standard Functions
•
>
APPLK
I t ~
sm i
/
MODK
f~ :
fK
abstract
common functions
modification component f o r each
application
S i i s t h e i th standard function APPLi is the i th a p p l i c a t i o n f l i s the j t h g r a p h i c a l f3unction used to s u p p o r t , APPLi
MODi is t h e s e t of m o d i f i c a t i o n s to the s t a n d a r d f u n c t i o n s r e q u i r e d by APPLi
Fig. 1. Conceptual view of graphical application support. The mechanism for decomposingthe graphicalsupport of APPL into Standard Functions+MOD, is the definition of the standard functions in terms of transition tables and the definition of the modificationsas changesto those transitiontables.
Reducing graphics programming effort through structured support application can now be written with no further concern for graphics and interaction. This permits the application to be completely device-independent. The implementation of the standard function for a particular graphics system can be carried out using the manufacturer's support software or any of the techniques mentioned in the previous section. The procedure for the implementation follows: (1) Provide code to transform the user actions actually performed into the input codes defined for the transition tables. (This corresponds to the lexical scan phase of a compiler.) (2) Write a driver routine which returns the next-state and output entries, given the present state and present input. (This should be a general routine, independent of any particular standard function.) (3) Code the system responses associated with the output entries in the transition table. To execute an interactive application using standard function support, the standard functions used by the application are loaded along with the application. The modifications to the standard transition table required for this application are carried out, and execution then proceeds as directed by the user at the display console. The loading process is illustrated in Fig. 2.
EXPERIENCE WITH METHOD
In order to test the concept of tailoring a generalized graphics support module to meet the requirements of specific applications, a standard function for schematic input was developed. The applications to be supported by this standard function were control system analysis[l l] and electrical circuit analysis[12]. Since the schematic input for circuit analysis was the more complex of the two cases, this was considered first. That is, a transition table was constructed for a graphics function which handled schematic input for a circuit analysis program. This transition table was then extended to handle schematic input for control system analysis. From this extended transition table, the generalized graphics function was extracted, producing the modifications required for circuit analysis and control system analysis as a by-product. Once the definition of the standard function had been completed, the implementation took approximately 8 weeks [10]. Had the implementation been performed by a systems programmer thoroughly familiar with the
Standard Functions
APPL.
l
'
Application Functions for Application
MOD. ) ~
+
j
+
List of Standard Functions used by Application
Exec. Load Module
}ill
Modifications to these Standard Functions
Executable Load Module for APPLj
j
Fig. 2. Loading of graphical application support for an application.
193
graphics system, this time would have been considerably shorter. The resulting graphics support module was successfully demonstrated as providing an interactive application interface capable of driving either the electrical circuit analysis or the control system analysis program. Further experiments in implementing application support based on this structuring technique are currently being considered. EXTENSIONSTO STRUCTUREDSUPPORT By following the procedure outlined earlier (under Description of Method), an installation could provide standard function graphics support to its application programmers. However, what happens when a new application, which was not considered in the original study, is to be implemented? This situation can be handled in two ways: Case 1. Assume that the application requires graphics functions which are similar to some of the standard functions already provided. Then the relevant standard functions can be extended to support the new application, analogous to the extension of the schematic input function to handle a second application. Case 2. Assume that the application requires one or more graphics functions not provided by the currentlydefined set of standard functions. Two approaches are possible: (1) A new standard function is defined for each new graphics function. (The assumption is that other applications will also be able to use the new standard functions.) (2) The graphics function is coded in the conventional manner, not using standard functions. (The assumption here is that the requirement is unique and not shared by any other application.) REFERENCES
1. S. A. Coons, Proc. AFIPS Spring Joint Computer Conf. 27, 883 (1%5). 2. H. B. Baskin, In Pertinent Concepts in Computer Graphics (edited by M. Faiman and J. Nievergelt). University of Illinois Press, Urbana (1%9). 3. L. A. Belady, M. W. Blasgen, C. J. Evangelisti and R. D. Tennison, IBM Syst J. 10, 143 (1971). 4. W.N. Newman, Proc. AFIPS Spring Joint Computer Conf. 32, 47 (1%8). 5. T. R. Stack and S. T. Walker, Proc. AFIPS Spring Joint Computer Conf. 38, 113 (1971). 6. R. L. Beckermeyer, Proc. AFJPS FallJoint Computer Conf. 37, 315 (1970). 7. E. L. Jacks, Proc. AFIPS Fall Joint Computer Conf. 26, 343 (1964). 8. B. W. Boehm, V. R. Lamb, R. L. Mobtey and J. E. Rieber, Proc. AFIPS Spring Joint Computer Conf. 34, 321 (1969). 9. C. W. Day, Jr., ITIRC Accession No. 72A002079, IBM Corp., Armonk, N.Y. (1970). 10. R. A. Lewallen, Ph.D. Thesis, Pennsylvania State University (1973). 11. P. A. Honkanen, R. A. Lewallen and R. A. Mikelskas, Proc. of the Fourth Asilomar Conf. on Circuits and Systems (1970). 12. IBM Corp. Program Information Department, 2250 ECAP, Program 360D-16A.002, Hawthorne, N.Y. (1%7).
REDUCING GRAPHICS PROGRAMMING EFFORT THROUGH STRUCTURED SUPPORT* RICHARD A. LEWALLEN+ Department of Mathematical Sciences and Computer Center, Clemson University, Clemson, South Carolina, U.S.A. Abstract--This paper describes a method for structuring graphics support which simplifies the programming of
interactive applications, while improving their portability by providing a device-independent interface. The primary objective is to ease the task of the application programmer in developing applications which use interaction and graphics. Common graphics functions which are used by several applications are generalized and defined in terms of transition tables. User actions become inputs, system wait points become states, and system responses are pointed to by table outputs. A suitable modification is applied to each of the generalized graphics functions to tailor it to be used by a particular application. The lower cost of the new graphics hardware developed in recent years has removed one of the constraints which prevented computer graphics from reaching the potential predicted for it in the 1960's [1]. However, the difficulty of developing good graphics application programs continues to restrict the growth of this field. Coupled with this difficulty is the need for program modification when a new graphics device is acquired or the program needs to be run elsewhere. This paper describes a method for structuring interactive graphics support which reduces the programming effort required and simplifies application development, while providing the application program with a device-independent interface. The primary objective is to ease the task of the application programmer in developing applications which will operate interactively. BACKGROUND
A number of previous studies have addressed the difficulty of programming computer graphics applications, attempting to simplify the programming process. This section briefly reviews these efforts. The DESIGNPAD program [2, 3], developed at the IBM Watson Research center, provides an interdisciplinary design and program-solving facility which accepts symbolic diagram input and provides graphic output. For problems which can be represented as labeled block diagrams, DESIGNPAD offers a powerful and elaborate graphics interface. However, this is the only class of problems considered, and no capability is provided for dealing with other types of applications. Although the primary emphasis in most graphics research has been on handling display images and manipulating the display and analysis data structures, the problem of specifying the interaction between the user and the system has received some attention, notably by Newman[4]. His Network Definition Language (NDL) allows problem-oriented languages, defined as statediagrams, to be compiled into interactive programs. While *Paper presented at the Conference on Computer Graphics and Interactive Techniques, 15-17 July 1974, sponsored by the University of Colorado Computing Center and ACM/SIGGRAPH. tPresent address: Daliel International Corporation, Greenville, SC, U.S.A.
solving the problem of specifying user-display interaction, NDL still required the programmer to code the individual graphic actions. The state-diagram approach was also used at the National Security Agency in implementing the Advanced Interactive Display Systems (AIDS) [5]. The user-computer interaction is specified via the WHEN Interactive Specification Statement, which serves as an extension of the state table: WHEN IN STATE n, IF condition a, THEN ... response... A precompiler generates FORTRAN statements, which are then compiled and executed. This approach has been well received by application programmers, many of whom now write reasonably complex interactive programs in a matter of days rather than weeks. However, the programmer must still specify the details of this graphic-related operations. At the General Motors Research Laboratories, a somewhat novel approach to the graphics programming problem has been implemented [6,7]. In order to provide a uniform working environment for all console users, all displays adhere to a common screen format. A package of functional evaluations and subroutines, called operators, allows transformations and other geometric operations to be performed. The console user transmits arguments to an operator by associating stylized parameters in the operator pictogram with actual parameters in his problem, shown in the work area of the screen. The Operator Programming Language (OPL) permits the operators themselves to be programmed at the screen in the same way that the application user solves his problem. The operator programmer has access to a set of operators which add symbols to a logic diagram and build the structure which will be used by the interpreter during execution. Since operators can call other operators, allowing large structures be build up in a modular fashion, the operator programmer appears to be roughly equivalent to an application programmer. Although released from having to code these operations by using OPL, the operator still must do effectively the same thing at the console. 191
192
RICHARDA.
Another system which permits specification of interactive graphics procedures at the display console was developed at the RAND Corporation[8]. Known as POGO (Programmer-Oriented Graphics Operation), it provides capabilities for speeding-up the construction of an interactive graphics interface. Included are standard control pages for frequently-performed operations (e.g. input and output), questionnaire displays for specifying program arrays and variables, and a DESIGN program to assist the user in designing his own control pages. While not being completely automatic (the user still has to do a certain amount of FORTRAN coding), POGO has cut significantly the control page development time for actual applications. However, as with AIDS and OPL, the programmer still must specify the details of the graphics interaction. In fact, all these approaches share, to a certain degree, the same drawbacks associated with standard graphics support (graphics macro-facilities or subroutine packages). When compared with conventional devices (card readers, printers, etc.) programmed with a higher-level language, the task of specifying graphical input and output is vastly more difficult. A programmer who wishes to include graphics in his application would like to do this with no more difficulty than he encounters when using more conventional devices. A step in this direction was taken by Day at the IBM Systems Research Institute[9]. An elaborate interactive plotting package was developed which was intended to be used in conjunction with a user-written analysis program. This would allow the application program to be deviceindependent, since all device-oriented operations could be confined to a separate module. By having a systems programmer implement the graphics module, the application writer could be freed from the details of programming the user interface. It was further suggested that certain of these graphics modules, which performed fairly common functions, might be used by a number of applications. The plotting package was an example. Given a suitably defined set of such modules, an installation might be able to support many applications which had standard requirements for graphics support. The latter suggestion led to the work reported here. Rather than pre-defining standard graphics functions and making them available for use by application programmers, this investigation sought to answer the following question: Given a set of graphics requirement for a number of applications, is it possible to define generalized graphics functions which satisfy each application's specific requirements?f10] DESCRIPTION OF METHOD
The fundamental assumption of this method is that applications should be analyzed from the viewpoint of the application programmer. What are the interactive functions he wishes to have performed by the display subsystem? Once these have been identified, a clean separation can be made between the computational functions and those which deal strictly with interaction and graphics.
LEWALLEN
Given the set of applications which are to be implemented, a study is made of the interactive functions required. (The term function here refers to the use of the graphics device in some phase of the application, such as the input of an electrical circuit diagram, rather than to an individual operation such as responding to the selection of a particular component.) After several applications have been considered, clusters of graphics functions with a great deal of commonality begin to develop. For each of these clusters of similar graphics functions, a generalized interactive support module is defined, which can be modified by a suitable transformation to satisfy each of the particular applications which will use it. Such a generalized graphics module is called a standard
function. The mechanism used for the definition of a standard function is the transition table of a state diagram. The procedure follows: (1) The set of possible user actions is listed and each action is assigned a number. This list becomes the input set. (2) The set of wait points is listed, numbered, and becomes the state set. (3) The system responses are listed, numbered, and become the output set. (4) The next-state and output entries in the transition table are filled in for each valid input/state combination. The above procedure completely specifies the logical behavior of the standard function. Frequently, a given entry (either next-state or output) in the transition table is dependent on which application is using the standard function. Thus, the set of modifications to the transition table should be listed for each application. Each set of modifications can be used to map the generalized standard function into a graphics support module which is tailored to a particular application. A conceptual view of this process is illustrated in Fig. 1. Up to this point, only the definition of the standard function has been accomplished. Since the application interface to the standard function has been defined, the
A P P L1
M O D I Standard Functions
•
>
APPLK
I t ~
sm i
/
MODK
f~ :
fK
abstract
common functions
modification component f o r each
application
S i i s t h e i th standard function APPLi is the i th a p p l i c a t i o n f l i s the j t h g r a p h i c a l f3unction used to s u p p o r t , APPLi
MODi is t h e s e t of m o d i f i c a t i o n s to the s t a n d a r d f u n c t i o n s r e q u i r e d by APPLi
Fig. 1. Conceptual view of graphical application support. The mechanism for decomposingthe graphicalsupport of APPL into Standard Functions+MOD, is the definition of the standard functions in terms of transition tables and the definition of the modificationsas changesto those transitiontables.
Reducing graphics programming effort through structured support application can now be written with no further concern for graphics and interaction. This permits the application to be completely device-independent. The implementation of the standard function for a particular graphics system can be carried out using the manufacturer's support software or any of the techniques mentioned in the previous section. The procedure for the implementation follows: (1) Provide code to transform the user actions actually performed into the input codes defined for the transition tables. (This corresponds to the lexical scan phase of a compiler.) (2) Write a driver routine which returns the next-state and output entries, given the present state and present input. (This should be a general routine, independent of any particular standard function.) (3) Code the system responses associated with the output entries in the transition table. To execute an interactive application using standard function support, the standard functions used by the application are loaded along with the application. The modifications to the standard transition table required for this application are carried out, and execution then proceeds as directed by the user at the display console. The loading process is illustrated in Fig. 2.
EXPERIENCE WITH METHOD
In order to test the concept of tailoring a generalized graphics support module to meet the requirements of specific applications, a standard function for schematic input was developed. The applications to be supported by this standard function were control system analysis[l l] and electrical circuit analysis[12]. Since the schematic input for circuit analysis was the more complex of the two cases, this was considered first. That is, a transition table was constructed for a graphics function which handled schematic input for a circuit analysis program. This transition table was then extended to handle schematic input for control system analysis. From this extended transition table, the generalized graphics function was extracted, producing the modifications required for circuit analysis and control system analysis as a by-product. Once the definition of the standard function had been completed, the implementation took approximately 8 weeks [10]. Had the implementation been performed by a systems programmer thoroughly familiar with the
Standard Functions
APPL.
l
'
Application Functions for Application
MOD. ) ~
+
j
+
List of Standard Functions used by Application
Exec. Load Module
}ill
Modifications to these Standard Functions
Executable Load Module for APPLj
j
Fig. 2. Loading of graphical application support for an application.
193
graphics system, this time would have been considerably shorter. The resulting graphics support module was successfully demonstrated as providing an interactive application interface capable of driving either the electrical circuit analysis or the control system analysis program. Further experiments in implementing application support based on this structuring technique are currently being considered. EXTENSIONSTO STRUCTUREDSUPPORT By following the procedure outlined earlier (under Description of Method), an installation could provide standard function graphics support to its application programmers. However, what happens when a new application, which was not considered in the original study, is to be implemented? This situation can be handled in two ways: Case 1. Assume that the application requires graphics functions which are similar to some of the standard functions already provided. Then the relevant standard functions can be extended to support the new application, analogous to the extension of the schematic input function to handle a second application. Case 2. Assume that the application requires one or more graphics functions not provided by the currentlydefined set of standard functions. Two approaches are possible: (1) A new standard function is defined for each new graphics function. (The assumption is that other applications will also be able to use the new standard functions.) (2) The graphics function is coded in the conventional manner, not using standard functions. (The assumption here is that the requirement is unique and not shared by any other application.) REFERENCES
1. S. A. Coons, Proc. AFIPS Spring Joint Computer Conf. 27, 883 (1%5). 2. H. B. Baskin, In Pertinent Concepts in Computer Graphics (edited by M. Faiman and J. Nievergelt). University of Illinois Press, Urbana (1%9). 3. L. A. Belady, M. W. Blasgen, C. J. Evangelisti and R. D. Tennison, IBM Syst J. 10, 143 (1971). 4. W.N. Newman, Proc. AFIPS Spring Joint Computer Conf. 32, 47 (1%8). 5. T. R. Stack and S. T. Walker, Proc. AFIPS Spring Joint Computer Conf. 38, 113 (1971). 6. R. L. Beckermeyer, Proc. AFJPS FallJoint Computer Conf. 37, 315 (1970). 7. E. L. Jacks, Proc. AFIPS Fall Joint Computer Conf. 26, 343 (1964). 8. B. W. Boehm, V. R. Lamb, R. L. Mobtey and J. E. Rieber, Proc. AFIPS Spring Joint Computer Conf. 34, 321 (1969). 9. C. W. Day, Jr., ITIRC Accession No. 72A002079, IBM Corp., Armonk, N.Y. (1970). 10. R. A. Lewallen, Ph.D. Thesis, Pennsylvania State University (1973). 11. P. A. Honkanen, R. A. Lewallen and R. A. Mikelskas, Proc. of the Fourth Asilomar Conf. on Circuits and Systems (1970). 12. IBM Corp. Program Information Department, 2250 ECAP, Program 360D-16A.002, Hawthorne, N.Y. (1%7).