An Object - Oriented Approach in Knowledge Based Software Engineering of an Intelligent GUI∗ Maria VIRVOU, Katerina KABASSI Department of Informatics, University of Piraeus, Karaoli & Dimitriou 80, 18534, Piraeus, Greece E-mail:
[email protected];
[email protected] Abstract. This paper describes an object - oriented approach for the development of a Graphical User Interface that incorporates intelligence and deals with files and folders in a similar way as the Windows 98 Explorer. The system described is called IFM. IFM reasons constantly about users’ actions so that it may automatically offer help in case it believes a user may have made an error. IFM has an object – oriented component for the GUI and a knowledge base that is used by its user modelling component for the reasoning. We have used the Rational Unified Process and UML for the development of the whole of IFM, thus integrating the intelligent and the object oriented part. An empirical study and a requirements analysis were conducted during the requirements capture. The results were used for designing the system. After completing the implementation of a second release of IFM, an evaluation took place to find the system’s limitations in order to improve it.
1
Introduction
Graphical user interfaces are considered user friendlier than command language interfaces. However, as McGraw [1] points out, they may prove difficult to traverse and use if they are poorly designed; hence in addition to basic user interface guidelines, developers may also want to consider the feasibility and benefits of using AI to enhance the user interface. Intelligent File Manipulator (IFM) is a graphical user interface for file manipulation, similar to the Windows 98/NT Explorer, which also incorporates intelligence [2, 3]. It has the ability to reason about users’ actions and aims at providing spontaneous help and advice to users who have made an error with respect to their hypothesised intentions. However, the development of a user interface is an issue that needs a lot of attention. For example, Sutton and Sprague conducted a survey in IBM in 1978 [4], which revealed that 50% of the designer’s time was spent on designing the user interface of a system. The same result was also confirmed by a more recent survey by Myers and Rosson [5] in 1990s. Therefore, as Dix et al. [6] point out, it is definitely worth the effort to provide structure and techniques to understand and improve the interactive design process. If a user interface incorporates AI techniques the difficulty of the design process becomes even greater and so does the need for structure and techniques for the design process. ∗
The presentation of this work was supported by the Research Center of University of Piraeus.
The prevailing engineering paradigm for user interfaces is the iterative design [7, 4, 8, 9]. Therefore, the classical Waterfall model of life cycle is not appropriate. On the other hand, an object-oriented life cycle model, such as the one suggested by the Rational Unified Process [10, 11], seems more promising since it supports many iterations of the development phases. In addition, UML [12], which is the object-oriented modelling language that is supported by the Rational Unified Process, provides multiple diagrams that may illustrate a lot of the subtleties of the design of a user interface. Not only is it compatible with the object-oriented programming needed for the graphical user interface but it can also provide a powerful language for modelling the knowledge base of the intelligent user interface. In this paper, we show that UML and the Rational Unified Process may provide a powerful modelling language and a model of life cycle, which can be adapted to the needs of the design process of a GUI that incorporates intelligence, such as IFM. In the life cycle of IFM we have conducted many evaluations and/or empirical studies to ensure that the system addresses real users’ needs. Using UML we have modelled these users’ needs in the requirements capture. Moreover, we have represented the knowledge base of IFM using class diagrams. 2
Life cycle of IFM
In order to specify all requirements and design of IFM, an iterative development had to be adopted. Therefore the iteration of several phases of the development was considered crucial and the Rational Unified Process [10, 11] formed the basis for the life cycle of the system. According to the Rational Unified Process, during the life cycle of the system the architecture is prototyped, tested, measured and analysed, and then refined in subsequent iterations [13]. On this basis the software life cycle is divided into cycles, each cycle working on a new generation of the product developed. The process divides one development cycle in four consecutive phases: the inception, the elaboration, the construction and the transition phase [10, 11]. During the inception phase, a primary executable release of IFM was developed [2]. Its design originated from another system called RESCUER that was meant to provide assistance to users of command language interfaces, such as the interface of UNIX [14, 15]. In order to enhance the first version of IFM, another iteration of the software life cycle took place. The iteration started with the evaluation of the first prototype. Evaluation is an integral part of the design process and should take place throughout the design phase of the life cycle; most techniques for evaluation at this stage are analytic and involve using an expert to assess the design against cognitive and usability principles [6]. The method selected for the design evaluation was an empirical study that took place in the phase of the elaboration. In the empirical study expert and novice users of Windows 98/NT, were asked to work with a standard file manipulation program, such as Windows 98/NT Explorer as they would normally do. Each user’s actions were recorded using the computer logging method and were then analysed in order to identify the errors that users make while completing certain tasks. Human evaluators, using the video recording method observed the users’ actions issued during their interaction with the regular explorer and wrote down their comments about each action. The same protocols were also given to IFM as input, so that we would find out what IFM’s limitations were, in comparison with the human evaluators’ comments. The results of this process were models suitable for developing use cases. Use cases are needed for the formation of the so – called use case diagrams, which are incorporated in
UML for expressing the system’s required functionality. A use case is a description of the system’s behaviour during the interaction with an actor [16]. The use cases created resulted in the identification of the misconceptions users have while navigating through a standard “Windows Explorer” and which were not identified by the previous version of IFM. The limitations of IFM that were identified during the empirical study were analysed and the architecture of IFM was revised. This resulted in the creation of a component diagram, which represents all the implementation modules. Finally, in the construction phase the primary executable release of IFM was expanded. After completing the second executable release, a formative evaluation took place. The limitations of IFM identified in this evaluation are meant to be addressed in the third executable release of IFM. 3
Primary Executable Release
In the inception phase the primary executable release of IFM [2] was developed, during the preliminary iterations of the life cycle. IFM is a system that constantly reasons about users’ actions in order to diagnose problematic situations and give advice concerning the error identified. As Cerri and Loia [17] point out, if error diagnosis is to be performed, a user modelling component should be incorporated into the system. IFM’s user modelling component generates hypotheses about users’ plans and possible errors or misconceptions. An example of erroneous actions is clicking the wrong command or even the wrong files. However, there may be ambiguities about errors, since there may be different explanations of observed incorrect users’ actions [18]. IFM uses a simulator of human error generations and a limited plan recognition mechanism in order to resolve ambiguities about errors. The simulator of human error generations is based on a cognitive theory that attempts to formalise the reasoning that people use. This theory is called Human Plausible Reasoning [19]. Intelligent File Manipulator adapts this theory to provide a simulation of possible users’ errors. The limited plan recognition mechanism is used to improve the system’s control. Each action of a user can be considered as expected, neutral, suspect or erroneous, depending on its degree of compatibility with the user’s hypothesised intentions. In order to categorise the action in one of the four previous categories we have used a notion called ‘instability’. An instability is added when an action results to a new plan and deleted when the action leads to the continuation of a user plan that started earlier. For example, an instability is added when a user selects a copy command. This instability is removed when the user selects the paste command. An example of the system’s operation is the following: The user’s initial file store state is shown in figure 1. Folders are represented as boxes and files in plain text. The user intends to move A:\text1.txt into A:\documents1\. However, s/he accidentally attempts to move A:\ text1.txt into A:\documents2\. In this case, he runs the risk of overwriting the file A:\documents2\ text1.txt, which is a destructive action, by moving the file into the wrong folder IFM would suggest the user to move the file into A:\documents1\ instead of A:\documents2\ for two reasons: 1. The folder A:\documents1\ is empty whereas the folder A:\documents2\ is not. 2. If the command issued by the user is executed it will result in overwriting the file A:\documents2\ text1.txt, which will mean the loss of useful information. documents1
A:\
text1.txt
documents2 text1.txt
text2.txt
Figure 1 : Initial file store state
4
Requirements Capture
For the requirements capture we conducted an empirical study and performed requirements analysis. The empirical study involved end users of a standard explorer, which does not incorporate intelligence, such as the Windows 98/NT explorer. One of the main aims of the empirical study was to categorise as many users’ plans as possible and to identify the most frequent errors that expert and novice users may make while interacting with a standard Explorer. In this way, we could identify limitations of IFM. Another important aim of the empirical study was to evaluate IFM’s reactions, in comparison to the human expert comments. The results of that comparison were also used in order to identify IFM’s limitations so that we would enhance the specifications for a second version of IFM. 4.1
Empirical Study
The empirical study involved 7 novice and 8 expert users. All users were asked to work uninterrupted with a standard explorer such as the Windows 98/NT Explorer as they would normally do. All users’ actions were video recorded through computer logging. Then the protocols collected were given to 10 human experts to comment them. Furthermore, all human experts possessed a first and/or higher degree and had used extensively programs like the one studied or had teaching experience related to the use of such programs. The protocols collected were also given as input to IFM, so that we could record IFM’s reactions to these users’ actions. Finally, IFM’s reactions were compared to the human experts’ comments. In this way, we could evaluate IFM in terms of how successful it was at following the users’ reasoning as compared to human experts who were also asked to reason about the same users’ actions. By the comparison of the human expert comments to IFM’s reactions we found out that in the majority of the cases where IFM had diagnosed an error and generated an advice, its advice was similar to the majority of the experts’ advice (range of compatibility of advice: 89% - 100%). Moreover, a lot of limitations of IFM were identified, which resulted in the enhancement of IFM’s design, presented in more detail in Section 5. 4.2
Requirements Analysis
The plans recognised during the empirical study were used as input to the requirements analysis. Those plans were carefully studied in order to construct use case diagrams. Use case is a modelling technique used to describe what a new system should do or what an existing system already does [20]. Use case diagrams can represent requirements. In use cases we can identify actors and use cases. An actor can be anyone or anything that interacts with the system. Each actor usually represents a category of users. On the other hand, a use case may represent a functionality of the system. However, Muller, Haslewanter & Dayton [21] point out that there may be some problems with the use case driven approach. One problem is that the use case model usually is written with the software system as the focus of attention. They mean that the use cases give too little priority to the end users and that each use case has been made up by software
engineers to represent user actions. To overcome these problems it is necessary to model the use cases in participation with the end-users [22]. In the development of IFM we constructed use case diagrams as a result of a thorough empirical study that revealed the real users’ plans. Sequences of actions. In this way we identified the use cases where users tended to have problems and therefore IFM had to provide assistance. In particular, we have used use case diagrams to model all actions a user needs to perform to manipulate files. For example, the use case diagram in figure 2 describes the process that must be followed in order to copy or move items, folders or files, from a directory to another. The user must select the directory, where the items are, select the items s/he wants to copy and execute the copy or cut command. The items are then stored in clipboard and the user must select the target directory and execute the paste command. With the execution of that command, IFM identifies the state of the action. If the action is considered as expected or neutral the procedure is completed and the user can see the results of her/his actions to the file store. If the state considered by the system as suspect or erroneous, it searches for alternative actions and present them to the user. IFM’s reasoning and interaction with the user about possible errors is represented in the use case called “Use case diagram for moving or copying items”.
selection of directory
Search and presentation of alternatives
User
selection of item/s
Execution of cut command Execution of paste command
Execution of copy command
Identification of command's state
selection of new directory
Update filestore
User Figure 2: Use case diagram for copying or moving items
5
Analysis and Design
The conclusions drawn from the requirements capture were used as input to analysis and design and therefore led to the extension of IFM’s design. Certain observations in the requirements capture resulted in the augmentation of the instabilities used in the primary release of the system. Careful study of the users’ errors revealed new categories of errors that had not been taken into account before. Some of these errors were quite important and
their identification led to a significant improvement of the system. For example, it was observed that users often deleted folders without being sure about the contents of these folders. Finally, the empirical study showed that users tend to reproduce the same mistakes over and over again. In order to have more individualised user advice, IFM keeps a long term user model for each user, which consists of long term information about a user [23, 24]. The long term user model holds a profile of the user that may be acquired during several interactions of the user with the system. The long term user model is used in order to diagnose and provide advice in a more individualised way. The study of users’ plans during the requirements analysis revealed the fact that users issued more commands than those included in the domain representation of IFM’s primary design. Therefore, the domain representation was extended to include several new commands. These commands had to be represented in hierarchies in the knowledge base of the system. User Action
Selector
Clipboard
T : item;
Open T : item;
Select
Copy
Cut
Creator T : Folder;
Inf ormationProv iders
T : item;
Explore T : Folder;
delDir T : Folder;
mkFile
Paste
mktxt
mkdoc
Modif ier T : item;
Destroy er
delFile T : File;
Rename
mkDir
mkbmp
mkWav
Figure 3: A Class diagram representing part of IFM’s knowledge base.
We have found out that UML notation may be quite suitable for modelling our knowledge base. In the case of Prolog, a term may be represented as a class and its arguments as attributes of the specific class. Furthermore, UML relationships can be used to represent predicates (also called relations). We can distinguish predicates into three categories according to their semantics. Predicates that correspond to an isa relationship can be represented by a UML generalisation, for example isa(selector(T),userAction). Others that correspond to an ispart relationship can be represented by a UML aggregation, for example contains(sugar,cake). Finally, UML association represents predicates that cannot be categorised into one of the above categories, for example siblings(bob,mary). A hierarchical, tree-structured knowledge base may be presented by means of generalisations. In particular, in IFM we have used a class diagram in order to represent the structure of the Prolog predicates involved (figure 3). Each term situated in a leaf of the tree structure corresponds to a user’s action. Higher-level terms indicate the categorisation of users’ actions, namely Selector, Clipboard, Information Providers, Creator, Destroyer and Modifier. The attribute T represents the item involved in user’s action. T can be a folder, a file, or either a folder or a file (an item).
6 Implementation Based on the analysis and design, the implementation of the second release took place. In order to illustrate the implementation modules and their dependencies we use the component diagrams, which show the structure of the code for the implementation. Each component in a component diagram can be a source code component, a binary component, or an executable component [20]. Figure 4 is a component diagram that illustrates the connection between the knowledge-based part of IFM and the object-oriented part. The knowledge-based part provides the reasoning for the GUI. The component that corresponds to this reasoning is “logic.ql” which is implemented in Prolog. The rest of the components are all implemented in Delphi’s Pascal. The component ‘main.pas’ is the code for the file manipulation system and the identification of user’s actions. This component communicates with “logic.ql” in order to create alternative commands to show them to the user. If the system find an alternative that can be considered as expected or neutral, the system informs the user using ‘alternatives.pas’ and afterwards, the user states her/his next actions. Finally, the component “login.pas” corresponds to the verification of the user. Logic.ql
main.pas
alternati ves.pas
login.pas
Figure 4: Component diagram
7 Testing IFM IFM’s second executable release was evaluated using half of the protocols collected during the empirical study. Those protocols were used in order to compare human experts’ comments to the reactions of the new version of IFM. The results of this testing procedure showed that IFM was quite successful at achieving a high degree of compatibility with the experts’ advice. The most important problem derived by the evaluation was that in many cases IFM generated a lot of alternative commands. In most of the cases, the suggestion of the majority of the experts was compatible with one of the alternative commands, generated by IFM. The system should be capable of selecting the most possible ones. This limitation is to be addressed in a subsequent executable release of IFM that will take place in new iterations of the system. 8 Conclusions IFM is a graphical user interface that incorporates intelligence so that it may address situations where users may have made mistakes that did not intend. A system like this needs multiple iterations of its development cycle so that many evaluations involving users may take place. The Rational Unified Process has been used as a model of IFM’s life cycle and UML has been used for modelling several aspects of the system. The Rational Unified Process has provided a very satisfactory framework for the development of IFM ensuring the necessary multiple evaluations, involving real users. A lot of limitations of the first executable release were identified and addressed in a second release. Currently, further
improvements have been specified to be addressed in the next future release. UML’s use case diagrams have provided a satisfactory technique for modelling the user’s needs that resulted from the multiple evaluations. In addition, the use cases of IFM were specified as a result of empirical studies and/or evaluations which ensures the fact that these use cases really represent user requirements rather than the beliefs of software engineers about users. Finally, UML has provided a sufficiently powerful modelling language not only for the object-oriented features of IFM but also for the knowledge-based part of it and the integration of both parts. Acknowledgements The authors would like to express their appreciation to M. Moundridou for her useful comments. References [1] [2] [3]
[4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14]
[15] [16] [17] [18] [19] [20] [21]
K.L. McGraw. Performance Support Systems: Integrating AI, Hypermedia and CBT to Enhance User Performance. Journal of Artificial Intelligence in Education, 5 (1), (1994), pp. 3-26. M. Virvou & A. Stavrianou. User Modelling in a GUI. Proceedings of the 8th International Conference on Human-Computer Interaction (HCII 99), Munich, Germany, 1, (1999), 262-265. M. Virvou & K. Kabassi. An Empirical Study Concerning Graphical User Interfaces that Manipulate Files. To appear in proceedings of World Conference on Educational Multimedia, Hypermedia and Communications (ED-MEDIA 2000), Montreal, Canada, (2000). J.A. Sutton & R.H. Sprague Jr. A study of display generation and management in interactive business applications, (Rep. RJ2392), IBM, 1978. B.A. Myers & M.B. Rosson. Survey on user interface programming. CHI’92 Conference Proceedings of the Conference on Computer Supported Cooperative Work, (1990), pp. 195-202. A. Dix, J. Finlay, G. Abowd & R. Beale. Human-Computer Interaction, NY: Prentice-Hall, 1993. I. Sommerville, Software Engineering. Addison-Wesley, 1992. B. Scheiderman. Designing the User Interface. Addison-Wesley, 1998. D.R. Olsen, Jr. Developing User Interfaces. Morgan Kaufmann Publishers, Inc, 1998. P. Kruchten. Rational Unified Process-An Introduction, Addison-Wesley, 1999. T. Quatrani. Visual Modeling with Rational Rose and UML, Addison-Wesley, 1998. Gr. Booch, J. Rumbaugh & I. Jacobson. The Unified Modeling Language User Guide. AddisonWesley, 1999. P. Kruchten. The 4+1 View Model of Architecture. IEEE Software, 12 (6), (1995), pp. 42-50. M. Virvou. RESCUER: Intelligent Help for Plausible User Errors. Proceedings of ED-MEDIA, EDTELECOM 98, World Conference on Education Multimedia and Educational Telecommunications, 2, (1998), 1413-1420. M. Virvou & B. Du Boulay. Human Plausible Reasoning for Intelligent Help. User Modeling and User Adapted Interaction, 9, (1999), pp. 321-375. I. Jacobson, M. Christerson, P. Jonsson & G. Overgaard. Object-Oriented Software Engineering. A Use Case Driven Approach. Addison-Wesley, Wokingham, England, 1992. S. A. Cerri & V. Loia. A Concurrent, Distributed Architecture for Diagnostic Reasoning. User Modeling and User Adapted Interaction, 7(2), (1997), pp. 69-105. A. Mitrovic, S. Djordjevic-Kajan, L. Stoimenov. INSTRUCT: Modeling students by asking questions. User Modeling and User Adapted Interaction, 6(4), (1996), pp. 273-302. A. Collins & R. Michalski. The Logic of Plausible Reasoning: A core Theory. Cognitive Science 13, (1998), pp.1-49. H.E. Eriksson & M. Penker. UML Toolkit, John Wiley & Sons, Inc, 1998. M.J. Muller, J.H. Haslwanter & T. Dayton. Participatory Practises in the Software Lifecycle, In M. Helander, T.K. Landauer, & P. Prabhu (Eds.), Handbook of Human-Computer Interaction (pp. 255297). Elsevier Science B.V., Amsterdam, 1997.
[22] [23] [24]
M. Lif. User Interface Modelling – adding usability to use cases (Rep. No 84 CMD). Uppsala University, 1998. E. Rich. User Modelling via Stereotypes. Cognitive Science, 3 (4), (1979), pp. 329-354. J. Jones & M. Virvou. User modelling and advice giving in Intelligent Help Systems for UNIX. Information and Software Technology, 33, (1991), pp. 121-133.
