Feinentwurf hydrated
This commit is contained in:
parent
560e6aa01c
commit
0469d41760
Binary file not shown.
@ -331,28 +331,27 @@
|
||||
\end{itemize*}
|
||||
|
||||
Blockdiagramm
|
||||
\begin{itemize*}
|
||||
\item Klassisches Beschreibungsmittel für Systemaufbau
|
||||
\item Nicht Teil von UML
|
||||
\end{itemize*}
|
||||
|
||||
Konfigurationsdiagramm
|
||||
\begin{itemize*}
|
||||
\item meistverbreitetes Hilfsmittel zur Beschreibung der physikalischen Verteilung von System-Komponenten
|
||||
\item Nicht Teil von UML
|
||||
\end{itemize*}
|
||||
\begin{itemize*}
|
||||
\item Klassisches Beschreibungsmittel für Systemaufbau
|
||||
\item Nicht Teil von UML
|
||||
\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*}
|
||||
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)
|
||||
\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
|
||||
\section{Analyse}
|
||||
|
||||
Funktionale Anforderungen - Was soll es tun?
|
||||
\begin{itemize*}
|
||||
\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-out] Anzahl von Stellen, an denen M andere Module aufruft + Anzahl der globalen Variablen, die von M verändert werden
|
||||
\end{description*}
|
||||
\begin{itemize*}
|
||||
\begin{itemize*}
|
||||
\item Heuristik Kopplung / Kohäsion
|
||||
\begin{itemize*}
|
||||
\item Hoher Fan-out bedeutet hohe Kopplung $\rightarrow$ minimieren
|
||||
@ -659,7 +658,6 @@
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
|
||||
Prinzipien des OO-Entwurfs
|
||||
\begin{itemize*}
|
||||
\item Keep it simple stupid (KISS)
|
||||
@ -869,51 +867,42 @@
|
||||
\end{itemize*}
|
||||
\item Kontrollfluss
|
||||
\item Dokumentation
|
||||
\begin{itemize*}
|
||||
\item Verständlich aus Sicht des Lesers formulieren (Glossar)
|
||||
\item Das Warum beschreiben (Entwurfsentscheidungen)
|
||||
\item Annahmen, Voraussetzungen, Randbedingungen
|
||||
\item Notation erklären oder Standards verwenden (UML)
|
||||
\item Auf Zweckdienlichkeit prüfen, Reviews durchführen
|
||||
\item Verschiedene Sichten für verschiedene Zielgruppen
|
||||
\begin{itemize*}
|
||||
\item Verständlich aus Sicht des Lesers formulieren (Glossar)
|
||||
\item Das Warum beschreiben (Entwurfsentscheidungen)
|
||||
\item Annahmen, Voraussetzungen, Randbedingungen
|
||||
\item Notation erklären oder Standards verwenden (UML)
|
||||
\item Auf Zweckdienlichkeit prüfen, Reviews durchführen
|
||||
\item Verschiedene Sichten für verschiedene Zielgruppen
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
Schicht
|
||||
\begin{itemize*}
|
||||
\item Gruppe von Subsystemen in der Zerlegungshierarchie
|
||||
\item Verwandte Dienste
|
||||
\item Ähnlicher Abstraktionsgrad
|
||||
\item Abhängigkeit nur von darunter liegenden!
|
||||
\end{itemize*}
|
||||
Schicht
|
||||
\begin{itemize*}
|
||||
\item Gruppe von Subsystemen in der Zerlegungshierarchie
|
||||
\item Verwandte Dienste
|
||||
\item Ähnlicher Abstraktionsgrad
|
||||
\item Abhängigkeit nur von darunter liegenden!
|
||||
\end{itemize*}
|
||||
|
||||
Repository (Depot, blackboard)
|
||||
\begin{itemize*}
|
||||
\item Zentrale Datenhaltung
|
||||
\item Anwendungen tauschen Daten nur über Repository aus
|
||||
\item Kontrollfluss z.B. über Signale oder Semaphore
|
||||
\item Gut für datenintensive Verarbeitungsaufgaben geeignet
|
||||
\end{itemize*}
|
||||
Repository (Depot, blackboard)
|
||||
\begin{itemize*}
|
||||
\item Zentrale Datenhaltung
|
||||
\item Anwendungen tauschen Daten nur über Repository aus
|
||||
\item Kontrollfluss z.B. über Signale oder Semaphore
|
||||
\item Gut für datenintensive Verarbeitungsaufgaben geeignet
|
||||
\end{itemize*}
|
||||
|
||||
Peer-to-peer
|
||||
\begin{itemize*}
|
||||
\item Gleichberechtigte Partner, Föderation
|
||||
\item Verteilte kommunizierende Subsysteme
|
||||
\item Orts- und Umgebungsunabhängigkeit
|
||||
\end{itemize*}
|
||||
Peer-to-peer
|
||||
\begin{itemize*}
|
||||
\item Gleichberechtigte Partner, Föderation
|
||||
\item Verteilte kommunizierende Subsysteme
|
||||
\item Orts- und Umgebungsunabhängigkeit
|
||||
\end{itemize*}
|
||||
|
||||
|
||||
\newpage
|
||||
\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
|
||||
\begin{itemize*}
|
||||
\item Identifizieren und Entwerfen von Klassen der Lösungsdomäne
|
||||
@ -921,78 +910,53 @@ Peer-to-peer
|
||||
\item Detaillierte Beschreibung der Klassen
|
||||
\item Beschreibung von Schnittstellen
|
||||
\item Iterativer Prozess!
|
||||
\begin{itemize*}
|
||||
\item Verbesserung des Entwurfs - Refactoring
|
||||
\item Optimieren des Entwurfsmodells zur Erfüllung nichtfunktionaler Anforderungen
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
Objektorientierter Feinentwurf
|
||||
\begin{itemize*}
|
||||
\item Ausgangspunkt
|
||||
\begin{itemize*}
|
||||
\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 unterstützende Subsysteme unter Berücksichtigung gewählter Technologien
|
||||
\item Spezifikationen der Klassen
|
||||
\item Spezifikationen von externen Schnittstellen
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
\subsection{Klassen- und Objektentwurf}
|
||||
\begin{itemize*}
|
||||
\item Klassen der Lösungsdomäne
|
||||
\begin{itemize*}
|
||||
\item Klassen, die nicht durch objektorientierte Analyse der Anwendungsdomäne entstehen
|
||||
\end{itemize*}
|
||||
\item Entstehungsgründe
|
||||
\begin{itemize*}
|
||||
\item Architektur von Software und System
|
||||
\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*}
|
||||
|
||||
Klassen identifizieren (responsibility-driven design (Wirfs-Brock, McKean))
|
||||
> 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
|
||||
|
||||
Responsibility-Driven Design - Begriffe
|
||||
\begin{itemize*}
|
||||
\item Sichtweise auf Softwaresystem
|
||||
\item Application = set of interacting objects
|
||||
\item Object = implementation of role(s)
|
||||
\item Role = set of related responsibilities
|
||||
\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*}
|
||||
Responsibility-Driven Design
|
||||
\begin{description*}
|
||||
\item[Application] set of interacting objects
|
||||
\item[Object] implementation of role(s)
|
||||
\item[Role] set of related responsibilities
|
||||
\item[Responsibility] obligation to perform a task or know information
|
||||
\item[Collaboration] interaction of objects or roles
|
||||
\item[Contract] agreement outlining collaboration terms
|
||||
\end{description*}
|
||||
|
||||
Arten von Rollen
|
||||
|
||||
\begin{itemize*}
|
||||
\item Information holder | knows and provides information |
|
||||
\item Structurer | maintains relationship between objects and information about relationships |
|
||||
\item Service provider | performs work, offers computing services |
|
||||
\item Coordinator | reacts to events by delegating tasks to others |
|
||||
\item Controller | makes decisions and directs other’s actions |
|
||||
\item Interfacer | transforms information and requests between system parts |
|
||||
\end{itemize*}
|
||||
\begin{description*}
|
||||
\item[Information holder] knows and provides information
|
||||
\item[Structurer] maintains relationship between objects and information about relationships
|
||||
\item[Service provider] performs work, offers computing services
|
||||
\item[Coordinator] reacts to events by delegating tasks to others
|
||||
\item[Controller] makes decisions and directs other’s actions
|
||||
\item[Interfacer] transforms information and requests between system parts
|
||||
\end{description*}
|
||||
|
||||
Hilfsmittel: CRC-Karten
|
||||
\begin{itemize*}
|
||||
\item Candidate (or class), Responsibility, Collaboration
|
||||
\item Informelles Mittel zum
|
||||
\begin{itemize*}
|
||||
\item Finden,
|
||||
\item Beschreiben und
|
||||
\item iterativen Verändern von Klassen
|
||||
\end{itemize*}
|
||||
\item Informelles Mittel zum Finden, Beschreiben und iterativen Verändern von Klassen
|
||||
\end{itemize*}
|
||||
|
||||
Ein Objekt
|
||||
@ -1007,12 +971,10 @@ Peer-to-peer
|
||||
\item Kohärenz: zusammengehörende Verantwortlichkeiten in einer Klasse konzentrieren!
|
||||
\end{itemize*}
|
||||
|
||||
|
||||
\subsection{Entwurfsprinzipien}
|
||||
\begin{itemize*}
|
||||
\item Kapselung
|
||||
\begin{itemize*}
|
||||
\item Probleme: Zugriff auf private oder ebenen-fremde Attribute
|
||||
\item Verwenden von get- und set-Operationen
|
||||
\item Zusicherungen einhalten
|
||||
\item Zugriffe zentralisieren
|
||||
@ -1030,25 +992,23 @@ Peer-to-peer
|
||||
\begin{itemize*}
|
||||
\item „besteht aus“, „ist Teil von“ oder „Ganzes-/Teile-Beziehung“
|
||||
\item Schwache Bindung der Teile mit dem Ganzen
|
||||
\item Notation: ungefüllte Raute am Ganzen
|
||||
\end{itemize*}
|
||||
\item Komposition
|
||||
\begin{itemize*}
|
||||
\item Wie Aggregation, jedoch stärkere Bindung
|
||||
\item Teil nur einem Ganzen zugeordnet
|
||||
\item Nur Multiplizität von 1 oder 0..1 möglich!
|
||||
\item Gefüllte Raute am Ganzen
|
||||
\end{itemize*}
|
||||
\item Polymorphie
|
||||
\begin{itemize*}
|
||||
\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 gleicher Operationsname, unterschiedliche Signatur
|
||||
\item abstrakte Operationen: Virtuelle Operationen ohne Implementierung
|
||||
\item abstrakte Klasse: Klasse mit abstrakten Operationen
|
||||
\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
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
@ -1056,17 +1016,14 @@ Peer-to-peer
|
||||
|
||||
Vererbung im Entwurf
|
||||
\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
|
||||
\begin{itemize*}
|
||||
\item Funktionalität nur einmal implementieren!
|
||||
\item Spezifikations-Wiederverwendung
|
||||
\item Implementierungs-Wiederverwendung
|
||||
\end{itemize*}
|
||||
\item Verbesserung der Erweiterbarkeit
|
||||
\begin{itemize*}
|
||||
\item Abstrakte Schnittstellen einsetzen!
|
||||
\end{itemize*}
|
||||
\item Verbesserung der Erweiterbarkeit: Abstrakte Schnittstellen einsetzen!
|
||||
\end{itemize*}
|
||||
|
||||
Vererbung oder Assoziation
|
||||
@ -1076,34 +1033,24 @@ Peer-to-peer
|
||||
\item Vererbung: Unterscheidungsmerkmal definierbar (Diskriminator)
|
||||
\item Vermeide Vererbung, wenn es Alternativen gibt
|
||||
\item Mehrfachvererbung
|
||||
\begin{itemize*}
|
||||
\item Problem: Unabhängige Aspekte der Vererbungshierarchie
|
||||
\item Vermeidung: abstrakte Klassen oder Komposition
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
Abstrakte Klassen
|
||||
\begin{itemize*}
|
||||
\item Nur Unterklassen, keine Instanzen
|
||||
\item Attribute in Unterklassen füllen
|
||||
\item Notation: Kursiv oder Stereotyp <<abstract>>
|
||||
\end{itemize*}
|
||||
|
||||
Offen / Geschlossen-Prinzip [Meyer 1988]
|
||||
Offen / Geschlossen-Prinzip
|
||||
\begin{itemize*}
|
||||
\item Erweiterbarkeit eines Entwurfs
|
||||
\item Offen für Erweiterungen,
|
||||
\begin{itemize*}
|
||||
\item z.B. durch Vererbung / Polymorphie
|
||||
\item Virtuelle Operationen verwenden
|
||||
\item Verändert vorhandenes Verhalten nicht
|
||||
\item Erweiterung um zusätzliche Funktionen oder Daten
|
||||
\end{itemize*}
|
||||
\item Geschlossen für Änderungen
|
||||
\begin{itemize*}
|
||||
\item private Attribute
|
||||
\item Möglichst protected Operationen
|
||||
\end{itemize*}
|
||||
\item Geschlossen für Änderungen (private)
|
||||
\item Beschränkung der Erweiterbarkeit
|
||||
\begin{itemize*}
|
||||
\item Keine Einschränkungen der Funktionalität der Basisklasse!
|
||||
@ -1112,7 +1059,7 @@ Peer-to-peer
|
||||
|
||||
Liskovsches Ersetzungsprinzip
|
||||
\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 Kein unerwartetes Verhalten eines Objektes eines Subtyps
|
||||
\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)
|
||||
\begin{itemize*}
|
||||
\item Gesetz von „schüchternen“ Objekten
|
||||
\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 ...
|
||||
\begin{itemize*}
|
||||
@ -1130,7 +1076,6 @@ Peer-to-peer
|
||||
\item direkt in M erzeugt wurden
|
||||
\item (oder sich in globalen Variablen befinden)
|
||||
\end{itemize*}
|
||||
\item Als Metrik überprüfbar
|
||||
\end{itemize*}
|
||||
|
||||
Ein Objekt sollte
|
||||
@ -1144,17 +1089,8 @@ Peer-to-peer
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
|
||||
\subsection{Entwurfsmodelle}
|
||||
Klassendiagramm
|
||||
\subsection{Entwurfsmodell Klassendiagramm}
|
||||
\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
|
||||
\begin{itemize*}
|
||||
\item Klasse (Attribute, Operationen)
|
||||
@ -1198,70 +1134,37 @@ Peer-to-peer
|
||||
\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}
|
||||
\begin{itemize*}
|
||||
\item Vereinbarung über Art des Aufrufs
|
||||
\begin{itemize*}
|
||||
\item Homogenität gleicher Funktionen
|
||||
\item Enthält:
|
||||
\item Spezifikation von Operationen
|
||||
\item keine Implementierung ( Java, nicht UML!)
|
||||
\item keine Attribute
|
||||
\item In Java außerdem anstelle von Mehrfachvererbung
|
||||
\item keine Implementierung, keine Attribute
|
||||
\end{itemize*}
|
||||
\item Schnittstellen in UML
|
||||
\begin{itemize*}
|
||||
\item Funktion ähnlich abstrakter Klasse
|
||||
\item Meist für technische Aspekte
|
||||
\item Notation: Stereotyp <<interface>> oder grafisch (lollipop notation)
|
||||
\end{itemize*}
|
||||
\item Verträge („design by contract“)
|
||||
\begin{itemize*}
|
||||
\item Schnittstelle sagt bisher nichts über Effekt der Klasse aus
|
||||
\item Vollständige Beschreibung wäre Programm?
|
||||
\item Vereinfachte Beschreibung für Abfolgen:
|
||||
\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!
|
||||
\item Vorbedingung: Prädikat, das vor Aufruf gelten muss
|
||||
\item Nachbedingung: Prädikat, das nach Aufruf gelten muss
|
||||
\item Invariante: Prädikat, das immer gilt
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
Protokollrollen - Dynamisches Verhalten von Schnittstellen
|
||||
\begin{itemize*}
|
||||
\item Ohne Sicht auf innere Implementierung (anders als beim Objektlebenszyklus)
|
||||
\item Protokoll = Kollaboration von Protokollrollen (protocol, protocol role)
|
||||
\item Ohne Sicht auf innere Implementierung
|
||||
\item Protokoll = Kollaboration von Protokollrollen
|
||||
\item Modell: Zustandsautomat
|
||||
\begin{itemize*}
|
||||
\item Genauer: Spezialisierung
|
||||
\item Beschreibung der Synchronisation von Objekten
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
\subsection{Entwurfsmuster}
|
||||
\begin{itemize*}
|
||||
\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)
|
||||
schematische Lösung für eine Klasse verwandter Probleme (Höhere Ebene: Architekturmuster)
|
||||
\begin{itemize*}
|
||||
\item Wie helfen Muster im Entwurf?
|
||||
\begin{itemize*}
|
||||
@ -1277,141 +1180,40 @@ Peer-to-peer
|
||||
\item Verhaltensmuster
|
||||
\end{itemize*}
|
||||
\item Erzeugungsmuster
|
||||
\begin{itemize*}
|
||||
\item Factory Method, Fabrikmethode:
|
||||
\item Implementierungsvarianten; Erzeugung von Objekten wird an Unterklassen delegiert
|
||||
\item Abstract Factory, Abstrakte Fabrik:
|
||||
\item Schnittstelle zur Erzeugung von Familien verwandter Objekte
|
||||
\item Prototype, Prototyp:
|
||||
\item Objekterzeugung durch Vorlage und Kopie
|
||||
\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*}
|
||||
\begin{description*}
|
||||
\item[Factory Method] Implementierungsvarianten; Erzeugung von Objekten wird an Unterklassen delegiert
|
||||
\item[Abstract Factory] Schnittstelle zur Erzeugung von Familien verwandter Objekte
|
||||
\item[Prototype] Objekterzeugung durch Vorlage und Kopie
|
||||
\item[Builder] Trennung von Erzeugung und Repräsentation komplexer Objekte, für Erzeugung unterschiedlicher Repräsentationen
|
||||
\item[Singleton] Sicherstellung, dass nur ein Objekt einer Klasse erzeugt wird, die einen globalen Zugriff bietet
|
||||
\end{description*}
|
||||
\end{itemize*}
|
||||
|
||||
Strukturmuster
|
||||
\begin{itemize*}
|
||||
\item Adapter
|
||||
\begin{itemize*}
|
||||
\item Anpassung der (inkompatiblen) Schnittstelle einer Klasse oder eines Objekts an eine erwartete Schnittstelle
|
||||
\end{itemize*}
|
||||
\item Bridge, Brücke
|
||||
\begin{itemize*}
|
||||
\item Abstraktion (Schnittstelle) von Implementierung entkoppeln, um beide unabhängig zu ändern; Impl.-Klasse nur als Verweis
|
||||
\end{itemize*}
|
||||
\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*}
|
||||
\begin{description*}
|
||||
\item[Adapter] Anpassung der (inkompatiblen) Schnittstelle einer Klasse oder eines Objekts an eine erwartete Schnittstelle
|
||||
\item[Bridge] Abstraktion (Schnittstelle) von Implementierung entkoppeln, um beide unabhängig zu ändern; Impl.-Klasse nur als Verweis
|
||||
\item[Decorator] Objekt dynamisch um Zuständigkeiten erweitern (Alternative zur Bildung von Unterklassen)
|
||||
\item[Facade] Einheitliche Schnittstelle zu einer Schnittstellenmenge, vereinfacht Zugriff
|
||||
\item[Flyweight] Gemeinsame Nutzung kleiner Objekte zur effizienten Verwendung großer Mengen davon (Speicheraufwand)
|
||||
\item[Composite] Zusammenfügen verschiedener Objekte zur Repräsentation von Teil-Ganzes-Beziehungen; Objekte und Kompositionen können einheitlich behandelt werden, Baumstruktur
|
||||
\item[Proxy] kontrollierter Zugriff auf Objekt durch vorgeschaltetes Stellvertreterobjekt
|
||||
\end{description*}
|
||||
|
||||
Verhaltensmuster
|
||||
\begin{itemize*}
|
||||
\item Command, Befehl
|
||||
\begin{itemize*}
|
||||
\item Befehl / Operation als Objekt kapseln (Parameterübergabe, Operations-Warteschlangen, logging, Rückgängig machen)
|
||||
\end{itemize*}
|
||||
\item Observer, Beobachter
|
||||
\begin{itemize*}
|
||||
\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
|
||||
\end{itemize*}
|
||||
\item Visitor, Besucher
|
||||
\begin{itemize*}
|
||||
\item Beschreibung und Kapselung einer zu definierenden Operation, die auf einer Objektmenge ausgeführt wird
|
||||
\end{itemize*}
|
||||
\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*}
|
||||
\begin{description*}
|
||||
\item[Command] Befehl / Operation als Objekt kapseln (Parameterübergabe, Operations-Warteschlangen, logging, Rückgängig machen)
|
||||
\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[Visitor] Beschreibung und Kapselung einer zu definierenden Operation, die auf einer Objektmenge ausgeführt wird
|
||||
\item[Interpreter] Repräsentation der Grammatik einer Sprache sowie Interpreter zur Analyse von Sätzen der Sprache
|
||||
\item[Iterator] Sequentieller Zugriff auf die Elemente einer Sammlung ohne Kenntnis der Implementierung der Sammlung
|
||||
\item[Memento] Internen Zustand eines Objekts erfassen und speichern, um Objektzustand wiederherstellen zu können
|
||||
\item[Template Method] Beschreibung des Skeletts eines Algorithmus mit Delegation der Einzelschritte an Unterklassen; Teilschritte können von Unterklassen geändert werden
|
||||
\item[Strategy] Ermöglicht Austausch verschiedener Implementierungen einer Aufgabe ohne Beeinflussung der sie benutzenden Objekte
|
||||
\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
|
||||
\item[State] Ermöglicht Objekt, sein Verhalten abhängig von seinem inneren Zustand zu ändern, als ob es die Klasse wechselt
|
||||
\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{description*}
|
||||
|
||||
Anwendung von Entwurfsmustern
|
||||
\begin{itemize*}
|
||||
@ -1428,7 +1230,6 @@ Peer-to-peer
|
||||
\end{itemize*}
|
||||
|
||||
\subsection{Klassenbibliotheken und Komponenten}
|
||||
Klassenbibliotheken
|
||||
\begin{itemize*}
|
||||
\item Zusammenfassung von Modulen, Klassen, etc.
|
||||
\item Mit einem bestimmten (abstrakten) Zweck
|
||||
@ -1439,11 +1240,8 @@ Peer-to-peer
|
||||
\item Numerische Routinen, Simulation, ...
|
||||
\end{itemize*}
|
||||
\item Wird in Anwendung eingebunden (importiert), API
|
||||
\begin{itemize*}
|
||||
\item Objekte instanziieren oder Klassen ableiten
|
||||
\end{itemize*}
|
||||
\item Meist passiv: Kontrollfluss wird von Anwendung gesteuert
|
||||
\item Beispiele: stdlib, MFC, GNU scientific library, Java 3D, IPP
|
||||
\end{itemize*}
|
||||
|
||||
Komponentenbasierte Entwicklung
|
||||
@ -1451,11 +1249,7 @@ Peer-to-peer
|
||||
\item Bausteinorientierte Programmierung (component-ware)
|
||||
\item Softwareentwicklung: Konstruktion aus vorgegebenen Bausteinen
|
||||
\item Entsprechung für Wiederverwendung: Generische Bausteine (components)
|
||||
\begin{itemize*}
|
||||
\item Anpassbar, zusammensetzbar
|
||||
\end{itemize*}
|
||||
\item Werkzeuggestützte bzw. grafische Kompositionsmechanismen
|
||||
\item Beispiele: Java Beans, Enterprise Java Beans (EJBs), Microsoft COM+
|
||||
\item Komponenten-Entwicklung oft auch projektspezifisch
|
||||
\item Warum Komponenten
|
||||
\begin{itemize*}
|
||||
@ -1463,17 +1257,15 @@ Peer-to-peer
|
||||
\item Zunehmend verteilte Anwendungen mit offener Struktur und Internet-Anbindung
|
||||
\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 Weg aus der „Software-Krise“?
|
||||
\end{itemize*}
|
||||
\item Eigenschaften von Komponenten
|
||||
\begin{itemize*}
|
||||
\item müssen von ihrer Umgebung und anderen Komponenten unabhängig und getrennt sein
|
||||
\item Kontextabhängigkeiten: benötigte Komponenten-Infrastruktur und Systemressourcen
|
||||
\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 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*}
|
||||
|
||||
@ -1495,13 +1287,12 @@ Peer-to-peer
|
||||
\end{itemize*}
|
||||
|
||||
\subsection{Dokumentation}
|
||||
Dokumentation des Feinentwurfs
|
||||
\begin{itemize*}
|
||||
\item Möglichkeiten
|
||||
\begin{itemize*}
|
||||
\item Eigenständiges Dokument
|
||||
\item Erweiterung des Lastenhefts / Grobkonzepts
|
||||
\item Eingebettet in den Quellcode (Werkzeug, z.B. Javadoc)
|
||||
\item Eingebettet in den Quellcode
|
||||
\end{itemize*}
|
||||
\item Inhalt
|
||||
\begin{itemize*}
|
||||
@ -1514,7 +1305,6 @@ Peer-to-peer
|
||||
|
||||
\newpage
|
||||
\section{Implementierung}
|
||||
Aufgaben der Implementierung
|
||||
\begin{itemize*}
|
||||
\item Aus Spezifikationen Programm(code) erzeugen
|
||||
\item Aufbauend auf Ergebnissen des Feinentwurfs
|
||||
|
||||
Loading…
Reference in New Issue
Block a user