Maria Knobelsdorf, University of Dortmund, Germany - Didaktik der ...

3.1.1 Greenfoot as a framework for designing
learning environments
The idea of using Greenfoot for the project course arose
from the fact that Greenfoot is not just the programming environment
itself but features an easy-to-use Java API for the
development of 2D-graphical games and simulations. Since
the Greenfoot framework is based on Java, it facilitates the
development of quite complex scenarios: “While it is possible
to create simple games quickly and easily in Greenfoot, it
is equally possible to build highly sophisticated simulations
of complex systems [...]” (Kölling [27], p. 2).
Thus Greenfoot is, in principle, well suited to provide both
an introductory development environment and meaningful
contexts. Henriksen and Kölling suggest that Greenfoot
would open new possibilities for course design because it allows
for using multiple scenarios of varied complexity and
from different application areas [16]. Moreover scenarios
can, in principle, be adapted to different learning theories
and to different learning objectives related to both object
orientation and other informatical issues beyond programming.
These new possibilities are promising. But obviously the
freedom to develop and adapt scenarios, or maybe even just
to select them to match specific course objectives, involves
additional time and effort for course preparation (figure 1).
Traditional microworlds Greenfoot
Implement framework
(with fixed scenario)
Design exercise
Solve exercise
Framework
implementor
Teacher
Student
Implement framework
Design scenario
Design exercise
Solve exercise
Framework
implementor
Student
Teacher
Figure 1: Roles in creation and use of traditional
microworlds and Greenfoot scenarios, according to
Henriksen and Kölling [16]. Greenfoot scenarios –
games and simulations – can be shared in the Greenfoot
gallery or maybe along with some ‘nifty assignments’
[11] in the Greenroom. (Adapted from [16])
Our project course aimed for fathoming the possibilities
provided by the Greenfoot framework, and the limitations.
In consideration of Nygaard’s advice that teaching objectorientation
must start with a “sufficiently complex example”
[30], we focused on developing scenarios that were conspicuously
more complex than conventional microworlds. The
challenge was to design these complex scenarios in such a
way that they would fit well into the framework and at the
same time match the classroom requirements so as to arrange
learning environments around them.
While Greenfoot as an IDE is aimed at young students
[43], for advanced students it’s well-designed API gives a
good and concise example of an object-oriented framework.
In developing against the Greenfoot framework (and yet using
a professional development environment) our Informatics
students learn how to elegantly handle and extend a given
framework.
113
3.1.2 Software development as decontextualization
and recontextualization
Our department has a strong tradition in questioning the
“separability of production from the use of products in social
contexts” ([14], p. 49), that is associated with e. g. Floyd
and colleagues [12, 14], and that has been influenced by
the so-called Scandinavian Approach [13]. Typically, when
our students enroll for the project course they are already
acquainted with the ideas of agility [2] and the perspective
on software development as an evolutionary process that
intertwines software production, embedment and use.
Therefore another starting point for the development of
our process model is our understanding of software development
as a design process and a social activity incorporating
alternate decontextualization and recontextualization
activities. Instead of bringing up Dijkstra’s ‘firewall’ between
the realm of the ‘correctness problem’ and the realm
of the ‘pleasantness problem’ [9], the dialectic of decontextualization
and recontextualization emphasizes that software
is situated in human contexts.
Decontextualization refers to the analysis and translation
of contextualized meaning and ‘situated action’ [38] into
models, algorithms, programs and other computational artifacts.
On the other hand recontextualization is the transfer
and embedment of formalized decontextualized activities,
programs etc. into a human context and results in transforming
it. Figure 2 illustrates this ‘socio-technical core’ on
the basis of Rolf and colleagues [25, 33, 44].
Along with the ‘roles in creation and use of Greenfoot
scenarios’ shown in figure 1, we adopted this model as a
central pattern for the design of our process model.
Context
Recontextualization
Decontextualization
Artifacts
Figure 2: The ‘socio-technical core’ (cf. [25, 33, 44])
of alternate decontextualization and recontextualization
processes in software development activities
serves us as a starting point and as a pattern for our
model design.
3.2 Phase 1: First project course
The outline of our first project course offered in winter
2009/10 can be considered as our first prototype process
model. Our course of action featured many aspects we later
elaborated in our model. A central activity was developing
computational artifacts like models, Greenfoot simulations
and other programs and documents that would be employed
as learning equipment in the classroom context of a school
project. But we also gave attention on theoretical and transdisciplinary
foundations like learning styles, gender and diversity
issues [32].
The most important result that emerged from this first
project course was a terminology related to our course setting.
In contrast to other software development projects in
our project the context that was to be analyzed often was not