Go home now Header Background Image
Search
Submission Procedure
share: |
 
Follow us
 
 
 
 
Volume 8 / Issue 10 / Abstract

available in:   PDF (958 kB) PS (2 MB)
 
get:  
Similar Docs BibTeX   Write a comment
  
get:  
Links into Future
 
DOI:   10.3217/jucs-008-10-0957

Mental Models to Represent Dynamics - Using the Example "factorial"

Gisbert Dittrich
(Dept. of Informatics, Dortmund University, Germany
gisbert.dittrich@udo.edu)

Abstract: To use hypertext/hypermedia elements in teaching at universities an author not only needs knowledge of the technological possibilities. In addition he/she has to renew a here so called mental model of the relevant aspects of the material to be transferred. For the author, this last mentioned problem seems to be a central and often very complicated and time consuming one.

Key Words: Mental model, presentation of dynamics, animation

Categories: H.5.1, H.5.4

1 Introduction

The technical developments in recent years very often suggest to present lectures "out of the computer". Many progressive lecturers develop presentations of talks and/or lectures using presentation programs like e.g. PowerPoint. Especially presentations of dynamics will become possible thanks to the new technical features such as the generation of animations as well as videos.

In order to present elements of dynamics an author naturally needs to know how to generate these elements. But in my opinion in addition to the technical possibilities it is essential to generate an adequate mental model appropriate for the given presentation. This task which is associated to the usage of these new possibilities seems to me to be central . It requires deep insights into the material to be presented and thus is not to delegate to the staff responsible for the technical generation of the material. In my opinion many lecturers who are not familiar with these techniques totally oversee or at least strongly underestimate this problem.

In this contribution the mentioned problem of developing adequate mental models will be clarified by looking at the problem of introducing recursion with an example, namely factorial(3). Starting with a representation as can be found in the book [DoberDiss 96] the mental model has to be enhanced/refined such that all relevant steps can be shown explicitly. This leads to an animation of this example that can be found in [Dittrich 01]. Alternatives will be mentioned.

2 A Mental Model for the Example "factorial"

We will give an introduction into the handling of recursion in programming languages using the example of factorial formulated recursively (here in C++). Therefore we have to model all relevant aspects of function invocations explicitly. In my opinion, the analysis of this problem leads to the explicit representation of the following aspects:

Page 957

  • code of the function and its application in a program (1)
  • implications of (repeated) function invocations
    • generation and stacking of function invocations (2)
    • generation and stacking of internal environments (3)
  • output of the execution of the program (4)
  • comment on the actual situations and of the transitions between them.(5)

This is a very rough and still to be refined description of the mental model. In this case study they appear in a natural manner and will be shown later in our animation. These aspects should be represented in the right order as complete as possible though comprehensible at every point in time. Last but not least the presentation has to be completely reproducible and to be learned with individually adapted velocity.

3 Technical Conversions into Presentations

In a book (cf. e.g. [DoberDiss 96]) usually the running of a program is described in textual form, eventually enhanced by graphics including a set of different overlaid snapshots.

This representation requires the reader to generate his own comprehensive model in his head, where to reproduce the running of the program along the given description and the graphics. If one is in the situation to start to learn these phenomena, this sort of representation proves to be very rudimentary and thus often not easy to understand.

A good teacher/lecturer is much better in transferring insights into e.g. recursive invocations, when he/she applies traditional means for representations on a blackboard. Appropriate representations of internal situations include concrete values of relevant variables which can be wiped off and replaced by new values according to the different steps defined in the program. . An alternative is to apply transparencies even with overlays.

But this representation usually includes some drawbacks as well. On the one hand usually only a part of the entire situation will be represented explicitly (e.g. one has to have in mind the code and the place, where and in which invocation the program is actually running). On the other hand when the presentation is over only memorization is available. A repetition of the representation is impossible.

In my opinion, the generation of an (usually very expendable) animation fulfills the requested task at best. An animation concerning the representation of the running of a program fulfilling the computation of the recursive version of factorial(3) is applied in my lecture (cf. [Dittrich 01]). This animation is generated using Macromedia Director and runs stand alone under Mac OS 9. The interested reader is invited to visit the web page of the lecture which can be found in [Dittrich 01]. Although a paper is a completely different media and in no way appropriate to represent an animation I'll try to do this by describing the main issues in text form supported by some screenshots. In total, the animation comprises 73 different displays with animated transitions. I assume the reader is familiar with the content of running recursively described functions. Therefore, I will only explain the specialties of representation, not the content to be represented.

Page 958

Let us start with Figure 1, where you can see the code of the recursively written function "factorial" with an application in a main-program (written in C++) as required in Chapter 2, (1).

Figure 1: Code of the program to be run

(In the above and the following figures the yellow frames and bold numbers are only for clarifying the references or for highlighting. They are not part of the animation.)

In the area 4, figure 2 shows (according to chapter 2(4)) the current status of the output of the program. Actually, you can only see the insertion point for output, represented by "-" . Area 5 shows a comment (cf. Chapter 2 (5)). In area 6 you can find the line, which is actually to execute, highlighted by a darkened background.

Page 959

Figure 2: Starting point for execution

Figure 3: First invocation of the function factorial with current parameter 3

In Figure 3 we find the situation before execution of the function "factorial" with the current parameter 3. In addition to the explanations of 4, 5, and 6 (with the current information top left we find the current part of existing variables (according to chapter 2(3)). As can be seen, in order to gain insights in the global state of this situation, we have to look at 4 different distributed places.

Page 960

Let us switch to the Figure 4. Figure 4 shows the situation, that the program is just before executing factorial for the second time, that is in this case with current parameter 2. Here the control is transferred to the first invocation of factorial. This is expressed by darkening the main program (cf. 2, as required in Chapter 2 (2)). The current state of the program is composed of the current value of the variable "number" of the main program, the current values of the local variables and the current parameter, here denoted as P-Value, for the next invocation of "factorial". You can find all this information explicitly.

Figure 4: Situation before executing factorial for the second time

Figure 5: Situation immediately after invoking factorial for the second time

Figure 5 depicts the situation immediately after the second invocation. The shadowing of the code of the first invocation of the code is accompanied with a shadowing of the local variables. These two phenomena can be seen as represented in the parts 2 and 3, respectively.

Page 961

As you know, in order to come to the terminating branch of "factorial" we need three invocations of the function in total. The main part of this situation after executing the third invocation can be found in Figure 6. Here we have stacked function invocations and local variables 3 times. The result of the last invocation is 1. Directly after this execution the instance of the third invocation will be removed uncovering the second invocation of "factorial" and leaving the result "1" for the call of factorial. This can be seen in figure 7. Now the calculation in the second instance of factorial can be executed. This situation can be found in Figure 8. In more steps similar to those represented in Figures 6 to 8 we can come back to the first call of factorial in the main program.

Figure 6: Situation after executing factorial for the third time

Figure 7: Situation immediately after removing the third invocation

Page 962

Figure 8: Calculation in the second instance

The situation there can be seen in Figure 9.

Figure 9: Situation immediately after execution of the first call of factorial

The very end is depicted in figure 10.

Figure 10: End of program running with total output and comment

Page 963

After looking at all these screenshots I hope the reader is convinced that all relevant aspects as mentioned in chapter 2 are really explicitly modeled thus leading to an easy understanding of the description of nontrivial issues.

With respect to this animation one may think to pursue the following alternative:

Run the program in a modern program developer tool in the debug mode (e.g. Project Builder under Mac OS X). This procedure has the big advantage that different programs can be explained in detail. Disadvantages are that on the one hand the stacking mechanism is a little bit difficult to understand and on the other hand that the presentation is not reproducible in a natural manner. The second drawback can be avoided by filming the display with a camcorder or by applying an appropriate program for catching the dynamic content of the display or parts of them (e.g. Snaps Pro under Mac OS X).

4 Conclusion

Using the example factorial(3) to introduce the mechanism of running programs with recursion we explained how to profit from representing dynamics by applying animations or similar time based media objects. The price we have to pay is the development of an appropriate mental model explicitly representing all relevant aspects of that what happens. The differences to other usually applied presentations are discussed a little bit.

Now we are only in a position to gather experience to present dynamics applying time based media objects by developing further different examples. We hope that in the near future this will lead to some sort of methodology in order to develop such documents.

References

[Dittrich 98] Dittrich, G.: "Rechnerunterstützte Informatiklehre: Ansätze zur Einbringung von Hypermedia-Elementen in den Hochschulunterricht" in Appelrath, H.-J. - Boles, D. - Meyer-Wegener (Edts.) Tagungsband WS Multimedia-Systeme, p. 19-30, 28. GI-Jahrestagung, Magdeburg, Sept. 1998 (in German)

[DittWest 00] Dittrich, G. - Westbomke, J.: "On Potential Areas of Multimedia-Application in Teaching and Learning at Universities", Article idpt99072 of IDPT2000 (International Conference on Integrated Design and Process Technology) Dallas, Texas, June 2000

[Dittrich 01] Dittrich, G.: "Einführung in die Informatik für Naturwissenschaftler und Ingenieure I, WS 2001/02, FB Informatik, Uni Dortmund, (in German) http://mediasrv.cs.uni-dortmund.de/Lehre/EINI-I_WS01_02/index.html (in German)

[DoberDiss 96] Doberkat, E.-E. - Dißmann, S.: Einführung in die objektorientierte Programmierung mit BETA, Addison-Wesley, 1996 (in German)

Page 964