LOG IN: 17 (1997) Heft 3/4

Programmierumgebungen für die Schule

von Bernhard Husch

Betrachtet man moderne, für die PC-Plattform bestimmte Programmierumgebungen, stellt man fest, daß es in der Erscheinungsform der Benutzeroberflächen kaum Unterschiede gibt. Man könnte fast meinen, die Softwarehersteller schrieben voneinander ab. Auch in der Funktionalität gleichen sich die Software-Entwicklungswerkzeuge meist, in der Regel werden komplette Programmierumgebungen mit integriertem Debugger und sogar einem Versionskontrollsystem geliefert. Einige dieser modernen Programmiersysteme sollen hier vorgestellt und zugleich daraufhin überprüft werden, welche Möglichkeiten sie für einen aktuellen Informatikunterricht bieten.

Wandel des Programmierens in der Schule

Bevor wir uns der Ausstattungsfrage der häufig hochkomplexen Entwicklungsumgebungen zuwenden, ist jedoch zu fragen, ob der Informatikunterricht der allgemeinbildenden Schule sie wirklich benötigt. Es ist unbestritten – und die meisten Rahmenpläne für Informatik in der Bundesrepublik Deutschland berücksichtigen dies –, daß nicht jede Programmiersprache zum Einsatz im Unterricht geeignet ist. Schon frühzeitig wurde in den ersten Rahmenplanentwürfen die Verwendung einer strukturierten Programmiersprache gefordert, wobei der Grad der Strukturiertheit unterschiedlich aufgefaßt wird und wurde; die erhitzten Diskussionen zwischen BASIC-Befürwortern und PASCAL-Vorreitern noch bis in die achtziger Jahre sind den Informatiklehrerinnen und -lehrern bestimmt noch gut in Erinnerung. Diese Diskussion soll an dieser Stelle nicht noch einmal aufgeworfen werden, zumal sich heute die Diskussion auf einer anderen Ebene abspielt: Häufig wird heute als Kritikpunkt ins Feld geführt, daß die PC-basierten Programmiersprachen nicht an internationalen Normen ausgerichtet sind, demzufolge auch keine portierbaren Programme geschrieben werden können.

Auch dies sind nur Scheingefechte, denn zum einen ist anzumerken, daß der Informatikunterricht der allgemeinbildenden Schule keine Programmierausbildung vorsieht; im Zentrum des algorithmischen Teils stehen Lernziele, die sich auf das Verständnis von (Standard-) Algorithmen beziehen. Wie diese Ziele umgesetzt werden, dürfte relativ egal sein, Hauptsache ist, daß das dazu benutzte Werkzeug die adäquaten Mittel zur Umsetzung von Algorithmen in Computerprogramme besitzt. Unter Umständen kann sich zum Beispiel herausstellen, daß das imperative Programmierparadigma überhaupt kein angemessenes Werkzeug zur Bildung bestimmter Algorithmen ist.

Zum anderen muß berücksichtigt werden, daß der Informatikunterricht Unterrichtsgegenstände exemplarisch aufgreift. Dies gilt auch für die hier verwendeten Programmiersprachen. Es steht nicht zu erwarten, daß die wenigen Schüler, die später tatsächlich einen Beruf ergreifen, der Programmierkennntisse erfordert, eben mit genau der Programmiersprache, in der sie in der Schule unterrichtet wurden, arbeiten werden.

Schließlich gibt es auch äußere Zwänge, die die Benutzung einer bestimmten Programmiersprache erforderlich machen; z.B., weil in der Schule keine andere Programmierumgebung verfügbar ist, und eine Neubeschaffung aufgrund einer angespannten Haushaltslage nicht durchsetzbar ist.

Ist man dennoch in der glücklichen Lage, eine neue Programmierplattform für die Schule auswählen zu können, so spricht eigentlich nichts dagegen, sich für eines der modernen Werkzeuge zur Softwareentwicklung zu entscheiden. Die Auswahl im Bereich der PC-Programmierung bleibt allerdings bescheiden und hängt weitestgehend vom zur Verfügung stehenden Budget ab.

Zwei Beispiele aktuellerProgrammierplattformen

JAVA

Ganz preiswert kann man es bekommen, wenn man sich für die Programmiersprache JAVA entscheidet. Den JAVA Development Kit – eine Programmierumgebung für JAVA-Anwendungen und JAVA-Applets – kann man kostenfrei aus dem Internet beziehen. Neben der kostengünstigen Lösung besticht hier vor allem die Möglichkeit, plattformübergreifend programmieren zu können: JAVA-Programme, auf dem PC entwickelt, lassen sich ohne Portierungsaufwand auf jede andere Systemplattform übertragen.

Der Nachteil bei der Benutzung von JAVA besteht darin, daß ein fundiertes Wissen über objektorientierte Programmierung erforderlich ist und daß – speziell zur Programmierung von Benutzeroberflächen – eine intensive Kenntnis der entsprechenden Bibliotheken zur Oberflächenprogrammierung benötigt wird. Im JAVA Development Kit (JDK) ist auch kein visuelles Entwicklungswerkzeug für die Gestaltung von Benutzeroberflächen enthalten, so daß diese wie unter Borland PASCAL for Windows im Quellcode ausprogrammiert werden müssen. Für den Informatikunterricht bedeutet das, daß man zunächst einen großen Vorlauf benötigt, um sich schrittweise an die Möglichkeiten und Grenzen der Programmierumgebung heranzutasten.

Spielprogramm mit VisualBASIC 4

Motivierender für Schüler ist es, wenn man sofort Ergebnisse sieht. In einem Lehrerfortbildungsseminar haben wir dies ausprobiert: Es sollte ein Spielprogramm für Windows geschrieben werden, bei dem der Anwender mit einem Ball nach einem sich bewegenden Gegenstand wirft. Ein erster, funktionierender Prototyp konnte bereits bei allen Beteiligten nach einer Sequenz von zwei Unterrichtsstunden begutachtet werden. Nach weiteren vier Unterrichtsstunden standen zahlreiche unterschiedliche Spielprogramme bereit, die alle ihre speziellen Ausprägungen hatten (vgl. Bild 2).

Eine besondere Schwierigkeit bei der Einführung in die Programmierung von Anwendungen unter grafischen Benutzeroberflächen wie MS-Windows oder X-Windows besteht für den Programmierer (der in der Regel von der imperativen Programmierung beeinflußt ist) darin, daß sich die Programme nicht mehr durch Ablaufdiagramme (z.B. im Nassi-Shneiderman-Diagramm) darstellen lassen, weil der Benutzer aufgrund der Tatsache, daß er mit der Maus zu jedem Zeitpunkt überallhin auf dem Bildschirm herumklicken kann, zu jeder Zeit jede Funktion auslösen kann. Schränkt man diese Möglichkeit zu sehr ein, was durchaus realisierbar ist, wird auch die ereignisgesteuerte Benutzerumgebung sinnlos.

Ereignisgesteuerte Programme lassen sich am besten durch Zustandsdiagramme darstellen, weil durch sie die dynamischen Zusammenhänge richtig verdeutlicht werden können (s. dazu Doberenz/Kowalski, 1995, S.413ff.); demnach kann man diese Art von Programmen unter automatentheoretischen Aspekten betrachten. Wandmacher (1993, S.152ff.) beschreibt, wie verallgemeinerte Übergangsnetzwerke zur formalen Beschreibung von Benutzeroberflächen verwandt werden können.

In dem Beispiel des Spielprogramms wurde so nicht verfahren, sondern es wurde versucht, einen intuitiven Zugang zu den programmtechnischen Erfordernissen zu finden. Es sollte überlegt werden, wie sich die Objekte durch Ereignisse verändern bzw. durch welche Ereignisse bestimmte Aktionen ausgelöst werden.

Es konnte schnell herausgefunden werden, daß die Bewegungen des Lachgesichts am Boden des Fensters und die Ballbewegung durch von einem Zeitgeber ausgelöste Ereignisse hervorgerufen werden müssen. Der Zeitgeber ist ein Systemobjekt, das durch die Programmierumgebung zur Verfügung gestellt wird.

Eine entsprechende Ereignismethode ließ sich nun schnell schreiben: Jedesmal wenn der Zeitgeber ein Ereignis ausgelöst hatte, sollte sich das Lachgesicht um eine bestimmte Strecke (hier 100 Pixel) auf dem Bildschirm nach links bewegen. War der linke Fensterrand erreicht, sollte es am rechten Fensterrand wieder erscheinen. Der Programmcode dazu sieht wie folgt aus:

Private Sub LachgesichtsStoppuhr_Timer()
If Lachgesicht.Left > -444 Then

Lachgesicht.Left = Lachgesicht.Left - 100

Else

Lachgesicht.Left = 6000

End If

End Sub

Das Ungewohnte bei dieser Art der Programmierung ist, daß es völlig gleichgültig ist, in welcher Reihenfolge die Ereignismethoden (oder -prozeduren) im Programmcode stehen, weil nicht sie die zeitliche Abfolge des Abarbeitens bestimmt, sondern es hängt von den Ereignissen ab, welches Codesegment zum Aufruf gelangt.

Prinzipien der visuellen Programmierung

Im Zusammenhang mit den modernen Entwicklungsumgebungen wird häufig der Begriff „visuelle Programmierung“ verwandt. Visuelle Programmierung beruht auf der Tatsache, daß die Funktionsauslösung in Programmen über Dialogkomponenten erfolgt, die auf der Benutzeroberfläche sichtbar sind; das können einfache Schaltflächen (Buttons), Optionsschaltflächen (Radiobuttons), Menüpunkte, Eingabefelder, Rollbalken usw. sein. Je nach Ausstattungsreichtum eines Entwicklersystems kann der Anwendungsprogrammierer auf eine mehr oder weniger gut ausgestattete Bibliothek derartiger Komponenten zugreifen und sie in seinen Programmen benutzen.

Objektorientiertes Datenmodell als Grundlage

Da den meisten dieser Entwicklungsumgebungen ein objektorientiertes Datenmodell zugrunde liegt, sind diesen Komponenten bestimmte Eigenschaften und Verhaltensweisen zugeordnet, die sich schon zur Entwurfszeit der Programme festlegen lassen.

Zunächst wird bei der visuellen Programmentwicklung die Benutzerschnittstelle definiert, indem man in einem für die Programmausführung vorgesehenen Fenster die für das Programm erforderlichen Dialogkomponenten zusammenstellt. In Bild 3 ist als Beispiel die Entwicklung einer Datenbankanwendung dargestellt, bei der die Schnittstellenkomposition schon recht weit fortgeschritten ist. Die Dialogkomponenten wurden aus einer Komponentenbibliothek einfach in das Programmfenster gezogen, und durch die Beschreibung ihrer Eigenschaften im linken Fenster wurde ihre spätere Erscheinungsform und ein bestimmtes Grundverhalten festgelegt.

Aufgabe des Programmierers ist es, durch Beschreibung von Ereignismethoden die Benutzeroberfläche „zum Leben zu erwecken“. Bei dieser Datenbankanwendung wurde zum Beispiel eine Ereignismethode entwickelt, in der beschrieben wird, was passieren soll, wenn ein Anwender auf die „Einfügeschaltfläche“ mit der Maus klickt. Da in dem Programmfenster ein Karteikartensystem als Strukturierungsobjekt für die einzugebenden Daten benutzt wird, muß bei einem solchen Einfügeereignis unterschieden werden, welche Karteikarte gerade ausgewählt war als das Ereignis eintrat. Der entsprechende Programmcode sieht so aus:

procedure TfrmHauptformular.cmdNeuClick (Sender: TObject);

begin

with dmWandertag do

case pcKarteikarten.Activepage.Pageindex of
0 : Datensatz_Einfuegen (tbZiele);
1 : Datensatz_einfuegen (tbInstitutionen);
2 : Datensatz_einfuegen (tbPersonen);
3 : Datensatz_einfuegen (tbOeffnungszeiten);
4 : Datensatz_einfuegen (tbKategorien);

end {case}

end;

procedure TfrmHauptformular.Datensatz_einfuegen (eine_Tabelle : TTable);

begin

if not eine_Tabelle.Active then
eine_Tabelle.Open;

if not (eine_Tabelle.State = dsInsert) then begin

Insertschalter_aktivieren (‘nein’);
Editschalter_aktivieren (‘nein’);
Suchschalter_aktivieren (‘nein’);
Deleteschalter_aktivieren (‘nein’);
Druckschalter_aktivieren (‘nein’);
Navigationsschalter_aktivieren (‘nein’);
eine_Tabelle.Insert

end {if}

end;

In diesem Fall würde also die Variante mit der Marke 0 ausgewählt und abgearbeitet werden. Da sich das Einfügen auf unterschiedliche Tabellen der Datenbank beziehen kann, wurde eine für alle Tabellen gültige Einfügemethode geschrieben, die im wesentlichen die Benutzeroberfläche für die Funktion umgestaltet, indem nämlich alle Schaltflächen – und damit alle Datenbankfunktionen – deaktiviert werden, die während des Einfügeprozesses nicht aufgerufen werden dürfen.

Mit diesem Ereignis, das die Benutzerschnittstellengestaltung betrifft, ist ein weiteres Ereignis verknüpft: Das Einfügen eines neuen Datensatzes muß in gewisser Weise vorbereitet werden. Dazu werden zwei Datenbankereignisse herangezogen, die jedesmal beim Einfügen eines neuen Datensatzes von der Database-Engine ausgelöst werden. Diese Ereignisse sind mit der betroffenen Tabelle verbunden und wurden in diesem Fall wie folgt ausprogrammiert:

procedure TdmWandertag.tbZieleNewRecord(DataSet: TDataSet);

begin

with frmHauptformular do begin

edSBahn.Text := ‘keine Angabe’;
edUBahn.TExt := ‘keine Angabe’;
edBus.Text := ‘keine Angabe’;
edTram.Text := ‘keine Angabe’;
radOrtsangabe.Value := ‘draußen’;
chkErmaessigung.Checked := false;
chkVoranmeldung.Checked := false;

end {with}

end;

procedure TdmWandertag.tbPersonenAfterInsert (DataSet: TDataSet);

begin

if not sqlLetztePersonennummer.Active then sqlLetztePersonennummer.Open;

tbPersonenPersonennummer.VAlue := sqlLetztePersonennummerLetzteNummer.Value + 1;

end;

Im ersten Codebeispiel werden im Eingabeformular des Programms Standardwerte in die Dialogkomponenten eingetragen, im zweiten wird der Identifikationsschlüssel der Tabelle auf den nächsten gültigen Wert gesetzt.

Datenbankschnittstellen als weitere Grundlage

Und damit erschließt sich schon eine weitere Dimension moderner Programmentwicklungs-Umgebungen. In der Regel bieten diese Werkzeuge auch eine oder mehrere Datenbankschnittstellen an. Für den Informatikunterricht scheint dies auch interessant zu sein, weil die integrierten Datenbankschnittstellen die Anwendungsprogrammierung für Datenbanken ermöglichen, ohne daß man auf eine völlig anders geartete „Programmiersprache der Vierten Generation“ (4GL) ausweichen muß.

Bei den aktuellen relationalen Datenbank-Managementsystemen (RDBMS) wird in der Regel die Datenbanksprache SQL zur Datendefinition und -manipulation verwendet. Anwendungsprogrammierung ausschließlich unter der deskriptiven Programmiersprache SQL ist nicht möglich, so daß die meisten Softwareentwickler für ihr RDBMS eine eigene Anwendungssprache liefern.

Im Berliner Rahmenplan für Informatik in der SekundarstufeII sind Datenbanken als Unterrichtsgegenstand vorgesehen. Einige Berliner Schulen haben dem Rechnung getragen, indem sie für ihre (Unix-) Rechner ein professionelles RDBMS beschafft haben, bei dem sich Anwendungsprogrammierung mittels einer speziellen 4GL durchführen läßt. Der Lernaufwand ist jedoch unter dem Aspekt, daß vorher in einer anderen Programmiersprache gearbeitet wurde (meist MODULA-2 oder PASCAL), unvergleichlich hoch, so daß es sinnvoll erscheint, die vorher benutzte Programmiersprache mit einer entsprechenden Datenbankschnittstelle weiterzubenutzen. Das ist bei den modernen Entwicklersystemen gegeben.

Die Arbeit mit Datenbanken wird zudem ebenfalls durch die Bereitstellung visueller Datenbankwerkzeuge unterstützt. So lassen sich zum Beispiel in Delphi Datenbankabfragen sehr bequem mit einem Abfragegenerator konstruieren (s. Bild 4). Bei VisualBASIC sind die Werkzeuge zur Datenbankdefinition und -manipulation Bestandteil der Programmentwickungsumgebung.

Zur Auswahl von Programmiersystemen

Pomberger und Blaschek (1993) nennen folgende Qualitätskriterien – unter anderen – für die Auswahl einer Programmiersprache in einem Softwareprojekt: Modularität, Dokumentationswert, Datenstrukturen, Ablaufsteuerung, …, Dialogtauglichkeit, spezielle Sprachelemente. Diese Kriterien sind auch an eine für die Schule geeignete Programmiersprache zu stellen, wobei die Auswahl letztlich von der Methode abhängt, mit der ein Softwaresystem entworfen wird.

Objektorientierte Entwurfsstrategien als Mittelpunkt

Wählt man eine objektorientierte Entwurfsstrategie, empfiehlt sich auch die Verwendung einer objektorientierten Programmiersprache. In der Schule benutzte Programmiersprachen mit objektorientierten Erweiterungen gibt es bereits seit längerer Zeit: Turbo-PASCAL (ab Version 4.0), TopspeedMODULA-2 und FST MODULA-2. Speziell die PASCAL-Variante von Turbo-PASCAL hat sich im Laufe der Zeit zu einer gut handhabbaren objektorientierten Programmiersprache entwickelt, bei der der Anwendungsprogrammierer kein Wissen über technische Details der Speicherverwaltung bei der Instantiierung von Objekten einbringen muß.

Objektorientierte Programmierung wird fälschlicherweise häufig ausschließlich in Zusammenhang mit der Programmierung von Benutzeroberflächen gebracht. Daß die Oberflächenprogrammierung nur einen Teilaspekt in diesem Zusammenhang darstellt, mag folgendes Beispiel zeigen: Es sollte ein Programm zur Demonstration der Funktionen in Listen geschrieben werden. Die Benutzerschnittstelle war sehr einfach definiert (s. Bild 5). Die Hauptarbeit bestand nun darin, eine geeignete Datenstruktur für Listen zu entwickeln, die sich dadurch auszeichnete, daß sie jederzeit erweitert und/oder spezialisiert werden konnte. Hintergrund war, daß später aus der allgemeinen Listenklasse spezielle Listentypen wie „Stacks“ und „Queues“ abgeleitet werden sollten.

Die Ausgangsüberlegung bestand darin, daß alle Listen leer sein können, oder eine bestimmte Anzahl von Elementen beinhalten können. Die Elemente einer Liste haben gleiche Eigenschaften, sie können einen Vorgänger und einen Nachfolger haben, ein Vorgänger bzw. Nachfolger muß an das Listenelement angekettet werden können und auch wieder abgehängt werden können. Über die Nutzdaten, die in diesen Listenelementen verwaltet werden sollen, braucht man zu diesem Zeitpunkt nichts zu wissen. Die entsprechende Klassen- definition sieht dann in ObjectPASCAL wie folgt aus:

unit Links;
interface

type

TLink = class

constructor create;
{Erzeugt ein Element}

destructor destroy;
{Entfernt ein Element}

procedure set_next (next_link : TLink);
{Bindet ein Element next_Link an dieses als Nachfolger}

function get_next : TLink;
{Liefert das nachfolgende Element}

procedure set_prev (prev_link : TLink);
{Bindet ein Element prev_Link an dieses als Vorgänger}

function get_prev : TLink;
{Liefert das vorhergehende Element}

private
Previous,
Next : TLink;

end {TLink};

Auf die Vorgänger bzw. Nachfolger kann hier nur mittels der Methoden der Klasse zugegriffen werden, die Daten sind nach außen gekapselt.

Möchte man nun spezielle Elemente haben, die auch Nutzdaten – zum Beispiel ganze Zahlen – verwalten können, so kann man die allgemein beschriebene Klasse der Elemente mittels der Technik der Vererbung dazu benutzen.

unit IntegerLinks;
interface
uses Links;

type

TIntegerLink = class(TLink)

procedure set_Value (the_Value : integer);
{Schreibt eine ganze Zahl the_Value in das Element als Dateninhalt}

function get_Value : integer;
{Liest den Dateninhalt (ganzzahlig) aus dem Element}

private
Value : integer;

end {TIntegerLink};

Die spezialisierte Klasse TIntegerLink hat sämtliche Eigenschaften und Methoden von der Klasse TLink geerbt und darüber hinaus zwei neue Methoden und eine neue Eigenschaft dazugewonnen. Es läßt sich leicht sehen, daß aus der allgemeinen Klasse TLink viele spezialisierte Klassen abgeleitet werden können, die nicht nur auf einfachen Datenstrukturen, sondern auch auf komplexen Konstrukten basieren können.

Die Elemente sollen in einer Liste verwaltet werden. Welche Operationen auf Listen angewandt werden können, läßt sich auch wieder allgemein beschreiben. Nachstehend sei ein Auszug aus der Klassenbeschreibung für die allgemeinen Listen dargestellt.

unit Lists; {Klasse der doppelt verketteten Listen.}
interface
uses Links; {benutzt Klasse der Links (Knoten)}

type

TList = class

constructor create;
{Erzeugt eine leere Liste}

destructor destroy;
{Leert die Liste und entfernt sie.}

procedure append (the_Element : TLink);
{Setzt ein neues Element an das Listenende}

procedure prepend (the_Element : TLink);
{Setzt ein neues Element an den Listenanfang}

procedure insert_before (the_Element : TLink);
{Fügt ein neues Element vor dem akuellen ein}

procedure insert_after (the_Element : TLink);
{Fügt ein neues Element hinter dem aktuellen ein}

procedure delete;
{Entfernt das aktuelle Element aus der Liste. Es kann nicht mehr auf das Element oder seinen
Wert zugegriffen werden.}

procedure set_last;
{Positioniert auf das letzte Element der Liste. Dies ist nun das aktuelle Element.}

function is_first : boolean;
{Prüft, ob der Listenanfang erreicht ist.}

function is_last : boolean;
{Prüft, ob das Listenende erreicht ist.}

function empty : boolean;
{Prüft, ob die Liste leer ist.}

private

Head, {Listenanfang, erstes Element}
Tail, {Listenende, letztes Element}
Current : TLink;
{Element an der aktuellen Listenposition}

end {TList};

Die technischen Details zur Organisation der Liste werden auch hier nach außen hin verborgen, indem nämlich die Objekte Head, Tail und Current in einer privaten Deklaration aufgeführt werden.

Schließlich wird alles in einen Zusammenhang mit der eingangs beschriebenen Benutzeroberfläche gebracht. Die Werte für die Listenelemente sollen in das Eingabefeld geschrieben werden, und durch Klicken auf eine der Schaltflächen unter dem Eingabefeld wird die jeweilige Listenoperation ausgelöst. Das nachfolgende Codebeispiel bezieht sich auf den Fall, daß ein neues Listenelement vor das augenblicklich aktuelle Element gesetzt werden soll.

procedure TfrmListe.btInsertBeforeClick(Sender: TObject);

var

neuesElement : TIntegerLink;

begin

neuesElement := TIntegerLink.create;
neuesElement.set_Value(StrToInt(edEingabe.Text));
die_Liste.insert_before(neuesElement);
edEingabe.SetFocus

end;

Fehlerbehandlung

Ein weiterer Ausschnitt aus dem Modul zur Gestaltung und Versorgung der Benutzerschnittstelle soll ein Beispiel dafür geben, wie eine Fehlerbehandlung das Programm vor unerwünschten Abstürzen schützen kann. Der Code, in dem ein Fehler auftreten kann, ist durch ein try … except-Konstrukt geschützt; tritt in dem Block nach dem try ein Fehler auf, so wird eine Ausnahmebehandlung eingesetzt, die bei der auf das except folgenden Anweisung beginnt. In diesem Fall wird vermieden, daß beim Blättern in der Liste über das Listenende hinaus gelesen wird.

procedure TfrmListe.btNextClick(Sender: TObject);

var

das_Element : TIntegerLink;

begin

try

if not die_Liste.empty then

if not die_Liste.is_last then begin

die_Liste.set_next;
das_Element := TIntegerLink (die_Liste.get_current);
edEingabe.Text := IntToStr (das_Element.get_Value) end {if}

else

MessageDlg(‘Das Ende der Liste ist bereits erreicht.’, mtInformation, [mbOk], 0)

else

MessageDlg(‘Die Liste ist leer.’, mtInformation, [mbOk], 0)

except

on EAccessviolation do
MessageDlg(‘Der Stack ist leer.’, mtInformation, [mbOk], 0)

end {except};

edEingabe.SetFocus

end;

Fazit

Unser kleiner Rundgang durch die Möglichkeiten, die moderne Programmierumgebungen bieten, ist damit beendet. Speziell die aktuellen Softwarewerkzeuge für den Personal Computer verfügen über eine derartige Mächtigkeit, daß sie in der Schule sicherlich mit vollem Nutzen eingesetzt werden können. Trotzdem ist es die Überlegung wert, ob man nicht mit den Vorteilen der visuellen Programmierung eine neue Motivation zum Programmieren bei Schülern erzeugen kann. Voraussetzung dazu ist jedoch, daß man neue Überlegungen über die Inhalte des Informatikunterrichts anstellt. Denn mit den traditionellen Konzepten von Softwareentwicklung lassen sich die neuen Entwicklungssysteme nicht mehr sinnvoll einsetzen.

Literatur

• Doberenz, W.; Kowalski, Th.: Visual BASIC. München, Wien: Carl Hanser Verlag, 1995.
• Wandmacher, J.: Software-Ergonomie. Berlin u.a.: Walter de Gruyter, 1993.
• Pomberger, G.; Blaschek, G.: Grundlagen des Software-Engineering – Prototyping- und objektorientierte Software-Entwicklung. München, Wien: Carl Hanser Verlag, 1993.

Erstellt: 20-Oct-1997 von: Agon S. Buchholz <asb@zedat.fu-berlin.de>.
Zuletzt bearbeitet: 05-Jun-00 von: Agon S. Buchholz <asb@zedat.fu-berlin.de>.
Projekt: LOG IN: Archiv: 1997: Ausgabe 3/4: Thema: Programmierumgebungen für die Schule
URL: http://log-in.fachdid.fu-berlin.de/Archiv/1997/3-4/programmierumgebungen.html.