VP-SE Research Group (C)

Courseware CAD

Bertrand Ibrahim, Alain Aubord, Birgit Laustsen, Michael Tepper

IFIP fifth World Conference on Computers in Education, Sydney, Australia, 9-13 July, 1990.

Stream: Research on Educational Application of Information Technologies.

A Postscript version of this document can be found here.

Abstract:

Even though the creation of Computer Aided Learning software (CAL) is always done on a computer, most development phases are still usually done with pen and paper. Authoring systems generally tackle the "coding" phase, leaving aside the specification and design phases and often imposing rather severe constraints on the users of such systems. The specification and design of courseware is not an easy or very formal process. Computer Aided Software Engineering (CASE) can nevertheless be very helpful in such an endeavor. We present here a whole development environment that runs on a graphic workstation. It allows a team of teachers and pedagogues to specify lessons graphically and then makes it easier for the team of programmers to translate these specifications into programs that can run on different target machines. The specification uses a very simple formalism and the programs are generated in a general purpose programming language such as Pascal or Ada. This development environment includes, among other tools, a graphic script editor, an automatic program generator, a synchronous multi-window editor to hand-code the parts of the CAL program not generated automatically and a translation manager to help maintaining translations of the lessons in different natural languages.

Keywords:

Software engineering, Automatic programming, Graphical specification, Development environment, Courseware, Computer aided learning, CAL, Computer based learning, CBL.

1. Introduction:

The most common approach to the development of computer aided tutoring is to use an authoring system. The problems with such a tool are that it is restrictive in what the developer can do and that it is tailored for individual work. Recent research (Karr87) shows that general purpose (high level) programming languages are still seen as the state-of-the-art for large scale quality courseware development. Such large scale projects are the result of a collaboration between teachers, pedagogues and programmers altogether.

Unfortunately, until now, very few tools exist to support large scale courseware development using general purpose programming languages. Moreover, very little has been done to support the whole development process of such software. There are however software engineering techniques (Glin84, Raed85) already used in other fields of software development that can very usefully be applied to courseware development.

Software CAD (Computer Aided Design) is an emerging paradigm of these very last years (Smith86, Buhr89). It refers to automated software design techniques centered around wiring- diagram-like graphical representation of software, with a supporting environment that allows for automatic program generation and fast prototyping.

The project we describe in this document (Figure 1) is based on this paradigm and is the result of a long experience in developing large computer aided learning (CAL) applications in a rather traditional way. This project intends to tackle the software development life-cycle of CAL lessons in order to allow the designers to concentrate on the pedagogical aspects of the lessons.

From the very beginning, we made the assumption that the development environment didn't need to be the same as the runtime environment. As a matter of fact, the needs of the designers and coders during the development phases are quite different from the needs of the learners using the final product. It follows from this that the development environment is targeted to run on a large screen graphic workstation when the environment of the learner is more modest and runs on PC- like machines.

Since teachers do not necessarily have a background in programming, it is essential that the tools made available to them to specify and design a lesson be as simple and close to their "universe" as possible. There are different phases in the development of CAL software and teachers or pedagogues are needed in only a few of them. They shouldn't need to be involved in the programming phase and yet a certain continuity is needed from the specification and design phase, then the programming and debugging phase, to the field tests and final use, including reviews all along the development process.

This continuity is ensured by a document that describes in a very detailed way what can happen during the learning process. This document, we call it a scenario or a script, can be considered as a semi-formal specification of the software that will be built thereafter.

2. Design phase:

The formalism we use in a scenario has been developed by Prof. A. Bork's team (Bork86) at the University of California, Irvine. It allows a complete and detailed description (partially in natural language) of a lesson. Since a good CAL lesson is mainly a dialog between the learner and the computer, the major building blocks of the scenario deal with program output, user input and how the program should respond to user input. All other operations are indicated in free text as instructions to the coder.

This specification formalism is a kind of graphical language. It is precise enough to give an exact description of the behavior of the final product, i.e. the lesson. It is built on just three basic primitives: text that has to appear on the screen, instructions to the coder (in natural language) and predicates (generally corresponding to answer analysis criteria). The specification of a lesson can thus be represented as a directed graph, in which each node corresponds to one of the three basic primitives and where the edges indicate the sequencing of operations (Figure 2). Text to be displayed is written in an ellipse, instructions to the programmer are between curly brackets and predicates are inside rectangular boxes.

The quality of a CAL lesson highly depends on its non-linearity, i.e. its ability to adjust its behavior to the learner's profile. This non-linearity is achieved by using cascades of tests (predicates) to be applied on the learner's answers to questions or on his actions following a task assignment. For more non-linearity, edges originating from a test box are labeled with a number or an interval. At runtime, a counter is associated with the test box. This counter will be incremented each time the criterion specified in the box has been satisfied. The corresponding edge will be followed depending on the value this counter has. Complementary predicates can be put in sequence (like IF THEN ELSIF instructions). If the criterion is satisfied, an edge on the side is followed; if it isn't satisfied, the criterion just below (if present) is then evaluated, and so on. If none of the criteria apply to the user input, the edges originating from the bottom of the last box indicate the actions to be taken in such an unanticipated case.

This formalism does not prejudice who, of the learner or the computer, has control of the other. It has been used to specify very different kind of lessons, ranging from mastery learning tutorials to microworlds with embedded tutoring as well as self-instructional software.

In our environment, a scenario is built using a script editor. The script editor is essentially a graph building editor in which the basic primitives correspond to the formalism we have just described. It is used to interactively enter the detailed specification of a lesson.

Using a mouse and keyboard interface, the designers specify each step of the lesson one by one, edit the textual content of each step and add or change sequencing links as they wish. These links are shown on the graphical representation as arrows, but are not considered by the script editor as simple objects. The user of the script editor can indeed use them to move along the script. He just has to select an arrow on the graph and pick the jump to arc origin or jump to arc end items in the menu to display what is at the beginning or end of a given edge.

As this example shows, the script editor is not just a simple graphic editor. It has knowledge of the structural aspect of a script and, as such, disallows most meaningless operations and offers a few primitives that help the designers check the consistency of their work. There is, for instance, a validation primitive that checks among other things that every step of the script is reachable and that there is no gap in the labelling of the edges originating from a test box.

3. Prototyping phase:

As we said earlier, the specification we get from the design phase is not purely formal. It includes what we call instructions to the coder that are written in natural language, without any restriction on what they can contain. It is therefore out of question to hope that the environment will ever be able to generate automatically the code for all such elements of the specification. Answer analysis criteria may also be specified in a rather informal way and are thus difficult to generate automatically too.

It is however relatively easy to generate code for the formal part of the specification, i.e. the messages and the sequencing of operations. The environment includes for this purpose an automatic program generator that translates the script into a program written in a high level programming languages such as Ada, Modula 2, UCSD Pascal, or Turbo Pascal. This tool can be seen as a graphical compiler that transforms a graphical representation of a lesson into an executable program. The target language can be chosen according to what is available on the target machine on which the code will be running.

Since the specification is not purely formal, the automatically generated program does not totally implement it. However, this is not a problem. A node of type message is translated into a call to the text display primitive with the name of the corresponding message as parameter. A node of type test is translated into a call to a boolean function whose body will be defined in a separate module. A node of type instruction to the coder is translated into a call to a procedure whose body will also be defined externally in a separate module.

Even though the body of a procedure corresponding to an instruction to the coder will later have to be "hand-coded", the automatic program generator initially generates a dummy body that displays on screen the text of the instruction. Similarly, the body of a boolean function corresponding to an answer analysis criterion will initially prompt the user for the value the function is supposed to return.

This means that the automatically generated program can already run as is on a target machine without any need for coding. Its behaviour will not fully correspond to the specification, but it will already give a rough idea of how the final product will look like.

Running this program on a target machine allows the designers, already at this early stage, to review the text as it is displayed on screen, to work on and tune the screen design and to test the different paths the learner can follow depending on his actions or answers.

As an alternative to program generation, we have contemplated a direct interpretation of the script on the development machine. This solution looks appealing but it is however not as easy to implement as it might seem at first. It indeed implies among other things that one emulates the screen and window management of the target machine on the screen of the development machine.

On the other side, the choice we made, i.e. generate source code that will be compiled on the target machine, has the advantage of integrating the prototyping and coding phase.

4. Coding phase:

The code produced during the prototyping phase includes dummy procedures and functions in separate modules corresponding to the instruction to the coder and to the test elements of the script. The task of the programmers is then to replace these dummy bodies with code that really does what the designers asked for.

One major problem in using code produced by an automatic program generator is that this code is hardly readable by a human being. Most of the symbols used in the code are generated by rather simplistic algorithms and are thus quite cryptic. Isolating the parts that have to be "hand-coded" is already a step in the good direction since the programmers will not have to deal with the automatically generated code.

The use of a modular target programming language is essential here. It allows a complete separation between the automatically generated code and the code added by the programmers, so that the programmers do not need to modify the code produced by the automatic translation.

Programming a procedure when one is not able to see how it fits in the whole application is not an easy task. The programmers can therefore use a specific tool of our development environment to write their code. This tool, a synchronous multi-window editor, allows a programmer to complete, in one window, the automatically generated code corresponding to the part of the script that is showing in another window. The idea is to have different windows show the different aspects or views of the same thing : a regular text editor in one window to edit one of the separate modules that have to be hand-coded and the script editor in another window to show the corresponding specification.

Any script window can be synchronized with a module window, or vice-versa. The script window is read-only in the sense that one can only issue positioning commands in it. One can enter positioning commands in any of the windows and ask for the other window to "synchronize", i.e. show the corresponding part of the view it handles. The programmer can thus very easily see, write or modify the code corresponding to a specific part of the script, by finding the location in the script window and then asking for the module window to synchronize, i.e. show the code for that part of the script. One can also find a specific location in the code (e.g. where an error occurred) and then ask for the script window to synchronize, i.e. show the part of the script that is the specification of the corresponding code.

One can have more than one pair of script-program windows at the same time. With this tool, the programmer can always see the specification at the same time as the code he is working on. This specification (the script) should help him understand and manage the code, since it can be seen as a human readable documentation of the code.

5. Debugging and maintenance phase:

Another problem that could arise from the approach we have taken is related to the fact that the development machine is not the same as the machine on which the CAL program will run. If there is an error in the code written by the programmers, it is on the target machine that it will show up.

For this delicate phase, the environment includes a remote supervision tool. It is a program that runs on a development machine at the same time as a lesson is running on a target machine connected to the same local area network (LAN). This tool is used to follow on the development machine the execution of the CAL program. To do this, the automatic program generator has to include, in the code it generates, instructions to send on the network. The informations sent indicate which program is running, which step of the script is currently being executed and possibly the name of the learner (e.g. for automatic curriculum).

The remote supervision tool can thus directly show on the script (which is a human readable specification of the lesson) where in the lesson the target program is. It allows a programmer to find much more easily where in a lesson a given error occurred. The synchronous multi-window editor can then be used by the programmer to move directly to the code that generated the error and correct it.

A similar mechanism makes it possible to collect automatically statistics on the learning process, once the CAL program is operational. The analysis of these statistics is useful for the designers of a lesson to review the pedagogical design. This review can then be carried out with the script editor.

6. Translation phase:

In a country that has four official languages it appears natural for us to want to have the dialogues of the CAL programs we develop be translated in different languages. That is why there is in our view another rather important phase: the translation of the dialogues (Frank85, Ibra86). Indeed, all the CAL software we develop is intended to be easily translated into different languages using the Latin alphabet (with some variants for accented letters). This translation phase can happen before, as well as after, design reviews. Therefore, it implies using an editing tool that also has the functionalities of a version manager to handle a database of updates.

We indeed make the assumption that there will not be a canonical language in which the design and all the reviews would be made and from which translations will be made. It may in fact very well happen that the design be done using, for instance, English, then have the lesson translated to French and Italian. Any of these three versions can then be edited with the script editor because some field test has shown a modification to be desirable. The problem is then to make sure that all versions are up-to-date.

In order to help to maintain the coherence of the different translations, a multi-window editing utility manages the modifications that are made to the messages. This tool maintains a database of modifications for the different message files, allowing the person(s) in charge of the translation to find directly the places that need to be updated, showing in a window the original message in the initial language, in another window the updated version of the message for this same language, in a third window the translation of the original message and, in a fourth window, the user can enter the update for the translated message. Only the fourth window is active, i.e. it is the only one in which the user can apply a modification. The other windows are passive (read only), but all four windows are synchronized and moving to a specific message in any of them generates a similar move in the other ones.

This tool is separate from the script editor since it has to be used by different persons. The translations will indeed not be done by the original designers, but rather by people proficient in both the original and target languages. The translation manager has nevertheless to be coupled with the script editor in the sense that it has to know which changes have been made with the script editor on one version of the messages in order to be able to indicate to the translators where to make updates in the other versions.

7. Future extensions

Even though the development of this environment is not yet complete, we are already working on extending its capabilities. As the reader may have noticed, the specification formalism we use is open ended, in the sense that it allows the designer to give part of the specification in natural language (as instructions to the coder). In the first phase, we designed the automatic program generator so that it takes care only of the display of the messages and of the sequencing of the operations. The instructions for the coder are, for the moment, translated into a procedure call and the answer analysis criteria into function calls. These procedures and functions are in a separate module and their body must be written by a programmer.

In a second phase, we intend to augment the translation capabilities of the automatic program generator by using artificial intelligence techniques, i.e. knowledge acquisition and generalization techniques. It will try to detect similarities between different instructions to the coder and query the programmer for a predicate, allowing the generator to associate specific parameters to each instruction to the coder.

Another extension we have in mind for this project is to use groupware techniques for the design phase. We indeed generally have more than one designer work on the development of the same set of lessons at the same time and we often have different people do the reviews. It would therefore be useful if the environment could support such team work either by allowing different people on different workstations to work on the same script at the same time (distributed work) or different reviewers to annotate the original script without changing it in the absence of the designers (asynchronous work).