diff --git a/Softwaretechnik.md b/Softwaretechnik.md index e351043..a89cdcc 100644 --- a/Softwaretechnik.md +++ b/Softwaretechnik.md @@ -771,9 +771,712 @@ Pflichtenheft (Beispiel) # Grobentwurf +## Einführung +Systementwurf – Aufgabe +- Sicht des geplanten Systems von innen (Entwickler) +- Wie sollen vereinbartes Verhalten und Funktionen (Analysemodell) intern realisiert werden? +- Von Spezifikation von Anforderungen und Funktionen -> Vorbereitung der Implementierung +- Formal: Transformation des Analysemodells in ein Systementwurfsmodell +- System(grob)entwurf, Feinentwurf/Objektentwurf +Teile und herrsche +- Grobentwurf + - Entwurfsziele identifizieren + - Grobe Systemstruktur festlegen (Architektur) + - Zerlegung in Subsysteme, Spezifikation + - Schichten, Pakete, Komponenten + - Bewerten der Zerlegung anhand der Entwurfsziele + - Schnittstellen festlegen +- Feinentwurf + - Subsysteme im Detail entwerfen + - Strukturierung der Komponenten + - Klassen, Objekte, Funktionen, Datenstrukturen + - Verhalten, Algorithmen – Teillösungen + + +## Systemzerlegung +Vorgehen +- Zerlegung eines Systems in Subsysteme +- Betrachtung der Lösungsdomäne! +- Subsysteme weiter zerlegen bis Komplexität ausreichend klein ist z.B. für Arbeitspakete + +Was macht ein Subsystem aus? +- Schnittstellen, Funktionen, „Verantwortung“ +- Was bietet es an? +- Was benutzt es? +- Was tut es intern? + +Operation +- Name und Parameter +- Funktion, Prozedur, Methode, Eintrittspunkt ... + +Dienst +- Satz von Operationen, die bereitgestellt werden + +Abhängigkeiten von Subsystemen +- Subsysteme untereinander: Kopplung (coupling) +- Maß für die Abhängigkeit von Subsystemen + +Möglichst lose Kopplung +- Änderungen in einem beteiligten Subsystem haben geringe Auswirkungen (Stabilität) +- Erleichtert Wartbarkeit und Arbeitsteilung + +Mittel zur Verringerung der Kopplung +- Zusätzliche Unterteilung in Subsysteme +- Aber: dann größere Komplexität! + +Abhängigkeiten von Subsystemen +| Kopplungsart | Bemerkung | +| -- | -- | +| Datenkopplung (gemeinsame Daten) | Möglichst vermeiden! Wenn nicht möglich, Verwaltung zentralisieren und Zugriff über Schnittstelle | +| Schnittstellenkopplung (gegenseitiger Aufruf) | Akzeptabel | +| Strukturkopplung (gemeinsame Strukturelemente) | Vermeiden! (z.B. keine Vererbung über Paketgrenzen hinweg) | + +- Elemente eines Subsystems: Kohäsion (cohesion) +- Maß für Zusammengehörigkeit der Elemente +- Möglichst hohe Kohäsion + - Enge Beziehung oder ähnliche Aufgaben der Elemente + - Erleichtert Verständnis, Wartung und Anpassung +- Mittel zum Erreichen hoher Kohäsion + - Datenkapselung, Objektorientierung + - Benutzung geeigneter Patterns (Kapitel 5) + +Metriken für modulare Entwürfe +- Fan-in / fan-out-Metrik [S.Henry, D. Kafura 1981]: + - Fan-in: Anzahl der Stellen, wo Kontrollfluss auf das betrachtete Modul M übergeht (Aufrufe von Funktionen / Prozeduren in M) + Anzahl globaler Variablen, die in M zugänglich sind + - Fan-out: Anzahl von Stellen, an denen M andere Module aufruft + Anzahl der globalen Variablen, die von M verändert werden +- Heuristik Kopplung / Kohäsion + - Hoher Fan-out bedeutet hohe Kopplung, minimieren + - Hoher Fan-in kann auf geringe Kohäsion von M hindeuten + +Komplexität beherrschen: "Wenn Du es nicht in fünf Minuten erklären kannst, hast Du es entweder selbst nicht verstanden oder es funktioniert nicht." [Rechtin, Maier: The Art of Systems Architecting 2000] + +Vorgehen: Heuristiken und Erfahrungen +- „Erfahrung ist die härteste Lehrerin. Sie gibt Dir zuerst den Test und anschließend den Unterricht.“ [Ruth 1993] +- „Ein Architekt der zu Beginn seiner Arbeit vollständige und konsistente Anforderungen benötigt, mag ein brillanter Entwickler sein – aber er ist kein Architekt“ [Rechtin 2000] +- „Das Leben von Software-Architekten besteht aus einer langen und schnellen Abfolge suboptimaler Entwurfs-entscheidungen, die teilweise im Dunkeln getroffen werden.“ [Kruchten2001] + +Wie organisiert man Subsysteme? +- Innerhalb einer Verfeinerungsstufe: fachlich orientierte Zerlegung +- Mehrfache Zerlegung: Hierarchie-Graph der Verfeinerung + +Schicht +- Gruppe von Subsystemen in der Zerlegungshierarchie +- Verwandte Dienste +- Ähnlicher Abstraktionsgrad +- Abhängigkeit nur von darunter liegenden! + +- Geschlossene Schichtenarchitektur + - Beispiel: OSI-Modell für Kommunikationssysteme +- Offene Schichtenarchitektur + - Beispiel: Java Swing auf X11-Plattform + +Prinzipien des OO-Entwurfs +- So-einfach-wie-möglich-Prinzip (KISS) +- Fehler berücksichtigen (Strukturierung, Kapselung, Modularisierung, Wiederverwendung) +- Entwerfen nach Verantwortlichkeiten +- Hohe Kohäsion / Geringe Kopplung +- Zyklische Abhängigkeiten vermeiden +- Auf Schnittstellen konzentrieren + - Abhängigkeiten nur von Schnittstellen + - Abtrennung von Schnittstellen (eher viele kleine als eine große) + - Umkehr der Abhängigkeiten (dependency inversion-Prinzip) +- Offen / Geschlossen Prinzip + +Zyklische Abhängigkeiten vermeiden +- Änderungen wirken sich auf beide Komponenten aus +- Probleme beim Löschen und Initialisieren +- Auflösen durch + - Gemeinsame Klassen in separates Paket + - Gemeinsame Schnittstellen definieren + +Symptome schlechten Designs +- Starrheit + - Einfache Änderungen schwierig realisierbar + - Einfache Änderungen führen zur Modifikation einer Vielzahl von Komponenten +- Zerbrechlichkeit + - Änderungen an einer Stelle führen zu Fehlern an völlig anderer Stelle +- Schlechte Wiederverwendbarkeit + - Komponenten können Aufgrund spezieller Anhängigkeiten kaum wiederverwendet werden + +Wann ist ein Entwurf „gut“? +- Korrekt + - Erfüllung der Anforderungen + - Wiedergabe aller Funktionen des Systemmodells + - Sicherstellung der nichtfunktionalen Anforderungen +- Verständlich und präzise, gut dokumentiert +- Anpassbar +- Hohe Kohäsion innerhalb der Komponenten +- Schwache Kopplung zwischen den Komponenten +- Wiederverwendung +- Kriterien gelten auf allen Ebenen des Entwurfs! (Architektur, Subsysteme, Komponenten) + +## Architekturmodelle +- Modellierung mit UML + - Bisher: logische Sicht + - Technisch: Organisation in Paketen, Namensraum, Import +- Paketdiagramm + - Gliederung (Strukturierung) des Systems in Teile + - Zuordnung von Elementen zu einem Paket + - Hierarchien und Abhängigkeiten zwischen den Paketen + - Anwendung: Definition von Schichten +- Enthält-Beziehung + - Definiert, in welchem Paket ein Element enthalten ist + - Ermöglicht qualifizierten Zugriff auf enthaltene Elemente + - Löschen des Pakets bewirkt Löschen beinhalteter Elemente + - Definition von Sichtbarkeit / Zugriffsrechte + - Auswirkung auf weitere Enthält-Beziehung + - '+' - public (default) + - '-' - private +- Paket- / Element-Import + - Unqualifizierter Zugriff auf Elemente eines anderen Namensraums (Paketes) +- Komponentendiagramm + - Komponente – modulare, austauschbare Einheit + - Strukturierung des Systems durch Komponenten + - Modellierung der + - Abhängigkeiten zwischen Komponenten + - inneren Struktur von Komponenten + - Definition von Schnittstellen + - Verwendung von Elementen aus Klassen- und Objektdiagramm + - Stärkere dynamische Sicht -> kein Verhalten + - Komponente <> + - Kapselt Funktionalitäten (Physisch gruppierte Klassen) + - „Spezialisierte“ Klasse (Vererbung, Exemplare möglich) + - Stellt Funktionalitäten über Schnittstellen bereit + - Definiert benötigte Schnittstellen + - Enthält Klassen oder weitere Komponenten + - Modulares Element: Substitution (Austauschbarkeit) steht im Vordergrund + - Black-Box-Darstellung + - Zur Verfügung gestellte Funktionalität `<>` + - Benötigte Funktionalität `<>`‚ + - White-Box-Darstellung + - Interner Aufbau der Komponente `<>` + - Artefakte `<>`‚ Realisierende physische Einheit (z.B.: .dll) + +Schnittstellen / Interfaces +- Definition Diagrammunabhängig + - Meist Klassendiagramm +- Ähnlich Semantik einer Klasse + - Nur public-Attribute und Operationen +- Definiert Verpflichtung zur Implementierung von + - Operationen + - Merkmale -> Attribute dürfen definiert werden + - Verpflichtungen (z.B.: Vor- / Nachbedingungen) +- Meist abstrakte Klassen mit abstrakten Operationen +- Abstrakt – muss überschrieben werden +- Notation + - Stereotyp: <> + - Meist kursiv geschrieben, da abstrakte Klasse + +Schnittstellenrealisierung, Implementierungsbeziehung +- Schnittstellen werden realisiert, nicht instanziiert +- Schnittstellenkonform + - Klasse realisiert alle Attribute und Operationen +- Schnittstelle kann von anderen Schnittstellen erben +- Keine Schnittstellenrealisierung zwischen zwei Interface-Klassen -> Generalisierung verwenden +- Darstellung + - Gestrichelte Linie mit nicht gefülltem Dreieck an der Seite der Superklasse + - Alternativ: Lollipop-Darstellung + + +## Softwarearchitekturmuster +- Wiederverwendung auf sehr hoher Abstraktionsstufe +- Falls geplante Anwendung passt, anwenden! + +Schichten-Architektur (layers) +- Problem + - Komplexität: Strukturierung des Systems, unterschiedliche Abstraktionsebenen + - Änderungen sollen möglichst lokal bleiben + - Teilsysteme sollen austauschbar, wiederverwendbar und getrennt entwickelbar sein + - Schnittstellen sollen stabil sein +- Lösung + - Zuordnung von Subsystemen zu horizontalen Schichten gleicher Abstraktionsebene + - Komponenten einer Schicht bieten Dienste der darüber liegenden Schicht an + +Client-Server (Klient/Anbieter) +- Client (front-end) + - Benutzungsschnittstelle + - Einbindung in Geschäftsprozesse + - Entkoppelt von Netztechnologie und Datenhaltung +- Server (back-end) + - Datenhaltung, evtl. Fachlogik +- Genauer: Two-tier client/server architecture +- Asynchroner Kontrollfluss +- Aufteilung Funktionen Client / Server + - Mehr Funktionen im Server: + - zentrale Verwaltung, Wartungsaufwand geringer, Portabilität, einfache Client-Hardware (Net PC) + - „Thin Client“ – nur GUI + - Mehr Funktionen im Client: Flaschenhals Server wird entlastet, individuellere Client-Funktionen + - „Fat Client“ – Teil der Anwendung im Client + - Entscheidet mit über Umsetzung (Java Script, ...) + +Three-Tier / Four-Tier Architecture +- Client/Server mit weiterer Aufteilung ähnlich Repository + +Bewertung Client-Server +- Vorteile + - Leicht verständlich + - Änderungen bleiben lokal + - Geringere Kopplung zwischen den Schichten + - Schichten austauschbar und wiederverwendbar + - Getrennte Entwicklung der Schichten möglich + - Vorhandene / stabilere Schnittstellen +- Nachteile + - Geringere Performance + - Zusätzlicher Verwaltungs- oder Datenoverhead + - Manche Änderungen führen zu Änderungen in allen Schichten (z.B. neues Datenfeld) + +Pipes and Filters +- Datenstrom- oder Kontrollflussorientiertes System +- Lose verbundene Berechnungskomponenten +- Kombination der Berechnungskomponenten nur vom Typ der Ein- und Ausgabedaten abhängig +- Leicht erweiterbar System gewünscht +- Parallele Verarbeitung vorteilhaft +- Verwendung von globalen Steuerungskontrollstrukturen (Parallelisierung, Verzweigung, Schleifen) gewünscht +- Vorteile + - Stark entkoppelte Komponenten + - Hohe Flexibilität gegenüber Änderungen & Erweiterungen + - Hoher Wiederverwendungsgrad der Komponenten + - Unabhängige Entwicklung der Komponenten + - Leichte Parallelisierung der Berechnungen möglich + - Überprüfung der Datenkompatibilität dynamisch / statisch +- Nachteile + - Schwierige Fehlerbehandlung, kein expliziter Kontrollfluss + - Fehler durch inkompatible Datentypfehler erst zur Laufzeit + - Häufig zusätzliche Datenkonvertierungen notwendig + + +Plug-In Architektur (Microkernel) +- Zielstellung + - Stabile, verbreitete Standard-Anwendung (Kern) + - Funktionalität soll durch Komponenten leicht erweiterbar sein + - Dritte sollen Komponenten leicht erstellen können +- Lösung + - Möglichst schlanker zentraler Kern + - Plugin-Manager verwaltet Komponenten: Laden, Entladen, Zugriffskontrolle, Konfiguration +- Plugin + - Komponente mit Standard-Schnittstelle + - Erweitert Funktionalität (extension point) +- Vorteile + - Robustes Verhalten + - Trennung der Zuständigkeiten + - Erweiterbar, Austauschbar, Wiederverwendbar + - Geringe Kopplung zu den Komponenten + - Anpassung an eigene Bedürfnisse möglich + - Leichte Aufteilung der Entwicklung der Arbeitspakete +- Nachteile + - Höherer initialer Aufwand + - Verwaltungsoverhead zur Laufzeit + - Versionsverwaltung der Komponenten nötig + - Abhängigkeiten unter den Komponenten schwierig realisierbar + - Geschickte Definition der Extension Points nötig + +Repository (Depot, blackboard) +- Zentrale Datenhaltung + - Datenbankmanagementsystem, Dateisystem +- Anwendungen tauschen Daten nur über Repository aus +- Kontrollfluss z.B. über Signale oder Semaphore +- Gut für datenintensive Verarbeitungsaufgaben geeignet + +Peer-to-peer +- Gleichberechtigte Partner, “Föderation” +- Verteilte kommunizierende Subsysteme +- Orts- und Umgebungsunabhängigkeit + +Model-View-Controller (MVC) +- Modell / Sicht / Steuerung +- Trennung verschiedener Aufgabengebiete: + - Model: verwaltet Domänenwissen, Daten und Zustand; häufig Datenbank + - View: Darstellung, Anzeige, GUI + - Controller: Steuerung der Interaktion, Nutzerbefehle +- Erlauben Austausch von Anzeige- und Speichersystem +- Kontrollfluss + - Controller steuert + - View wird über Datenänderungen benachrichtigt (callback) +- Geeignet für interaktive Systeme +- Problem + - Lose Kopplung zwischen verschiedenen Komponenten + - Daten werden in verschiedenen Sichten dargestellt + - Realisierung von GUI‘s +- Lösung durch drei Komponenten + - Daten (Model) enthält die Kernfunktionalität / Durchführung der Geschäftsprozesse, kapselt und Speichert die Daten + - Sichten bzw. Dialoge (View) stellt die Daten für den Anwender in unterschiedlicher Art dar + - Logik bzw. Steuerung (Controller) Realisiert die Interaktion mit dem Benutzer, übernimmt die Eingaben vom View und ändert die Daten im Modell, legt die Darstellungsart der Sichten fest +- Vorteile + - Unabhängige Entwicklung der Komponenten + - Änderung der Oberfläche ohne Änderung des Modells + - Unterschiedliche Oberflächen für das selbe Modell +- Nachteile + - Performance + - Erhöhter initialer Entwicklungsaufwand + + +## Frameworks +Was ist ein Framework? +- A framework is a set of prefabricated software building blocks that programmers can use, extend, or customize for specific computing solutions [Taligent] +- Ein framework (Rahmenwerk, Anwendungsgerüst) ist eine Menge von zusammengehörigen Klassen, die einen abstrakten Entwurf für eine Problemfamilie darstellen [nach Pomberger/Blaschek] + +Ziele +- Wiederverwendung von Code, Architektur, Entwurfsprinzipien und Verhaltensschema +- Ähnliche Benutzungsschnittstelle + +Klassifikation I +- Anwendungs-Framework (application framework) + - Gibt Systemarchitektur für typische Anwendungsstruktur vor + - GUI-Framework: Motif, Qt, Swing, ... +- Bereichsspezifisches Framework (domain framework) + - Expertenwissen für Anwendungsbereich + - für typische Anwendungen u.a. in den Bereichen Luftfahrt, Produktion, Finanzwesen, Automotive, ... + - Beispiel: AUTOSAR +- Infrastrukturgerüst (support framework) + - Gerätetreiber, Anpassung an Hardware + - Middleware: DCOM, Java RMI, CORBA, WebSphere, ... + +Klassifikation II +- Offene Programmgerüste (white box) + - Erweiterbarkeit durch Vererbung und dynamische Bindung + - Funktionen konkretisieren durch Ableitung von Basisklassen des Programmgerüsts und Überschreiben vordefinierter Methoden +- Geschlossene Programmgerüste (black box) + - Erweiterbarkeit durch Definition von Schnittstellen für Module, die für eine konkrete Anwendung in das Gerüst eingesetzt werden können + - Wiederverwendung durch Komponenten, die sich an Schnittstellen halten; Aufruf über Delegation + + +Webframeworks – Angular JS +- Clientseitiges Webframework von Google +- Frei verwendbar (Open Source) +- Erstellung von Single-Page-Webanwendungen +- Model View Prinzip + +- Vorteile + - Weitergabe von Expertenwissen + - Durchdachtes Design: langfristige Aufwandsersparnis + - Wartungsaufwand reduziert, systematische Tests möglich + - Prinzipiell sehr hohe Produktivität möglich + - Erleichtert Integration und Konsistenz verwandter Anforderungen +- Nachteile + - Erstellung und Einarbeitung aufwändig + - Zusätzlicher Dokumentations- und Wartungsaufwand + - Fehlersuche erschwert durch Overhead des Frameworks + - Kombination verschiedener Frameworks sehr schwierig + +## Systemarchitektur und Verteilung +Systemarchitektur +- Aufbau und Elemente der Ablaufumgebung, Hardware +- Häufig enger Zusammenhang mit Softwarearchitektur + - Architekturmuster + - Ablaufmuster +- Besonders bei eingebetteten Systemen +- Systemarchitektur hat Einfluss auf Softwarearchitektur + - Grenzobjekte, Schnittstellen, ... +- Gute Systemarchitektur? + - Nichtfunktionale Anforderungen + - Modellierung und Simulation, Lastmessungen + - +Typische Strukturen +- Zentralrechner (mainframe) mit Terminals +- Server und einfache Stationen +- PCs und Server +- Kommunikationsverbindungen, Sensoren, Speicher, ... + + +- Blockdiagramm + - Klassisches Beschreibungsmittel für Systemaufbau + - Nicht Teil von UML +- Konfigurationsdiagramm + - meistverbreitetes Hilfsmittel zur Beschreibung der physikalischen Verteilung von System-Komponenten + - Nicht Teil von UML +- Verteilungsdiagramm (UML deployment diagram) + - Darstellung der Hardwaretopologie + - Zuordnung von Artefakten zu Hardwareeinheiten (Knoten) + - Verteilung von Systembestandteilen auf Hardware + - Kommunikationsverbindung und Abhängigkeiten zwischen Knoten + - Relativ spät im Projekt Installation / Wartung des Systems + +## Globaler Kontrollfluss +Globaler Kontrollfluss +- Ablaufsicht der Architektur + - Definition nebenläufiger Systemeinheiten (z.B. Prozesse) + - Steuerung der Abfolge von Einzelfunktionen + - Synchronisation und Koordination + - Reaktion auf externe Ereignisse + - Darstellung z.B. durch Sequenzdiagramme +- Nebenläufigkeit auf Architekturebene + - Threads , Prozesse, verteiltes System + - Asynchroner Nachrichtenaustausch +- Einfluss auf Architektur / abhängig von Architektur! +- Ablaufmuster + - Zentral + - Call/Return (prozedural, synchron) + - Master/Slave (nebenläufig mit zentraler Steuerung) + - Dezentral + - Ereignisgesteuert (event-driven) + - interrupts + - publish-subscribe (ähnlich observer) + - (selective) broadcast + - Datenflussgesteuert (data flow architecture) + +## Sonstiges +Ablauf des OO-Systementwurfs [B. Oesterreich] +- Schichtenmodell definieren +- Verteilungsmodell definieren +- Fachliches Subsystemmodell definieren +- Ablaufverantwortlichkeiten definieren +- Komponentenspezifisches Klassenmodell entwickeln +- Komponentenschnittstelle entwerfen +- Zustandsmodelle weiterentwickeln +- Objektfluss modellieren +- Interaktionsmodelle entwickeln, Attribute definieren +- Dialoge spezifizieren +- Design-Diskurs +- Testgetriebene Entwicklung + +Weitere Aufgaben beim Grobentwurf +- Entwurf einer persistenten Datenverwaltung + - Dateisystem, Datenbank +- Sicherheit + - Zugriffskontrolle + - Fehlertoleranz (Daten und Hardware) + - Protokollfunktionen +- Kontrollfluss + - Ausnahmen + - Starten, Initialisieren und Beenden der Anwendung + - „Randanwendungsfälle“ + +Notwendigkeit der Architekturdokumentation +- Quellcode aufgrund niedrigen Abstraktionsniveaus ungünstig für Dokumentation +- Überblick und Arbeitsteilung +- Lebensdauer von Systemen länger als geplant +- Fehler und Probleme leichter finden und beseitigen +- Neue Anforderungen mit angemessenem Aufwand erfüllen +- Vereinfachung der Wartung, Pflege, Erweiterung, Wiederverwendung + +## Dokumentation +- Grundprinzipien + - Verständlich aus Sicht des Lesers formulieren (Glossar) + - Das Warum beschreiben (Entwurfsentscheidungen) + - Annahmen, Voraussetzungen, Randbedingungen dokumentieren + - Wiederholungen vermeiden + - Notation erklären oder Standards verwenden (UML) + - Legende hinzufügen + - Auf Zweckdienlichkeit prüfen, Reviews durchführen (Inhalt, Qualität) + - Verschiedene Sichten für verschiedene Zielgruppen # Feinentwurf + +| Analyse-Modell | Entwurfs-Modell | +| -- | -- | +| 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 +- Identifizieren und Entwerfen von Klassen der Lösungsdomäne +- Identifikation und Verwendung von Entwurfsmustern +- Detaillierte Beschreibung der Klassen +- Beschreibung von Schnittstellen +- Iterativer Prozess! + - Verbesserung des Entwurfs – Refactoring + - Optimieren des Entwurfsmodells zur Erfüllung nichtfunktionaler Anforderungen + +Objektorientierter Feinentwurf +- Ausgangspunkt + - Grobdefinition der Architektur, Zerlegung in Subsysteme (evtl. unter Verwendung von Standardarchitekturen) + - Verteilungskonzept + - Ablaufmodell +- Ergebnis + - OO-Modell für jedes Subsystem der Architektur + - OO-Modell für unterstützende Subsysteme unter Berücksichtigung gewählter Technologien + - Spezifikationen der Klassen + - Spezifikationen von externen Schnittstellen + +## Klassen- und Objektentwurf +- Klassen der Lösungsdomäne + - Klassen, die nicht durch objektorientierte Analyse der Anwendungsdomäne entstehen +- Entstehungsgründe + - Architektur von Software und System + - nichtfunktionale Anforderungen + - Beispiele: Kommunikation, Fehlertoleranz, Adapter, Datenhaltung, Effizienz, Benutzerschnittstellenobjekte, Middleware, ... + - Sichtbare (Grenz- und Steuerungsobjekte) werden schon in der Analyse identifiziert + +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 +- Sichtweise auf Softwaresystem +- Application = set of interacting objects +- Object = implementation of role(s) +- Role = set of related responsibilities +- Responsibility = obligation to perform a task or know information +- Collaboration = interaction of objects or roles +- Contract = agreement outlining collaboration terms + +Arten von Rollen +||| +|--|--| +| Information holder | knows and provides information | +| Structurer | maintains relationship between objects and information about relationships | +| Service provider | performs work, offers computing services | +| Coordinator | reacts to events by delegating tasks to others | +| Controller | makes decisions and directs other’s actions | +| Interfacer | transforms information and requests between system parts | + +Hilfsmittel: CRC-Karten +- Candidate (or class), Responsibility, Collaboration +- Informelles Mittel zum + - Finden, + - Beschreiben und + - iterativen Verändern von Klassen + +Ein Objekt +- implementiert eine Schnittstelle und beeinflusst andere Objekte +- wird in drei Teilen entworfen + - Öffentliche Schnittstelle + - Art und Weise der Benutzung + - Innere Details der Funktionsweise +- Kohärenz: zusammengehörende Verantwortlichkeiten in einer Klasse konzentrieren! + + +## Entwurfsprinzipien +- Kapselung + - Probleme: Zugriff auf private oder ebenen-fremde Attribute + - Verwenden von get- und set-Operationen + - Zusicherungen einhalten + - Zugriffe zentralisieren + - Verbalisierung + - Zugriffsbeschränkung +- Zerlegung + - Teile und Herrsche + - Zerlegen in Komponenten + - Verantwortlichkeitsprinzip: Komponente ist klar für eine Aufgabe verantwortlich + - Eigenschaften und Schnittstellen im Klassendiagramm + - Beziehungen zwischen Klassen: Assoziationen + - Aggregation + - „besteht aus“, „ist Teil von“ oder „Ganzes-/Teile-Beziehung“ + - Schwache Bindung der Teile mit dem Ganzen + - Notation: ungefüllte Raute am Ganzen + - Komposition + - Wie Aggregation, jedoch stärkere Bindung + - Teil nur einem Ganzen zugeordnet + - Nur Multiplizität von 1 oder 0..1 möglich! + - Gefüllte Raute am Ganzen +- Polymorphie + - Reaktion auf eine Nachricht abhängig vom Typ des Objektes + - Variablen können Objekte verschiedener Klassen aufnehmen (Voraussetzung: Typ der Variablen ist eine gemeinsame Basisklasse der (davon) abgeleiteten Klasse(n) der Objekte) + - Überladen von Operationen + - gleicher Operationsname, unterschiedliche Signatur + - abstrakte Operationen: Virtuelle Operationen ohne Implementierung + - abstrakte Klasse: Klasse mit abstrakten Operationen + - Folgen + - von abstrakten Klassen können keine Objekte angelegt werden (Implementierung fehlt) + - Abgeleitete Klassen müssen Operation implementieren, damit Objekte angelegt werden können + +Vererbung im Entwurf +- In der Analyse: Klassifikation von Objekten, Taxonomie, Spezialisierung/Verallgemeinerung, Organisation von Klassen in Hierarchien +- Verringerung von Redundanz und damit Inkonsistenzen + - Funktionalität nur einmal implementieren! + - Spezifikations-Wiederverwendung + - Implementierungs-Wiederverwendung +- Verbesserung der Erweiterbarkeit + - Abstrakte Schnittstellen einsetzen! + +Vererbung oder Assoziation +- Schlüsselwort Vererbung: ist ein +- Schlüsselwort Assoziation: besteht aus, ist Teil, hat,... +- Vererbung: Unterscheidungsmerkmal definierbar (Diskriminator) +- Vermeide Vererbung, wenn es Alternativen gibt +- Mehrfachvererbung + - Problem: Unabhängige Aspekte der Vererbungshierarchie + - Vermeidung: abstrakte Klassen oder Komposition + +Abstrakte Klassen +- Nur Unterklassen, keine Instanzen +- Attribute in Unterklassen füllen +- Notation: Kursiv oder Stereotyp <> + +Offen / Geschlossen-Prinzip [Meyer 1988] +- Erweiterbarkeit eines Entwurfs +- Offen für Erweiterungen, + - z.B. durch Vererbung / Polymorphie + - Virtuelle Operationen verwenden + - Verändert vorhandenes Verhalten nicht + - Erweiterung um zusätzliche Funktionen oder Daten +- Geschlossen für Änderungen + - private Attribute + - Möglichst protected Operationen +- Beschränkung der Erweiterbarkeit + - Keine Einschränkungen der Funktionalität der Basisklasse! + +Liskovsches Ersetzungsprinzip +- 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] +- Engere Definition als „ist-ein“-Beziehung +- Kein unerwartetes Verhalten eines Objektes eines Subtyps +- Methoden, die Objekte der Basisklasse erwarten, müssen auch mit Objekten der abgeleiteten Klasse funktionieren +- Zusicherungen der Basisklasse müssen von der abgeleiteten Klasse erfüllt werden! + +Gesetz von Demeter (LoD) +- Gesetz von „schüchternen“ Objekten +- Objekte sollen nur mit Objekten in ihrer unmittelbaren Umgebung kommunizieren +- Aus einer Methode M dürfen (sollten) nur Nachrichten an Objekte gesendet werden, die ... + - unmittelbarer Bestandteil des Objekts von M sind (super) + - M als Argument übergeben wurden + - direkt in M erzeugt wurden + - (oder sich in globalen Variablen befinden) +- Als Metrik überprüfbar + +Ein Objekt sollte +- Nur Methoden aufrufen, die zur eigenen Klasse gehören +- Nur Methoden von Objekten aufrufen, die: + - Von Attributen referenziert werden + - Als Parameter übergeben wurden + - Selbst erzeugt wurden + + +## Entwurfsmodelle +Klassendiagramm +- Eigenschaften + - Modellierung der statischen Struktur (Aufbau) + - Modellierung der Struktur von Daten + - Klasse im Mittelpunkt (Aufbau, Beziehungen zueinander) + - Wichtigstes und bekanntestes Diagramm der UML! +- Elemente des Klassendiagramms + - Klasse (Attribute, Operationen) + - Vererbung / Realisierung + - Assoziationen + - Beziehungen / Abhängigkeiten +- Attribute + - Klassenattribut: "X" static – statisch, nur einmal pro Klasse vorhanden + - Sichtbarkeit + - "+" public – im Namensraum sichtbar + - "#" protected – nur in abgeleiteten Klassen sichtbar + - "~" package – im Paket sichtbar + - "-" private – nur in der Klasse selbst sichtbar + - Ableitung "/" derived – abgeleitetes Attribut +- Weitere Eigenschaften + - readOnly – nach Initialisierung nicht änderbar + - composite – Aggregation: Composition + - redefines X – überschreibe Attr. der Oberklasse + - subsets X – Teilmenge + - union – Attribut ist Vereinigung der subsets + - unique – Elemente eindeutig (Schlüsselattribut) + - ordered – Elemente sind geordnet (unordered) + - sequence – Speicherung der Elemente als Liste + - bag – Elemente sind Multimenge + + +## Schnittstellen + + +## Entwurfsmuster + + +## Klassenbibliotheken und Komponenten + + +## Dokumentation + # Implementierung # Vorgehensweise # Projektmanagement \ No newline at end of file