Feinentwurf
This commit is contained in:
		
							parent
							
								
									e0fdf429ba
								
							
						
					
					
						commit
						c125604a5b
					
				| @ -1464,19 +1464,226 @@ Klassendiagramm | ||||
|   - ordered – Elemente sind geordnet (unordered) | ||||
|   - sequence – Speicherung der Elemente als Liste | ||||
|   - bag – Elemente sind Multimenge | ||||
| - Parameterlisten | ||||
|   - in: Eingangsparameter | ||||
|   - out: Ausgangsparameter | ||||
|   - inout: Eingangs- und Ausgangsparameter | ||||
|   - return: Rückgabewert | ||||
| - Beziehungen | ||||
|   - navigierbar/unspezifiziert/nicht-navigierbar | ||||
|   - ungerichtete/gerichtete Relation/assoziation | ||||
| 
 | ||||
| Aktive Klassen | ||||
| - Reagieren nicht nur, sondern werden von sich aus aktiv | ||||
| - Z.B. Steuerobjekte | ||||
| - Als Thread oder Prozess realisiert | ||||
| 
 | ||||
| ## Schnittstellen | ||||
| - Vereinbarung über Art des Aufrufs | ||||
|   - Homogenität gleicher Funktionen | ||||
|   - Enthält | ||||
|     - Spezifikation von Operationen | ||||
|     - keine Implementierung ( Java, nicht UML!) | ||||
|     - keine Attribute | ||||
|   - In Java außerdem anstelle von Mehrfachvererbung | ||||
| - Schnittstellen in UML | ||||
|   - Funktion ähnlich abstrakter Klasse | ||||
|   - Meist für technische Aspekte | ||||
|   - Notation: Stereotyp <<interface>> oder grafisch (lollipop notation) | ||||
| - Verträge („design by contract“) | ||||
|   - Schnittstelle sagt bisher nichts über Effekt der Klasse aus | ||||
|   - Vollständige Beschreibung wäre Programm? | ||||
|   - Vereinfachte Beschreibung für Abfolgen: | ||||
|     - Vorbedingung: Prädikat, das vor Aufruf gelten muss <<precondition>> | ||||
|     - Nachbedingung: Prädikat, das nach Aufruf gelten muss <<postcondition>> | ||||
|     - Invariante: Prädikat, das immer gilt <<invariant>> | ||||
|   - Jeweils Einschränkungen! | ||||
| 
 | ||||
| Protokollrollen - Dynamisches Verhalten von Schnittstellen | ||||
| - Ohne Sicht auf innere Implementierung (anders als beim Objektlebenszyklus) | ||||
| - Protokoll = Kollaboration von Protokollrollen (protocol, protocol role) | ||||
| - Modell: Zustandsautomat | ||||
|   - Genauer: Spezialisierung | ||||
|   - Beschreibung der Synchronisation von Objekten | ||||
| 
 | ||||
| ## Entwurfsmuster | ||||
| - Warum Wiederverwendung? | ||||
|   - Geringerer Aufwand | ||||
|   - Das Rad nicht noch einmal neu erfinden | ||||
|   - Verwenden üblicher, aus Erfahrung gewachsener Strukturen | ||||
| - ... und warum nicht? | ||||
|   - Aufwand für Anpassung kann hoch sein! | ||||
|   - Einarbeiten in teilweise komplexe Schnittstellen | ||||
|   - Abhängigkeit von externen Komponenten, Zwang zu späterer Portierung | ||||
| 
 | ||||
| > Was ist ein Entwurfsmuster? Eine schematische Lösung für eine Klasse verwandter Probleme (Höhere Ebene: Architekturmuster) | ||||
| - Wie helfen Muster im Entwurf? | ||||
|   - Identifizieren von Klassen (Anwendungs- und Lösungsdomäne) | ||||
|   - Regeln sind abstrakt oder an realen Objekten orientiert | ||||
|   - Muster: Arten von Rollen bzw. Lösungshinweise für typische Strukturierungsaufgaben | ||||
|   - Änderbarkeit und Lesbarkeit des Entwurfs verbessern | ||||
| - Arten von Entwurfsmustern | ||||
|   - Erzeugungsmuster | ||||
|   - Strukturmuster | ||||
|   - Verhaltensmuster | ||||
| - Erzeugungsmuster | ||||
|   - Factory Method, Fabrikmethode | ||||
|     - Implementierungsvarianten; Erzeugung von Objekten wird an Unterklassen delegiert | ||||
|   - Abstract Factory, Abstrakte Fabrik | ||||
|     - Schnittstelle zur Erzeugung von Familien verwandter Objekte | ||||
|   - Prototype, Prototyp | ||||
|     - Objekterzeugung durch Vorlage und Kopie | ||||
|   - Builder, Erbauer | ||||
|     - Trennung von Erzeugung und Repräsentation komplexer Objekte, für Erzeugung unterschiedlicher Repräsentationen | ||||
|   - Singleton | ||||
|     - Sicherstellung, dass nur ein Objekt einer Klasse erzeugt wird, die einen globalen Zugriff bietet | ||||
| 
 | ||||
| Strukturmuster | ||||
| - Adapter | ||||
|   - Anpassung der (inkompatiblen) Schnittstelle einer Klasse oder eines Objekts an eine erwartete Schnittstelle | ||||
| - Bridge, Brücke | ||||
|   - Abstraktion (Schnittstelle) von Implementierung entkoppeln, um beide unabhängig zu ändern; Impl.-Klasse nur als Verweis | ||||
| - Decorator, Dekorierer | ||||
|   - Objekt dynamisch um Zuständigkeiten erweitern (Alternative zur Bildung von Unterklassen) | ||||
| - Facade, Fassade | ||||
|   - Einheitliche Schnittstelle zu einer Schnittstellenmenge, vereinfacht Zugriff | ||||
| - Flyweight, Fliegengewicht | ||||
|   - Gemeinsame Nutzung kleiner Objekte zur effizienten Verwendung großer Mengen davon (Speicheraufwand) | ||||
| - Composite, Verbund, Kompositum | ||||
|   - Zusammenfügen verschiedener Objekte zur Repräsentation von Teil-Ganzes-Beziehungen; Objekte und Kompositionen können einheitlich behandelt werden, Baumstruktur | ||||
| - Proxy, Stellvertreter | ||||
|   - Kontrollierter Zugriff auf Objekt durch vorgeschaltetes Stellvertreterobjekt | ||||
|   - Gründe: Schutz, entfernter Zugriff (remote proxy), smart pointer, Erzeugung on demand | ||||
| 
 | ||||
| Adapter | ||||
| - Vorteile | ||||
|   - Kommunikation unabhängiger Softwarekomponenten | ||||
|   - Einfache Erweiterung um zusätzliche Funktionalität | ||||
|   - Austausch der Komponente durch Änderung des Adapters leicht möglich | ||||
| - Nachteile | ||||
|   - Zusätzlicher Adaptierungsschritt benötigt Zeit | ||||
|   - Schlechte Wiederverwendbarkeit der Adapter | ||||
| - Bekannte Verwendung, Spezialfälle | ||||
|   - Fassade: Adapter eines Teilsystems | ||||
|   - Proxy: erweitert die Funktionalität bei gleicher Schnittstelle | ||||
|   - Brücke: keine Anpassung, sondern vorherige Strukturierung | ||||
| 
 | ||||
| Verhaltensmuster  | ||||
| - Command, Befehl | ||||
|   - Befehl / Operation als Objekt kapseln (Parameterübergabe, Operations-Warteschlangen, logging, Rückgängig machen) | ||||
| - Observer, Beobachter | ||||
|   - 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 | ||||
| - Visitor, Besucher | ||||
|   - Beschreibung und Kapselung einer zu definierenden Operation, die auf einer Objektmenge ausgeführt wird | ||||
| - Interpreter | ||||
|   - Repräsentation der Grammatik einer Sprache sowie Interpreter zur Analyse von Sätzen der Sprache | ||||
| - Iterator | ||||
|   - Sequentieller Zugriff auf die Elemente einer Sammlung ohne Kenntnis der Implementierung der Sammlung | ||||
| - Memento | ||||
|   - Internen Zustand eines Objekts erfassen und speichern, um Objektzustand wiederherstellen zu können | ||||
| - Template Method, Schablonenmethode | ||||
|   - Beschreibung des Skeletts eines Algorithmus mit Delegation der Einzelschritte an Unterklassen; Teilschritte können von Unterklassen geändert werden | ||||
| - Strategy, Strategie | ||||
|   - Ermöglicht Austausch verschiedener Implementierungen einer Aufgabe ohne Beeinflussung der sie benutzenden Objekte | ||||
| - Mediator, Vermittler | ||||
|   - 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 | ||||
| - State, Zustand | ||||
|   - Ermöglicht Objekt, sein Verhalten abhängig von seinem inneren Zustand zu ändern, als ob es die Klasse wechselt | ||||
| - Chain of Responsibility, Zuständigkeitskette | ||||
|   - Vermeidet direkte Kopplung von Auslöser und Empfänger einer Anfrage bzw. Operation. Mehrere Objekte werden nacheinander benachrichtigt, bis die Anfrage erledigt ist | ||||
| 
 | ||||
| Bewertung Observer | ||||
| - Vorteile | ||||
|   - Entkopplung von Komponenten und Schichten möglich | ||||
|   - Broadcast und selective Broadcast möglich | ||||
| - Nachteile | ||||
|   - Bei vielen Beobachtern: Benachrichtigung aufwendig | ||||
|   - Unerwartete Änderung, Änderungskaskaden und Rekursion | ||||
|   - Abmelden der Beobachter vor dem Löschen | ||||
| - Bekannte Verwendung, Spezialfälle | ||||
|   - Verwendung im Model-View-Controller Muster | ||||
|   - Qt: Signal / Slot-Prinzip ähnlich | ||||
| 
 | ||||
| Anwendung von Entwurfsmustern | ||||
| - Untersuche Anwendbarkeit und Konsequenzen | ||||
| - Analysiere Struktur, Teilnehmer und Kollaborationen | ||||
| - Wähle aus dem Anwendungskontext Namen für Teilnehmer | ||||
| - Spezifiziere die teilnehmenden Klassen | ||||
|   - Deklariere Schnittstellen, Vererbung und Variablen | ||||
|   - Identifiziere existierende Entwurfsklassen, die durch das Muster beeinflusst werden | ||||
| - Wähle anwendungsspezifische Namen für Operationen | ||||
| - Implementiere Operationen entsprechend den Verantwortlichkeiten und Kollaborationen des Musters | ||||
| 
 | ||||
| ## Klassenbibliotheken und Komponenten | ||||
| Klassenbibliotheken | ||||
| - Zusammenfassung von Modulen, Klassen, etc. | ||||
| - Mit einem bestimmten (abstrakten) Zweck | ||||
|   - Abstrakte Datenverwaltung, Templates | ||||
|   - Grundlegende System-Aufgaben | ||||
|   - Untere Kapselungs-Schicht des Laufzeitsystems oder der Programmierumgebung | ||||
|   - Numerische Routinen, Simulation, ... | ||||
| - Wird in Anwendung eingebunden (importiert), API | ||||
|   - Objekte instanziieren oder Klassen ableiten | ||||
| - Meist passiv: Kontrollfluss wird von Anwendung gesteuert | ||||
| - Beispiele: stdlib, MFC, GNU scientific library, Java 3D, IPP | ||||
| 
 | ||||
| Komponentenbasierte Entwicklung | ||||
| - Bausteinorientierte Programmierung (component-ware) | ||||
| - Softwareentwicklung: Konstruktion aus vorgegebenen Bausteinen | ||||
| - Entsprechung für Wiederverwendung: Generische Bausteine (components) | ||||
|   - Anpassbar, zusammensetzbar | ||||
| - Werkzeuggestützte bzw. grafische Kompositionsmechanismen | ||||
| - Beispiele: Java Beans, Enterprise Java Beans (EJBs), Microsoft COM+ | ||||
| - Komponenten-Entwicklung oft auch projektspezifisch | ||||
| - Warum Komponenten | ||||
|   - Monolithische, proprietäre Software führt zunehmend zu Problemen | ||||
|   - Zunehmend verteilte Anwendungen mit offener Struktur und Internet-Anbindung | ||||
|   - Zusammensetzen der Funktionalität aus standardisierten Elementen, die über offene Schnittstellen kommunizieren | ||||
|   - Komponenten sollen Flexibilität bei sich ändernden Anforderungen erhöhen | ||||
|   - Weg aus der „Software-Krise“? | ||||
| - Eigenschaften von Komponenten | ||||
|   - müssen von ihrer Umgebung und anderen Komponenten unabhängig und getrennt sein | ||||
|     - Kontextabhängigkeiten: benötigte Komponenten-Infrastruktur und Systemressourcen | ||||
|     - Kapseln ihre angebotenen Funktionen | ||||
|   - Werden immer als ganze Einheit eingesetzt; alle Bestandteile sind enthalten (Archiv-Datei) | ||||
|   - Sind nicht von Kopien ihrer selbst unterscheidbar | ||||
|   - Klare Spezifikation der Schnittstelle nötig; explizit definierte Interaktionen mit Komponenten und Umgebung | ||||
|   - Komposition durch Dritte: Endbenutzer, Komponenten-Hersteller und Komponenten-Integrator; meist nur kompilierter Code verfügbar | ||||
| 
 | ||||
| Komponenten für Client/Server-Architekturen | ||||
| - Wichtige Aspekte | ||||
|   - Transaktionen | ||||
|   - Sicherheit | ||||
|   - Ressourcenverwaltung | ||||
|   - Persistenz | ||||
| - Komponentenkonzept für Server-Komponenten | ||||
|   - meist unsichtbare Komponenten | ||||
|   - standardisierte Realisierung der wichtigen Eigenschaften für Client/Server-Anwendungen | ||||
|   - Realisierung: Enterprise Java Beans (EJBs) innerhalb eines Java Enterprise Edition Servers | ||||
| 
 | ||||
| ## Dokumentation | ||||
| Dokumentation des Feinentwurfs | ||||
| - Möglichkeiten | ||||
|   - Eigenständiges Dokument | ||||
|   - Erweiterung des Lastenhefts / Grobkonzepts | ||||
|   - Eingebettet in den Quellcode (Werkzeug, z.B. Javadoc) | ||||
| - Inhalt | ||||
|   - Ähnlich Grobkonzept | ||||
|   - Zusätzlich detaillierte Modelle | ||||
|   - Abwägungen des Objektentwurfs | ||||
|   - Klassenschnittstellen | ||||
| 
 | ||||
| # Implementierung | ||||
| ## Konventionen und Werkzeuge | ||||
| ## Code-Qualität | ||||
| ## Dokumentation | ||||
| ## Codegenerierung | ||||
| ## Implementierung aktiver Objekte | ||||
| ## Verifikation und Testen | ||||
| ## Testaktivitäten und Werkzeuge | ||||
| ## Softwareverteilung | ||||
| 
 | ||||
| # Vorgehensweise | ||||
| 
 | ||||
| 
 | ||||
| # Projektmanagement | ||||
		Loading…
	
		Reference in New Issue
	
	Block a user