Formal Refinement of Informal GUI Design Artefacts Judy Bowen Department of Computer Science University of Waikato Private Bag 3105, Hamilton, New Zealand jab34@cs.waikato.ac.nz Steve Reeves Department of Computer Science University of Waikato Private Bag 3105, Hamilton, New Zealand stever@cs.waikato.ac.nz Abstract Before we build any piece of software we would, surely, need to be certain that what we intend to build is what is re- quired by the users of that software. In addition, we would want to be sure that the proposed software will behave as expected, do the right thing under all circumstances and also be usable. These functional and usability requirements are often considered separately. The functional require- ments may be considered by way of formal specifications or models which are then subjected to verification and valida- tion to ensure that the required properties hold. Similarly, the usability and user requirements may be captured using task analysis methods and checked by design methods such as GOMS, scenario development and usability testing of in- cremental prototypes. This paper looks at one way of bring- ing these two processes together by including the graphical user interface (GUI) design process and design concerns in the formal process of specification and refinement. In par- ticular it considers what it means for a prototype of a GUI to be considered as a formal refinement of a specification. In this paper we will show how we can consider the visual dis- play, or presentation, of the GUI as the refinement, rather than the code which produces that presentation, and how this allows us to apply standard and well-known refinement techniques to informal design artefacts. 1. Introduction The importance of providing well-designed, usable graphical user interfaces for applications is well-known, and has been the subject of a great deal of research for many years. Similarly, the importance of ensuring that the ap- plications we build are correct and robust is equally well- known, and a variety of methods, both formal and informal, exist to ensure that we are able to do this. We are inter- ested in formal software engineering processes (strong soft- ware engineering is becoming the accepted phrase for this) which allow us to prove that the software we build will sat- isfy the requirements for that software, and further, that it will behave as required and expected under all conditions. It is not uncommon for the GUI of an application and the underlying functionality of that application to be con- sidered separately during the design process. Many formal software engineering processes ignore the GUI at the early stages of design and development, concentrating solely on overall system functionality. At the same time GUI design processes treat the GUI itself in isolation from the rest of the system. At some stage, however, these two separate de- sign strands must be brought together so that the final im- plementation of the application can be created. At this stage we must hope that not only have the two strands of develop- ment been successful in performing their separate tasks and have produced an application and GUI which will satisfy all requirements, but also that there are no conflicts when we combine the two parts of the design. One of the problems with this approach of separating the system functionality from the GUI is that it assumes there is a clearly identifiable separation of the behaviour of the GUI and the behaviour of the underlying system. However, this is not always the case. If we look at currently popular de- sign environments and methodologies such as the Microsoft .NET framework or the J2EE platform as well as the growth of web-based applications, we see that it is often very diffi- cult to perform this separation of functionality. The GUI of such systems often directly performs much of the function- ality of that system and there is no clear separation. This is just one example of why it is important to include the GUI in our early formal system specifications and find ways of supporting GUI design which are based on the same rigor- ous proof of correctness as the rest of our system. The ben- efits that formal specification and verification bring to our system design are clearly just as desirable in GUI design. There are, of course, existing formal methods that are designed exactly for the purpose of describing and mod- elling GUIs. These may be based on early works such as the P.I.E.method [7] or Interactors [9], but increasingly re-