Objektorientierte Analyse und Design (OOAD) mit der Unified Modeling Language (UML) Flashcards
Definition Objektorientierung
Gegenstände der Realität werden als Objekte abgebildet
Polymorphismus
Verschiedene Arten von Objekten können auf die gleiche Nachricht reagieren, welche Methode tatsächlich ausgeführt wird, entscheidet sich erst zur Laufzeit (Late Binding)
Objekte haben…
- Zustand (Werte der Attribute)
- Verhalten (Methoden beschreiben, wie auf Nachrichten reagiert wird)
- Identität (zwei Objekte mit identischen Werten sind zwei einzigartige Objekte)
Kapselung
Informationen werden vor einem Teil der Applikation verborgen gehalten
Zweck OOAD
- Software soll funktionale Anforderungen erfüllen
- dazu kommen nicht-funktionale Anforderungen (Plattformen, Wartbarkeit, Erweiterbarkeit, Skalierbarkeit, Wiederverwendbarkeit…)
- techn. Anforderungen: z.B. Spaghetticode und Seiteneffekte vermeiden
- Anforderungen analysieren und Aufbau entwerfen, BEVOR Code geschrieben wird
3 mögliche(!) Schritte zu guter Software
1) Software macht, was Kunde möchte
2) Anwenden von OO-Prinzipien für Flexibilität (ein Konzept pro Klasse, keine leeren Attribute)
3) Anstreben eines wartbaren und wiederverwendbaren Designs (bei Änderungen möglichst wenige Klassen ändern müssen, delegieren von Aufgaben)
Separation of Concerns
Gesamtcode wird aufgeteilt, sodass jeder Teil für eine bestimmte Aufgabe zuständig ist
CRC-Cards
Class-Responsibility-Collaboration Cards trennen Zuständigkeiten von Klassen
Vorteile OOAD
- Kunde wird zufriedengestellt (Programm funktioniert und kann verändert werden)
- Programm kann für nächsten Kunden wiederverwendet werden
Unified Modeling Language (UML)
Graphisches Modell um Anforderungen an Softwaresystem und technischen Aufbau des Systems besser zu verstehen
Vorteile UML
Eindeutigkeit: Festlegen beim Zeichnen
Verständlichkeit: gibt komplexe Zusammenhänge wieder
Ausdrucksstärke: Fokus Gesamtsystem oder Teilaspekt
Standardisierung: vereinfach Kommunikation in Projekten
Plattformunabhängigkeit: keine Festlegung
Kriterien, welches der 14 UML-Diagrammtypen genutzt werden soll
Zweck: Wozu dient das Modell?
Zielgruppe: Für wen ist es gedacht?
Kosten/Nutzen-Verhältnis des Modells
UML-Diagrammarten
- Verhaltensdiagramme (weiter: Interaktionsdiagramme)
- Strukturdiagramme
Weitere Methoden, die bei Analyse und Design zum Einsatz kommen
- Screen-Prototypes (GUI für Anforderungsanalyse)
- Use-Case-Dokumente (verbal formuliert oder UML für Anwender oder Entwickler)
Objektorienterte Analyse
Verstehen der Kundenanforderungen durch Sprechen, Fragen stellen, Diskutieren, versch. Blickwinkel
Definition Use Case (Aufteilen der Gesamtaufgabe)
- Anwendungsfall
- Ein Akteur interagiert mit dem zu entwerfenden
System mit einer bestimmten Absicht - dafür: Semi-Strukturierte Methode der Dokumentation
Eigenschaften Use Case (4)
1) Bringt dem Anwender einen Nutzen
2) Hat definierten Anfang und definiertes Ende
3) Wird von einem Akteur außerhalb des Systems initiiert
4) Muss alle Pfade vom Ausgangspunkt bis zum Ziel enthalten
Inhalt Use Case Dokument
- Name (ID)
- Status
- Version
- Description
- Actors
- Basic Flow und Alternative Flow
- Trigger
- Pre- und Postconditions
- Related Use Cases
Prinzipien Use Case (Diagramme)
1) encapsulate what varies
2) understand requirements (Entwickler muss System verstehen)
3) code to interfaces rather that to an implementation (Code einer Klasse soll möglichst unabhängig vom Code anderer Klassen sein)
Domänenanalyse
- Beschreiben der Aufgabe in Sprache des Anwenders
- Sammeln von Informationen (Kunde, Anwender, existierende Systeme, Theorien und Techniken der Domäne)
Use-Case-Diagramme
- beschreiben auf hoher Ebene Funktionalität eines Systems (Was?, aber nicht Wie?)
- Abstrahieren von Details
- geben keine Reihenfolge der Use Cases vor
- Zweckmäßigkeit statt Vollständigkeit
Bestandteile Use Case Diagramm
- großes Rechteck definiert Systemgrenze
- Akteur (EXTERNER Benutzer oder EXTERNES System interagiert mit System)
- Anwendungsfall (Funktionalität des Systems, welches aus einer Menge von Aktionen besteht)
Assoziation
- Bezeichnung zwischen Akteur und Anwendungsfall
- gerichtet: mit Pfeilspitze und Multiplizität
- ungerichtet: lässt offen, ob Akteur den Use Case initiieren kann
Multiplizität
Gibt an, wie viele Objekte bei einem Aufruf des Use Cases von wie vielen Akteuren bearbeitet werden können (ist immer zu einem bestimmten Zeitpunkt zu verstehen)
Beziehungen zwischen Anwendungsfällen
<>: gemeinsame Funktionalität wird in mehreren Use Cases verwendet
<>: ein Use Case erweitert einen anderen
Generalisierung (Vererbung)
- zwischen Akteuren mit Pfeilen (unausgefüllte Spitze)
- zwischen Use Cases möglich, aber unüblich
Klassendiagramme
- beschreiben Struktur des OO-Systems
- für Diskussion mit Anwender (auf wesentliche Klassen beschränken)
- Vorlage für Entwicklung (müssen detailliert sein)
- im Use-Case-Dokument: Substantive meist Klassen, Verben meist Methoden
Elemente Klassendiagramm
- Klassen (Attribute und Methoden)
- Generalisierungspfeile (von spezielle zu allgemeine Klasse)
Assoziation und Kardinalität
Assoziation: Beziehung zwischen zwei Klassen
Kardinalität: wie viele Objekte können an Assoziation beteiligt sein
- kann mit Namen und Dreieck für Leserichtung versehen werden
Aggregation (Raute an Pfeil NICHT ausgefüllt)
Form der Assoziation, bei der sich ein Objekt der einen Klasse u.a. aus einem Objekt der anderen Klasse zusammensetzt (Bsp.: Wohnzimmer aus Couch und Tisch)
Komposition (Raute an Pfeil aufgefüllt)
- Aggregation, bei der ein Objekt untrennbar mit einem Ganzen verbunden ist (wenn es das Ganze nicht mehr gibt, gibt es auch die Teile nicht mehr) –> Baum aus Stamm und Ast
- Multiplizität auf Seite des Ganzen immer 1 (kann daher weggelassen werden)
- Klasse des Ganzen erzeugt ihre Teile selbst
Grundregeln Klassendesign
- was sich ändern kann wird möglichst in einer einzigen Klasse gekapselt
- Gemeinsamkeiten werden in Klasse auf höherer Ebene “zusammengezogen”
Detaillierungsgrad von Klassendiagrammen
- hängt vom Zweck des Diagramms ab
- erweiterbares Klassendesign wichtig
- sollten alle relevanten Klassen, Attribute und Methoden enthalten (müssen nicht zwingend alle Notationselemente enthalten)
Attribute in Klassendiagrammen
- alles außer Attributname ist optional
- Klassenattribute werden unterstrichen
- Datentyp nach :
- Defaultwerte nach =
- Attribute, die nicht gespeichert, sondern berechnet werden, werden mit / gekennzeichnet (z.B. Alter aus Geburtsdatum)
Sichtbarkeiten von Attributen
+ public, für alle Klassen sichtbar
# protected, für eigene Klassen sichtbar
- private, für andere Klassen unsichtbar
~ package, innerhalb des Paketes sichtbar
Multiplizitäten in Klassendiagrammen
- wird bei einem Attribut in Form [4], [0..6], [1..*] angegeben
- Attribute, die Assoziation implementieren werden im Klassendiagramm weggelassen (Multiplizität steht statt Assoziation)
Eigenschaften von Attributen
- am Ende der Attributzeile in geschweiften Klammern
- {readOnly} Attributwert kann nicht verändert werden
- {unique} Jeder Attributwert darf bei maximal einem Objekt vorkommen
Reihenfolge / Syntax Notationselemente für Attribute
Sichtbarkeit / Name : Typ Multiplizität = Defaultwert {Eigenschaft}
Eigenschaften von Methoden
- in für elementare Datentypen
- inout für komplexe Datentypen
- {sequence} –> Tupel: Werte sind geordnet
- {bag} –> Menge: Werte sind ungeordnet, Reihenfolge nicht definiert
Reihenfolge / Syntax Notationselemente für Methoden
Sichtbarkeit Name (Parameterliste) : Rückgabetyp {Eigenschaft}
Methoden in Klassendiagrammen
- Parameter enthalten mindestens Name und Typ, durch Komma voneinander getrennt
- Multiplizität in Parameterliste definiert, aus wie vielen Teilen ein Parameter bestehen darf
- Überladene Methoden werden mehrfach aufgeführt
Reflexive Assoziationen
- Rollen besonders wichtig (z.B. Chef ist selbst auch ein Mitarbeiter)
- Sichtbarkeit von Rollen kann definiert werden
Assoziationen: XOR
Objekte der beteiligten Klassen dürfen nur an einer der Assoziationen beteiligt sein
Assoziationen: Navigierbarkeit
- in welcher Richtung haben Assoziationen Kenntnis voneinander (Pfeilrichtung)
- Objekte einer Klasse können als Attribut ein Objekt einer anderen Klasse bekommen
- Assoziation mit x verbietet Navigierbarkeit
- Assoziationen ohne Pfeil und x spezifizieren Navigierbarkeit gar nicht
Assoziationen: Qualifizierer
- geben an, anhand welcher Attribute einem Objekt der Klasse ein Objekt der assoziierten Klasse zugeordnet wird
Assoziationen: Assoziationklassen
- Modellierung der Eigenschaften einer Assoziation
- gehören zu keiner Klasse (nur Assoziationsklasse)
- bei m:n-Assoziationen
- Umwandlung in normale Klassen nötig
Assoziationen: n-äre Assoziationen
- Beziehungen zwischen zwei oder mehr Klassen
- Symbol: Raute
- keine Navigierbarkeit oder Qualifizierer
- Multiplizitäten beziehen sich auf Kombinationen aller anderen Objekte (Untergrenze meist 0)
n-äre Assoziationen nicht praxisgängig weil…
- Reduzieren Komplexität nicht so wie binäre Assoziationen (Sinn von Modellen)
- können in mehrere binäre Assoziationen aufgelöst werden
- nicht direkt implementierbar
Abhängigkeiten in Klassendiagrammen
- Klasse kann nicht ohne andere Klasse implementiert werden
Gründe der Abhängigkeit: - <>: Methodenaufruf
- <>: Erzeugung von Instanzen
Generalisierung in Klassendiagrammen
- UML erlaubt Mehrfachvererbung (Java nicht)
- Vererbungsbeziehungen können zu Generalisierungsgruppen zusammengefasst werden (z.B. Anspruch und Eigentum)
Generalisierung in Klassendiagrammen: Eigenschaften
- Unterklassen umfassen zusammen alle Objekte der Oberklasse oder nicht ({complete}, {incomplete})
- Unterklassen überlappen sich oder nicht ({overlapping}, {disjoint})
Generalisierung in Klassendiagrammen: Stereotypen
- modellieren nicht Realität, sondern beschreiben andere Notationselemente
- <>: Aufzählungstypen
- <>: Klassen stellen statische Attribute und Methoden für andere Klassen bereit (meist abstrakt)
Templates in Klassendiagrammen
- Vorlage für Klasse (abhängig von Parameter)
- Typ des Parameters beliebig (kein Parameter = beliebige Klasse)
- um Datenstrukturen für beliebige Klassen zu definieren (Stapel, Listen, Mengen)
- gestrichelter Pfeil von Klasse zu Template (Binden der Übergabe)
Schnittstellen in Klassendiagrammen
- Vorschrift, welche Attribute und Methoden eine Klasse implementieren muss (implementieren selbst keine), die Schnittstelle implementiert
- <>
Implementierung von Schnittstellen
- andere Klasse können Methoden und Attribute der implementierenden Klasse aufrufen (muss diese aber dann implementiert haben)
- realisierte Schnittstelle: Modellierung als Ball-End
- benötigte Schnittstelle: Modellierung als Socket-Symbol
Aktivitätsdiagramme
- beschreiben Verhalten von Systemen
- zur Detaillierung von Use Cases
- Modellierung von Geschäftsprozessen
- Abläufe in Systemen beschreiben
- können sogar Algorithmen beschreiben
Sequenzdiagramme
- gleiche Anwendungsfelder wie Aktivitätsdiagramme
- Schwerpunkt liegt auf Chronologie der ausgetauschten Nachrichten zwischen Akteuren und System
- sobald es parallele Prozesse gibt, muss Aktivitätsdiagramm genommen werden
- Wie und in welcher Reihenfolge wird kommuniziert?
Synchrone Kommunikation
findet in Echtzeit statt (ortsunabhängig), z.B. Chat
Asynchrone Kommunikation
findet zeitliche versetzt statt, z.B. Email
