Ein O-O Design Beispiel. Ein Reservierungs-Panel. Das Übergangs-Diagramm. Programmierung im Grossen Bertrand Meyer Vorlesung 19

Transkript

1 Programmierung im Grossen Bertrand Meyer Vorlesung 9 Ein O-O Design Beispiel Letzte Aktualisierung: 8. Juni 004 Ein Reservierungs-Panel -- Enquiry on Flights -- Flight sought from: Santa Barbara Departure on or after: 3 June Preferred airline (s): Special requirements: To: Zurich On or before: 4 June AVAILABLE FLIGHTS: Flt#AA 4 Dep 8:5 Arr 7:45 Thru: Chicago Choose next action: 0 Exit Further enquiry 3 Reserve a seat Das Übergangs-Diagramm Initial 3 3 Confirmation Enquiry_on _flights Reservation Enquiry_on _seats 3

2 Ein erster Versuch PEnquiry_on_flights: output enquiry on flights screen repeat read user s answers and his exit choice C if error in answer then output message until no error in answer process answer inspect C when C0 then goto Exit when C then goto P... when Cm- then goto PReservation... (und ähnlich für jeden Zustand) 4 Was ist mit dem Schema falsch? Komplizierte Verzweigungs-Struktur ( spaghetti bowl ). Erweiterungs-Probleme: Dialog-Struktur in der Programm-Struktur codiert. 5 Eine funktionale, top-wn Lösung Für mehr Flexibilität, stelle die Struktur des Übergangs- Diagramms durch eine Funktion transition (i, k) dar. Diese wird verwet, um das Übergangs-Diagramm, das einer bestimmten interaktiven Anwung zugeordnet ist, zu spezifizieren. Die Funktion transition kann durch eine Datenstruktur, zum Beispiel ein zwei-dimensionales Array, implementiert werden. 6

3 Die Funktion transition 0 (Initial) () (Conf.) 3 (Reserv.) 4 (Seats) 5 (flights) 0 3 Exit Exit Exit Exit Exit Return Das Übergangs-Diagramm Initial 3 3 Confirmation Enquiry_on _flights Reservation Enquiry_on _seats 8 Neue System-Architektur Level 3 session Level initial transition is_final Level display read correct message process 9 3

4 Neue System-Architektur Prozedur session definiert nur die Graphen-Übergänge. Weiss nichts über die einzelnen Schirme einer Anwung. Sollte die selbe für alle Anwungen sein. session is -- Execute full session local current_, choice: INTEGER current_ := initial repeat choice := (current_) current_ := transition (current_, choice) until is_final (current_) 0 Um eine Anwung zu Beschreiben Gib transition Funktion Definiere initial Zustand Definiere is_final Funktion Aktionen in einem Zustand (current_: INTEGER): INTEGER is -- Actions for current_, returning user s exit choice. local answer: ANSWER good: BOOLEAN choice: INTEGER repeat display (current_) [answer, choice] := read (current_) good := correct (current_, answer) if not good then message (current_, answer) until good process (current_, answer) return choice 4

5 Spezifikation der übrigen Routinen display (s) gibt den Schirm für Zustand s zurück. [a, e] := read (s) liest nach a die Benutzerantwort auf den Schirm von Zustand s und nach e die Ausgangs-Wahl des Benutzers. correct (s, a) liefert true dann und nur dann, wenn a eine korrekte Antwort auf die in Zustand s gestellte Frage ist. Falls so, verarbeitet process (s, a) die Antwort a. Falls nicht, gibt message (s, a) die passe Fehlermeldung aus. 3 Objekt- Orientiert: Das Gesetz der Inversion Wie offen ist diese Lösung für Veränderungen und Adaptionen? Neue Transitionen? Neue Zustände? Neue Applikationen? Routine Signaturen: (: INTEGER): INTEGER display (: INTEGER) read (: INTEGER): [ANSWER, INTEGER] correct (: INTEGER; a: ANSWER): BOOLEAN message (: INTEGER; a: ANSWER) process (: INTEGER; a: ANSWER) is_final (: INTEGER) 4 Objekt- Orientiert: Das Gesetz der Inversion Wie offen ist diese Lösung für Veränderungen und Adaptionen? Neue Transitionen? Neue Zustände? Neue Applikationen? Routine Signaturen: (: INTEGER): INTEGER display (: INTEGER) read (: INTEGER): [ANSWER, INTEGER] correct (: INTEGER; a: ANSWER): BOOLEAN message (: INTEGER; a: ANSWER) process (: INTEGER; a: ANSWER) is_final (: INTEGER) 5 5

6 Daten-Übertragung Alle Routinen haben den Zustand als Eingabe-Parameter. Sie müssen nach dem Argument unterscheiden, zb : display (current_: INTEGER) is inspect current_ when then... when then... when n then... Konsequenzen: Lange und komplizierte Routinen. Müssen über eine möglicherweise komplexe Applikation wissen. Um eine Transition oder Zustand hinzuzufügen, muss man alle ändern. 6 Der Kontroll-Fluss Zugrundeliege Ursache, warum die Struktur so inflexibel ist: Zu viel DATEN-ÜBERTRAGUNG. Variable current_ kommt als Argument von session (Level 3) zu allen Routinen auf Level und weiter zu Level Schlimmer: es gibt ein weiteres implizites Argument zu allen Routinen die Anwung. Man kann session, display,,... nicht als Bibliotheks-Komponenten schreiben, weil jede alle interaktiven Anwungen kennen muss. 7 Die sichtbare Architektur Level 3 session Level initial transition is_final Level display read correct message process 8 6

7 Die wahre Geschichte Level 3 session Level initial transition is_final Level display read correct message process 9 Das Gesetz der Inversion Der überall lauernde Zustand Wenn deine Routinen zu viele Daten austauschen, gebe deine Routinen in deine Daten. 0 O-O werden Verwe STATE als den Abstrakten Daten-Typen (ergibt eine Klasse). Unter den Features eines Zustands: Die Routinen von Level (deferred in STATE), wie oben, jech ohne das current_ Argument. 7

8 Groupieren nach Daten-Abstraktionen Level 3 session Level initial transition is_final STATE Level display read correct message process Klasse STATE deferred class STATE feature choice: INTEGER -- User s selection for next step input: ANSWER -- User s answer for this step display is -- Show screen for this step. deferred read is -- Get user s answer and exit choice, -- recording them into input and choice. deferred ensure input /= Void correct: BOOLEAN is -- Is input acceptable? deferred 3 Klasse STATE message is -- Display message for erroneous input. require not correct deferred process is -- Process correct input. require correct deferred 4 8

9 Klasse STATE is local good: BOOLEAN from until good loop display read good := correct if not good then message process choice := input.choice 5 Klassen-Struktur * STATE INITIAL RESERVATION CONFIRMATION 6 Um den Zustand einer Applikation zu beschreiben Führe einen neuen Nachkommen von STATE ein: class ENQUIRY_ON_FLIGHTS inherit STATE feature display is... read is... correct: BOOLEAN is... message is... process is

10 Neuordnung der Module APPLICATION Level 3 session Level initial transition is_final STATE Level display read correct message process 8 Beschreiben einer kompletten Applikation Kein Hauptprogram sondern eine Klasse, die das System darstellt. Beschreibe die Anwung durch die verbleiben Features auf Levels and : Funktion transition. Zustand initial. Boolean Funktion is_final. Prozedur session. 9 Implementierungs-Entscheidungen Stelle Übergänge durch ein Array transition dar: n Reihen (Anzahl an Zuständen), m Spalten (Anzahl an Möglichkeiten), bei der Erzeugung angegeben Zustände von bis n numeriert; Array s gibt den dem Index zugeordneten Zustand (Umkehrung nicht nötig: Warum?) Keine deferred boolean Funktion is_final, sondern die Konvention: eine Transition zu Zustand 0 bedeutet Terminierung. KeinesolcheKonventionfürden Initial-Zustand(zu einschränk). Attribut initial_number. 30 0

11 Beschreiben einer Anwung class APPLICATION create make feature initial: INTEGER make (n, m: INTEGER) is -- Allocate with n s and m possible choices. create transition.make (, n,, m) create s.make (, n) feature {NONE} -- Representation of transition diagram transition: ARRAY [STATE] -- State transitions s: ARRAY [STATE] -- State for each index 3 Array von Zuständen: ein polymorpher Kontainer s: ARRAY [STATE] Notation um auf ein Array-Element zuzugreifen, zb s [i] in Pascal: s.item (i) i (Bald in Eiffel: einfach nur s [i]) 3 Das Array von Zuständen (ENQUIRY_ ON_FLIGHTS) (ENQUIRY_ ON_SEATS) (INITIAL) (CONFIRMATION) STATES (RESERVATION) 33

12 Ausführen einer Sitzung session is -- Run one session of application local current_: STATE -- Polymorphic! index: INTEGER from index := initial invariant 0 <= index index <= n until index = 0 loop current_ := index current_. 34 check <= current_.choice current_.choice <= m index := transition.item (index, current_.choice) Klassen-Struktur * STATE INITIAL RESERVATION CONFIRMATION 35 Andere Features von APPLICATION put_ (s: STATE; number: INTEGER) is -- Enter s with index number. require <= number number <= s.upper s.put (number, s) choose_initial (number: INTEGER) is -- Define number number as the initial --. require <= number number <= s.upper first_number := number 36

13 Weitere Features von APPLICATION put_transition (source, target, label: INTEGER) is -- Add transition labeled label from -- number source to number target. require <= source source <= s.upper 0 <= target target <= s.upper <= label label <= transition.upper transition.put (source, label, target) invariant 0 <= st_number st_number <= n transition.upper = s.upper 37 Um eine Anwung zu bauen Notwige Zustände Instanzen von STATE sollten verfügbar sein. Initialisiere die Anwung: create a.make (_count, choice_count) Weise jedem relevanten Zustand s eine Nummer zu: a.put_ (s, n) Wähle Initial-Zustand n0: a.choose_initial (n0) Gib Übergänge ein: a.put_transition (sou, tar, lab) Kann nun ausgeführt werden: a.session 38 Offene Architektur Währ der System-Evolution kannst du zu jeder Zeit: Einen neuen Übergang einfügen (put_transition). Einen neuen Zustand einfügen (put_). Einen Zustand löschen (nicht gezeigt, aber einfach einzubauen). Ändern der Aktionen in einem gegebenen Zustand

14 Kommentare zur Architektur Prozedur session ist nicht die Funktion des Systems sondern nur eine Routine von APPLICATION. Andere Anwungen: Baue und modifiziere: füge hinzu oder lösche Zustände, Übergange, etc. Simulation, zb in Batch (wiederholen einer vorherigen Sitzung), oder bei einem Zeilen-Terminal. Sammeln von Statistiken, ein Log, ein Skript. Speichern in eine Datei oder Datenbank. Jede solche Erweiterung benötigt nur inkrementelles hinzufügen von Routinen. Beeinflusst nicht die Struktur von APPLICATION und Kunden. 40 Das System ist offen Schlüssel für Offenheit: Architektur basiert auf den Typen von den Objekten des Problems (Zustand, Übergang, Anwung). Basiert man es auf dem scheinbaren Zweck des Systems würde man es vor Evolution abschliessen. Wirkliche Systeme haben keine Spitze 4 Objekt-Orientiertes Design It s all about finding the right data abstractions Es dreht sich alles um die richtigen Daten-Abstraktionen 4 4

15 Ende der Vorlesung 9 5