Sprachen und Automaten Einsatz der Software AtoCC (Kurs: 07C404101) Fortbildungsveranstaltung des Staatlichen Schulamts Cottbus Sprachen und Automaten Einsatz der Software AtoCC (Kurs: 07C404101) Christian Wagenknecht, Michael Hielscher Cottbus, am 22.01.08

Das Wichtigste zuerst! Vielen Dank an Herrn Thomas Lösler.

Veranstaltungsort: Oberstufenzentrum I, 03044 Cottbus, Sielower Str. 10

TI-Inhalte in der Schulinformatik: Probleme und Chancen  Blick in die Lehrpläne verschiedener Bundesländer Bevor wir uns dem speziellen Thema der Fortbildung zuwenden, wollen wir es einordnen  TI-Inhalte in der Schulinformatik

Lehrplan  Ziele und Inhalte In den meisten Bundesländern sind ausgewählte Inhalte der TI Lehrplaninhalt der Sek. II: Nr.  Bundesland   Lehrplaninhalt (Lernbereich) Pflichtbestandteil 1 Baden-Württemberg Bereich der theoretischen Informatik (Automaten, Berechenbarkeit) nein 2 Bayern  3. Formale Sprachen (noch Entwurf)   3 Berlin  4.4 Sprachen und Automaten ja (auch GK) 4 Brandenburg Ja (auch GK) 5 Bremen  Grundlagen der Theoretischen Informatik (Automaten, formale Sprachen) 6 Hamburg  Formale Sprachen, endliche Automaten, Keller-automaten, Scanner, Parser, Ableitungsbaum nein  7 Hessen Formale Sprachen und Grammatiken Automaten, Fakultativ: Übersetzerbau 8 Mecklenburg-Vorpommern ja (auch GK)  9 Niedersachsen Eigenschaften endlicher Automaten Aspekte formaler Sprachen 10 Nordrhein-Westfalen Endliche Automaten und formale Sprachen 11 Rheinland-Pfalz Formale Sprachen und Automaten zur Sprachbeschreibung und Spracherkennung   ja (nur LK) 12 Saarland Automaten und formale Sprachen Fakultativ: Übersetzerbau 13 Sachsen  8 A: Formale Sprachen, Kellerautomat, Akzeptor 14 Sachsen-Anhalt 15 Schleswig-Holstein Automaten als mögliches Themengebiet 16 Thüringen Themenbereich 7.3: Einblick in formale Sprachen

TI-Inhalte in der Schulinformatik: Probleme und Chancen Blick in die Lehrpläne verschiedener Bundesländer Konkrete Inhalte

Lehrplanauszug Hessen 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 Registermaschine Turing- oder registerberechenbar Churchsche These Computer als universelle symbolverarbeitende Maschine Verhältnis Mensch-Maschine Fakultative Unterrichtsinhalte/Aufgaben: Übersetzerbau Scanner, Parser, Interpreter und Compiler z. B. Steuersprache für Roboter, LOGO, Plotter oder miniPASCAL

TI an Hochschulen – NICHTS für Schulen 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, ... ksS / 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) endlicher Automat GK Informatik f. Jahrgangsstufen 11 und 12, wird ab Schuljahr 2008/09 wirksam

Informatik-Lehrplan: S II, Brandenburg gemeinsames Kerncurriculum mit Berlin und MeckPomm = Basis für schulinterne Lehrpläne 1. Auflage: 2006, gültig für Qualifizierungsphase ab Schuljahr 2008/9

Kompetenzerwerb im Themenfeld (Auszug) 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 LehrerInnen werden's schon machen!

Abbildung der Kompetenzbereiche auf Kurshalbjahre Klassen 11 und 12 (Qualifikationsphase): 4 Kurshalbjahre 3-5 Stunden pro Kurshalbjahr

TI-Inhalte in der Schulinformatik: Probleme und Chancen 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 "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 Zeit-Problem, Inhalte-Problem (Zusammenfassung von oben) Manche Lehrende mögen es nicht. – Motivationsproblem  Manche Lehrende können es nicht richtig. - Qualifikationsproblem  SchülerInnen/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 in Schulen: diverse Simulationstools oder Lernumgebungen, wie Kara; meist von enthusiastischen LehrerInnen 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 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) "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) 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)

Lern- und Arbeitsumgebung für TI: Anforderungen (2/2) Selbstverantwortetes Lernen und Lerntyp- Bezug durch Angebot alternativer Arbeits- und Beschreibungsformen Binnendifferenzierung durch erweiterbare Aufgabenstellungen Beiträge des Lernenden durch Formulierung von Aufgabenstellungen/Musterlösungen Dokumentation der Arbeitsergebnisse mit hohe Darstellungsqualität

Modellierung des Übersetzungsprozesses mit "ausführbaren" T-Diagrammen AtoCC - Vom abstrakten Automaten zur automatisierten Entwicklung von Sprachübersetzern Typische Kopplung von Automatentheorie mit Aspekten des Compilerbaus (s. Lehrpläne) Wichtige didaktische Entscheidung: Zielsprache sollte nicht Maschinencode sein!! ein enger Bezug der Herstellung eines Sprachübersetzers zu den theoretischen Grundlagen erfordert hohe Abstraktion Modellierung des Übersetzungsprozesses mit "ausführbaren" T-Diagrammen Gekürzte Punkte: Visualisierung und deskriptives Vorgehen bei der Compilerentwicklung mit VCC automatisierte Umsetzung in lauffähigen Compiler Übersetzungsprozess im T-Diagramm = Rückkehr zur Modellierungsebene

Unsere Ziele Belastbare Motivation für TI-Inhalte durch herausfordernde Start-Fragestellung mit Praxisrelevanz und Modellierung eines Zielsystems (Sprachübersetzer) am Anfang Vermittlungs-/Anwendungszyklen für TI-Wissen mit Projekt- bezug (Praxis nicht als "Anhängsel" zur Theorie) Komplexe Anwendung von TI-Inhalten auf sehr hohem Abstraktionsniveau (automatisierte Compiler-Generierung), Rückkehr zur und Konkretisierung der Modellierungsebene Behauptung: Dabei ist AtoCC ein unverzichtbares Hilfsmittel.

Beispiel: ZR – eine Sprache für einen Zeichenroboter Installationshinweise: Installieren Sie .NET Framework 2.0 oder höher (unter www.atocc.de  Fortbildung  Software) Installieren Sie GhostScript 8.60 Installieren Sie „AtoCC Setup.exe“ Wenn nicht vorhanden einen PDF Reader (Adobe Reader oder Foxit Reader) installieren. (Wenn noch nicht vorhanden MSXML 4 oder 6 installieren. Downloadseite wird von AutoEdit automatisch beim ersten Start geöffnet, wenn dies fehlen sollte.)

Beispiel: ZR – eine Sprache für einen Zeichenroboter 24 Praxisnahe (echte!) Aufgabe mit grafischer Ausgabe: Entwickeln Sie einen Compiler, der die Sprache ZR (ZeichenRoboter) in PDF übersetzt. (Schülergerecht formulieren!) 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 xpos orient sin len mul add def /ypos ypos orient cos len mul add def xpos ypos lineto stroke } def 300 400 goto 100 draw 90 turn 100 … turn 10 turn 24

Beispiel: ZR – eine Sprache für einen Zeichenroboter 25 Weiterer Ablauf: Modellierung der Problemlösung mit TDiag Syntax-Definition von ZR: formale Grammatik, Ableitungsbaum mit kfGEdit Parser  Akzeptoren  Automatenmodelle (EA, KA) mit AutoEdit Arbeitsteilung: Scanner, Parser Zielsprachenbezug  automatisierte Compiler-Entwicklung mit VCC Teilsysteme werden in Modellierung eingebracht (TDiag) Ergebnis: lauffähiger (nichttrivialer) Übersetzer, den man benutzen kann! TDiag, kfGEdit, AutoEdit, und VCC sind Bestandteile von AtoCC. 25

Beispiel: ZR – eine Sprache für einen Zeichenroboter Wir wollen zunächst den Compilerprozess entwerfen. (Modellierung) Verwendung von T-Diagrammen: T-Diagramme bestehen aus 4 Bausteintypen. Compilerbaustein, Programmbaustein, Interpreterbaustein und Ein/Ausgabe-Baustein Ein/Ausgabe an Programmbaustein Compiler Programm Interpreter

Beispiel: ZR – eine Sprache für einen Zeichenroboter Entwerfen eines T-Diagramms für Zeichenroboter Compiler: ZR2PS werden wir entwickeln, PS2PDF und Acrobat Reader wird vom System bereitgestellt.

Beispiel: ZR – eine Sprache für einen Zeichenroboter Nachdem wir nun wissen, wie unser Compiler später eingesetzt werden soll, wenden wir uns der Entwicklung des Compilers zu. Sprache näher betrachten Terminale und Nichterminale festlegen formale Grammatik definieren Ableitungsbäume erzeugen

Beispiel: ZR – eine Sprache für einen Zeichenroboter Betrachten wir die Sprache ZR und versuchen wir ihren Aufbau zu beschreiben: VW 50 RE 270 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 Beschreiben wir den Baustein Zahl genauer: 0 soll keine Zahl in ZR sein, da VW 0 oder RE 0 keine Veränderung herbeiführen. Vorangestellte Nullen wie 0815 wollen wir auch nicht erlauben. Ergänzen wir unsere Grammatik um: Zahl  ErsteZiffer Ziffern Ziffern  Ziffer Ziffern |  Ziffer  0 | 1 | ... | 9 ErsteZiffer  1 | 2 | ... | 9

Beispiel: ZR – eine Sprache für einen Zeichenroboter

Beispiel: ZR – eine Sprache für einen Zeichenroboter

Beispiel: ZR – eine Sprache für einen Zeichenroboter

Beispiel: ZR – eine Sprache für einen Zeichenroboter Programm  Anweisungen Anweisungen  Anweisung Anweisungen | EPSILON Anweisung  VW Zahl | RE Zahl | WH Zahl [ Anweisungen ] | FARBE Farbwert | STIFT Zahl Farbwert  rot | blau | gruen | gelb | schwarz Zahl  ErsteZiffer Ziffern Ziffern  Ziffer Ziffern | EPSILON Ziffer  0 | 1 | ... | 9 ErsteZiffer  1 | 2 | ... | 9

Beispiel: ZR – eine Sprache für einen Zeichenroboter 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  ErsteZiffer Ziffern Ziffern  Ziffer Ziffern | EPSILON Ziffer  0 | 1 | ... | 9 ErsteZiffer  1 | 2 | ... | 9 Anweisungen  Anweisung Anweisungen | EPSILON Anweisung  VW Zahl | WH Zahl [ Anweisungen ]

Beispiel: ZR – eine Sprache für einen Zeichenroboter Kleiner Sprachausschnitt: Zahl  ErsteZiffer Ziffern Ziffern  Ziffer Ziffern | EPSILON Ziffer  0 | 1 | ... | 9 ErsteZiffer  1 | 2 | ... | 9

Beispiel: ZR – eine Sprache für einen Zeichenroboter

Beispiel: ZR – eine Sprache für einen Zeichenroboter Anweisungen  Anweisung Anweisungen | EPSILON Anweisung  VW n | WH n [ Anweisungen ]

Beispiel: ZR – eine Sprache für einen Zeichenroboter

Beispiel: ZR – eine Sprache für einen Zeichenroboter Aus der Kombination von kleinen endlichen Automaten und einem Kellerautomat wird später unser Compiler bestehen. Für DEA-Sprachen können auch reguläre Ausdrücke verwendet werden: Beispiel Zahl: [1-9][0-9]*

Arbeitsweise des Compilers Quelltext in ZR Scanner Tokenliste Parser Ausgabe in Ziel-sprache

Arbeitsweise eines Scanners Quelltext in ZR Scanner Tokenliste Ein- und Ausgabe des Scanners: Quelltext besteht aus Zeichen und der Rechner weiß noch nicht wie diese zusammengehören. Viele kleine endliche Automaten entscheiden welche Schlüsselworte im Quelltext stehen. Token als Paare [Tokenname, Lexem] z.B.: [Wiederhole, "WH"] [Zahl, "12"] [KlammerAuf, "["]

Beispiel: ZR – eine Sprache für einen Zeichenroboter Programm  Anweisungen Anweisungen  Anweisung 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]*

Beispiel: ZR – eine Sprache für einen Zeichenroboter Endliche Automaten (RegExp) für alle unsere Terminale: KlammerAuf : \[ KlammerZu : \] Wiederhole : WH Rechts : RE Vor : VW Stift : STIFT Farbe : FARBE Farbwert : rot|blau|gruen|gelb|schwarz Zahl : [1-9][0-9]*

Beispiel: ZR – eine Sprache für einen Zeichenroboter

Beispiel: ZR – eine Sprache für einen Zeichenroboter Demo: zr-verkuerzt.exe –t zr-input.txt ggf. auch einen Syntaxfehler (in zr-input.txt) zeigen per Hand ergänzen

Arbeitsweise des Parsers Tokenliste Parser #true oder (#false) Ein- und Ausgabe des Parsers: 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 Entwicklung des ZR2PS 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: ZR – eine Sprache für einen Zeichenroboter Zielcodegenerierung: Der Compiler soll PostScript 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 Die Platzhalter $1 bis $n: In S-Attributen verwenden wir Platzhalter für die Ergebnisse der einzelnen Regelbausteine. Eingabewort sei: VW 20 RE 10 Eingabewort sei: VW 20 RE 10 $1 $2 Von einem Token ist $n immer des Lexem des Tokens ! Von einem Nichtterminal ist $n immer das Ergebnis $$ des Nichtterminals ! VW 20 $$ = "20 draw "

Beispiel: ZR – eine Sprache für einen Zeichenroboter 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 ] Von einem Token ist $n immer des Lexem des Tokens ! Von einem Nichtterminal ist $n immer das Ergebnis $$ des Nichtterminals ! $$ = "20 draw 20 draw 20 draw 20 draw " Alle $n und $$ sind vom Datentyp String !!!

Arbeitsweise des Compilers Quelltext in ZR Scanner Tokenliste Parser Ausgabe in Ziel-sprache %!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 … [Wiederhole, "WH"] [Zahl, "12"] [KlammerAuf" "["] … WH 36 [WH 4 [VW 100 RE 90] RE 10] Programm  Anweisungen Anweisungen  Anweisung Anweisungen |  Anweisung  VW Zahl | RE Zahl | WH Zahl [ Anweisungen ] | FARBE Farbwert | STIFT Zahl

Beispiel: ZR – eine Sprache für einen Zeichenroboter Anwenden des Compilers auf der Modellierungsebene der T-Diagramme in TDiag.