SWT-Übung WS 10/11 26.01.2011 Zusammenfassung

Benutzungsoberfläche Allgemeine Sicht Prototyp der Benutzungsoberfläche Datensicht Funktionssicht

Diverses 1/2 UML - Objektorientierung Vererbung Mehrfachvererbung Polymorphismus Dynamisches Binden Assoziation Unabhängige Objekte Kardinalitäten und Namen „immer an die Pfeilspitze“ Aggregation Spezifikation von Ganzes- und Teile davon Komposition Zerstörung des Gesamten führt zur Zerstörung der Teile

Beziehungen zwischen Objekten Assoziation: „Kennt“-Beziehung, entspricht Beziehung aus ER-Modell hier mit Rollen, Multiplizitäten und Sichtbarkeitsangaben implizieren Attribute vom Typ des jeweiligen Assoziationsendes Beziehungen zwischen OBJEKTen SWT-Übung 21.1.2008

Beziehungen zwischen Objekten Aggregation: Monitor-Objekte sind Teil von „Rechner“-Objekten (z.B. beim Einkauf) – existieren aber auch eigenständig SWT-Übung 21.1.2008

Beziehungen zwischen Objekten Komposition: Display-Objekte sind Teil von genau einem „Notebook“- alleinstehend existieren sie nicht SWT-Übung 21.1.2008

Use Case Diagramm SWT-Übung 23.1.2007

Sequenzdiagramm 1/2 Objektname:Klassenname John:Vermittlung :Angerufener Anrufer anmelden() Bestätigung Nummer_wählen Klingelton Telefon_Klingeln Hörer_Abnehmen Klingelton_beenden Klingeln_beenden Weltwissen_übertragen Kein_Weltwissen_mehr_hören_wollen Verabschiedung_einleiten Verabschiedung_annehmen Verbindung_beenden Auflegen Objektname:Klassenname Durchgängiger logischer Fluss Antworten

Sequenzdiagramme 2/2

Statecharts „Botschaft ([Bedingung]) / Aktion Determinismus! Bezug zu Klassendiagramm!

Diverses 2/2 Konsistenzregeln: Jede in einem Sequenzdiagramm beschriebene Aufrufreihenfolge muss vom Statechart erlaubt sein. Jede Transition im Statechart sollte durch mindestens ein Sequenzdiagramm genutzt werden. Statecharts beschreiben alle möglichen Aufrufreihenfolgen, deswegen beschreiben sie normalerweise mehr als die Überdeckung aller Sequenzdiagramme.

Pattern 1/3 Enthalten Aspekte aus der Sicht der Informatik Bewährte Struktur Effiziente Datenstrukturen Gute Wartbarkeit Möglichkeit der Wiederverwendung Guter Performanz Adapter, Observer (evtl. Singleton) sollten grob bekannt sein!

Pattern 2/3: „Ein Entwurfsmuster gibt eine bewährte generische Lösung für ein immer wiederkehrendes Entwurfsproblem, das in bestimmten Situationen auftritt.” Mustername und Klassifizierung Zweck (kurze Darstellung des Musters), aka “Motivation” (exemplarisches Szenario) Anwendbarkeit (mögliche Verwendungen) Struktur (graphische Darstellung der strukturellen Eigenschaften) Akteure (beteiligte Klassen und Objekte) Konsequenzen (Vor- und Nachteile, Ergebnisse) Beispielcode Bekannte Verwendung Verwandte Muster (Unterschiede, Zusammenarbeit)

Pattern 3: Observer - Beispiel aus Übung: OP-Termin, Terminobserver

Pattern 4: Klassen-Adapter

Pattern 5: Objekt-Adapter

Data Dictionary Operatoren: [ A | B ] – A xor B { A } – unbeschränkte Wiederholung M { A } N – beschränkte Wiederholung, mind. M max N, M oder N kann weggelassen werden  0 bzw. * ( A ) – Option == 0 { A } 1 = Äquivalenz + Sequenz, ohne Reihenfolgenspezifikation! * * Kommentar SWT-Übung 05.11.2007, Andreas Wolff

SA/RT 1/2 „Kontextdiagramm“ = oberstes DFD Beschreibung der Beziehung zur Umwelt genau 1 Prozess („0.“) Keine Speicher Mindestens 1 Schnittstelle DFD 0 – Verfeinerung des Kontextdiagrammes Zerlegung von „0“ in Teilprozesse Verfeinerung der Datenflüsse Speicher DFD 1, DFD 2, DFD 1.1 ... Verfeinerung von Prozessen zu Weiteren Diagrammen (|Prozesse| < 7) oder MiniSpecs

SA/RT 2/2 Realtime-Erweiterung der klassischen SA neben Datenflüssen werden zusätzlich Kontrollflüsse modelliert Kontrollflüsse steuern die Verarbeitung sind diskret nehmen eine endliche Anzahl bekannter Werte an werden als gestrichelte Linien dargestellt einem Datenflussdiagramm kann eine Kontrollspezifikation überlagert sein steuert das Systemverhalten auf der jeweiligen Ebene „schaltet“ die Prozesse durch Zustandsübergangsdiagramm und/oder Entscheidungstabelle (Prozessaktivierungstabelle) beschreibbar dadurch wird das Gesamtmodell zustandsbehaftet

SA/RT

Function Point Kategorieneinteilung zu Produktanforderungen Klassifizierung dieser Zuordnungen Berechnung der unbewerteten Function Points Bewertung der Einflussfaktoren Berechnung der bewerteten Function Points Bestimmung des Aufwandes in MM (mittels empirischer Daten) Aktualisierung der empirischen Daten

Klausur

Klausur

Klausur