Kapitel 4: Dynamische Analyse mit FUSION. SoPra 2008 Kap. 4: Dynamische Analyse mit FUSION (1/30)

Transkript

1 Kapitel 4: Dynamische Analyse mit FUSION SoPra 2008 Kap. 4: Dynamische Analyse mit FUSION (1/30)

2 Dokumente der dynamischen Analyse Analyse des Systemverhaltens (dynamischer Aspekt). Zu entwickeln sind: Interaktionsmodell beschreibt notwendige Agenten, Events, Systemoperationen beschreibt beispielhaft Interaktion von Agenten mit System (Szenarien) Grundlage für Tests Operationsmodell beschreibt Systemoperationen deklarativ Lebenszyklen beschreibt erlaubte Interaktion mit System verallgemeinert Szenarien erweitern: Glossar SoPra 2008 Kap. 4: Dynamische Analyse mit FUSION (2/30)

3 Kapitel 4.1: Die Systemschnittstelle Die Ziele der Anwendung werden durch Interaktionen (Kommunikationen) von Agenten erreicht. Das System ist ein Agent; die anderen Agenten bilden die Umgebung. Interaktionen werden durch Events angestoßen: Inputevents: Agent System Outputevents: System Agent Inputevents lösen Systemoperation aus, die den Systemzustand verändern (und ggf. zu Outputevents führen). SoPra 2008 Kap. 4.1: Dynamische Analyse mit FUSION Die Systemschnittstelle (3/30)

4 Systemschnittstelle Agenten immer vorhandener Agent: zu entwerfendes System Agenten sind z.b.: Personen (evtl. in Rollen), die das System bedienen externe Systeme (andere existierende Systeme, Drucker) externe, vorgegebene Datenbanken (hier: Datenbank intern) Agenten werden aus Szenarien gewonnen SoPra 2008 Kap. 4.1: Dynamische Analyse mit FUSION Die Systemschnittstelle (4/30)

5 Systemschnittstelle Events und Operationen Agenten kommunizieren durch Austausch von Nachrichten (Events). Event kann Argumente haben, die dem Ziel übergeben werden. Erhält das System einen Event, führt es eine Systemoperation aus. Ausgabeevent an eine Person (gestrichelt) ist typischerweise (die Anzeige eines) Ergebnis. allgemein: asynchrone Kommunikation, d. h. Agent muss nicht auf Ergebnis warten. Eine Interaktion in einem Szenario hat typischerweise eine (manchmal: mehrere) Systemoperation(en) zur Folge. SoPra 2008 Kap. 4.1: Dynamische Analyse mit FUSION Die Systemschnittstelle (5/30)

6 Kapitel 4.2: Szenarien Beispiel: Anlegen von Buchungen 1. Beim Anlegen einer Buchung gibt der Benutzer durch einen Buchungswunsch ein, wie die Buchung aussehen soll: welcher Zeitraum welche Dauer welche Kapazität und Mindestausstattung welcher Raum und welches Gebäude (meist egal) Raumwunsch als Teil des Buchungswunsches 2. Das System macht Vorschläge, z. B. Raum 1005 ist von 10:00-15:00 Uhr für eine Stunde frei. 3. Benutzer wählt dann die konkrete Stunde. SoPra 2008 Kap. 4.2: Dynamische Analyse mit FUSION Szenarien (6/30)

7 Szenarien: Sequenzdiagramme Beispiel: Anlegen von Buchungen 1 Agenten :Benutzer :System machevorschläge(b.wunsch) Set(B.vorschlag) 3 Events legebuchungan(b.vorschlag,startzeit,titel) ok } 4 Operationen 2 Zeit SoPra 2008 Kap. 4.2: Dynamische Analyse mit FUSION Szenarien (7/30)

8 Szenarien (Warum?) Vorteile Erstellen der Systemschnittstelle Validierung des Objektmodells Visualisierung des Verhaltens einfache Diagramme auch für Kunden verständlich Nachteil Szenarien beschreiben nur Beispielabläufe lineare Abfolge ohne Alternativen Möglichkeit: mehrere, alternative Szenarien SoPra 2008 Kap. 4.2: Dynamische Analyse mit FUSION Szenarien (8/30)

9 Szenarien (Wie?) System als black box betrachten Granularität der Operationen festlegen feingranular: viel Interaktion, detaillierte Fehlerbehandlung grobgranular: wenig Interaktion, automatisch Bsp.: machevorschläge durch findegeeigneteräume verfeinern Agenten und Operationen in das data dictionary eintragen SoPra 2008 Kap. 4.2: Dynamische Analyse mit FUSION Szenarien (9/30)

10 Szenarien Tipps viele Selektionsoperationen in der Systemschnittstelle zur Navigation systematische Namen in einer Sprache vergeben! In FUSION ist das Festlegen der Argumente der Systemoperationen nicht zwingend vorgeschrieben. Es ist hier aber sinnvoll. SoPra 2008 Kap. 4.2: Dynamische Analyse mit FUSION Szenarien (10/30)

11 Szenarien Szenarien bei Systemen mit GUI Typisches Szenario mit GUI: Fenster WIN zeigt Daten d 1... d n an (evtl. leer) Beispiel: Eingabefenster zur Neueingabe/zum Ändern eines Administrators Daten d 1... d n werden modifiziert/eingegeben (bei einem Wizard in mehreren Fenster hintereinander) Beispiel: Name, ,... eines Administrators OK-Button (abschicken, ändern, eingeben) wird gedrückt Die GUI wechselt in ein neues Fenster NEXT, abhängig vom Ergebnis (Daten akzeptiert/nicht akzeptiert) Beispiel: Neues Fenster zeigt alle Administratoren an SoPra 2008 Kap. 4.2: Dynamische Analyse mit FUSION Szenarien (11/30)

12 Szenarien bei Systemen mit GUI Beispiel: Szenario als Sequenzdiagramm: 2 Alternativen :Admin :System :Admin :System legeadminan(name, ,...) legeadminan(name, ,...) ok set(administrator) holealleadmins() set(administrator) SoPra 2008 Kap. 4.2: Dynamische Analyse mit FUSION Szenarien (12/30)

13 Szenarien bei Systemen mit GUI Granularität festlegen viele Argumente in einem Objekt zusammenfassen: legeadminan(administrator) statt legeadminan(name, , Passwort, Kontaktdaten,... ) wenn das nicht geht (keine Klasse Administrator vorhanden), fehlen vielleicht Konzepte! SoPra 2008 Kap. 4.2: Dynamische Analyse mit FUSION Szenarien (13/30)

14 Kapitel 4.3: Das Operationsmodell Beispiel: machevorschläge(...) Operation: Beschreibung: Vorbedingung: Typ: Ergebnisse: machevorschläge(bw:buchungswunsch, be:benutzer) Berechnet mögliche Buchungsvorschläge, die den Buchungswunsch erfüllen und nicht mit dem Gesamtbelegungsplan in Konflikt stehen. Der zu bw assoziierte Raumwunsch ist erfüllbar. Der Gesamtbelegungsplan ist konsistent. Systemoperation Menge von Buchungsvorschlägen set(bv) SoPra 2008 Kap. 4.3: Dynamische Analyse mit FUSION Das Operationsmodell (14/30)

15 Beispiel machevorschläge(...) (2) Nachbedingung: be wurde mit bw assoziiert (machte). Eine Menge von Buchungsvorschlagsobjekten set(bv) wurde generiert. Für jeden Buchungsvorschlag bv: Assoziation erfüllt zu bw wurde erzeugt. Passende Termine t wurden erzeugt und zu bv assoziiert. Diese respektieren den Gesamtbelegungsplan. Für alle Termine t: gebuchterzeitraum wurde gesetzt, und über findetstattin ein freier Raum assoziiert. gebuchterzeitraum ist modulo Kalenderwoche identisch und maximal. SoPra 2008 Kap. 4.3: Dynamische Analyse mit FUSION Das Operationsmodell (15/30)

16 Operationsmodell (Schema für Kontrakte) Operation: Name der Systemoperation Beschreibung: kurzer, informeller, möglichst prägnanter Text Vorbedingung: Welche Eigenschaften müssen vor Ausführung gelten? Nachbedingung: Was gilt nach Ausführung (relativ zu vorher)? Ergebnisse: Was gibt die Operation zurück? Ausnahmen: Fehler, die zum Abbruch der Operation führen Ausgaben: An welche Agenten werden welche Events geschickt? Typ: hier: Systemoperation Querverweise: Referenz auf andere Modelle Anmerkungen: Algorithmen, Effizienz,... SoPra 2008 Kap. 4.3: Dynamische Analyse mit FUSION Das Operationsmodell (16/30)

17 Operationsmodell Zwingend erforderliche Bestandteile Operation: Name der Systemoperation mit Argumenten und Typen Beschreibung/Description: informell: Aufgabe/Ziel der Operation Vorbedingung/Precondition: Anforderungen an den Anfangszustand und die Eingaben (semi-formal oder formal) Nachbedingung/Postcondition: beschreibt Änderungen gegenüber dem Anfangszustand und Invarianten Nachbedingung setzt Zustand vor und nach Ausführung in Relation Nachbedingung beschreibt Verhalten für erlaubte initiale Zustände Invarianten müssen vor und nach der Ausführung gelten in die Vor- und Nachbedingung mit aufnehmen Ist die Vorbedingung erfüllt, so wird die Nachbedingung garantiert. (Kontrakt) SoPra 2008 Kap. 4.3: Dynamische Analyse mit FUSION Das Operationsmodell (17/30)

18 Operationsmodell optionale Bestandteile Ergebnisse/Result Values: Rückgabewert(e) der Operation, Outputevents Ausnahmen/Exceptions: Bedingungen, die zum Abbruch der Operation führen Ausgaben/Messages: Nachrichten/Events an andere Agenten (außer Ergebnisse) Typ: Art der Operation: Systemoperation (Kontrakte auch für andere Operationen möglich) Querverweise/Cross References: Verweis auf Szenarien, in denen die Systemoperation vorkommt Anmerkungen/Notes: zusätzliche Informationen SoPra 2008 Kap. 4.3: Dynamische Analyse mit FUSION Das Operationsmodell (18/30)

19 Operationsmodell (Warum?) Systemoperationen werden klar spezifiziert Ein-/Ausgaben werden detailliert beschrieben Vorteile ermöglicht separate Weiterentwicklung (Modularisierung) Arbeitsweise (Implementierung) der Operation weiterhin offen Nachteil Nachbedingung manchmal schwer deklarativ zu beschreiben evtl. Hinweis auf Algorithmus SoPra 2008 Kap. 4.3: Dynamische Analyse mit FUSION Das Operationsmodell (19/30)

20 Operationsmodell (Wie?) Entwickle Vorbedingung aus Szenarios. Welche Annahmen macht die Operation an Zustand/Eingaben? ( Vorbedingung) Welche Überprüfungen macht die Operation? ( Ausnahmen) Entwickle Nachbedingung und Ergebnisse aus Szenarios. Extrahiere Ausgaben aus Szenarios. Prüfe, ob Ergebnis unerwünschte Werte zulässt. Sind Vor- und Nachbedingung erfüllbar? Extrahiere Invarianten und Prädikate aus dem Objektmodell. Trage alle Operationen und Events ins data dictionary ein. SoPra 2008 Kap. 4.3: Dynamische Analyse mit FUSION Das Operationsmodell (20/30)

21 Kapitel 4.4: Lebenszyklus (Bestandteile) Verallgemeinerung von Szenarien Szenario: ein Beispielfall, linearer Ablauf Lebenszyklus: alle möglichen Abläufe, regulärer Ausdruck Ziel: Spezifikation des Systems durch Lebenszyklen Regulärer Ausdruck reg Operation operationsname Ausgabeevent # eventname Sequenz reg 1.reg 2 Wiederholung (reg) Alternative (reg 1 reg 2 ) Parallelität (reg 1 reg 2 ) Definition eines Makros: N = reg Verwendung eines vorher definierten Makros: N Gesamtsystem: INIT = reg SoPra 2008 Kap. 4.4: Dynamische Analyse mit FUSION Lebenszyklus (21/30)

22 Erinnerung: Szenarien :Admin :System legeadminan(administrator) ok holealleadmins() set(administrator) SoPra 2008 Kap. 4.4: Dynamische Analyse mit FUSION Lebenszyklus (22/30)

23 Szenarien im Life Cycle Szenario als Bestandteil des Life Cycle: ADMIN ::= legeadminan(administrator).#ok. holealleadmins().#set(administrator). NEXT Von Zustand (Kontext) ADMIN gehe durch Ausführen der Operationen legeadminan und holealleadmins in Kontext NEXT SoPra 2008 Kap. 4.4: Dynamische Analyse mit FUSION Lebenszyklus (23/30)

24 Erweiterte Lebenszyklen neu: rechtsrekursive Definition N 1 = reg N 2 neu: N = ε ( nichts tun, beenden ) Idee: N bezeichnet einen Zustand/Kontext (oft visualisiert durch ein Fenster, evtl. mehrere Fenster) Definition bedeutet: von Kontext N 1 kommt man mit reg nach Kontext N 2 (Automaten)Theorie: Erweiterung beschreibt nicht mehr Systeme Praxis: zyklisches Wechseln zwischen Kontexten wesentlich einfacher zu beschreiben SoPra 2008 Kap. 4.4: Dynamische Analyse mit FUSION Lebenszyklus (24/30)

25 Lebenszyklus (Warum?) Vorteile aussagekräftiger als Szenarien modelliert Menge aller Szenarien spezifiziert das System Vorstufe zum Design des User Interface Nachteile kompliziertere Notation reguläre Ausdrücke immer noch nicht sehr ausdrucksstark SoPra 2008 Kap. 4.4: Dynamische Analyse mit FUSION Lebenszyklus (25/30)

26 Lebenszyklus (Wie?) Welche Informationen will man darstellen? Welche Kontexte (= Zustände) braucht man also? Wann können Eingaben wiederholt werden? Welche Schritte sind optional? Wie betritt/verlässt man das System? SoPra 2008 Kap. 4.4: Dynamische Analyse mit FUSION Lebenszyklus (26/30)

27 Lebenszyklus (Zusammenfassung) Ziel: jedes Szenario in einem Lebenszyklus berücksichtigen Fehlerbehandlung, Abbruchmöglichkeiten nicht vergessen! Lebenszyklen zu Lebenszyklus für Gesamtsystem kombinieren zusätzliche Operationen, Events und Makros ins data dictionary eintragen SoPra 2008 Kap. 4.4: Dynamische Analyse mit FUSION Lebenszyklus (27/30)

28 Kapitel 4.5: Abschluss der Analyse Vorgehensweise in der Analyse Modelle werden nicht strikt nacheinander erstellt Wann ist Analyse abgeschlossen? Vollständige, in allen Details korrekte Dokumente sind selten Manche Details werden erst in der Design-Phase bekannt eingeschränkte Kontrolle von Vollständigkeit und Konsistenz Qualitätskontrolle der Dokumente: Konsistenz Vollständigkeit SoPra 2008 Kap. 4.5: Dynamische Analyse mit FUSION Abschluss der Analyse (28/30)

29 Abschluss der Analyse (Kontrollen 1) Vollständigkeit (alle Anforderungen berücksichtigt?) Alle funktionalen Anforderungen durch Szenarien abgedeckt? Alle möglichen Szenarien im Lebenszyklus enthalten? Jede Systemoperation im Operationsmodell vorhanden? Alle statischen Informationen aus den Systemoperationen im Objektmodell vorhanden? Alle Informationen/Begriffe im data dictionary? SoPra 2008 Kap. 4.5: Dynamische Analyse mit FUSION Abschluss der Analyse (29/30)

30 Abschluss (Kontrollen 2) Konsistenz (Modelle untereinander verträglich?) Passen Klassen, Assoziationen und Attribute aus dem Operationsmodell mit dem Objektmodell zusammen? Passt das Operationsmodell zum data dictionary? Systemoperationen (aus Lebenszyklus) im Operationsmodell mit den selben Parametern definiert? Doppelte Funktionalität in Systemoperationen vermieden? Wenn Systemoperationen neue Objekte erzeugen, setzen sie deren Attribute und Assoziationen sinnvoll? SoPra 2008 Kap. 4.5: Dynamische Analyse mit FUSION Abschluss der Analyse (30/30)