6 Zustandsorientierte Modellierung und imperative Programme

Transkript

1 6 Zustandsorientierte Modellierung und imperative Programme 6.1 Problematik An dieser Stelle stoßen wir auf eine sehr problematische Stelle in unserem Unterrichtskonzept: 4 Einerseits sind Grundkenntnisse ber die Funktionsweise imperativer Programme ein unverzichtbarer Baustein zum Verst ndnis der Funktionsweise elektronischer Informationsund Kommunikationssysteme. Diese Grundkenntnisse k nnen nur erfolgreich vermittelt werden, wenn die Sch lerinnen und Sch ler tats chlich selbst Programme schreiben, bersetzen lassen und deren Ablauf verfolgen k nnen. 4 Andererseits geh ren spezielle Kenntnisse ber die Syntax der dabei verwendeten konkreten Programmiersprache zu Klasse 4 in Bezug auf ihre Allgemeing ltigkeit und damit NICHT zum Kanon allgemeinbildender Lerninhalte. Ein reiner Programmierkurs muß also vermieden werden. 6.2 L sungsansatz Zur L sung dieses Problems schlagen wir vor, die Programmierung im Unterricht auf die Implementierung von Zustands - bergangsdiagrammen zu beschr nken. Damit kann sichergestellt werden, 4 dass das geplante System vor der eigentlichen Codierung einigermaßen sauber modelliert wird, 4 dass die behandelten Probleme in einem begrenzten Komplexit tsbereich bleiben: Einfache Syntaxspielereien ergeben triviale, sehr komplexe Aufgabenstellungen zu komplizierte Diagramme. ber die Automatensicht als Meta-Ebene erh lt man eine klare Systematik und eine intuitiv verst ndliche Semantik der einzelnen Sprachelemente. Das Programm stellt sich dann lediglich als Simulation des Ablaufs eines Modells dar. Der pr fungsrelevante Lernstoff beschr nkt sich auf die Erstellung von Zustands- bergangsdiagrammen und Grundkonzepte ihrer Umsetzung in Programme (z. B. Variablenkonzept). Auf keinen Fall darf die Kenntnis spezieller Syntaxelemente einer Programmiersprache eine Note beeinflussen. Merke: Wir wollen den Sch lern grundlegende Kenntnisse ber Informations- und Kommunikationssysteme beibringen. Wir wollen sie dabei NICHT zu Programmierern ausbilden! Insgesamt arbeiten wir im folgenden auf vier Abstraktionsebenen: Automaten-, Algorithmus- Programm- und Prozessebene. Diese Ebenen m ssen den Sch lern stets klar vor Augen gef hrt werden. Zustands- bergangsdiagramm Algorithmus Programm Prozess Insbesondere sollen die Sch ler im folgenden erkennen, dass ein bestimmter Automat, ebenso wie ein Algorithmus oder ein Programm (abh ngig von den Eingaben) oft zahlreiche m gliche Abl ufe (Aktionsfolgen) aufweist. Ein Prozess repr sentiert dann einen realen Ablauf dieser abstrakten Konzepte. 6.3 Vorgeschichte Die Sch ler befinden sich etwa in der 10. JGSt. und haben einen berblick ber grundlegende Techniken der Repr sentation von Information hinter sich. Dabei haben sie einige wichtige Seite 1

2 Datenstrukturen und in umgangssprachlicher Form die Strukturelemente von Algorithmen (Sequenz, Auswahl, Wiederholung) kennengelernt. Bei der unmittelbar vorausgegangenen Behandlung der datenorientierten Modellierung haben wir uns die Sache etwas einfach gemacht und auf die Modellierung zeitlicher Abl ufe verzichtet. Bei der Betrachtung der Problematik von Transaktionen wurde dann offensichtlich, daß wir eine Methode ben tigen, um zeitliche Abl ufe exakt beschreiben zu k nnen. Dazu eignen sich Zustands- bergangsdiagramme besonders gut. 6.4 Zustands- bergangsdiagramme Diese Beschreibungstechnik abstrahiert reale, kontinuierliche zeitliche Abl ufe, indem sie einzelne Abschnitte ihres zeitlichen Verlaufs jeweils eine der beiden folgenden Kategorien einordnet: Relativ lang andauernde Zust nde (symbolisiert durch abgerundete Rechtecke), welche einen andauernden Vorgang und/oder einen konstanten Wert eines Attributs dargestellt werden und in verschwindend kurzen Zeitspannen ablaufende berg nge zwischen diesen Zust nden (symbolisiert durch Pfeile). Jeder Pfeil wird zumindest mit der Aktion, welche den jeweiligen bergang ausl st, markiert. Am Beispiel der Sperrung von Datens tzen oder Tabellen kann das in einfacher Weise veranschaulicht werden: Datensatz gesperrt Bearbeiter schließt Datensatz Bearbeiter ffnet Datensatz Alle Datens tze freigegeben Administratior startet Sortierverfahren Administratior beendet Sortierverfahren Tabelle gesperrt Abbildung 1: Datenbanksperren im Zustands- bergangsmodell Ger t bereit Abheben [keinfreizeichen] Auflegen [besetzt] Auflegen [Wartezeit zu lang] Auflegen App1: H rer abgehoben [Freizeichen] W hlbereit W hlen Phys. verbunden [frei] App2: Klingelt [App2 wird abgehoben] App2: H rer abgehoben Sprechbereit Zustand1 [Bedingung f r bergang] Ausl seaktion /ausgel ste Aktion/ Zustand2 Abbildung 2: Zustands- bergangsdiagramm einer Telefonverbindung Seite 2

3 Mit den bisher zur Verf gung stehenden Syntaxelementen k nnen wir allerdings nur endliche Automaten ohne Ausgabe modellieren. Um auch den Ablauf von Automaten mit Ausgabe, Kellerautomaten oder Turingmaschinen beschreiben zu k nnen, ben tigen wir zus tzlich weitere Notationsm glichkeiten. Am Beispiel des Aufbaus einer Telefonverbindung kann die Einf hrung bedingter berg nge (notiert durch die Bedingung in eckigen Klammern an der jeweiligen Transition) veranschaulicht werden (siehe Abbildung 2). Zus tzlich kann man als dritte Markierung (kursiv gesetzt) noch eine Aktion anbringen, welche durch den bergang ausgel st wird. 6.5 Beschreibung abstrakter Maschinen Als Hintergrundinformation f r Lehrkr fte soll hier kurz dargestellt werden, wie man den Ablauf diverser Typen abstrakter Maschinen mit Hilfe der oben eingef hrten Zustandsbergangsdiagramme beschreiben kann. Wir halten uns an die oben eingef hrte Notation (siehe Abbildung 1). Zustand Z 1 Zustand Z 2 / Abbildung 3: Notation der Zustands- bergangsdiagramme Auf dieser Grundlage stellen wir Argumente und Werte der Zustands- bergangsfunktion vom Zustand z 1 zum Zustand z 2 durch Tripel (A, B, G) dar. Die ausl sende Aktion ist in allen F llen die Eingabe eines Zeichens. Der Einfachheit halber schreiben wir kurz A = k statt A = "EINGABE = k". Mealy-Automat Der bergang von z 1 nach z 2 als Reaktion auf die Eingabe a mit gleichzeitiger Ausgabe b: (z 2, b) (z 1, a) (A, B, G) = (a, _, b) Kellerautomat Als (nicht dargestellte) Hilfsdatenstruktur stellen wir uns einen Keller mit unendlicher Kapazit t vor, der mit Zeichen aus dem Alphabet K bef llt werden kann. Ein Zeichen aus K dient als Kellerbegrenzer. Darauf sollen die Funktionen PUSH() und POP() in der blichen Weise definiert sein. Der bergang z 1 z 2 bei Eingabe von a und oberstem Kellersymbol k mit gleichzeitigem Ablegen der Zeichenfolge w auf dem Keller sieht dann so aus: (z 2, w) (z 1, a, k) (A, B, G) = (a, IF POP() = k, PUSH(w)) Turingmaschine Als Hilfsdatenstruktur verwenden wir ein unendlich langen Band mit linear angeordneten Zeichen aus einem Alphabet T vor. Eines dieser Zeichen wird als Leerzeichen verwendet. Die von der Eingabe a ausgel ste Transition mit Schreiben (WRITE) von b und anschließender Bewegung (MOVE) des Schreib-Lesekopfes in Richtung c {,, } schreibt sich als (z 2, b, c) (z 1, a) (A, B, G) = (a, _, WRITE b; MOVE c). Seite 3

4 Der Strichpunkt trennt dabei die Aktionen innerhalb von Aktionssequenzen. 6.6 Ein Veranschaulichungsbeispiel Nun sind wir in der Lage, einfache reale Automaten mit Hilfe von Zustandsbergangsdiagrammen zu beschreiben. Der Getr nkeautomat in der Aula der Schule k nnte etwa das Diagramm aus Abbildung 4 liefern. Initialisieren Aus Strom Einschalten Strom Ausschalten Initial Abbruchtaste /Geld zur ck Abbruchtaste /Geld zur ck 5DM,1DM,0.5DM Ausgabe /Getr nk ausgeben, Restgeld zur ck Getr nk gew hlt Limo, Cola [Eingabe >= 1.50 DM] Geld erhalten Limo, Cola 5DM,1DM,0.5DM Abbildung 4: Ein Getr nkeautomat Zielangabe: Nun wollen wir diesen Automaten mit Hilfe eines Rechners simulieren. Dazu m ssen wir uns vorher einige Grundkenntnisse ber imperative Programmierung aneignen. 6.7 Algorithmen und Programme Neben den Zustands- bergangsdiagrammen stellen Algorithmen eine alternative Methode zur Beschreibung zeitlicher Abl ufe dar. Ihre Grundelemente haben wir bereits fr her kennengelernt. Hier zur Erinnerung nochmals eine Definition des Begriffs (aus Broy 1992): Ein Algorithmus ist ein Verfahren mit einer pr zisen (d.h. ineiner genau festgelegten Sprache abgefaßten) endlichen Beschreibung unter Verwendung effektiver (d.h. tats chlich ausf hrbarer) Verarbeitungsschritte. Als Sprache kann dabei ein (pr zisierter) Ausschnitt der nat rlichen Sprache ebenso wie synthetische formale Sprachen verwendet werden. Unter letztere Kategorie fallen Programmiersprachen wie Pascal, C, C++, Java. Seite 4

5 Ein Programm ist nichts anderes als die (hoffentlich) exakte Formulierung eines Algorithmus in einer speziellen Sprache. Die einzelnen Verarbeitungsschritte werden (in imperativen Programmiersprachen) in Form von Anweisungen oder Befehlen formuliert. Mit Hilfe eines Programms k nnen wir den Ablauf eines Zustands- bergangsmodells auf einem Rechner simulieren. Ein Beispiel f r einen Algorithmus: Falls Nagel und Hammer vorhanden Stecke den Nagel mit der Hand senkrecht zur Oberfl che ins Holz Nimm den Hammer in die rechte Hand Wiederhole bis der Kopf des Nagels das Holz ber hrt Schlage mit dem Hammer parallel zur Nagelachse auf den Nagelkopf Falls der Nagel seitlich ausweicht Biege ihn wieder gerade Hier erkennt man bereits, daß die Forderung nach Pr zision nicht leicht zu erf llen ist. Auch die Frage, wann Ausf hrungsschritte elementar sind, ist nicht immer leicht zu beantworten. Es ist jedoch leicht zu erkennen, daß Algorithmen einige wenige grundlegende Strukturelemente aufweisen: Sequenzen (Folgen von Verarbeitungsschritten) Alternativen (Wenn, dann, Falls...) Wiederholungen (Wiederhole bis...) Man nennt diese Strukturelemente auch Kontrollstrukturen, da sie den Ablauf des Handlungsgeschehens kontrollieren. 6.8 Zust nde und Variable Wenn wir die Abl ufe, welche durch Zustands- bergangsdiagramme beschrieben werden, durch Programme simulieren wollen, ben tigen wir ein Hilfsmittel zur Simulation der Zust nde. Daf r verwendet man in der Programmiertechnik Variable. Das sind mit einem Namen versehene Container, die verschiedene Werte aus einem bestimmten Wertebereich (Sorte oder Typ) annehmen k nnen. Die Sch ler kennen bereits ein hnliches Konzept aus dem Datenbankbereich in Form der Attribute von Entit tsklassen. Ein Beispiel: Die Variable mit dem Namen Z hler soll als Container f r Sorte der nat rliche Zahlen dienen. Sie k nnte dann als Wert etwa die Zahl 12 enthalten. Der Name Variable kommt daher, daß dieser Wert ge ndert werden kann. 12 Z hler Andere Beispiele f r Variable: Name Wertebereich Inhalte z.b. Buchtitel Text (String) Fr ulein Smillas Gesp r f r Schnee, Faust Geburtsdatum Datum , Abteilung Zeichen (Character) 2, h, X, + Seite 5

6 Der Zusammenhang mit Zustands- bergangsdiagrammen wird hergestellt, indem man jedem Zustand wie in Abbildung 5 einen bestimmten Wert einer Variablen (oder sp ter eine Kombination von Werten mehrerer Variablen) zuordnet Erh hung von Z hler um 1 Z hler=1 Z hler=2 Z hler=3 Verminderung von Z hler um 1 Erh hung von Z hler um 1 Verminderung von Z hler um 1 Z hler:=1 Inhalt von Z hler nicht definiert Abbildung 5: Variablen und Zust nde berg nge werden durch Ver nderung des Wertes der jeweiligen Variable ausgel st: Der Variablen Z hler wird zum Beispiel der (ver nderte) Wert 1 zugewiesen. Wir schreiben daf r Z hler := 1. Eine solche Aktion heißt deswegen Zuweisung. Dieser Aktionstyp ist charakteristisch f r eine ganz bestimmte Art von Programmiersprachen, die sogenannten imperativen Programmiersprachen. Die Aktion Z hler := 1 muß streng von der Aussage Z hler = 1 unterschieden werden. Letztere sagt aus, dass die Variable Z hler gegenw rtig den Wert 1 hat. Diese Unterscheidung wird den Sch lern mit Hilfe der Zustands- bergangsdiagramme schnell klargemacht. 6.9 Imperative Programmierung Ein SQL-Abfrageprogramm f r eine relationale Datenbanken ist (im einfachsten Fall) eine Kombination von Kriterien, die beschreiben, welche Daten wir aus den betroffenen Tabellen extrahieren wollen. Im Gegensatz dazu besteht ein imperatives Programm aus einer Kombination von Befehlen oder Anweisungen, von jeder eine spezielle Aktion ausl st. Wir kennen bisher nur den Zuweisungsbefehl :=. Man kann imperative Programme als eine Folge von Zustandskombinationen der betroffenen Variablen ansehen. Der Zuweisungsbefehl sieht beispielsweise in Pascal folgendermaßen aus: Aktion Syntax Beispiel Wirkung Zuweisung <Variable> := <Term> Z hler := Z hler/3 Der Wert des Terms auf der rechten Seite des := wird berechnet und anschließend das Ergebnis der auf der linken Seite bezeichneten Variablen als Wert zugewiesen. Sequenzen von Befehlen Um eine Folge von Anweisungen hintereinander ausf hren zu k nnen, gibt es die M glichkeit, diese in Form einer Sequenz anzuordnen. In vielen Programmiersprachen werden an bestimmten Stellen, etwa innerhalb einer Auswahlanweisung (s.unten) nur einzelne Befehle zugelassen. In einem solchen Fall gibt es meist die M glichkeit, eine Sequenz von Befehlen mit Hilfe einer Sequenzklammer zu einem Befehl zusammenzufassen. In Pascal werden dazu die W rter begin und end verwendet. In C, C++ und Java verwendet man stattdessen die ge- Seite 6

7 schweiften Klammern { und }. Die einzelnen Befehle innerhalb der Sequenz werden oft (u.a. in Pascal) durch Strichpunkte voneinander getrennt. Ein m glicher Ablauf unseres Automaten aus Abbildung 5 w re dann etwa durch die folgende Pascal-Befehlsfolge festgelegt: z hler := 1; z hler := z hler+1; z hler := z hler+1; z hler := z hler-1; z hler := z hler-1; Hier ist allerdings Vorsicht geboten: diese Befehlsfolge repr sentiert NICHT den obigen Automaten, sondern nur einen seiner m glichen Abl ufe! Programme und Prozesse Nun erg nzen wir unsere Befehlssequenz zu einem vollst ndigen (wenn auch noch nicht sehr ergiebigen) Pascal-Programm: program Nummer1; var Z hler: Integer; begin z hler := 1; z hler := z hler+1; z hler := z hler+1; z hler := z hler-1; z hler := z hler-1; end. Programmdeklaration: Das Programm erh lt einen Namen Variablendeklaration: Die Container werden eingerichtet Beginn der Befehlsfolge Zuweisungsbefehl B1 Zuweisungsbefehl B2 Zuweisungsbefehl B3 Zuweisungsbefehl B4 Zuweisungsbefehl B5 Ende des Programms Der hier abgedruckte Text unseres ersten Programms Nummer 1 ist zun chst f r den Rechner nur ein Text wie jeder andere, etwa die Weihnachtsgr ße an Tante Emma. Um das Programm ausf hren zu k nnen, muß dieser erst durch ein speziell f r diesen Zweck konstruiertes anderes Programm (Compiler oder Interpreter) in eine Folge von ausf hrbaren Maschinenbefehlen (Maschinencode) bersetzt werden. Diese Befehle sind Kombinationen aus Nullen oder Einsen, z.b Sp ter werden wir mehr dar ber erfahren. Dieser Maschinencode wird dann im Hauptspeicher des Rechners oder als ausf hrbare Datei auf der Festplatte aufbewahrt, bis seine tats chliche Abarbeitung gestartet wird. Dann entsteht daraus ein aktiver Prozeß. Wir fassen die verwendeten Begriffe nochmals zusammen: Programm Formuleirung eines Algorithmus in einer bestimmten Programmiersprache, z.b. Pascal, Basic, C++, Java. Maschinencode Folge von Maschinenbefehlen, z.b , ,.. welche vom Rechner unmittelbar ausgef hrt werden k nnen. Prozeß Compiler Folge von Aktionen des Rechners bersetzungsprogramm, das vor dem Start des Prozesses den gesamten Programmtext in Maschinencode bersetzt Seite 7

8 Interpreter bersetzungsprogramm, die Befehle des Programmtextes einzeln bersetzt und sofort deren Ausf hrung startet. Der Ablauf eine Programm bersetzung durch einen Compiler l ßt sich wiederum mit einem Zustands- bergangsdiagramm (auf abstrakterer Ebene) beschreiben (siehe Abbildung 6). bersetzen/ Compilieren Programmtext Maschinencode Ausf hrung starten Prozeß Abbildung 6: Kompilierung uns Ausf hrung eines Programms 6.10 E/A-Automaten Ein System, das durch ein Zustands- bergangsdiagramm beschrieben werden kann, nennen wir Automat. Unser Automat aus Abbildung 5 hat gegenw rtig noch den unsch nen Nachteil, dass er nicht mit seiner Umgebung kommunizieren kann. In der Regel werden Automaten durch Eingaben, d.h. durch Signale aus ihrer Umgebung auf bestimmten Kan len, gesteuert. Aufgrund der Regeln des Zustands- bergangsdiagramms produzieren sie in Reaktion auf die Eingaben ganz bestimmte Ausgaben auf speziellen Ausgabekan len. Das Datenflußdiagramm eines Automaten in Abbildung 7 zeigt drei Eingabe- und zwei Ausgabekan le. Eingabekan le E/A Automat Ausgabekan le Abbildung 7: Kan le eines E/A-Automaten Es gibt in unserer Umgebung zahlreiche Maschinen, die auf diese Weise arbeiten, wie etwa Kaffee-, Getr nke oder Kaugummiautomaten. Ein Getr nkeautomat k nnte die folgenden Kan le aufweisen: Eingabekan le: Ausgabekan le: Netzschalter, Geldeinwurf, Getr nkewahltaste, R ckgabeknopf Netzsignall mpchen, Geldausgabe, Getr nkeausgabe In unserer imperativen Programmiersprache Pascal verwenden wird f r die Ein- und Ausgabe (u.a.) die folgenden Befehle: Aktion Syntax Beispiel Wirkung Eingabe readln(<variablenname>) readln(z hler); die Eingabe von der Tastatur bis zum Bet tigen der return-taste Seite 8

9 wird der genannten Variable als Wert zugewiesen. Ausgabe writeln(<term>) writeln(z hler+1) Der Wert des Terms wird am Bildschirm ausgegeben. Im Zustands- bergangsdiagramm von E/A-Automaten sind die Ausl seaktionen f r berg nge in der Regel Eingaben. Zur Vereinfachung notieren wir dann an den bergangspfeilen oft nur die Eingabewerte, nicht mehr die gesamte Aktion. Wir schreiben also nur noch Cola anstatt Auswahlknopf f r Cola bet tigt. Wir reichern unser obiges Programm 1 mit einem Eingabe- und einem Ausgabebefehl an... readln (z hler);.. writeln(z hler); 6.11 Variablenzust nde Bei Verwendung mehrerer Variablen beschreibt wird ein Ablauf eines Programms durch eine Spur im Zustandsraum beschrieben. Dieser Raum wird durch die Variablen aufgespannt, wobei jede Variable eine Dimension beitr gt. Wir betrachten ein kleines Programm2 mit zwei Variablen: begin Z hler :=3; Nenner :=2; Z hler := Z hler +1; Nenner := 2*Nenner; Z hler := Z hler/nenner; end. Zuweisungsbefehl B1 Zuweisungsbefehl B2 Zuweisungsbefehl B3 Zuweisungsbefehl B4 Zuweisungsbefehl B5 Das Zustands- bergangsdiagramm dieses Programms sieht dann folgendermaßen aus: Z hler=3 Nenner n. def B2: Nenner:=1 Z hler=3 B3: Z hler:=z hler+1 Nenner=2 Z hler=4 Nenner=2 B1: Z hler:=1 B4: Nenner:=2*Nenner Z hler n. def, Nenner n.def Z hler=1 Nenner=4 B5: Z hler:=z hler/nenner Z hler=4 Nenner=4 Abbildung 8: Programm 1 im Zustands- bergangsdiagarmm Der Ablauf des Programms Nr. 2 f hrt zur folgenden Spur im zweidimensionalen Zustandsraum: Seite 9

10 nenner n. def Z 0 Z 1 nenner = 1 nenner = 2 nenner = 3 nenner = 4 nenner = 5 Z 5 Z 2 Z 3 Z 4 Zustandsr ume von Programmen mit mehr als drei Variablen sind offensichtlich nicht mehr grafisch darstellbar Modellzust nde Unser Ziel ist es, mit Hilfe von Zustands- bergangsdiagrammen reale oder geplante Systeme zu modellieren und diese Modelle dann mit Hilfe einer Programmiersprache zu simulieren. Bei der Erstellung von zustandsorientierten Modellen f hrt die Auffassung von Zust nden als Punkte eines mehrdimensionalen Zustandsraumes meist zu einem un bersichtlichen Gewirr von Zust nden, in dem die wesentlichen Aspekte des Systems untergehen. Man faßt deshalb oft eine Menge von Punkten (einen Unterraume ) des eigentlichen (Variablen-)Zustandsraums zu einem (Modell-) Zustand zusammen. Wir werden im folgenden also zwischen Variablenund Modellzust nden unterscheiden m ssen. Dieses Vorgehen hat zur Konsequenz, dass man f r jeden Zustand eine signifikante Variable zu seiner Definition ben tigt. Bei unserem Getr nkeautomaten werden im Modellzustand Geld erhalten viele Variablenzust nde der Variablen Geldeingabe zusammengefaßt Bedingte berg nge Bisher haben wir nur den Ablauf von Automaten simuliert, deren Zust nde jeweils einem Punkt im Variablen-Zustandsraum entsprachen. In diesem Fall f hrt jede Zuweisung eines ver nderten Wertes an irgendeine Variable automatisch zur nderung des Zustandes. Bei Modellzust nden gilt das unter Umst nden nicht mehr, n mlich dann, wenn der Wert einer f r den Zustand irrelevanten Variablen ver ndert wird, etwa der Wert von Geldeingabe im Zustand Geld erhalten bei unserem Getr nkeautomaten. Wir ben tigen daher ein Sprachmittel, das uns bedingte berg nge erlaubt nach dem Schema: "Falls eine bestimmte Variable in bestimmter Weise ver ndert wird, gehe zu Zustand..". Eine solche Anwesiung heißt bedingte Bedingte Anweisung Ein Beispiel f r eine bedingte Anweisung (ohne Alternative) w re bei unserem Getr nkeautomaten die Steuerung des bergangs zwischen dem Zustand Aus und dem Zustand Ein durch Eingabe des Steuersignals Strom einschalten. Aus einschalten Initial Abbildung 9: Einfache Auswahl Seite 10

11 In Pascal: Aktion Syntax Beispiel Wirkung bedingte Anweisung If <Bedingung> then <Anweisung> if Eingabe = einschalten then Zustand := Ein Falls <Bedingung> wahr ist, wird die <Anweisung> ausgef hrt. Ansonsten wird zum n chsten Befehl nach der Auswahlanweisung bergegangen. Zur Veranschaulichung solcher Konstrollstrukturen kann man Ablaufpl ne (Kontrollflussdiagramme) einsetzen. Start <Bedingung> wahr Anweisung falsch Stop Abbildung 10: Ablaufplan f r eine bedingte Anweisung Bedingte Anweisung mit (Standard-)Alternative Eine typische Anwendung von Standardalternativen sind Reaktionen auf fehlerhafte Eingaben. Am Beispiel einer Division kann das veranschaulicht werden: Aktion Syntax Beispiel Wirkung einfache Auswahl mit Standardalternative If <Bedingung> then <Anweisung1> else <Anweisung1> if nenner <> 0 then bruch:=z hler/nenner else writeln( FEHLER! ) Das zugeh rige Zustands- bergangsdiagramm findet sich in Abbildung 11. Falls <Bedingung> wahr ist, wird die <Anweisung1> ausgef hrt, ansonsten <Anweisung2>. Seite 11

12 z hler = 5 bruch = 5/nenner z hler = 5 bruch n. def zahl eingeben [nenner <>0] /bruch := z hler/eingabe zahl eingeben [nenner = 0] /"FEHLER" ausgeben Fehlerzustand Abbildung 11: Einfache Auswahl mit Alternative Auch im Ablaufplan f r eine bedingte Anweisung kann man die Alternative eintragen: Start <Bedingung> falsch wahr <Anweisung1> <Anweisung2> Stop Abbildung 12: Ablaufplan f r bedingte Anweisung mit Alternative Fallunterscheidung Bei der Simulation von Automaten kommt man in den seltensten F llen ohne Fallunterscheidung aus, da es meist von einem Zustand aus mehrere Alternativen f r berg nge gibt. Wenn wir den Zustand Geld erhalten in unserem Getr nkeautomaten aus Abbildung 4 umsetzen wollen, haben wir folgende Alternativen f r berg nge von diesem Zustand aus: Eingabe Bedingung Endzustand Ausgabe M nze keine Geld erhalten keine Limo/Cola Eingabe >= 1.50 Getr nk gew hlt keine Abbruchtaste keine Initial Geld zur ck Leider kann in Pascal die Anweisung f r die mehrfache Auswahl nur mit Variablen eingesetzt werden, deren Wertemenge linear geordnet ist. Dazu geh ren Zeichen, ganze Zahlen, aber Seite 12

13 keine Gleitkommazahlen oder Texte (Strings). Deshalb m ssen wir die Eingaben durch einzelne Zeichen beschreiben: 5, 1 f r die M nzen 5DM, 1DM (50Pf lassen wir hier weg). l, c f r Limo und Cola a f r Abbruch. Damit kann man den bergang vom Zustand Geld erhalten aus in Pascal wie folgt beschreiben: program getraenke-teil; var zustand: String; eingabe: char; einnahme: Integer; begin.. case eingabe of 5 : einnahme:=einnahme+5; 1 : einnahme:=ennahme+1; l, c : if einnahme >= 2.5 then zustand:= Getr nk gew hlt a : begin zustand:= Initial ; ausgabe:=einnahme; else writeln / FEHLER! )... end. Die mehrfache Auswahl in Pascal sieht so aus: Aktion Syntax Wirkung mehrfahe Auswahl case <Ordinalvariable> of <Wert1>: <Anweisung1>; <Wert2>: <Anweisung2>;.. else <AnweisungAlt> Falls <Ordinalvariable> einen der aufgelisteten Werte annimmt, wird die dahinterstehende <Anweisung> ausgef hrt. Wird keiner der aufgelisteten Werte angenommen, kommt <AnweisungAlt> zur Ausf hrung. Die Standardalternative (else-zweig) kann weggelassen werden. Anstatt der Angabe von Werten k nnen auch Listen von Werten ( 5, 1, 0 ) oder Bereiche (2.. 8) angegeben werden. Seite 13

14 Start <Variable> = Wert 1 Wert 2 Wert 3 sonst <Anweisung1> <Anweisung2> <Anweisung3> <AnweisungAlt> Stop Abbildung 13: Fallunterscheidung 6.14 Wiederholungen Nun sind wir fast soweit, unsere Automaten simulieren zu k nnen. Unser einziges verbliebenes Problem besteht darin, daß der Automat wiederholt auf Eingaben reagieren sollte. Bisher k nnen wir nur einen einzigen bergang als Reaktion auf eine einzige Eingabe simulieren. Wir ben tigen also noch eine M glichkeit, Anweisungen zu wiederholen. Nat rlich muß diese Wiederholung abgebrochen werden k nnen, um Endlosschleifen zu vermeiden. Wir wollen solange wiederholen, als eine bestimmte Bedingung wahr ist. In Pascal gibt es zu diesem Zweck die while-anweisung: Aktion Syntax Beispiel Wirkung Wiederholung while <Bedingung> do <Anweisung> while zahl < 10 do begin writeln(zahl*zahl); zahl:=zahl+1; Solange die Bedingung wahr ist, wird die Anweisung ausgef hrt. Seite 14

15 Solange <Bedingung> wiederhole Anweisung Ende (des zu wiederholenden Blocks) Abbildung 14: Wiederholung Jetzt vef gen wir ber alle Hilfsmittel, un unseren Automaten aus Abbildung 4 simulieren zu k nnen. F r den ersten Versuch vereinfachen wir den Automaten noch ein wenig (siehe Abbildung 15 ): Strom aus stop (s) /Geld zur ck stop (s) stop (s) /Geld zur ck Initial (i) Abbruch /Geld zur ck Abbruch (a) /Geld zur ck Ausgabe (x) /Ware ausgeben, Restgeld zur ck 1,2,.5 bezahlt (b) [Eingabe >= Preis] 1,2,5 kassiert (k) [Eingabe< Preis] 1,2,5 Abbildung 15: Warenautomat Der Automat kann mit einem Netzschalter ein- und ausgeschaltet werden. Er akzeptiert Geldeinwurf, bis der festeingestellte Preis (z.b. 11DM) erreicht oder berschritten ist. Dann gibt er auf Befehl die Ware und das Wechselgeld aus Zus tzlich kann jeder Vorgang mit einem Abbruchknopf vorzeitig beendet werden. In diesem Fall wird die gesamte Einnahme wieder ausgegeben. Seite 15

16 Das folgende Pascal-Programm simuliert genau dieses Verhalten: program Automat; uses WinCrt; const preis = 11; var zustand: Char; eingabe: Char; einnahme: Integer; restgeld: Integer; power: String; begin zustand := i ;power := on ; while power = on do begin gotoxy(10,1);write( Eingabe: );eingabe:=readkey; Case zustand of i :begin einnahme := 0; Case eingabe of 1, 2, 5 :begin einnahme:= Ord(eingabe)-48;zustand := k ; s : power := off ; k :Case eingabe of 1, 2, 5 :begin einnahme:= einnahme+ord(eingabe)-48; if einnahme >= preis then zustand:= b ; a : begin restgeld := einnahme; zustand := i ; gotoxy(20,10);writeln( Restgeld:,restgeld); s : begin restgeld := einnahme; power := off ; gotoxy(20,10);writeln( Restgeld:,restgeld); b :Case eingabe of x : a : s : begin restgeld := einnahme-preis; zustand := i ; gotoxy(20,10);writeln( Restgeld:,restgeld); gotoxy(20,11);writeln( Warenausgabe:, KAUGUMMI! ); begin restgeld := einnahme;zustand := i ; gotoxy(20,10);writeln( Restgeld:,restgeld); begin restgeld := einnahme;power := off ; gotoxy(20,10);writeln( Restgeld:,restgeld); gotoxy(30,1);write( Einnahme:,einnahme); Seite 16

17 gotoxy(30,2);write( Zustand:,zustand); end. Wir erkennen darin sehr leicht die Struktur, die sich bei der Simulation von endlichen Automaten ergibt, n mlich eine Wiederholung, innerhalb derer sich eine Fallunterscheidung f r die Zust nde befindet, die wiederum in jeder Alternative je eine Fallunterscheidung f r die Eingaben enth lt. 1 A A A B 2 B B 3 Abbildung 16: Beispielautomat Solange weiter = WAHR 1 Zustand = 2 3 Eingabe = Eingabe = Eingabe = A B A B A B a; Zustand:=2 b; Zustand:=3 c; Zustand:=1 d; Zustand:=3 e; Zustand:=1 f; Zustand:=2 Abbildung 17: Simulation schematisch Seite 17

18 Wiederhole solange weiter = WAHR Falls Zustand = 1: Falls Eingabe = A: Aktion a; Zustand = 2 B: Aktion b; Zustand = 3 2: Falls Eingabe = A: Aktion c; Zustand = 1 B: Aktion d; Zustand = 3 3: Falls Eingabe = A: Aktion e; Zustand = 1 B: Aktion f; Zustand = Literatur Balzert H.: Lehrbuch der Software-Technik. Software-Entwicklung. Hedelberg, Berlin, Oxford. Spektrum, Akad. Verlag, 1996 Brauer W.: Automatentheorie. Teubner, Stuttgart, 1984) Broy M.: Informatik. Eine grundlegende Einf hrung, Teil I. Springer, Berlin Heidelberg, Horn C., Kerner I.O.(Hrsg.): Lehr- und bungsbuch Informatik. Band 1: Grundlagen und berblick, Band 3: Praktische Informatik. Fachbuchverlag Leipzig, Seite 18