Fortbildungsveranstaltung des Staatlichen Schulamts Frankfurt THEORETISCHE INFORMATIK MIT
Fortbildungsveranstaltung des Staatlichen Schulamts Frankfurt THEORETISCHE INFORMATIK MIT ATOCC: FORMALE SPRACHEN, ABSTRAKTE AUTOMATEN UND COMPILER. EINSATZ DER SOFTWARE ATOCC (KURS: 07 F 305201) Frankfurt, am 10. 06. 08 Christian Wagenknecht, Michael Hielscher
Das Wichtigste zuerst! 2 Vielen Dank an Herrn Thomas Lösler. Frau Nagel und Frau Rückert
3 Veranstaltungsort: Gymnasium I, Frankfurt/Oder, Wieckestr. 1 b
TI-Inhalte in der Schulinformatik: Probleme und Chancen 4 Blick in die Lehrpläne verschiedener Bundesländer
Lehrplan Ziele und Inhalte 5 In den meisten Bundesländern sind ausgewählte Inhalte der TI Lehrplaninhalt der Sek. II: Nr. Bundesland Lehrplaninhalt (Lernbereich) Pflichtbestandteil Bereich der theoretischen Informatik 1 Baden-Württemberg nein (Automaten, Berechenbarkeit) 2 Bayern 3. Formale Sprachen (noch Entwurf) 3 Berlin 4. 4 Sprachen und Automaten ja (auch GK) 4 Brandenburg 4. 4 Sprachen und Automaten Ja (auch GK) Grundlagen der Theoretischen Informatik 5 Bremen nein (Automaten, formale Sprachen) Formale Sprachen, endliche Automaten, Keller 6 Hamburg nein automaten, Scanner, Parser, Ableitungsbaum Formale Sprachen und Grammatiken Automaten, 7 Hessen ja (auch GK) Fakultativ: Übersetzerbau 8 Mecklenburg-Vorpommern 4. 4 Sprachen und Automaten ja (auch GK) Eigenschaften endlicher Automaten 9 Niedersachsen nein Aspekte formaler Sprachen 10 Nordrhein-Westfalen Endliche Automaten und formale Sprachen nein Formale Sprachen und Automaten zur 11 Rheinland-Pfalz ja (nur LK) Sprachbeschreibung und Spracherkennung Automaten und formale Sprachen 12 Saarland ja (auch GK) Fakultativ: Übersetzerbau 13 Sachsen 8 A: Formale Sprachen, Kellerautomat, Akzeptor nein Endliche Automaten und formale Sprachen 14 Sachsen-Anhalt nein 15 Schleswig-Holstein Automaten als mögliches Themengebiet nein 16 Thüringen Themenbereich 7. 3: Einblick in formale Sprachen nein
TI-Inhalte in der Schulinformatik: Probleme und Chancen 6 Blick in die Lehrpläne verschiedener Bundesländer Konkrete Inhalte
Lehrplanauszug Hessen 7 Verbindliche Unterrichtsinhalte/Aufgaben: Formale Sprachen und Grammatiken reguläre und kontextfreie Grammatiken und Sprachen Anwendung mit Syntaxdiagrammen Chomsky-Hierarchie (LK) kontextsensitive Sprachen (LK) Endliche Automaten Zustand, Zustandsübergang, Zustandsdiagramm Zeichen, Akzeptor Simulation realer Automaten (z. B. Getränkeautomat) Anwendung endlicher Automaten (z. B. Scanner) deterministische und nicht-deterministische Automaten (LK) reguläre Ausdrücke (LK) Mensch-Maschine-Kommunikation (LK) Kellerautomaten (LK, GK fakultativ) Automat mit Kellerspeicher kontextfreie Grammatiken Klammerausdrücke, Rekursion Turing- oder registerberechenbar Churchsche These Computer als universelle symbolverarbeitende Maschine Verhältnis Mensch-Maschine Turing- oder Registermaschine (LK, GK fakultativ) Fakultative Unterrichtsinhalte/Aufgaben: Übersetzerbau Scanner, Parser, Interpreter und Compiler z. B. Steuersprache für Roboter, LOGO, Plotter oder mini. PASCAL
TI an Hochschulen – NICHTS für Schulen 8 Typischerweise: Begrifflich orientiert, deduktiv • Zeichen, Alphabet, Wort, Verkettung, Wortmenge • Sprache, formale Grammatik, Ableitung • reguläre Sprachen: Chomsky-Typ-3 -Grammatik, reguläre Ausdrücke, DEA, NEA, L(DEA)=L(NEA), Minimalautomat, diverse Sätze (Nerode/Myhill, Pumping Lemma, . . . ), . . . • kontextfreie Sprachen: Typ-2 -Gr. , DKA, NKA, L(DKA)<L(NKA), Transformation G >>> NKA (1 Zustand), diverse Sätze, . . . • ks. S / unbeschr. Sprachen: Typ-1 - und Typ-0 -Grammatiken, Turing-Maschine (beschränkt/unbeschränkt) * * Theorie der formalen Sprachen Automatentheorie Berechenbarkeitstheorie Komplexitätstheorie
Lernbereich 8 A (Sächs. Lehrplan) 9 endlicher Automat GK Informatik f. Jahrgangsstufen 11 und 12, wird ab Schuljahr 2008/09 wirksam
Informatik-Lehrplan: S II, Brandenburg 10 gemeinsames Kerncurriculum mit Berlin und Meck. Pomm = Basis für schulinterne Lehrpläne 1. Auflage: 2006, gültig für Qualifizierungsphase ab Schuljahr 2008/9
Kompetenzerwerb im Themenfeld (Auszug) 11 Die Schülerinnen und Schüler verstehen die zur Problemlösung eingesetzten Programmiersprachen als spezielle formale Sprachen, die es ihnen erlauben, Probleme mit den Methoden der Informatik zu lösen. Hoffentlich nicht!!! Durch die Einführung des Automatenmodells vertiefen sie ihr Verständnis von Informatiksystemen. Naja, die Lehrer. Innen werden's schon machen!
Abbildung der Kompetenzbereiche auf Kurshalbjahre 12 Klassen 11 und 12 (Qualifikationsphase): 4 Kurshalbjahre 3 -5 Stunden pro Kurshalbjahr
TI-Inhalte in der Schulinformatik: Probleme und Chancen 13 Blick in die Lehrpläne verschiedener Bundesländer Konkrete Inhalte: totale Überfrachtung mit Fachinhalten TI-Kompetenz der LP-Autoren? (Fachsystematik, Formulierung von Wunschvorstellungen, . . . )
Gefühlssituation der Lehrenden 14 "TI wollte ich nie machen. " "TI hat mich nie richtig interessiert. " "TI war mir immer zu theoretisch und abstrakt. " "Die TI-Dozenten waren suspekt – TI im postgradualen Studium erinnere ich mit Grausen. " "Die TI-Inhalten helfen mir nicht, wenn das Schulnetzwerk mal wieder zusammenbricht. ". . .
TI-Inhalte in der Schulinformatik: Probleme und Chancen 15 Zeit-Problem, Inhalte-Problem (Zusammenfassung von oben) Manche Lehrende mögen es nicht. – Motivationsproblem Manche Lehrende können es nicht richtig. Qualifikationsproblem Schüler. Innen/Studierende fragen gelegentlich: "Wann geht es denn nun endlich richtig los mit der Informatik? Ach so, das ist es schon. " - Vermittlungsproblem "Ergebnis": Wenn möglich, TI weglassen. FALSCH!!! Chance: Informatik als Wissenschaft repräsentieren! (wie Mathematik und Naturwissenschaften) Sonst: Studienabbrecher als konkrete Folge!!!
Didaktische Software für TI 16 § in Schulen: diverse Simulationstools oder Lernumgebungen, wie Kara; meist von enthusiastischen Lehrer. Innen entwickelt § in Hochschulen: Systeme für die Lehre, wie JFLAP LEX und YACC für die Hand des Ingenieurs Simulationstool – Bildungsserver Hessen
Defizite existierender Systeme 17 § Systeme bzw. separate Module thematisieren Einzelaspekte § nicht definitionskonform und/oder nicht an Lernprozessen orientiert, sondern die Prozess. Simulation dominiert § Suggerieren abstrakten Automat als physikalisches Objekt § Systeme können nur simple Beispiele bearbeiten – zu große Distanz zur Praxis
Lernumgebungen (Quelle: LP Brandenburg) 18 "Lernumgebungen werden so gestaltet, dass sie das selbst gesteuerte Lernen von Schülerinnen und Schülern fördern. Sie unterstützen durch den Einsatz von Medien sowie zeitgemäßer Kommunikations- und Informationstechnik sowohl die Differenzierung individueller Lernprozesse als auch das kooperative Lernen. Dies trifft sowohl auf die Nutzung von multimedialen und netzbasierten Lernarrangements als auch auf den produktiven Umgang mit Medien zu. Moderne Lernumgebungen ermöglichen es den Lernenden, eigene Lern- und Arbeitsziele zu formulieren und zu verwirklichen sowie eigene Arbeitsergebnisse auszuwerten und zu nutzen. "
Lern- und Arbeitsumgebung für TI: Anforderungen (1/2) 19 § ganzheitlicher Ansatz: Praxis Theorie Praxis, s. Lehrplanforderung § einheitliche Bedienung der Module (für Automatentheorie und Sprachübersetzer) § Handlungsorientierung auf hohen Abstraktionsniveaus (wenig technischer Ballast auch für anspruchsvolle Aufgabenstellungen)
Ato. CC - Vom abstrakten Automaten zur automatisierten Entwicklung von Sprachübersetzern 21 § Typische Kopplung von Automatentheorie mit Aspekten des Compilerbaus (s. Lehrpläne) § Wichtige didaktische Entscheidung: Zielsprache des Compilers sollte nicht Maschinencode sein!! § Herstellung eines lauffähigen(!) Sprachübersetzers durch Anwendung der Kenntnisse aus der TI erfordert hohe Abstraktion (CC mit VCC) § Modellierung des Übersetzungsprozesses mit "ausführbaren" T-Diagrammen
Didaktische Gestaltung der Lerneinheit 22 1. Belastbare Motivation für TI-Inhalte durch herausfordernde Start-Fragestellung mit Praxisrelevanz und Modellierung eines Zielsystems (Sprachübersetzer) am Anfang 2. Vermittlungs-/Anwendungszyklen für TI-Wissen mit Projektbezug (Praxis nicht als "Anhängsel" zur Theorie) 3. Komplexe Anwendung von TI-Inhalten auf sehr hohem Abstraktionsniveau (automatisierte Compiler-Generierung), Rückkehr zur und Konkretisierung der Modellierungsebene Behauptung: Dabei ist Ato. CC ein unverzichtbares Hilfsmittel.
Beispiel: ZR – eine Sprache für einen Zeichenroboter 23 Installationshinweise: Bitte Reihenfolge einhalten! Software unter: www. atocc. de Fortbildung Software Installieren Sie Ghost. Script 8. 60 http: //www. michael-hielscher. de/download/gs 860 w 32. exe Installieren Sie „Ato. CC Setup. exe“ http: //www. michaelhielscher. de/download/atocc/Ato. CC%20 Setup. exe Wenn nicht vorhanden einen PDF Reader (Adobe Reader oder Foxit Reader) installieren.
Beispiel: ZR – eine Sprache für einen Zeichenroboter 24 Praxisnahe (echte!) Aufgabe mit grafischer (akustischer) Ausgabe: Entwickeln Sie einen Compiler, der die Sprache ZR (Zeichen. Roboter) in PDF übersetzt. (Schülergerecht formulieren!) Eingabewort (in ZR): WH 36 [WH 4 [VW 100 RE 90] RE 10] Sprachelemente: VW n Vor. Wärts n Schritte RE n Rechts um n Grad WH n [. . . ] Wiehder. Hole n-mal [. . . ] FARBE f Stift. FARRBE f STIFT n Strichstärke n Aufgabe: Verwenden Sie den fertigen Compiler zr 2 pdf blume. zr (konsole. bat aufrufen, blume. zr ansehen)
Beispiel: ZR – eine Sprache für einen Zeichenroboter 25 Der Zeichenroboter kann auch mehr: Bunte. Blume. zr
Beispiel: ZR – eine Sprache für einen Zeichenroboter 26 Weiterer Ablauf: 1. Modellierung der Problemlösung mit TDiag 2. Syntax-Definition von ZR: formale Grammatik, Ableitungsbaum mit kf. GEdit 3. Parser Akzeptoren Automatenmodelle (EA, KA) mit Auto. Edit 4. Arbeitsteilung: Scanner, Parser 5. Zielsprachenbezug automatisierte Compiler-Entwicklung mit VCC 6. Teilsysteme werden in Modellierung eingebracht (TDiag) 7. Ergebnis: lauffähiger (nichttrivialer) Übersetzer, den man benutzen kann! TDiag, kf. GEdit, Auto. Edit, und VCC sind Bestandteile von Ato. CC.
Beispiel: ZR – eine Sprache für einen Zeichenroboter 27 Wir wollen zunächst den Übersetzungsprozess entwerfen modellieren Verwendung von T-Diagrammen: T-Diagramme bestehen aus 4 Bausteintypen. Compilerbaustein, Programmbaustein, Interpreterbaustein und Ein/Ausgabe-Baustein Compiler Programm Interpreter Ein/Ausgabe an Programmbaustein
Beispiel: ZR – eine Sprache für einen Zeichenroboter 28 T-Diagramm: 1. Entwurf ZR 2 PDF möchte niemand schreiben!!!
Beispiel: ZR – eine Sprache für einen Zeichenroboter 29 T-Diagramm: 2. Entwurf ZR 2 PS werden wir entwickeln, PS 2 PDF und Acrobat Reader wird vom System bereitgestellt.
Beispiel: ZR – eine Sprache für einen Zeichenroboter 30 Nachdem wir nun wissen, wie unser Compiler später zur Übersetzung eingesetzt werden soll, wenden wir uns der Entwicklung des Compilers zu. Zunächst für die Quellsprache: Mit Sprache auseinandersetzen: Beispielwörter bilden; Grammatik definieren, d. h. Terminale bestimmten, Produktionsregeln angeben und dabei Nichtterminale festlegen = induktives Vorgehen Ableitungsbäume erzeugen
Beispiel: ZR – eine Sprache für einen Zeichenroboter 31 Wir betrachten die Sprache ZR und versuchen ihren Aufbau zu beschreiben: VW 50 RE 270 RE 45 WH 2 [VW 100] WH 4 [VW 100 RE 100] WH 36 [WH 4 [VW 100 RE 90] RE 10] Magnetkarten an der Tafel
Beispiel: ZR – eine Sprache für einen Zeichenroboter 32 Beschreiben wir den Baustein Zahl genauer: soll in ZR keine Zahl sein, da VW 0 oder RE 0 keine Veränderung herbeiführen. Vorangestellte Nullen, wie bei 0815, wollen wir auch nicht erlauben. 0 Ergänzen wir unsere Grammatik um: Zahl Ziffern Ziffer Erste. Ziffern Ziffern | 0 | 1 |. . . | 9 1 | 2 |. . . | 9
Beispiel: ZR – eine Sprache für einen Zeichenroboter 33
Beispiel: ZR – eine Sprache für einen Zeichenroboter 34
Beispiel: ZR – eine Sprache für einen Zeichenroboter 35
Beispiel: ZR – eine Sprache für einen Zeichenroboter 36 Programm Anweisungen | EPSILON Anweisung VW Zahl | RE Zahl | WH Zahl [ Anweisungen ] | FARBE Farbwert | STIFT Zahl Farbwert rot | blau | gruen | gelb | schwarz Zahl Erste. Ziffern Ziffern | EPSILON Ziffer 0 | 1 |. . . | 9 Erste. Ziffer 1 | 2 |. . . | 9
Beispiel: ZR – eine Sprache für einen Zeichenroboter 37 Automaten als Akzeptoren für Sprachen Akzeptor prüft, ob ein Wort zur Sprache gehört oder nicht. (Keine Ausgabe Wort akzeptiert) (Thema: Programmiersprachen und Syntaxfehler) Wir nehmen zwei Ausschnitte aus den Produktionen: Zahl Ziffern Ziffer Erste. Ziffern Ziffern | EPSILON 0 | 1 |. . . | 9 1 | 2 |. . . | 9 Anweisungen Anweisungen | EPSILON VW Zahl | WH Zahl [ Anweisungen ]
Beispiel: ZR – eine Sprache für einen Zeichenroboter 38 Kleiner Sprachausschnitt: Zahl Erste. Ziffern Ziffern | EPSILON Ziffer 0 | 1 |. . . | 9 Erste. Ziffer 1 | 2 |. . . | 9
Beispiel: ZR – eine Sprache für einen Zeichenroboter 39
Beispiel: ZR – eine Sprache für einen Zeichenroboter 40
Beispiel: ZR – eine Sprache für einen Zeichenroboter 41 Anweisungen | EPSILON Anweisung VW n | WH n [ Anweisungen ] DKA für obigen Grammatik-Ausschnitt
Beispiel: ZR – eine Sprache für einen Zeichenroboter 42 Aus der Kombination von kleinen endlichen Automaten und einem Kellerautomaten wird später unser Compiler bestehen. Für EA-Sprachen können auch reguläre Ausdrücke verwendet werden: Beispiel Zahl (nicht 0, ohne Vornullen): [1 -9][0 -9]*
Arbeitsweise des Compilers 43 Quelltext in ZR Scanner Tokenliste Parser Ausgabe in Zielsprache
Arbeitsweise eines Scanners 44 Ein- und Ausgabe des Scanners: Quelltext in ZR Quelltext besteht aus Zeichen und der Rechner weiß noch nicht wie diese zusammengehören. Scanner Viele kleine endliche Automaten entscheiden welche Schlüsselworte im Quelltext stehen. Tokenliste Token als Paare [Tokenname, Lexem] z. B. : [Wiederhole, "WH"] [Zahl, "12"] [Klammer. Auf, "["]
Beispiel: ZR – eine Sprache für einen Zeichenroboter 45 Programm Anweisungen | EPSILON Anweisung VW Zahl | RE Zahl | WH Zahl [ Anweisungen ] | FARBE Farbwert | STIFT Zahl Farbwert : rot|blau|gruen|gelb|schwarz Zahl : [1 -9][0 -9]*
Reguläre Grammatik NEA DEA 46 farbwert. txt
Beispiel: ZR – eine Sprache für einen Zeichenroboter 47 Endliche Automaten (Reg. Exp) für alle unsere Terminale: Klammer. Auf : [ Klammer. Zu : ] Wiederhole : WH Rechts : RE Vor : VW Stift : STIFT Farbe : FARBE Farbwert : rot|blau|gruen|gelb|schwarz Zahl : [1 -9][0 -9]* S, T, I, F, T
Beispiel: ZR – eine Sprache für einen Zeichenroboter 48
Beispiel: ZR – eine Sprache für einen Zeichenroboter 49 per Hand ergänzen
Arbeitsweise des Parsers 50 Ein- und Ausgabe des Parsers: Tokenliste Parser #true oder (#false) Beinhaltet die aufgetretenen Terminale der Grammatik des Parsers Grammatik von ZR in Form eines Kellerautomaten Prüft ob Wort zur Sprache gehört #false erfolgt meinst durch Ausgabe von „Syntax Error“
Beispiel: ZR – eine Sprache für einen Zeichenroboter 51 Entwicklung des ZR 2 PS Compilers in VCC Übertragen der EA in die Scannerdefinition Übertragen der vereinfachten Grammatik in die Parserdefinition Entwickeln sogenannter S-Attribute für die Zielcodegenerierung
Beispiel: Postscript als Zielsprache des ZR-Compilers 52 ZR PS PDF Eingabewort (in ZR): WH 36 [WH 4 [VW 100 RE 90] RE 10] Ausgabewort (in PS): %!PS-Adobe-2. 0 /orient 0 def /xpos 0 def /ypos 0 def 0 0 0 setrgbcolor /goto { /ypos exch def /xpos exch def xpos ypos moveto} def /turn { /orient exch orient add def} def /draw { /len exch def newpath xpos ypos moveto /xpos orient sin len mul add def /ypos orient cos len mul add def xpos ypos lineto stroke } def 300 400 goto 100 draw 90 turn 100 … turn 10 turn
Beispiel: ZR – eine Sprache für einen Zeichenroboter 53 Zielcodegenerierung: Der Compiler soll Post. Script erstellen nicht nur #true und #false ausgeben. Entwicklung von S-Attributen S-Attribute sind kleine Quelltextfragmente die für jede rechte Regelseite definiert werden können. Wird eine Regel angewendet wird auch das entsprechende Quellcodefragment ausgeführt.
Beispiel: ZR – eine Sprache für einen Zeichenroboter 54 Die Platzhalter $1 bis $n: In S-Attributen verwenden wir Platzhalter für die Ergebnisse der einzelnen Regelbausteine. Eingabewort sei: VW 20 RE 10 $1 $2 VW 20 $$ = "20 draw " Ø Von einem Token ist $n immer des Lexem des Tokens ! Ø Von einem Nichtterminal ist $n immer das Ergebnis $$ des Nichtterminals !
Beispiel: ZR – eine Sprache für einen Zeichenroboter 55 Die Platzhalter $1 bis $n: In S-Attributen verwenden wir Platzhalter für die Ergebnisse der einzelnen Regelbausteine. Eingabewort sei: WH 4 [ VW 20 ] $1 $2 $3 $4 $5 WH 4 [ 20 draw ] $$ = "20 draw " Ø Von einem Token ist $n immer des Lexem des Tokens ! Ø Von einem Nichtterminal ist $n immer das Ergebnis $$ des Nichtterminals ! Ø Alle $n und $$ sind vom Datentyp String !!!
Arbeitsweise des Compilers 56 [Wiederhole, "WH"] [Zahl, "12"] [Klammer. Auf" "["] … WH 36 [WH 4 [VW 100 RE 90] RE 10] Quelltext in ZR Scanner Tokenliste %!PS-Adobe-2. 0 /orient 0 def /xpos 0 def /ypos 0 def 0 0 0 setrgbcolor /goto { /ypos exch def /xpos exch def xpos ypos moveto} def … Parser Ausgabe in Zielsprache Programm Anweisungen | Anweisung VW Zahl | RE Zahl | WH Zahl [ Anweisungen ] | FARBE Farbwert | STIFT Zahl
Beispiel: ZR – eine Sprache für einen Zeichenroboter 57 Anwenden des Compilers auf der Modellierungsebene der T-Diagramme in TDiag.
- Slides: 56