Aufgabe. Ansatz: Abstrakte Klasse Kämpfer, die Gemeinsamkeiten enthält und individuelle Aktionen abstrakt vorgibt. Prof. Dr.

Transkript

1 Aufgabe In einem Rollenspiel sollen verschiedene Kämpfer zu Teams gruppiert werden können. Als Grundlage sollen zunächst verschiedene Versionen vom Kämpfern erstellbar sein Spezifikation: Kämpfer haben Gesundheitspunkte (Kämpfer lebt solange Punktzahl positiv), Stärke und Geschick; abhängig vom Typ schlagen sie zu und müssen Schläge einstecken Ansatz: Abstrakte Klasse Kämpfer, die Gemeinsamkeiten enthält und individuelle Aktionen abstrakt vorgibt 298

2 Abstrakter Kämpfer public abstract class Kaempfer { protected int gesundheit; protected int staerke; protected int geschick; public abstract int zuhauen(); public abstract void einstecken(int int schlag); Spezifikation: Kämpfer haben Gesundheitspunkte (Kämpfer lebt solange Punktzahl positiv), Stärke und Geschick; } public boolean lebt(){ return this.gesundheit > 0; } // get- und setmethoden weggelassen abhängig vom Typ schlagen sie zu und müssen Schläge einstecken 299

3 Beispielimplementierung package kaempfer; import main.basis; public class Xena extends public int zuhauen() { return (Basis.zufall Basis.zufall(super.geschick super.geschick - 2) + 5) * super.staerke / 2; } public void einstecken(int int schlag) { super.gesundheit -= schlag; } 300

4 Kaempfer als UML-Klassendiagramm 301

5 Beispielnutzung 1/3 (hölzern) public static void main(string[] s) { System.out.println("Welcher K\u00e4mpfer u00e4mpfer: "); int auswahl1 = Basis.leseInteger(); Kaempfer k1 = null; switch(auswahl1){ case 1: k1 = new Conan(); break; case 2: k1 = new Xena(); break; case 3: k1 = new Blob(); break; } k1.setgesundheit(100); k1.setgeschick(5); k1.setstaerke(10); // analog für Kaempfer k2 302

6 Beispielnutzung 2/3 } while (k1.lebt() && k2.lebt()) { int k1schlag = k1.zuhauen(); System.out.println(k1 + " haut mit " + k1schlag); k2.einstecken(k1schlag); if (k2.lebt()) { int k2schlag = k2.zuhauen(); System.out.println(k2 + " haut mit " + k2schlag); k1.einstecken(k2schlag); } } if (k1.lebt()) { System.out.println(k1 + " hat gewonnen"); } else { System.out.println(k2 + " hat gewonnen"); } 303

7 Beispielnutzung 3/3 Welcher Kämpfer: 1 Welcher Kämpfer: 2 Conan haut mit 10 Xena haut mit 36 Conan haut mit 0 Xena haut mit 24 Conan haut mit 30 Xena haut mit 28 Conan haut mit 20 Xena haut mit 36 Xena hat gewonnen 304

8 Analyse Programm läuft kritisch: Jeder der Kämpfer nutzen will, muss switchcase-konstrukt realisieren kritisch: Erzeugung findet weit weg von den eigentlichen Kämpfer-Klassen statt Ansatz: Erzeugung der Kämpfer in eigener Klasse Diese Klasse wird Factory genannt Diese Klasse bietet Methode, um neue Objekte als Aufrufergebnis zu erhalten 305

9 Factory Pattern in UML 306

10 Realisierung der Factory public class KaempferFactory { } public Kaempfer kaempfererstellen(int auswahl) { switch(auswahl auswahl){ case 1: return new Conan(); case 2: return new Xena(); case 3: return new Blob(); } return null; } 307

11 Nutzung der Factory (Ausschnitt) KaempferFactory kf = new KaempferFactory(); System.out.println("Welcher K\u00e4mpfer: "); Kaempfer k1 = kf.kaempfererstellen(basis.leseinteger Basis.leseInteger()); System.out.println("Welcher K\u00e4mpfer: "); Kaempfer k2 = kf.kaempfererstellen(basis.leseinteger Basis.leseInteger()); Anmerkung: kaempfererstellen() kann auch Klassenmethode sein 308

12 Hintergrund von Pattern beim Programmieren fällt auf, dass man einige Ideen immer wieder nutzen kann bei Software-Architekturen fällt auf, dass es auch sinnvolle wiederkehrende Strukturen gibt Strukturen werden Pattern genannt und werden nach den bearbeiteten Aufgabenstellungen benannt Bedeutung von Pattern ab der Sammlung in [GHJ95] bekannt Ziele: schnellere Entwicklung, einfache Lesbarkeit, gemeinsame Sprache der Entwickler, Wart- und Erweiterbarkeit [GHJ95] E. Gamma, R. Helm, R. Johnson, J. Vlissides, Design Pattern, Addison-Wesley, 1995 (Gang of Four-Buch) 309

13 Erweiterung Premiumkämpfer gleicher Ansatz erneut genutzt Problem: Nutzer muss zunächst Factory auswählen Lösung: Factory Pattern erneut nutzen 310

14 Factory für Factories 311

15 Nutzung der Factories (Ausschnitt ohne Dialog) public class KaempferArtFactory { public static AbstractKaempferFactory kaempferfactoryerstellen(string typ){ switch(typ){ case "basic basic": return new KaempferFactory(); case "premium": return new PremiumKaempferFactory(); } return null; } } AbstractKaempferFactory kf = KaempferArtFactory.kaempferFactoryErstellen kaempferfactoryerstellen(" ("basic basic"); Kaempfer k1 = kf.kaempfererstellen(1); kf = KaempferArtFactory.kaempferFactoryErstellen("premium"); Kaempfer k2 = kf.kaempfererstellen(2); 312

16 Weitergehende Analyse - Ausblick zentraler Teil des Factory Method Pattern, Erzeugung von Objekten wird durch realisierende Klassen entschieden Factory, die andere Factories zur Erzeugung nutzt, ist Grundlage des Abstract Factory Pattern inhaltlich: Waffen und Rüstungen ergänzen 313

17 Nutzung von Komponenten Komponente: konfigurierbare, übersetzte Software, die klare Funktionalität anbietet Beispiel: Komponente bietet Kämpfer-Objekte an benötigt Klasse, die die Erzeugung ermöglicht 314

18 Validierungs-Framework (Bean Validation 1.1, JSR 349) public abstract class Kaempfer value=0, message = "Gesundheit nicht negativ") protected int value=3, message="minimale Staerke value= 15, message="maximale Staerke beachten") protected int value=5, message="minimales Geschick value= 20, message="maximales Geschick beachten") protected int geschick; // wie vorher 315

19 Beispielnutzung der Validierung public static void main(string[] s) { AbstractKaempferFactory kf = KaempferArtFactory.kaempferFactoryErstellen kaempferfactoryerstellen(" ("basic basic"); Kaempfer k = kf.kaempfererstellen(2); k.setgesundheit(-1); k.setgeschick(22); ValidatorFactory factory = Validation.buildDefaultValidatorFactory builddefaultvalidatorfactory(); Validator validator = factory.getvalidator(); for (ConstraintViolation ConstraintViolation<Kaempfer Kaempfer> c : validator.validate(k)) { System.out.println(" :: " + c.getmessage()); } } :: maximales Geschick beachten :: minimale Staerke beachten :: Gesundheit nicht negativ 316

20 Persistenz-Framework (JPA 2.1, JSR public abstract class GeneratedValue(strategy = GenerationType.AUTO) protected int = 0, message = "Gesundheit nicht negativ") protected int = 3, message = "minimale Staerke = 15, message = "maximale Staerke beachten") protected int = 5, message = "minimales Geschick = 20, message = "maximales Geschick beachten") // wie vorher, konkrete Klassen auch annotiert 317

21 Beispielnutzung der Persistenz public static void main(string[] s) { AbstractKaempferFactory kf = KaempferArtFactory.kaempferFactoryErstellen kaempferfactoryerstellen(" ("basic basic"); Kaempfer k = kf.kaempfererstellen(2); k.setgesundheit(100 (100); k.setstaerke(7 (7); k.setgeschick(9 (9); EntityManagerFactory emf = Persistence.createEntityManagerFactory createentitymanagerfactory(" ("KaempferPU KaempferPU"); EntityManager em = emf.createentitymanager(); em.gettransaction(). ().begin begin(); em.persist(k); em.gettransaction(). ().commit commit(); em.close(); SELECT * FROM Kaempfer emf.close(); } 318

22 7. Konkretisierungen im Feindesign 7.1 Zustandsdiagramme 7.2 Object Constraint Language 200

23 Verfeinerte Modellierung Durch die verschiedenen Sichten der Systemarchitektur wird der Weg vom Anforderungsmodell zur Implementierung beschrieben Es bleiben offene Themen: Wie bekomme ich ein gutes Klassendesign (nächstes Kapitel)? Wie kann man das komplexe Verhalten von Objekten noch beschreiben (Klassendiagramme sind statisch, Sequenzdiagramme exemplarisch)? Antwort: Zustandsdiagramme Wie kann man bei der Klassenmodellierung Randbedingungen formulieren, was in Klassendiagrammen (Bedingungen in geschweiften Klammern) nur bedingt möglich ist? Antwort: Object Constraint Language 201

24 Zustandsdiagramme 7.1 generell wird der Zustand eines Objekts durch die Werte seiner Exemplar- und Klassenvariablen beschrieben Häufig wird der Begriff Zustand auch für eine spezielle Exemplarvariable genutzt, die z. B. über eine Enumeration realisierbar ist z. B. : Ampel: rot, rotgelb, gelb, grün z. B. : Projekt: vorbereitet, grob geplant, Mitarbeiter zugeordnet, verschoben, in Bearbeitung, in Endabnahme, in Gewährleistung, beendet Die Übergänge zwischen den Zuständen werden durch Ereignisse, zumeist Methodenaufrufe, veranlasst Die Übergänge lassen sich durch ein Zustandsdiagramm (ursprünglich Statechart nach D. Harel) spezifizieren Zustandsautomaten spielen auch in der theoretischen und technischen Informatik eine zentrale Rolle 202

25 Struktur von Zustandsdiagrammen Zustandsdiagramm gehört zu einem Objekt einer Klasse alle Angaben für Zustände und Transitionen sind Optional Transition wird ausgeführt, wenn Ereignis eintritt und Bedingung erfüllt ist ohne Ereignis und Bedingung wird Transition dann ausgeführt, wenn Entry, Do, und Exit durchlaufen Einfacher Automat muss deterministisch sein 203

26 Beispiel: Zustandsdiagramm eines Projekts man erkennt: nach Planung keine Planungsänderung 204

27 Hierarchische Zustände 205

28 Parallele Unterzustände unabhängige Teilzustände können in parallelen Zuständen bearbeitet werden ohne Parallelität müsste Kreuzprodukt der Zustände der parallelen Automaten betrachtet werden 206

29 Beispiel: Uhr 207

30 Zustandsmodellierung und Realzeitsysteme in klassischen OO- Programmen gibt es meist wenige zentrale Klassen, für die sich eine Zustandsmodellierung anbietet In Systemen mit Zeit kann Zustandsmodellierung Zeitbedingungen beinhalten auch warte(5 sek) 208

31 Event [Condition] / Action Transitionsbeschriftung Ereignis[Bedingung]/Aktion Was ist Ereignis? Hängt von Applikation ab Methodenaufruf Ereignis im Programm (Variable wechselt Wert) technische Systeme: Signale typisches Beispiel: Steuersysteme erhalten Signale (->Ereignisse) von Sensoren wenn etwas passiert (z. B. ein-/ausgeschaltet) lesen Werte anderer Sensoren, Teilsysteme (-> Bedingung), die Entscheidungen beeinflussen senden Signale (-> Aktion) an andere Systeme 209

32 Microsteps und Macrosteps (1/2) Actions eines Teilautomaten können Events eines anderen Teilautomaten sein Microstep: einzelne Schritte betrachten Start -> K(A1,B1) p-> K(A2,B1) x-> K(A2,B2) q-> K(A3,B2) y-> K(A3,B3) z-> K(A3,B1) r-> K(A1,B1) 210

33 Microsteps und Macrosteps (2/2) Macrostep: nur Zustände nach vollständiger Bearbeitung betrachten (Ausnahme: Livelock) Start -> K(A1/B1) p-> K(A3/B3) z-> K(A1/B1) typischerweise nur an Macrosteps interessiert 211

34 Beispiel: Start-Stopp-Automatik (1/3) zentrale Aufgabe: Start-Stopp-Automatik stellt den Motor immer dann selbstständig aus, wenn dieser nicht mehr benötigt wird (z. B. Halt an Ampel) Randbedingung: keine Abschaltung bis maximal 3 Grad und ab minimal 30 Grad Ablauf: Zündschlüssel einstecken, Motorstartknopf drücken, dann startet Automatik Motorein- und Abschaltung wird anhand der Kupplung erkannt Automatik kann auch wieder gestoppt werden [Frage: was fehlt alles zur Realität] 212

35 Beispiel: Start-Stopp-Automatik (2/3) Klärung, von welche Sensoren werden Signale empfangen: Zündschloss: start und ende Kupplung: leerlauf und druecken Automatiksteuerung: an und aus Klärung, welchen Sensoren können abgefragt werden: Temperaturwert temp in lokaler Variablen Klärung an welche Sensoren Signale geschickt werden Motorsteuerung: motor_an und motor_aus 213

36 Beispiel: Start-Stopp-Automatik (3/3) 214

37 Umsetzung von Zustandsdiagrammen Abhängig davon, wie formal die Zustände und Transitionen spezifiziert sind, kann aus Zustandsdiagrammen Programmcode erzeugt werden Typisch: Iteratives Vorgehen: informelle Beschreibungen werden schrittweise durch formalere ersetzt Ereignisse können für folgendes stehen Methodenaufrufe externe Ereignisse des GUI (-> Methodenaufruf) Teilsituation, die bei der Abarbeitung einer Methode auftreten kann Automat wird zunächst zu komplexer Methode, die z. B. anhand der Zustände in Teilmethoden refaktoriert werden kann 215

38 GUI als Zustandsautomat 216

39 Android als Zustandsdiagramm Stephan Kleuker 217