Contact us Heritage collections Image license terms
HOME ACL ACD ICF SUS DCS G&A STARLINK Literature
Further reading □ Foreword □ Contents □ Preface □ Prologue □ Acknowledgements □ Participants □ 1. Introduction □ A. Guedj □ B. Hopgood □ C. Crestin □ D. Warman □ E. Sabin □ F. Encarnacao □ G. Dunn □ H. Bono □ I. Newell □ J. Foley □ K. Foley □ L. Sancha □ M. Sancha □ N. Sancha □ 2. Working documents □ Current position □ Graphics primitives □ Core □ Attributes □ Structure □ Methodology: Structure □ Design □ Input □ Transformations □ Formal Specification □ Conceptual Framework □ IFIP Report □ Recommendations □ Future
C&A INF CCD CISD Archives Contact us Heritage archives Image license terms

Search

   
⟶ ACD ⟶ Literature ⟶ Books ⟶ Methodology in Computer Graphics
⟶ ACD ⟶ Literature ⟶ Books ⟶ Methodology in Computer Graphics
ACL ACD C&A INF CCD CISD Archives
Further reading ⇓

□ Foreword □ Contents □ Preface □ Prologue □ Acknowledgements □ Participants □ 1. Introduction □ A. Guedj □ B. Hopgood □ C. Crestin □ D. Warman □ E. Sabin □ F. Encarnacao □ G. Dunn □ H. Bono □ I. Newell □ J. Foley □ K. Foley □ L. Sancha □ M. Sancha □ N. Sancha □ 2. Working documents □ Current position □ Graphics primitives □ Core □ Attributes □ Structure □ Methodology: Structure □ Design □ Input □ Transformations □ Formal Specification □ Conceptual Framework □ IFIP Report □ Recommendations □ Future

Recommendations on Methodology in Computer Graphics

J. Encarnacao, G. Nees

This paper is a highly condensed version of /ENC 76/ which was the result of cooperation between scientists from a number of institutions in the Federal Republic of Germany, all dealing with computer graphics. The initiative for forming the group was taken by J. Encarnacao. The members of the group represent computer scientists, developers and users of graphic systems. The goal was to establish a consistent approach to the methodology for defining, describing, designing and using graphical systems.

1. Introduction

Motivation and objectives for standard graphical software are portability or machine independence and device independence. A standard graphical system should be defined in a way general enough to support a wide variety of users, and it should be easily understood by programmers and users. In order to reach the desired goal of such a device independent, general-purpose-system with a good chance of success, we propose to make the following restrictions:

  1. The graphics functions to be defined include the construction and manipulation of pictures (no picture-analysis).
  2. A picture is generated from vector and/or text elements (no greyscale pictures).
  3. Only those graphics peripheral devices that are suitable for a general-purpose system will be considered.
  4. The definition of graphical functions, that represent the user interface, should reflect the expected frequency of occurrence of the operational device types e.g. the hardware of the most frequent used device types should be utilized as effectively as possible. One may accept a loss of efficiency for more unusual device types.

Device independence (e.g. independence from graphic peripherals) is the point on which we want to concentrate. We define device independence as the ability to use an application program with a wide variety of devices.

Standardization in this area should contribute to out ability to produce graphical data in one computer and then output it successively or simultaneously to different graphics devices (also using external intermediate storage). Simultaneous output on different devices is important when it is necessary to work with different picture sections, for example a general view and some detailed view of the same picture. it is very important to have, in addition to output device independence, also input device independence. This will be realized by using logical input devices and having them assigned to physical input devices.

2. Interfaces in a graphic system

The basic idea in designing a device-independent general purpose graphics system is to split the system into a device-dependent and a device-independent part, and hence to have graphical input/output completely separated from the user's program. This concept follows /COT 72/, was discussed in /ENC,ECK 76/ and is shown in fig. l. The basis of a device-independent graphics system is shown in fig. 2.

USER PROGRAM USER INTERFACE PRE- PROCESSOR DEVICE INDEPENDENT INPUT DATA LOGICAL INPUT INTERFACE CODE GENERATOR INTERFACE DEVICE INDEPENDENT OUTPUT DATA Device Driver INPUT PROCESSOR OUTPUT PROCESSOR DEVICE DEPENDENT INPUT DATA DEVICE DEPENDENT OUTPUT DATA DEVICE INTERFACE DEVICE DEPENDENT DEVICE INDEPENDENT

Figure 1: Separation between user-program and graphical input-output

input simulation routines input code interpreter input control input device output devices refresh display storage tube pen plotter device dependent picture code (DDPC) + correlation DDPC input devices state tables device code generator local administrator DDPC generator local administrator DDPC generator local processing ability local administrator device coordinates PPC administrator output devices state tables device description tables pre-processor (Graphics supervisor) PPC interpreter PPC generator pseudo picture code (PPC) administrator list User Coordinates records administrator records Correlation to the database transformations output simulation routines Users' application progam database buffered input e.g. digitizer input file

Figure 2: Concept for a device independent graphics system

The different possible ways of generating pictures lead to the definition of two kinds of picture buffers. In fig. 2 these buffers are called pseudo picture code and device dependent picture code. The Pseudo-Picture-Code (PPC) is a device independent structured description of the picture to be displayed and it contains all the picture data in user specific form. The PPC serves as a source representation, that can be used to control several output devices.

The Device-Dependent Picture Code (DDPC) is used for picture refresh and is generated from the PPC in such a form, that in each case the selected device can be used in an almost optimal way. That means, if the output device is able to interpret subpictures of subpictures out of the structured description, then this ability will be utilized; the same is valid for transformations and graphical primary elements (primitives) such as circle and other curve generators.

3. Development Methodology (text by D. L. Parnas - abridged)

Successful development of graphic systems of the sort discussed in this paper requires a methodological approach to the development of computer systems. Experience with an ad-hoc approach to the development of large systems has shown a need for a more systematic or step-by-step approach. Such a step-by-step approach requites an ability to precisely specify the interfaces between components and to precisely document the design decisions made at each stage of the development. If we are not able to precisely document the decisions and interfaces made along the way, our final product may be just another one indistinguishable from those developed with moderate success in a less systematic way.

For these reasons we need a specification language in which to write this document. However, Specification is used in two quite different ways in the computer system literature. Engineers tend to use it in the sense of SPECS meaning a statement of the requirements which a product must meet. Mathematically trained persons often use the word in a more general sense meaning simply any statement which makes the description of an object more specific. For example the specifications for operating systems given in /HOARE 73/ and /BREDT 75/ are specifications in the more general sense, but would not be accepted as specifications in the narrow sense used in /PAR 72/. While both of these papers provide more specific information about the systems being described, they do not provide a statement of the requirements which the systems must fulfil.

In order to avoid terminological confusion we shall in the following use specification in the engineering (SPECS) sense, and use the phrase abstract implementation instead of the more general use of the word specification.

In summary then, we see two fundamental problems involved in the development of the systems described.

  1. We require precise descriptions of the various components so that interface problems can be avoided. The description of the properties of the components visible at the interface are considered requirements that those components can meet and will be called specifications.
  2. When one begins to implement such components, it is necessary that internal design decisions be precisely documented. Naturally, larger components will be subdivided into smaller components. The way that these subcomponents will be used to obtain the larger, is expressed in the form of an abstract implementation in terms of those components. (/NEES 76/)

4. Outlook

The approach to graphics, submitted in this paper, should be considered to be a dynamic one. Especially that which concerns development methodology. Investigations at the Technische Hochschule Darmstadt on functional specification of graphical systems (starting from Parnas-techniques) are being carried out (for information on this topic please contact J. Encarnacao).

Bibliography

/BREDT 75/
A. R. Saxena and T. H. Bredt: A structured specification of hierarchical operating systems SIGPLAN Notices, Vol. 10, No. 6, June 1975, pp. 310-318
/COT 72/
Ira. W. Cotton: Network graphic attention handling. Online 72 Conference Proceedings, pp. 465-490
/ENC 76/
J. Encarnacao, B. Fink, E. Horbst, R. Konkart, G, Nees, D. L. Parnas, E. G. Schlechtendahl: A recommendation on methodology in computer graphics, A position paper for the IFIP Graphics Workshop, Seillac, France, May 23 - 26, 1976
/ENC,ECK 76/
J. Encarnacao, R. Eckert: Bemuhungen und Moglichkeiten bei der Begriffsbildung und Normung Graphischer Systeme (activities and possibilities for the standardization of graphics systems). Lecture Notes of the German Chapter of the ACM II Marz 76 (in German).
/HOARE 73/
C. A. R, Hoare: A structured paging system Computer Journal 16,3 (Aug. 1973), pp. 209-215
/NEES 76/
G. Nees: Towards an unified approach to the specification of computer graphics software Lecture Notes of the German Chapter of the ACM I April 1976
/PAR 72/
D. L. Parnas A technique for software module specification with examples Communication of the ACM, May 1972

Discussion

The previous paper was not presented in full; instead G. Nees presented the following remarks:

Our approach has three (possibly four ?) levels:

On level I: device independence is the point on which we want to concentrate. We define device independence as the ability to use an application program with a wide variety of devices. Standardization in this area should contribute to our ability to produce graphical data in one computer and then output it successively or simultaneously to different graphical output devices.

The basic idea in the design of a device-independent general purpose graphic system is to split the system into a device-dependent and a device-independent part and to arrange to have the input and output completely separated from the user program, The interesting interfaces for our purpose are:

  1. User interface
  2. Code generator interface
  3. Logical input interface

In our position paper there is a fairly general exemplification of this structure. We think that the graphical architecture which is described there is still sufficiently abstract to cover a large number of models in the logical sense.

On levels II and III, i.e. Development Methodology: I cite from the text, which Parnas contributed to our position paper: Successful development of Graphics Systems requires a methodological approach similar to the development of computer systems. Experience with an ad-hoc approach to the development of large systems has shown a need for a more systematic or step-by-step approach. Such a step-by-step approach requires an ability to precisely specify the interfaces between components and to precisely document the design decisions made at each stage of the development. For interface specifications (in the sense of engineering SPECS), Parnas is using his technique of V- and 0-functions, whereas design decisions should be made by abstract implementations.

Before speaking on abstract implementations I would like to mention the problem of invariance again: of course you can discuss specification or abstract implementation without touching on graphics at all. The reason for this is that an abstract data type can have a lot of models only some of which - or none at all - are graphic-relevant. The conclusion is that when you speak of design methodology applied to computer graphics you will not be able to avoid the task of discussing a paradigm (or more than one paradigm) of graphical models of abstract concepts. The fact that all graphical business is specialised comes into the picture. This is the reason why we think it is a good idea to sketch a model architecture for a graphical system; because such a structure can yield a paradigm of interesting graphical data types.

As an abstract-implementation language we choose Reynolds GEDANKEN because of its extremely powerful structure handling capabilities. One can, for example, define a class of graphical data structures by an abstract syntax, which, in turn, is nothing else but GEDANKEN-functions, which may be control parameters to transformers having data structures obeying that syntax. One may guess that such a class of data structures plus its transformers is equivalent to a cluster of CLU.

⇑ Top of page
© Chilton Computing and UKRI Science and Technology Facilities Council webmaster@chilton-computing.org.uk
Our thanks to UKRI Science and Technology Facilities Council for hosting this site