Funktionale Modellierung im Unterricht -Anwendungen und Implikationen

Karin Hodnigg

Universitat Klagenfurt, Institut fur Informatiksysteme, Austriakarin@isys.uni-klu.ac.at

Abstract. Die Unterschiede in einzelnen Programmierparadigmen habennachhaltige Auswirkungen auf die Problemlosungsstrategien von Schulern.Nach einer Gegenuberstellung der bekanntesten Paradigmen befasst sichdiese Arbeit vor allem mit der Denkweise der funktionalen Modellierungim Unterricht. Der Einstieg uber das funktionale Denkmodell erweistsich gerade in Hinblick auf das Verstandnis von Funktionen als vielversprechend. Dabei stellen Tabellenkalkulationen eine gute Moglichkeitdar, diese funktionalen Modelle in dem Datenfluss ahnlichen Darstellun-gen zu implementieren.Heute werden Tabellenkalkulationen hauptsachlich anwendungsorientiertunterrichtet (ECDL). Allerdings ist auch das Erstellen einer ”einfachen”Kalkulation das Erstellen eines Programms. Daten in Zellen werdendurch eine hochentwickelte Formelsprache miteinander verknupft, umneue Information zu gewinnen. Da das den Tabellenkalkulationen zu-grunde liegende Paradigma vom herkommlichen prozeduralen abweicht,aber dem funktionalen durch seine Natur entgegenkommt (wenn auchnicht entspricht), ist die Verknupfung von funktionalen Datenmodel-lierungen und Tabellenkalkulationen sinnvoll und vor allem hilfreich, umbei Schulern Verstandnis fur funktionale Modellierung und das Funktio-nenkonzept zu erarbeiten.

1 Motivation

Der Informatikunterricht an der Schule ist primar mit dem Erarbeiten vonProblemlosungen verbunden. ”Programmieren” heisst ja nichts anderes, als eineLosungsstrategie so zu beschreiben, dass der Computer diese Strategie als Ver-fahren ausfuhren kann. Hohere Programmiersprachen dienen dazu, die kogni-tive Lucke zwischen Problemlosung des Programmierers auf der einen Seite undden Schaltkreisen auf der anderen Seite zu schließen. Zentral ist daher das Er-arbeiten von Modellen und den entsprechenden Losungsstrategien (Program-men). In weiterer Folge ist mit ”Programm” tatsachlich der allgemeine Terminusgemeint - wie wir in weiterer Folge noch sehen werden, inkludiert das Sprechenuber Paradigmen auch das Sprechen uber das Modell zur Losung eines Problemsals auch die Implementierung und Ausfuhrung.

Dabei muss der Schuler vor allem in Hinblick auf sein Denkmodell unterstutztwerden, sei dies nun prozedural, funktional oder logisch. Daher kann Infor-matikunterricht niemals nur auf der Vermittlung von Programmierdialekten fußen,

sondern muss ganz wesentlich auf unterschiedliche Paradigmen eingehen. Nur sokann dem Schuler ein Verstandnis vermittelt werden, mit dessen Hilfe er odersie entscheiden kann, welche Strategie die beste zu Losung eines Problems (oderauch Ratsels) ist.

Basierend auf dem linguistischen Relativitatsprinzip, genauer der ”Sapir-Whorf”-These [!!!] [], kann formuliert werden, dass ”Unterschiede zwischen denSprachen Unterschiede in den gedanklichen Strukturen ihrer Sprecher (bei gle-icher außerer Situation) bewirken”. Im schulischen Umfeld herrscht daher leb-hafte Diskussion uber das beste, das adaquate Paradigma und entsprechendeDenkmodell fur den Informatikunterricht. Gleiches gilt fur das verwendete Werkzeug.Die Interaktion zwischen dem Trager der fundamentalen Idee, dem Werkzeug,mit dem gearbeitet wird und der Ruckwirkung auf das Denken ist in Abb. 1dargestellt.

Fig. 1. Paradigmen und Denkweise

Abbildung 1 zeigt die Zusammenhange und Ruckwirkungen, basierend aufder Sapir-Whorf-These, deren Aussagekraft zwar vielleicht im linugistischen Bere-ich diskutiert werden kann, fur informatische Grundprinzipien allerdings kaumangezweifelt werden kann. Ob die Losung eines Problem einfacher in einemFakten-Regel-System oder einem prozeduralen Programm gefunden werden kann,ist erstens eine fachinformatische Frage, zweitens aber, und das von großererWichtigkeit, eine Frage des Denkmodells unseres Programmierers. Erst wenner beide Paradigmen kennt (und sich gefahren- und fehlerfrei in ihnen bewe-gen kann), kann er eine Entscheidung treffen. Es geht also mehr als nur umdas Sprechen unterschiedlicher Sprachen (um in der linguistischen Metapher zubleiben), sondern um das Finden des richtigen Denkmodells!

2 Programmierparadigmen im schulischen Kontext

Uber die Notwendigkeit zu diskutieren, ob Programmieren Teil der Computer-und Allgemeinbildung sein soll bwz. ist, ist mittlerweile uberflussig geworden:

Programmieren gehort als eine spezifische Art der Problemlosung zum Wissen,das Schuler benotigen, um den Computer sachgerecht zu benutzen. Jedenfallsaber sind die zugrunde liegenden Denkprinzipien notwendig: Nur so kann derim Rahmen des Informatikunterrichts verhindert werden, dass dem ComputerAnimositaten unterstellt werden! Nichts Mystisches geschieht in der Interaktionmit einem Computer, lediglich die implementierten Programme (welcher Artauch immer) werden ausgefuhrt.

Ein Programmierparadigma ist ein Prinzip, ein Denkmodell, das einer Pro-grammiertechnik zugrunde liegt. Dabei unterscheidet man zwischen imperativer,pradikativer, funktionaler und objektorientierter Programmierung. Hier werdendiese kurz prasentiert, wobei vor allem das Denkmodell eingegangen wird, dassie evozieren.

– Imperatives ProgrammierparadigmaDas imperative, etwas legerer auch das prozedurale Programmierparadigma,betrachtet Programme als eine Abfolge beziehungsweise eine Abarbeitungvon elementaren Anweisungen. Diese Anweisungen dienen der Manipulationvon Daten, welche das gewunschte Ergebnis liefern. Grundlegendes Konzeptim imperativen Paradigma ist daher das Variablenkonzept. Im Wesentlichenfallen ”traditionelle” Programmiersprachen unter dieses Paradigma, wie bspw.Assembler, Pascal, C oder Modula-2.Illustrierend hier ein kurzes Pascal-Beispiel, das obige Ausfuhrungen un-terstreicht: Anweisungen werden (auch in Schleifen oder Entscheidungen)nacheinander ausgefuhrt, dabei wird die Anweisung abgearbeitet. Die Lauf-variable i verdeutlicht bereits in diesem kleinen Beispiel das Konzept derVariable - ein fur Schuler durchaus komplexes Konzept, da es leicht von dermathematischen Bedeutung abweicht.

Beginvar i : integer;for i := 1 to 10 dowriteln(’schleife an der stelle’ + i);

End.

– Pradikatives ProgrammierparadigmaDas pradikative, auch logische Paradigma betrachtet einen (abgeschlossenen)Teil der Welt, in der bestimmte Tatsachen (Fakten) und Gesetze (Regeln)existieren. Aufgrund von bestimmten Fakten konnen Regen ”feuern”, d.h.ausgefuhrt werden, und andern damit das Universum, das die Basis aus Fak-ten und Regeln beschreibt. Ein Programm ist dann die Suche nach Antwortenauf Anfragen. Bekannteste Vertreter des pradikativen Paradigmas ist sicher-lich PROLOG.Hier ein Beispiel in Prolog, das illustriert, in welcher Form ein logischesProgramm definiert und ausgefuhrt wird. Dabei werden die Eltern von Abeluber Fakten modelliert. Die child()-Regel definiert dann, dass X ein Kindvon Y und Z ist, wenn Y (bzw. Z) ein parent von X sind. ?- ist der Aufrufder Inferenzmaschine, welche dann ausgehend von den definierten Faktenund Regeln pruft, ob die angegebene Regel zutrifft.

man(Adam).woman(Eva).parent (Eva, Abel).parent (Adam, Abel).child (X, Y, Z) :- parent( Y, X), parent (Z, X).

?- child(Abel, Eva, Adam)

Zu beachten ist, dass im Gegensatz zur umgangssprachlichen ”Offenheit”ein solcherart modelliertes Universum abgeschlossen ist - nicht modellierteswird nicht mit ”nicht modelliert” sondern mit ”existiert nicht” beantwortet.So fuhrt ?-man(Kain) zu einem NO.-Resultat.Sowohl dem funktionalen als auch dem logischen Paradigma liegt der Gedankezugrunde, nicht mehr zu definieren, wie ein Problem zu losen ist, sondernwas das Problem selbst ist (”Wie” versus ”Was”). Fur die Erarbeitung desgewunschten Resultats ist eine so genannte Inferenzmaschine verantwortlich.

– Funktionales ProgrammierparadigmaIm funktionalen Programmierparadigma wird ein Programm als eine Trans-formation zwischen Eingabe- und Ausgabewerten betrachtet. Ein vollstandigesProgramm ist daher die Verschachtelung unterschiedlicher Funktionen, beider Ausfuhrung des Programms werden dann die einzelnen Funktionen angewen-det.Inharent ist hier das Prinzip der Rekursion: Ein Problem wird solange durchselbstbezugliche Referenzen ”verkleinert”, bis es leicht losbar ist. Die Losungeines rekursiven Problems stellt dann die Zusammenstellung der einzelnen,leicht errechenbaren Losungen dar [?]. In LISP, als einen Vertreter des funk-tionalen Paradigmas, ist das Variablenkonzept fast vollig fremd (und unter-scheidet sich fundamental vom Variablenkonzept der imperativen Program-miersprachen).

(DEFUN fakultaet (n)(COND ((EQUAL n 0) 1) ( T (TIMES n (fakultatet (DIFFERENCE n 1))))))

Obiges Beispiel zur Berechnung der Fakultat verdeutlicht[?], dass auch hierKonditionen moglich sind - trotzdem ist das Grundkonzept, die Rekursion,ein fur Schuler schwer oder kaum verstandliches.Funktionale Programmierung erfolgt problemorientiert und ist klar struk-turiert [Sch05]. Daruber hinaus kennt funktionale Programmierung keineSeiteneffekte und besitzt ein einfaches Grundprinzip: Ausserdem zeigt dasFunktionale Paradigma weitere Dimensionen des Funktionsbegriffs und derProgrammierung auf.

– Objektorientiertes ProgrammierparadigmaDas objektorientierte Paradigma basiert auf dem Prinzip von Klassen undMethoden. Klassen kapseln Daten und Methoden, wobei Methoden aus An-weisungen bestehen. Im Gegensatz zu imperativen Paradigma werden Datenzumindest konzeptionell nicht ”passiv” in Variablenform, sondern ”aktiv”behandelt: Die Ausfuhrung eines Programms fußt auf der Interaktion derKlassen mittels der Methoden.

class myObject {private int _myVal = 0;public int getValue() {

return _myVal;}public void setValue(int val) {

_myVal = val;}}

Die Objektorientierung hat in Smalltalk, C++, Java, etc. unzahlige Vertreter.Obiges Beispiel illustriert ein wenig die Trennung von Daten und Operatio-nen darauf.

Anzumerken ist noch, dass obige Einteilung nur eine mogliche ist und keineswegsdogmatisch aufgefasst werden darf. Alle Paradigmen bieten einen unterschiedlichenBlick auf die Problem- und Programmierwelten, mit denen ein Schuler im Nor-malfall konfrontiert ist. Daher ist die Vermittlung einer Basis fur zumindest diePrinzipien der imperativen (objektorientierten), pradikativen und funktionalenProgrammierwelt notwendig.

Im Allgemeinen wird man Schuler nicht mit der ganzen Variabilitat und Kom-plexitat eines Paradigmas ”uberfallen”, sondern sie mittels so genannter ”ToyWorlds” (Spielewelten wie bspw. KAROL, LOGO, etc.) auf die Programmierweltin kleinen Schritten vorbereiten. Schildkroten, Roboter etc. sind da gute An-wendungsbeispiele, brauchen allerdings in letzter Konsequenz die Uberfuhrungin eine fur die Schuler in Hinblick auf ihre spatere Lebenswelt sinnvolle En-twicklungsumgebung. Mit der funktionalen Modellierung schafft man diesen Sp-agat nahezu spielerisch: Durch funktionale Modellierung werden Schuler an dasfunktionale Paradigma herangefuhrt, ohne gleich mit der vollen Komplexitatkonfrontiert zu sein, andererseits aber die Moglichkeit haben, dadurch eine fursie alltagliche Softwareumgebung (die der Tabellenkalkulation) sinnvoll und vorallem zweck- und zielgerichtet zu nutzen [Hub04], [Hod05].

3 Funktionale Modellierung im Unterricht

Nun stellt sich aufgrund der Bandbreite der unterschiedlichen Ansatze die Fragenach dem adaquaten Start in die Welt der Programmierung fur Schuler. Sicher-lich ist die imperative bzw. daraus abgeleitete objekt-orientierte Programmierungvorherrschend im Informatikunterricht. Gerade am Anfang erleichtert vielenLernenden die ”‘Kochbuch-Rezept”’-Metapher den Einstieg in Programmierungeines Systems Allerdings zeigen sich nach [Sch95], citehubwieser darin docherkennbare Schwachen, da die imperative Programmierung mit einer ganzenMenge an Konstrukten, Kontrollstrukturen und Befehlen aufwartet (”Lernen aufVorrat”). Anstatt sich auf die Modellierung der Losung und die anschließendeImplementierung zu konzentrieren, werden Anfanger mit diesem Uberbau oftuberfordert. Mit Fortschritt der Erfahrungen der Schuler ist das imperative/objektorientierte

Paradigma und darauf basierende Programmiersprachen aber die Sprache derWahl (auch in Hinblick auf spateren Nutzen).

Logische Programmierung andererseits erfordert Vorkenntnisse der Pradikatenlogik- auch wenn Schuler haufig in der Lage sind, logische Probleme intuitiv zu losen[Sch95]. Dieses Vorwissen kann allerdings haufig nicht vorausgesetzt werden.Allerdings sollte gerade die deklarative Problembeschreibung unbedingt auchTeil des Informatikunterrichts sein.

3.1 Funktionale Modelle

Das funktionale Paradigma fordert einen klaren Programmierstil - und funk-tionales Denken fordert einen verstandigen Umgang mit bestimmten Software-Systeme (im Speziellen jetzt Tabellenkalkulationen). Doch steht das Konzept derRekursion in keinerlei Relation mit einem adaquaten Einstieg in die Program-mierung. Trotzdem ermoglicht das funktionale Konzept eine Verstandnisbildunghinsichtlich des Funktionen-Begriffs, der deklarativen Problemanalyse und derPartitionierung eines großen, moglicherweise schwer losbaren Problems in einebestimmte Anzahl kleinerer, einfacherer Probleme.

Um mit [?] zu sprechen: ”‘Lediglich die kausale Struktur und der funktionaleDatenfluss eines Kontextes konnen [als Einstieg] reprasentiert werden; Rekur-sionen oder schleifenahnliche Konstrukte konnen und sollen nicht modelliertwerden”’. Allerdings ist ein weiterfuhrender Unterricht in Richtung funktionaleProgrammierung in vertiefenden Wahlfachern sicherlich durch ebendiese Model-lierungskonzepte im Anfangerunterricht unterstutzt.

Der saloppe Sprung von Programmierung zu Modellierung und die Ver-nachlassigung der tatsachlichen Implementierung gelingt jetzt nur, weil Program-mierung bis jetzt als Sammelbegriff fur das Finden von Problemlosungsverfahrenverwendet wurde. Aus diesem Grund braucht es jetzt keines fachlichen Sprungs,wir beschranken uns in weiterer Folge einfach auf die Modellierung desselben,ohne uns vorerst um eine Umsetzung oder tatsachliche Realisierung zu kummern.

Im funktionalen Paradigma steht der Funktionsbegriff im Zentrum. Diesensollte man also zuerst diskutieren (wohlgemerkt: nicht in dieser Form im Unter-richt).

Partielle Funktion: Sei f : Z −→ Y mit Z Definitionsbereich und Y Wer-tebereich. Ist nun X ⊇ Z, so nennt man f : X ⇀ Y f(x) = y mit x ∈ X, y ∈ Y ,oder auch zur Verdeutlichung der Relation zwischen Eingabe- und Ausgabew-erten X

f→ Y .D.h. partielle Funktionen sind Funktionen, die nicht in allen Elementen des

Grundbereichs definiert sind, sondern bestimmte Elemente bewusst undefiniertgelassen wurden. Diese mathematisch anmutende Definition hat aber ihre Wurzelnin der Informatik - und im funktionalen Paradigma: Jede Funktion ist eine par-tielle Funktion mit jenen Elementen im Definitionsbereich, die eine Ausgabeliefern. In der Informatik sprechen wir im Allgemeinen also nicht von totalenFunktionen.

3.2 Ein Beispiel einer funktionalen Modellierung

Im Informatikunterricht kann man daher eine Funktion uber eine Eingabemenge(von Werten), welche durch eine gegebene Transition in eine (andere) Mengevon Ausgangswerten verwandelt werden soll, definieren. Wenn Schuler aus derMathematik bereits den Funktionenbegriff kennen, ist das daher ein einfacherund vor allem doch entsprechend formaler Einstieg in die Modellierung undImplementierung. Außerdem wird die fundamentale des Datenflusses fur Schulereinfach greifbar.

Vor allem die Darstellung ist einfach moglich ( wenn man Rekursionen undSchleifenkonzepte außer Acht lasst). Abbildung 2 zeigt die Moglichkeit der Kon-struktion eines solchen Modells in einem einfachen Beispiel eines Ticketauto-maten.

Fig. 2. Ein Fahrscheinautomat (funktional modelliert)

Die Legende unten beschreibt die einzelnen Komponenten dieses funktionalenModells. Dabei wird vor allem der Datenfluss fur Schuler erkennbar, aber auchdie ”Einteilung” des Systems in unterschiedliche Funktionen. Dabei ist die Wichtigkeitdieser Erkenntnis keineswegs zu unterschatzen. Schuler mussen und sollen erken-nen, dass sich ein System keineswegs einfach so (aus dem Stand heraus) alsGanzes in jedem Detail beschreiben lassen [Sch05]. Die Aufsplittung der Funk-

tion verarbeite() in waehle Fahrschein(), zahle(), berechne Wechselgeld() lassterkennen, dass die einzelnen Funktionen leicht zu beschreiben sind als das gesamteSystem.

Mit diesen Ausfuhrungen wird offensichtlich, dass viele Autoren [Sch95],[Hub04],[Sch05] und [Hod05] den Einsatz funktionaler Modellierung vor allem fur deneinfuhrenden Informatikunterricht bevorzugen. Nach der Diskussion der unter-schiedlichen Denkmodelle, der Auswahl eines dieser Denkmodelle und der Diskus-sion auf mogliche (erwunschte) Ruckwirkungen auf das Denken der Schuler sollteman nach 1 wohl zur Auswahl eines Werkzeuges ubergehen, mit dem die model-lierten Probleme wohl auch implementiert (oder zum Teil implementiert) werdenkonnen. In dieser Arbeit konzentrieren wir uns auf Tabellenkalkulationen als dasWerkzeug unserer Wahl.

4 Tabellenkalkulation als Anwendung

Die Popularitat von Tabellenkalkulationen beruht vor allem auf der intuitivenAnwendung von Tabellenkalkulationssystemen. Tabellenkalkulationen sind le-icht zu erstellen und vor allem leicht zu uberprufen, da Formeln sofort ausgew-ertet werden. Die Einsatzmoglichkeit von Tabellenkalkulationsanwendungen, diees erlaubt, statt aufwendiger Programmierung einfachere Berechnungen rascheinzugeben. Die sofortige Auswertung von Formeln nach ihrer Eingabe verstecktzwar Komplexitat, allerdings werden dem Benutzer an der OberflachestatischeWerte angezeigt. Es ist fur den Endbenutzer (in unserem Fall den Schuler) alsonicht einfach nur durch Hinschauen erkennbar, ob sich ein statischer (Eingabe-)Wert oder eine Formel in einer Zelle befinden.

4.1 Tabellenkalkulationen in der Wirtschaft

Entscheidend jedoch ist, dass es sich bei der Erstellung von Tabellenkalkula-tionen in den meisten Fallen um Endbenutzerprogrammierung handelt. DasEndprodukt, also die Tabellenkalkulation selbst, ist Software. Domanenexpertenwird ein Werkzeug in die Hand gegeben, ihre Probleme direkt zu losen. Diesimpliziert aber auch, dass es sich bei den Endbenutzern nur selten auch um An-wendungsexperten handelt. Zu einem uberwiegenden Teil wird auch die Tatsachenegiert, dass die Erstellung von Tabellenkalkulationen eine Programmiertatigkeitist [1], [2]. Das Fehlen wichtigen Referenzdokumente wie Spezifikation oder Doku-mentation erschwert in weiterer Folge die Qualitatssicherung von bestehendenTabellenkalkulationen. Aus dem Software-Erstellungsprozess bekannte Defizitewie unzureichende Tests oder Audits, das Fehlen von Plausibilitatsprufungen,wenig Kontrolle uber Wartung und Entwicklung und unzureichendes Trainingsind daher Risiken, die es bei der Qualitatssicherung von Tabellenkalkulationenzu uberwinden gilt. Ein weiterer interessanter Aspekt bei der Bewertung derQualitat von Tabellenkalkulationen ist ein ubermaßiges Vertrauen in die Kor-rektheit.Schulunterricht soll daher auch hier ”Aufklarung” betreiben.

4.2 Das Tabellenkalkulations-Paradigma

Nach der Sapir-Whorf These gilt es vor allem in Hinblick auf die Endbenutzer-Programmierung im Bereich der Tabellenkalkulationen, die verwendete Pro-grammiersprache zu definieren und ihre Eigenschaften zu kennen [HK04]. Tabel-lenkalkulationen bieten neben einem starken visuellen Format (dem tabellar-ischen Layout) eine deklarative Formelsprache, welche uber Referenzen Zellenvoneinander abhangig macht. Die sofortige Auswertung einer Formel in einerZelle versteckt Komplexitat, fordert aber einen ”Versuch-und-Irrtum”-Ansatzbei der Entwicklung einer Tabellenkalkulation. Standige Modifikationen undlaufende Entwicklung werden dadurch zwar nicht erschwert, sind aber dochproblematisch. Tabellenkalkulationen konnen also nicht mit konventionellen Pro-grammen verglichen werden. Diese werden nach der vollen Spezifikation evaluiert,wahrend bei Tabellenkalkulationen nach jeder Modifikation einer Zelle die Tabel-lenkalkulation, genauer: die von der modifizierten Zelle transitiv abhangige Mengevon Zellen, neu berechnet werden muss. Abbildung 3 zeigt den Zusammenhangzwischen den unterschiedlichen Zellen, indem zuerst (in der Formelebene) Ref-erenzen betrachtet werden. Hier erkennt man, dass Datenabhangigkeiten quasidie unterste Schicht in diesem kleinen Modell darstellen.

Fig. 3. Drei ebenen aufbau von tabellenkalkulationen

Tabellenkalkulationen haben kein spezifiziertes oder eindeutiges Resultat.Ein Arbeitsblatt kann nicht nur ein Resultat liefern - auch die Zwischenresul-tate der Berechnungen sind haufig relevant. Mangelnde Dokumentation dieser(Zwischen-)Ergebnisse und das Fehlen einer Spezifikation (und sei diese noch soallgemein wie ”Diese Tabellenkalkulation errechnet die Umsatze der AbteilungX in den Quartal Q,R und S und berucksichtigt dabei Produkt P nicht”) machtTesten im klassischen Sinne der Softwareentwicklung unmoglich und erschwertdaruber hinaus die Wartung.

Langlebige Tabellenkalkulationen haben aber einen Lebenszyklus, der dur-chaus mit der Softwareentwicklung verglichen werden kann. Und doch existieren

bestechende Unterschiede: Da Entwicklung von Tabellenkalkulationen und Tabel-lenkalkulationsanwendung ineinander flie-ßen, existiert im Sinne einer Software-Entwicklung keine Trennung zwischen ”Programmierung” und ”Laufzeit”. Er-weiterungen sind einfach moglich (ohne Rekompilierung). Dabei soll jedoch zwis-chen beabsichtigten und unbeabsichtigten Erweiterungen unterschieden werden:Tippfehler und Seiteneffekte bei Anderungen sind nicht zu vernachlassigendeFehlerquellen. Daruber hinaus bieten Tabellenkalkulationsanwendungen eine ”ak-tive”, soll heissen adaptive, Entwicklungsumgebung.

Doch gibt es eine Reihe von Charakteristiken fur die Entwicklung einer Tabel-lenkalkulation. Im Allgemeinen werden Formeln fur einen Bereich von Dateneingegeben, welche dann mittels ”Klicken-und-Ziehen” uber einen Zellenbereich”kopiert” werden. Dabei ist die Entwicklungsumgebung, also die Tabellenkalku-lationsanwendung, aktiv. Aktiv deshalb, weil dabei Parameter, sprich Referen-zen, angepasst werden. Somit ist auch das Layout einer Tabellen-kalkulation einTeil des einer Kalkulation zugrunde liegenden Programms. Die Programmier-sprache einer Tabellenkalkulation umfasst demnach also vier Ebenen:

– Editor-Sprache– Formelsprache– Datenabhangigkeiten– Layout

Dabei stellen sowohl das Ansprechen von Daten uber Zelladressen als auchdie globale Natur der Datenzellen in einer Tabellenkalkulation wesentliche Un-terschiede zur herkommlichen Programmierung dar. Zellen einer Kalkulationkonnen irgendwo auf dem Arbeitsblatt referenziert werden, sind also praktischglobal sichtbar. Allerdings durfen in dem Datenabhangig-keitsgraphen keine Zyklen,so genannte zirkulare Referenzen, entstehen, daher sind fur eine Zelle ihre ”Quell-datenzellen” nicht sichtbar. Dies impliziert eine Sichtbarkeitsordnung [Hod05]auf Formelzellen, die nicht notwendigerweise der Ordnung des Layouts einerKalkulation entsprechen muss. Dieses Missverhaltnis kann zu Problemen fuhren,stellt aber Freiheit fur die Schuler dar [Sch05].

5 Funktionale Modelle in Tabellenkalkulationen

Nun haben wird eine Anwendung, welche unseren Anspruchen genugt: Sie ist

– funktional orientiert (deklarative Formelsprache!)– frei im Layout– implementiert bereits Datenfluss und Eingabezellen

Im Unterschied zu der Modellierung ist aber die Formelzelle, welche diegewunschte Berechnung ausfuhrt (also unsere Funktion) gleichzeitig auch Aus-gabewert - der dann angezeigt wird. Das allerdings durfte in Hinblick auf diekorrekte und konkrete Nutzung von Tabellenkalkulationen eher ein Vorteil dennein Nachteil sein.

5.1 Bespiel des Fahrscheinautomaten [revisited]

Nun versuchen wir das Eingangs vorgestellte funktionale Datenmodell als Tabel-lenkalkulationsprogramm zu ubertragen. Unsere Funktionen werden zu Funktio-nen aus den Eingabewerten, so berechnet sich ein Fahrpreis aus dem gewahltenFahrschein, der Ruckgabewert berechnet sich aus dem Fahrpreis und dem einge-worfenen Munzwurf.

Kopie.jpg

Fig. 4. Fahrscheinautomat - modelliert in einer Tabellenkalkulation

Dies lasst sich leicht implementieren: Eingabezellen ”Einwurf” und ”Fahrschein-wahl” sind leere Zellen, die den Input der Funktionen darstellen. Die externenSpeicher ”Munzspeicher” und ”Preistabelle” dienen mit vorgefertigten Datenzum weiteren Berechnen des Preises und des (moglichen) Retourgeldes. DieAusgabezellen sind dann jene letzten Berechnungszellen, welche einerseits Re-tourgeld berechnet haben, andererseits auch den Fahrschein drucken (in unseremFall: ”Ausgabe” oder ”Ausgabe verweigert”).

5.2 Grenzen der Funktionalen Modellierung imTabellenkalkulationsparadigma

Nun allerdings stoßen wir an die Grenzen mit unserem Modell: Wie konnteman modellieren, dass sich der Munzspeicher entsprechend den Eingaben andert,benotigen wir seine Daten doch zur Berechnung unseres Ruckgabegeldes. Nun,in dieser Modellierung ist dies mit einer Tabellenkalkulation nicht so einfachmoglich, ohne jetzt einen konzeptionellen Sprung im Unterricht machen zu mussen.

Selbstbezugliche Formeln zu bauen ist in Tabellenkalkulationen an und fursich kein Problem: Sie sind und bleiben allerdings in einer dem oben vorgestell-ten Paradigma gefahrliche Konstruktion. Das iterative Auflosen einer solchenRekursion (und der Darstellung der unterschiedlichen Zwischenergebnisse) stelltsich allerdings gar nicht so einfach dar.

Nehme man nun die hinlanglich bekannte Ulam-Funktion, auch als 3k+1-Funktion bekannt. Die einfache Implementierung dieser rekursiven Funktion

als funktionales Modell ist schon schwierig (da Rekursionen lediglich aufgelost,nicht aber dargestellt werden konnen). Eine Tabellenkalkulation kann diesesProblem lediglich analog zur Darstellung der funktionalen Modellierung [Sch05]aufnehmen, wie Abbilung 5 zeigt.

Fig. 5. Ulam Realisierung

Hier werden dann die Grenzen der funktionalen Programmierung in Exceldeutlich. Rekursion und Schleifenkonzept sind dem Tabellenkalkulationsparadigmavollig fremd. Hier endet dann auch die Anwendungsmoglichkeit von funktionalenApplikation.

6 Zusammenfassung und Ausblick

In dieser Arbeit wurden unterschiedliche Paradigmen vorgestellt, welche im In-formatikunterricht eingesetzt werden konnen und sollen. Davon ausgehend wurdeein Ansatz prasentiert, funktionale Modellierung einzusetzen, um einerseits Verstandniszu bilden fur Funktionen in der Programmierung, andererseits aber auch Werkzeugewie Tabellenkalkulationen hinreichend gut zu kennen, um zu wissen, dass auchdas einfache Erstellen einer Kalkulation bereits (interaktive) Programmierungist.

References

[HK04] Clermont M. Hodnigg K., Mittermeir R. Computational models of spreadsheetdevlopment: Basis for educational approaches. Proceedings of EuSpRIG 2004,5:p.153–168, 2004.

[Hod05] Karin Hodnigg. A pragmatic approach to spreadsheet training based uponthe ”‘projection-screen”’-model. In From Computer Literacy to InformaticsFundamentals, Proceedings of the International Conference on Informatics inSecondary School - Evolution and Perspectives, ISSEP 2005, pages p.116 –129, 2005.

[Hub04] Peter Hubwieser. Functional modelling in secondary schools using spread-sheets. Education and Information Technologies, Official Journal of the IFIPTechnical Committee on Education, 9:p.175–183, 2004.

[Sch95] Andreas Schwill. Programmierstile im anfangsunterricht. In InnovativeKonzepte fr die Ausbildung, 6. GI Fachtagung Informatik und Schule, pagesp.178 – 187, 1995.

[Sch05] Markus Schneider. A strategy to introduce functional data modeling at schoolinformatics. In From Computer Literacy to Informatics Fundamentals, Pro-ceedings of the International Conference on Informatics in Secondary School -Evolution and Perspectives, ISSEP 2005, pages p.130 – 144, 2005.