WO2001022227A1

WO2001022227A1 - Computer program for multiple types of user interfaces and method for testing such computer programs

Info

Publication number: WO2001022227A1
Application number: PCT/NL1999/000580
Authority: WO
Inventors: Gerrit Johannes De Vries
Original assignee: Actuarieel Adviesbureau Vermaase B.V.
Priority date: 1999-09-20
Filing date: 1999-09-20
Publication date: 2001-03-29
Also published as: AU5884799A

Abstract

Computer program for communicating with an environment (6) by means of a predetermined user interface (5), comprising at least an interface layer (4) for communication with the user interface (5) and with an application model layer (2), the application model layer (2) modelling a predetermined functionality. The interface layer (4) is arranged to construct user interface elements which implement the communication with the user interface (5) and the application model layer (2) for a specific type of user interface (5), and to retrieve, at least during execution of the computer program, information on the construction of the user interface elements from a user interface description (3). Furthermore, a method for testing the application model layer (2) is described, the method being implemented by exchanging the interface layer (4) by a test engine (20) and the user interface description (3) by a test script (22).

Description

Computer program for multiple types of user interfaces and method for testing such computer programs

The present invention relates to a computer program for communicating with an environment by means of a predetermined user interface, the computer program comprising at least an interface layer for communication with the user interface and for communication with an application model layer, the application model layer modelling a predetermined functionality.

Such a software architecture is known from the prior art, e.g. from Glenn E. Krasner and Stephen T. Pope, "A cookbook for using the model-view-controller user interface paradigm in Smalltalk 80", Journal of Object Oriented Programming, pages 26-49, August/September 1988.

The Model-View-Controller (MNC) architecture comprises an application layer and an interface layer. The application layer comprises models, which are objects that implement the domain specific parts of an application. The interface layer comprises views, which are objects that present some aspects of a specific model to the application's environment, usually the user interface, and which are associated with exactly one model. However, a model can have zero, one or more views associated with it. Controllers are the interfaces between input devices and a model. Data inside a model can be changed by a view by using a controller. An active controller may accept input from the user interface and call methods from the associated model to change it accordingly. The model performs the requested action and sends update messages to its dependent views, being the associated views, which update their presentation of the model. Although the MNC-architecture provides user interface independence for the application layer to a certain extent, this architecture has a number of drawbacks Usually, the interface layer still comprises a lot of model dependent information, as the controllers and views have to know something about their associated models. Models may pose conditions on their use (such as allowable input values) and on their state. The model can be extended to handle infraction of these conditions, but usually, it will make a model very complicated, and a possible source of programming errors. It is more viable to let the controllers handle these kinds of conditions, as these are able to disable input, limit input ranges, etc. This, however, has the disadvantage that the controllers will include part of the computer program that is independent of the type of user interface being used. When porting the application to another type of user interface, the controllers in the interface layer will have to be re-implemented and tested again. When using the MVC-architecture, the models, views and controllers will be constructed during runtime. The controllers can be constructed by the views, both comprised in the interface layer. Some part of the system will have to decide when specific views and models have to be introduced in or removed from the system. To maintain user interface independence, construction of views should be a task of the interface layer. However, as the construction of views may vary a lot among distinct types of user interfaces, this should be programmed separately for each interface. Again this may partly not be dependent on the type of user interface being used, leading to the same problems with regard to re-implementing and testing as above.

In the MNC-architecture, controllers and views are distinct for every application. This leads to a requirement not only for a custom interface layer for every type of user interface, but even for every application for the same type of user interface.

In summary, an obviously user interface independent part of an application may be separated from the remainder of the application, but still part of the application should be rewritten for porting the application to a different type of user interface. The latter part contains code that is independent of the type of user interface. In addition, the enforcement of model conditions as well as the construction process of views may result in complex and fault prone source code. The resulting code is different on every target type of user interface, and should therefore be separately tested for every type of user interface. The object of the present invention is to provide a computer program, which is adaptable to multiple types of user interfaces. A further object of he present invention is to provide a method for the testing of an application model layer for a computer program according to the present invention.

The first object is achieved by a computer program according to the preamble defined above, characterised in that the interface layer is arranged to construct user interface elements and to retrieve, at least during execution of the computer program, information on the construction of the user interface elements from a user interface description, the user elements implementing the communication with the user interface and the application model layer, and implementing the functionality of the interface layer for a specific type of user interface.

The computer program according to the invention makes it possible to develop computer programs for different kinds of user interfaces, and, in a second aspect, to automate the testing of these computer programs. Note that 'user' does not necessarily mean 'human user'. A user might be another computer program, service, or process as well. Thus the computer program according to the invention can relate to applications that are intended for human end-users, as well as the components of component based software. In the latter case, the user interface is shaped in terms of the middleware, and the users are the external components. The concept of user interface will be utilised throughout this patent application to indicate both cases.

A user interface can be interpreted as being part of the environment of a particular computer program. The environment includes the computer hardware and operating system, next to the type of user interface. Effectively, a computer program that runs under Windows '95, but employs a Braille interface for blind people is meant for a different environment than a computer program on the same computer that uses the normal Windows '95 interface.

The architecture of the computer program according to the present invention may be used as the basis of an application framework. Application frameworks can be extended in a prescribed way in order to develop end-user applications. Application programmers may extend such a framework with domain specific source code, while developing a program. The part of the framework that actually depends on the type of user interface can easily be replaced by interface layers that target distinct types of user interfaces. The architecture enforces that the application specific source code is independent of the interface layer, and vice versa. This in its turn allows that the application model layer, modelling the functionality of the software program, can be developed and tested only once for multiple types of user interfaces. It can then be combined with numerous specific interface layers, which may be made available for numerous types of user interfaces, thus enlarging and facilitating the portability of the developed application model layer.

A computer program according to the present invention will have one distinct part, the application model layer, which will not directly interact with the user interface associated with that computer program. The application model layer comprises the functionality of the software program, information being present in application specific entities. The interface layer elements will handle all communication with the user interface, translating information in the application specific entities into user interface specific entities and vice versa. The user interface description is the only part of the computer program that is specific for both the functionality of the computer program as well as for the environment (more specifically, type of user interface) of the computer program.

In a preferred embodiment of the computer program according to the invention, the user interface description comprises a description of user interface elements for the computer program in a predetermined format and the means for constructing are arranged to read and interpret the format of the user interface description. This may be accomplished by allowing the interface layer to have direct access to the user interface description, enabling the interface layer to read and interpret the information contained in the user interface description. Also, the user interface description may be transformed in a format readable by a specific interface layer. Alternatively, the user interface description may be transformed into a separate module, which will become part of the computer program during execution. Finally, the user interface description may provide the information in a type of programming language, ready to be added to the interface layer and the application model layer. In a further embodiment, the communication between the interface layer and the application model layer is implemented by means of events, events being pieces of software code that are being called under predefined circumstances, and the user interface description further describing the declaration of events and the circumstances under which the events are to be invoked by the interface layer. This enables the application model layer to be independent from the particular interface layer to which it is coupled to form the computer program.

In a still further aspect, the present invention relates to a method for testing a computer program constructed according to the present invention.

The testing of computer programs with Graphical User Interfaces (GUI's) is often a labour intensive task. Intuitively, this task may benefit from automation, but in practice a lot of the test work has to be done manually. The testing of a computer program can be divided into three subtasks: generation of test cases, execution of these test cases, and evaluation of the program results. Additionally, the test cases and their results can be saved for later use, so that it can be checked that the functionality of tested program components does not alter during the development process. This is called regression testing. Each of these tasks, including regression testing, can be automated with currently available tools. However, it still seems practically impossible to automate the integration of the just mentioned different tasks without a lot of human intervention and manual assistance. This is especially true if the Program Under Test (PUT) uses a GUI.

The method of testing software programs according to the software architecture of the present invention addresses the following three problems: 1) There exist numerous tools that assist in the automation of computer program testing. However, it remains practically impossible to automate the whole cycle of (1) test case generation, (2) test case execution, and (3) result evaluation. 2) Tools that exist for the automation of the regression tests of computer programs with GUI's, e.g. Capture/Playback tools are frequently targeted towards one type of user interface. It is difficult to convert the data that is gathered by such tools to formats that are applicable to other types of user interfaces. A third disadvantage of Capture Playback tools is that a simple change to the user interface may invalidate the captured regression tests.

The second object of the present invention is achieved by a method for testing computer programs according to the present invention. The method comprises the step of testing the application model layer by means of a test engine, the test engine replacing the interface layer and being arranged to simulate user actions. Preferably, the method comprises the step of testing the application model layer by means of a test engine, the test engine replacing the interface layer and being arranged to simulate user actions, and a test script declaring the events and the circumstances under which the test engine should invoke the events, the test script replacing the user interface description. Thus, by replacing the interface layer by a test engine and the user interface description by a test script, it is possible to test the application model layer once, independent of the user interface. In a further embodiment, the method further comprises the step of checking responses of the application model layer to events by means of information with regard to correct behaviour of the application model layer comprised in the test script, allowing automatic checking of the correct behaviour of the application model layer. The computer program according to the present invention has been described above in a two-layer architecture. However, practical implementations of the computer program are also possible in a three-layer architecture. In a further embodiment, the interface layer comprises an abstract interface layer and a concrete interface layer, the concrete interface layer being arranged to access the application model layer via the abstract interface layer and the concrete interface layer being arranged to communicate with the user interface. Dividing the interface layer in two parts, an abstract interface layer, modelling an abstract representation of the interface, and a concrete interface layer, modelling the user interface as it appears to the end-user, allows easier implementation of the present computer program.

The application model layer is preferably arranged to model the core behaviour of the software program in the form of documents, documents being software objects encapsulating and managing application data. Furthermore, the application model layer is preferably arranged to connect to the abstract interface layer by the use of events, events being pieces of software code that are being called under predefined circumstances.

The abstract interface layer preferably comprises document adapters and error- identifiers, document adapters being objects that extend a document in the application model layer with information about its representation in the user interface by references to the document and in which error identifiers are abstract entities used to identify errors that events may return.

The computer program further comprises at least one interface declaration, each of the at least one interface declarations being related to one application model layer, the abstract interface layer being initialised during execution of the computer program by the at least one interface declaration, the at least one interface declaration comprising part of the state information of the document adapters, available error- identifiers and an identification of a main document adapter. The interface declaration is specific for a particular application model layer, and is therefore independent from the type of user interface and independent from the interface layer. Preferably, the concrete interface layer comprises at least one view, the at least one view being an object that implements a core functionality of a predetermined element of the user interface, the core functionality comprising a presentation of the state and document value of a document adapter in the abstract interface layer, handling of messages from document adapters in the abstract interface layer and handling input from the user interface, by calls to associated document adapters.

The computer program further comprises at least one interface instantiation, each of the at least one interface instantiations being related to one application model layer, the concrete interface layer being initialised during execution of the computer program by the at least one interface instantiation, the at least one interface instantiation comprising part of the state information of the views, including a relationship of the views with the document adapters in the abstract interface layer, an identification of a main view, and a representation of error-identifiers in the user interface. The interface instantiation is dependent on the type of user interface and dependent on the specific combination of an application model layer and an interface layer. The interface declaration and interface instantiation provide the mechanisms for initialising the various parts of the computer program. It will be apparent that the interface instantiation must match the interface declaration. This can be checked manually or by means of a parser, being a specific computer program having that functionality.

The application model layer of computer program with a three-layer architecture may be tested by a method comprising the step of testing the application model layer (AML) by means of test cases executed by a test engine, the test engine replacing the concrete interface layer (C L). The test engine is a user interface module in itself, although it is not meant to communicate with the ordinary program users. Instead it tries to simulate their behaviour, and evaluates the program's responses to that behaviour.

The test engine is in fact just another concrete interface layer. However, it does not communicate with the end-user(s), but instead tries to simulate their potential behaviour, while observing the resultant program responses. Initially, one can make the following remarks about the controllability, observability, and detectability:

1) Controllability: the test engine has all the information that was present in the interface declaration (via the abstract interface layer). Effectively, the engine knows exactly which actions a user might perform. The engine can simulate these actions by calling the appropriate methods in the abstract interface layer.

However, because the state of adapters might change in response to these actions

(through the execution of events in the application model layer), the engine can not determine a complete test case a priori. Instead it should perform an action and wait for the responses, before it can determine the next action.

2) Observability: the test engine gets notification messages if the application model layer changes the state or document value of an adapter. This includes all changes that affect the representation of data in the user interface. Further, the engine contains the code that handles assertion failures and trace messages, thus it may observe these too. Finally, exceptions that are not handled by the application model layer and abstract interface layer can be caught by the test engine.

3) Detectability: assertion failures are a direct indication of incorrect program behaviour.

In a preferred embodiment, the method further comprises the step of initialising the test engine by a test script before execution of the test cases, the test script matching the corresponding interface declaration associated with the application model layer, and configuring the test engine. Preferably, the step of initialising the test engine is executed by means of test views in the test script, the test views comprising descriptions for constructing a simulated user action (SUA), the simulated user action being used to define a simulated input to a document adapter in the abstract interface layer. The test engine is responsible for the construction of simulated user ations according to the descriptions provided in the test script, and the execution of these simulated user actions.

These embodiments allow an influence on the generation of test cases, in order to direct the testing of an application. This enables testing only a portion of a program, stress certain parts, or try to achieve a certain degree of code coverage. Additionally, the detectability is increased. Such a test script is comparable to an interface instantiation, in the sense that it must match the interface declaration, and that it configures the concrete interface layer (the test engine).

In a further embodiment a simulated user action is constructed after executing a previous simulated user action. Furthermore, a composite simulated user action related to a composite document adapter in the abstract interface layer is constructed as an algorithm for constructing member simulated user actions, the step of executing a composite simulated user action comprising the steps of a) constructing a member simulated user action, b) executing the member simulated user action and c) repeating steps a) and b) until the member simulated user action is executed which simulates an action of closing user interface elements related to the associated document adapter in the abstract interface layer.

According to an embodiment of the invention, the method further comprises the step of initialising the test engine by use of a test script parser, the step of initialising the test engine comprising the steps of checking whether configuration information for construction of test views is provided for each document adapter in the abstract interface layer and add default test view configurations for each document adapter in the abstract interface layer for which a test view is required but no configuration information is present in the test script. The default test view configurations depend on the type and state information of the document adapter, as provided in the interface declaration. This embodiment allows the testing of a software program without defining the test script up front, as the test script parser can still construct meaningful test cases.

A further embodiment of the method according to the present invention further comprises the step of recording the software program's behaviour during execution in a test base. This allows either manual or automatic test result evaluation or validation.

Preferably, the software program is tested by an embodiment comprising the steps of: a) creating an empty test base for storage of test cases; b) activating a main test view; c) constructing a simulated user action; d) saving the simulated user action in a temporary file; e) starting a copy of the software program for executing the simulated user action, comprising the steps of el) reading simulated user action from temporary file; e2) finding test view associated with simulated user action; e3) executing simulated user action; and e4) exiting the software program, saving the simulated user action containing information about performed user interface actions, program responses to these actions, and evaluation information; f) adding the saved simulated user action to the test base; and g) repeating steps b) through f). The test base will then comprise all information of the test cases run, allowing test result evaluation and regression testing.

In a further embodiment, the test script further comprises methods for evaluating and/or validating the computer program's responses to the simulated user actions. These methods are preferably comprised in the test views. Alternatively, the methods for evaluating and/or validating are comprised in hook functions, the hook functions being included in the computer program and comprising methods for validating conditions related to execution of a simulated user action. The hook functions are easier to implement than methods comprised in the test views. The hook functions should be declared in the test script, preferably as part of the configuration of the test views.

Using the test results in the test base, it is possible to perform regression testing during development of a computer program or when porting a computer program to another type of user interface. To this end, the method further comprises the step of regression testing by re-executing the test cases stored in the test base. Preferably, the method further comprises the steps of checking whether a test case, which is to be re-executed, is still a valid test case for the computer program, i.e. whether each simulated user action which is present in the test case still relates to a valid user action for the computer program. The dynamic behaviour of the computer program is disregarded at this point.. Furthermore, the method may comprise the step of checking whether a simulated user action in a test case, which is to be re-executed, can be adapted to the computer program, and if this check is positive, adapting a simulated user action in a test case.

A further aspect of the present invention relates to a computer readable storage medium comprising a computer program according to the present invention. Also, a further aspect of the present invention relates to a method for developing a computer program according to the present invention.

By replacing part of the computer program according to the present invention with a test engine, it becomes possible to automate the testing of those computer programs. The test engine is, due to the described architecture, able to generate, execute, and evaluate test cases automatically. The test engine can also record the program's behaviour during execution, in order to automate regression testing. Regression tests are portable to all supported types of user interfaces. Changes in the layout of a GUI do not influence the regression tests (as is the case with Capture/Playback tools)

The whole process of generating and executing test cases, evaluating the program's results, as well as regression testing can be automated by means of the described method

The present invention will now be clarified by means of examples, with reference to the accompanying drawings, in which

Fig 1 shows a diagrammatic view of the 2-layer composition of a computer program according to the invention, during execution of the computer program, Fig 2 shows a diagrammatic view of the 2-layer composition of a computer program according to the invention, during testing of the computer program,

Fig 3 shows a diagrammatic view of the 3 -layer composition of a computer program according to the invention, during execution of the computer program,

Fig 4 shows a diagrammatic view of the 3-layer composition of a computer program according to the invention, during testing of the computer program

The growing interest and trust in object oriented design methods has resulted in different kinds of application frameworks These frameworks form the basis of computer programs They can be extended in a prescribed way in order to develop end- user applications Thus, application frameworks make it possible to reuse not only source code (as program libraries do), but to reuse design ideas as well The architecture of an application framework can be described by identifying the different design patterns that are used in the architecture A design pattern characterises a reproducible similarity in a design, see for example Erich Gamma, Richard Helm, Ralph Johnson, and John Nlissides Design Patterns: Elements of Reusable Object- Oriented Software. Addison- Wesley, 1996 By using design patterns to describe architectures, one identifies the distribution of responsibilities among objects, their integration, and collaboration

Computer software is interactive in its nature It collects input and generates output based on this input New input may depend on previous output in the same run, allowing interleave of input and output in some sort of conversation The input does not have to be generated by a human user It could be gathered from external devices, other computer programs, operating system services, etc Likewise, the output can be presented to a human, might result in the movement of a robot arm, etc For all these kinds of input and output, the computer program needs some sort of interface, which is called the user interface.

To test a computer program, one must be able to generate test cases that simulate the potential behaviour of the user(s) of the Program Under Test (PUT). The generated test cases have to be executed, and the program results should be evaluated. Three concepts play an important role in this process:

1) Controllability: the tester has to be able to control the application and its environment, in order to simulate the possible circumstances under which the PUT can be utilised, and in order to make the results of the test cases reproducible. Controllability relates to program input in its widest sense (every circumstance that might influence the behaviour of a computer program).

2) Observability: the tester must get enough information about the way that a program affects its environment, so that it becomes feasible to check if the program affects its environment as required. Observability relates to program output in its widest sense.

3) Detectability: it must be possible to differentiate correct from incorrect program behaviour. Detectability is the probability that failures will be detected if they are observed.

Test scaffolding is a well-known technique that may improve the observability and controllability of a certain module in a computer program. The module is isolated from the rest of the program (the module's environment), which is replaced by drivers and stubs. The drivers generate the necessary input for the module, the stubs may improve the observability. Test scaffolding is not always a feasible technique. For instance, when one wants to test a program entirely, the environment is not so easy to replace, because it consists of the Operating System, its services, and users. For simple command-line tools, I/O redirection might be a good alternative. However, for more complex computer programs one has to use other means. Particularly GUI's are practically impossible to test through test scaffolding or comparable methods. Yet, by dividing such an application into several layers, test scaffolding may become a viable technique. We will illustrate the terms that must be satisfied from the following two layers (see Figure 1):

1) Interface Layer 4 (EL)

2) Application Model Layer 2 (AML) During running of an application 1, an interface layer 4 communicates with an environment 6 of the application 1 via a user interface 5, gathering input from the users and presenting output to them. The application model layer 2 has to use the interface layer 4 to communicate with its environment 6 via the user interface 5. Effectively, the interface layer 4 is the environment of the application model layer 2. Provided that the interface layer 4 is independent of the application model layer 2 to which it is coupled, one interface layer 4 can be used with lots of different application model layers 2. Effectively, it makes sense to test the interface layer 4 thoroughly, separate from a specific application model layer 2. Moreover, a particular application model layer 2 can be tested through a test engine 20 that replaces the interface layer 4, as shown in Fig. 2.

A software program developed with the software architecture according to the present invention will have one distinct part, the application model layer 2, which will not directly interact with the user interface 5. The application model layer 2 comprises the functionality of the software program 1 , information being present in application specific entities. The interface layer 4 will handle all communication with the user interface 5, translating information in the application specific entities into user interface specific entities and vice versa.

In the following, the interface layer 4 will be identified by IL and the application model layer 2 by AML. The following criteria have to be met, in order to make this architecture practical:

1) All communications, or at least the ones that must be controlled and observed during testing, should pass the LL 4. Thus, the program's environment 6 communicates via the user interface 5 with the LL 4, which will communicate with the AML 2 if that is required. Conversely, the AML 2 has to use the IL 4 if it requires some service from the program's environment 6 via user interface 5, especially if it expects a user to generate some input.

2) The IL 4 must have one implementation per user interface 5. Consequently, the implementation of the IL 4 has to be independent of a specific AML 2. Infraction of this demand results in a separate LL 4 for every program that will be developed. Testing an IL 4 faces the same practical disadvantages as testing a computer program without the described architecture. If a separate IL 4 is required for every AML 2, then there is nothing to gain from the architecture. Note that Data-View (DN) and Model-Niew-Controller (MVC) architectures do not conform to this criterion The MNC architecture is described in Glenn E Krasner and Stephen T Pope A cookbook for using the model-view-controller user interface paradigm in Smalltalk 80 Journal of Object Oriented Programming, pages 26-49, August/September 1988 The DV architecture is a derivative of MVC

3) The AML 2 must be independent of the particular LL 4 to which it is coupled Thus the interface that the LL 4 offers to the AML 2 must be independent of the user interface 5 This demand ensures that the IL 4 can be replaced easily by distinct IL's 4 that target other types of user interfaces 5 The design would be even better if the implementation of the test engine 20 that replaces an IL 4 for testing does not depend on the actual AML 2 as well Then, one test engine 20 can be used to test every possible AML 2 that is developed by use of the described two-layer architecture The test engine 20 is just another IL 4, only now the IL 4 does not interface with the usual end-users Instead, it tries to simulate their behaviour and to evaluate the program's responses to that behaviour This adds the following criteria to the previous ones

4) There must be enough meta-information about the PUT available in the IL 4, such that the IL 4 knows what actions the user(s) may perform when they run the computer program This demand relates to the concept controllability 5) The LL 4 has to know how the AML 2 can respond to these actions, and must have the means to detect these responses This demand relates to observability 6) The LL 4 should have the means to differentiate among correct and incorrect behaviour of the AML 2 This demand relates to detectability Ideally, if one develops a computer program by use of this architecture, distinct IL's 4 already exist for the targeted types of user interfaces 5 The application developer adds an AML 2, and tests it with an appropriate IL 4 (test engine 20) When the AML 2 is considered shippable, it will be built into an application for a specific type of user interface 5, by combining it with an LL 4 that targets the requested user interface 5

Criterion 1 can be used to define what should or should not be part of the IL 4 Every part of the computer program's environment 6 that an AML 2 addresses directly, without the use of the intervening IL 4, might contribute to extra effort in case some distinct EL 4 targeting another environment 6 needs to be used This may have consequences for the described test method as well In order to meet criterion 2, the implementation of the LL 4 will differ considerably from a similar implementation in the MVC architecture. The LL 4 has to be used by various different applications, probably even from different application domains. Effectively, the LL 4 does not provide application specific user interface elements. However, it should provide the necessary means to construct them. The LL 4 implements all functionality for creating a user interface 5 for a computer program 1. It does, however, not implement any particular (application specific) user interface 5. In case the kind of user interface 5 that an IL 4 targets is a GUI, the IL 4 has to provide at least the code for creating and managing dialog boxes, menus, edit boxes, widgets, and other user interface entities. Yet, it will not provide the code to create and control, e.g., a specific "Customer Data" dialog box. Such code is application specific, and does therefore not belong to the LL 4. (Note that in the MVC architecture such code is supposed to be part of the IL 4.) On the other hand, such code is not supposed to be part of the AML 2 either. Clearly, the code will depend on the particular IL 4 for which it is written, and according to the criterion the AML 2 should not depend upon any particular IL 4. Therefore, information about the presentation of a specific user interface 5 for a specific computer program 1 should be kept separately from both layers 2, 4. It is possible to capture this information in a separate description, the user interface description 3 (UID). The ULO 3 is called a description, because it does not (necessarily) require any true programming. Instead the ULD 3 just summarises all user interface elements that together shape a user interface 5 for a specific computer program 1, and describes their properties and relations. A valid description in a GUI might say that there is a dialog box called "Customer Data" in the user interface 5, having two child windows, the first one being called "Name", etc. During execution of a computer program 1 according to the present invention, the LL 4 should have access to the information in the ULD 3. For this purpose the IL 4 may have the functionality to read and interpret an UTD 3. Alternatively, a separate ULD parser can be provided, which is able to convert each UTD 3 for a specific IL 4 to a format that can be interpreted by the IL 4. The parser might even create a separate module, which should become part of the computer program 1 and is able to initialise the IL 4 in accordance with the information provided in the UID 3. Then again the ULD 3 might be provided in some kind of programming language, ready to be added to the IL 4 and AML 2. A specific UID 3 can only be used in conjunction with the IL 4 for which it was meant to describe the computer program's user interface 5, and the AML 2 that requires that user interface 5. In effect the ULD 3 is the only part of the computer program 1 that is specific for both the functionality of the program as well as the environment 6 of this program. A clear interface between the AML 2 and IL 4, which meets criterion 3, may for instance be accomplished by the use of events 11. The UTD 3 can be used as a means to declare the events 11, the circumstances under which the events 11 have to be invoked by the IL 4, and the means the AML 2 has to respond to these events 11. Of course, the events 11 have to be implemented in the AML 2. Moreover, it must be checked that every UID 3 that may supplement a particular AML 2 declares the same events 11 for the same logical circumstances. In a further embodiment, described below it will be shown how this can be accomplished without the need for manual checking.

Now, in order to test the computer program 1, drivers and stubs might replace the IL 4. Together, these drivers and stubs will be called a test engine 20. In addition to the test engine 20, a test script 22 can be used to make the drivers and stubs independent of any particular AML 2. The test script 22 thus replaces the ULD 3. The test script 22 has to declare at least the AML's events 11, the circumstances that should result in the invocation of these events 11, and the means the AML 2 has to respond to these events 11. Additionally the ULD 3 might be appended with information about how to discriminate correct from incorrect program behaviour. Effectively the test engine 20 can simulate user actions by calling the events 11. Additionally it is possible to interpret the responses of the AML 2 to these events 11, and to judge the correctness of these responses. This is in accordance with criteria 4, 5, and 6. Architecturally, the test engine 20 is just another LL 4, and the test script 22 is an UTD 3 for the test engine 20. A further embodiment of the present invention consists of three layers:

1) Concrete Interface Layer 12 (CLL)

2) Abstract Interface Layer 10 (ALL)

3) Application Model Layer 2 (AML)

Although the architecture does not require an object oriented programming language, it is assumed that such a language is used for the implementation of the different layers. It is also assumed that the core functionality of the application is implemented as a set of documents 7. One should not limit the meaning of the word

'document' to an object containing words, paragraphs, and text formatting information. A document 7 encapsulates and manages application data. This might be in the just described sense, but a document 7 may also render information that more closely represents reports, spreadsheets, graphics, customer information, etc. Documents 7 are usually composed of simpler documents. The leafs of such a structure are the data types that are built into the utilised programming language. Thus, a document 7 is modelled in a programming language by a built-in data type, or by a class or structure that is composed of other documents. A class is a data-type, which is declared and implemented by the programmer.

The following concepts are used in the remainder of this patent application: • Implementation of a layer: the source code (in some sort of programming language) that realises the functionality of the layer.

• Configuration of a layer: the state of all objects and data structures of a layer at a specific moment in time. A layer can not have a configuration until it is implemented and running. However, it is possible to describe a specific configuration, without executing its implementation.

• Constant-configuration of the CLL 12 or ALL 10: that part of the configuration that only depends on the particular AML 2 to which it is coupled. The constant- configuration does not change during the execution of a program, and may only change during initialisation and destruction of the program. • Serialisation: the process of storing or reading the (constant-) configuration of a layer to or from persistent storage, e.g. disk or tape. This makes it, for example, possible to end an application and restart it later, using the serialised configuration as a starting point.

• Serialised configuration: the (constant-) configuration on some sort of persistent storage. This might be in a binary format or in a human readable, e.g. textual, format. In the latter case, the serialised configuration does not have to be generated by the program itself. It could be provided by a human being, in order to configure the program or initialise it to a predefined state.

The CLL 12 models the user interface as it appears to the end-users. In the case of a GUI, this means that it, among others, controls the size, position, and colour of menus, dialogue boxes, widgets, and controls. It uses the AIL 10 to get information about the abstract representation of the interface. The CIL 12 does not access the AML 2 directly. Operations in the AML 2 of which the results are of any importance to the CIL 12 are reflected through the AIL 10.

Control of an application starts in the CLL 12. The CLL 12 first initialises the AIL 10 with a serialised constant-configuration, and then itself. After that, the CIL 12 starts to handle user-input, which will result in calls to the AIL 10. The CIL 12 will also take care of publicising output of the ALL 10 to the end-users.

The AIL 10 only models the abstract user interface properties. This layer represents menus and dialogue boxes as 'sets' of user interface entities. The menu- items, controls, or widgets they contain are represented as members of these sets. Such members may be new sets, or relate to controls or widgets for the exchange of numbers, dates, floating-point values, etc. The elements must be abstract enough to be represented by other types of user interface entities if, instead of a GUI, another form of user interface is employed. Document adapters 8 have these kind of properties.

Furthermore, the ALL 10 holds the document values that are assigned to these entities, and additional information about their state. The AIL 10 does not have to include the implementation of the documents 7, although for general types of documents 7 it may do so. State information includes flags that distinguish between enabled and disabled, visible and invisible, the allowed ranges of input values, information about how the elements are coupled to the AML 2, etc. Part of the state information belongs to the constant-configuration, and will not change during the execution of the program. The other part is controlled by the AML 2. The CLL 12 does not alter the state information, except the documents 7 controlled by document adapters 8 of which the value is changed by request of a user. However, the layout of the CLL 12 may depend on it. For instance, if a user interface entity is disabled, it might be shown greyed in the CLL 12 of a GUI. Besides, the user may only view the document value of disabled entities. The CLL 12 should enforce that the user(s) can not alter such values. Thus, the CLL 12 must check the configuration of the ALL 10 to determine the allowed user actions.

Together, the CLL 12 and AIL 10 make up the IL 4 as it was introduced in the previous section. The AIL 10 has to be implemented only once, and can be used for every type of user interface 5 and AML 2. The CIL 12 has a different implementation for every type of user interface 5 that needs to be supported. This implementation does, of course, not depend on a specific AML 2. Each particular AML 2 can be combined with the AIL 10 and any available CLL 12, provided that the CLL 12 implements user interface entities for all utilised kinds of abstract user interface elements.

The AML 2 implements the documents 7 that model the core behaviour of the computer program. Furthermore, it connects these documents 7 to the ALL 10. In this description, it is assumed that the AML 2 is coupled to the ALL 10 by the use of events 11. Of course, the connection can be made by other means as well. For instance by a messaging system that follows the observer pattern (see Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides: Design Patterns: Elements of Reusable Object- Oriented Software. Addison- Wesley, 1996). An event 11 is a piece of code (a function, procedure, or method) that will be called under predefined circumstances. For example, their might be an event 11 that will be called each time that a user changes the document value of a specific user interface entity.

Abstract Interface Layer

The main ingredients of the AIL 10 are document adapters 8 (shortly: adapters), and error identifiers 9 (El's).

The adapters 8 are the abstract user interface elements that were described above.

Usually, an adapter 8 is an object that extends a document 7 with information about its representation in the user interface. Although they are called document adapters 8, the entities do not necessarily require a document 7. For instance, buttons or menu-items usually do not relate to a document value. Of course, this is true for the adapters 8 that represent them as well.

An embodiment of the invention will include various kinds of adapters 8, which can be categorised as follows:

1- Leaf adapters: the abstractions of the user interface elements that relate to simpler data types. Examples of leaf adapters are number adapters for the exchange of numerical values with the interface user, and string adapters for the exchange of textual values with the interface user. Both of these adapters can be represented by an edit-box in the CIL 12 of a GUI, but also by a listbox with an edit-field.

Another example is a command adapter, which can be coupled to an event 11 in the AML 2, but does not have a document value. The event 11 may affect the document value or state of other adapters. In a GUI, the command adapter can be represented by, e.g., a button inside a dialogue box, or a specific menu-item. Relationships between leaf adapters are expressed through the composite adapters of which they are members. The type of document that a leaf adapter manages is provided by the programming language or by the AIL 10 itself.

2- Composite adapters: they relate to sets of other adapters. Composite adapters have two purposes:

1- The documents 7 they 'adapt' are the more complex objects that are not supported by the leaf-adapters. Thus they offer a way to provide document adapters 8 for the documents 7 that are implemented in the AML 2.

2- They regulate the dependencies between their member adapters. For instance, a specific type of composite adapter might request that all of its members would be accessed in a fixed order, by the user(s). Of course, the state of members may pose additional restrictions on their use, e.g. the CIL 12 is not allowed to change the document value of adapters that have been disabled.

In a GUI, dialogue boxes or application frame windows can represent composite adapters. In the former case, their members are represented by the controls of the dialogue box. In the latter case, the menu-items, toolbar-buttons, status bars, etc. of the frame represent them.

One of the composite adapters must be identified as the main adapter, i.e. the adapter that will be coupled to the part of the user interface that must be active when the application starts.

3- Resource adapters: they provide a mechanism to make use of application resources without knowing how they are represented in the CIL 12. Thus resources that in one CIL 12 may be represent by a message-box, and in another CLL 12 by a stream of audio (a message in the form of spoken audio). Each distinct type of adapter can be implemented as a class that inherits functionality from a general base class, which provides the core functionality of an adapter 8. Composite adapters can be implemented by use of the composite-pattern (see Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1996). Thus composite adapters are derived from the same base class as the other adapters, and add the functionality to manage their member adapters.

The CIL 12 should be notified when the AML 2 changes the state or document value of an adapter 8. The observer-pattern can be employed to make this happen. The just mentioned adapter base class will provide the functionality of a subject in the pattern. Objects in the CIL 12 can register themselves to the adapters 8 in which state they are interested. Hence, they become observers of that adapter 8. The observers should be derived from a class with observer functionality. An adapter 8 will send a message 15 to all of its observers, if its state or document value is changed by the AML 2. The notified observers can handle these messages 15, if necessary, so that the changes are reflected to the end-users. This mechanism ensures that the ALL 10 requires very little knowledge of the CIL 12, and thus becomes almost completely independent of its implementation. The only dependencies are in the use of the observer pattern.

Each adapter 8 may be linked to several events 11 in the AML 2. A leaf adapter might for instance include a validate event. Such an event 11 should be executed when an end-user changes the value of the associated document 7, by use of the CIL 12. During the execution of that event 11, the AML 2 gets a chance to change the state of other adapters, of which the CIL 12 will be notified by the just mentioned observer pattern. The event may return an error code to its caller. This can be done in the form of an El 9.

Since the adapters 8 are instantiated objects, their state and document value is part of the actual configuration of the AIL 10. The state information can be subdivided into information that depends on the actions that a user has performed, and information that is inherently constant during the execution of the program. The latter is part of a constant-configuration of the AIL 10. Examples of adapter data that belongs to the constant-configuration are:

• the identifications of the events 11 that may be called, and the circumstances under which events 11 may be called;

• is the adapter 8 responsible for user input, output, or both;

• the type of document 7 that is managed by a specific composite adapter.

El's 9 are used to identify errors that the events 11 may return. However, they do not concretise how these errors should be presented to the user. The CLL 12 is responsible for that. El's 9 might for instance be represented by constant integers in the utilised programming language. If an adapter 8 executes an event 1 1 that returns an El 9, it must notify the CIL 12 of the error. Demanding that each CIL 12 implements a function that handles El's 9 can do this. The adapter 8 calls this function. The function chooses a way to publicise the error to the end-users, and requests a follow up action, e.g. abort, or retry. It returns this value to the adapter 8, which will determine its next action. Of course, El's 9 may also represent warnings. A real embodiment of this invention will probably use a more advanced error reporting mechanism (for instance via exception handling), or a combination of different error handling mechanisms.

The constant-configuration of the ALL 10 consists of a portion of the state information of the adapters 8 (see above), the available El's 9, an identification of the main adapter 8, and possibly some additional information. Together, this will be called the interface declaration 14. The interface declaration 14 provides abstract information about the user interface. It defines to which document values a user has access, which values the user can change, the kinds of errors that a user might expect, etc. Yet, the AML 2 can still influence this behaviour, by changing the (non-constant) state information of adapters 8. If that were not the case, it would be practically impossible to develop interactive computer programs. Each AML 2 requires an interface declaration 14. Since the interface declaration 14 specifies the events 11, the implementation of the AML 2 depends on it. Effectively, the implementation of the AML 2 depends on the constant-configuration of the AIL 10, but not on its implementation.

The interface declaration 14 must be read, interpreted and possibly parsed. Programs or modules that implement these tasks may be constructed in such a way that they support polymorphism, inheritance, encapsulation, reuse, and other advanced means to construct an interface declaration 14.

Concrete Interface Layer

The CIL 12 communicates with the program's environment 6 in order to gather input from that environment 6 and present output to it. Such an environment 6 will normally be the Operating System (OS) and an Application Program Interface that provides the functionality to communicate with the potential end-users.

The objects that together implement the core functionality of the user interface will be called views 13. If necessary, each view 13 must have the functionality to present the state and document value of an adapter 8 to end-users, handle input from user(s), and handle the messages 15 they get from document adapters 8. Commonly, views 13 are notified of user actions by way of operating system messages. The relationship between views 13 and adapters 8 can theoretically be m : n, in which both m and n are integers that may be equal to 0 However, this will usually be m 1, meaning that an adapter 8 will be represented by one or more views 13 in the CLL 12 Not all views 13 are used to visualise, or otherwise make public, the state of an adapter 8 For instance, this is not the case with views 13 that represent accelerator keys Accelerator keys are key combinations that can be used as shorthands for executing menu-items, or other controls Views 13 that implement this functionality control an adapter 8, but do not publicise their state or document value On the other hand, there might be views 13 that are only responsible for representing the document value and/or state of an adapter 8, but do not actually control the adapter 8 Of course, the state of an adapter 8 determines if users might view 13 and/or change their document value The CIL 12 is responsible for providing the appropriate views 13 to perform these tasks In a GUI, the views 13 will usually represent controls, widgets, etc Composite adapters can be instantiated by menus, dialog boxes, or application frames If a composite adapter is a member of another composite adapter, a button or menu-item can link them Naturally, other kinds of user interfaces use different views 13

One of the views 13 has to be identified as being the main view This view 13 relates to the main adapter in the AIL 10, and will be executed at program start-up Depending on user actions, other views 13 might be activated The configuration of the AIL 10 determines which views 13 may be activated by the users

In addition to views 13, which concretise the adapters 8, the El's 9 must be instantiated in the CLL 12 If one uses a GUI, the El's 9 will usually be instantiated by different message boxes, or maybe by a beep or sound As already mentioned, the CIL

12 must include a function that can be called by the AIL 10 to present the representation of El's 9 to users, and to request a response for these errors

Furthermore, the CLL 12 is responsible for the handling of trace messages and assertion failures in debug builds and during application testing It should provide the functions for these tasks as well

The constant-configuration of the CLL 12 determines at least the number of active views 13, their type, their relationship with the various adapters 8, and additional information that depends upon their type In a GUI, such information may include the size, position, and colour of a view 13. Furthermore, the constant-configuration includes an identification of the main view, and the representation of El's 9 in the user interface. This constant-configuration will be called interface instantiation 16, because it defines the look-and-feel of the user interface that was declared by use of the interface declaration 14.

The interface declaration 14 and interface instantiation 16 are strongly related.

The interface instantiation 16 must match the interface declaration 14. Adapters 8 may require an instantiation in the form of a view 13. Depending on the kind of adapter, some types of views 13 are not, and others are allowed to represent the adapter 8. Also, every El 9 should be concretised in the interface instantiation 16.

Since the interface declaration 14 and interface instantiation 16 are static, a separate program can be used to check if they match each other. This program may also combine the interface declaration 14, interface instantiation 16, and their relationships, and serialise them in a format that can be employed very fast by the resulting application.

It is possible that the AIL 10 implements some sort of adapter that can not be represented by all kinds of user interfaces. For instance, a Voice Response Interface is not suitable for the input of drawings or pictures. The ALL 10 may provide adapters for such documents 7, but a specific CIL 12 might not implement views 13 to handle them. An application that uses such an adapter 8 in its interface declaration can not be ported to that specific user interface, unless the adapter 8 is identified as being optional. Optional adapters do not require an instantiation in the form of a view 13 in the CIL 12. Note that the state "optional", if supported, is part of the constant configuration of an adapter 8.

Application Model Layer

The AML 2 implements at least the documents 7 that are not provided by the AIL

10, and the events 11. It must be possible to change the state of adapters 8, and their document value from code inside the AML 2, or else one can not develop interactive applications. There are (at least) two straightforward ways to implement these possibilities, both require that the interface parser builds a declaration file. When C++ is used as programming language, which is assumed to be so, the declaration file is a

C++-header file. The file will be called interface header. The two methods are: 1 Make the adapters 8 directly accessible from the AML 2, by use of references 17 to them, which are declared in the interface header

2 Use proxy objects to make the adapters 8 accessible This can be done by use of a proxy-pattern (see Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides Design Patterns Elements of Reusable Object-Oriented

Software Addison-Wesley, 1996) A proxy object shields an adapter from incorrect use, and may provide a different interface to it

The second method is preferable, because it hides the adapters 8 from the AML 2, which is good since the adapters 8 offer a lot of functionality that is meant specifically for the CLL 12 The AML 2 should not be allowed to access this functionality

Additionally, it should be possible to regulate the access to adapters 8, depending on the scope from which they are called In other words it has to be possible to deny access to certain adapters 8 in certain functions or events Moreover, infraction of this demand should be detected at compile time, not at run time Modern languages, like C++, offer certain methods to accomplish just that

1 ) Give the events 11 arguments, which provide access to the adapters 8 that might be accessed The arguments may be proxy objects that provide the desired access to the adapters 8

2) Use the scope properties of the programming language to enforce this For instance, let the interface parser categorise the events 11 on the basis of the adapters 8 that they may access Now the interface parser can include a C++-class definition for each of these categories in the interface header Each event 11 can be declared as a static member of such a class The class should also include protected static member variables that can be used to access the adapters 8 (e g the just described proxy objects) Now an adapter can only be accessed if a member variable that accesses it is placed in the same class as the event from which it must be accessed Both methods can be combined of course It seems natural to let the scope of an adapter 8 depend on the composite adapter of which it is a member The interface parser should put the El's 9, the declarations of events, the classification into scope categories, and the references or proxy objects to adapters in the interface header. Events 11 must be abstract enough to be supported by most types of user interfaces Thus, they do not provide functionality like 'called when the user presses the tab-key', but 'called when this specific adapter's value is changed by the user' The events 11 will generally be used to program the document constraints Consequently, they guide a user through the user interface in such a way that he/she/it will only construct valid documents 7 This simplifies the implementation of the documents 7, and results in documents 7 that can be ported easily to other architectures or application frameworks

Note that the implementation of such constraints in a DV, or MVC architecture is part of the interface layer (views or controllers) Effectively, in such an architecture one must reprogram these constraints if the program is ported to a radically different type of user interface

The AML 2 is not the only part of the application that must be added to the framework for the construction of a useful application The interface declaration 14, and interface instantiation 16 must be provided as well As mentioned before, the interface declaration 14 also specifies the various events that have to be implemented The interface declaration 14 and interface instantiation 16 do not contain program code They just describe an interface An application framework that is based on this architecture, can be extended with user interface editors Such editors reduce the development of the interface declaration 14 and interface instantiation 16 to a matter of drawing or otherwise configuring the interface

Interface Parser

The interface instantiation 16 and interface declaration 14 are strongly related It is possible to check if an instantiation matches a specific declaration statically This could be done by a specific program, which we will call the interface parser In addition to checking if a declaration is correctly instantiated, the parser generates the constant- configurations for the AIL 10 and CIL 12 in a format that is easily interpretable by these layers The parser can do this through the construction of a program unit that will perform the required initialisations, or through the serialisation of this configuration The latter method will be assumed Note that the serialised configuration is equal to the information provided in the interface declaration 14 and interface instantiation 16, although some information about their relationship may be added for convenience or performance reasons In addition, the interface parser should provide declarations of the events, the El's 9, and possibly references to adapters 8, or proxy objects for the access of adapters 8 In C++, these things can be put in one or more header files the interface header Other languages provide comparable means to accomplish the same task The header file may also include code that registers the various events, so that the AIL 10 knows how to call them Registration can take place in a separate function that is implemented in the interface header, and called by the CIL 12 or ALL 10 during start-up of the application Object-oriented languages, like C++, provide more advanced means to take care of the administration Of course, the interface header will only be included in source files that are part of the AML 2

Every CLL 12 requires a dedicated interface parser However, the interface header that these distinct parsers generate does only depend on the interface declaration Each distinct interface parser has to generate the same interface header for a specific interface declaration Otherwise the AML 2, which includes this header, will differ between different types of user interfaces

An interface parser performs the following actions

1) Read the interface declaration 14

2) Check if the interface declaration 14 is consistent (does not contain any errors) 3) Generate the interface header.

4) Read the interface instantiation 16

5) Check the internal consistency of the interface instantiation 16

6) Check if the interface instantiation 16 matches the interface declaration 14 Examples of things to check are. i) Does a view 13 match the type of the adapter 8 for which it used? ii) Is there a view 13 for every adapter 8 that requires one? iii) Are the relationships between adapters 8 also available between the views

13 that represent them? iv) Is every El 9 instantiated? 7) Generate a constant-configuration file for the application This configuration file must contain at least the interface declaration 14 to be able to configure the ALL 10, and the interface instantiation 16 for the CIL 12 Additionally, the configuration can contain information about the mappings between both The first three steps only depend on the interface declaration 14, and are therefore independent of the type of user interface 5 All seven steps may result in errors, in which case a valid application can not be built

Test engine Fig 3 shows a diagrammatic view of the 3-layer composition of a software program according to the invention, during testing of the software program

The test engine 20 is in fact just another CIL 12 However, it does not communicate with the end-user(s), but instead tries to simulate their potential behaviour, while observing the resultant program responses (see Fig 3) Initially, one can make the following remarks about the controllability, observability, and detectability

1) Controllability the test engine 20 has all the information that was present in the interface declaration 14 (via the ALL 10) Effectively, the engine 20 knows exactly which actions a user might perform The engine 20 can simulate these actions by calling the appropriate methods in the ALL 10 However, because the state of adapters 8 might change in response to these actions (through the execution of events in the AML 2), the engine can not determine a complete test case a priori Instead it should perform an action and wait for the responses, before it can determine the next action 2) Observability the test engine 20 gets notification messages 15 if the AML 2 changes the state or document value of an adapter 8 This includes all changes that affect the representation of data in the user interface Further, the engine contains the code that handles assertion failures and trace messages, thus it may observe these too Finally, exceptions that are not handled by the AML 2 and ALL 10 can be caught by the test engine 20

3) Detectability assertion failures are a direct indication of incorrect program behaviour In conclusion, the controllability and observability are very good Yet, it would be better if one could influence the generation of test cases, in order to direct the testing of an application Then one will be able to test only a portion of a program, stress certain parts, or try to achieve a certain degree of code coverage Additionally, it must be possible to increase the detectability Both extensions could be added by supporting some kind of test script 22 Such a test script 22 is comparable to an interface instantiation 16, in the sense that it must match the interface declaration 14, and that it configures the CIL 12 (the test engine 20).

There are many ways to support test scripts 22. A straightforward one will be described that is not so difficult to implement but is very powerful. In it, the test script 22 will mainly consist of a constant-configuration of test views 21. These test views are implemented in the test engine 20. They are comparable to the views 13 in other CIL 12's: they control and observe the adapter(s) 8 to which they relate. The difference is, of course, that the test views 21 are not controlled by the end-user(s). Every adapter 8 of which the document value might be changed by the CLL 12, and every adapter 8 that may call an event 11, should be represented by a test view 21. Different kinds of test views 21 can be used for different types of adapters 8. A test view 21 that is responsible for testing a certain adapter is said to control that adapter. It must provide the means to simulate user actions that relate to the adapter 8, and to evaluate the results of these actions. Therefore, each test view 21 includes an algorithm for the construction of a new simulated user action (SUA), and a method to perform the just constructed SUA. In the remainder, these methods are called respectively: GenerateSUA, and ExecuteSUA. It should be possible to influence the employed algorithm in GenerateSUA via the test script 22.

SUA's can be either atomic, in which case the test engine 20 knows a priori that the complete SUA can be performed, if no serious failures are detected during that execution. SUA's can be composed of other SUA's as well. In that case the composite SUA is not atomic, for reasons already mentioned. The simulation of user interface actions on leaf adapters can be tested through atomic SUA's. Composite adapters, on the other hand, will usually require composite SUA's. A user may step through the members of such an adapter, performing different kinds of actions before closing the user interface entity that relates to the composite adapter.

The interface parser of the test engine 20 {test-script parser) works just like an ordinary interface parser. Thus among others, it checks the interface declaration 14, generates the interface header, and verifies that the test script 22 matches the interface declaration. If the test script 22 does not contain a test view 21 for an adapter 8 that requires one, the interface parser can add a default test view 21 for that kind of adapter. Effectively, the test script 22 is optional. Without a test script 22, the interface parser can still construct a constant-configuration for the test engine 20. Such a constant- configuration may effect in the generation of meaningful test cases, and the resultant evaluation information will include trace messages, assertion failures, and unhandled exceptions If a 'design by contract' programming style is employed during the development of the PUT (see Bertrand Meyer Applying 'design by contract' Computer, 25(10) 40-51, October 1992), such tests might be just fine in certain stages of program development

Note that the test script 22 does not have to include instantiations of the El's 9 Logging and evaluating the El's 9 that events return gives exactly the information a tester or developer needs The test script 22 should identify a main test view 21, which may default to the test view 21 that relates to the main-adapter Application testing starts with this test view 21, just as the execution otherwise would start with the main view Additionally, the test script 22 may include settings that influence the following properties

1 How many test cases have to be constructed 2 Should all test cases be saved to the test base or, for instance, only the failure revealing ones The test base is a database that contains executed test cases Each saved test case includes all SUA's that constitute the test case, the logged program responses, and information about detected program failures To be able to test for failures in code that is part of the program initialisation

(constructors of global objects), or program cleanup (destructors of global objects), the PUT 1 should be restarted for each new test case Note that this is only necessary for programming languages that support such language idioms Therefore the PUT 1, which consists of the AML 2, AIL 10, and test engine 20 can be executed in two modes

1 The shell mode The test team executes the program in this mode The program may then offer options like the following ones

1 Construct a new test base Thus, generate, execute, and evaluate test cases and store these test cases in the test base Note that executed test cases include the logs of the program's behaviour, and the evaluation results

2 Regression test an old test base, put the results in a new one Thus execute the test cases in the old test base again, to check if they reveal the same failures (evaluate the test cases again), and/or to check if their behaviour is not changed (compare the logs of the program's behaviour of both runs). Put the results of these runs in a new test base. 3. Generate test reports from an already constructed test base. The test engine 20 itself implements the functionality to let a tester choose between these options.

To actually perform a specific test case, the PUT in shell mode will spawn a copy of itself in the child mode. This copy will execute and evaluate the test case, and notify the shell program of the results. After that the copy will end itself.

2. The child mode: The PUT in this mode will actually execute and evaluate a single test case. The differentiation between shell and child mode can be accomplished through, for instance, program arguments. The test engine 20 differentiates between both modes of execution.

Before the operations of both program modes will be described, it will be discussed what the GenerateSUA and ExecuteSUA methods should do.

As already mentioned, each test case includes a number of SUA's. A test view 21 is responsible for the construction of the SUA's that relate to the adapter 8 it controls. Thus the test view 21 that is coupled to a number adapter may construct a SUA that simulates a user entering a new value. However, such an SUA would not be valid if the adapter is disabled. Thus, the method GenerateSUA can not construct a new SUA until all previously generated SUA's (for the same test case) are executed. Stated in another way: each ExecuteSUA may affect the configuration of the AIL 10 in a way that influences the potential follow-up SUA's. Thus a call to GenerateSUA must be followed by a call to ExecuteSUA, before another call to some GenerateSUA can determine the next action.

Intuitively, a GenerateSUA, which constructs a composite SUA, actually constructs a sequence of consecutive SUA's. However, it can not call the ExecuteSUA methods to execute these SUA's. Since that is the task of the ExecuteSUA that relates to the original GenerateSUA. Thus, either the GenerateSUA has to perform actions that relate to ExecuteSUA, or it is the other way around. As a solution, if a GenerateSUA tries to generate a composite SUA, it does not actually generate all member SUA's. Instead it generates the composite SUA as an algorithm for the construction of these members. The ExecuteSUA method uses this algorithm to generate the member SUA's, and executes them immediately. Thus ExecuteSUA performs the following actions for composite SUA's that not yet include the member SUA's:

1. Construct a member SUA, according to the algorithm that was included with the composite SUA. The SUA may simulate an action on the related composite adapter, e.g. "end the communication with the adapter" (a). Otherwise, the test view 21 will select a member adapter and call the appropriate GenerateSUA to generate a SUA for the member (b).

2. Execute the just generated SUA. In case of (a), the ExecuteSUA of the actual test view 21 will know how to execute the SUA. Otherwise (b), the ExecuteSUA of the test view 21 that generated the SUA should be used. (SUA's must include an identification of the test view 21, which generated them).

3. Repeat steps 1 and 2 until a SUA that simulates the action of closing the user interface element that would have handled the composite-adapter is successfully executed. If after several attempts the closing can still not be simulated, this can be logged as an error or warning, and the execution of the SUA can be stopped.

Note that the member SUA's can be composite SUA's as well. Note also that if a composite SUA already includes its members, the ExecuteSUA will simply execute these members. The algorithm will be discarded in that case. This is useful for regression tests of already constructed and executed test cases. In summary, a test case is not constructed a priori. Instead, it is dynamically built, based on the generation algorithms that are part of the constant-configuration of test views 21. Each executed test case consists of a composite SUA. Each SUA is an object that includes information about the test view 21 that generated and executed it, and the action that it simulates. In the case of a composite SUA, this action is initially provided as an algorithm that can be used to construct a series of member SUA's. During its execution, the child SUA's are added one by one, and executed directly.

In order to be able to automate regression testing, the program behaviour in response to the execution of SUA's must be logged. This information can best be kept with the SUA's that caused them. Thus, it seems practical to include in each SUA a list of all the messages that are send to the various adapters 8. This can be implemented by adding the notion of an active SUA. The test engine 20 takes care of forwarding all messages that are send by the adapters 8 to the currently active SUA. Each ExecuteSUA method will set the SUA it executes to be the active one just before execution. After execution the method will activate the SUA that was active earlier. Generating reports for a test case is now easy: just list a description of each SUA in the test case in chronological order, and add descriptions for the logged adapter messages that it caused. Such reports can be evaluated manually, automatically, or used for regression testing. Note that the addition of evaluations to the test scripts 22 will be discussed later.

It is now possible to describe the steps that the shell version of a PUT must perform, when it constructs a new test base:

1. Create an empty test base to store the test cases. 2. Activate the main test view 21.

3. Execute its method GenerateSUA.

4. Serialise the generated SUA to a temporary file.

5. Spawn a copy of the PUT in child mode, and tell it to execute the serialised SUA. 6. Wait until the spawned copy ends itself, and check its return value for serious problems. If the child application does not end itself in a reasonable time, log this as a serious failure for the original SUA, and add the SUA to the test base. Otherwise, read the executed SUA, which was serialised by the child, and add it to the test base. 7. Delete both temporary files.

8. Repeat steps 3-7, until enough failures are detected or the test base contains enough test cases, or enough test cases are evaluated. The child version performs the following steps: 1. Read an SUA from the temporary file. 2. Search for the test view 21 that relates to the SUA.

3. Call the appropriate ExecuteSUA, in order to execute and evaluate the SUA. The result will be a test case, which has exact information about all performed user interface actions, the program's responses to these actions, and evaluation information.

4. Exit the application.

5. During application exit: check for failures in destructor, or program cleanup code. Add these failures to the evaluation information of the SUA. Finally the SUA should be serialised to a new temporary file. Serious errors during this serialisation can be reported through a return value of the program.

Note that serious failures during the execution of a test case (for instance failed assertions or unhandled exceptions) may force the child to stop the execution of a test case. This can be logged in the SUA as well. A (partially) executed test case contains all the information that is required to reproduce the detected failures.

So far, the dynamic generation of test cases has been discussed, and the logging of the program results. Now it is time to discuss how one may add program evaluations or validations to test scripts 22. Evaluations can, for instance, be coupled to the test views 21 via the test script 22. They may fall into different categories:

1. Conditions that must be valid before the execution of an SUA related to a specific adapter 8.

2. Conditions that must be valid after the execution of an SUA related to a specific adapter 8. 3. Conditions of the following form: if condition A is valid before the execution of an SUA then condition B should be valid after the execution of the SUA.

Of course, one may hit upon other categories as well. Only the second category will be illustrated, but implementations for other categories can be implemented in equal manner. The second category can be described as a post condition for SUA's performed by a specific test view 21. The validation of such post conditions can take place in the ExecuteSUA member of a test view 21, just after the actual execution of the SUA. There are at least two ways in which someone can specify the validation:

1. By way of a direct description in the test script 22 of the validation that must be performed.

2. By way of a procedure that will be added to the PUT and that performs the validations. This procedure will be called a hook function 24, or simply hook. A hook 24 is comparable to an event in the AML 2, in that it must be registered. Therefore the test-interface parser must generate an additional header file (test header) that takes care of declaring and registering the hooks 24, and providing proxies so that the state and document value of adapters 8 can be requested from inside those hooks 24. The techniques to accomplish these tasks are comparable to the tasks that the interface parser must perform, in order to construct the interface header.

The modules that implement the hook functions 24, which are added by the tester, should include the test header, and implement the hook functions 24. The tester has to program the hook functions 24 carefully, in order to not influence the normal flow of control. The fact that a hook 24, when not carefully designed, may affect the normal flow of control, is a disadvantage of this method in comparison with the previous one. However, this method is much easier to implement, because the test parser does not have to parse the post conditions. Moreover, this method is more flexible, and allows the programmer to test the program internals. To limit the risks, the proxies that are added to the test header should only provide read access to the available adapters 8. They should not make it possible to change the state or document value of them.

Regression testing

To regression test a program, one must execute the stored test cases again. The test engine 20 can just re-evaluate the test cases, thus disregard the logged behaviour in the previous run. Alternatively, it can compare the logged behaviour, so that the tester is sure that the program's behaviour is not changed for a number of test cases. The former method is probably better in early stages of development, in which the program's behaviour will change much, and the validations that the test engine 20 must perform may alter as well. The latter method gives results that are comparable to the results of Capture/Playback tools.

When the interface declaration 14 of an application has been changed, some additional work has to be done. First, the test engine 20 has to make sure that a test case is still valid. Secondly, if a test case is not valid anymore, the test engine 20 may try to convert the test case to one that is valid. Adding the following methods to test views 21 can perform these tasks: IsExecutableSUA, IsMigratableSUA, and MigrateSUA. The first method checks if a specific SUA is a valid argument for the method ExecuteSUA of the same test view 21. If the SUA is a composite, the IsExecutableSUA method will recur to calls of IsExectableSUA for test views 21 that relate to its members Only if all members are valid, the composite SUA is The I sMigratableSUA can be called for test cases that are not valid It checks if a test view 21 that can not execute an SUA, can convert this SUA to an SUA that it can execute The same composite structure can be used to get the result for composite SUA's Finally, the MigrateSUA can be used by the test engine 20 to construct a new SUA, based on a non-executable, migratable SUA

Suppose, for instance, that an old version of an interface declaration 14 declares an adapter 8 as being a number adapter, where the new version declares it as a string adapter The test engine 20 couples the new adapter 8 to a string test view 21 The IsExecutableSUA will return false for an SUA that was generated for the old version However number values can easily be represented as string values, and SUA's that operate on number adapters have to do with changing numerical values Thus the I sMigratableSUA may return true for such an SUA Then, the MigrateSUA must be able to convert the SUA to one that mimics the action of changing the value of a string adapter, and may additionally convert the logged messages to messages that could have been send by a string adapter.

A test engine 20 that supports these conversions can be used successfully during the whole development cycle of a computer application The methods IsExecutableSUA, IsMigratableSUA, and MigrateSUA can be called in the shell version of the PUT, just before ordering the child version to execute the SUA It is not guaranteed that all SUA's in a test case for which IsExecutableSUA returns true can actually be executed Due to changes in the AML 2, an event may change the state of adapters 8 in a different way as in a previous version of the PUT Consequently, this may influence the allowed sequence of SUA's The method I sExecutableSUA can not detect this, because it does not actually execute SUA's, so it does not now how the SUA's influence the state of adapters 8 Instead, the method ExecuteSUA must check, before executing an SUA, that it is valid to perform the simulated action, taking the configuration of the AIL 10 into consideration If this is not the case, the ExecuteSUA should not execute the SUA, but mark this as a difference with respect to the previous version Execution of the test case must stop at this point Note that in this case the logged adapter messages will differ from the ones that were logged for the previous version as well For the comparison of logged adapter messages, which represent the application's behaviour, data-flow algorithms can be used. Such algorithms provide the means to indicate that the sequence of messages [A, B, C] is equal to the sequence [B, A, C] if the result of message B does not influence the result of message A, and vice versa. Data flow algorithms can be used to detect all relationships in a sequence of messages, and to check that, with respect to these relationships, the end-results of the actions that relate to two sequences do, or do not differ.

Claims

1. Computer program for communicating with an environment by means of a predetermined user interface, the computer program comprising at least an interface layer for communication with the user interface and for communication with an application model layer, the application model layer modelling a predetermined functionality, characterised in that the interface layer (4) is arranged to construct user interface elements and to retrieve, at least during execution of the computer program, information regarding user interface element construction from a user interface description (3), the user interface elements implementing the communication with the user interface (5) and the application model layer (2), and implementing interface layer (4) functionality for a specific type of user interface (5),.

2. Computer program according to claim 1, characterised in that the user interface description (3) comprises a description of user interface elements for the computer program in a predetermined format and the means for constructing are arranged to read and interpret the format of the user interface description (3).

3. Computer program according to claim 1 or 2, characterised in that the communication between the interface layer (4) and the application model layer (2) is implemented by means of events (11), events (11) being pieces of software code that are being called under predefined circumstances, and the user interface description (3) further describing the declaration of events (11) and the circumstances under which the events (11) are to be invoked by the interface layer (4).

4. Method for automatically testing a computer program according to one of the claims 1 through 3, characterised in that, the method comprises the step of testing the application model layer (2) by means of a test engine (20), the test engine (20) replacing the interface layer (4) and being arranged to simulate user actions.

5. Method for automatically testing a computer program according to claim 3, characterised in that, the method comprises the step of testing the application model layer (2) by means of a test engine (20), the test engine (20) replacing the interface layer (4) and being arranged to simulate user actions, and a test script (22) declaring the events (11) and the circumstances under which the test engine (20) should invoke the events (11), the test script (22) replacing the user interface description (3).

6. Method according to claim 5, characterised in that the method further comprises the step of checking responses of the application model layer (2) to events (11) by means of information with regard to correct behaviour of the application model layer (2) comprised in the test script (22).

7. Computer program according to claim 1, characterised in that the interface layer (4) comprises an abstract interface layer (10) and a concrete interface layer (12), the concrete interface layer (12) being arranged to communicate with the application model layer (2) via the abstract interface layer (10) and the concrete interface layer (12) being arranged to communicate with the user interface (5).

8. Computer program according to claim 7, characterised in that the application model layer (2) is arranged to model the core behaviour of the software program (1) in the form of documents (7), documents (7) being software objects encapsulating and managing application data.

9. Computer program according to claim 7 or 8, characterised in that the application model layer (2) is arranged to connect to the abstract interface layer (10) by the use of events (11), events (11) being pieces of software code that are being called under predefined circumstances.

10. Computer program according to claim 9, characterised in that the abstract interface layer (10) comprises document adapters (8) and error-identifiers (9), document adapters (8) being objects that extend a document in the application model layer (2) with information about its representation in the user interface (6) by references (17) to the document and error identifiers (9) being abstract entities used to identify errors that events (11) may return.

11. Computer program according to claim 10, characterised in that the computer program further comprises at least one interface declaration (14), each of the at least one interface declarations (14) being related to one application model layer (2), the abstract interface layer (10) being initialised during execution of the computer program (1) by the at least one interface declaration (14), the at least one interface declaration (14) comprising part of the state information of the document adapters (8), available error-identifiers (9) and an identification of a main document adapter.

12. Computer program according to claim 10 or 11, characterised in that the concrete interface layer (12) comprises at least one view (13), the at least one view (13) being an object that implements a core functionality of a predetermined element of the user interface (5), the core functionality comprising a presentation of the state and document value of a document adapter (8) in the abstract interface layer (10), handling of messages from document adapters (8) in the abstract interface layer (10) and handling input from the user interface (5), by calls to associated document adapters (8).

13. Computer program according to claim 12, characterised in that the computer program further comprises at least one interface instantiation (16), each of the at least one interface instantiations (16) being related to one application model layer (2), the concrete interface layer (12) being initialised during execution of the computer program by the at least one interface instantiation (16), the at least one interface instantiation (16) comprising part of state information of the views, including a relationship of the views (13) with the document adapters (8) in the abstract interface layer (10), an identification of a main view (13), and a representation of error- identifiers (9) in the user interface (5).

14. Method for automatically testing a computer program according to one of the claims 7 through 13, characterised in that the method comprises the step of testing the application model layer (2) by means of test cases executed by a test engine (20), the test engine (20) replacing the concrete interface layer (12).

15. Method for automatically testing a computer program according to claim 11, 12 or 13, characterised in that the method further comprises the step of initialising the test engine (20) by a test script (22) before execution of the test cases, the test script (22) matching the corresponding interface declaration (14) associated with the application model layer (2), and configuring the test engine (20).

16. Method according to claim 15, characterised in that the step of initialising the test engine (20) is executed by means of test views (21) in the test script (22), the test views (21) comprising descriptions for: constructing a simulated user action, the simulated user action being used to define a simulated input to a document adapter (8) in the abstract interface layer (10).

17. Method according to claim 16, characterised in that a simulated user action is constructed after executing a previous simulated user action.

18. Method according to claim 16 or 17, characterised in that a composite simulated user action related to a composite document adapter in the abstract interface layer (10) is constructed as an algorithm for constructing member simulated user actions, the step of executing a composite simulated user action comprising the steps of: a) constructing a member simulated user action b) executing the member simulated user action c) repeating steps a) and b) until the member simulated user action is executed, which simulates an action of closing user interface elements related to the associated document adapter (8) in the abstract interface layer (10).

19. Method according to one of the claims 16 through 18, characterised in that the method further comprises the step of initialising the test engine (20) by use of a test script parser, the step of initialising the test engine (20) comprising the steps of checking whether configuration informationfor construction of test views is provided for each document adapter (8) in the abstract interface layer (10); and add default test view configurations for each document adapter (8) in the abstract interface layer (10) for which a test view (21) is required but no configuration information is present in the test script (22).

20. Method according to one of the claims 14 through 19, characterised in that the method further comprises the step of recording the software program's behaviour during execution in a test base.

21. Method according to one of the claims 16 through 20, characterised in that the method further comprises the steps of: a) creating an empty test base for storage of test cases; b) activating a main test view (21); c) constructing a simulated user action; d) saving the simulated user action in a temporary file; e) starting a copy of the software program for executing the simulated user action, comprising the steps of el) reading the simulated user action from temporary file; e2) finding the test view (21) associated with simulated user action; e3) executing the simulated user action; and e4) exiting the computer program, saving the simulated user action containing information about performed user interface actions, program responses to these actions, and evaluation information; f) adding the saved simulated user action to the test base; and g) repeating steps b) through f).

22. Method according to one of the claims 16 through 21, characterised in that the test script (22) further comprises methods for evaluating and/or validating the computer program's responses to the simulated user actions.

23. Method according to claim 22, characterised in that the methods for evaluating and/or validating the computer program's response are comprised in the test views (21).

24. Method according to claim 22, characterised in that the methods for evaluating and/or validating are comprised in hook functions (24), the hook functions being included in the computer program and validating conditions related to execution of a simulated user action.

25. Method according to one of the claims 21 through 24, characterised in that the method further comprises the step of regression testing by re-executing the test cases stored in the test base.

26. Method according to claim 25, characterised in that the method further comprises the steps of checking whether a test case, which is to be re-executed, is still a valid test case for the computer program.

27. Method according to claim 26, characterised in that the method further comprises the step of checking whether a simulated user action in a test case, which is to be re-executed, can be adapted to the computer program.

28. Method according to claim 27, characterised in that the method further comprises the step of adapting a simulated user action in a test case.

29. Computer readable storage medium comprising a computer program according to one of the claims 1 through 3 or 7 through 13.

30. Method for developing a computer program according to one of the claims 1 through 3 or 7 through 9, comprising the steps of combining an interface layer (4) for a specific type of user interface with an application model layer (2) and defining a user interface description (3).

31. Computer system comprising memory means and processor means, the memory means comprising a computer program according to one of the claims 1 through 3 or 7 through 9, in which the processor means are arranged to read the user interface description (3) from the memory means.