X: Why Z?

X: Why Z? Jonathan P. Bowen Abstract users (i.e., implementors) of the standard should understand the formal text. Currently many such users do not have the necessary education and training for this, and there are often misconceptions about the role of formal methods and notations. (Hall’s paper2 is highly recommended to dispel some of these.) The problems are being actively discussed and are now on the way to being addressed in Europe at least 3; 4 . However, this is only part of the technology transfer problem which is fraught with difficulties, any one of which can cause failure of the whole process5 . Window management systems are now used extensively for user interfaces to computer systems. In particular, X11 has come to dominate the workstation market as a widely accepted industry standard on many different hardware platforms. However, no formal standard currently exists for this window system, both in terms of an international standards body (although this is being addressed), and in terms of a precise (mathematical) specification of what the interface is intended to do. This paper advocates the use of a formal notation to describe such an important system to avoid ambiguity and undesired or unintended variations between different implementations of the same system. The formal notation used for demonstration purposes, Z, is based on set theory, and has been developed at the Programming Research Group in Oxford. One popular misconception concerning the use of formal methods is that it is all about conducting (difficult) proofs. Whilst this is certainly one aspect that can provide increased confidence in the correctness of a system, it is not necessary to perform fully formal (mechanized or mechanizable) proofs to gain benefit from the use of formal methods. Indeed most current industrial use makes little or no use of proofs in practice6 . Instead, formal notation can be used for mathematical modelling and unambiguous transmission of ideas between designers. Z7 is a notation ideally suited for this mode of use, and is used throughout the rest of this paper for illustrative purposes. Keywords: Formal specification, X window system, Z notation, window managers, standards. 1 Introduction Z is a typed language based on set theory and first order predicate calculus that has been developed at Oxford over the past decade or so. For readers not familiar with the notation, a glossary is included at the end of the paper. In addition, for those seriously interested in learning Z, several introductory textbooks are now available (e.g., see Potter et al.8 or McDermid and Whysall9 ). The Z notation is itself undergoing the process of standardization through the BSI10 ; appropriately, the standard is using formal notation for this purpose. Indeed, much of Z may be specified in Z itself11. Despite the fact that Z has not been standardized for much of its existence, and indeed developers have benefited from being free to experiment with the notation, it has still proved a useful tool both for ‘back of an envelope’ designs, and for more polished documents. Most standards in the area of computing are currently largely informal in the mathematical sense. The only widely accepted formal notation is BNF for defining the syntax of the numerous computer languages and notations that are available today. However, the semantics of these languages is almost invariably defined using natural language which is of course open to all sorts of misinterpretation and ambiguity. It has been suggested that standards should be defined more formally to help alleviate these problems1 . Informal natural language should still be included to aid the understanding of the formal text by confirming the meaning to the reader and connecting the introduced concepts to the ‘real’ world. This also allows the casual reader to use the standard. However, the formal text should always be considered the final arbiter in the case of (perceived) differences between the descriptions. Thus any serious Finally, once a system has been formally specified, it is possible to use mathematical methods to develop an implementation in some programming language, thus reducing the chances of the introduction of errors during this phase of the development (e.g., see Morgan12 ).  Oxford University Computing Laboratory, Programming Research Group, 11 Keble Road, OXFORD OX1 3QD, U.K. Email: Jonathan.Bowen@comlab.ox.ac.uk 1 In the area of graphics, parts of the ISO/IEC GKS graphics standard have been formalized 13; 14 . The interest in formalizing aspects of computer graphics and interactive systems is gradually increasing 15 . Early attempts have demonstrated the necessity of chosing an appropriate notation for the job 16. Some formal notations have been designed with computer processing in mind17 and readability can be a secondary consideration. However, in the case of standards, the latter becomes a much more important factor than the former. Z was designed from the start to be read by humans rather than computers, being based on notations that are already widely understood by mathematicians. Indeed, tools (apart from those for document preparation) have only relatively recently become available. It seems to be particularly difficult to produce a useful proof tool (e.g., zedB18 ). However, a type-checking tool at least (e.g., f UZZ19 ) would appear to be a minimum requirement for producing an industrially scaled specification intended for wide readership. Other more generally applicable tools for cross-referencing and indexing are also useful to aid navigation of large specifications. It is also possible to animate Z specifications, using Prolog for example20 , but this may limit the expressibility of the notation since the specifier may need to consider efficiency of execution, and thus in effect be involved with high-level programming, rather than just being concerned with producing a clear specification. The human-computer interface (HCI) is an important part of most software systems, and window systems are currently the standard interface for the vast majority of workstations. Formalizing HCI in a realistic and useful manner is a difficult task, but progress is being made in categorizing features of interfaces that may help to ensure their reliability in the future 21; 22 . There seems to be considerable scope for further work in this area. The main part of this paper presents some example specifications of a small part of the X window system. X, two other window systems, and the graphics rasterop function have been investigated. The specifications presented here have been extracted and adapted from a monograph describing this work in more detail 23. The various components of X are ‘standardized’ by the X Consortium at MIT, set up in 1988. Most major computing companies are members of the consortium. This ‘vendor-neutral’ approach has been a key component to the success of X. The X protocol is undergoing the process of standardization under the auspices of the American National Standards Institute (ANSI)24 . The International Organization for Standardization (ISO) have expressed an interest in reviewing this and the Institute of Electrical and Electronics Engineers (IEEE) is considering several standards concerned with X. As far as the author is aware, no formal specification exists or is planned in any of these standards. 2 Basic Concepts Before starting to attempt to specify any system formally, it is helpful to introduce a few fundamental and generally applicable concepts. This section gives a formal framework to aid the description of pixels, and their organization into pixel maps and a number of windows. 2.1 Pixel Positions A raster graphics display is made up of a set of pixels with positions or coordinates. These are normally defined in X–Y coordinate space. The display is a fixed size bounded rectangle in the X–Y plane. Xsize ; Ysize : 1 The offset in a particular direction is specified from zero up by convention. The position of a pixel may be specified by a pair of X–Y coordinates. Xrange Yrange Pixel == == == 0 . . Xsize ? 1 0 . . Ysize ? 1 Xrange  Yrange The pixel at (0; 0) is normally at the upper left-hand corner of the display and the pixel at (Xsize ? 1; Ysize ? 1) is at the bottom right by convention for most window systems. Many operations are applied to pairs of pixels. PixelPair pix1 ; pix2 : Pixel x1 ; x2 : Xrange y1 ; y2 : Yrange pix1 = (x1 ; y1) pix2 = (x2 ; y2) The ‘+’, ‘?’ and ‘’ infix operators may be applied to pixel positions in a manner that corresponds to the equivalent arithmetic operators. ‘ +’ and ‘?’ may be used for moving pixel areas around the display. ‘ ’ can be used to define a (partial) pixel ordering from the top left to bottom right. + ; ? : (Pixel  Pixel )  Pixel  : Pixel # Pixel 8 PixelPair  (x1 + x2 Xsize ^ y1 + y2 Ysize ) ) pix1 +pix2 = (x1 + x2 y1 + y2 ) ^ (x2  x1 ^ y2  y1 ) ) pix1 ?pix2 = (x1 ? x2 y1 ? y2 ) ^ pix1 pix2 , x1  x2 ^ y1  y2 < < ; ; 2 We can define the offset between any two pixel posiIf all the bits are Clear the Value is considered Black tions as a pixel offset. This is defined to wrap round the and if they are all Set it is considered White . edge of the pixel area and is thus a total function. Black == (  val : Value j ran val = fClear g ) o set : Pixel " Pixel  Pixel White == (  val : Value j ran val = fSet g ) 8 PixelPair  Note that if there is only one bit-plane (i.e., Zsize then pixel values can only be Black or White . o set pix1 pix2 = ((x1 + x2 ) mod Xsize ; (y 1 + y2 ) mod Ysize ) 8 PixelPair  A pixel map consists of a (partial) function from pixel positions to the value of the pixel contents. This can be used to describe part of a display, such as a window.  Pixel ) " Pixel Pixmap pix1 . .pix2 = (x1 . . x2 )  (y1 . . y2 ) == Pixel  Value Non-empty pixel maps may be of interest. Pixmap1 An alternative way of expressing this is: pix1; pix2 : Pixel ` pix1 . .pix2 = fp : Pixel j pix1 p ^ p pix2 g == Pixmap n fg Pixel maps are often rectangular in shape. If this property is important, we can define such pixel maps using their bottom left and top right pixel positions. A rectangular area of pixels can be defined using any two opposing corners (e.g., the coordinates defined using an attached mouse to sweep between the two). The following functions return the upper left and bottom right pixel positions from two such pixel positions respectively. min 1) ` Zsize = 1 ) Value = fBlack ; White g We can also use the ‘. .’ operator to define a rectangular area of pixels between a top left and bottom right pixel position (inclusively). . . : (Pixel = Rectangle == fmap : Pixmap1 j 91 p1 ; p2 : Pixel  dom map = p1 . .p2 g Sometimes it is desirable to set all the range of a pixel map to a particular value, for example when clearing a window down to the background colour. A function to set the range of a given function to a particular value is useful for this. ; max : (Pixel  Pixel ) " Pixel 8 PixelPair  pix1 min pix2 = (min fx 1 ; x2 g; min fy 1 ; y2 g) ^ pix1 max pix2 = (max fx1 ; x2 g; max fy1 ; y2 g) P; V ] [ setval : V " (P  V ) " (P  V ) 8v : V; p : P V  setval v p = (  m : P  V j 2.2 Pixel Maps (dom m = dom p ^ ran m = fv g) ) A raster graphics display has a number of bit-planes. This may be considered as the Z direction of the display. ‘setval’ is defined generically on the sets P and V above. This allows the function to be applied to different sets if required, thus allowing extra versatility. Normally P and Zsize : 1 V will be the sets Pixmap and Value in the specification Each bit in a bit-plane has one of two values (cleared or presented here. set). The following laws apply to the ‘setval ’ function: Clear Set Bit == == == p : Pixmap ; v : Value ` (setval v )+ p = setval v p v : Value ` setval v = 0 1 fClear ; Set g The value of a pixel at a particular position may be I.e., ‘setval v ’ is idempotent (applying it more than once modelled as a function from bit-plane number to bit value. has no further effect) and an empty pixel map remains empty when ‘setval v ’ is applied to it. Zrange == 0 . . Zsize ? 1 Two pixel maps may overlap. For example, one winValue == Zrange " Bit dow may be obscured by another. This can be captured 3 a sequence, it is sometimes desirable to ‘compact’ the remaining windows into a sequence again. as a relation between pixel maps (or more generally, any pair of similarly typed partial functions): P; V ] [ W] compact : (  W ) " seq W compact = hi 8 f :  W ; i : j i = min (dom f )  compact f = hf (i )i  compact (fi g  f ) [  V ) # (P  V ) 8 p1 p2 : P  V  p1 overlaps p2 , dom p1 \ dom p2 = 6 overlaps : (P ; If the windows in a sequence overlap, it is useful to be able to move selected windows so that their contents may be viewed (or hidden). This is analogous to shuffling a pile of sheets of paper (windows) on a desk (screen). Note that the sheets of paper may be of different sizes and in different positions on the desk. We can define functions to ‘select’ and ‘remove’ a set of windows from a sequence using their identifiers (as opposed to their position in the pile which may of course vary). A sequence of pixel maps may be overlaid in the order given by the sequence. It is convenient to define a distributed overriding operator for this in terms of the standard overriding operator. P; V ] [  : seq(P  V ) " (P  V )  hi = 8 p : P  V   hp i = p 8 s1 s2 : seq(P  V )   (s1  s2) = ( s1 )  ( s2) = = = ; = = W] [ = select ; remove : seq W  W " seq W Distributed overriding is particularly useful for defining 8 s : seq W ; w : W  the view on a screen of a display, given a sequence of s select w = compact (s  w ) ^ possibly overlapping pixel maps. s remove w = compact (s  w ) The following laws apply for the distributed overriding operator (using pixel maps in the examples shown below): We can then ‘raise’ or ‘lower’ these windows to the end or beginning of the sequence as required. s : seq Pixmap ; p : Pixmap `  (s  hp i) = ( s )  p p1 p2 : Pixmap `  hp1 p2i = p1  p2 = ; W] [ = = raise ; lower : seq W  W " seq W 8 s : seq W ; w : W  ; s : seq1 Pixmap ` = s = (=(front s ))  (last s ) = (head s )  (=(tail s )) S s : seq Pixmap ` dom(= s ) = dom( (ran s )) S s : seq Pixmap ` ran(= s )  ran( (ran s )) s : seqTPixmap ` (ran s ) = ) = s = S(ran s ) s raise w = (s remove w )  (s select w ) ^ s lower w = (s select w )  (s remove w ) Every window in a system usually has an identifier, denoted Window , which allows it to be accessed uniquely. Note that the first law above provides an alternative (al[Window ] though less symmetric) way of defining ‘=’. The last law states that if none of the pixel maps overlap, the disThe generic functions defined in this section will nortributed overriding operator gives the same result as the mally be applied to such identifiers. This concludes the union of all the pixel maps. basic definitions which will be used as required in the rest of this paper. 2.3 Windows A (finite) series of windows on a display screen may be 3 Specification of X in Z viewed as a sequence in which each window is laid on the screen in the order defined by the sequence (bottom A high level description of an abstract state of the system first, top last). If some of the windows are removed from and a selection of window operations in terms of a change 4 3.1 State of that state are presented in this section. A standard approach to presenting such a description in Z has been developed over the years. Some of the conventions used are included in the last section of the glossary at the end of the paper. The operations covered are those available to applications programs via library procedure calls. In general, similar operations are available to the user under mouse control. It is assumed that the reader has some basic knowledge of windowing techniques (e.g., see Foley and van Dam25 or Newman and Sproull 26). Only operations directly concerned with windowing are covered. The systems described also include many other operations such as graphics, raster-op, mouse and cursor routines, etc. The description here covers the following: The state of the X system is introduced in simple stages in order to build up the concepts involved. This is done by defining a series of state schemas in terms of the previously introduced state (using ‘schema inclusion’) and manageably sized state definition fragments with constraining predicates (‘invariants’) that relate parts of the state and must always hold. All the windows in an X server are arranged in a strict hierarchy. At the top of the hierarchy is the ‘root’ window. Each window has a parent except the root window. These child windows may in turn have their own children. Each window, including the root window, may be considered to consist of a pixel map in this simple description.  State of the system and initialization. X 0 root : Window children : Window parents : Window  Window subwindows : Window # Window windows : Window  Pixmap root 2= children children = dom parents subwindows = parents  dom windows = children [ froot g  Windowing operations, ignoring error conditions.  Error conditions and status reports.  Simplifications and assumptions in the specification.  General comments and inconsistencies. Graphics facilities within windows are not included, although Z is suitable for this. For example, it has been Subwindows are displayed in a particular order within used to specify parts of the graphics standard GKS13; 14 , the raster-op function23 and graphics operations provided their parent window. This may be modelled as a sequence of windows in ascending order of display. These consist by X27 . 23 of all the child windows. Three window systems have been investigated : X 1 X 0 order : Window  iseq Window dom order = dom windows ( 8 w1 ; w2 : dom order j w1 6= w2  (order w1 ) \ ran(order w2 ) = ) Sfran w : dom order  ran(order w )g = children ( 8 w : dom windows  ran(order w ) = subwindows fw g ) 1. The Blit28 from AT&T; 2. WM29 (now implemented under X as the Andrew Toolkit30) from Carnegie-Mellon University; 3. X24; 31; 32 , originating from MIT. The latter is presented in this paper since this has now become an industry standard and is thus likely to be the most familiar to readers. (However, unfortunately it is also the most complicated.) X is a network transparent windowing system developed initially with support from DEC and more recently a consortium including the major workstation vendors. The X display server distributes user input to, and accepts output requests from various client programs either on the same machine or over a network. Windows must be ‘mapped’ before they can be displayed. The root window is always mapped. All of a window’s ancestors (if any) must also be mapped for it to be viewable on the display. Unviewable windows are mapped but have some ancestor that is unmapped. 5 X 2 X 1 mapped ; viewable ; unviewable : Window mapped  dom windows root 2 mapped viewable = fc : children j parents  fc g  mapped g [ froot g unviewable = fc : children j c 2 (mapped n viewable )g Proof: InitX fpredicate in InitX g ) windows 0 = froot 0 7! background 0 g flaw of ‘dom’g ) dom windows 0 = froot 0g fpredicate in X 0g ) children 0 [ froot 0g = froot 0g fsince root 0 2= children 0 from X 0g ) children 0 = Such reasoning is normally only done informally in a designer’s head; confirming such properties serves to Each viewable window has an associated visible pixel increase the confidence that a specification does actually describe what is wanted. map which consists of the pixel map of the window overConsider changes in the window system. The root laid with its subwindows (in order) if any. These are window identifier and the background of the screen do ‘clipped’ to the size of the parent window. not change. The root window covers the entire background of the display screen. The screen displays the pixel map visible ∆X from the root window. X X0 root 0 = root background 0 = background X X 2 visible : Window  Pixmap screen ; background : Pixmap dom visible = viewable ( 8 w : viewable  visible w = (windows w )  (dom(windows w )  =(compact ((order w )  visible ))) ) background = windows root screen = visible root Sometimes the state of the system is unaffected during an operation. b [ ∆X j X 0 ΞX = = X] We can now consider operations on the state of the system; initially, error-free operations are presented for simplicity. Error conditions are covered subsequently, and then combined with the relevant operations as required, thus allowing a separation of concerns. The view of the system considered here is that of the Initially only the root window is present and this displays user communicating with one X display at a time. It the background. would be possible to taken a more global view and consider a set of displays on a network. This has been done for WM23 . InitX X0 windows 0 = froot 0 7! background 0 g order 0 = froot 0 7! hig mapped 0 = froot 0g 3.2 Creating and Destroying Windows Firstly, we wish to be able to create windows. For these operations we have to supply the parent window under which the new window is to reside in the window hierarchy. The position, size and background of the window must also be specified. Here these are defined by bgnd ? for simplicity. Note that the created window will not actually be displayed until it and all its ancestors are ‘mapped’ (see later). Thus there are no child windows: InitX ` children 0 = 6 CreateWindow 0 ∆X parent ? : Window bgnd ? : Pixmap w ! : Window parent ? 2 dom windows w ! 2= dom windows windows 0 = windows [ fw ! 7! bgnd ?g order 0 = order  fparent ? 7! (order parent ?)  hw !ig mapped 0 = mapped ΦDestroy ∆X w ? : Window destroy : Window w ? 2 children windows 0 = destroy  windows ( 8 w : dom windows  order 0 w = (order w ) remove destroy ) mapped 0 = mapped n destroy We may wish all subwindows, as well as the window itself, to be destroyed. DestroyWindow 0 =b [ ΦDestroy j destroy = subwindows  fw ?g ] The predicates in the schema above fully define the state after the operation since all the other state components may be derived from those given above. The other Alternatively, we may wish to just destroy the subwincomponents are included in the state definition to allow dows under the specified window. different views of the system, depending on the manner DestroySubwindows 0 =b in which we wish to access the state. [ ΦDestroy j destroy = subwindows + fw ?g ] Sometimes it is convenient to create several windows at once under a single parent window. Note that not Note that the ‘root’ background window cannot be deall the windows requested may be created, but this is stroyed using these operations. Only child windows may indicated by the information returned. This consists of a be destroyed. partial injection obtained from the sequence numbers of DestroyWindow 0 ` root 0 2 dom windows 0 the windows which are actually created to the window identifiers which they are allocated. Proof: directly from the invariant dom windows = children [ froot g in the schema X 0. However, we may wish to investigate this further, to see what preconCreateWindows 0 ditions are introduced by such a constraint. ∆X parent ? : Window defs ? : seq Pixmap 3.3 Manipulating Windows defs ! :  Window A window, and all its ancestors, must be ‘mapped’ to be parent ? 2 dom windows visible on the screen. However a mapped window may dom defs !  dom defs ? still be invisible if it is obscured by a sibling window. ran defs ! \ dom windows = Mapping operations require a child window to be specwindows 0 = windows [ (defs !  defs ?) ified. The hierarchical relationships between windows and the contents of the windows are left unaffected. order 0 = order  fparent ? 7! (order parent ?)  (compact defs !)g ΦMap mapped 0 = mapped ∆X w ? : Window w ? 2 children windows 0 = windows We also wish to be able to destroy child windows. Given a particular window, we may wish to destroy a set of windows which are associated with it. We can define Mapping a window raises the window and all its suba partial specification to do this as a schema. Exactly windows which have had map requests. Mapping a winwhich windows are to be destroyed is not specified for dow which is already mapped has no effect on the screen the present. – it does not raise it. 7 MapWindow 0 ΦMap parent : Window parent = parents w ? w ? 2= mapped ) order = order  fparent 7! ((order parent ) raise fw ?g)g w ? 2 mapped ) order = order mapped = mapped [ fw ?g ΦWindow ∆X w ? : Window map : Pixmap parent : Window 0 parent = parents w ? windows = windows  fw ? 7! map g order = order  fparent 7! ((order parent ) raise fw ?g)g mapped = mapped 0 0 0 0 0 All the unmapped subwindows of a given window can be mapped together. The order in which they are mapped is The definition above allows operations to move and change windows to be defined more easily. chosen by the system rather than the caller. Some operations explicitly affect the order in which the windows are displayed. A child window is specified, MapSubwindows 0 and window relationships, the windows themselves and ΦMap the set of mapped windows remain unchanged. neworder : iseq Window ΦOrder newmapped : Window ∆X newmapped = subwindows fw ?g n mapped w ? : Window ran neworder = newmapped parent : Window suborder ; suborder 0 : seq Window order 0 = order  fw ? 7! ((order w ?) remove newmapped )  parent = parents w ? neworder g mapped = mapped [ newmapped windows = windows suborder = order parent order = order  fparent 7! suborder g mapped = mapped 0 0 0 0 0 A window can be unmapped. The window will disappear from view if it was visible. A window may be ‘raised’ so that no sibling window obscures it. If the windows are regarded as overlapping sheets of paper stacked on a desk, then raising a window is analogous to moving the sheet to the top of the stack, whilst leaving its position on the desk the same. UnmapWindow 0 ΦMap order = order mapped = mapped n fw ?g 0 RaiseWindow 0 =b [ ΦOrder j suborder 0 0 = suborder raise fw ?g ] A window may also be ‘lowered’ in a complementary fashion. If the windows are regarded as overlapping sheets of paper stacked on a desk, then lowering a window is analogous to moving the sheet to the bottom of the stack, whilst leaving its position on the desk the same. All subwindows of a specified window can be unmapped. UnmapSubwindows 0 ΦMap order = order mapped = mapped n subwindows fw ?g LowerWindow 0 =b [ ΦOrder j suborder 0 0 0 = suborder lower fw ?g ] As well as the definitions presented here, operations to move, change, rotate the order of, and query the status of windows have also been specified23 . The subset of operations was chosen to allow similar operations in the other two window systems that were investigated to be compared. Windows may be manipulated in various ways. Given a window, its pixel map may be updated. It is also raised to the top of the display. We can define a general schema to simplify the definition of such operations. 8 3.4 Errors 3.5 Simplifications and Assumptions Many operations return a status report signalling success or failure of the operation. Let this be denoted Status . Often a NULL status indicates success and a non-NULL status indicates failure. In the description given, only ‘opaque’ windows have been considered. The actual X system includes ‘transparent’ windows, mainly used for menus, and ‘icon’ windows which may be associated with opaque windows, but these have been ignored in this description for simplicity. These could be included in the state of the system. The operation specifications would need to be updated appropriately. Status ] [ NULL : Status X ext X transparent opaque : Window icon : Window  Window htransparent opaque ran icon i partition children dom icon  opaque The operations covered so far detail what should happen in the event of no errors. In this case we also wish to report the fact that the operation was successful. ; Success status ! : Status status ! = NULL ; ; Windows have other information associated with them besides their pixel maps and their mapping status, such as border information, but this is not covered here. Exposure events that result from window operations are also ignored. If errors do occur, then these need to be reported as well. For example, an invalid parent window may be specified. InvalidParent ΞX parent ? : Window status ! : Status parent ? 2 dom windows status ! 6= NULL 3.6 Comments and Inconsistencies The X window system is relatively complicated. It includes a number of basic concepts, many of which could not be included here fully because of lack of space. However, the hierarchical structure makes it very versatile. Perhaps surprisingly, X has no notion of a ‘current’ window. Hence a large number of the library routines need a window identifier as input (including all those covered here). This is rather cumbersome and could introduce some unnecessary overhead in application programs using the system. However this is advantageous if a number of windows are being updated simultaneously since then there are effectively several current windows. An earlier version of this specification was sent to one of the authors of X at MIT with annotations, raising questions about areas which were not well understood from the original documentation33. A number of inconsistencies in the formal specification (compared to the implementation of X) were discovered from the feedback obtained. The major errors were as follows: = Alternatively, an invalid child window could be given as input. InvalidWindow ΞX w ? : Window status ! : Status w ? 2 children status ! 6= NULL = We may include these errors with the previously defined operations which ignored error conditions, to produce total operations. CreateWindow 1 =b (CreateWindow 0 ^ Success ) _ InvalidParent  Children are always on top of their parent, and the hierarchies of two siblings never interleave. In the original specification, an overall order (order : seq Window ) was included as part of the state; it did not preclude the above. Here the ordering is defined on a per window basis, for just the immediate children. All the other operations covered take the following form. DestroyWindow 1 =b (DestroyWindow 0 ^ Success ) _ InvalidWindow 9  The contents of unmapped and invisible parts of windows are lost. For example, in the schema 0 Φ , the predicate ‘ = ’ is actually incorrect since the contents of the window ? will be lost if it is unmapped. However the specification has not been changed in this respect since exposure events are ignored here, and these would typically restore the contents of re-exposed windows. If exposure events were added to this specification then this should be changed. Map windows windows w These points were missed from the original documentation used to formulate this specification34; 35 . They would probably have been discovered if an implementation of X had been available for ‘testing’ purposes. The documentation could be improved in these areas to avoid misunderstanding. The formal specification could of course be corrected. However this information was received about a year after the original specification was formulated. Changing an existing formal specification (like program maintenance) is difficult at the best of times. Corrections can lead to more errors being introduced. Additionally X is particularly complicated in its operation compared to some other window systems. Thus the specification has been left in its original form. Perhaps if formal methods had be used in the design of X, a cleaner, simpler system would have resulted. This has been found to be the case in other designs where a formal approach has been adopted 36. The first version of X specified was Version 9 33 . Documentation for Version 1034 and Version 1135 were also available subsequently as feedback was obtained from the developers. Whilst there was interest in the Z specifications, this has not so far affected the development of X greatly; a much more substantial effort to specify a larger percentage of X would be needed, but this would of course require considerable resources. Any further work on formalizing X should use the current Version 11 documentation. 4 Conclusions Part of a high level description of the X window system has been presented; only a few operations have been covered. A complete description would require a manual or standard. a formal specification does not necessarily reduce the size of a description using informal methods but it does make it much more precise. Because of this, it is possible to reason about a system and detect inconsistencies in it far more easily than the case where only an informal specification is available. Even if formal specification is not used in the final documentation, its use will clarify points which can then be described informally to the user. 10 4.1 Comparison of Window Systems In this exercise, subsets of operations in each of the window systems were selected to allow them to be compared. Even the small subset chosen proved useful for this. Of the three window systems originally investigated, X provides the most comprehensive features. WM is a much simpler system with no overlapping windows or hierarchical structure. However it does automatically adjust the size of windows when necessary. The Blit is a ‘raw’ machine onto which window management functions can be loaded if desired. The following table gives a comparison of the features available on each system. Window system Overlapping windows Hierarchical structure Automatic sizing Current window p   p Blit WM   p p pX p   Of the three window systems, X was investigated first. It turned out to be the most complicated system and took a significant amount of time to formalize. Subsequently, the specification of the Blit and WM were comparatively easy. The original specification was formulated mainly from Version 10 of X31 . Since then, Version 11 of X (or X11 as it is normally known) has become an industry standard and is available on many workstations37; 32 .24 provides a good historical perspective of the phenomenal success of X from its inception in 1984 to the X Consortium, consisting of over 70 organizations, that exists today. The other two systems are not so widely used. X now includes an Andrew Toolkit library interface 30 built on top of the main X interface that implements almost all of WM. Hence most Andrew applications will run under X without source modification. There are a number of different ‘toolkits’ built on top of the basic X system, including an X Toolkit38, to make the system more usable. 4.2 Formal Specification of Existing Systems Originally it had been planned to compare parts of a number of distributed systems using Z. However, the authors of potential systems for investigation could only supply academic papers (not enough information) or the source code (too much information). What was required was some form of informal documentation for the system. Because window systems are used directly by users, there seems to be more readable documentation available. In each case, omissions and ambiguities in the documentation were discovered by attempting to formalize the system. Where necessary, intelligent guesses were made about the actual operation. These were usually correct, but not always. Subsequently, the formal specifications could be used to update the existing documentation, or even rewrite it from scratch. Although Z has been developed as a design tool, it is also well suited for post hoc specifications of existing systems, and for detecting and correcting errors and anomalies in the documentation of such systems36 . However, it is recommended that where possible, a formal notation should be used from the outset, rather than being introduced part way through or after the design process, to gain maximum benefit. Ideally the formal and informal descriptions should be developed together in the same document to allow the design team members to compare the two easily and reinforce their understanding or raise questions if an ambiguity or mismatch is detected. This applies equally to readers of the documentation after the system has been developed, although hopefully such problems should be much reduced by then. Since formal text is less ambiguous than an informal description, it should normally be considered the final arbiter in the case of any misunderstanding. The most important stage of formalizing a system is selecting the right level of abstraction for modelling its state. This is normally an iterative process. On attempting to specify an operation one often needs to backtrack to change the abstract state of the system. In particular, extra state components can be convenient to provide different views of the system depending on the operation involved. The schema calculus provided by Z may be used to structure the specification. Large specifications may be structured hierarchically, using schemas as types and a technique known as promotion39. Recently, the possibility of combining object-oriented techniques with Z have been investigated by a number of researchers (e.g., Object-Z41 ). A text book advocating the use of object-oriented techniques with Z is now available9 . There are likely to be some inconsistencies between the formal specifications and the actual operation of the systems described. This is due to impreciseness and misunderstanding of the informal documentation used to formulate these specifications. This illustrates one of the reasons for using formal specification techniques – to avoid ambiguity or vagueness and to aid precise communication of ideas. Because of this, formal notation forces issues to the surface much earlier in the design process than when using informal description techniques such as natural language and diagrams. Difficult areas of the design cannot be ignored until the implementation stage. This reduces the number of backtracks necessary round the design/implementation/testing cycle. Additionally, using formal specification techniques should reduce maintenance costs since more of the errors in a system will be discovered before it is released into 11 the field. Although specification and design costs will be increased, implementation and maintenance costs should be lower, reducing overall costs. Formally specifying an existing system could be particularly useful if it is to be re-engineered to comply with modern software engineering standards. In such cases there could be costs benefits by taking such an approach; for example, IBM claim an overall saving in cost of 9% (which runs into millions) in the redevelopment of their CICS transaction processing software42. 4.3 Limitations A particular formal notation cannot describe all aspects of a system. Some features are not worth formalizing (e.g., the colour of the casing of an X window server). Others may be beyond the scope of the notation, or there may be more appropriate and specialized formalisms available. Z, for example, is designed for describing discrete digital (normally computer-based) systems and a style has been developed for modelling an abstract state of a system and operations on that state. It is not particularly good for describing concurrency. Other notations, such as CSP43 , have been designed specifically for this and the networking aspects of X may be better described using such a formalism. 4.4 General Conclusions Z can be used to specify real systems succinctly. The examples given here and other case studies and real examples undertaken at the Programming Research Group and elsewhere lend support to this assertion. Z may be used to produce readable specifications. It has been designed to be read by humans rather than computers. Thus it can form the basis for documentation, together with informal explanation. Large specifications are manageable in Z, using the schema notation for structuring 40. It is possible to produce hierarchical specifications. A part of a system may be specified in isolation, and then this may be put into a global context using schema promotion39. Once a system has been formally specified, it is possible for it to be mathematically transformed or ‘refined’ into an implementation in some programming language12 . This reduces the chances of introducing errors during the development stage. It would seem that Z and other formal notations could be usefully applied to unambiguously specify many aspects of computer systems in standards and other documentation, and aspects of user interfaces and graphics in particular. Acknowledgements 10. Z standards change group, “Z Base Standard”, (Version 0.4), Technical Report ZIP/PRG/91/074 (December 1991). (Available from the ZIP Secretary Project, Oxford University Computing Laboratory, 11 Keble Road, Oxford OX1 3QD, UK.) This work was prompted by two trips to the US when several window systems were viewed in operation. The author is indebted to the developers of each of the systems who made the relevant documentation and other references freely available and/or provided feedback on 11. J.M. Spivey, Understanding Z: A Specification Language and its Formal Semantics, Cambridge Univerthe formal specification: in particular, Mahadev Satyasity Press (1988). narayanan, Rob Pike, Dave Presotto, Bob Scheifler, Bill Weihl and Jim Gettys. Members of the Programming Research Group at Oxford provided intellectual support. 12. C.C. Morgan, Programming from Specifications, Prentice Hall International Series in Computer SciThe formal text in this paper has been type-checked 19 ence (1990). using the f UZZ package . The author is grateful to the UK Science and Engineer13. D.J. Arnold, D.A. Duce and G.J. Reynolds, “An Aping Research Council (SERC) for financial support. proach to the Formal Specification of Configurable Models of Graphics Systems”, pp. 439–463 in EUROGRAPHICS’87, G. Maréchal (ed.), Elsevier SciReferences ence Publishers B.V. (1987). 1. D. Blyth, C. Boldyreff, C. Ruggles and N. TettehLartey, “The Case for Formal Methods in Standards”, IEEE Software, pp. 65–67 (September 1990). 2. J.A. Hall, “Seven Myths of Formal Methods”, IEEE Software, pp. 11–19 (September 1990). 14. D.J. Arnold and G.J. Reynolds, “Configuring Graphics Systems Components”, Software Engineering Journal, 3(6), pp. 248–256 (November 1988). 15. D.A. Duce, “Formal Methods in Computer Graphics”, Computer Graphics Forum, 10, pp. 359–361 (1989). 3. D. Gries, “Influences (or lack thereof) of Formalism in teaching Programming and Software Engineering”, in Formal Development of Programs and 16. R. Gnatz, “An Algebraic Approach to the Standardization and Certification of Graphics Software”, Proofs, E.W. Dijkstra (ed.), chapter 18, pp. 229–236, Computer Graphics Forum, 2(2/3), pp. 153–166 University of Texas at Austin Year of Programming (1983). Series, Addison Wesley (1990). 4. I. Pyle, “Software Engineers and the IEE”, Software 17. L. Damnjanovic, “The Formal Specification of Level 1a of GKS”, Computer Graphics Forum, 10, pp. 11– Engineering Journal, 1(2), pp. 66–68 (March 1986). 25 (1991). 5. J.N. Buxton and R. Malcolm, “Software Technology Transfer”, Software Engineering Journal, 6(1), 18. D. Neilson and D. Prasad, “zedB: A Proof Tool for Z built on B”, in Z User Workshop, York 1991, J.E. pp. 17–23 (January 1991). Nicholls (ed.), Springer-Verlag, Workshops in Computing (1992). To appear. 6. R. Barden, S. Stepney and D. Cooper, “The Use of Z”, in Z User Workshop, York 1991, J.E. Nicholls (ed.), Springer-Verlag, Workshops in Computing 19. J.M. Spivey, “The f UZZ Manual”, Computing Science Consultancy, 2 Willow Close, Garsington, Ox(1992). To appear. ford, UK (1988). 2nd edition to appear, 1992. 7. J.M. Spivey, The Z Notation: A Reference Manual, 2nd edition, Prentice-Hall International Series 20. A.J.J. Dick, P.J. Krause and J. Cozens, “Computer Aided Transformation of Z into Prolog”, pp. 71–85 in in Computer Science (1992). Z User Workshop, Oxford 1989, J.E. Nicholls (ed.), 8. B.F. Potter, J.E. Sinclair and D. Till, An Introduction Springer-Verlag, Workshops in Computing (1990). to Formal Specification and Z, Prentice-Hall Inter21. A. Dix, Formal Methods for Interactive Systems, national Series in Computer Science (1990). Academic Press (1991). 9. J.A. McDermid and P. Whysall, Formal System Specification and Implementation using Z, Prentice-Hall 22. M.D. Harrison and H. Thimbleby (eds.), Formal International Series in Computer Science (1992). Methods in HCI, Cambridge University Press (1990). 12 23. J.P. Bowen, “Formal Specification of Window Sys- 37. R. Scheifler, J. Gettys and R. Newman, X Window tems”, Technical Monograph PRG-74, Oxford UniSystem: C Library and Protocol Reference, Digital versity Computing Laboratory, UK (1989). Press, Bedford, MA, USA (1988). 24. R. Scheifler and J. Gettys, “The X Window Sys- 38. J. McCormack and P. Asente, “An Overview of the X tem”, in Research Directions in Computer Science: Toolkit”, in Proc. ACM SIGGRAPH Symposium on An MIT Perspective, A.R. Meyer, J.V. Guttag, R.L. Use Interface Software, pp. 46–55 (October 1988). Rivest and P. Szolovits (eds.), chapter 5, pp. 75–92 (1991). 39. J.C.P. Woodcock, “Mathematics as a Management Tool: Proof Rules for Promotion”, Proc. 6th Annual 25. J.D. Foley and A. van Dam, Fundamentals of ComCSR Conference on Large Software Systems, Bristol, puter Graphics, Addison Wesley (1982). UK (1989). 26. W.M. Newman and R.F. Sproull, Principles of Interactive Computer Graphics, 2nd edition, McGraw 40. J.C.P. Woodcock, “Structuring Specifications in Z”, Software Engineering Journal, 4(1), pp. 51–66 (JanHill (1981). uary 1989). 27. N.J. Dunlop, “Formal Specification of a Windowing System”, MSc thesis, Oxford University Computing 41. D. Carrington, D. Duke, R. Duke, P. King, G. Rose and G. Smith, “Object-Z: An Object-Oriented Laboratory, UK (1988). Extension to Z”, in Formal Description II Tech28. R. Pike, “The Blit: a Multiplexed Graphics Terniques (FORTE’89), S. Vuong (ed.), North-Holland, minal”, AT&T Bell Laboratories Technical Journal, pp. 281–296, Vancouver, Canada (1990). 63(8), part 2, pp. 1607–1631 (October 1984). 42. M. Phillips, “CICS/ESA 3.1 experiences”, in Z 29. D.S.H. Rosenthal, “A Programmer’s Guide to “WM” User Workshop, Oxford 1989, J.E. Nicholls (ed.), or How do I get into this Window Stuff”, Information Springer-Verlag, Workshops in Computing, pp. 179– Technology Center (ITC), Carnegie-Mellon Univer185 (1990). sity, USA (October 1985). 30. A. Palay et al., “The Andrew Toolkit: An Overview”, 43. C.A.R. Hoare, Communicating Sequential Processes, Prentice Hall International Series in ComProc. Winter USENIX Technical Conference, pp. 9– puter Science (1985). 21, Dallas, USA (1988). 31. R. Scheifler and J. Gettys, “The X Window System”, ACM Transactions on Graphics, 5(2), pp. 79–109 (April 1986). 32. R. Scheifler and J. Gettys, The X Window System, Digital Press, Bedford, MA, USA (1989). 33. J. Gettys and R. Newman, “Xlib – C Language X Interface”, (Version 9), MIT Project Athena, Massachusetts Institute of Technology, USA (1985). 34. J. Gettys, R. Newman and A. Della Fera, “Xlib – C Language X Interface”, (Version 10), MIT Project Athena, Massachusetts Institute of Technology, USA (1986). 35. R. Scheifler, “X Window System Protocol, Version 11”, (Draft 4), Massachusetts Institute of Technology, USA (1986). 36. J.P. Bowen, “Formal Specification in Z as a Design and Documentation Tool”, Proc. 2nd IEE/BCS Conference, Software Engineering 88, pp. 164–168, Liverpool, UK (1988). 13 Glossary of Z notation A glossary of the Z mathematical and schema notation used in this paper is included here for easy reference. The complete notation is not covered. For more information, see Spivey7 . Names a ,b d ,e f ,g m ,n p ,q s ,t x ,y A,B N Q ,R S ,T X identifiers declarations (e.g., a : A; b ; ::: : B :::) functions numbers predicates sequences expressions sets set of number relations schemas schema text (e.g., d , d j p or S ) R+ Q R Definitions a == x Abbreviated definition a ::= b j ::: Data type definition (or a ::= b x  j :::) [a ] Introduction of a given set (or [a ; :::]) Infix operator a Postfix operator a Functions AB A"B AB AB AB fx Logic :p p ^q p _q p )q p ,q 8X  q 9X  q 91 X  q Logical negation Logical conjunction Logical disjunction Logical implication (: p _ q ) Logical equivalence (p ) q ^ q Universal quantification Existential quantification Unique existential quantification Partial function Total function Finite partial function Bijective function Partial injective function Function application (or f (x ) ) Numbers ) p) 1  succ n m+n m?n m n m div n m mod n mn m .. n min N max N Sets x =y x 6= y x 2A x 2= A Equality of expressions Inequality (: (x = y )) Set membership Non-membership Empty set A  B Set inclusion A  B Strict set inclusion fx ; y ; :::g Set of elements fX  x g Set comprehension  X  x Lambda-expression – function  X  x Mu-expression – unique value (x ; y ; :::) Ordered tuple A  B  ::: Cartesian product A Power set (set of subsets) A Set of finite subsets A\B Set intersection A[B Set union AnB Set difference #A Size of a finite set Set of natural numbers f0; 1; 2; :::g Set of non-zero natural numbers ( n f0g) Set of integers Successor function (n + 1) Addition Subtraction Multiplication Division Modulo arithmetic Less than or equal (also <,  and >) Number range Minimum number Maximum number Sequences seq A seq1 A iseq A hi hx ; y ; :::i s t = s head s tail s last s front s rev s s A Relations A#B a 7! b dom R ran R id A QR AR AR AR AR R A Rn R R Irreflexive-transitive closure Relational overriding ( (dom R  Q ) [ R ) Relation ( (A  B ) ) Maplet ( (a ; b ) ) Domain of relation Range of relation Identity function Forward relational composition Domain restriction Domain anti-restriction Range restriction Range anti-restriction Relational image Relation composed n times Inverse of relation (R ?1 ) Reflexive-transitive closure Set of finite sequences Set of non-empty finite sequences Set of finite injective sequences Empty sequence Sequence f1 7! x ; 2 7! y ; :::g Sequence concatenation Distributed sequence concatenation First element of sequence ( s (1) ) All but the head element of a sequence Last element of sequence ( s (#s ) ) All but the last element of a sequence Reverse a sequence Sequence filtering Schema notation S d p d p a ; :::] d p [ 14 Vertical schema. New lines denote ‘ ;’ and ‘^’. The schema name and predicate part are optional. The schema may subsequently be referenced by name in the document. Axiomatic definition. The definitions may be non-unique. The predicate part is optional. The definitions apply globally in the document. Generic definition. The generic parameters are optional. The definitions must be unique. The definitions apply globally in the document. S= b [X ] Horizontal schema [T ; ::: j :::] Schema inclusion Selection (given z : S ) z :a Tuple of components S Schema negation :S Schema precondition pre S Schema conjunction S ^T Schema disjunction S _T S ) T Schema implication S , T Schema equivalence S n (a ; :::) Hiding of component(s) Projection of components S T Schema composition (S then T ) S T S >> T Schema piping (S outputs to T inputs) component renaming (b becomes S [a =b ; :::] Schema a , etc.) 8 X  S Schema universal quantification 9 X  S Schema existential quantification 91 X  S Schema unique existential quantification Conventions a? a! a0 S0 ∆S ΞS ΦS `p d `p Input to an operation Output from an operation State component after an operation (a before) State schema after an operation (S before) Change of state (normally S ^ S 0 ) No change of state (normally [∆S j  S =  S 0 ] ) Partial specification of an operation Theorem Theorem ( ` 8 d  p ) 15