A. Pasternak:   Aber kommen wir jetzt zur Rekonstruktion. Rekonstruktion, Konstruktion hängen ja eng zusammen.

J. Magenheim:   Dekonstruktion!

A. Pasternak:   Ja, Dekonstruktion. Ja, vielleicht müssen wir auch Rekonstruktion und Dekonstruktion mal so ein bisschen ....

J. Magenheim:   Ja, ja, das sind verschiedene Dinge.

A. Pasternak:   Ja, aber es geht ja schon da um Informatiksysteme. Wenn es um Konstruktion geht, konstruiere ich ein Informatiksysteme und auch bei Dekonstruktion gehe ich an ein Informatiksystem. Oder sehe ich das da etwas zu platt?

J. Magenheim:   Also das Ganze hat da einen theoretischen Hintergrund, warum ich den Begriff 'Dekonstruktion' verwende. Und zwar hat das eigentlich einen philosophischen Hintergrund und zwar geht es Jacques Derrida um die Dekonstruktion als philosophischen Ansatz, der vor allen Dingen in der Literaturwissenschaft zum Tragen kam. Später auch in der Architektur. (Ich war vor ein paar Jahren im Oman, wo ich das sehr schön gesehen habe.) Im Artikel von Derrida, wo Bezug genommen wird zur Architektur. Aber das ist jetzt eine andere Baustelle. Also man kann Dekonstruktion durchaus außerhalb von Literaturwissenschaften anwenden, wobei manche Philosophen das strikt in Frage stellen.

Aber was heißt das? Software und auch Informatiksysteme haben ja verschiedene Repräsentationsformen. Wir können Softwarecode so als Code sehen, das ist dann praktisch eine Beschreibung auf textueller Ebene. Die müssen wir aber nur benutzen, damit wir uns als Menschen verständigen können, was da gerade entwickelt werden soll. Der Computer wird das ausrechnen, wenn wir eine Abfolge von Impulsen von Bitstrukturen geben oder vielleicht Assemblercode. Er ist schwer zu lesen, wenn ich das auch programmiert habe. Du wahrscheinlich auch.

A. Pasternak:   Ja natürlich, klar, mein Studienprojekt,

J. Magenheim:   ... inline in Pascal.

A. Pasternak:   'Error 97': Kommando nicht bekannt.

J. Magenheim:   Genau. Ja, also deshalb ist es halt so, dass wir erstmal uns klar machen müssen, dass Informatiksysteme ganz unterschiedliche Erscheinungsformen haben. Das kann natürlich eine Repräsentation sein in Form von Sourcecode. Das kann aber auch eine Hardware Description Language sein, die die Hardware beschreibt. Das kann eine grafische Beschreibung sein wie UML oder Business Process Modeling, was auch immer eine domain-spezifische grafische Beschreibungssprache. Das kann auf jeden Fall die GUI sein, die man konstruiert. Das können die Designpattern sein, die drinstecken, Model View Controller oder Observer-Observable, wenn es um Objekt und Strukturen geht. Ganz sicher die Hardware und auch wie sie funktionieren, die Vernetzungstrukturen, die als Topologie dahinter stecken. Also so eine Hardware, so ein Informatiksystem ist auf der technisch formalen Ebene erstmal sehr, sehr stark repräsentiert in unterschiedlichen Formen.

Und wir haben zusätzlich bei unseren didaktischen Ansätzen bei der Dekonstruktion auch noch Videoclips von realen Systemen hinzugenommen. Die funktionieren dann von so einem Schulkiosk zum Beispiel oder ein Hochregallager, das wir bauen wollten in Lego Mindstorm-Technik. Das wir aber vorher bei Bertelsmann real angeguckt haben, um da mal zu gucken, was ist die Realität, was machen die hier. Man kann Interviews machen mit Nutzern im Kontext von Requirements Engineering als Anforderungsanalyse.

Also es gibt halt ganz viele verschiedene Möglichkeiten, Informatiksysteme zu repräsentieren. Und jetzt ist halt der Text eine Form. Und jetzt muss ich noch mal zurückkommen zu Derrida, der halt sagt, wenn ich als außenstehender Betrachter mich mit so einem Text auseinandersetze, sprich Software, dann gibt es aber eine Differenz zwischen dem, was dort steht und was ich möglicherweise als Interpreter da hineininterpretiere. Und das ist ein Unterschied zum Beispiel zum Ansatz der Hermeneutik, wo es diesen hermeneutischen Zirkel gibt, wo ja das Postulat da ist, dass ich in Zirkeln und im Diskurs mich mit Texten auseinandersetze und mich dann immer dem wahren Gehalt des Textes nähere. Also sozusagen: Es gibt die Wahrheit und es ist möglich, es zu erschließen, was ich dann tatsächlich im Kern erschließen kann.

Das ist bei der Software die Frage, gerade auch beim Reengineering, weil wir entwickeln ja in der Praxis Software nie 'from the scratch on'. Und wenn du dich dann also mit Sourcecode beschäftigst, der vor allen Dingen auch mal schlecht dokumentiert ist und sollst jetzt praktisch dann das System weiterentwickeln, weil es zum Beispiel neue Funktionen bekommen soll. Dann musst du dich halt mit dem Sourcecode auseinandersetzen und musst den sozusagen dekonstruktiv lesen und musst denken, was hat der Entwickler sich dabei gedacht? Vielleicht hat er sich gar nichts dabei gedacht. Ist das jetzt Zufall, haben die was übersehen oder ist das genauso gemacht worden? Und das sind halt Dinge, die in diesem dekonstruktiven Ansatz bei Derrida oder auch bei der Architektur, das wäre ein anderes Beispiel von Technik, auch übertragbar ist auf Informatiksysteme.

A. Pasternak:   Ja, wir sind jetzt in der Schule. Das erste Mal, dass ich so richtig damit betroffen war, war in Königstein. Da habe ich nämlich ein Netzsystem, wie ich es im Leistungskurs entwickelt habe, vorgestellt. Es ist Ende der 90er Jahre, Anfang 2000 gewesen und Carsten war auch da. Und auf einmal sagte er, das ist ja Dekonstruktion. Da war mir das theoretische Konstrukt nicht so bekannt.

Und jetzt will ich dir mal eben vorstellen, was ich gemacht habe und du kannst selber mal sagen, ob du das als solches empfindest. Ich habe im Leistungskurs - wohl gemerkt - Netze gemacht. Und ich war der Meinung, bin auch weiterhin der Meinung, dass ich das auch theoretisch betrachten muss, wie ein Netz wirklich funktioniert. Und dass es da theoretische Konzepte gibt. Also habe ich das ISO-OSI-Modell besprochen. Aber ich finde es immer doof, wenn man so was auf einer Ebene stehen lässt, wo man es dann nur theoretisch bespricht. Es war mir aber auch klar, dass ich nicht irgendwie zum Beispiel ein reales System nehmen kann, angucken kann, auch die Software nicht angucken kann. Genau aus den Gründen, die du gesagt hast, es ist im Prinzip unmöglich, weil so viel spezifische Hardware für das System vorausgesetzt wird und man da berücksichtigen muss. Das geht nicht.

Also habe ich mir Folgendes überlegt: Dass ich mit den Schülern ein eigenes Netzsystem schreibe in der Sprache, die wir damals verwendet haben, sprich Pascal. Wir haben für jede Schicht ein eigenes Modul genommen. Wir haben die Schnittstellen beschrieben zwischen den Schichten. Und die Leute haben in Arbeitsgruppen dann entsprechend Software geschrieben. Das Netz, unsere Hardware-Schicht war ganz einfach: Dass wir in einem vorhandenen Novell-Netz im Prinzip eine Datei geschrieben haben.

J. Magenheim:   Du hast Dich auch mit Novell rumgeschlagen, ja?

A. Pasternak:   Ja, genau!
Die Datei wurde geschrieben und andere Rechner konnten darauf zugreifen. Und der Rechner hat sich immer mit einer Nummer als Adresse identifiziert. Da konnten wir dann, nachdem das System geschrieben wurde, also eine Anwendungsschicht drauflegen. In unserem Fall war das eine ganz einfache Sache. Wir schicken also irgendwelche Meldungen vom Rechner A zum Rechner B. Wäre das System, wie Carsten es gesagt hat: "Das ist ja ein Beispiel für Dekonstruktion"?

J. Magenheim:   Also ich muss da mal nachhaken. Wie kamt ihr auf das Protokoll? Wie kamt ihr auf die Layer-Schichten?

A. Pasternak:   Die Layer-Schichten sind vom ISO-OSI-Modell.

J. Magenheim:   Da habt ihr gesagt: "Das gibt's so", "Ihr müsst Euch die dritte, vierte Schicht angucken" und so weiter.

A. Pasternak:   "Und was macht die Schicht?" Und in unserem konkreten Fall ist der Eingang so und der Ausgang so. Und ganz oben stehen da irgendwelche textuellen Geschichten. Und ich sag mal, die Anwendungsschicht war so, dass der eine Rechner nur Großbuchstaben in der Repräsentation hatte und der andere Rechner nur Kleinbuchstaben. Was du in Grossbuchstaben losgeschickt hattest, kam beim anderen Rechner als Kleinbuchstaben an. Also solche Vereinfachungen haben wir gemacht. Aber es ging dann wirklich von Schicht zu Schicht runter. Und dann wurde die entsprechende Datei geschrieben, und der andere Rechner hat die Datei, wenn sie für ihn war, geholt. Und hat die dann dementsprechend wieder schichtenweise analysiert.

J. Magenheim:   Also das ist so grenzwertig, zumindest bezüglich der Dekonstruktion. Weil ihr habt natürlich ein vorhandenes theoretisches Konzept, das ISO-OSI-Modell genommen. Dass da die dritte, vierte Schicht relevant ist, und nicht die erste und die fünfte und so weiter, weil die sechste, deshalb müsst ihr die auch theoretisch auch aneignen, das habt ihr auch angelesen.

A. Pasternak:   Ja, wie haben die Unterschiede zum TCP/IP-Protokoll überlegt, warum das sinnvoll ist oder nicht.

J. Magenheim:   Also es ist ein gewisser Transfer von einem theoretischen Konzept in die Praxis. Ja, das ist grenzwertig, weil die Dekonstruktion will bedeuten, es liegt bereits ein funktionierendes technisches System vor, und ihr möchtet dem eine weitere Funktionalität hinzufügen.

Also wir hatten zum Beispiel das Problem: In dem Hochregallager, wo wir verschiedene Roboter haben rumfahren lassen, dass sie miteinander kommunizieren mussten, sie mussten über den Status berichten. Und da war es aber so, dass das Protokoll, dass das RIS verwendet, nicht ausreichend war. Wir wollten noch weitere Informationen übermitteln über Infrarotsensor. Und da haben wir uns schlau gemacht, wie kommunizieren die Roboter miteinander. Wir arbeiten hier mit den Sensoren zusammen, wie müssen wir das Protokoll erweitern.

Also wir sind jetzt nicht von nur einem theoretischen Konzept ausgegangen, sondern auch von einem praktisch existierenden System und haben dieses erweitert. Anfangs hatten die Regale, die waren alle gleich groß, die Boxen passten alle rein, alles war standardisiert. Aber jetzt gab es plötzlich - das war Reengineering - die Boxen waren unterschiedlich groß und es gab unterschiedlich große Regale. Und man musste halt finden, wo ist eins frei. Und dazu brauchte man eine Protokoll-Erweiterung.

A. Pasternak:   Da wäre die Abituraufgabe, die ich dann gestellt habe, vielleicht ganz passend dazu. Wir hatten ja im Prinzip ein Netz, wo jeder Rechner mit einer Integerzahl adressiert werden konnte. Dann habe ich gesagt, okay, wir können ja auch im Prinzip jetzt in unserem Novell-Netz verschiedene Dateien haben, und die Dateien sind halt unterschiedlich, repräsentieren verschiedene Netze. Und wie müsste jetzt ein Router aussehen, der also praktisch von einem Teilnetz zu einem anderen Teilnetz, wobei jetzt die Adresse erweitert wird auf Netzadresse und Rechneradresse, routet.

J. Magenheim:   Genau. Das wäre sehr typisch eine Dekonstruktionsaufgabe.

A. Pasternak:   Also haben wir doch an dieser Stelle im Endeffekt Dekonstruktion betrieben.

J. Magenheim:   Das würde ich schon sagen.
Und ich meine, wir haben jetzt halt die Dekonstruktion an Beispielen gemacht, die Informatiksysteme waren, die aus einer Einheit von Soft- und Hardware bestanden haben.

Ein anderes Beispiel ist so ein kleines Warenwirtschaftssystem in einem Kiosk, wo wir gesagt haben: Okay, diese Kiosksoftware erfasst zwar Waren, aber wir wollen jetzt auch eine andere Ausgabe haben, die GUI soll umgestaltet werden. Oder wir wollen die Preise anders gelistet haben. Und da musstest du halt praktisch in den Sourcecode gucken, wie sieht die GUI aus, wo wird eigentlich die Preisberechnung gemacht. Und du konntest dann an der Stelle etwas verändern. Das heißt, du hast eingegriffen in ein bestehendes System. Oder du hast dann sogar gesagt: Auftrag vom Management: Wir wollen mal wissen, wie gut der Umsatz an der einzelnen Kasse ist und ob da eine Fehlbedienung gemacht wird. Könnt ihr das mal programmieren?

Und da kam jetzt auch der gesellschaftliche Aspekt hinein. Das wollte ich jetzt gerade nochmal sagen, weil das ganz wichtig ist. Wenn wir Informatik und Gesellschaft als Thema im Unterricht haben wollen und wir wollen über so technische Systeme reden. Dann ist es mal ganz schön, mal so eine Sache zu machen.

Datenspuren im Netz, so ein Unplugged-Spiel, kennst du wahrscheinlich auch, wo man Datenspuren hinterlässt und da kommen bestimmte Vorfälle und das wird ausgewertet. Aber eigentlich ist der gesellschaftliche Impact von Informatiksystemen, die Entscheidung fällt bei der Systemgestaltung, indem du nämlich bestimmte Entscheidungen triffst und festlegst, was das System kann, was es nicht kann. Wer sieht überhaupt, was es kann. Gibt es Backdoors? Gibt es nur bestimmte Personengruppen, die privilegiert sind? So was du siehst, da kommst du zum Betriebsverfassungsgesetz, Gewerkschaftsfragen, Überwachung von Arbeitsplätzen. Das ist ein ganz spannendes Feld. Und da kann man nämlich sehen, dass eigentlich schon bei der Systemgestaltung in der technischen Entscheidung für das Design, der 'Social Impact' festgelegt wird.

A. Pasternak:   Ja, da stimm ich dir vollkommen zu.
Noch mal zurück zu meinem Beispiel. Ich habe das natürlich mit einem Leistungskurs gemacht. Einmal, weil nichts da war, was mir brauchbar erschien. Aber mit einem zweiten Aspekt. Ich wollte das eigentlich auch mit meinen Grundkursen besprechen. Mir war vollkommen klar, dass die Programmierungsvoraussetzungen bei den meisten Schülern schlechter sind. Wir haben auch wesentlich weniger Zeit im Grundkurs. Und meine Idee war: Zu sagen, okay, wenn ich das System einmal habe, auch ergänzt durch die Abituraufgaben und sonstige Dinge, dann kann ich das in späteren Kursen - auch im Grundkurs - einsetzen, die das eben nicht mehr selber programmieren. Aber wenn ich das ISO-OSI-Modell weiterhin besprechen will - was ich später dann nicht gemacht habe - dann wäre das die Möglichkeit: Wir haben dieses theoretische Modell und hier haben wir ein System. Und die hätten dann tatsächlich nur erstmal diesen Code analysiert, den sie selber nicht geschrieben haben.

Aber nicht so sehr unter dem Aspekt, dass sie da was verändern sollen, weil wahrscheinlich auch bei den meisten, die Programmmierfähigkeiten nicht so groß gewesen wären. Es sei denn, es wäre uns eine Kleinigkeit eingefallen. Aber es wäre wahrscheinlich nur auf einer Kleinigkeitsebene geblieben. Aber sie hätten, sie haben es zumindest dann teilweise analysiert. Wäre das in dem Sinne dann die relativ schulmäßige Anwendung dieses Prinzip auf der technischen Software-Ebene?

J. Magenheim:   Also dieser Zusammenhang von Exploration oder Dekonstruktion und Gestaltung spielt ja eine ganz große Rolle. Wir haben das Konzept ja weiterentwickelt nachher bis zur Primarstufe.