diff --git a/Softwaretechnik - Cheatsheet.pdf b/Softwaretechnik - Cheatsheet.pdf index f276943..f8e5ae1 100644 Binary files a/Softwaretechnik - Cheatsheet.pdf and b/Softwaretechnik - Cheatsheet.pdf differ diff --git a/Softwaretechnik - Cheatsheet.tex b/Softwaretechnik - Cheatsheet.tex index c71c031..a625a95 100644 --- a/Softwaretechnik - Cheatsheet.tex +++ b/Softwaretechnik - Cheatsheet.tex @@ -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 <> \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 <> 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 <> - \item Nachbedingung: Prädikat, das nach Aufruf gelten muss <> - \item Invariante: Prädikat, das immer gilt <> - \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