Suche Home Einstellungen Anmelden Hilfe

Zusammenfassung:

Abstract:

1. Modellieren im anwendungsorientierten Informatikunterricht
2. Modellieren und Denkschulung
3. Modellieren und Softwaretechnik
4. Modellieren und gesellschaftliche Auswirkungen
5. Fazit
6. Literatur
7. Anhang

1. Modellieren im anwendungsorientierten Informatikunterricht

Das Anfertigen einer derartigen Skizze erfordert methodisch die Analyse der vorhandenen Quellen zur Informatikdidaktik, zu Unterrichtsinhalten, -methoden und vor allem der damit verbundenen Zielen, kurz: eine umfangreiche empirische Untersuchung. Ein sauberes methodisches Vorgehen würde also nicht nur den hier zur Verfügung stehenden Raum übersteigen. Daher werde ich mich auf eine recht grobe Skizze beschränken, die sich aus der Analyse der veröffentlichten Literatur zum Themenkomplex des Modellierens ableiten läßt. Um das Nachvollziehen zu erleichtern, können in der Online-Version des Artikels jeweils dort, wo auf Literatur eingegangen wird, kurze Zitate aus der angesprochenen Literatur aufgerufen werden - die wichtigen Zitate befinden sich direkt im Text.

Wie sieht also die Grundlage des typischen Informatikunterrichts aus, bezogen auf den Schwerpunkt des Artikels, das Modellieren? Um das festzustellen, müssen wir uns die Entwicklung des in der Didaktik so genannten anwendungsorientierten Ansatzes ansehen:

Im anwendungsorientierten Ansatz wollte man das "algorithmische Denken" sowie die "Auswirkungen der Datenverarbeitung auf die Gesellschaft" integrativ behandeln, um ein Auseinanderfallen des Informatikunterrichts "in einen Programmierkurs und einen Gesellschaftskundeunterricht" zu verhindern (Riedel, 1981, S.38). Beide Bereiche werden als konstitutiv angesehen, der Informatikunterricht dient als Denkschulung und als Vorbereitung auf eine informatisierte Welt.

Die Denkschulung erfolgt durch Problemlösen, das sich an den Methoden des Software-Engineering orientiert. Ein Beispiel dafür ist die Formulierung "Vom Problem zum Programm", so der Untertitel eines Schulbuchs (Balzert, 1987). Darin wird formuliert, "[i]m täglichen Leben steht man ständig vor Problemen, die man lösen muß" (S.13). Und etwas später (S.16f):

"Die Beispiele und Erläuterungen zeigen, daß das Lösen von Problemen ein umfangreiches Gebiet umfaßt. Ziel der Informatik ist es, Lösungsverfahren für bestimmte Probleme zu finden und so zu beschreiben, daß sie von DVAn abgearbeitet werden können. Dadurch ergeben sich Einschränkungen hinsichtlich des Problemkreises als auch hinsichtlich der Lösungsbeschreibungen.¹⁾"

Die Schüler sollen Verfahren zur Problemlösung lernen:

"Als ein Leitfaden auf dem Weg vom Problem zur Lösung wird ein Schema zum Problemlösen benutzt, das einen gewissen Rahmen bzw. eine Hilfestellung beim Problemlösen bietet und für viele Problembereiche ein sinnvolles systematisches Vorgehen ermöglicht" (S.17).

Nun, wo bleibt das Modellieren? Modellieren wird zu einem Begriff, der die planerischen Anteile (und Phasen) der Softwareentwicklung betont und als Gegensatz zum einfachen Codieren und zum so genannten 'Hacken' in Stellung gebracht wird. Dazu beachte man auch, wie im folgenden Zitat nebenbei auch der enge Zusammenhang zwischen Modellieren und Problemlösen angedeutet wird:

"Informatikunterricht soll kein Programmierkurs sein. Warum eigentlich nicht? [...] Problemlösen (Modellieren und Strukturieren) unter Anwendung von Informatikprinzipien und -methoden gilt als erstrebenswert. Die Programmiersprache soll im Hintergrund (Mittel zum Zweck) bleiben. Das aber ist Programmierung (nicht zu verwechseln mit Codierung)" (Schubert, 1991, S.27).

In einer weiteren Variante unterscheidet Eberle zwischen "relativ programmunabhängige[r] Umsetzung mittels der Strukturierungshilfsmittel wie Programmablaufplan, Struktogramm, Pseudocode oder auf einer höheren Ebene Datenflussplan" und der "Implementierung in einen Programmcode". Das "eigentliche" Problemlösen sei demnach die "Umsetzung der alltagssprachlich formulierten Problemstellungen in formale Beziehungen". Dabei falle "dem antizipativen Verständnis der zeitlichen Abläufe (Prozeduren)" besondere Bedeutung zu. Und daran zeige sich ebenfalls der Unterschied zur Mathematik (Eberle, 1996, S.329). Auch hier zeigt sich also die weitgehende Gleichsetzung von Problemlösen, Modellieren und Softwareentwicklung.

Halten wir den ersten Pinselstrich unserer Skizze fest: Anfang der Achtziger Jahre fällt eine Art didaktische Grundsatzentscheidung, in deren Folge das Unterrichtsziel (Vermittlung von Problemlösefähigkeiten), der Unterrichtsinhalt (Modellieren) und die Anbindung an die Wissenschaft Informatik (Softwareentwicklung) an einem Ort zusammenfallen. Diese Entscheidung hat über 20 Jahre Bestand.

Wenn nun feststeht, was man im Informatikunterricht zu welchem Zwecke macht, ist die Frage: wie soll man es machen? Welcher Unterrichtsablauf ergibt sich?

Nun, der Unterrichtsablauf ist in Phasen gegliedert, die dem Softwareentwicklungsprozess nachempfunden sind:

"Der Problemlöseprozeß kann in folgende Phasen gegliedert werden [...]:

• Problem- und Zielformulierung,
• Problemanalyse und Modellbildung,
• Algorithmierung,
• Codierung und Implementation,
• Benutzungsphase." (Riedel S.38)

Dieses unterrichtliche Vorgehen wird durch die Techniken 'Zergliedern in Teilprobleme' und 'Schrittweise Verfeinerung' unterstützt (vgl. Balzert, 1987, S.31-35. Eberle, 1996 S.95f (Koerber), 98f (Schubert), 104 (van Lück)).

Soweit hat sich nun ein recht abgerundetes Bild ergeben. Aber man wollte mit dem anwendungsorientierten Ansatz mehr erreichen: Gesellschaftliche Auswirkungen der Informatik sollten durch eine Hinwendung zur Modellierung und zu softwaretechnischen Methoden integrativ behandelt werden können.

Diese Frage ist im unterrichtlichen Gang jedoch ein Anhängsel geblieben. Dieses zeigt etwa die Kritik Baumanns, der eine Art Versozialwissenschaftlichung des Informatikunterrichts fürchtet (vgl. etwa Baumann, 1996, S.181).

Auch Forneck kommt in einer Untersuchung des anwendungsorientierten Ansatzes zu dem Schluss, dass "es in den untersuchten Unterrichtsreihen nicht gelingt, nach einer Algorithmisierung und Programmierung diese Tätigkeiten auf gesellschaftliche Fragen zurückzubeziehen" (Forneck, 1992, S.229).

Dies zeigt (für unsere Skizze), dass die Fragen nach den Auswirkungen oft nicht aus den informatischen Inhalten und Herangehensweisen motiviert werden und daher auch nicht auf der Grundlage der Unterrichtsinhalte des Informatikunterrichts beantwortet werden können.

Zudem ergibt sich die Frage, wie das Verhältnis zwischen Informatik und Gesellschaft gesehen werden kann bzw. soll.

Zum Teil steckt in der Aussage, die Wirkungen der Informatik sollen betrachtet werden, bereits eine Konzeption dieses Verhältnisses: Demnach ist die Informatik Ausgangspunkt von Veränderungen in der Gesellschaft. Das läuft im Grunde auf einen Technik-Determinismus (vgl. Chandler, 1996) hinaus:

"According to technological determinists, particular technical developments, communications technologies or media, or, most broadly, technology in general are the sole or prime antecedent causes of changes in society, and technology is seen as the fundamental condition underlying the pattern of social organization.
Technological determinists interpret technology in general and communications technologies in particular as the basis of society in the past, present and even the future. They say that technologies such as writing or print or television or the computer 'changed society'. In its most extreme form, the entire form of society is seen as being determined by technology: new technologies transform society at every level, including institutions, social interaction and individuals. At the least a wide range of social and cultural phenomena are seen as shaped by technology. 'Human factors' and social arrangements are seen as secondary." (http://www.aber.ac.uk/media/Documents/tecdet/tdet02.html)

In diesem Zusammenhang bekommt auch das Wort Baumanns von der 'Versozialwissenschaftlichung' einen anderen Klang: Wenn man tatsächlich die gesellschaftlichen Fragen nur ungenau, unscharf, unformal und im gewissen Sinne nicht formal-methodisch, nicht technisch-deterministisch behandeln kann, dann führt deren Thematisierung im Informatikunterricht zwangsläufig zu einem Bruch im unterrichtlichen Ablauf, der ja bislang (im Sinne unserer groben Skizze sogar ausschließlich!) von den formalen Schritten der Softwareentwicklung geprägt ist.

Zusammenfassung: Modellieren im anwendungsorientierten Ansatz beginnt mit der Setzung, den Unterrichtsablauf an das Wasserfallmodell der Softwareentwicklung zu koppeln. Damit wird der Begriff des Problemlösens nach und nach gleichbedeutend mit dem Begriff Softwareentwicklung. Problemlösendes Denken wird gleichgesetzt mit algorithmischem Denken. Schließlich kann die unterrichtliche Softwareentwicklung als Denkschulung bezeichnet werden. Das zweite Standbein des Ansatzes besteht in der Absicht, das Thema der gesellschaftlichen Auswirkungen in den Unterrichtsablauf (also in das Erstellen von Problemlösungen) zu integrieren. Diese Absicht konnte jedoch nicht zufriedenstellend umgesetzt werden. Zudem beruht sie auf einer Weltsicht, die Technik und Gesellschaft in ein unangemessenes deterministisches Verhältnis setzt.

2. Modellieren und Denkschulung

Die Transferforschung bezüglich der These, Softwareentwicklung fördere Problemlösefähigkeiten, zusammenfassend zieht Eberle folgende Schlussfolgerung:

"Beim Programmieren sind die Problemlöse- und Denkfähigkeiten an die Strukturen der Programmiersprache gebunden²⁾. Diese wiederum sind nicht auf die Problemlösestrukturen aller Probleme generalisierbar. Während wir an anderer Stelle [...] vor allem das erste negative Ergebnis betont haben, gilt es auch, deswegen nicht einfach den formalen Bildungswert dieser Inhalte in Frage zu stellen, sondern in positiver Weise den gefundenen spezifischen Transfer zu betonen: Demnach ist Programmieren/Algorithmik geeignet, a) spezifische Problemlösefähigkeiten für andere Bereiche herauszubilden und b) wie in anderen Fächern auch einen aufgrund des jetzigen Forschungsstandes nicht größeren, aber auch nicht kleineren Beitrag zur Entwicklung allgemeiner Problemlösefähigkeiten zu leisten." (Eberle, 1996, S. 212)

Die von Eberle herangezogenen Untersuchungen (Eberle, 1996, S.201-212) beziehen sich hauptsächlich auf Logo, aber auch auf Pascal, Fortran, Basic, zum Teil auf Standardanwendungen und Modellbildungswerkzeuge.

Insgesamt ordnet Eberle sein Konzept zum Problemlösen (wohlgemerkt: nach Analyse auch späterer Ansätze) in den anwendungsorientierten Ansatz ein. Demnach soll die "inhaltliche Struktur der informatischen Problemlösung als gleichzeitige Ablaufstruktur für den Unterricht" dienen (Eberle, 1996, S.331. Vgl. auch die Empfehlung S. 339 und das Beispiel auf S. 397).

Trotz manchmal anders lautender Berichte scheint sich demnach der in den achtziger Jahren entwickelte anwendungsorientierte Ansatz zumindest in Bezug auf das algorithmische Problemlösen bewährt zu haben - ansonsten hätte Eberle diesen Ansatz in 1996 nicht so direkt in seine Konzeption und seine Empfehlungen für den Informatikunterricht übernehmen können. Andererseits wird deutlich, wie sehr der Begriff Problemlösen an den Algorithmus-Begriff und an das imperative Programmieren bzw. die strukturierte Softwareentwicklung nach dem Wasserfallmodell gebunden ist³⁾.

In der Softwaretechnik jedoch haben sich die Methoden stark der Objektorientierung zugewandt: Objektorientierte Sprachen haben rein imperative abgelöst (vgl. Quibeldey-Cirkel, 1994. S.12), objektorientierte Vorgehensmodelle haben das Wasserfallmodell abgelöst (vgl. Quibeldey-Cirkel, 1994. S.105⁴⁾). Die ursprüngliche Idee des anwendungsorientierten Ansatzes, das Problemlösen im Informatikunterricht an die Methoden der Informatik anzukoppeln, ist jedoch nicht in Frage gestellt worden.

Welche Änderungen im Informatikunterricht könnte nun der Wechsel zu objektorientierten Methoden nach sich ziehen? Diese Änderungen könnten die Unterrichtsziele, -methoden und -inhalte betreffen.

Zunächst stellt sich die Frage nach unterschiedlichen Vorgehensweisen in der Softwareentwicklung, die ein verändertes unterrichtliches Vorgehen und andere Unterrichtsmethoden zur Folge haben können.

Ein für den Vergleich verschiedener objektorientierter Vorgehensmodelle in der Softwaretechnik entwickeltes Schema läßt eine bekannte Phasierung erkennen: "Für den neutralen Vergleich wurden die fünf Phasen Voruntersuchung, Systemanalyse, Entwurf, Erzeugung und Einführung gewählt" (Noack/Schienmann, 1999, S.170). Die groben Ablaufstrukturen der beiden hier unterschiedenen Paradigmen lassen zunächst also keine Unterschiede erkennen. Im Detail allerdings ergeben sich Abweichungen.

In den objektorientierten Vorgehensmodellen sind explizit Schleifen bzw. Iterationen möglich, der Problemlöseprozess wird stärker als ein heuristischer Prozess aufgefasst: als Suchen und Finden von Lösungsideen, die überprüft, verändert und verworfen werden können. Demgegenüber stellt sich das Wasserfallmodell eher als ein logisch-deduktiver Prozess dar.

Objektorientierte Vorgehensmodelle versuchen stärker (in Abgrenzung zum algorithmischen Problemlösen gesehen) Softwarequalitätseigenschaften wie Benutzbarkeit, Wiederverwendbarkeit, Flexibilität und Wartbarkeit zu berücksichtigen, und sie weisen der Phase Voruntersuchung (Anforderungsanalyse) eine stärkere Bedeutung zu, denn: "Man weiß, daß der Anfangszustand verändert werden muß, kennt aber den Zielzustand bloß vage oder gar nicht, allenfalls sind globale Zielkriterien bekannt, Komparative wie 'besser' oder 'effizienter'" (Quibeldey-Cirkel, 1999, S.47).

Betrachten wir zunächst die Auswirkungen der veränderten Vorgehensweise auf die Anforderungen, die an Softwareentwickler gestellt werden, demzufolge im Unterricht besonders trainiert und als Unterrichtsziele explizit ausgewiesen werden könnten. Diese induktive Art der Bestimmung von Unterrichtszielen reicht natürlich als Begründung für deren Setzung nicht aus. Bevor ich einige Anknüpfungspunkte für eine bildungstheoretische Begründung nenne, lege ich dar, wie sich die Unterrichtsziele im Bereich der Problemlösefähigkeiten ändern:

Fokussiert man die formalen Bildungsziele auf das problemlösende Denken, dann kann folgende Hypothese aufgestellt werden: Man kann zwischen einfachen und komplexen Problemen sowie (damit verknüpft) zwischen linear-analytischem und vernetztem Denken unterscheiden⁵⁾. Objektorientierte Methoden fordern und fördern Letzteres stärker als algorithmenorientierte Herangehensweisen.

Was ist vernetztes Denken? In einer Arbeitsdefinition kann vernetztes Denken "als ein situationsbezogenes Denken verstanden werden, bei dem die in einer spezifischen Denksituation relevanten Elemente zueinander in Relation gesetzt, integriert und zu einem Gesamtzusammenhang verflochten werden" (Möller, 1999 S.28). Gegenüber "linear-analytischem - auf logische-deduktive Kausalketten zurückführbarem - Denken" berücksichtigt vernetztes Denken Wechselwirkungen einzelner Teilaspekte und Gesamtzusammenhänge (Möller, 1999, S.28).

Durch die Thematisierung von Fragen, die über die algorithmische Problemlösung hinausgehen (Softwarequalitätskriterien und Einbettung in Anwendungskontext) kann eine objektorientierte Methodik möglicherweise komplexere Denkweisen fordern und fördern: Die Anzahl der zu beachtenden Kriterien wäre größer, das Erkennen der Abhängigkeiten zwischen den Kriterien sowie deren Gewichtung wären gefordert⁶⁾.

Eine andere Sichtweise auf Software bietet sich an: Gegenüber einer Datenstruktur, auf der Operationen angewendet werden, entsteht eine Welt aus interagierenden Objekten, die durch Ereignissteuerung nichtlineares Verhalten ermöglicht. Ein Objekt wird dabei typisiert als Klasse definiert. Einander ähnelnde Klassen werden in eine hierarchisierende Vererbungsbeziehung gestellt.

Vor diesem Paradigma könnte objektorientiertes Modellieren konzeptuell vernetztes Denken trainieren (vgl. Möller, 1999), denn die interagierenden Objekte sollen ein benutzbares Softwaresystem ergeben, so dass eine sinnvolle Vernetzung der Objekte hergestellt werden muss.

Möglicherweise erfordert also bereits die objektorientierte Quelltext-Organisation eine Art vernetztes Denken: Gegenüber imperativer Software, die wie eine Art Orchester funktioniert, dass zentral von einem Dirigenten geleitet wird, funktioniert ein objektorientiertes Programm eher wie ein Jazz-Ensemble aus individuellen Solisten, deren Zusammenarbeit die Gesamtfunktionalität ergibt⁷⁾. Die Organisation dieser Zusammenarbeit erfordert die Vernetzung der Objekte und damit vom Entwickler vernetztes Denken.

Die eigentliche Chance der Objektorientierung dürfte jedoch eher in solchen objektorientierten Vorgehensweisen der Softwareentwicklung liegen, die versuchen, die Kunden einzubeziehen und kooperativ (= Entwickler und Kunden) Ziele und Anforderungen an die zu entwickelnde Software zu bestimmen. Die Kunden werden in den Entwicklungsprozess einbezogen, um die unscharfen oder unklaren Anforderungen zu bestimmen.

Durch die Übertragung dieser Unklarheit in den Unterricht besteht die Möglichkeit zu einem kreativen Problemfindungsprozess. Lewis/Petrina/Hill vermuten, dass durch ein solches kreatives Element des 'Problem posing', welches nicht nur Problemfindung, sondern auch Umformulierung von Problemen einbezieht, der Unterricht lernwirksamer wird. Sie zitieren entsprechende Studien:

"These studies have shown that when technological problem solving was taught through design and was open-ended, thereby allowing for problem posing and exploration, student creativity was fostered, and this enriched student learning."

"well structured problems, which required convergent thinking and could be solved via algorithms and ill-structured problems, which required divergent thinking and solution via heuristics".

"context-bound and situation-specific models [...] where the student as learner plays an important and active role". (Lewis/Petrina/Hill, 1998)

1. Help Students Organize Their Knowledge
2. Build On What Students Already Know
3. Facilitate Information Processing
4. Facilitate "Deep Thinking"
5. Make Thinking Processes Explicit

Objektorientierte Ansätze der Modellierung bieten sich demnach dort an, wo Probleme 'offen' sind, wo unterschiedliche Lösungen und gegebenenfalls sogar unterschiedliche Beurteilungskriterien möglich sind. Das heißt, dieses Vorgehen bietet sich an, um die Gestaltung von Software zu thematisieren. Damit ändern sich Unterrichtsziele und -abläufe. Die Unterrichtsmethodik muss sich wegbewegen von der bewährten, am Wasserfallmodell orientierten Sequenzierung in entsprechende Unterrichtsphasen.

Zusammenfassung: Es ist nicht sicher, dass durch Programmieren transferierbare Problemlösefähigkeiten vermittelt werden. Die Softwaretechnik hat sich zudem weitgehend von Wasserfallmodellen verabschiedet. Im Informatikunterricht scheint das anwendungsorientierte Vorgehen dennoch bevorzugt zu werden. Der Wechsel zu objektorientierten Methoden kann jedoch andere Problemlösefähigkeiten fördern: Vernetztes Denken. Diese Vermutung gründet sich zu einem gewissen Grad auf die vernetzte objektorientierte Quelltextorganisation, stärker jedoch auf iterative Softwareentwicklungsmethoden, die Rolle von Softwarequalitätskriterien und den Gedanken, dass Software nicht ohne Berücksichtigung des Einsatzkontextes entwickelt werden kann. Unterrichtsmethodisch kann dieses Lernziel durch die Gelegenheit zu kreativen Problemfindungsprozessen und Prinzipien zum Training kognitiver Fähigkeiten unterstützt werden. Damit wird auch die Bindung des Unterrichtsablaufs an Wasserfallmodelle in Frage gestellt. Welche alternativen Modelle für den Unterrichtsablauf in Frage kommen, welche anderen Abläufe aus der Softwaretechnik Pate für Unterrichtsabläufe sein können, ist offen.

3. Modellieren und Softwaretechnik

Quibeldey-Cirkel behauptet: "Als 'schädlich' für den Entwurf komplexer Systeme gilt das algorithmische Denken an sich" (Quibeldey-Cirkel, 1995), denn "algorithmisches Denken schließt den Kunden vom Entwurfsprozess aus".

Ein Modell für die Entwicklung von Software zur Unterstützung von Geschäftsprozessen (vgl. Deiters, 1997) zeigt beispielhaft das mögliche Vorgehen: Zunächst erfolgt eine Analyse des Ist-Zustands, dessen Ergebnis ein Geschäftsprozess-Modell ist. Auf der Basis dieser Ist-Analyse wird ein Soll-Modell entwickelt, welches die Geschäftsprozesse zu optimieren versucht - und erst auf der Basis dieses Modells beginnt die 'eigentliche' Softwareentwicklung. Die Ergebnisse einer Phase, die einzelnen Modelle sind eher 'Modelle für' als 'Modelle von' (vgl. Schefe, 1999, S.132f): Sie dienen als Grundlage für den nächsten Schritt, sind Vorbild für die weitere Arbeit anstelle Abbild der Ausgangslage. Das trifft selbst auf die Ist-Analyse zu, denn in der Ist-Analyse werden diejenigen Aspekte betrachtet, von denen man annimmt, dass sie im weiteren Verlauf wichtig sind.

Aus Sicht der Softwaretechnik sind neben dem Abbilden der Kundenanforderungen allgemeine Softwarequalitätskriterien, Erfahrungswissen sowie die Eigenschaften der Werkzeuge zu berücksichtigen. Aus Sicht der Auftraggeber werden nicht (nur) vorhandene Tätigkeiten oder Arbeitsabläufe automatisiert, also 'in den Rechner' abgebildet. Es werden Infrastrukturen geschaffen, die in vorhandene Abläufe eingreifen und diese ändern. Dies gilt zwar nicht für jegliche Projekte, jedoch für die E-Type-Systems: Für Software, die in einen Kontext eingebettet wird (Dazu mehr im nächsten Abschnitt).

Die sich ergebende Frage, ob Software Realität abbildet oder Arbeitsplätze gestaltet, soll hier nicht in ausschließender Art diskutiert werden. Es geht um die Suche nach Sichtweisen auf Informatik und Softwaretechnik, die geeignet sind, die unterrichtlichen Ziele zu stützen. Ich vermute, dass eine Konzentration auf abbildende Aspekte den Softwareentwicklungsprozess zu sehr aus der Sicht der Softwareentwickler darstellt, so dass eine einschätzende Beurteilung auch im Sinne der Diskussion von Auswirkungen nicht so leicht in den Unterrichtsablauf zu integrieren ist.

Doch bevor das Thema der gesellschaftlichen Auswirkungen im nächsten Abschnitt diskutiert wird, zeichne ich im folgenden inner-informatische Argumente gegen eine rein abbildende Sichtweise nach. Man kann eine Art abbildende Sichtweise auf folgenden Aspekt richten: Demnach bildet Software "soziales Verhalten in Daten" (Keil-Slawik, 2000) ab. Passender ist jedoch die Ansicht Schefes, wonach die stattgefundene Tätigkeit als normierende Beschreibung von Handlungszusammenhängen (Schefe, 1999, S.122 und S.132) aufgefasst wird. Diese Ansicht berücksichtigt stärker den oben angesprochenen Unterschied von Ist-Modell und Soll-Modell. Man könnte den Begriff Abbilden auch auf das Abbilden des geplanten Systems beziehen. Anstelle von 'Abbilden des geplanten Systems' trifft m. E. der Begriff Gestaltung den Sachverhalt besser. Dazu Keil-Slawik: "Die der Software zugrunde liegenden Modelle menschlichen Verhaltens verändern dieses mehr oder weniger stark [...] Eine Rückbezüglichkeit entsteht" - diese Formulierung fokussiert eher auf ungewollte Nebenwirkungen, die aus dem Software-Einsatz entstehen können, negiert so aber gerade die Tatsache, dass verändernde Wirkungen gewollt sind und im Soll-Modell gestaltet werden⁸⁾.

Entwurfsmuster, wie von Gamma et. al. vorgestellt, haben gerade den Zweck, die Qualität eines Entwurfs (insbesondere bezüglich Flexibilisierung und Wartbarkeit) dadurch zu erhöhen, dass der Entwurf auf allgemein bekannte und bewährte Muster aufbaut und somit auf genaues Abbilden verzichtet. Sie stellen fest:

"Die strikt an der realen Welt orientierte Modellierung führt zu einem System, das vielleicht die heutige Realität wiedergibt, aber nicht unbedingt die von morgen. [...] Abstraktionen sind der Schlüssel dazu, einen Entwurf flexibel zu machen". (Gamma et. al., 1996, S.14)

Insgesamt muss man jedoch feststellen, dass die Sichtweise, informatisches Modellieren sei Abbilden von Realität, sehr oft anzutreffen ist. Wedekind u.a. vermuten dazu:

"Der Grund, warum dieser schlichte abbildungstheoretische Realismus trotz seiner offensichtlichen Schwächen so weit (nicht nur in den Naturwissenschaften) verbreitet ist, liegt wohl drin, daß der entscheidende Schritt, der dem Modellieren vorausgeht, als relativ unproblematisch gilt". (Wedekind, 1998, S.267)

"[I]hre Realität ist immer durch disziplinspezifische Versuchs- und Beobachtungskontexte gegeben, [...] so daß man bei dem Stichwort 'Realität' im Grunde doch nur an Beschreibungen disziplinrelevanter Sachverhalte denkt" (Wedekind, 1998, S.267).

In Bezug auf die Objektorientierung kommt hinzu, dass (im Vergleich mit dem strukturierten Ansatz) das Besondere gerade die Hinwendung zum Problembereich, zur Anwendungsdomäne, zum Realitätsausschnitt und in der Abkehr von den Besonderheiten der Maschine besteht. Darin liegt der Grund, weshalb die Übersetzungen zwischen Analyse, Design und Implementation(-s"-Modell") leichter fallen.

Verständlich, dass dieser Aspekt denn auch in den allermeisten Lehrbüchern zur Objektorientierung betont wird. Damit wird auf die Besonderheiten der Objektorientierung in Abgrenzung zum strukturierten Ansatz fokussiert. Im Grunde richten sich die entsprechenden Lehrbücher an einen bereits 'informatisch sozialisierten' Adressatenkreis. Für eine erste Begegnung mit Informatik jedoch gilt eine umgekehrte Richtung: Nicht von den bisher im Vordergrund stehenden maschinellen Aspekten soll der Blick auf das Modellieren des Anwendungsbereichs gelenkt werden, sondern gerade umgekehrt vom alltäglichen Erfahrungsbereich auf die Besonderheiten von Software⁹⁾. Da dürfte helfen, zur Vermittlung der Besonderheiten von Software darauf hinzuweisen, dass Modellieren auch Gestalten und nicht nur Abbilden ist.

Ein Beispiel für ein solches Vorgehen kann aus dem Ansatz von Hubwieser abgeleitet werden, der den informationswissenschaftlichen Ansatz für den Informatikunterricht und insbesondere die Modellierung auf dem Modellierungsbegriff des hier zitierten Artikels von Wedekind et. al. aufbaut (Hubwieser, 1999, S.24). Hubwieser benutzt diesen Ansatz, um im Informatikunterricht den Umgang mit Informationen speziell unter dem Aspekt der von der Informatik entwickelten Beschreibungstechniken, Notationen, Sprachen und Vorgehensweisen einzuführen und einzuüben. Er legt einen Schwerpunkt auf grafische Notationen, wie sie auch von der Objektorientierung bevorzugt werden.

Das bedeutet für den Informatikunterricht, auch und zunehmend, in Werkzeuge einzuführen. Noack/Schienmann behaupten sogar: "Objektorientierte Anwendungsentwicklung ist ohne umfassende Werkzeugunterstützung nicht denkbar" (S.177). Im Informatikunterricht werden Modellierungswerkzeuge benötigt, um das zu lösende Problem und später die Problemlösung zu repräsentieren - meist grafisch. Aus der grafischen Darstellung der Problemlösung wird dann die Implementation erzeugt ('Das Modell umgesetzt', wie manchmal etwas hemdsärmelig gesagt wird).

Hier lauert nun eine weitere Schwierigkeit für eine Konzeption des Informatikunterrichts, auch wenn diese hier nur benannt werden kann, ohne eine Lösung anzubieten: Für die Beschäftigung mit den Werkzeugen der Informatik im Unterricht kann man zwei Ebenen unterscheiden: Zum einen die Ebene, auf der Ergebnisse der Informatik genutzt werden, und zum anderen die Ebene der informatischen Fragestellungen:

"Es ist eine wesentliche Aufgabe der Informatik, Sprachkonzepte, Formalismen, Techniken und Werkzeuge zu entwickeln, die die Verständnisbildung so unterstützen, daß die Brücke zwischen der Welt der sinnfreien maschinellen Abläufe und ihrer sinnhaften Einbettung in menschliche Handlungszusammenhänge effektiv und verläßlich geschlagen werden kann und zwar sowohl auf der Seite der Herstellung als auch auf der Seite der Nutzung." (Keil-Slawik, 2000)

Zusammenfassung: Objektorientierte Verfahrensweisen versuchen problemnah zu arbeiten und den Kunden in den Entwurfsprozess einzubeziehen. Beispielsweise werden Begriffe des Problembereichs in der Software benutzt. Daher wird oft darauf hingewiesen, dass Teile der Wirklichkeit abgebildet werden, Modellieren also Abbilden bedeutet. Diese Sichtweise ist jedoch in der Informatik umstritten und kann dazu verleiten, Objektorientierung als weiteres Problemlöseparadigma in den anwendungsorientierten Ansatz einzuordnen. Damit wäre in Bezug auf die Thematisierung der Wechselwirkungen zwischen Informatik und Gesellschaft nichts gewonnen.

4. Modellieren und gesellschaftliche Auswirkungen

Erkennbar werden diese in der Phase Voruntersuchung, in der es um die Anforderungen des Kunden geht. Software wird entsprechend den Wünschen des Kunden gestaltet, hier liegen die Zwecke. An den Gestaltungsmethoden ist erkennbar: Software fügt sich in die Umgebung ein und ändert diese, so dass damit wiederum Änderungswünsche an die Software entstehen. Dementsprechend berücksichtigen die Methoden und die Qualitätskriterien, dass Software änderbar sein sollte.

Dies gilt nicht unbedingt für jede Software. Lehman unterscheidet zwischen verschiedenen Typen, von denen die 'E-Type-Systems' in diesem Rahmen interessieren: Software, über die man ohne Berücksichtigung des Einsatzkontextes keine Aussagen treffen kann. Es handelt sich um Software, die in soziale Kontexte eingebettet wird¹⁰⁾.

Aus zwei Gründen ist der Ansatz Lehmans in unserem Zusammenhang interessant: Zum einen stellt Lehman eine Taxonomie von Software-Typen auf, die nach dem Grad der Verzahnung der Software mit der Einsatzumgebung geordnet ist. Damit wird deutlich, dass Informatikunterricht einen bestimmten Typus von Software behandeln muss, soll eben diese Verzahnung vermittelt werden. Aufbauend auf dem Ansatz von Lehman kann man vermutlich Auswahlkriterien für entsprechende Unterrichtsbeispiele erarbeiten. Zum anderen gründet sich die Taxonomie auf langjährige empirische Studien, die hauptsächlich Software-Projekte untersuchen, die nach dem strukturierten Ansatz arbeiten. Damit wird deutlich, dass eben diese beobachtete Verzahnung von Software und Einsatzumgebung keineswegs, wie man eventuell vermuten könnte, auf Besonderheiten der Objektorientierung aufbaut. Man kann mit Lehman umgekehrt argumentieren, dass die Weiterentwicklung softwaretechnischer Methoden und Werkzeuge (auch) auf den sich aus dieser Verzahnung ergebenden Schwierigkeiten bei der Entwicklung von Software beruht.

Schefe spricht in diesem Zusammenhang sogar vom grundsätzlichen "Dilemma der Softwaretechnik [...], Unformalisierbares formal rekonstruieren zu müssen" (Schefe, 1999, S. 122). Zwischen den in der Anforderungsanalyse ermittelten unformalen Anforderungen und der formalen Spezifikation besteht eine nicht mathematisch fassbare Beziehung, die Schefe 'Sinnzuweisung' nennt, da es sich dabei um eine intentionale Bedeutungszuweisung handele. Die Aufgabe der Anforderungsanalyse sei daher, im Gegensatz zu einer naturwissenschaftlichen Abbildung eines Realitätsausschnitts, "bestimmte handlungsorientierte Konzeptualisierungen der Realität zu beschreiben. [...] Die Aufgabe ist, Intentionen zu verstehen, Sinn zu erfassen" (Hervorhebung im Orig., Schefe, 1999, S.123). Oder, um es mit Scott Ambler etwas handfester auszudrücken: Die Frage ist nicht mehr nur, wie man ein Software-System richtig konstruiert, sondern, wie man das richtige Software-System konstruiert¹¹⁾. Und diese Frage richtet sich an die Einsatzumgebung, wenn man so will, den gesellschaftlichen Kontext, den Handlungszusammenhang, in den die Software eingebettet ist.

"Die geringe Wiederverwendbarkeit von Software hat ihre Ursachen nicht primär in unzulänglichen Programmiertechniken, sondern in Erkenntnissituationen. Es geht nicht um die Erkennung allgemeingültiger Gesetze und ('wiederverwendbarer') Lösungen, sondern um individuellen Situationen mit wandelbaren Zwecken anpassbare Mittel" (Schefe, 1999, S.123).

Die Gestaltung von Software berücksichtigt also den geplanten Einsatzkontext. Zu diesem Kontext gehören nicht nur die materiellen Gegebenheiten wie Hard- und Software, sondern auch die sozialen Gegebenheiten wie Arbeitsabläufe und verschiedene Rollen der Benutzer. Im Modellierungsprozess wird die geplante Software sozusagen kontextualisiert. Und dieser Prozess geht von zwei Seiten aus: Die Modelle (Anforderung, Analyse, Design) werden an die Umgebung angepasst - und andererseits kann auch die Umgebung angepasst werden: Arbeitsabläufe und Rollen der Benutzer können sich ändern. Die Sichtweise, Software (oder verallgemeinert: Informatik) gestaltet Arbeitsplätze, ist daher zu präzisieren, um nicht in einen Technik-Determinismus zu verfallen. Zwischen Software und Umgebung gibt es Wechselwirkungen, vernetzte Abhängigkeiten und nicht einseitige Ursache-Wirkungs-Beziehungen. In diesem Zusammenhang sollte man jedoch auch nicht in das andere Extrem fallen, dazu Chandler's Schlussbemerkung zum Technik-Determinismus:

It is not very helpful to retreat to the extreme position that 'everything causes everything'. It is a great mistake to jump from the conclusion that the relationship between technology and society is not simple to the conclusion that the use of a particular technology in a specific context has no consequences at all. Any technological change which is great enough is likely to produce some social change. And some of these changes may be widespread and major. (http://www.aber.ac.uk/media/Documents/tecdet/tdet13.html)

"The immediate task is not, [...] to find a single alternate metaphor but to recognize that there are different ways of approaching the study of technology and society" (Pannabecker, 1991, S.8).

So kann Informatikunterricht Gestaltungsaufgaben im Sinne der Klafki'schen Schlüsselprobleme thematisieren, welche - verallgemeinert aus der exemplarischen Behandlung von kleineren Aufgaben im Unterricht - im Grunde die Gesellschaft als Ganzes betreffen¹²⁾.

Hier nun finden wir bildungstheoretische Anknüpfungspunkte, die den oben dargestellten Wechsel der Unterrichtsziele legitimieren können. Zum einen betrifft das den Bereich des Trainings kognitiver Fähigkeiten, aber auch - wie wir in der Zwischenzeit gesehen haben - den Bereich des Verhältnisses zwischen Informatik (als Stellvertreter für Technik allgemein) und Gesellschaft:

"Zur bildenden Auseinandersetzung gehört zentral die - an exemplarischen Beispielen zu erarbeitende Einsicht, daß und warum die Frage nach 'Lösungen' der großen Gegenwarts- und Zukunftsprobleme verschiedene Antworten ermöglicht [...]. Aus diesem Grundsachverhalt folgt allerdings keineswegs die umstandslose Anerkennung aller solcher Positionen als gleichberechtigt. Vielmehr stellt sich die Frage nach Kriterien, mit deren Hilfe die Geltung unterschiedlicher Lösungsvorschläge [...] beurteilt werden kann" (Klafki, 1996, S. 61).

"'vernetzendes Denken' oder 'Zusammenhangsdenken' [...]. Die Betonung dieser Fähigkeit ergibt sich zwingend aus neueren Zeit- und Gesellschaftsanalysen, die jene vielfältigen Verflechtungen herausgearbeitet haben, die heute, im Zeitalter hochentwickelter Technik und ihrer möglichen Folgen sowie der damit verbundenen politischen und ökonomischen Wirkungszusammenhänge - zugespitzt formuliert - 'alles mit allem' verknüpfen" (Klafki, 1996, S.63f).

"daß mit linearem bzw. vernetztem Denken konträre Weltbilder verknüpft sind. Lineares Denken kann auf ein technokratisches Weltbild zurückgeführt werden, demzufolge Teilaspekte der Wirklichkeit als isoliert nebeneinander stehend betrachtet werden und es für Wirklichkeitsphänomene eindeutige Erklärungen, für Probleme einfache Lösungen gibt."

In einer vernetzten Weltsicht dagegen wird die Welt

"als System vernetzter natürlicher Abläufe begriffen, bei dem die zwischen Teilbereichen der Realität bestehenden Beziehungen mindestens ebenso wichtig für ein Gesamtverständnis sind wie die Teilbereiche selbst.[...] [Zwischen den Teilbereichen gibt es] Wechselwirkungsprozesse, Rückkopplungen, direkte oder indirekte (Kausal-)Beziehungen" (Möller, 1999, S.28)¹³⁾.

Der zweite Aspekt unter dem wir uns wieder auf den Anfang des Artikels beziehen, betrifft die Anforderungen an die Softwaregestaltung: Ereignisgesteuerte, objektorientierte Software muss so gestaltet werden, dass sie mit den Handlungsabläufen des Einsatzbereichs vernetzt ist. Diese Kontextualisierung bedarf vernetzten Denkens. Darin liegen die Schwierigkeiten des Entwurfs und des Lernens. Andererseits liegt hier auch ein erstes Anwendungsfeld für ein im unterrichtlichen Softwareentwurf trainiertes vernetztes Denken: Die Frage nach den Auswirkungen des Einsatzes einer Software und der Qualität der vorliegenden Software muss Wechselwirkungen zwischen der Software und dem Kontext erfassen.

Die Fragen betreffen die Flexibilität der Software in den Bereichen, in denen Änderungen erforderlich, wünschbar sind. Und sie betreffen die Passung in den Kontext: Hier ist zu sehen, dass die beobachtete Qualität der Software auch mit der Art der Benutzung zusammenhängt. Ebenfalls ist zu berücksichtigen:

"[P]roblem solving and product design are not the same; the best result of a sound problem solving process is often something other than a new product" (Flowers, 1998).

Zusammenfassung: Die Berücksichtigung verschiedener Kriterien und das Erkennen der Vernetzung von Software und Einsatzumgebung erschließt einerseits exemplarisch die Thematik der Wechselwirkungen zwischen Informatik und Gesellschaft; auch im Sinne der Klafki'schen Schlüsselprobleme. Andererseits wird hier das vernetzende Denken gefordert und gefördert.

5. Fazit

Objektorientierung kann helfen, diese Öffnung zu ermöglichen. Die Fragestellungen könnten sich auf die E-Type-Systems beziehen, für welche die Lehman'schen "Laws of Software Evolution" gelten. Damit sind die Fragestellungen in einen Kontext eingebettet und mit Re-Engineering-Verfahren kann im Unterricht die Benutzung und Weiterentwicklung der Software angegangen werden. Das könnte 'deep thinking' fördern. Wichtig wird sein, die jeweilige Phase und Ebene (Analyse, Design, Weiterentwicklung, Beurteilen der Lösungsidee, Suchen nach Lösungsideen, etc.) in ihrer Stellung und zu Aufgabe verdeutlichen. Informatische Notationen wie UML und entsprechende Softwareentwicklungsumgebungen sind dabei als Werkzeuge angesprochen. Durch die Arbeit in Gruppen und das Abwägen verschiedener Lösungsideen werden nicht nur vernetzte Denkfähigkeiten, das Betrachten des Problems aus verschiedenen Sichtweisen, sondern auch verschiedene Beziehungen zwischen Kunde und Auftraggeber und darin angelegt zwischen Technik und Gesellschaft erfahrbar.

Wäre das ein ganz neuer Informatikunterricht? Nein, eigentlich nicht. Die Ziele des anwendungsorientierten Ansatzes sind auch vor dem Hintergrund der Objektorientierung nicht gegenstandslos geworden. Vielmehr handelt es sich um eine Akzentverschiebung, die von Impulsen aus der Objektorientierung profitieren kann, aber nicht von diesen Impulsen abhängt. Wäre dem so, dann gründete die Argumentation allein auf der Ebene der Ergebnisse der Wissenschaft Informatik, nicht jedoch auf der Ebene informatischer Forschungsfragen. Das Problem, wie man die im gegebenen Kontext richtige Software konstruiert (Ambler), wie man zwischen formaler Spezifikation und unformalen Anforderungen Sinn zuweisen kann (Schefe), bzw. wie man den Brückenschlag zwischen den beiden Welten hinbekommt (Keil-Slawik), ist die hier zentrale informatische Fragestellung.

Die Objektorientierung hat für diese Fragestellung keine Patentlösung gefunden, doch kann sie Impulse für Unterrichtsmethoden geben, um diese Frage im Rahmen des Informatikunterrichts gewinnbringend ansprechen zu können. Die "Dekonstruktion von Informatiksystemen als Unterrichtsmethode" (Hampel/Magenheim /Schulte, 1999) macht einen Schritt in diese Richtung.

6. Literatur

Arlt, Wolfgang (Hrsg.): Informatik als Schulfach. Didaktische Handreichungen für das Schulfach Informatik. Oldenbourg Verlag München Wien 1981.

Balzert, Helmut: Informatik 1. Vom Problem zum Programm. Hueber-Holzmann, 1987. 2. Aufl. (1. Aufl. 1976)

Baumann, Rüdeger: Didaktik der Informatik. Klett, 1996. (Zweite, vollständig neu bearbeitete Auflage)

Beck, K., Cunningham, W.: A Laboratory For Teaching Object-Oriented Thinking. SIGPLAN Notices, Volume 24, Number 10, October 1989
(http://c2.com/doc/oopsla89/paper.html, 9.5.01)

Chandler, Daniel: Technological or Media Determinism. 1995.
(http://www.aber.ac.uk/media/Documents/tecdet/tecdet.html, 9.5.01)

Deiters, Wolfgang: Prozeßmodelle als Grundlage für ein systematisches Management von Geschäftsprozessen. In: Informatik Forschung und Entwicklung 12, 1997. S. 52-60.
(http://link.springer.de/link/service/journals/00450/papers/7012002/70120052.pdf, 9.5.01)

Eberle, Franz: Didaktik der Informatik bzw. einer informations- und kommunikationstechnologischen Bildung auf der Sekundarstufe II. Aarau: Verlag für Berufspädagogik Sauerländer, 1996.

Flowers, Jim: Problem Solving in Technology Education: A Taoist Perspective. In: Journal of Technology Education, Vol 10, Nr.1 1998.
(http://scholar.lib.vt.edu/ejournals/JTE/v10n1/flowers.html, 9.5.01)

Forneck, Hermann J.: Bildung im informationstechnischen Zeitalter. Verlag Sauerländer, 1992.

Gamma, E., Helm, R., Johnson, R., Vilissides, J.: Entwurfsmuster. Elemente wiederverwendbarer Software. Addison-Wesley, 1996.

Hampel, T., Magenheim, J., Schulte, C.: Dekonstruktion von Informatiksystemen als Unterrichtsmethode. In: Schwill, A. (Hrsg.): Informatik und Schule. Springer, 1999. S.149-164.

Hubwieser, Peter: Modellieren in der Schulinformatik. In: Log In 19, Nr.1, 1999. S. 24-29.

Johnson, Scott D.: A Framework for Technology Education Curricula Which Emphasizes Intellectual Processes. In: Journal of Technology Education, 1992 Vol.3, Nr.2
(http://scholar.lib.vt.edu/ejournals/JTE/v3n2/pdf/johnson.pdf, 9.5.01)

Keil-Slawik, Reinhard: Zwischen Vision und Alltagspraxis: Anmerkungen zur Konstruktion und Nutzung typographischer Maschinen. In: G.G. Voß, W. Holly und K. Boehnke (Hg.): Neue Medien im Alltag: Begriffsbestimmungen eines interdisziplinären Forschungsfeldes. Opladen: Leske & Budrich, 2000. S. 199-220.

Klafki, Wolfgang: Grundzüge eines neuen Allgemeinbildungskonzepts. Im Zentrum: Epochaltypische Schlüsselprobleme. S. 43 - 81. In: Klafki, Wolfgang: Neue Studien zur Bildungstheorie und Didaktik. Weinheim, Beltz. 5. Auflage 1996 (1. Auflage 1985).

Koerber, B., Sack, L., Schulz-Zander, R.: Prinzipien des Informatikunterrichts S. 28-35. In: Arlt.

Krasemann, Hartmut: Welche Ausbildung brauchen Informatiker? In: Informatik-Spektrum 20 (1997) 6, 328-334
(http://link.springer.de/link/service/journals/00287/papers/7020006/70200328.pdf, 9.5.01)

Lehman, M. M.: Programs, Life Cycles, and Laws of Software Evolution. In: Proceedings of the IEEE, Vol. 68, No.9, September 1980.

Lewis, T., Petrina, S., Hill, A.: Problem Posing - Adding a creative increment to technological Problem solving. In: Journal of Industrial Technology Education, Vol 36, Nr.1 1998.
(http://scholar.lib.vt.edu/ejournals/JITE/v36n1/lewis.html, 9.5.01)

Möller, Dirk: Förderung vernetzten Denkens im Unterricht. Grundlagen und Umsetzung am Beispiel der Leittextmethode. Lit Verlag, Münster 1999

Noack, J.,Schienmann, B.: Objektorientierte Vorgehensmodelle im Vergleich. Informatik-Spektrum 22, 1999, S. 166-180.
(http://link.springer.de/link/service/journals/00287/papers/9022003/90220166.pdf, 9.5.01)

Pannabecker, J. R.: Technological impacts and determinism in technology education: Alternate metaphors from social reconstructivism. Journal of Technology Education, 1991,Vol 3, Nr.1
http://scholar.lib.vt.edu/ejournals/JTE/v3n1/pdf/pannabecker.pdf, 9.5.01)

Quibeldey-Cirkel, Klaus: Das Objekt-Paradigma in der Informatik. Teubner, Stuttgart, 1994

Quibeldey-Cirkel, Klaus: Entwurfsmuster: Design Patterns in der objektorientierten Softwaretechnik. Heidelberg u. a.: Springer-Verlag 1999.

Quibeldey-Cirkel, Klaus: Quo vadis Informatik? Aspekte einer objektorientierten Entwurfslehre. In: Objekt-Spektrum 2 (1995), Heft 1. S. 30-36.
(http://www.ti.et-inf.uni-siegen.de/staff/Quibeldey/Schriften/Quo-Vadis.pdf, 9.5.01)

Riedel, Dieter : Ansätze einer Didaktik des Informatikunterrichts. S.36-41. In: Arlt.

Schefe, Peter: Softwaretechnik und Erkenntnistheorie. In: Informatik Spektrum 22, 1999. S. 122-135
(http://link.springer.de/link/service/journals/00287/papers/9022002/90220122.pdf, 9.5.01)

Schubert, Sigrid: Fachdidaktische Fragen der Schulinformatik und (un)mögliche Antworten. In: Gorny, Peter (Hrsg.): Informatik und Schule 1991. Springer-Verlag 1991. S.27-33.

Wedekind, H., Görz, G., Kötter, R., Inhetveen, R.: Modellierung, Simulation,Visualisierung. In: Informatik-Spektrum 21, 1998. S.: 265-272.
(http://link.springer.de/link/service/journals/00287/papers/8021005/80210265.pdf, 9.5.01)

1) Der Artikel ist nach den Regeln der neuen Rechtschreibung verfasst, die Zitate sind jedoch originalgetreu übernommen, also oft in der alten Rechtschreibung gesetzt.

2) Weiter hinten (S.426f) schränkt Eberle allerdings die Bedeutung der Programmiersprache als nachrangig ein. Die Programmiersprache diene nur als "Vehikel zur Visualisierung algorithmischer Grundstrukturen".

3) Andere Sprachkonzepte, insbesondere deklarative, werden zwar eingefordert (etwa Schubert 1991), dienen aber eher als Ergänzung des imperativen Ansatzes (vgl. auch Baumann, 1996, S.239ff).

4) Dort heißt es: "..Zum anderen verläuft der objektorientierte Entwurfsprozess iterativ: Die zahlreichen Durchläufe verschmelzen zunehmend die Phasenübergänge."

5) Krasemann spricht in einem ähnlichen Zusammenhang von strukturellem Denken. Krasemann, 1997, S.331.

6) Die Anzahl der Kriterien, deren Vernetzung und Gewichtung sind Kriterien für komplexes Denken.

7) Die Metapher 'Orchester vs. Jazz-Ensemble' stammt aus: Bellin, David; Simone, Susan Suchmann: The CRC card book. Addison Wesley, 1997. S. 8f.

8) Wobei offen bleibt, ob nun der Softwareentwickler oder der Auftraggeber der Gestalter dieser verändernden Wirkungen ist. Möglicherweise führt der Softwareentwickler nur aus, möglicherweise findet eine Art 'partizipative Systemgestaltung' statt.

9) Zu Besonderheiten von Software siehe auch die zitierten Arbeiten Keil-Slawik und Lehman.

10) Daher das 'E-Type' - der Begriff 'embedded systems' bezeichnet Software, die in Maschinen eingebettet ist.

11) "Developers are good at building systems right. What we're not good at is building the right system." (Ambler, 1995, S.1)

12) Vgl. dazu Klafki, insbesondere den Abschnitt 5 (S.56-69): Bildung im Medium des Allgemeinen: Konzentration auf epochaltypische Schlüsselprobleme. Klafki selbst nennt die "Gefahren und die Möglichkeiten der neuen technischen Steuerungs-, Informations- und Kommunikationsmedien" als Beispiel (S.59).

13) Möller (S. 41) warnt: "Die gesellschaftlich-globalen Implikationen der Fähigkeit zum konzeptuellen vernetzten Denken könnten in Verbindung mit der Gegenüberstellung von vernetzten und linear-analytischem Denken [...] zu dem Schluß verleiten, daß es nur eine kategorisch richtige Denkform gibt, nämlich die des konzeptuell-vernetzten Denkens. Eine derart glorifizierende Sichtweise wird jedoch von DÖRNER überzeugend in Frage gestellt. DÖRNER fordert eine 'Flexibilität der Denkweisen', nicht eine Einseitigkeit, indem er betont: 'Manchmal ist das analytische Denken gefragt, das Denken im Detail und zu anderen Zeitpunkten braucht man die Synthese, das >Denken im großen Stil<, wo Details ganz bewußt übersehen werden müssen.' (1989a, S.49; vgl. auch 1989b, S.298f)"

Anhang: Zusammenstellung der Quellen

Zwar konnte bereits 1975/76 ein gewisser Konsens erreicht werden, daß im Informatikunterricht sowohl "algorithmisches Denken" als auch die "Auswirkungen der Datenverarbeitung auf die Gesellschaft" behandelt werden sollen.

Doch ergab sich zunächst die Tendenz, diese doppelte Zielsetzung,

• einerseits Befähigung, algorithmische Problemlösungen zu entwickeln und mit Computern realisieren zu können,
• andererseits Behandlung des Einsatzes von Computern in Produktion, Verwaltung und Wissenschaft sowie der gesellschaftlichen Auswirkungen davon,
• im Unterricht getrennt zu behandeln. Überspitzt formuliert, fiel der Informatikunterricht in einen Programmierkurs und in Gesellschaftskundeunterricht auseinander. Doch anwendungsorientierter Informatikunterricht sollte
• nicht additive Zusammenfassung des algorithmischen und des gesellschaftlichen Aspekts der Informatik, also Behandlung beider Seiten nebeneinander in einem Schulfach sein,
• sondern die Integration beider Seiten auf ihrer gemeinsamen Grundlage, dem Modellbildungsprozeß, leisten.

Die folgenden Überlegungen stellen eine Konkretisierung des Strukturmodells für das zweite Unterrichtsstadium dar. [...]

Der Problemlösungsprozeß kann in folgende Phasen gegliedert werden, die anschließend näher erläutert werden:

Problem- und Zielformulierung,
Problemanalyse und Modellbildung,
Algorithmierung,
Codierung und Implementation,
Benutzungsphase.

Zweite Phase: Problemanalyse und Modellbildung.
Der Modellbildungsprozeß wird aus didaktischen Gründen in zwei Schritte gegliedert:

• Einheit von Problemanalyse und Entwicklung eines deskriptiven Modell-Ansatzes, der alle für die Problemlösung relevanten Informationen darstellt (ein Abstraktions- und Erkenntnisprozeß, der durchgeführt wird unter Anwendung von Wissen);
• Bestimmung und Durchführung der operativen Modellanwendung zum Zweck des Problemlösens (Informationsverarbeitung). Obgleich hierbei (zumindest im Unterricht) noch der Mensch als Prozessor auftritt, wobei u.U. Hilfsmittel wie Taschenrechner und Würfel (zur Erzeugung von Zufallszahlen) eingesetzt werden können, wird bereits die Form der Informationsdarstellung und -verarbeitung mit Blick auf die spätere Rechnerbenutzung eingeführt.

Dritte und vierte Phase: Algorithmierung und Codierung.
Die Operationen, die mit dem Modell-Ansatz durchgeführt werden sollen, sind ein Informationsverarbeitungsprozeß; sie werden dann algorithmiert und in einer Weise transformiert, daß sie schließlich vom Rechner ausgeführt werden können. Ziel dieses Transformationsprozesses der Operationen, die mit dem Modell-Ansatz (der dabei als ihr 'Objekt' fungiert) durchgeführt werden, ist, daß der Prozessor Mensch durch den Prozessor 'Computer (Hardware/Software)' ersetzt wird (wobei neue Tätigkeiten für den Menschen, als Benutzer, entstehen): Automatisierung geistiger Arbeit. Hier zeigt sich, daß es in der Tat äußerst wichtig ist, den Problemlösungsprozeß und den Konstruktionsprozeß des Algorithmus deutlich zu unterscheiden.

Die Voraussetzung der Algorithmierung und Programmierung besteht also in folgendem:
Zunächst wird Wissen, das in allgemeiner Form gegeben ist, auf eine konkrete Situation angewendet. Resultat ist ein Modell-Ansatz, gewonnen durch Abstraktion, Komplexitätsreduzierung, Formalisierung. Dabei sind Analyse des Problems und Konstruktion des (deskriptiven) Modell-Ansatzes zwei Seiten eines einheitlichen Prozesses. Sein Ziel ist die Erzeugung eines Mittels, das die operative Anwendung von Wissen (nämlich als operative Anwendung des Modell-Ansatzes) ermöglicht.

Fünfte Phase: Installation und Benutzung.
Indem die operative Anwendung des Modell-Ansatzes algorithmiert und (vermittelt über Codierung und Implementation) automatisiert wird, wird ein Produkt (ein neues 'Arbeitsmittel') hergestellt. Es ermöglicht eine völlig neuartige Bewältigung der Problemsituation. Wie jedes neuartige Arbeitsmittel macht es neuartige Tätigkeiten und Qualifikationen seitens seiner Benutzer notwendig. Gewöhnlich sind deshalb in Verwaltung und Produktion einschneidende organisatorische und personelle Veränderungen notwendig, wenn das Arbeitsmittel 'Computer/Software' eingesetzt werden soll.

Erst die Anwendung und Benutzung des Programms ermöglicht die Rückinterpretation der gewonnen Daten auf den Realitäts- und Praxisbereich, in dem sich das Problem gestellt hat. Bei der Behandlung dieser fünften Phase des Problemlöseprozesses sind im Schulunterricht mehrere Aspekte zu unterscheiden:

• Prüfung, ob das im Unterricht erstellte Programm 'zuverlässig' ist und der Anforderungsdefinition entspricht;
• Bewertung der Ergebnisse unter dem Gesichtspunkt ihrer Aussagefähigkeit, also Diskussion des Abstraktionsprozesses, der zum Modell geführt hat, sowie der Leistungsfähigkeit, Grenzen und evtl. Gefahren der Problemlösung (Kritik und Verbesserung des Modells);
• Bestimmung der Anforderungen, die das Produkt an seine Benutzer stellt (sofern das im Unterricht erarbeitete Programm von anderen angewendet wird);
• Auswirkungen, die die Anwendung des Produktes für die Benutzer und weitere Betroffene hat (sofern das im Unterricht erarbeitete Programm auch tatsächlich eingesetzt wird);
• Behandlung gesellschaftlicher Auswirkungen professioneller Softwareherstellung und -anwendung innerhalb des Praxisbereichs, aus dem ein exemplarisches Detailproblem für die Bearbeitung im Unterricht ausgewählt wurde.

Balzert, Helmut: Informatik 1. Vom Problem zum Programm. Hueber-Holzmann, 1987. 2. Aufl. (1. Aufl. 1976): S.13

Im täglichen Leben steht man ständig vor Problemen, die man lösen muß. Die Probleme sind unterschiedlich; neben einfachen Problemen gibt es schwierige und komplizierte Probleme. Ebenso bestehen meist mehrere Möglichkeiten, eine Lösung zu erhalten, frei nach dem Motto: "Viele Wege führen zum Ziel". Kleine Probleme kann man schnell lösen, umfangreiche Probleme nehmen entweder längere Zeit in Anspruch, oder es werden Hilfsmittel benötigt - in Form technischer Mittel wie Rechenstab, Tabellen oder DVAn oder durch Befragen von Kollegen, Bekannten und Fachleuten oder durch Delegation des Problems an andere Personen. Die Lösung selbst kann von unterschiedlicher Qualität und Quantität sein; sie kann mehr oder weniger exakt und eindeutig sein; sie kann vollständig oder unvollständig, richtig oder falsch sein.

Anhand einiger Beispiele sollen Probleme, Wege zur Lösung und Lösungen bzw. Lösungsansätze gegenübergestellt werden. 

Balzert, Helmut: Informatik 1. Vom Problem zum Programm. Hueber-Holzmann, 1987. 2. Aufl. (1. Aufl. 1976): S.16f

Die Beispiele und Erläuterungen zeigen, daß das Lösen von Problemen ein umfangreiches Gebiet umfaßt. Ziel der Informatik ist es, Lösungsverfahren für bestimmte Probleme zu finden und so zu beschreiben, daß sie von DVAn abgearbeitet werden können. Dadurch ergeben sich bestimmte Einschränkungen sowohl hinsichtlich des Problemkreises als auch hinsichtlich der Lösungsbeschreibungen.
Es gibt Probleme, die prinzipiell nicht mit einer DVA gelöst werden können; es existieren aber auch Problembereiche, von denen man nicht sofort weiß, ob sich die Lösungen für die Abarbeitung durch DVAn eignen.
Grundsätzlich kann Ihnen eine DVA nicht das Auffinden von Lösungsverfahren abnehmen. Diese müssen Sie selbst finden; aber die Ausführung von gefundenen und geeignet dargestellten Lösungsverfahren kann von DVAn übernommen werden.
Im übertragenen Sinne bedeutet dies: Das Rezept für den Schwedischen Apfelkuchen müssen Sie selbst zusammenstellen; das Backen nach dem Rezept kann dann auch von jemand anderem übernommen werden, der die notwendigen Grundkenntnisse im Backen besitzt.
Das Sortierverfahren zum Sortieren einer Kartei müssen sie entwickeln, das Sortieren selbst kann durch eine DVA geschehen.
Wenn Sie die Verzinsung eines Kapitals mit Zins und Zinseszinsen ausrechnen wollen, dann nützt ihnen auch ein vorhandener Taschenrechner nichts, wenn sie die Zinseszinsformel nicht kennen.
Um beurteilen zu können, welche Probleme mit einem Computer bearbeitet werden können und welche Lösungsbeschreibungen eine DVA versteht bzw. welche Grundkenntnisse man bei einer DVA voraussetzen kann, sind einige Kenntnisse über die heutigen Fähigkeiten von DVAn nötig.
Allgemein kann man sagen, daß eine DVA nur nach vollständig vorgelegten Rezepten, Anweisungen, Beschreibungen oder Regeln Lösungen ausführen kann. Sie ist nicht in der Lage, zu denken oder zu überlegen und kann keine Rezepte oder Beschreibungen kreativ selbst entwickeln.
Die Fähigkeit von DVAn sollen jetzt hier nicht im Einzelnen aufgezählt, sondern schrittweise entwickelt werden, um das Verständnis zu erleichtern. Auf diese Art und Weise lernen Sie Eigenschaften von DVAn kennen, die erforderlich sind, um den Problemlösungsprozeß selbst zu unterstützen und eine optimale Verarbeitung von Problemlösungen zu ermöglichen. Die derzeitigen technischen Möglichkeiten lassen das nur bedingt zu.
Was das Verständnis von Lösungsverfahren anbelangt, befinden sich heutige DVAn vergleichsweise im Stadium eines Kindes im Kindergarten [...], beiden müssen Beschreibungen einer Lösung noch in sehr primitiver Form und in kleinen Schritten nahegebracht werden.
Zu den "Fähigkeiten" heutiger DVAn muß man hinzufügen, daß ein Computer nur Lösungen in einem strengen Formalismus akzeptiert und verbale Lösungsbeschreibungen nicht "versteht". Ein solcher Formalismus (d.h. "die formale Verpackung Ihrer Problemlösung") wird nach und nach entwickelt.
Als ein Leitfaden auf dem Weg vom Problem zur Lösung wird ein Schema zum Problemlösen benutzt, das einen gewissen Rahmen bzw. eine Hilfestellung beim Problemlösen bietet und für viele Problembereiche ein sinnvolles systematisches Vorgehen ermöglicht.
Systematisches Vorgehen bei der Lösung von Problemen ist auch im Privat- und Berufsbereich zu empfehlen; nach dem Motto: "Erst denken, dann handeln". DVAn reagieren grundsätzlich nur richtig, wenn dieses Prinzip gewahrt bleibt.
Ausgangspunkt jedes Problemlösungsprozesses ist die genaue Betrachtung der Problemstellung

Schubert, Sigrid: Fachdidaktische Fragen der Schulinformatik und (un)mögliche Antworten. In: Gorny, Peter (Hrsg.): Informatik und Schule 1991. Springer-Verlag 1991. S.27-33: S.27

Informatikunterricht soll kein Programmierkurs sein. Warum eigentlich nicht? Hier gehen Vorwürfe (berechtigte und unberechtigte) eine interessante Verbindung ein. Problemlösen (Modellieren und Strukturieren) unter Anwendung von Informatikprinzipien und -methoden gilt als erstrebenswert. Die Programmiersprache soll im Hintergrund (Mittel zum Zweck) bleiben. Das aber ist Programmierung (nicht zu verwechseln mit Codierung). Das Grundmodell der heute erfolgreichen Informatikausbildung beruht auf der Entwicklung guter (strukturierter) Lösungspläne (Abb. 1) und dem typischen Tätigkeitszyklus (Abb. 2). Programmierung fördert solche Techniken der geistigen Arbeit (Abb. 3), die mit heuristischen Methoden von Realitätsausschnitten zu geeigneten Modellierungen, d.h. zu Algorithmen (Strukturen für dynamische Prozesse und Daten) führen. Bildungsziel sollten in stärkerem Maße die heuristischen Methoden der Strukturierung sein und weniger die algorithmischen Ergebnisse (in Form von Software). Software als vergegenständlichte Intelligenz erlaubt das Modellieren und Kombinieren von logischen Grundbausteinen (Sequenz, Zyklus, Alternative) mit ungewöhnlichen Freiheitsgraden. Die Möglichkeit zur Entwicklung von kreativen und effektiven Problemlösungen ist ebenso gegeben wie die des schablonenhaften Nachvollziehens von Beispielen. Beim Lehrer liegt die Weichenstellung. Der persönlichkeitsbildende Wert der Informatik ist ihre spezifische Weise, Modellen aus Strukturen zu entwickeln und die experimentelle Manipulation mit diesen Modellen (unbewußtes Programmieren [Gorny 91]), die dem Lernenden seine Denkfehler aufzeigen.

Hubwieser, Peter: Modellieren in der Schulinformatik. In: Log In 19, Nr.1, 1999. S. 24-29: S.24f

Falls wir die Ansicht von S. Schubert teilen, stellen sich uns bei der Umsetzung dieser Ausrichtung in einen konkreten Lehrplan einige Probleme in den Weg: Welche Lerninhalte sollen wir in den Lehrplan schreiben, um

• sicherzustellen, daß im Unterricht wirklich genügend Gewicht auf die Modellierung und Strukturierung der behandelten Probleme gelegt wird?
• zu verhindern, daß sich die Behandlung der Modellierung in kurzen, abstrakten philosophischen Exkursen erschöpft?
• zu vermeiden, daß am Ende doch wieder spezielle Implementierungstechniken, spezifische Eigenheiten der verwendeten Programmiersprache in den Mittelpunkt des Unterrichtes rücken?

[-> Schubert]

Eberle, Franz: Didaktik der Informatik bzw. einer informations- und kommunikationstechnologischen Bildung auf der Sekundarstufe II. Aarau: Verlag für Berufspädagogik Sauerländer, 1996: S.329

Die Lösung algorithmischer Problemstellungen erfordert die Umsetzung von Problem und Problemlösung in formale Strukturen in zwei Schritten: Zunächst bietet sich die (relativ) programmunabhängige Umsetzung mittels der Strukturierungshilfsmittel wie Programmablaufplan, Struktogramm, Pseudocode oder auf einer höheren Ebene Datenflußplan an, und erst nachher die Implementierung in einen Programmcode. Erfahrungsgemäss ist es bereits die Umsetzung alltagssprachlich formulierter Problemstellungen in formale Beziehungen im ersten Schritt, also das eigentliche "Problemlösen" selbst, und weniger die Umsetzung in die Programmsyntax, die von Lernenden als besonders schwierig empfunden wird (vgl. z.B. Apel 1991a, 238). Dabei ist zu unterscheiden zwischen der reinen Übersetzung von Umgangssprachen in formale Schreibweise (das Niveau kann variieren) und dem antizipativen Verständnis der zeitlichen Abläufe (Prozeduren), während deren sich die Inhalte von Variablen ändern (z.B. Iterationen). Letzteres erfordert eine zusätzliche kognitive Leistung und unterscheidet auch informatisches Denken von grossen Teilen des mathematischen Denkens (zumindest bezüglich der Mathematik auf der Sekundarstufe II), das statische Beziehungen formalisiert (siehe auch Claus 1977).

Wo direkt Lösungen im Programmcode konstruiert werden, was in der Schulpraxis häufig zu sehen ist, sind diese Schwierigkeiten bei der Programmierung selbst zu beobachten. Neben den kognitiven Ansprüchen, die Formalisierung und Abstrahierung grundsätzlich mit sich bringen, sind auch Gründe bei der Vorgehensmethodik im Unterricht zu finden.

Baumann, Rüdeger: Didaktik der Informatik. Klett, 1996. (Zweite, vollständig neu bearbeitete Auflage): S.181f

Falsch verstandene Anwendungsorientierung (siehe c) unternimmt es, die Schüler über Handlungsfelder des praktischen Lebens (von der Heizölgewinnung über das Algenwachstum in Teichen bis zum bargeldlosen Zahlungsverkehr) zu informieren; der Unterricht wird damit zu einer Art Sach-, Sozial- und Umweltkunde. Richtig verstandene Anwendungsorientierung dagegen nimmt jene Situationen als Ausgangspunkt eines gedanklichen Prozesses, der von den wechselnden Anwendungsfällen abstrahiert, um die idealtypischen Strukturen herauszuarbeiten.

Das Konzept eines "anwendungsorientierten" Informatikunterrichts, wie er etwa in dem von W. Arlt herausgegebenem Sammelband (1981) dokumentiert ist, muß aus den genannten Gründen als bedenklich, weil didaktisch unreflektiert, kritisiert werden. Anwendungsorientierung darf erstens nicht mit dem ausschließlichen Arbeiten an Programmierprojekten (bei einseitiger Orientierung an den Methoden der konventionellen Softwaretechnik) verwechselt, zweitens nicht als Ersatz für die Fächer Arbeitslehre oder Sozialkunde mißverstanden werden und drittens nicht die Theorieflucht kultivieren (siehe Kapitel 21).

[-> Riedel in Arlt]

Forneck, Hermann J.: Bildung im informatonstechnischen Zeitalter. Verlag Sauerländer, 1992: S.229

Durch den Vergleich und die Analyse der Lernziele, der Unterrichtssituationen und der Unterrichtszeit konnte belegt werden, dass die didaktisch angestrebte Verschränkung von konstruktiver und gesellschaftlicher Perspektive in den untersuchten Unterrichtsreihen nicht befriedigend eingelöst wird. Zwar streuen auf der Stufe des impliziten Weltbezugs die im Unterricht bearbeiteten Bereiche gut, normative bzw. subjektive Handlungsdimensionen sind jedoch nahezu nicht vertreten. Im Vordergrund des anwendungsorientierten Unterrichts steht teleologisches Handeln.

Zudem wurde aufgewiesen, daß es in den untersuchten Unterrichtsreihen nicht gelingt, nach einer Algorithmisierung und Programmierung diese Tätigkeiten auf gesellschaftliche Fragen zurückzubeziehen. Das liegt auch an der Komplexität und Voraussetzungshaftigkeit der Algorithmisierung und Programmierung. Hier wird eine Inkonsequenz in der Begründung das Ansatzes deutlich. In der praktischen Implementation von Computern bzw. von Software wird ein Team von Spezialisten (Programmierern, Betriebswirtschaftlern, Medizinern, Psychologen, Juristen etc.) eingesetzt. Sie alle tragen im Prozess ihrer Zusammenarbeit zur Lösung eines vielschichtigen Problems bei. Dieser Prozess der Anwendung soll im anwendungsorientierten Ansatz in seiner Komplexität den Schülern vermittelt werden. Pragmatisch ergibt sich allerdings das Problem, wie das, was in der Realität eine Reihe von Spezialisten durch Teamarbeit zustande bringen, in einem Fach und von einem Lehrer verantwortlich geleistet werden soll.

Eberle, Franz: Didaktik der Informatik bzw. einer informations- und kommunikationstechnologischen Bildung auf der Sekundarstufe II. Aarau: Verlag für Berufspädagogik Sauerländer, 1996: S.212

Zusammenfassend konnte bis jetzt ein erfolgreicher genereller Transfer von informatischen Problemlösemethoden auf völlig andere inhaltliche Bereiche und damit die besondere Förderung genereller Problemlösefähigkeiten durch Informatik wie schon früher für andere Fächer (z.B. Latein und Mathematik) nicht überzeugend, hingegen ein spezifischer Transfer (wie in anderen Fächern auch) sehr wohl nachgewiesen werden. Beim Programmieren sind die Problemlöse- und Denkfähigkeiten an die Strukturen der Programmiersprache gebunden. Diese wiederum sind nicht auf die Problemlösestrukturen aller Probleme generalisierbar. Während wir an anderer Stelle (Eberle 1994a) und z.B. auch Frey (1989) vor allem das erste negative Ergebnis betont haben, gilt es auch, deswegen nicht einfach den formalen Bildungswert dieser Inhalte in Frage zu stellen, sondern in positiver Weise den gefundenen spezifischen Transfer zu betonen: Demnach ist Programmieren/Algorithmik geeignet,

a) spezifische Problemlösefähigkeiten für andere Bereiche herauszubilden und
b) wie in anderen Fächern auch einen aufgrund des jetzigen Forschungsstander nicht größeren, aber auch nicht kleineren Beitrag zur Entwicklung allgemeiner Problemlösefähigkeiten zu leisten.

Eberle, Franz: Didaktik der Informatik bzw. einer informations- und kommunikationstechnologischen Bildung auf der Sekundarstufe II. Aarau: Verlag für Berufspädagogik Sauerländer, 1996: S.331

Für die Entwicklung von Anwendungen haben die Vertreter eines anwendungsorientierten Ansatzes des Informatikunterrichts (siehe 4.1.3) konsequent die inhaltliche Struktur der informatischen Problemlösung als gleichzeitige Ablaufstruktur für den Unterricht postuliert ("didaktische Struktur"). Dies ist typisch für die Erarbeitung jenes prozeduralen Wissens, das eigentlich eine Methodik des Software-Engineering ist. Wenn in der ITB ebenfalls Transfer gefördert (siehe dazu unter 8.4) und in Richtung Expertise geführt werden soll, dürfte dieses Problemlöseverfahren tatsächlich dafür geeignet sein (siehe auch die Überlegungen von Dubs [1983, 1985] zu "Problemlösen und Transfer" in der Betriebswirtschaftslehre; siehe auch die Überlegungen zu den "fundamentalen Ideen" unter 5.5.2.3.2). -> Empfehlung E007

Eberle, Franz: Didaktik der Informatik bzw. einer informations- und kommunikationstechnologischen Bildung auf der Sekundarstufe II. Aarau: Verlag für Berufspädagogik Sauerländer, 1996: S.339

E007:

Anhand eines typischen Problemlöseverfahrens (z.B. Fünf-Phasen-Modell von Koerber/Peters [1993b, 21ff.]; siehe auch 4.1.3) der Informatik sollten - auch im Anfängerunterricht - immer wieder die typischen Elemente der (prozeduralen) Problemlösungsschritte bewusstgemacht (Metakognition) und auf ihrer Einhaltung sollte beharrt werden. Dazu gehören insbesondere auch die Entwicklung eines (Ablauf-)Modells vor der Umsetzung in einen Programmcode (mit den Hilfsmitteln Programmablaufplan, Struktogramm, Pseudocode, Datenflussplan). Daraus ergibt sich der Wechsel vom (induktiven) Bottom-Up-Vorgehen (Konfrontation mit einer gewissen Komplexität) am Anfang zum Top-Down-Vorgehen.

McCoy (1990, 46f.) empfiehlt in diesem Zusammenhang als mögliche Aktivitäten zur Metakognition:

• Probleme in der Klasse besprechen.
• Probleme gegenseitig in Kleingruppen beschreiben und Lernende anhalten, gegebene und gesuchte Grössen zu visualisieren.
• Anwendung der "KWL"-Methode zum besseren Verständnis: What we know, what we want to know and what we must learn (or teach the computer).

Eberle, Franz: Didaktik der Informatik bzw. einer informations- und kommunikationstechnologischen Bildung auf der Sekundarstufe II. Aarau: Verlag für Berufspädagogik Sauerländer, 1996: S.397f

Beispiel 1:
Eine Lehrkraft möchte die Vorgehensmethodik zur Lösung eines informatischen Problems behandeln (siehe 8.2.2.2.1). Die Strategie umfasst die folgenden Schritte: 1. Beschreiben und Analysieren des Problems. 2. Erarbeiten des Ziels und eines Modells des Problemlösungsablaufs. 3. Entwerfen des detaillierten Problemlösungsablaufs und Aufbereiten des Entwurfs hinsichtlich des Computereinsatzes. 4a. Codieren des Programlösungsablaufs als Quellprogramm und Testen oder 4b. Konfigurieren, Modifizieren, Anpassen eines Programmsystems und Testen oder 4c. Vorbereiten und Testen von Benutzungsfällen eines Anwendersystems bzw. Benutzerprogramms. 5. Einsetzen des informationstechnischen Systems und Beurteilen des Einsatzes (u.a. Koerber/Peters 1993b, 22). Wenn die Lernenden diese Vorgehensmethodik verstanden haben und die einzelnen Schritte erläutern können, verfügen sie über die Problemlösestrategie in deklarativer Form. Wenn die Lernenden immer wieder nach dieser Methodik vorgehen, um konkrete Aufgaben zu lösen, geht sie in prozedurale Form über. Bei der häufigen Anwendung dieser Problemlösemethodik wird sie je nach Kontext (z.B. einfaches oder komplexes Problem), Schwierigkeitsgrad des Problems, Vorwissen der Lernenden (z.B. über Befehle und Funktionen eines Anwenderprogramms), Motivations- und Interessenlage angepasst (z.B. Varianten der Stufe 4; Methoden zu Stufe 3) oder erweitert. Die Problemlösestrategie ist damit auch mit Anwendungsbedingungen verbunden (konditionales Wissen). Diese Überlegungen gelten für alle Strukturierungsmittel für prozedurale Abläufe gleichermassen (Struktogramm, Programmablaufplan). Dies zeigt auch, dass das reine Lernen von Programmbefehlen (deklaratives Wissen) die Anforderungen an vollständiges Wissen nicht erfüllt. 

Quibeldey-Cirkel, Klaus: Das Objekt-Paradigma in der Informatik. Teubner, Stuttgart, 1994: S.105f

Das also ist die klassische Zweiteilung zwischen Problem und Lösung, zwischen Was und Wie, zwischen Analyse und Design - "Klassisch" meint die funktionale Dekomposition. Die objektorientierte setzt neue Maßstäbe: Die Grenzen zwischen Analyse, Design und Implementierung verwischen immer mehr. Zum einen sind die relevanten Gegenstände (Objekte und deren Beziehungen untereinander) in allen Phasen gleich. Zum anderen verläuft der objektorientierte Entwurfsprozeß iterativ: Die zahlreichen Durchläufe verschmelzen zunehmend die Phasenübergänge. "The blurring of the traditional boundaries", umschreiben dies Tim KORSON und John MCGREGOR in ihrer Studie [Korson & McGregor, 1990, S.41], und Brian HENDERSON-SELLERS nennt es "a seamless transition" [Henderson-Sellers, 1992, S.320]. In der objektorientierten Analyse abstrahieren wir von den verbalen Wünschen des Kunden auf die konzeptionellen Einheiten, die mit den Dingen und Vorstellungen im betrachteten Weltausschnitt korrespondieren. Im fließenden Übergang der Analyse zum Design werden diese Abstraktionen in Klassen und Objekte umgewandelt. Struktur und Organisation bleiben dabei erhalten. Methode und formale Beschreibung sind gleich.

Noack, J.,Schienmann, B.: Objektorientierte Vorgehensmodelle im Vergleich. Informatik-Spektrum 22, 1999, S. 166-180.
(http://link.springer.de/link/service/journals/00287/papers/9022003/90220166.pdf, 9.5.01): S.170

Die Phasenabdeckung bestimmt den Umfang bzw. die Vollständigkeit, mit welcher die Phasen des objektorientierten Entwicklungsprozesses im Vorgehensmodell behandelt werden (Abb. 5). Obwohl Vorgehensmodelle die einzelnen Entwicklungsphasen i.a. weiter differenzieren, unterschiedliche zyklische und iterative Abhängigkeiten zwischen den Phasen festlegen oder diese zusammenfassen, lassen sich grob vier oder fünf Phasen unterscheiden. Für den neutralen Vergleich wurden die fünf Phasen Voruntersuchung, Systemanalyse, Entwurf, Erzeugung und Einführung gewählt. Häufig wird über die eigentliche Erstellung hinaus auch der gesamte Lebenszyklus von Software-Produkten inkl. rückgekoppelter Planungs-, Systemnutzungs- und Wartungsphasen beschrieben. In diesem Fall wird anstelle von Vorgehensmodell auch der Begriff Lebenszyklusmodell verwendet. Mit der Prozeßabdeckung (vgl. Abb. 5) wird analysiert, ob neben dem Entwicklungsprozeß, welcher die eigentliche Erstellung und Konstruktion der Software beschreibt, weitere ergänzende Prozesse in den Vorgehensmodellen unterschieden werden. Solche Prozesse fassen komplementäre, rollenspezifische Aufgabenbereiche, die kontinuierlich wahrzunehmen sind, als eigene Prozesse zusammen. Sie begleiten den Entwicklungsprozeß oder sind zumindest eng mit ihm verzahnt. Typischerweise lassen sich in praxiserprobten Vorgehensmodellen Prozesse für Test, Projektmanagement, Qualitätssicherung, Change- und Configuration-Management sowie Betrieb und Nutzung identifizieren, vgl. [24, S.17].

Quibeldey-Cirkel, Klaus: Entwurfsmuster: Design Patterns in der objektorientierten Softwaretechnik. Heidelberg u. a.: Springer-Verlag 1999: S.47

Dialektische Probleme: Man weiß, daß der Anfangszustand verändert werden muß, kennt aber den Zielzustand bloß vage oder gar nicht, allenfalls sind globale Zielkriterien bekannt, Komparative wie "besser" oder "effizienter". Die Lösung kann nur dialektisch erreicht werden, das heißt, der Entwurf wird fortwährend auf Widersprüche geprüft. Je offener das Problem im Hinblick auf den Zielzustand ist, desto öfter muß man versuchen, durch Erzeugen und Überprüfen von Alternativen die Zielkriterien zu präzisieren. So überwinden wir in der Softwaretechnik dialektische Barrieren im Dialog mit dem Kunden (exploratives Prototyping).

Möller, Dirk: Förderung vernetzten Denkens im Unterricht. Grundlagen und Umsetzung am Beispiel der Leittextmethode. Lit Verlag, Münster 1999: S.27f

Vernetztes Denken wird verstanden als ...

• - "... ein integrierendes, zusammenfügendes Denken, das auf einem breiteren Horizont ruht, von grösseren [>sic<; der Verfasser] Zusammenhängen ausgeht und viele Einflussfaktoren berücksichtigt, das weniger isolierend und zerlegend ist als das übliche Vorgehen. Ein Denken also, das mehr demjenigen des viele Dinge zu einem Gesamtbild zusammenfügenden Generalisten als dem analytischen Vorgehen des auf ein enges Fachgebiet beschränkten Spezialisten entspricht." (ULRICH/PROBST, 1990, S.11),
• eine Denkform, bei der "... die klassische Trennung von Ursache und Wirkung als globales Ordnungsprinzip aufgegeben wird" und bei der in "...Rückkopplungsschleifen bzw. vernetzten Strukturen, bei denen sich der Gegensatz zwischen Ursache und Wirkung in einem dynamischen Prozeß auflöst", gedacht wird. (OSSIMITZ, 1990, S.17);
• "Systemdenken zielt auf das Erkennen von Wechselwirkungen zwischen einer Vielzahl von Variablen. Es beinhaltet den Versuch, gegenüber der Analyse einzelner Faktoren die Synthese, d.h. die Einordnung von Einzelerscheinungen in einen Gesamtzusammenhang zu betonen." (BRETTSCHNEIDER, 1997, S.107);
• "Im Gegensatz zum bisherigen Ursache-Wirkungs-Denken ... ist das Systemdenken ausgerichtet auf die vernetzten Zusammenhänge, auf die grundlegenden Ordnungsprinzipien und Wechselwirkungen eines Systems" (KAISER, 1992, S.18).

Diese Polarität manifestiert sich auch darin, daß mit linearem bzw. vernetztem Denken konträre Weltbilder verknüpft sind (vgl. VESTER, 1991). Lineares Denken kann auf ein technokratisches Weltbild zurückgeführt werden, demzufolge Teilaspekte der Wirklichkeit als isoliert nebeneinander stehend betrachtet werden und es für Wirklichkeitsphänomene eindeutige Erklärungen, für Probleme einfache Lösungen, gibt. Nach dieser Sichtweise stellt sich die ganze Welt als übersichtlich dar. Vernetztes Denken hingegen steht stellvertretend für ein kybernetisches Weltbild (vgl. VESTER, 1991). Danach wird die Welt als System vernetzter natürlicher Abläufe begriffen, bei dem die zwischen Teilbereichen der Realität bestehenden Beziehungen mindestens ebenso wichtig für ein Gesamtverständnis sind wie die Teilbereiche selbst (vgl. VESTER, 1997). Die Welt besteht aus Teilsystemen (z.B. biologisch-ökologische, soziale, technologische, ökonomische Teilsysteme), innerhalb derer und zwischen denen es Wechselwirkungsprozesse, Rückkopplungen, direkte oder indirekte (Kausal-)Beziehungen gibt. Nichts steht isoliert für sich, alles ist eingebettet in ein vernetztes Ganzes und für Wirklichkeitsphänomene gibt es multikausale Erklärungen.

Lewis, T., Petrina, S., Hill, A.: Problem Posing - Adding a creative increment to technological Problem solving. In: Journal of Industrial Technology Education, Vol 36, Nr.1, 1998.
(http://scholar.lib.vt.edu/ejournals/JITE/v36n1/lewis.html, 9.5.01):

In this article, we have raised issues concerning the technological method, a generic problem solving method, suggesting that greater attention needs to be paid to problem posing, which we believe to lie at the creative end of the problem-solving continuum. Through the 1980s, technology educators' agenda had been to gain recognition of their subject area as a discipline, leading naturally to a concentration on technology education content. More recently there has been concentration on process, almost at the expense of content. At least one of the unsettled issues that arises at this point in our history is how does the process of problem solving materialize into technology education instruction and learning? We have questioned the efficacy of abstract, generic models in light of theory. Moving from generic models to context-bound and situation-specific models shifts the focus from curriculum to instruction and situation where the student as learner plays an important and active role in the equation. This shift is at the heart of this article. [...]

Perhaps the biggest indictment of problem solving as a method of our field, is that it has come to be viewed as being decontextualized and content-independent. For example, students may be asked to create load bearing structures without accompanying instruction in the related principles. That is not how technologists do their work. Technologists possess deep knowledge about the fields in which the practice. It is that knowledge which leads them to understand what they do not know, and what needs to be known. Architects understand architecture' structures, forces, aesthetics, etc. Tool designers understand material properties, and the mechanical forces operating at the interface of tool and work. They know the importance of providing for chip removal. Brain surgeons understand the anatomy of the human brain. Architects, brain surgeons, and tool designers, all technologists, come to insight and to new problems based upon puzzles encountered in their respective fields and their reflections upon them. It is thus foolhardy to conceive of an omnibus problem solving method that would work in all three of their respective domains. People come to problems in the content domains that preoccupy them.

Johnson, Scott D.: A Framework for Technology Education Curricula Which Emphasizes Intellectual Processes. In: Journal of Technology Education, 1992 Vol.3, Nr.2  (http://scholar.lib.vt.edu/ejournals/JTE/v3n2/pdf/johnson.pdf, 9.5.01): S.32f

Five broad, general principles emanate from the cognitive research literature which emphasize the development of intellectual processes (Thomas, Johnson, Cooke, DiCola, Jehng, & Kvistad, 1988). Those principles include making thinking and learning easier, building on what students already know, facilitating information processing, facilitating "deep thinking," and making thinking processes explicit. The following list identifies the instructional principles which are used to enhance intellectual processes. See Thomas et al. (1988) for more detailed descriptions of these principles.

Principle 1: Help Students Organize Their Knowledge. Research shows that experts are able to process large amounts of information when solving problems while novices often get "mentally bogged down" when confronted with lots of information. Instruction to improve intellectual processes must reduce the overload on student's working memory in order to enhance their ability to learn and solve problems. One way to reduce the "load" on working memory is through the use of an external memory. Use of an external memory enables problem solvers to keep track of where they are in the process of solving a problem, thereby easing the load on working memory (Larkin, 1988). External memories can be as simple as a bill of materials for a project or as complicated as a diagram of an electronic device or complex social system. Concept mapping is another form of external memory that helps students organize new information (Novak, Gowin, & Johansen, 1983).

Principle 2: Build on What Students Already Know. Learning theories state that the ability to gain and use new knowledge is greatly affected by the knowledge students bring to a learning situation. Students use their existing knowledge to interpret and understand what is presented each day. If a student does not come to class with the appropriate prerequisite knowledge, the student will have difficulty understanding and remembering the new content. In essence, prerequisite knowledge serves as an "anchor" to hold new information in memory. Without an appropriate anchor in the student's memory, the new information will simply "float away." As a result, in order for learning to take place, teachers must be sure that students have the prerequisite knowledge needed to learn. Two instructional techniques which address this principle are advanced organizers and analogies.

Principle 3: Facilitate Information Processing. Cognitive science research has consistently indicated that the way something is learned influences later use of that knowledge. New knowledge is "indexed" in the mind when it is learned so that it can be easily found and retrieved when needed (Phye & Andre, 1986; Reiser, 1986). Indexing of information in memory is analogous to using a card catalogue to "index" books in a library. With such an indexing system, specific books can be identified and located easily. Consequently, instruction must ensure that new information is indexed in ways that make it accessible at a later time. Strategies which facilitate information processing include supporting instruction through written, verbal, and graphic materials, providing outlines and organizing schemas for new content, and using real world scenarios for examples and activities which match student interests and experiences.

Principle 4: Facilitate "Deep Thinking". Any instructional method that causes students to consciously work harder at learning will help them achieve the instructional outcomes. Thinking hard increases the clarity of new information and aids understanding and recall. One of the best ways to get students to think is to have them elaborate on the material. In general, elaboration means that students think about the meaning of the material, identify relationships to other information, connect new information to what is already familiar, and generate expectations, predictions, and questions about the material. Techniques such as cooperative learning, peer tutoring, and paired problem solving can be used to get students to think.

Principle 5: Make Thinking Processes Explicit. There appears to be a growing consensus among researchers and teachers that it is beneficial to explicitly and directly teach students both the concept of metacognition and the use of metacognitive processes. When using direct instruction, teachers should explicitly teach strategies and skills by explaining not only what the strategy is, but also how, when, where, and why the strategy should be employed. Problem solving, decision making, planning, evaluating, and reflecting are all skills that can be reinforced in technology education classrooms. The direct teaching of these skills will improve student's overall performance by teaching them how to learn better rather than teaching them to perform isolated skills. In essence, the approach can be described by the old adage "Give people fish and they are fed for a day, but teach them to fish and they are fed for a lifetime." 

Quibeldey-Cirkel, Klaus: Quo vadis Informatik? Aspekte einer objektorientierten Entwurfslehre. In: Objekt-Spektrum 2 (1995), Heft 1. S. 30-36.
(http://www.ti.et-inf.uni-siegen.de/staff/Quibeldey/Schriften/Quo-Vadis.pdf, 9.5.01):

Die Softwarekrise der 60er Jahre war hausgemacht:

Edsger Dijkstra führte sie auf die damals beliebte, heute berüchtigte Sprunganweisung zurück - "Goto Statement Considered Harmful". Auch die Softwarekrise der 90er Jahre, im Informatik-Duden bereits als Krise der Wiederverwendung vermerkt, ist hausgemacht: Als "schädlich für den Entwurf komplexer Systeme gilt das algorithmische Denken an sich. Informatik ist heute weit mehr als die Lehre vom Programmieren. Die Wirthsche Gleichung "Programmieren = Entwerfen von Algorithmen und Datenstrukturen" verkürzt die universitären Lehrinhalte auf unzulässige Weise. Auch an den allgemeinbildenden Schulen wird die Umorientierung gefordert: "Algorithmen - wozu?", fragt Rüdeger Baumann in LOG IN, der Zeitschrift für Informatik-Didaktik [Bau94].

Woher stammen die Anforderungen an ein Programm? Vom Auftraggeber, dem Kunden. Dessen Sprachwelt ist aber nur bedingt die Sprachwelt des Programmierers. Der besitzt in der Regel das "linguistische Monopol" auf die Programmspezifikation. Die restriktive Wirkung der Sprache haben bereits Ludwig Wittgenstein und Benjamin Whorf betont: "Die Grenzen meiner Sprache bedeuten die Grenzen meiner Welt" [Wit73] und "Languages shape the way we think, and determine what we can think about" [Who74]. Die Fachsprache der Anforderungen in die Sprache der Informatik zu übersetzen, kommunikativ mit dem Kunden, das ist die eigentliche Ingenieurleistung. Der Entwurf wissenstechnischer Systeme braucht andere Wissensformen als Algorithmen, Programmablauf- und Datenflußpläne. Algorithmisches Denken schließt den Kunden vom Entwurfsprozeß aus!

Schefe, Peter: Softwaretechnik und Erkenntnistheorie. In: Informatik Spektrum 22, 1999. S. 122-135
(http://link.springer.de/link/service/journals/00287/papers/9022002/90220122.pdf, 9.5.01): S.132f

Neuere Entwicklungen der Softwaretechnik haben dem Dilemma der Formalisierung durch eine Flexibilisierung des Entwicklungsprozesses Rechnung getragen, u. a. durch so genanntes Prototyping. Der Begriff des Prototyps steht in engem Zusammenhang mit dem Begriff des Modells, mit diesem wiederum verknüpft sich die Vorstellung der objektivierenden Abbildung. Es bedarf also einer Bedeutungsexplikation. In ihrer terminologischen Untersuchung zur Softwaretechnik schlagen Hesse et al.[13] vor:

Modell: Idealisierte, vereinfachte, in gewisser Hinsicht ähnliche Darstellung eines Gegenstands, Systems oder sonstigen Weltausschnitts mit dem Ziel, daran bestimmte Eigenschaften des Vorbilds besser studieren zu können. (S. 98)

Dies ist aber eher eine die Softwaretechnik irreführende Bedeutung. Die Hauptquelle für Unklarheiten ist die grundlegende Doppeldeutigkeit des Begriffs: "Modell" als Vorbild und als Nachbild. Eine Konfundierung beider Bedeutungen findet man z.B. in der "Engineer's notion of model" bei B. Monahan und R. Shaw [22]:

This is a prototype construction, smaller in scale than the real thing, but useful for testing out ideas and checking specific calculations (e.g. the use of wind tunnel models in aerodynamic design). (S. 21/4, von mir hervorgehoben P. S.)

Die Unterscheidungen "explorativ", "experimentell", "evolutionär" [9] sind nur schwer voneinander abgrenzbare Akzentuierungen pragmatischer Faktoren, die letztlich alle demselben Zweck dienen: mehr Klarheit über das zu realisierende System zu gewinnen. Ein Prototyp ist in allen Fällen etwas schon Realisiertes, nicht eine bloße Beschreibung. Das ist das verwirrend Gemeinsame mit dem Flugzeug-Windkanal-Modell.

Eine andere Bedeutung wird sehr gut durch den Physiker H. Hertz [12] expliziert:

Wir machen uns unsere Scheinbilder oder Symbole der äußeren Gegenstände, und zwar machen wir sie von solcher Art, daß die denknotwendigen Folgen der Bilder stets wieder die Bilder seien von den naturnotwendigen Folgen der abgebildeten Gegenstände. [...] so können wir an ihnen, wie an Modellen, in kurzer Zeit die Folgen entwickeln [...]. (S. 112)

This is a mathematical theory in which the more fundamental aspects of the system are formulated and discussed. This is useful in making predictions and in drawing conclusions about the system by the use of logical inference. (S. 21/4)

Die Modellierung von Geschäftsvorgängen [...] führt zur Spezifikation einer abstrakten Repräsentation eines Anwendungssystems [...]. Solche Modelle sind Ausgangspunkt für die Prozeßausführung, die die Umsetzung von Prozeßmodellen in lauffähige Systeme zum Ziel hat. ([15], S.14)

Keil-Slawik, Reinhard: Zwischen Vision und Alltagspraxis: Anmerkungen zur Konstruktion und Nutzung typographischer Maschinen. In: G.G. Voß, W. Holly und K. Boehnke (Hg.): Neue Medien im Alltag: Begriffsbestimmungen eines interdisziplinären Forschungsfeldes. Opladen: Leske & Budrich, 2000. S. 199-220: S.203

Letzteres verweist auf einen abschließenden Gesichtspunkt, der mittlerweile auch in der Techniksoziologie zu einer grundsätzlichen Umorientierung geführt hat. Nicht mehr allein der Instrumentcharakter gemäß definierter Zweck-Mittel-Relationen steht im Vordergrund der Analyse, sondern die Durchdringung der Hervorbringung und Techniknutzung mit menschlichen Absichten, Sinnzuschreibungen und Bewertungen (vgl. Dollhausen & Hörning, 1996). Dies ist auch nicht verwunderlich, denn ein Datum kann zugleich ein Steuerimpuls für einen technischen Prozeß sein, einen Verwaltungsakt verkörpern, menschliches Verhalten abbilden, ein Meßwert sein oder Teil eines literarischen Textes. Informationssysteme, Verwaltungssoftware, Produktionsplanungssysteme wie auch jedes Betriebssystem bilden soziales Verhalten in Daten ab. Diese unterliegen hinsichtlich ihrer Bedeutung sozialen Konventionen. Wo immer diese Konventionen in Form von Daten ein Teil der maschinellen Wirklichkeit werden, beeinflussen sie das Verhalten der Menschen. Die der Software zugrunde liegenden Modelle menschlichen Verhaltens verändern dieses mehr oder weniger stark, wenn die Konsequenzen des Softwareeinsatzes im Anwendungsfeld sichtbar werden. Eine Rückbezüglichkeit entsteht, wie sie in diesem Ausmaß und dieser engen Verflechtung bei keiner anderen Technik anzutreffen ist. Das Recht auf informationelle Selbstbestimmung beispielsweise ist ein verfassungsmäßig verbrieftes Grundrecht, das gemäß höchstrichterlicher Entscheidung als Antwort auf die technischen Möglichkeiten der Verarbeitung personenbezogener Daten zugestanden werden mußte, um die Persönlichkeitsrechte der Bürger zu schützen.

Schefe, Peter: Softwaretechnik und Erkenntnistheorie. In: Informatik Spektrum 22, 1999. S. 122-135
(http://link.springer.de/link/service/journals/00287/papers/9022002/90220122.pdf, 9.5.01): S.122

Die Erkenntnissituation des Softwaretechnikers ist nicht, wie allgemein angenommen, mit der eines Naturwissenschaftlers vergleichbar. Ausgehend von der ontologischen Doppelnatur von Software werden erkenntnistheoretische Basisprobleme der Softwaretechnik (insbesondere der Anforderungsanalyse und der Spezifikation) besprochen, Gegenstands- und Zeichenkonstitution sowie Begriffsbildung und Definierbarkeit. Das Dilemma der Softwaretechnik ist, Unformalisierbares formal rekonstruieren zu müssen. Dies zeigen sowohl der allgemein unklare Modellbegriff, wie auch die Ansprüche der 'objektorientierten Modellierung'. Es gilt, das Paradigma der abbildenden Modellierung durch ein Paradigma der normierenden Beschreibung abzulösen. Eine Umorientierung erfordert eine konsistente, erkenntnistheoretisch valide Terminologie.

Gamma, E., Helm, R., Johnson, R., Vilissides, J.: Entwurfsmuster. Elemente wiederverwendbarer Software. Addison-Wesley, 1996: S.14f

Objektorientierte Programme bestehen aus Objekten. Ein Objekt faßt sowohl Daten als auch Prozeduren zusammen, die auf diesen Daten arbeiten. Die Prozeduren heißen üblicherweise Methoden oder Operationen. Ein Objekt führt eine Operation aus, wenn es eine Anfrage (oder eine Nachricht) von einem Klienten erhält.

Anfragen sind der einzige Weg, ein Objekt dazu zu bringen, eine Operation auszuführen. Operationen sind der einzige Weg, um die internen Daten eines Objekts zu ändern. Man sagt aufgrund dieser Einschränkungen, daß der interne Zustand des Objekts gekapselt ist. Es kann nicht direkt auf ihn zugegriffen werden; seine Repräsentation ist außerhalb des Objekts nicht sichtbar.

Das Schwierige am objektorientierten Entwurf ist die Zerlegung eines Systems in Objekte. Hierbei spielen viele Faktoren eine Rolle: Kapselung, Granularität, Abhängigkeit, Flexibilität, Laufzeitverhalten, Evolution, Wiederverwendbarkeit und so weiter. Sie alle beeinflussen in einander oft widersprechender Weise die Zerlegung.

Objektorientierte Entwurfsmethoden bieten hierzu viele verschiedene Ansätze. Sie können eine Problemstellung aufschreiben, die Substantive und Verben unterstreichen und ihnen entsprechende Klassen und Operationen konstruieren. Oder Sie können sich auf die Interaktionen und die Zuständigkeiten in Ihrem System konzentrieren. Oder Sie können die reale Welt modellieren und bei der Analyse gefundene Objekte in den Entwurf überführen. Es wird immer strittig sein, welches der jeweils beste Ansatz ist.

Viele Objekte eines Entwurfs entstammen dem Analysemodell. Allerdings führen objektorientierte Entwürfe oft zu Klassen, für die es keine Entsprechung in der realen Welt gibt. Darunter sind Klassen geringen Abstraktionsgrades zu finden, wie zum Beispiel Arrays. Andere Klassen besitzen einen höheren Abstraktionsgrad. Beispielsweise führt das Kompositionsmuster (213) eine Abstraktion ein, mit der Objekte einheitlich behandelt werden können. Es kennt keine physische Entsprechung. Die strikt an der realen Welt orientierte Modellierung führt zu einem System, das vielleicht die heutige Realität wiedergibt, nicht aber unbedingt die von morgen. Diese sich während eines Entwurfs ergebenden Abstraktionen sind der Schlüssel dazu, einen Entwurf flexibel zu machen. Entwurfsmuster helfen Ihnen, die nicht so offensichtlichen Abstraktionen und die sie erfassenden Objekte zu identifizieren. Beispielsweise erscheinen Objekte, die einen Prozeß oder einen Algorithmus repräsentieren, nicht in der Natur, sind aber trotzdem ein essentieller Teil flexibler Entwürfe. Das Strategiemuster (333) beschreibt, wie man austauschbare Familien von Algorithmen implementiert. Das Zustandsmuster (357) repräsentiert jeden Zustand einer Entität als Objekt. Man findet diese Objekte selten während der Analyse oder während der frühen Entwurfsaktivitäten; sie werden erst später entdeckt, wenn man damit beschäftigt ist, einen Entwurf flexibler und wiederverwendbar zu machen. 

Wedekind, H., Görz, G., Kötter, R., Inhetveen, R.: Modellierung, Simulation, Visualisierung. In: Informatik-Spektrum 21, 1998. S.: 265-272.
(http://link.springer.de/link/service/journals/00287/papers/8021005/80210265.pdf, 9.5.01): S.267

Als exemplarisch für diese Art des Modellverständnisses können die Ausführungen von Kowalk (1996) gelten, auf die wir deshalb etwas näher eingehen wollen. Kowalk (S.30) definiert "Modell" als "eine Zusammenfassung von Merkmalen eines realen (oder empirischen) künstlichen Systems sowie eine Festlegung der Beziehungen zwischen diesen Merkmalen; da ein Modell niemals alle Merkmale eines Systems umfassen kann, ist ein Modell eine Abstraktion eines realen Systems". Als "System" gilt für ihn "eine räumlich abgeschlossene, logisch zusammengehörende und zeitlich begrenzte Einheit, die voneinander abhängende Komponenten umfaßt" (S.27), erläuternd fügt er hinzu: "Systeme sind im allgemeinen komplexe Gebilde, deren vollständige Beschreibung schwierig oder unmöglich ist. Die Wissenschaften zeichnen sich gerade dadurch aus, daß sie Modelle entwickeln, in denen die untersuchten Systeme auf relevante Merkmale reduziert werden; die Diskussion über diese Systeme geschieht somit in diesem Merkmalsraum, also in dem Modell; Ergebnisse solcher Untersuchungen werden dann aus dem Modell wieder auf das reale System projiziert" (S.28). Unter "Simulation" versteht er schließlich die numerisch approximative Behandlung von Modellen, deren mathematische Darstellung nicht auf geschlossene Lösungen führt (S.31, 35); wir werden darauf später noch zurückkommen.

Diese Vorschläge von Kowalk sind nun in mehrerer Hinsicht problematisch. So muß uns, um von einem Modell reden zu können, vorher "etwas" als System gegeben sein. Fatal ist dabei, daß wir nach Kowalk eigentlich nichts als System erkennen können, da wir prinzipiell nicht in der Lage sind zu beurteilen, wann die Abgeschlossenheitsbedingung erfüllt ist. Auch die geforderte "logische Zusammengehörigkeit" offenbart sich nicht unmittelbar. Ein räumlicher Zusammenhang mag sich noch durch bloßen Augenschein wahrnehmen lassen, eine logische Beziehung dagegen nicht; diese läßt sich nur zwischen Begriffen und Sätzen, nie aber zwischen den durch die Begriffe und Sätze bezeichneten bzw. dargestellten Gegenständen und Sachverhalten herstellen. Was immer wir wahrnehmen, es ist kein System, sondern bestenfalls etwas, was sich als System beschreiben läßt - und dies ist ein gewaltiger Unterschied.

Deshalb stellt die Forderung, mit einem sprachlichen Modell ein Stück "der Wirklichkeit" zu vereinfachen, auch einen sog. "Kategorienfehler" dar: Mit sprachlichen Mitteln lassen sich grundsätzlich nur sprachliche Darstellungen vereinfachen.

Der Grund, warum dieser schlichte abbildungstheoretische Realismus trotz seiner offensichtlichen Schwächen so weit (nicht nur in den Naturwissenschaften!) verbreitet ist, liegt wohl darin, daß der entscheidende Schritt, der dem Modellieren vorausgeht, als relativ unproblematisch gilt und die meisten Wissenschaftler deshalb meinen, auf eine nähere Reflexion verzichten zu können. Dabei ist offensichtlich, daß Naturwissenschaftler es nie mit einer "Realität" zu tun haben, der man sich unvermittelt und unbefangen stellen könnte; ihre Realität ist immer durch disziplinspezifische Versuchs- und Beobachtungskontexte gegeben, in die man aber gewissermaßen von Studienbeginn an hinein sozialisiert wird, so daß man bei dem Stichwort "Realität" im Grunde genommen doch nur an Beschreibungen disziplinrelevanter Sachverhalte denkt. D.h. jede Erstellung eines Modells baut in den Naturwissenschaften auf einer umfänglichen Beschreibung des zu modellierenden Sachverhalts auf: Wer einen physikalischen Sachverhalt modelliert, greift auf Beschreibungen eines Versuchsaufbaus zurück, auf Meßprotokolle und daraus verfertigte Datensätze; wer Verkehrsabläufe modelliert, hat Straßenkarten vorliegen sowie Ergebnisse von Verkehrszählungen und -befragungen usw. Derartige Beschreibungen sind es genau genommen, die zu Modellen umgeschrieben, vereinfacht und abstrakt gefaßt werden.

Die Frage, was hier "umfängliche Beschreibung" heißen soll, führt uns zu einer weiteren Schwäche des naiv-realistischen Ansatzes. Bei Kowalk sieht es so aus, als müsse der Mensch abstrahieren und vereinfachen, weil die Welt "eigentlich" für sein Auffassungsvermögen zu kompliziert und komplex ist. Wenn wir uns Modelle in den Wissenschaften aber näher ansehen, dann können wir feststellen, daß sie nicht aus dieser existenziellen Not des Menschen geboren werden, sondern sich bestimmten, theorieinduzierten Fragen verdanken. So bestimmt sich denn auch das Maß für die Umfänglichkeit der Ausgangsbeschreibung, die einem Modell zugrunde liegt, nach dem Forschungsprogramm derjenigen Theorie, in deren Kontext das Modell erstellt werden soll. Dieses Forschungsprogramm liefert die Beschreibungssprache, die Beschreibungsstandards und die Erklärungsschemata, in seinem Rahmen werden nicht zuletzt auch die Erwartungen formuliert, die der Arbeit an einem Modell vorausgehen. Modellieren ist also eine Tätigkeit, die nach zwei Seiten hin ausgerichtet ist: zum einen muß sich ein (gutes) Modell den empirischen Beschreibungen fügen, zum anderen den theoretischen Vorgaben. Wir wollen dieses Verhältnis noch ein wenig näher untersuchen.

Hubwieser, Peter: Modellieren in der Schulinformatik. In: Log In 19, Nr.1, 1999. S. 24-29: S.24

In der Informatikdidaktik findet sich seit langem ein tragfähiger Konsens über die große Bedeutung des Modellierungsvorganges für einen allgemeinbildenden Informatikunterricht (siehe etwa Koerber/Peters, 1988; Brauer/Brauer, 1989; Schulz-Zander u.a., 1993; Hubwieser/Broy, 1996). Der Begriff Modell ist dabei innerhalb der verschiedenen didaktischen Ansätze des Informatikunterrichtes sehr unterschiedlich belegt. Darunter versteht man unter anderem:

• (irgend-)eine abstrahierte Beschreibung von Systemen,
• eine Beschreibung eines Problems mit Hilfe von speziellen Modellierungsprogrammen (z.B. Stella),
• (irgend-)eine grafische Darstellung eines Systems,
• eine mathematische Gleichung für einen Zusammenhang,

Noack, J.,Schienmann, B.: Objektorientierte Vorgehensmodelle im Vergleich. Informatik-Spektrum 22, 1999, S. 166-180.
(http://link.springer.de/link/service/journals/00287/papers/9022003/90220166.pdf, 9.5.01): S.177

Objektorientierte Anwendungsentwicklung ist ohne umfassende Werkzeugunterstützung nicht denkbar. Dabei geht es zum einen um die Frage, mit welchen Werkzeugen die vom Vorgehensmodell geforderten Ergebnisse am besten erstellt werden und zum anderen um die Frage, in welcher Form das Vorgehensmodell seinen Anwendern, den Projektleitern und Software-Entwicklern, präsentiert wird.

Für den ersten Aspekt können in Anlehnung an das verbreitete NIST/ECMA-Referenzmodell [22] verschiedene horizontale und vertikale Werkzeuge beschrieben werden. Horizontale Werkzeuge zur Modellierung, Programmierung oder Gestaltung von Benutzungsoberflächen unterstützen nur bestimmte Phasen der Software-Entwicklung. Vertikale Werkzeuge, etwa für die Ablage von Entwicklungsinformationen, das Projektmanagement, die Konfiguration, Qualitätssicherung oder die Wiederverwendung werden phasenübergreifend eingesetzt.

In Hinblick auf Aussagen zu Entwicklungswerkzeugen lassen sich die betrachteten Modelle in verschiedene Rubriken einteilen. RUP und Perspective werden jeweils von Software-Werkzeugherstellern angeboten. Dementsprechend finden sich innerhalb dieser Vorgehensmodelle an vielen Stellen Hinweise, wie bestimmte Aktivitäten und Ergebnisse am besten mit den herstellereigenen Entwicklungswerkzeugen umgesetzt werden können.

Alle anderen Ansätze haben sich nicht auf bestimmte Entwicklungswerkzeuge festgelegt und sind daher als neutral einzustufen. V-Modell und AE-Modell enthalten Referenzarchitekturen, welche Werkzeugkategorien und funktionale Anforderungskriterien definieren, mit deren Hilfe eine Werkzeugauswahl vorgenommen werden kann. OPEN und WSSDM nennen einige für die Umsetzung in Frage kommende CASE-Werkzeuge exemplarisch.

Die Erfahrungen zeigen, daß die Akzeptanz eines Vorgehensmodells durch eine angemessene Werkzeugunterstützung wesentlich verbessert werden kann [44]. Gegenüber einer rein textuellen Darstellung besteht hierdurch die Möglichkeit, die Informationen Zielgruppengerecht zu filtern und damit letztlich die Komplexität für die am Entwicklungsprozeß beteiligten Rollen zu reduzieren. Auch der Prozeß der Anpassung des Vorgehensmodells und der Projektplanung kann entscheidend vereinfacht werden. Insbesondere die Präsentation als Hypertext und die Aufbereitung mit Hilfe von HTML und JAVA für einen Browser bieten erweiterte Navigationsmöglichkeiten. Als Einstiegspunkte kommen neben den Phasen und Aktivitäten auch Ergebnisse und Rollen in Frage.

Keil-Slawik, Reinhard: Zwischen Vision und Alltagspraxis: Anmerkungen zur Konstruktion und Nutzung typographischer Maschinen. In: G.G. Voß, W. Holly und K. Boehnke (Hg.): Neue Medien im Alltag: Begriffsbestimmungen eines interdisziplinären Forschungsfeldes. Opladen: Leske & Budrich, 2000. S. 199-220: S.204f

Da jedoch heutige Informatiksysteme nur konstruierbar und in ihrer jeweiligen Funktion verstehbar sind, weil sie mit Zeichen und Wörtern konstruiert werden, die - im Gegensatz zu unanschaulichen Schaltern und Leitungen oder einer rein formalen minimalen Symbolik - zugleich einen Sinnbezug zur Erfahrungswelt der Nutzer und Entwickler herstellen, müssen die Zeichenarrangements und symbolischen Ausdrucksmittel nicht nur zur Verarbeitung durch einen maschinellen Transformationsprozeß geeignet sein, sondern zugleich die Wahrnehmung und Verständnisbildung derjenigen unterstützen, die mit Hilfe dieser symbolischen Artefakte handeln. Software ist insofern ein semiotisches Artefakt, das von einer typographischen Maschine verarbeitet werden kann; das Verständnis erschließt sich nur unter Bezug auf den Handlungskontext ihrer Herstellung und Nutzung (vgl. Kay, 1984; Keil-Slawik, 1992).

Dies ist die spezifische Qualität, denen heutige Informatiksysteme ihre Existenz verdanken. Es ist eine wesentliche Aufgabe der Informatik, Sprachkonzepte, Formalismen, Techniken und Werkzeuge zu entwickeln, die die Verständnisbildung so unterstützen, daß die Brücke zwischen der Welt der sinnfreien maschinellen Abläufe und ihrer sinnhaften Einbettung in menschliche Handlungszusammenhänge effektiv und verläßlich geschlagen werden kann und zwar sowohl auf der Seite der Herstellung als auch auf der Seite der Nutzung. Diese Brücke wird weder von der Elektrotechnik noch von der Mathematik gebaut, sie verbindet Schaltungstechnik und Formalismen mit konstruktivem Verständnis, sie ist keine rein typographische, sondern eine semiotische, sie ist keine rein prinzipielle, sondern eine höchst pragmatische, denn der tatsächliche Nutzen dieser Konzepte erweist sich erst im Alltag der Informatiker. Neben der Ermittlung der technischen Funktion (Ein-/Ausgabeverhalten) ist es somit notwendig, die mediale Funktion typographischer Artefakte und Maschinen zu bestimmen. 

Schefe, Peter: Softwaretechnik und Erkenntnistheorie. In: Informatik Spektrum 22, 1999. S. 122-135
(http://link.springer.de/link/service/journals/00287/papers/9022002/90220122.pdf, 9.5.01): S.123

Dies Softwaretechnische Dreieck zeigt die wesentliche Problemkonstellation der Softwaretechnik. Die Ecken stehen für konzeptuelle oder symbolische Entitäten: Konzepte, Beschreibungen, mathematische Strukturen, die Kanten für ihre Beziehungen: Beschreibung/Interpretation, Spezifikation/Erfüllung, Rekonstruktion/-Sinnzuweisung. Sofern die benutzte Sprache eine formale ist, können die beschreibenden Ausdrücke durch mathematische Strukturen interpretiert - und schließlich auf einer mathematischen Maschine realisiert - werden. Gesucht sind solche Realisierungen, die die Spezifikation erfüllen. Die Erfüllungsrelation ist wiederum einer mathematischen Überprüfung (Verifikation) zugänglich, nicht dagegen die Interpretationssrelation, wie auch McDermid und Denvir richtig bemerken. Nicht zutreffend ist folglich ihre Verallgemeinerung der Erfüllungsrelation über die Beziehung zwischen Realität (Konzept) und Anforderungen (Text). "Das System erfüllt die Anforderungen" hat einen ganz anderen erkenntnistheoretischen Sinn als "Das System erfüllt die formale Spezifikation". Zwischen informalen Anforderungen und formaler Spezifikation besteht eine nicht mathematisch faßbare Beziehung, die das Diagramm noch nicht zum Ausdruck bringt. Die formale Spezifikation macht sich vom Realitätsbezug unabhängig. Erst die informalen Anforderungen liefern den Realitätsbezug. Diese intentionale Bedeutungszuweisung ist grundlegend verschieden von der einer mathematisch-logischen Interpretation. Wir nennen sie daher Sinnzuweisung. Folglich ist die Aufgabe der Anforderungsanalyse keineswegs mit der eines Naturwissenschaftlers vergleichbar. Es handelt sich vielmehr um die Aufgabe, bestimmte handlungsorientierte Konzeptualisierungen der Realität zu beschreiben, in einem Text niederzulegen. Sie ist eher mit der Aufgabe eines Ethnologen vergleichbar, der kulturelle Phänomene zu erfassen versucht, als mit der eines Naturwissenschaftlers, der Naturgesetze aufspürt. Die Aufgabe ist, Intentionen zu verstehen, Sinn zu erfassen. Dies bestätigt McDermids Bemerkung:

In practice it is very rare for problem domain theories to be re-used and this is an area where our current practices exacerbate the inherent problem.([21], S. 3)

Pannabecker, J. R.: Technological impacts and determinism in technology education: Alternate metaphors from social reconstructivism. Journal of Technology Education, 1991,Vol 3, Nr.1
(http://scholar.lib.vt.edu/ejournals/JTE/v3n1/pdf/pannabecker.pdf, 9.5.01):

IMPLICATIONS FOR TECHNOLOGY EDUCATION

The expression technological impacts needs to be abandoned as the primary metaphor for conceptualizing relationships between technology and society. These relationships are too complex to be understood solely as a set of causes and effects in which technology is the source of the causes and society the context of impacts. The immediate task is not, however, to find a single alternate metaphor but to recognize that there are different ways of approaching the study of technology and society. This diversity should be reflected in technology education programs, standards, and in the evaluation of programs. The current state of research and knowledge of the issues demand flexibility in the interpretation of the current technology education standards that address technology and society.

Nevertheless, flexibility of interpretation should not be construed to mean lack of rigor or "anything goes". Technology education has a mission with which its instructional and conceptual metaphors need to be integrated. For example, the emphasis on technology education for all students implies that women as well as men, non-experts and experts, and persons from all disciplines take an active part in decision-making. This inclusivity suggests the need for curricular research and critiques of technology assessment models, gender bias in technology, and the distribution of power (e.g., Carpenter, 1983; Noble, 1984; Rothschild, 1988).

Furthermore, technology education emphasizes the importance of DOING technology as a continuous and necessary part of the learning process. And it is in doing technology that students socially construct technology. Students direct, order, and influence technology and in so doing, belie the most extreme forms of technological determinism. Even a brief observation of this learning process demonstrates the existence of the indeterminant and aleatoric, laziness and concentration, social distribution and acquisition of power, failures and marginal successes typical of all social processes.

Studying impacts places the emphasis on a restricted and traumatic point in a sequence, in a sense, after the fact. Studying the social construction of technology places greater emphasis on the learning process of doing technology. Social constructivism, including systems metaphors and actor networks, as well as other models (e.g., historical and philosophical analyses) provide frameworks for conscious reflection and extend our understanding of technological complexity.

Klafki, Wolfgang: Grundzüge eines neuen Allgemeinbildungskonzepts. Im Zentrum: Epochaltypische Schlüsselprobleme. S. 43 - 81. In: Klafki, Wolfgang: Neue Studien zur Bildungstheorie und Didaktik. Weinheim, Beltz. 5. Auflage 1996 (1. Auflage 1985): S.61

Mein Vorschlag, die Konzentration auf Schlüsselprobleme im umschriebenen Sinne als eines der inhaltlichen Zentren eines neuen Allgemeinbildungskonzepts anzuerkennen und die entsprechenden curricularen bzw. didaktischen Konsequenzen zu ziehen, setzt voraus, daß ein weitgehender Konsens über die gravierende Bedeutung solcher Schlüsselprobleme diskursiv - z.B. in neuen Curriculum-Kommissionen - erarbeitet werden kann, nicht aber, daß das auch hinsichtlich der Wege zur Lösung solcher Probleme von vornherein notwendig ist. Im Hinblick auf die Frage der Lösungswege ist vielmehr zu betonen: Zur bildenden Auseinandersetzung gehört zentral die - an exemplarischen Beispielen zu erarbeitende - Einsicht, daß und warum die Frage nach "Lösungen" der großen Gegenwarts- und Zukunftsprobleme verschiedene Antworten ermöglicht, die etwa durch unterschiedliche ökonomisch-gesellschaftlich-politische Interessen und Positionen oder durch klassen-, schichten- oder generationsspezifische Sozialisationsschicksale und Wertorientierungen oder durch höchst individuelle weltanschauliche Grundentscheidungen bedingt sein können.

Aus diesem Grundsachverhalt folgt jedoch keineswegs die umstandslose Anerkennung aller solcher Positionen als gleichberechtigt. Vielmehr stellt sich die Frage nach Kriterien, mit deren Hilfe die Geltung unterschiedlicher Lösungsvorschläge für ein Schlüsselproblem oder einzelne seiner Teilelemente wertend beurteilt werden kann. Das entscheidende Kriterium läßt sich in der Frage ausdrücken: Wieweit können die einem Lösungsvorschlag zugrundeliegenden Prinzipien für alle potentiell Betroffenen verallgemeinert werden? 

Klafki, Wolfgang: Grundzüge eines neuen Allgemeinbildungskonzepts. Im Zentrum: Epochaltypische Schlüsselprobleme. S. 43 - 81. In: Klafki, Wolfgang: Neue Studien zur Bildungstheorie und Didaktik. Weinheim, Beltz. 5. Auflage 1996 (1. Auflage 1985): S.63f

Ich wende mich noch einem weiteren Aspekt der These von der notwendigen Konzentration auf Schlüsselprobleme im Sinne der hier vertretenen Allgemeinbildungskonzeption zu. Bei der Auseinandersetzung mit Schlüsselproblemen an exemplarischen Beispielen geht es nämlich nicht nur um die Erarbeitung jeweils problemspezifischer, struktureller Erkenntnisse, sondern auch um die Aneignung von Einstellungen und Fähigkeiten, deren Bedeutung über den Bereich des jeweiligen Schlüsselproblems hinausreicht. Ich hebe vier grundlegende Einstellungen und Fähigkeiten heraus. Sie enthalten jeweils inhaltsbezogene und kommunikationsbezogene Komponenten:

• Kritikbereitschaft und -fähigkeit einschließlich der Bereitschaft und Fähigkeit zur Selbstkritik. Dabei geht es darum, jeweils nach der Überzeugungskraft und den Grenzen fremder und eigener Begründungen für eine Position zu fragen und damit einen akzeptierten oder selbstentwickelten Standpunkt für weitere Prüfung offenzuhalten.
• Argumentationsbereitschaft und -fähigkeit, d.h. das Bemühen, eigene Positionen und eigene Kritik so in den Zusammenhang eines Gesprächs bzw. Diskurses mit anderen einbringen zu wollen und einbringen zu können, daß den Gesprächspartnern Verstehen und kritische Prüfung ermöglicht wird, so also, daß die Chance zum gemeinsamen Erkenntnisfortschritt gewahrt bleibt, hin zu besser begründeter Erkenntnis, als man sie zunächst besaß.
• Empathie im Sinne der Fähigkeit, eine Situation, ein Problem, eine Handlung aus der Lage des jeweils anderen, von der Sache Betroffenen aus sehen zu können. Das bedeutet einmal mehr, nicht jede beliebige Sichtweise ungeprüft als gleichberechtigt anzuerkennen; vielmehr geht es darum, Prozesse der argumentativen Erarbeitung begründeter Konsense in Gang zu setzen oder in Gang zu halten, Konsense, die über die anfängliche Diskrepanz unterschiedlicher Sichtweisen hinausgelangen können.
• Schließlich nenne ich noch eine weitere Bereitschaft und Fähigkeit von übergreifender Bedeutung. Man kann sie als "vernetztes Denken" oder "Zusammenhangsdenken" bezeichnen. Sie soll etwas ausführlicher erläutert werden.

Flowers, Jim: Problem Solving in Technology Education: A Taoist Perspective. In: Journal of Technology Education, Vol 10, Nr.1 1998.
(http://scholar.lib.vt.edu/ejournals/JTE/v10n1/flowers.html, 9.5.01):

Back then, the student often began with a project idea, not with a problem to solve. As this shift in approach occurs, one problem faced by today's teachers of product design is that students tend to subvert a prescribed design process. For example, a typical teacher may ask a student to engage in such a design process, beginning with the student identifying a problem to solve. Often this is a need or want. Next, the student may be asked to gather information and then to formulate many possible solutions to the problem, eventually choosing the best. In reality, some students approach the activity with the thought, "I want to get a CD rack out of this class", or some similar sentiment that begins with one particular solution. In order to satisfy the teacher's requirements, they then craft a need to fit this product idea. While most of their designs are fanciful and lack practical application, a few do, in fact, make sense. However, the entire approach of asking students to design yet another product to satisfy our needs and wants may be misguided, for two reasons.

First, few, if any, of today's products are designed (by technology students or professional product designers) to meet actual needs. They are almost always designed to meet open markets, and then human wants can be engineered to meet the product availability. A common joke asks, "If necessity is the mother of invention, how come so many inventions are unnecessary?" The phrase, "The customer is always right," and its more cynical corollary, "Give the customers what they think they want," are not without merit, and have led to economic success for many capitalists. However, the result of product design activities for technology students is that these students learn materialism to an extreme. They are taught that just because something can be invented or produced, it should be. They are taught that creatively designing products is a good thing, regardless of the outcomes. The ultimate criterion for success is money.

Second, problem solving and product design are not the same; the best result of a sound problem solving process is often something other than a new product. Maybe the solution to a problem would be a change in corporate policy, new legislation, a consumer education program, or changes in how a product is marketed. These are each examples of design, but it is a system, not a product, that is designed or redesigned. Maybe the best solution is non-action, and acceptance of the situation without change. There have been numerous examples of technological products or "fixes," such as DDT, that have backfired. We need a global citizenry that can entertain a wider variety of solutions than merely a new technological product. Yet if students are told (even tacitly) that their solution must be a physical product or model, then we are restricting their diversity of solutions, and thereby asking them to choose what may not be the best solution. Maybe that approach to problem solving is part of how teachers are taught. Boser (1993) compared problem solving educational specialists in two groups, technology teacher educators (TECH) and other researchers who were not technology teacher educators (EXT). "Members of the TECH panel tended to rate most highly those procedures practiced within the field, such as design-based problem solving, R & D experiences, and innovation activities. EXT panelists considered techniques such as simulation and case study, which are perhaps more widely used in content areas outside of technology education, as appropriate delivery vehicles for the recommended problem solving procedures", stated Boser.

Benutzer: gast • Besitzer: schwill • Zuletzt geändert am: