Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

4. Design Gliederung: Einführung Anforderungsdefinition Analyse Design

Ähnliche Präsentationen


Präsentation zum Thema: "4. Design Gliederung: Einführung Anforderungsdefinition Analyse Design"—  Präsentation transkript:

1 4. Design Gliederung: Einführung Anforderungsdefinition Analyse Design
Klassendiagramme Regel-Diagramme <== Zetteltests Validierung Zusammenfassung Programmiermethodik SS © 2005 Albert Zündorf, University of Kassel

2 Beispiel: Objektspiel Spielstein raussetzen
Main Memory Objects Rule Diagram / Program Programmiermethodik SS © 2005 Albert Zündorf, University of Kassel

3 The FAMous Fujaba Abstract Machine (Teil 1) Der Befehlssatz:
in den Objekten werden Kommandos / Nachrichten von vergesslichen „Object Guys“ abgearbeitet Object Guys schlafen normaler weise beim Aufwachen wird die Umgebung wird vom „Nebel des Vergessens“ verschleiert Object Guys sehen nicht was die anderen tun Jeder Object Guy hat eigenen „Namensraums“ Object Guy hat „Handlungsanweisungen“ für jedes mögliche Komando Immer ein Object Guy pro Nachricht Object Guy kann: Kanten lesen und lokale Namen für Nachbarn vergeben Attribute lesen und prüfen temporäre Werte notieren Berechnungen durchführen Nachrichten verschicken (wartet (untätig) auf Antwort) Antworten zurückschicken (und wieder einschlafen) Attribute schreiben Kanten löschen / erzeugen Objekte löschen / erzeugen Programmiermethodik SS © 2005 Albert Zündorf, University of Kassel

4 Rule Diagrams: graphische Notation für Befehle der Fujaba Abstract Machine
Main Memory Objects Rule Diagram / Program benenne this lese gehoert Link; benenne meinSp lese hat; benenne seinWuerfel prüfe augenzahl == 6 lese ist_Startfeld_von, benenne seinStart lese steht_in; benenne meinHeim lösche ist_Startfeld_von erzeuge steht_auf Programmiermethodik SS © 2005 Albert Zündorf, University of Kassel

5 Fujaba Abstract Machine Teil 2: Zetteltest
Main Memory Objects Rule Diagram / Program this meinHeim meinSp seinStart steht auf seinWuerfel Programmiermethodik SS © 2005 Albert Zündorf, University of Kassel

6 Rule Diagram Syntax: benennen  Objektkasten:
class Spielstein { ... public void raussetzen () { Heimatfeld meinHeim = null; Spieler meinSp = null; Feld seinStart = null; Wuerfel seinWuerfel = null; benennen: Objekttyp mit angeben ungebundene Objekte werden zu gebundenen Objekten, unbekannte Objekte werden bekannt Namen benutzen: ohne Objekttyp ACHTUNG: bei [failure] des Vorgängerschritts wurden eventuell nicht alle Variablen gebunden ! Programmiermethodik SS © 2005 Albert Zündorf, University of Kassel

7 Rule Diagram Syntax: lese Link  Link:
bei zu-1 Links von bekanntem Objekt zu unbekanntem Objekt - get-Methode verwenden - Erfolg prüfen: meinSp = this.getGehoert (); if (meinSp != null) { .... oder try { meinSp = this.getGehoert (); JavaSDM.ensure ( meinSp != null ); } catch (SDMException e) { sdmSuccess = false } ... danach ist der Name zugewiesen Programmiermethodik SS © 2005 Albert Zündorf, University of Kassel

8 Hilfsmethode JavaSDM.ensure
class JavaSDM { public static void ensure (boolean expr) if (expr == false) throw new SDMException (); } Programmiermethodik SS © 2005 Albert Zündorf, University of Kassel

9 Rule Diagram Syntax: lese Link  Link:
bei zu-n Links von bekanntem Objekt zu unbekanntem Objekt - iteratorOf-Methode verwenden - while Schleife bis zum Erfolg: sdmSuccess = false; Iterator iter = meinSp.iteratorOfSteine (); while ( !(sdmSuccess) && iter.hasNext () ) { try { stein2 = (Spielstein) iter.next (); JavaSDM.ensure // prüfen ob es der richtige ist sdmSuccess = true; } catch (SDMException e) { } } // while Programmiermethodik SS © 2005 Albert Zündorf, University of Kassel

10 Rule Diagram Syntax: prüfe Attributwert  Attributbedingung:
sdmSuccess = false; ... try { seinWuerfel = meinSp.getHat (); JavaSDM.ensure ( seinWuerfel != null); JavaSDM.ensure ( seinWuerfel.getAugenzahl == 6); ... } catch (SDMException e) { } Programmiermethodik SS © 2005 Albert Zündorf, University of Kassel

11 Rule Diagram Syntax: prüfe Link zwischen gebundenen (schon benannten) Objekten  Link: Link zwischen gebundenen Objekten: JavaSDM.ensure ( meinSp.getHat () == seinWuerfel); oder bei zu-n Link: JavaSDM.ensure ( x.hasInNeighbours (y)); prüfe allgemeinen Constraint:  Prüfung JavaSDM.ensure ( meinSp.noOfSteine() < w.getAugenzahl() ); Programmiermethodik SS © 2005 Albert Zündorf, University of Kassel

12 Rule Diagram Syntax: prüfe kein Nachbar da  negatives Objekt:
kollege = seinStart.getBewohner(); JavaSDM.ensure ( ! (kollege.getGehoert() == meinSp)) prüfe kein Link da  negativer Link: JavaSDM.ensure ( (x.getGehört() != meinSp)) Programmiermethodik SS © 2005 Albert Zündorf, University of Kassel

13 Rule Diagram Syntax: x :C next > x :C1 y :C2 others :C3
benenne wenn möglich  optionales Objekt: lese/prüfe Link wenn möglich  optionaler Link: benenne alle Nachbarn  Mengenobjekt : x :C next > x :C1 y :C2 others :C3 Programmiermethodik SS © 2005 Albert Zündorf, University of Kassel

14 Rule Diagram Syntax: loesche Objekt  <<destroy>>: gegener.removeYou() loesche Link  <<destroy>>: this.setStehtIn (null); erzeuge Objekt  <<create>>: neuStein = new SpielStein (); erzeuge Link  <<create>>: this.setStehtAuf (seinStart); setze Attributwert  augenzahl := 0: w.setAugenzahl (0); nachricht m1()   1: m1() meinSp.naechsterSpieler(); Programmiermethodik SS © 2005 Albert Zündorf, University of Kassel

15 Rule Syntax: Overview Programmiermethodik SS © 2005 Albert Zündorf, University of Kassel

16 Rule Diagrams: Kontrollfluss
Activities start activity stop activities rule acitivities code activities branch activities Transitionen ohne Guard [success] [failure] [boolean condition] [else] Programmiermethodik SS © 2005 Albert Zündorf, University of Kassel

17 Rule Diagrams: for-each Activities
this this lhome looser at lostCounter noPos noPos noPos Programmiermethodik SS © 2005 Albert Zündorf, University of Kassel

18 Rule Diagrams: for-each Activities
class Game { public void collectThrownCounters () { Iterator looserIter = this.iteratorOfPlayers(); while (!sdmSuccess && looserIter.hasNext()) { try { sdmSuccess = false; looser = looserIter.next (); lhome = looser.getHome (); JavaSDM.ensure (lhome != null); countersIter = looser.iteratorOfCounters (); while (!sdmSuccess && countersIter.hasNext()) { try { lostCounter = countersIter.next (); JavaSDM.ensure (lostCounter.getAt() == null); sdmSuccess = true; lostCounter.setAt (lhome); } catch (SDMException e) {} } // while } catch (SDMException e) {} } // while Programmiermethodik SS © 2005 Albert Zündorf, University of Kassel

19 Rule Diagrams: for-each Activities
doppelte Activity Box anwenden so oft wie möglich [each time] transition für zusätzliche Aktionen für jeden Match [end] transition nach Abbruch [end] Programmiermethodik SS © 2005 Albert Zündorf, University of Kassel

20 Rule Diagrams: for-each Activities
class Game { public void collectThrownCounters () { Iterator looserIter = this.iteratorOfPlayers(); while (!sdmSuccess && looserIter.hasNext()) { try { sdmSuccess = false; looser = looserIter.next (); lhome = looser.getHome (); JavaSDM.ensure (lhome != null); countersIter = looser.iteratorOfCounters (); while (!sdmSuccess && countersIter.hasNext()) { try { lostCounter = countersIter.next (); JavaSDM.ensure (lostCounter.getAt() == null); sdmSuccess = true; lostCounter.setAt (lhome); } catch (SDMException e) {} } // while } catch (SDMException e) {} } // while [end] Programmiermethodik SS © 2005 Albert Zündorf, University of Kassel

21 Programmiermethodik SS2006 © 2005 Albert Zündorf, University of Kassel

22 Programmiermethodik SS2006 © 2005 Albert Zündorf, University of Kassel

23 Programmiermethodik SS2006 © 2005 Albert Zündorf, University of Kassel


Herunterladen ppt "4. Design Gliederung: Einführung Anforderungsdefinition Analyse Design"

Ähnliche Präsentationen


Google-Anzeigen