wieerwill/Informatik
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Feinentwurf hydrated

Browse Source
This commit is contained in:
WieErWill 2021-03-15 20:56:14 +01:00
parent 560e6aa01c
commit 0469d41760
2 changed files with 111 additions and 321 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

BIN
Softwaretechnik - Cheatsheet.pdf
View File

Binary file not shown.

432
Softwaretechnik - Cheatsheet.tex
View File

@ -331,28 +331,27 @@
\end{itemize*} \end{itemize*}
Blockdiagramm Blockdiagramm
\begin{itemize*} \begin{itemize*}
\item Klassisches Beschreibungsmittel für Systemaufbau \item Klassisches Beschreibungsmittel für Systemaufbau
\item Nicht Teil von UML \item Nicht Teil von UML
\end{itemize*} \end{itemize*}
Konfigurationsdiagramm
\begin{itemize*}
\item meistverbreitetes Hilfsmittel zur Beschreibung der physikalischen Verteilung von System-Komponenten
\item Nicht Teil von UML
\end{itemize*}
Verteilungsdiagramm (UML deployment diagram) Konfigurationsdiagramm
\begin{itemize*} \begin{itemize*}
\item Darstellung der Hardwaretopologie \item meistverbreitetes Hilfsmittel zur Beschreibung der physikalischen Verteilung von System-Komponenten
\item Zuordnung von Artefakten zu Hardwareeinheiten (Knoten) \item Nicht Teil von UML
\item Kommunikationsverbindung und Abhängigkeiten zwischen Knoten \end{itemize*}
\item Relativ spät im Projekt Installation / Wartung des Systems
\end{itemize*} Verteilungsdiagramm (UML deployment diagram)
\begin{itemize*}
\item Darstellung der Hardwaretopologie
\item Zuordnung von Artefakten zu Hardwareeinheiten (Knoten)
\item Kommunikationsverbindung und Abhängigkeiten zwischen Knoten
\item Relativ spät im Projekt Installation / Wartung des Systems
\end{itemize*}
\newpage \newpage
\section{Analyse} \section{Analyse}
Funktionale Anforderungen - Was soll es tun? Funktionale Anforderungen - Was soll es tun?
\begin{itemize*} \begin{itemize*}
\item Was leistet das System \item Was leistet das System
@ -651,7 +650,7 @@
\item[Fan-in] Anzahl der Stellen, wo Kontrollfluss auf das betrachtete Modul M übergeht + Anzahl globaler Variablen, die in M zugänglich sind \item[Fan-in] Anzahl der Stellen, wo Kontrollfluss auf das betrachtete Modul M übergeht + Anzahl globaler Variablen, die in M zugänglich sind
\item[Fan-out] Anzahl von Stellen, an denen M andere Module aufruft + Anzahl der globalen Variablen, die von M verändert werden \item[Fan-out] Anzahl von Stellen, an denen M andere Module aufruft + Anzahl der globalen Variablen, die von M verändert werden
\end{description*} \end{description*}
\begin{itemize*} \begin{itemize*}
\item Heuristik Kopplung / Kohäsion \item Heuristik Kopplung / Kohäsion
\begin{itemize*} \begin{itemize*}
\item Hoher Fan-out bedeutet hohe Kopplung $\rightarrow$ minimieren \item Hoher Fan-out bedeutet hohe Kopplung $\rightarrow$ minimieren
@ -659,7 +658,6 @@
\end{itemize*} \end{itemize*}
\end{itemize*} \end{itemize*}
Prinzipien des OO-Entwurfs Prinzipien des OO-Entwurfs
\begin{itemize*} \begin{itemize*}
\item Keep it simple stupid (KISS) \item Keep it simple stupid (KISS)
@ -869,51 +867,42 @@
\end{itemize*} \end{itemize*}
\item Kontrollfluss \item Kontrollfluss
\item Dokumentation \item Dokumentation
\begin{itemize*} \begin{itemize*}
\item Verständlich aus Sicht des Lesers formulieren (Glossar) \item Verständlich aus Sicht des Lesers formulieren (Glossar)
\item Das Warum beschreiben (Entwurfsentscheidungen) \item Das Warum beschreiben (Entwurfsentscheidungen)
\item Annahmen, Voraussetzungen, Randbedingungen \item Annahmen, Voraussetzungen, Randbedingungen
\item Notation erklären oder Standards verwenden (UML) \item Notation erklären oder Standards verwenden (UML)
\item Auf Zweckdienlichkeit prüfen, Reviews durchführen \item Auf Zweckdienlichkeit prüfen, Reviews durchführen
\item Verschiedene Sichten für verschiedene Zielgruppen \item Verschiedene Sichten für verschiedene Zielgruppen
\end{itemize*}
\end{itemize*} \end{itemize*}
\end{itemize*}
Schicht Schicht
\begin{itemize*} \begin{itemize*}
\item Gruppe von Subsystemen in der Zerlegungshierarchie \item Gruppe von Subsystemen in der Zerlegungshierarchie
\item Verwandte Dienste \item Verwandte Dienste
\item Ähnlicher Abstraktionsgrad \item Ähnlicher Abstraktionsgrad
\item Abhängigkeit nur von darunter liegenden! \item Abhängigkeit nur von darunter liegenden!
\end{itemize*} \end{itemize*}
Repository (Depot, blackboard) Repository (Depot, blackboard)
\begin{itemize*} \begin{itemize*}
\item Zentrale Datenhaltung \item Zentrale Datenhaltung
\item Anwendungen tauschen Daten nur über Repository aus \item Anwendungen tauschen Daten nur über Repository aus
\item Kontrollfluss z.B. über Signale oder Semaphore \item Kontrollfluss z.B. über Signale oder Semaphore
\item Gut für datenintensive Verarbeitungsaufgaben geeignet \item Gut für datenintensive Verarbeitungsaufgaben geeignet
\end{itemize*} \end{itemize*}
Peer-to-peer Peer-to-peer
\begin{itemize*} \begin{itemize*}
\item Gleichberechtigte Partner, Föderation \item Gleichberechtigte Partner, Föderation
\item Verteilte kommunizierende Subsysteme \item Verteilte kommunizierende Subsysteme
\item Orts- und Umgebungsunabhängigkeit \item Orts- und Umgebungsunabhängigkeit
\end{itemize*} \end{itemize*}
\newpage \newpage
\section{Feinentwurf} \section{Feinentwurf}
%| Analyse-Modell | Entwurfs-Modell |
%| -\item | -\item |
%| Fachliche Domäne | Lösungsdomäne |
%| Teilweise unvollständig in Attributen und Operationen | Vollständige Angabe aller Attribute und Operationen |
%| Datentypen und Parameter können noch fehlen | Vollständige Angabe von Datentypen und Parametern |
%| Noch kaum Bezug zur Realisierungssprache | Auf Umsetzung in gewählter Programmiersprache bezogen |
%| Keine Überlegungen zur Realisierung von Assoziationen | Navigationsangaben, Qualifikation, Ordnung, Verwaltungsklassen |
%| | Entscheidung über Datenstrukturen, Anbindung GUI |
Schließen der Lücke zwischen Grobentwurf und Implementierung Schließen der Lücke zwischen Grobentwurf und Implementierung
\begin{itemize*} \begin{itemize*}
\item Identifizieren und Entwerfen von Klassen der Lösungsdomäne \item Identifizieren und Entwerfen von Klassen der Lösungsdomäne
@ -921,78 +910,53 @@ Peer-to-peer
\item Detaillierte Beschreibung der Klassen \item Detaillierte Beschreibung der Klassen
\item Beschreibung von Schnittstellen \item Beschreibung von Schnittstellen
\item Iterativer Prozess! \item Iterativer Prozess!
\begin{itemize*}
\item Verbesserung des Entwurfs - Refactoring
\item Optimieren des Entwurfsmodells zur Erfüllung nichtfunktionaler Anforderungen
\end{itemize*}
\end{itemize*} \end{itemize*}
Objektorientierter Feinentwurf Objektorientierter Feinentwurf
\begin{itemize*} \begin{itemize*}
\item Ausgangspunkt
\begin{itemize*}
\item Grobdefinition der Architektur, Zerlegung in Subsysteme (evtl. unter Verwendung von Standardarchitekturen) \item Grobdefinition der Architektur, Zerlegung in Subsysteme (evtl. unter Verwendung von Standardarchitekturen)
\item Verteilungskonzept
\item Ablaufmodell
\end{itemize*}
\item Ergebnis
\begin{itemize*}
\item OO-Modell für jedes Subsystem der Architektur \item OO-Modell für jedes Subsystem der Architektur
\item OO-Modell für unterstützende Subsysteme unter Berücksichtigung gewählter Technologien \item OO-Modell für unterstützende Subsysteme unter Berücksichtigung gewählter Technologien
\item Spezifikationen der Klassen \item Spezifikationen der Klassen
\item Spezifikationen von externen Schnittstellen \item Spezifikationen von externen Schnittstellen
\end{itemize*} \end{itemize*}
\end{itemize*}
\subsection{Klassen- und Objektentwurf} \subsection{Klassen- und Objektentwurf}
\begin{itemize*} \begin{itemize*}
\item Klassen der Lösungsdomäne \item Klassen der Lösungsdomäne
\begin{itemize*}
\item Klassen, die nicht durch objektorientierte Analyse der Anwendungsdomäne entstehen \item Klassen, die nicht durch objektorientierte Analyse der Anwendungsdomäne entstehen
\end{itemize*}
\item Entstehungsgründe \item Entstehungsgründe
\begin{itemize*} \begin{itemize*}
\item Architektur von Software und System \item Architektur von Software und System
\item nichtfunktionale Anforderungen \item nichtfunktionale Anforderungen
\item Beispiele: Kommunikation, Fehlertoleranz, Adapter, Datenhaltung, Effizienz, Benutzerschnittstellenobjekte, Middleware, ... \item Sichtbare Grenz- und Steuerungsobjekte werden schon in der Analyse identifiziert
\item Sichtbare (Grenz- und Steuerungsobjekte) werden schon in der Analyse identifiziert
\end{itemize*} \end{itemize*}
\end{itemize*} \end{itemize*}
Klassen identifizieren (responsibility-driven design (Wirfs-Brock, McKean)) Responsibility-Driven Design
> Verantwortlichkeits-Prinzip: Sichtweise: Objekte und Klassen sind nicht nur Behälter für Verhalten und Daten, sondern erfüllen in Zusammenarbeit mit anderen Objekten bestimmte Aufgaben eigenverantwortlich \begin{description*}
\item[Application] set of interacting objects
Responsibility-Driven Design - Begriffe \item[Object] implementation of role(s)
\begin{itemize*} \item[Role] set of related responsibilities
\item Sichtweise auf Softwaresystem \item[Responsibility] obligation to perform a task or know information
\item Application = set of interacting objects \item[Collaboration] interaction of objects or roles
\item Object = implementation of role(s) \item[Contract] agreement outlining collaboration terms
\item Role = set of related responsibilities \end{description*}
\item Responsibility = obligation to perform a task or know information
\item Collaboration = interaction of objects or roles
\item Contract = agreement outlining collaboration terms
\end{itemize*}
Arten von Rollen Arten von Rollen
\begin{description*}
\begin{itemize*} \item[Information holder] knows and provides information
\item Information holder | knows and provides information | \item[Structurer] maintains relationship between objects and information about relationships
\item Structurer | maintains relationship between objects and information about relationships | \item[Service provider] performs work, offers computing services
\item Service provider | performs work, offers computing services | \item[Coordinator] reacts to events by delegating tasks to others
\item Coordinator | reacts to events by delegating tasks to others | \item[Controller] makes decisions and directs other’s actions
\item Controller | makes decisions and directs other’s actions | \item[Interfacer] transforms information and requests between system parts
\item Interfacer | transforms information and requests between system parts | \end{description*}
\end{itemize*}
Hilfsmittel: CRC-Karten Hilfsmittel: CRC-Karten
\begin{itemize*} \begin{itemize*}
\item Candidate (or class), Responsibility, Collaboration \item Candidate (or class), Responsibility, Collaboration
\item Informelles Mittel zum \item Informelles Mittel zum Finden, Beschreiben und iterativen Verändern von Klassen
\begin{itemize*}
\item Finden,
\item Beschreiben und
\item iterativen Verändern von Klassen
\end{itemize*}
\end{itemize*} \end{itemize*}
Ein Objekt Ein Objekt
@ -1007,12 +971,10 @@ Peer-to-peer
\item Kohärenz: zusammengehörende Verantwortlichkeiten in einer Klasse konzentrieren! \item Kohärenz: zusammengehörende Verantwortlichkeiten in einer Klasse konzentrieren!
\end{itemize*} \end{itemize*}
\subsection{Entwurfsprinzipien} \subsection{Entwurfsprinzipien}
\begin{itemize*} \begin{itemize*}
\item Kapselung \item Kapselung
\begin{itemize*} \begin{itemize*}
\item Probleme: Zugriff auf private oder ebenen-fremde Attribute
\item Verwenden von get- und set-Operationen \item Verwenden von get- und set-Operationen
\item Zusicherungen einhalten \item Zusicherungen einhalten
\item Zugriffe zentralisieren \item Zugriffe zentralisieren
@ -1030,25 +992,23 @@ Peer-to-peer
\begin{itemize*} \begin{itemize*}
\item „besteht aus“, „ist Teil von“ oder „Ganzes-/Teile-Beziehung“ \item „besteht aus“, „ist Teil von“ oder „Ganzes-/Teile-Beziehung“
\item Schwache Bindung der Teile mit dem Ganzen \item Schwache Bindung der Teile mit dem Ganzen
\item Notation: ungefüllte Raute am Ganzen
\end{itemize*} \end{itemize*}
\item Komposition \item Komposition
\begin{itemize*} \begin{itemize*}
\item Wie Aggregation, jedoch stärkere Bindung \item Wie Aggregation, jedoch stärkere Bindung
\item Teil nur einem Ganzen zugeordnet \item Teil nur einem Ganzen zugeordnet
\item Nur Multiplizität von 1 oder 0..1 möglich! \item Nur Multiplizität von 1 oder 0..1 möglich!
\item Gefüllte Raute am Ganzen
\end{itemize*} \end{itemize*}
\item Polymorphie \item Polymorphie
\begin{itemize*} \begin{itemize*}
\item Reaktion auf eine Nachricht abhängig vom Typ des Objektes \item Reaktion auf eine Nachricht abhängig vom Typ des Objektes
\item Variablen können Objekte verschiedener Klassen aufnehmen (Voraussetzung: Typ der Variablen ist eine gemeinsame Basisklasse der (davon) abgeleiteten Klasse(n) der Objekte) \item Variablen können Objekte verschiedener Klassen aufnehmen
\item Überladen von Operationen \item Überladen von Operationen
\item gleicher Operationsname, unterschiedliche Signatur \item gleicher Operationsname, unterschiedliche Signatur
\item abstrakte Operationen: Virtuelle Operationen ohne Implementierung \item abstrakte Operationen: Virtuelle Operationen ohne Implementierung
\item abstrakte Klasse: Klasse mit abstrakten Operationen \item abstrakte Klasse: Klasse mit abstrakten Operationen
\item Folgen: \item Folgen:
\item von abstrakten Klassen können keine Objekte angelegt werden (Implementierung fehlt) \item von abstrakten Klassen können keine Objekte angelegt werden
\item Abgeleitete Klassen müssen Operation implementieren, damit Objekte angelegt werden können \item Abgeleitete Klassen müssen Operation implementieren, damit Objekte angelegt werden können
\end{itemize*} \end{itemize*}
\end{itemize*} \end{itemize*}
@ -1056,17 +1016,14 @@ Peer-to-peer
Vererbung im Entwurf Vererbung im Entwurf
\begin{itemize*} \begin{itemize*}
\item In der Analyse: Klassifikation von Objekten, Taxonomie, Spezialisierung/Verallgemeinerung, Organisation von Klassen in Hierarchien \item Klassifikation von Objekten, Taxonomie, Spezialisierung/Verallgemeinerung, Organisation von Klassen in Hierarchien
\item Verringerung von Redundanz und damit Inkonsistenzen \item Verringerung von Redundanz und damit Inkonsistenzen
\begin{itemize*} \begin{itemize*}
\item Funktionalität nur einmal implementieren! \item Funktionalität nur einmal implementieren!
\item Spezifikations-Wiederverwendung \item Spezifikations-Wiederverwendung
\item Implementierungs-Wiederverwendung \item Implementierungs-Wiederverwendung
\end{itemize*} \end{itemize*}
\item Verbesserung der Erweiterbarkeit \item Verbesserung der Erweiterbarkeit: Abstrakte Schnittstellen einsetzen!
\begin{itemize*}
\item Abstrakte Schnittstellen einsetzen!
\end{itemize*}
\end{itemize*} \end{itemize*}
Vererbung oder Assoziation Vererbung oder Assoziation
@ -1076,34 +1033,24 @@ Peer-to-peer
\item Vererbung: Unterscheidungsmerkmal definierbar (Diskriminator) \item Vererbung: Unterscheidungsmerkmal definierbar (Diskriminator)
\item Vermeide Vererbung, wenn es Alternativen gibt \item Vermeide Vererbung, wenn es Alternativen gibt
\item Mehrfachvererbung \item Mehrfachvererbung
\begin{itemize*}
\item Problem: Unabhängige Aspekte der Vererbungshierarchie
\item Vermeidung: abstrakte Klassen oder Komposition
\end{itemize*}
\end{itemize*} \end{itemize*}
Abstrakte Klassen Abstrakte Klassen
\begin{itemize*} \begin{itemize*}
\item Nur Unterklassen, keine Instanzen \item Nur Unterklassen, keine Instanzen
\item Attribute in Unterklassen füllen \item Attribute in Unterklassen füllen
\item Notation: Kursiv oder Stereotyp <<abstract>>
\end{itemize*} \end{itemize*}
Offen / Geschlossen-Prinzip [Meyer 1988] Offen / Geschlossen-Prinzip
\begin{itemize*} \begin{itemize*}
\item Erweiterbarkeit eines Entwurfs \item Erweiterbarkeit eines Entwurfs
\item Offen für Erweiterungen, \item Offen für Erweiterungen,
\begin{itemize*} \begin{itemize*}
\item z.B. durch Vererbung / Polymorphie
\item Virtuelle Operationen verwenden \item Virtuelle Operationen verwenden
\item Verändert vorhandenes Verhalten nicht \item Verändert vorhandenes Verhalten nicht
\item Erweiterung um zusätzliche Funktionen oder Daten \item Erweiterung um zusätzliche Funktionen oder Daten
\end{itemize*} \end{itemize*}
\item Geschlossen für Änderungen \item Geschlossen für Änderungen (private)
\begin{itemize*}
\item private Attribute
\item Möglichst protected Operationen
\end{itemize*}
\item Beschränkung der Erweiterbarkeit \item Beschränkung der Erweiterbarkeit
\begin{itemize*} \begin{itemize*}
\item Keine Einschränkungen der Funktionalität der Basisklasse! \item Keine Einschränkungen der Funktionalität der Basisklasse!
@ -1112,7 +1059,7 @@ Peer-to-peer
Liskovsches Ersetzungsprinzip Liskovsches Ersetzungsprinzip
\begin{itemize*} \begin{itemize*}
\item Wenn S eine Unterklasse von T ist, dann können Objekte des Typs T in einem Programm durch Objekte des Typs S ersetzt werden, ohne die Funktion des Programms zu verändern. [Barbara Liskov 1987] \item Wenn S eine Unterklasse von T ist, dann können Objekte des Typs T in einem Programm durch Objekte des Typs S ersetzt werden, ohne die Funktion des Programms zu verändern
\item Engere Definition als „ist-ein“-Beziehung \item Engere Definition als „ist-ein“-Beziehung
\item Kein unerwartetes Verhalten eines Objektes eines Subtyps \item Kein unerwartetes Verhalten eines Objektes eines Subtyps
\item Methoden, die Objekte der Basisklasse erwarten, müssen auch mit Objekten der abgeleiteten Klasse funktionieren \item Methoden, die Objekte der Basisklasse erwarten, müssen auch mit Objekten der abgeleiteten Klasse funktionieren
@ -1121,7 +1068,6 @@ Peer-to-peer
Gesetz von Demeter (LoD) Gesetz von Demeter (LoD)
\begin{itemize*} \begin{itemize*}
\item Gesetz von „schüchternen“ Objekten
\item Objekte sollen nur mit Objekten in ihrer unmittelbaren Umgebung kommunizieren \item Objekte sollen nur mit Objekten in ihrer unmittelbaren Umgebung kommunizieren
\item Aus einer Methode M dürfen (sollten) nur Nachrichten an Objekte gesendet werden, die ... \item Aus einer Methode M dürfen (sollten) nur Nachrichten an Objekte gesendet werden, die ...
\begin{itemize*} \begin{itemize*}
@ -1130,7 +1076,6 @@ Peer-to-peer
\item direkt in M erzeugt wurden \item direkt in M erzeugt wurden
\item (oder sich in globalen Variablen befinden) \item (oder sich in globalen Variablen befinden)
\end{itemize*} \end{itemize*}
\item Als Metrik überprüfbar
\end{itemize*} \end{itemize*}
Ein Objekt sollte Ein Objekt sollte
@ -1144,17 +1089,8 @@ Peer-to-peer
\end{itemize*} \end{itemize*}
\end{itemize*} \end{itemize*}
\subsection{Entwurfsmodell Klassendiagramm}
\subsection{Entwurfsmodelle}
Klassendiagramm
\begin{itemize*} \begin{itemize*}
\item Eigenschaften
\begin{itemize*}
\item Modellierung der statischen Struktur (Aufbau)
\item Modellierung der Struktur von Daten
\item Klasse im Mittelpunkt (Aufbau, Beziehungen zueinander)
\item Wichtigstes und bekanntestes Diagramm der UML!
\end{itemize*}
\item Elemente des Klassendiagramms \item Elemente des Klassendiagramms
\begin{itemize*} \begin{itemize*}
\item Klasse (Attribute, Operationen) \item Klasse (Attribute, Operationen)
@ -1198,70 +1134,37 @@ Peer-to-peer
\end{itemize*} \end{itemize*}
\end{itemize*} \end{itemize*}
Aktive Klassen
\begin{itemize*}
\item Reagieren nicht nur, sondern werden von sich aus aktiv
\item Z.B. Steuerobjekte
\item Als Thread oder Prozess realisiert
\end{itemize*}
\subsection{Schnittstellen} \subsection{Schnittstellen}
\begin{itemize*} \begin{itemize*}
\item Vereinbarung über Art des Aufrufs \item Vereinbarung über Art des Aufrufs
\begin{itemize*} \begin{itemize*}
\item Homogenität gleicher Funktionen \item Homogenität gleicher Funktionen
\item Enthält:
\item Spezifikation von Operationen \item Spezifikation von Operationen
\item keine Implementierung ( Java, nicht UML!) \item keine Implementierung, keine Attribute
\item keine Attribute
\item In Java außerdem anstelle von Mehrfachvererbung
\end{itemize*} \end{itemize*}
\item Schnittstellen in UML \item Schnittstellen in UML
\begin{itemize*} \begin{itemize*}
\item Funktion ähnlich abstrakter Klasse \item Funktion ähnlich abstrakter Klasse
\item Meist für technische Aspekte \item Meist für technische Aspekte
\item Notation: Stereotyp <<interface>> oder grafisch (lollipop notation)
\end{itemize*} \end{itemize*}
\item Verträge („design by contract“) \item Verträge („design by contract“)
\begin{itemize*} \begin{itemize*}
\item Schnittstelle sagt bisher nichts über Effekt der Klasse aus \item Vorbedingung: Prädikat, das vor Aufruf gelten muss
\item Vollständige Beschreibung wäre Programm? \item Nachbedingung: Prädikat, das nach Aufruf gelten muss
\item Vereinfachte Beschreibung für Abfolgen: \item Invariante: Prädikat, das immer gilt
\item Vorbedingung: Prädikat, das vor Aufruf gelten muss <<precondition>>
\item Nachbedingung: Prädikat, das nach Aufruf gelten muss <<postcondition>>
\item Invariante: Prädikat, das immer gilt <<invariant>>
\item Jeweils Einschränkungen!
\end{itemize*} \end{itemize*}
\end{itemize*} \end{itemize*}
Protokollrollen - Dynamisches Verhalten von Schnittstellen Protokollrollen - Dynamisches Verhalten von Schnittstellen
\begin{itemize*} \begin{itemize*}
\item Ohne Sicht auf innere Implementierung (anders als beim Objektlebenszyklus) \item Ohne Sicht auf innere Implementierung
\item Protokoll = Kollaboration von Protokollrollen (protocol, protocol role) \item Protokoll = Kollaboration von Protokollrollen
\item Modell: Zustandsautomat \item Modell: Zustandsautomat
\begin{itemize*}
\item Genauer: Spezialisierung
\item Beschreibung der Synchronisation von Objekten \item Beschreibung der Synchronisation von Objekten
\end{itemize*}
\end{itemize*} \end{itemize*}
\subsection{Entwurfsmuster} \subsection{Entwurfsmuster}
\begin{itemize*} schematische Lösung für eine Klasse verwandter Probleme (Höhere Ebene: Architekturmuster)
\item Warum Wiederverwendung?
\begin{itemize*}
\item Geringerer Aufwand
\item Das Rad nicht noch einmal neu erfinden
\item Verwenden üblicher, aus Erfahrung gewachsener Strukturen
\end{itemize*}
\item ... und warum nicht?
\begin{itemize*}
\item Aufwand für Anpassung kann hoch sein!
\item Einarbeiten in teilweise komplexe Schnittstellen
\item Abhängigkeit von externen Komponenten, Zwang zu späterer Portierung
\end{itemize*}
\end{itemize*}
> Was ist ein Entwurfsmuster? Eine schematische Lösung für eine Klasse verwandter Probleme (Höhere Ebene: Architekturmuster)
\begin{itemize*} \begin{itemize*}
\item Wie helfen Muster im Entwurf? \item Wie helfen Muster im Entwurf?
\begin{itemize*} \begin{itemize*}
@ -1277,141 +1180,40 @@ Peer-to-peer
\item Verhaltensmuster \item Verhaltensmuster
\end{itemize*} \end{itemize*}
\item Erzeugungsmuster \item Erzeugungsmuster
\begin{itemize*} \begin{description*}
\item Factory Method, Fabrikmethode: \item[Factory Method] Implementierungsvarianten; Erzeugung von Objekten wird an Unterklassen delegiert
\item Implementierungsvarianten; Erzeugung von Objekten wird an Unterklassen delegiert \item[Abstract Factory] Schnittstelle zur Erzeugung von Familien verwandter Objekte
\item Abstract Factory, Abstrakte Fabrik: \item[Prototype] Objekterzeugung durch Vorlage und Kopie
\item Schnittstelle zur Erzeugung von Familien verwandter Objekte \item[Builder] Trennung von Erzeugung und Repräsentation komplexer Objekte, für Erzeugung unterschiedlicher Repräsentationen
\item Prototype, Prototyp: \item[Singleton] Sicherstellung, dass nur ein Objekt einer Klasse erzeugt wird, die einen globalen Zugriff bietet
\item Objekterzeugung durch Vorlage und Kopie \end{description*}
\item Builder, Erbauer:
\item Trennung von Erzeugung und Repräsentation komplexer Objekte, für Erzeugung unterschiedlicher Repräsentationen
\item Singleton:
\item Sicherstellung, dass nur ein Objekt einer Klasse erzeugt wird, die einen globalen Zugriff bietet
\end{itemize*}
\end{itemize*} \end{itemize*}
Strukturmuster Strukturmuster
\begin{itemize*} \begin{description*}
\item Adapter \item[Adapter] Anpassung der (inkompatiblen) Schnittstelle einer Klasse oder eines Objekts an eine erwartete Schnittstelle
\begin{itemize*} \item[Bridge] Abstraktion (Schnittstelle) von Implementierung entkoppeln, um beide unabhängig zu ändern; Impl.-Klasse nur als Verweis
\item Anpassung der (inkompatiblen) Schnittstelle einer Klasse oder eines Objekts an eine erwartete Schnittstelle \item[Decorator] Objekt dynamisch um Zuständigkeiten erweitern (Alternative zur Bildung von Unterklassen)
\end{itemize*} \item[Facade] Einheitliche Schnittstelle zu einer Schnittstellenmenge, vereinfacht Zugriff
\item Bridge, Brücke \item[Flyweight] Gemeinsame Nutzung kleiner Objekte zur effizienten Verwendung großer Mengen davon (Speicheraufwand)
\begin{itemize*} \item[Composite] Zusammenfügen verschiedener Objekte zur Repräsentation von Teil-Ganzes-Beziehungen; Objekte und Kompositionen können einheitlich behandelt werden, Baumstruktur
\item Abstraktion (Schnittstelle) von Implementierung entkoppeln, um beide unabhängig zu ändern; Impl.-Klasse nur als Verweis \item[Proxy] kontrollierter Zugriff auf Objekt durch vorgeschaltetes Stellvertreterobjekt
\end{itemize*} \end{description*}
\item Decorator, Dekorierer
\begin{itemize*}
\item Objekt dynamisch um Zuständigkeiten erweitern (Alternative zur Bildung von Unterklassen)
\end{itemize*}
\item Facade, Fassade
\begin{itemize*}
\item Einheitliche Schnittstelle zu einer Schnittstellenmenge, vereinfacht Zugriff
\end{itemize*}
\item Flyweight, Fliegengewicht
\begin{itemize*}
\item Gemeinsame Nutzung kleiner Objekte zur effizienten Verwendung großer Mengen davon (Speicheraufwand)
\end{itemize*}
\item Composite, Verbund, Kompositum
\begin{itemize*}
\item Zusammenfügen verschiedener Objekte zur Repräsentation von Teil-Ganzes-Beziehungen; Objekte und Kompositionen können einheitlich behandelt werden, Baumstruktur
\end{itemize*}
\item Proxy, Stellvertreter
\begin{itemize*}
\item Kontrollierter Zugriff auf Objekt durch vorgeschaltetes Stellvertreterobjekt
\item Gründe: Schutz, entfernter Zugriff (remote proxy), smart pointer, Erzeugung on demand
\end{itemize*}
\end{itemize*}
Adapter
\begin{itemize*}
\item Vorteile
\begin{itemize*}
\item Kommunikation unabhängiger Softwarekomponenten
\item Einfache Erweiterung um zusätzliche Funktionalität
\item Austausch der Komponente durch Änderung des Adapters leicht möglich
\end{itemize*}
\item Nachteile
\begin{itemize*}
\item Zusätzlicher Adaptierungsschritt benötigt Zeit
\item Schlechte Wiederverwendbarkeit der Adapter
\end{itemize*}
\item Bekannte Verwendung, Spezialfälle
\begin{itemize*}
\item Fassade: Adapter eines Teilsystems
\item Proxy: erweitert die Funktionalität bei gleicher Schnittstelle
\item Brücke: keine Anpassung, sondern vorherige Strukturierung
\end{itemize*}
\end{itemize*}
Verhaltensmuster Verhaltensmuster
\begin{itemize*} \begin{description*}
\item Command, Befehl \item[Command] Befehl / Operation als Objekt kapseln (Parameterübergabe, Operations-Warteschlangen, logging, Rückgängig machen)
\begin{itemize*} \item[Observer] 1-zu-n-Beziehung zwischen Objekten, so dass die Änderung des zentralen Objekts zu einer Benachrichtigung und Aktualisierung der n (abhängigen) Zustände führt
\item Befehl / Operation als Objekt kapseln (Parameterübergabe, Operations-Warteschlangen, logging, Rückgängig machen) \item[Visitor] Beschreibung und Kapselung einer zu definierenden Operation, die auf einer Objektmenge ausgeführt wird
\end{itemize*} \item[Interpreter] Repräsentation der Grammatik einer Sprache sowie Interpreter zur Analyse von Sätzen der Sprache
\item Observer, Beobachter \item[Iterator] Sequentieller Zugriff auf die Elemente einer Sammlung ohne Kenntnis der Implementierung der Sammlung
\begin{itemize*} \item[Memento] Internen Zustand eines Objekts erfassen und speichern, um Objektzustand wiederherstellen zu können
\item 1-zu-n-Beziehung zwischen Objekten, so dass die Änderung des zentralen Objekts zu einer Benachrichtigung und Aktualisierung der n (abhängigen) Zustände führt \item[Template Method] Beschreibung des Skeletts eines Algorithmus mit Delegation der Einzelschritte an Unterklassen; Teilschritte können von Unterklassen geändert werden
\end{itemize*} \item[Strategy] Ermöglicht Austausch verschiedener Implementierungen einer Aufgabe ohne Beeinflussung der sie benutzenden Objekte
\item Visitor, Besucher \item[Mediator] Objekt, welches das Zusammenspiel einer lose gekoppelten Objektmenge in sich kapselt. Vermeidet direkten Bezug der Objekte untereinander und ermöglicht unabhängige Änderung des Zusammenspiels
\begin{itemize*} \item[State] Ermöglicht Objekt, sein Verhalten abhängig von seinem inneren Zustand zu ändern, als ob es die Klasse wechselt
\item Beschreibung und Kapselung einer zu definierenden Operation, die auf einer Objektmenge ausgeführt wird \item[Chain of Responsibility] Vermeidet direkte Kopplung von Auslöser und Empfänger einer Anfrage bzw. Operation. Mehrere Objekte werden nacheinander benachrichtigt, bis die Anfrage erledigt ist
\end{itemize*} \end{description*}
\item Interpreter
\begin{itemize*}
\item Repräsentation der Grammatik einer Sprache sowie Interpreter zur Analyse von Sätzen der Sprache
\end{itemize*}
\item Iterator
\begin{itemize*}
\item Sequentieller Zugriff auf die Elemente einer Sammlung ohne Kenntnis der Implementierung der Sammlung
\end{itemize*}
\item Memento
\begin{itemize*}
\item Internen Zustand eines Objekts erfassen und speichern, um Objektzustand wiederherstellen zu können
\end{itemize*}
\item Template Method, Schablonenmethode
\begin{itemize*}
\item Beschreibung des Skeletts eines Algorithmus mit Delegation der Einzelschritte an Unterklassen; Teilschritte können von Unterklassen geändert werden
\end{itemize*}
\item Strategy, Strategie
\begin{itemize*}
\item Ermöglicht Austausch verschiedener Implementierungen einer Aufgabe ohne Beeinflussung der sie benutzenden Objekte
\end{itemize*}
\item Mediator, Vermittler
\begin{itemize*}
\item Objekt, welches das Zusammenspiel einer lose gekoppelten Objektmenge in sich kapselt. Vermeidet direkten Bezug der Objekte untereinander und ermöglicht unabhängige Änderung des Zusammenspiels
\end{itemize*}
\item State, Zustand
\begin{itemize*}
\item Ermöglicht Objekt, sein Verhalten abhängig von seinem inneren Zustand zu ändern, als ob es die Klasse wechselt
\end{itemize*}
\item Chain of Responsibility, Zuständigkeitskette
\begin{itemize*}
\item Vermeidet direkte Kopplung von Auslöser und Empfänger einer Anfrage bzw. Operation. Mehrere Objekte werden nacheinander benachrichtigt, bis die Anfrage erledigt ist
\end{itemize*}
\end{itemize*}
Bewertung Observer
\begin{itemize*}
\item Vorteile
\begin{itemize*}
\item Entkopplung von Komponenten und Schichten möglich
\item Broadcast und selective Broadcast möglich
\end{itemize*}
\item Nachteile
\begin{itemize*}
\item Bei vielen Beobachtern: Benachrichtigung aufwendig
\item Unerwartete Änderung, Änderungskaskaden und Rekursion
\item Abmelden der Beobachter vor dem Löschen
\end{itemize*}
\item Bekannte Verwendung, Spezialfälle
\begin{itemize*}
\item Verwendung im Model-View-Controller Muster
\item Qt: Signal / Slot-Prinzip ähnlich
\end{itemize*}
\end{itemize*}
Anwendung von Entwurfsmustern Anwendung von Entwurfsmustern
\begin{itemize*} \begin{itemize*}
@ -1428,7 +1230,6 @@ Peer-to-peer
\end{itemize*} \end{itemize*}
\subsection{Klassenbibliotheken und Komponenten} \subsection{Klassenbibliotheken und Komponenten}
Klassenbibliotheken
\begin{itemize*} \begin{itemize*}
\item Zusammenfassung von Modulen, Klassen, etc. \item Zusammenfassung von Modulen, Klassen, etc.
\item Mit einem bestimmten (abstrakten) Zweck \item Mit einem bestimmten (abstrakten) Zweck
@ -1439,11 +1240,8 @@ Peer-to-peer
\item Numerische Routinen, Simulation, ... \item Numerische Routinen, Simulation, ...
\end{itemize*} \end{itemize*}
\item Wird in Anwendung eingebunden (importiert), API \item Wird in Anwendung eingebunden (importiert), API
\begin{itemize*}
\item Objekte instanziieren oder Klassen ableiten \item Objekte instanziieren oder Klassen ableiten
\end{itemize*}
\item Meist passiv: Kontrollfluss wird von Anwendung gesteuert \item Meist passiv: Kontrollfluss wird von Anwendung gesteuert
\item Beispiele: stdlib, MFC, GNU scientific library, Java 3D, IPP
\end{itemize*} \end{itemize*}
Komponentenbasierte Entwicklung Komponentenbasierte Entwicklung
@ -1451,11 +1249,7 @@ Peer-to-peer
\item Bausteinorientierte Programmierung (component-ware) \item Bausteinorientierte Programmierung (component-ware)
\item Softwareentwicklung: Konstruktion aus vorgegebenen Bausteinen \item Softwareentwicklung: Konstruktion aus vorgegebenen Bausteinen
\item Entsprechung für Wiederverwendung: Generische Bausteine (components) \item Entsprechung für Wiederverwendung: Generische Bausteine (components)
\begin{itemize*}
\item Anpassbar, zusammensetzbar
\end{itemize*}
\item Werkzeuggestützte bzw. grafische Kompositionsmechanismen \item Werkzeuggestützte bzw. grafische Kompositionsmechanismen
\item Beispiele: Java Beans, Enterprise Java Beans (EJBs), Microsoft COM+
\item Komponenten-Entwicklung oft auch projektspezifisch \item Komponenten-Entwicklung oft auch projektspezifisch
\item Warum Komponenten \item Warum Komponenten
\begin{itemize*} \begin{itemize*}
@ -1463,17 +1257,15 @@ Peer-to-peer
\item Zunehmend verteilte Anwendungen mit offener Struktur und Internet-Anbindung \item Zunehmend verteilte Anwendungen mit offener Struktur und Internet-Anbindung
\item Zusammensetzen der Funktionalität aus standardisierten Elementen, die über offene Schnittstellen kommunizieren \item Zusammensetzen der Funktionalität aus standardisierten Elementen, die über offene Schnittstellen kommunizieren
\item Komponenten sollen Flexibilität bei sich ändernden Anforderungen erhöhen \item Komponenten sollen Flexibilität bei sich ändernden Anforderungen erhöhen
\item Weg aus der „Software-Krise“?
\end{itemize*} \end{itemize*}
\item Eigenschaften von Komponenten \item Eigenschaften von Komponenten
\begin{itemize*} \begin{itemize*}
\item müssen von ihrer Umgebung und anderen Komponenten unabhängig und getrennt sein \item müssen von ihrer Umgebung und anderen Komponenten unabhängig und getrennt sein
\item Kontextabhängigkeiten: benötigte Komponenten-Infrastruktur und Systemressourcen \item Kontextabhängigkeiten: benötigte Komponenten-Infrastruktur und Systemressourcen
\item Kapseln ihre angebotenen Funktionen \item Kapseln ihre angebotenen Funktionen
\item Werden immer als ganze Einheit eingesetzt; alle Bestandteile sind enthalten (Archiv-Datei) \item Werden immer als ganze Einheit eingesetzt; alle Bestandteile sind enthalten
\item Sind nicht von Kopien ihrer selbst unterscheidbar \item Sind nicht von Kopien ihrer selbst unterscheidbar
\item Klare Spezifikation der Schnittstelle nötig; explizit definierte Interaktionen mit Komponenten und Umgebung \item Klare Spezifikation der Schnittstelle nötig; explizit definierte Interaktionen mit Komponenten und Umgebung
\item Komposition durch Dritte: Endbenutzer, Komponenten-Hersteller und Komponenten-Integrator; meist nur kompilierter Code verfügbar
\end{itemize*} \end{itemize*}
\end{itemize*} \end{itemize*}
@ -1495,13 +1287,12 @@ Peer-to-peer
\end{itemize*} \end{itemize*}
\subsection{Dokumentation} \subsection{Dokumentation}
Dokumentation des Feinentwurfs
\begin{itemize*} \begin{itemize*}
\item Möglichkeiten \item Möglichkeiten
\begin{itemize*} \begin{itemize*}
\item Eigenständiges Dokument \item Eigenständiges Dokument
\item Erweiterung des Lastenhefts / Grobkonzepts \item Erweiterung des Lastenhefts / Grobkonzepts
\item Eingebettet in den Quellcode (Werkzeug, z.B. Javadoc) \item Eingebettet in den Quellcode
\end{itemize*} \end{itemize*}
\item Inhalt \item Inhalt
\begin{itemize*} \begin{itemize*}
@ -1514,7 +1305,6 @@ Peer-to-peer
\newpage \newpage
\section{Implementierung} \section{Implementierung}
Aufgaben der Implementierung
\begin{itemize*} \begin{itemize*}
\item Aus Spezifikationen Programm(code) erzeugen \item Aus Spezifikationen Programm(code) erzeugen
\item Aufbauend auf Ergebnissen des Feinentwurfs \item Aufbauend auf Ergebnissen des Feinentwurfs