Softwaretechnik Lernzettel PDF

Preview

Summary

Warning: TT: undefined function: 32 SwT LernzettelAnwendungsfall und AktivitätsdiagrammAnwendungsfall -> Repräsentieren Systemfunktion zur Unterstützung von Prozessen Akteure -> Repräsentieren Umgebung des Systems -> Schnittstellen zur Umwelt (menschlich oder maschinell) Interag...

Description

SwT Lernzettel Anwendungsfall und Aktivitätsdiagramm Anwendungsfall Akteure

-> Repräsentieren Systemfunktion zur Unterstützung von Prozessen -> Repräsentieren Umgebung des Systems -> Schnittstellen zur Umwelt (menschlich oder maschinell) Interagieren mit Anwendungssystem, um bestimmte Aufgaben durchzuführen und konkrete Ziele zu erreichen

Anwendungsfalldiagramm:

Jeder Anwendungsfall (use case) formuliert in sich abgeschlossene Teilfunktionalität des Anwendungssystems • Optionale Systemgrenze Textuelle Beschreibung • aus Sicht der Akteure • Anwendungssystem als Black-Box betrachtet • Precondition: grenzt Situation ein, in die der Anwendungsfall ausgeführt werden kann bzw. darf - Muss vom System überprüfbar sein • Postcondition: für Akteur relevantes vom System zu erbringendes Ergebnis • Main flow: normaler Ablauf, unter optimalen Bedingungen - Abweichungen werden ausgelagert in: - Alternative flow (alternative Abläufe): Anwendungsfall wird wie beim Normalen Ablauf erfolgreich beendet und Nachbedingung des normalen Ablaufs ist erfüllt - Exceptional flow (Ausnahmesituation): erfolgreicher Ablauf gefährdet, es wird gesonderte Nachbedingung angegeben Beziehung zwischen Anwendungsfällen Include-Beziehung • Verschiedene Anwendungsfälle haben selbe Teilfunktionalität • Teilfunktionalität wird zur Redundanzvermeidung in separaten Anwendungsfall beschrieben, der verwendet werden kann • „A benutzt durch B spezifizierte Teilfunktionalität“

Extend-Beziehung • Erweiterung eines Anwendungsfalls unter bestimmten Bedingungen • „optionale Erweiterung“ • Textuell durch Extension Point markiert • Funktionalität von A kann unter bestimmten Bedingungen erweitert werden - Optionale Ergänzung des Basisanwendungsfalls A

Wann include, wann extend? - Include komplettiert Basisanwendungsfall durch zusätzliche Funktionalität (Pfeil zum Inkludierten è Vermeidung von Redundanz und erlaubt Wiederverwendung von Teilfunktionalitäten - Extend ist optional, Basisanwendungsfall ergibt auch ohne zusätzliche Funktionalität sinnvolles Ergebnis (Pfeil zum Basisanwendungsfall) è sichert Flexibilität und einfache Erweiterbarkeit Aktivitätsmodellierung • Modelliert Ablaufmöglichkeiten (z.B. komplexerer Anwendungsfälle) • Aktion startet nur, wenn alle vorangehenden Aktionen abgeschlossen sind

• • •

Parallelisierungsknoten: Aufspaltung in mehrere parallel abarbeitende Zweige Aufrufaktion : enthält eigene Aktion, die nicht ausgearbeitet ist (für die jetzige Aktivität nicht relevant) Ablauf-Ende: beendet nur den einen Ablaufzweig, nicht die Aktivität

UML Objektdiagramm und Klassendiagramm Was ist Strukturmodellierung: • Modellierung, der für das Anwednungssystem relevanten materiellen und immateriellen Dinge (Gegenstände und Sachverhalte) + ihrer Beziehungen • Insbesondere Daten und Informationen, wie: - Einzelmerkmale (Attribute) - Fähigkeiten (Operationen) - Beziehungen (Assoziationen) Strukturmodellierung mit UML: • Objekte (Zustand, Verhalten, Verbindung) • Klassen (Attribute, Operation, Assoziation, Generalisierung) • Pakete • OCL Objekte • Modellieren konkrete „Dinge“ (der Realwelt, der Software, …) • Charakterisiert durch Identität, Zustand und Verhalten

Eindeutige „Identifikation“, meist implizit

zu bestimmten Zeitpunkt beobachtete Eigenschaft

Reaktion des Objekts auf Ereignisse (Nachrichten, …)

Gleichheit von Objekten Wertegleichheit: • Verschiedene Objekte besitzen die selben Attribute (Instanz ein und derselben Klasse) und haben gleiche Attributwerte und Verbindungen Referenzielle Gleichheit: • Verschiedene Verbindungen verweisen auf dasselbe Objekt Objektverhalten Objekte reagieren, indem sie: • Zustand ändern • Verbindungen lösen oder neu eingehen • Selbst Ereignisse auslösen oder Nachrichten an Objekte senden Klassen • Charakterisiert durch Klassenname, Attribut und Operation • Beschreibt Objekte mit gemeinsamen Eigenschaften • Von Klasse beschriebene Objekte sind Instanzen dieser Klasse Aufbau: • Erster Buchstabe und Wortanfänge groß • Keine Umlaute • Fettdruck, nicht unterstrichen

Attribute • Attributname: kleingeschrieben, Wortanfänge groß • Typ: - Datentyp wie Boolean, Integer, Char, String, Date - Anwendungsspezifische wie Personalnummer oder KundenNr. - Auch Klassen möglich • Sichtbarkeit: public +, private -, protectet # • Eigenschaften: changeable, frozen, … Operationen • Signatur: Operationsname, Parameter inkl. Übergabewert und Typ/Ereignistyp - in => Eingabe-Werteparameter - inout => Eingabe-Referenzparameter - out => Ausgabe Referenzparameter, in Operation erzeugt • Eigenschaften: abstract, isQuery, , , … Eine Klasse, viele Objekte (Instanzen) • Benannte Instanz mit unbekannter Klasse - Objektname • Benannte Instanz mit bekannter Klasse - Objektname : Klassenname • Unbekannte Instanz mit bekannter Klasse (anonymes Objekt) - : Klassenname Assoziation - Beschreibt mögliche Objektverbindungen - Assoziationsname gibt an, welcher Sachverhalt mit Verbindung modelliert wird (großgeschrieben) - Verbindung zweier Klassen = binäre Assoziation - Selbe Klasse = reflexive (binäre) Assoziation - Mehr als wie Klassen (selten) = n-äre Assoziation Assoziationsenden beschreiben Rollen - Rollenname: beschreibt den Grund der Beteiligung an einer Verbindung (kleinges.) - Multiplizität (Kardinalität) è Gibt an, wie viele Instanzen der Klasse verbunden sein können Fest z.B. 1 oder 5 Bereich 1..5 oder 0..1 Stern (*) bedeutet 0..*(unendlich) è 1:1; 1:n; n:m Mehrwertige Assoziation: mindestens Multiplizität größe 1 Generalisierung - Alles, was für die Instanzen einer allgemeinen (Ober-)Klasse gilt, trifft auch für die Instanzen ihrer spezialisierten (Unter-)Klassen zu - Jede Instanz der Unterklasse ist auch Instanz der Oberklasse - Unterklasse erbt alle Attribute, Operationen und Assoziationen

Assoziation mit „Nebenbedingungen“ - Hierarchie auf verbunden Instanzen Aggregation: - Teil-Ganzes-Verhältnis - Ganzen-Instanz hat Verantwortung für Teil-Instanzen - Objekt kann bei Aggregation gleichzeitig auch Teil anderer Objekte sein => besondere Aufmerksamkeit beim zerstören

Komposition: - Schärfere Semantische Bedingung als bei Aggregation - Teil-Instanzen: - Dürfen nur von Operationen der Ganzes-Klasse entfernt oder ausgetauscht werden - Dürfen nicht Teil anderer Kompositionen sein - Werden beim Zerstören des „Ganzes-Objekts“ automatisch (kaskadierend) mit zerstört - Existenz somit abhängig von Existenz des Ganzes-Objekt

Assoziationsklassen - Geben Assoziationen „Klasseneigenschaften“ - Können dadurch mit Attributen, Operationen und Elementen ergänzt werden - Repräsentieren „ihre Assoziation und muss deshalb auch so heißen

UML Interaktionsdiagramme Objekte im Laufe der Zeit … - Objektdiagramm ist Schnappschuss (ein bestimmter Zeitpunkt) - Feste Anzahl dargestellter Objekte, Zustand ist statisch - Jedoch ändern Objekte ihren Zustand mit der Zeit Sequenzdiagramm (Raum und Zeit) - Min. zwei Dimensionen nötig, zur Darstellung einer Interaktion è Struktur (welche Objekte in welchem Zustand) è Zeit (wann welche Nachricht gesendet/empfangen wird) - Hier: Horizontal = Objekt-Achse Vertikal = Zeitachse

-

Verhaltensaktivierung durch Operationsaufruf (Nachricht) Synchrone Nachricht = Pfeil mit ausgefüllter Spitze

Objektlebenszyklus - Objekt wird erzeugt (instanziiert) - Ändert durch Aufrufe der Operation (in eigener Klasse definiert) seinen Zustand - Wird zerstört Kombinierte Fragmente - Zusammenhängende Teile einer Interaktion (im Sequenzdiagramm eingerahmt) - Interaktionsoperatoren steuern, wie kombinierte Fragmente ablaufen sollen - Oben links steht Art des Operators (opt, loop, usw.) -> Schachtelung möglich - Bedingung in Interaktionsoperatoren -> Boolsche Ausdrücke In eckiger Klammer – [prüfen == true]

Interaktionsausdrücke: - Kann Anzahl der Iterationen bestimmen, ist allerdings optional Interaktionsoperatoren: - Opt: Optionale Interaktionsteile - Loop: Schleife - Alt: Alternative Fragmente/Interaktionsschleife - Break: Abbruchfragment Synchrone Nachricht - Aufrufer wartet untätig, bis Ergebnis zurückkommt und fährt erst dann mit Beschäftigung fort - Zeitintervalle, in denen das gilt, werden durch Ausführungssequenzen dargestellt (schmales Rechteck auf Lebenslinie) - Rückgabenachricht als Antwort durch gestrichelte Pfeile dargestellt (Name der Aufrufnachricht wird ohne Parameter wiederholt Asynchrone Nachricht - Mehrere Objekte gleichzeitig aktiviert -> Nebenläufigkeit - Bsp. Brief: Schreiber fährt nach Absenden fort (muss erst warten, wenn Antwort benötigt) - Pfeil mit offener Spitze - Aktives Objekt => explizit, dass Sender nicht wartet Kommunikationsdiagramm (Raum und Reihenfolge) - Quasi Objektdiagramm, in dem zusätzlich ablauforientiertes Verhalten modelliert ist - Nachrichtenaustausch an Objektverbindungen notiert - Nachricht-Richtung und Art (Synchron, Asynchron, Erzeugung, Rückgabewert) durch Pfeile visualisiert

-

Da keine Zeitachse, muss Abfolge der Nachrichten durch Nummerierung verdeutlicht werden Während Ablauf erzeugtes oder zerstörtes Objekt mit {new} oder {destroyed} kennzeichnen, wenn beides, dann {transient}

Nummerierung - Hierarchische Dezimalnotation - Für jede Ausführungsspezifikation um einen Dezimalpunkt erweitern - Antwortnachricht hat gleiche Nummerierung wie Anfrage Sequenz vs. Kommunikation -

Bis auf wenige Eigenschaften äquivalent Abfolge der Nachrichten in Sequenz besser zu erkennen und kombinierte Fragmente besser darstellbar Kommunikationsdiagramm bietet beliebige Anordnung von Objekten und somit mehr Freiheit. Objekte mit intensiver Verbindung beieinander Platzierbar. Anordnung wie im Klassendiagramm steigert Wiedererkennungswert

Zustandsdiagramm -

Zustände abstrahieren Teilmengen möglicher Attributwerte und mögliche Kombinationen konkreter Objektverbindungen Eigenschaften außer Acht lassen, die Verhalten nicht beeinflussen Zustände als abgerundete Rechtecke

Ereignisse - Objekte ändern Attributwerte durch Ausführung von Operationen - Empfangen einer Nachricht ist spezielles Ereignis - Eintreten eines bestimmten Sachverhalts zu bestimmtem Zeitpunkt (vernachlässigbare Zeitdauer) -> mit Ereignisnamen versehen 1. Nachrichtsempfangs- (Aufruf-)Ereignis (call even): Veranlasst Ausführung einer Operation 2. Änderungsereignis (change event): Änderung, die für das zustandsorientierte Verhalten relevant ist 3. Zeitereignis (time event): Ablauf einer bestimmten Zeitperiode oder Eintritt eines bestimmten Zeitpunktes Zustandsübergänge (Transitionen) - Verhalten eines Objektes variiert je nach aktuellem Zustand und eintretendem Ereignis (trigger) - Entsprechend muss Verhalten für jede Kombination aus Zuständen und Ereignissen spezifiziert werden - Reaktion auf Eintreten eines Ereignisses = Übergang - Modellieren, wie Instanzen der Klasse abhängig ihres Zustandes auf Eintreten von Ereignissen reagieren (=> reaktives oder zustandsabhängiges Verhalten) - Pfeil mit offener Spitze

Wächterbedingung (Wächter) - Auslösung eines Zustandsübergangs hängt manchmal von konkreten Dingen (z.B. Werten) ab - Bezieht sich auf Parameter des Auszulösenden, sowie auf Attribute und Verbindungen des betroffenen Objekts - In eckigen Klammern hinter Ereignisname Konkurrierende Zustandsübergänge - Verhalten muss deterministisch sein - Bei diesen muss deshalb Wächterbedingung bei beiden mitgegeben werden, die sich unterscheidet Entry- und Exit-Verhalten Entry: Wird ausgeführt, nachdem eingehender Zustand Übergang getriggert und durchgeführt wurde Exit: ausgeführt, wenn ausgehender Zustandsübergang getriggert und durchgeführt wird (vor Aktion des ausgehenden Zustandsübergangs) Objektlebenszyklus Objekt wird instanziiert Verändert und Zustand Und wird irgendwann zerstört Vom Initialzustand muss ein Zustandsübergang ohne Ereignis und Wächterbedingung zum Ausgangszustand des Objektes führen (=>Objekterzeugung) Reflexive Zustandsübergänge - Entry- und Exit-Verhalten unterschiedlich bei reflexiven Übergängen und internen Transitionen - Bei reflexiven wird Exit-Verhalten, dann Aktion des Zustandsübergangs und dann Entry-Verhalten ausgeführt - Bei interner Transition wird nur das zugeordnete Verhalten, nicht aber Entry- oder Exit ausgeführt Domänenklassen (ermitteln und modellieren) - Domäne = bestimmtes Geschäftsfeld bzw. Gegenstandsbereich - Domänenklassen modellieren für das Anwendungssystem relevante Gegenstände und Sachverhalte der Domäne - Auf jede Klasse des Domänenmodells muss in mindestens einem Anwendungsfall Bezug genommen werden - Nur Attribute spezifiziert, aber keine Operationen Generalisierungsbeziehung - Klassen nach gemeinsamen Attributen und Assoziationen durchsuchen - Attribute und Assoziationen möglich hoch in Generalisierunshierarchie anordnen

Domänenklassen bereinigen - Nach irrelevanten Elementen durchsuchen - Klassen mit einem Attribut inspizieren (Attribut anderer Klasse zuteilbar und entfernbar) -> weisen oft auf zu feine Klassenzerlegung hin - Jede Domänenklasse sollte mehr als ein Attribut besitzen - Ableitbare Attribute und Assoziationen als solche markieren - Für jede Domänenklasse existiert mehr als ein Objekt in der Problemwelt (Normalfall) Benutzungsoberfläche skizzieren - Auf Grundsätzliche Eigenschaften der Benutzungsoberfläche konzentrieren, ohne bei Layout und Navigationsmöglichkeit ins Detail zu gehen CRUD – Matrix - Create, Read, Update, Delete - Hier wird die Nutzung von Instanzen und Domänenklassen durch einen Anwendungsfall modelliert - Nur direkt erkennbaren Nutzen modellieren Softwarespezifizierung Modell zu Modell Transformation - Anwendungsspezifikation => Softwarespezifikation - Softwarespezifikation => Grobentwurf - Grobentwurf => Feinentwurf - Feinentwurf => Implementation (Model2Code) Softwarespezifikationstätigkeiten - Kopieren Domänen-Klassen in Entitätsklassen - Umsetzung von Anwendungsfällen in Anwendungsfall-Funktionsklassen (AF-Klassen) - Zusammenführen von AF- und Entitätsklassen - Präzise für Entwickler beschrieben „Was“ zu leisten ist (nicht „Wie“!!!) o Funktionale Anforderung in Softwarespezifikation verankert o Qualität- und Realisierungsanforderung bleiben außen vor Klassenmodell der Softwarespezifikation Entitätsklassen (entity class) – Information - Repräsentieren langlebige Informationen - Umfassen alle Domänenklassen der Anforderungsspezifikation Übertragung von Domänen- in Entitätsklassen: - Kopieren und mit Stereotypsymbol markieren - Im weiteren Verlauf Attribute und Assoziationen verfeinern, sowie Operationen definieren - Ggf. neue Entitätsklassen für eher technische Anforderungen Domänenklassenmodell sollte sich weitgehend strukturgleich wiederfinden

Anwendungsfall-Funktionsklassen (application function class) – Funktionalität - Bündeln Interaktionen zwischen Akteuren und Anwendungssystemen - Verkapseln die den Anwendungsfällen zugrundeliegende fachliche Logik - Pro Anwendungsfall eine Anwendungs-Funktionsklasse - Repräsentation von Akteur gesteuerten Modifikationen - Kontrolle der an den Anwendungsfall beteiligten Entitätsklassen => Operationen aus Verhaltensmodellierung Klassendiagramm der SW-Spezifikation - Abhängigkeiten zwischen AF- und Entitätsklassen aus CRUD-Matrix Verhaltensmodell der Softwarespezifikation - Interaktionsdiagramme – „Black-Box-Sicht“ in „Grey-Box-Sicht“ verfeinern - AF und E-Klassen arbeiten zusammen, um Funktion für Akteure zu erbringen - Standard-Operatoren verwenden - Klassenweite fachliche Operationen zufügen Ablaufverhalten von Anwendungsfällen - Operationale Spezifikation, „ausführbar“ als Interaktion zwischen Akteuren und Spezifikationsklassen (Standart-)Operatoren - Präzisierung des Ablaufverhaltens Entitätsklassen: erzeuge(), zerstoere(), gib(), … AF-Klassen: - () - PraesentiereName() - Selektiere() - Praesentiere() - Modifiziere() - Pruefe() Spezifikation von Operationen - Vor und Nachbedingung einer Operation ordnen Objektkonstellation ein boolsches Ergebnis zu...