diff --git a/Softwaretechnik - Cheatsheet.pdf b/Softwaretechnik - Cheatsheet.pdf index 5f894f9..f276943 100644 Binary files a/Softwaretechnik - Cheatsheet.pdf and b/Softwaretechnik - Cheatsheet.pdf differ diff --git a/Softwaretechnik - Cheatsheet.tex b/Softwaretechnik - Cheatsheet.tex index cdc95dc..c71c031 100644 --- a/Softwaretechnik - Cheatsheet.tex +++ b/Softwaretechnik - Cheatsheet.tex @@ -185,48 +185,17 @@ \end{itemize*} \subsection{Klassische Modelle} - \begin{itemize*} - \item Funktionen - \begin{itemize*} - \item Funktionsbaum - \item Blockschaltbild - \end{itemize*} - \item Daten - \begin{itemize*} - \item Data Dictionary (Daten mit Strukturinformationen) - \item Entity Relationship Diagram - \end{itemize*} - \item Systemumgebung (Datenflussdiagramm) - \item Algorithmen - \begin{itemize*} - \item Entscheidungstabelle - \item Pseudocode - \item Programmablaufplan - \item Struktogramm - \end{itemize*} - \item Dynamisches Verhalten (diskrete Zustände und atomare zustandübergänge) - \begin{itemize*} - \item Zustandsautomat - \item Flow-Chart - \item Ereignisgesteuerte Prozesskette (EPK) - \item Petri-Netz (ggf. mit Zeitmodell) - \end{itemize*} - \item Objektorientierte Modelle - \begin{itemize*} - \item Klassendiagramme - \item UML - \end{itemize*} - \item Struktur-Diagramme - \begin{itemize*} - \item Klassen-, Objekt-, Komponenten-, Kompositions-Struktur-, - \item Paket- und Verteilungsdiagramm - \end{itemize*} - \item Verhaltens-Diagramme - \begin{itemize*} - \item Use-Case-, Aktivitäts- und Zustandsdiagramms - \item Interaktionsdiagramme: Sequenz-, Kommunikations-, Timing- und Interaktionsübersichts-Diagramm - \end{itemize*} - \end{itemize*} + \begin{description*} + \item[Funktionen] Funktionsbaum, Blockschaltbild + \item[Daten] Data Dictionary, Entity Relationship Diagram + \item[Systemumgebung] Datenflussdiagramm + \item[Algorithmen] Entscheidungstabelle, Pseudocode, Programmablaufplan + \item[Dynamisches Verhalten] diskrete Zustände und atomare zustandübergänge; Zustandsautomat, Flow-Chart + \item[Objektorientierte Modelle] Klassendiagramme, UML + \item[Struktur] Klassen-, Objekt-, Komponenten-, Kompositions-Strukturdiagramm + \item[Verhalten] Use-Case-, Aktivitäts- und Zustandsdiagramms + \item[Interaktion] Sequenz-, Kommunikations-, Timing-Diagramm + \end{description*} \paragraph{Use-Case-Diagramm} \begin{itemize*} @@ -259,6 +228,12 @@ \item Bildung von Hierarchien (Enthält-Beziehung) \item Abhängigkeiten zwischen den Paketen \item Zum Grobentwurf von Systemen + \item Löschen des Pakets bewirkt Löschen beinhalteter Elemente + \item Definition von Sichtbarkeit / Zugriffsrechte + \begin{itemize*} + \item '+' - public (default) + \item '-' - private + \end{itemize*} \end{itemize*} \paragraph{Komponentendiagramm} @@ -268,6 +243,16 @@ \item Modellierung der Abhängigkeiten zwischen Komponenten \item Modellierung der inneren Struktur von Komponenten \item Definition von Schnittstellen + \item Black-Box-Darstellung + \begin{itemize*} + \item Zur Verfügung gestellte Funktionalität + \item Benötigte Funktionalität + \end{itemize*} + \item White-Box-Darstellung + \begin{itemize*} + \item Interner Aufbau der Komponente + \item Artefakte‚ Realisierende physische Einheit + \end{itemize*} \end{itemize*} \paragraph{Kompositionsstrukturdiagramm} @@ -284,11 +269,7 @@ \item Geschäftsprozessmodellierung möglich \item Abstrakte und detaillierte Verhaltensbeschreibung möglich \item Grundlage zur Codegenerierung - \item Zur Verfeinerung von - \begin{itemize*} - \item Use-Cases - \item Operationen / Interaktionen - \end{itemize*} + \item Zur Verfeinerung von Use-Cases \end{itemize*} \paragraph{Interaktionsdiagramme} @@ -315,16 +296,15 @@ \item Weitere Elemente des Sequenzdiagramms \begin{itemize*} \item Nachrichten ohne Sender z.B. am Beginn einer Interaktion - \item Verlorene Nachrichten (ohne Empfänger) z. B. am Ende einer Interaktion - \item Erzeugen von Lebenslinien - \item Zerstören von Lebenslinien + \item Verlorene Nachrichten (ohne Empfänger) + \item Erzeugen/Zerstören von Lebenslinien \end{itemize*} \end{itemize*} \paragraph{Kommunikationsdiagramm} \begin{itemize*} - \item Kommunikationsbeziehungen der Kommunikationspartner stehen im Vordergrund - \item Welche Komponenten arbeiten wie zusammen, um eine Funktion zu erfüllen + \item Kommunikationsbeziehungen der Kommunikationspartner stehen + \item Welche Komponenten arbeiten zusammen $\rightarrow$ Funktion erfüllen \end{itemize*} \paragraph{Timing-Diagramm} @@ -334,7 +314,6 @@ \item Modellierung einzelner Interaktion \item Zeitlicher Verlauf senkrecht \item Kommunikationspartner waagerecht (unsortiert) - \item Ereignisspezifikation \item Trace: Folge von Sende- und Empfangsereignissen \end{itemize*} @@ -347,14 +326,30 @@ \item Ereignisse, die Zustandswechsel auslösen \end{itemize*} \item Modellierung von endlichen Automaten (Zustandsmaschinen) - \begin{itemize*} - \item Deterministische - \item Nichtdeterministische - \end{itemize*} - \item Modellierung von verteilten Systemen / parallelem Verhalten + \item Modellierung von verteilten Systemen/parallelem Verhalten \item Grundlage zur Codegenerierung \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*} + + 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} @@ -397,7 +392,7 @@ \begin{itemize*} \item Werden nicht umgesetzt \item Schränken Lösungsraum ein - \item Kosten, Durchlaufzeit, Technische Randbedingungen + \item Kosten, Durchlaufzeit, Technische Randbedingungen \end{itemize*} %![Analysebaum von Sommerville](Assets/Softwaretechnik1_Analyseformen1.png) @@ -540,31 +535,31 @@ \item Dynamisches Modell (Zustands- und Sequenzdiagramme) \item Unterscheidung der Objekttypen \end{itemize*} - %![Analyse nach Brügge/Dutoit](Assets/Softwaretechnik1_Bruegge1.png) - %![Analyse nach Brügge/Dutoit](Assets/Softwaretechnik1_Bruegge2.png) - \item Objektarten im Systemmodell - \begin{description*} - \item[Entitätsobjekte] vom System verwaltete Informationen - \item[Grenzobjekte] Interaktion zwischen System und Akteuren - \item[Steuerungsobjekte] Durchführung der Anwendungsfälle - \end{description*} - \item Identifizierung von Entitätsobjekten - \begin{itemize*} - \item Begriffe, die klargestellt werden müssen - \item Wiederkehrende Substantive in Anwendungsfällen - \item Reale Objekte, die das System kennen muss - \item Reale Prozesse, die das System verfolgen muss - \item Anwendungsfälle - \item Datenquellen und -senken - \end{itemize*} - \item Identifizierung von Grenzobjekten - \begin{itemize*} - \item Elemente der Benutzungsschnittstelle - \item Formulare für Eingaben - \item Nachrichten, Rückmeldungen - \item Endgeräte - \end{itemize*} - \item Identifizierung von Steuerungsobjekten + %![Analyse nach Brügge/Dutoit](Assets/Softwaretechnik1_Bruegge1.png) + %![Analyse nach Brügge/Dutoit](Assets/Softwaretechnik1_Bruegge2.png) + \item Objektarten im Systemmodell + \begin{description*} + \item[Entitätsobjekte] vom System verwaltete Informationen + \item[Grenzobjekte] Interaktion zwischen System und Akteuren + \item[Steuerungsobjekte] Durchführung der Anwendungsfälle + \end{description*} + \item Identifizierung von Entitätsobjekten + \begin{itemize*} + \item Begriffe, die klargestellt werden müssen + \item Wiederkehrende Substantive in Anwendungsfällen + \item Reale Objekte, die das System kennen muss + \item Reale Prozesse, die das System verfolgen muss + \item Anwendungsfälle + \item Datenquellen und -senken + \end{itemize*} + \item Identifizierung von Grenzobjekten + \begin{itemize*} + \item Elemente der Benutzungsschnittstelle + \item Formulare für Eingaben + \item Nachrichten, Rückmeldungen + \item Endgeräte + \end{itemize*} + \item Identifizierung von Steuerungsobjekten \item Abläufe der Anwendungsfälle modellieren \item Use Case durch Interaktion verfeinern \begin{description*} @@ -617,287 +612,91 @@ \newpage \section{Grobentwurf} - \subsection{Einführung} - Systementwurf - Aufgabe \begin{itemize*} - \item Sicht des geplanten Systems von innen (Entwickler) - \item Wie sollen vereinbartes Verhalten und Funktionen (Analysemodell) intern realisiert werden? - \item Von Spezifikation von Anforderungen und Funktionen $\rightarrow$ Vorbereitung der Implementierung - \item Formal: Transformation des Analysemodells in ein Systementwurfsmodell - \item System(grob)entwurf, Feinentwurf/Objektentwurf + \item Entwurfsziele identifizieren + \item Grobe Systemstruktur festlegen (Architektur) + \item Zerlegung in Subsysteme, Spezifikation + \item Bewerten der Zerlegung anhand der Entwurfsziele + \item Schnittstellen festlegen \end{itemize*} - Teile und herrsche - \begin{itemize*} - \item Grobentwurf - \begin{itemize*} - \item Entwurfsziele identifizieren - \item Grobe Systemstruktur festlegen (Architektur) - \item Zerlegung in Subsysteme, Spezifikation - \begin{itemize*} - \item Schichten, Pakete, Komponenten - \end{itemize*} - \item Bewerten der Zerlegung anhand der Entwurfsziele - \item Schnittstellen festlegen - \end{itemize*} - \item Feinentwurf - \begin{itemize*} - \item Subsysteme im Detail entwerfen - \begin{itemize*} - \item Strukturierung der Komponenten - \item Klassen, Objekte, Funktionen, Datenstrukturen - \item Verhalten, Algorithmen - Teillösungen - \end{itemize*} - \end{itemize*} - \end{itemize*} - - \subsection{Systemzerlegung} - Vorgehen + Kopplung/Abhängigkeiten von Subsystemen \begin{itemize*} - \item Zerlegung eines Systems in Subsysteme - \item Betrachtung der Lösungsdomäne! - \item Subsysteme weiter zerlegen bis Komplexität ausreichend klein ist z.B. für Arbeitspakete + \item Möglichst lose Kopplung + \begin{itemize*} + \item Änderungen haben geringe Auswirkungen + \item Erleichtert Wartbarkeit und Arbeitsteilung + \end{itemize*} + \item Mittel zur Verringerung + \begin{itemize*} + \item Zusätzliche Unterteilung in Subsysteme + \item Aber: dann größere Komplexität! + \end{itemize*} + \item Kopplungsarten + \begin{description*} + \item[Daten] vermeiden oder zentralisieren + \item[Schnittstellen] gegenseitiges Aufrufen + \item[Struktur] gemeinsame Elemente vermeiden über Paketgrenzen + \end{description*} \end{itemize*} - Was macht ein Subsystem aus? + Kohäsion (cohesion) \begin{itemize*} - \item Schnittstellen, Funktionen, „Verantwortung“ - \item Was bietet es an? - \item Was benutzt es? - \item Was tut es intern? - \end{itemize*} - - Operation - \begin{itemize*} - \item Name und Parameter - \item Funktion, Prozedur, Methode, Eintrittspunkt ... - \end{itemize*} - - Dienst: Satz von Operationen, die bereitgestellt werden - - Abhängigkeiten von Subsystemen - \begin{itemize*} - \item Subsysteme untereinander: Kopplung (coupling) - \item Maß für die Abhängigkeit von Subsystemen - \end{itemize*} - - Möglichst lose Kopplung - \begin{itemize*} - \item Änderungen in einem beteiligten Subsystem haben geringe Auswirkungen (Stabilität) - \item Erleichtert Wartbarkeit und Arbeitsteilung - \end{itemize*} - - Mittel zur Verringerung der Kopplung - \begin{itemize*} - \item Zusätzliche Unterteilung in Subsysteme - \item Aber: dann größere Komplexität! - \end{itemize*} - - Abhängigkeiten von Subsystemen - %| Kopplungsart | Bemerkung | - %| -\item | -\item | - %| 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) | - - \begin{itemize*} - \item Elemente eines Subsystems: Kohäsion (cohesion) \item Maß für Zusammengehörigkeit der Elemente - \item Möglichst hohe Kohäsion - \begin{itemize*} - \item Enge Beziehung oder ähnliche Aufgaben der Elemente - \item Erleichtert Verständnis, Wartung und Anpassung - \end{itemize*} - \item Mittel zum Erreichen hoher Kohäsion - \begin{itemize*} - \item Datenkapselung, Objektorientierung - \item Benutzung geeigneter Patterns (Kapitel 5) - \end{itemize*} + \item hohe Kohäsion erleichtert Verständnis, Wartung und Anpassung + \item Mittel zum Erreichen hoher Kohäsion: Datenkapselung \end{itemize*} - - Metriken für modulare Entwürfe - \begin{itemize*} - \item Fan-in / fan-out-Metrik [S.Henry, D. Kafura 1981]: + \begin{description*} + \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*} - \item 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 - \item Fan-out: Anzahl von Stellen, an denen M andere Module aufruft + Anzahl der globalen Variablen, die von M verändert werden - \end{itemize*} \item Heuristik Kopplung / Kohäsion \begin{itemize*} - \item Hoher Fan-out bedeutet hohe Kopplung, minimieren + \item Hoher Fan-out bedeutet hohe Kopplung $\rightarrow$ minimieren \item Hoher Fan-in kann auf geringe Kohäsion von M hindeuten \end{itemize*} \end{itemize*} - 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 - \begin{itemize*} - \item „Erfahrung ist die härteste Lehrerin. Sie gibt Dir zuerst den Test und anschließend den Unterricht.“ [Ruth 1993] - \item „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] - \item „Das Leben von Software-Architekten besteht aus einer langen und schnellen Abfolge suboptimaler Entwurfs-entscheidungen, die teilweise im Dunkeln getroffen werden.“ [Kruchten2001] - \end{itemize*} - - Wie organisiert man Subsysteme? - \begin{itemize*} - \item Innerhalb einer Verfeinerungsstufe: fachlich orientierte Zerlegung - \item Mehrfache Zerlegung: Hierarchie-Graph der Verfeinerung - \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*} - - \begin{itemize*} - \item Geschlossene Schichtenarchitektur - \begin{itemize*} - \item Beispiel: OSI-Modell für Kommunikationssysteme - \end{itemize*} - \item Offene Schichtenarchitektur - \begin{itemize*} - \item Beispiel: Java Swing auf X11-Plattform - \end{itemize*} - \end{itemize*} Prinzipien des OO-Entwurfs \begin{itemize*} - \item So-einfach-wie-möglich-Prinzip (KISS) - \item Fehler berücksichtigen (Strukturierung, Kapselung, Modularisierung, Wiederverwendung) + \item Keep it simple stupid (KISS) \item Entwerfen nach Verantwortlichkeiten \item Hohe Kohäsion / Geringe Kopplung \item Zyklische Abhängigkeiten vermeiden \item Auf Schnittstellen konzentrieren \begin{itemize*} \item Abhängigkeiten nur von Schnittstellen - \item Abtrennung von Schnittstellen (eher viele kleine als eine große) - \item Umkehr der Abhängigkeiten (dependency inversion-Prinzip) + \item Abtrennung von Schnitts. (viele kleine statt wenig große) + \item Umkehr der Abhängigkeiten (dependency inversion) \end{itemize*} \item Offen / Geschlossen Prinzip \end{itemize*} - Zyklische Abhängigkeiten vermeiden - \begin{itemize*} - \item Änderungen wirken sich auf beide Komponenten aus - \item Probleme beim Löschen und Initialisieren - \item Auflösen durch - \begin{itemize*} - \item Gemeinsame Klassen in separates Paket - \item Gemeinsame Schnittstellen definieren - \end{itemize*} - \end{itemize*} - Symptome schlechten Designs \begin{itemize*} - \item Starrheit - \begin{itemize*} - \item Einfache Änderungen schwierig realisierbar - \item Einfache Änderungen führen zur Modifikation einer Vielzahl von Komponenten - \end{itemize*} - \item Zerbrechlichkeit - \begin{itemize*} - \item Änderungen an einer Stelle führen zu Fehlern an völlig anderer Stelle - \end{itemize*} + \item Starrheit (Änderungen schwer machbar) + \item Zerbrechlichkeit (Änderungen werfen Fehler) \item Schlechte Wiederverwendbarkeit - \begin{itemize*} - \item Komponenten können Aufgrund spezieller Anhängigkeiten kaum wiederverwendet werden - \end{itemize*} \end{itemize*} Wann ist ein Entwurf „gut“? \begin{itemize*} - \item Korrekt - \begin{itemize*} - \item Erfüllung der Anforderungen - \item Wiedergabe aller Funktionen des Systemmodells - \item Sicherstellung der nichtfunktionalen Anforderungen - \end{itemize*} + \item Korrekt (Anforderungen erfüllen) \item Verständlich und präzise, gut dokumentiert \item Anpassbar \item Hohe Kohäsion innerhalb der Komponenten \item Schwache Kopplung zwischen den Komponenten \item Wiederverwendung - \item Kriterien gelten auf allen Ebenen des Entwurfs! (Architektur, Subsysteme, Komponenten) + \item Kriterien gelten auf allen Ebenen des Entwurfs! \end{itemize*} \subsection{Architekturmodelle} \begin{itemize*} - \item Modellierung mit UML - \begin{itemize*} - \item Bisher: logische Sicht - \item Technisch: Organisation in Paketen, Namensraum, Import - \end{itemize*} - \item Paketdiagramm - \begin{itemize*} - \item Gliederung (Strukturierung) des Systems in Teile - \item Zuordnung von Elementen zu einem Paket - \item Hierarchien und Abhängigkeiten zwischen den Paketen - \item Anwendung: Definition von Schichten - \end{itemize*} - \item Enthält-Beziehung - \begin{itemize*} - \item Definiert, in welchem Paket ein Element enthalten ist - \item Ermöglicht qualifizierten Zugriff auf enthaltene Elemente - \item Löschen des Pakets bewirkt Löschen beinhalteter Elemente - \item Definition von Sichtbarkeit / Zugriffsrechte - \begin{itemize*} - \item Auswirkung auf weitere Enthält-Beziehung - \item '+' - public (default) - \item '-' - private - \end{itemize*} - \end{itemize*} - \item Paket- / Element-Import - \begin{itemize*} - \item Unqualifizierter Zugriff auf Elemente eines anderen Namensraums (Paketes) - \end{itemize*} - \item Komponentendiagramm - \begin{itemize*} - \item Komponente - modulare, austauschbare Einheit - \item Strukturierung des Systems durch Komponenten - \item Modellierung der - \begin{itemize*} - \item Abhängigkeiten zwischen Komponenten - \item inneren Struktur von Komponenten - \end{itemize*} - \item Definition von Schnittstellen - \item Verwendung von Elementen aus Klassen- und Objektdiagramm - \item Stärkere dynamische Sicht $\rightarrow$ kein Verhalten - \item Komponente <> - \begin{itemize*} - \item Kapselt Funktionalitäten (Physisch gruppierte Klassen) - \item „Spezialisierte“ Klasse (Vererbung, Exemplare möglich) - \item Stellt Funktionalitäten über Schnittstellen bereit - \item Definiert benötigte Schnittstellen - \item Enthält Klassen oder weitere Komponenten - \item Modulares Element: Substitution (Austauschbarkeit) steht im Vordergrund - \end{itemize*} - \item Black-Box-Darstellung - \begin{itemize*} - \item Zur Verfügung gestellte Funktionalität `<>` - \item Benötigte Funktionalität `<>`‚ - \end{itemize*} - \item White-Box-Darstellung - \begin{itemize*} - \item Interner Aufbau der Komponente `<>` - \item Artefakte `<>`‚ Realisierende physische Einheit (z.B.: .dll) - \end{itemize*} - \end{itemize*} - \end{itemize*} - - Schnittstellen / Interfaces - \begin{itemize*} - \item Definition Diagrammunabhängig - \begin{itemize*} - \item Meist Klassendiagramm - \end{itemize*} - \item Ähnlich Semantik einer Klasse - \begin{itemize*} - \item Nur public-Attribute und Operationen - \end{itemize*} + \item Definition Diagrammunabhängig: Meist Klassendiagramm + \item Ähnlich Semantik einer Klasse: Nur public-Attribute und Operationen \item Definiert Verpflichtung zur Implementierung von \begin{itemize*} \item Operationen @@ -905,89 +704,27 @@ \item Verpflichtungen (z.B.: Vor- / Nachbedingungen) \end{itemize*} \item Meist abstrakte Klassen mit abstrakten Operationen - \item Abstrakt - muss überschrieben werden - \item Notation - \begin{itemize*} - \item Stereotyp: <> - \item Meist kursiv geschrieben, da abstrakte Klasse - \end{itemize*} - \end{itemize*} - - Schnittstellenrealisierung, Implementierungsbeziehung - \begin{itemize*} + \item Klasse realisiert alle Attribute und Operationen \item Schnittstellen werden realisiert, nicht instanziiert - \item Schnittstellenkonform - \begin{itemize*} - \item Klasse realisiert alle Attribute und Operationen - \end{itemize*} \item Schnittstelle kann von anderen Schnittstellen erben \item Keine Schnittstellenrealisierung zwischen zwei Interface-Klassen $\rightarrow$ Generalisierung verwenden - \item Darstellung - \begin{itemize*} - \item Gestrichelte Linie mit nicht gefülltem Dreieck an der Seite der Superklasse - \item Alternativ: Lollipop-Darstellung - \end{itemize*} - \end{itemize*} - - - \subsection{Softwarearchitekturmuster} - \begin{itemize*} \item Wiederverwendung auf sehr hoher Abstraktionsstufe - \item Falls geplante Anwendung passt, anwenden! \end{itemize*} Schichten-Architektur (layers) \begin{itemize*} - \item Problem - \begin{itemize*} - \item Komplexität: Strukturierung des Systems, unterschiedliche Abstraktionsebenen - \item Änderungen sollen möglichst lokal bleiben - \item Teilsysteme sollen austauschbar, wiederverwendbar und getrennt entwickelbar sein - \item Schnittstellen sollen stabil sein - \end{itemize*} - \item Lösung - \begin{itemize*} - \item Zuordnung von Subsystemen zu horizontalen Schichten gleicher Abstraktionsebene - \item Komponenten einer Schicht bieten Dienste der darüber liegenden Schicht an - \end{itemize*} + \item Zuordnung von Subsystemen zu horizontalen Schichten gleicher Abstraktionsebene + \item Komponenten einer Schicht bieten Dienste der darüber liegenden Schicht an \end{itemize*} - Client-Server (Klient/Anbieter) + Client-Server (Klient/Anbieter) Two-tier \begin{itemize*} - \item Client (front-end) - \begin{itemize*} - \item Benutzungsschnittstelle - \item Einbindung in Geschäftsprozesse - \item Entkoppelt von Netztechnologie und Datenhaltung - \end{itemize*} - \item Server (back-end) - \begin{itemize*} - \item Datenhaltung, evtl. Fachlogik - \end{itemize*} - \item Genauer: Two-tier client/server architecture + \item Client (front-end): Benutzungsschnittstelle + \item Server (back-end): Datenhaltung, evtl. Fachlogik \item Asynchroner Kontrollfluss \item Aufteilung Funktionen Client / Server - \begin{itemize*} - \item Mehr Funktionen im Server: - \begin{itemize*} - \item zentrale Verwaltung, Wartungsaufwand geringer, Portabilität, einfache Client-Hardware (Net PC) - \item „Thin Client“ - nur GUI - \end{itemize*} - \item Mehr Funktionen im Client: Flaschenhals Server wird entlastet, individuellere Client-Funktionen - \begin{itemize*} - \item „Fat Client“ - Teil der Anwendung im Client - \end{itemize*} - \item Entscheidet mit über Umsetzung (Java Script, ...) - \end{itemize*} - \end{itemize*} - - Three-Tier / Four-Tier Architecture: Client/Server mit weiterer Aufteilung ähnlich Repository - - Bewertung Client-Server - \begin{itemize*} \item Vorteile \begin{itemize*} - \item Leicht verständlich \item Änderungen bleiben lokal \item Geringere Kopplung zwischen den Schichten \item Schichten austauschbar und wiederverwendbar @@ -998,26 +735,21 @@ \begin{itemize*} \item Geringere Performance \item Zusätzlicher Verwaltungs- oder Datenoverhead - \item Manche Änderungen führen zu Änderungen in allen Schichten (z.B. neues Datenfeld) + \item Manche Änderungen führen zu Änderungen in allen Schichten \end{itemize*} \end{itemize*} Pipes and Filters \begin{itemize*} \item Datenstrom- oder Kontrollflussorientiertes System - \item Lose verbundene Berechnungskomponenten \item Kombination der Berechnungskomponenten nur vom Typ der Ein- und Ausgabedaten abhängig - \item Leicht erweiterbar System gewünscht - \item Parallele Verarbeitung vorteilhaft - \item Verwendung von globalen Steuerungskontrollstrukturen (Parallelisierung, Verzweigung, Schleifen) gewünscht + \item Verwendung von globalen Steuerungskontrollstrukturen \item Vorteile \begin{itemize*} - \item Stark entkoppelte Komponenten \item Hohe Flexibilität gegenüber Änderungen \& Erweiterungen \item Hoher Wiederverwendungsgrad der Komponenten \item Unabhängige Entwicklung der Komponenten \item Leichte Parallelisierung der Berechnungen möglich - \item Überprüfung der Datenkompatibilität dynamisch / statisch \end{itemize*} \item Nachteile \begin{itemize*} @@ -1027,21 +759,12 @@ \end{itemize*} \end{itemize*} - Plug-In Architektur (Microkernel) \begin{itemize*} - \item Zielstellung - \begin{itemize*} - \item Stabile, verbreitete Standard-Anwendung (Kern) - \item Funktionalität soll durch Komponenten leicht erweiterbar sein - \item Dritte sollen Komponenten leicht erstellen können - \end{itemize*} - \item Lösung - \begin{itemize*} - \item Möglichst schlanker zentraler Kern - \item Plugin-Manager verwaltet Komponenten: Laden, Entladen, Zugriffskontrolle, Konfiguration - \end{itemize*} - \item Plugin + \item Stabile, schlanker verbreitete Standard-Anwendung (Kern) + \item Funktionalität durch Komponenten leicht erweiterbar sein + \item Dritte sollen Komponenten leicht erstellen können + \item Plugin-Manager verwaltet Komponenten: Laden, Entladen \begin{itemize*} \item Komponente mit Standard-Schnittstelle \item Erweitert Funktionalität (extension point) @@ -1052,7 +775,6 @@ \item Trennung der Zuständigkeiten \item Erweiterbar, Austauschbar, Wiederverwendbar \item Geringe Kopplung zu den Komponenten - \item Anpassung an eigene Bedürfnisse möglich \item Leichte Aufteilung der Entwicklung der Arbeitspakete \end{itemize*} \item Nachteile @@ -1061,199 +783,51 @@ \item Verwaltungsoverhead zur Laufzeit \item Versionsverwaltung der Komponenten nötig \item Abhängigkeiten unter den Komponenten schwierig realisierbar - \item Geschickte Definition der Extension Points nötig \end{itemize*} \end{itemize*} - Repository (Depot, blackboard) - \begin{itemize*} - \item Zentrale Datenhaltung - \begin{itemize*} - \item Datenbankmanagementsystem, Dateisystem - \end{itemize*} - \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*} - Model-View-Controller (MVC) \begin{itemize*} - \item Modell / Sicht / Steuerung - \item Trennung verschiedener Aufgabengebiete: - \begin{itemize*} - \item Model: verwaltet Domänenwissen, Daten und Zustand; häufig Datenbank - \item View: Darstellung, Anzeige, GUI - \item Controller: Steuerung der Interaktion, Nutzerbefehle - \end{itemize*} \item Erlauben Austausch von Anzeige- und Speichersystem - \item Kontrollfluss - \begin{itemize*} - \item Controller steuert - \item View wird über Datenänderungen benachrichtigt (callback) - \end{itemize*} + \begin{description*} + \item[Model] verwaltet Domänenwissen, Daten und Zustand; Datenbank + \item[View] Darstellung, Anzeige, GUI + \item[Controller] Steuerung der Interaktion, Nutzerbefehle + \end{description*} \item Geeignet für interaktive Systeme - \item Problem - \begin{itemize*} - \item Lose Kopplung zwischen verschiedenen Komponenten - \item Daten werden in verschiedenen Sichten dargestellt - \item Realisierung von GUI‘s - \end{itemize*} - \item Lösung durch drei Komponenten - \begin{itemize*} - \item Daten (Model) enthält die Kernfunktionalität / Durchführung der Geschäftsprozesse, kapselt und Speichert die Daten - \item Sichten bzw. Dialoge (View) stellt die Daten für den Anwender in unterschiedlicher Art dar - \item 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 - \end{itemize*} - \item Vorteile - \begin{itemize*} - \item Unabhängige Entwicklung der Komponenten - \item Änderung der Oberfläche ohne Änderung des Modells - \item Unterschiedliche Oberflächen für das selbe Modell - \end{itemize*} - \item Nachteile - \begin{itemize*} - \item Performance - \item Erhöhter initialer Entwicklungsaufwand - \end{itemize*} + \item Daten enthält Kernfunktionalität, kapselt und speichert Daten + \item Sichten stellt die Daten in unterschiedlicher Art dar + \item Steuerung realisiert die Interaktion mit dem Benutzer, übernimmt die Eingaben vom View und ändert die Daten im Modell \end{itemize*} - \subsection{Frameworks} - Was ist ein Framework? \begin{itemize*} - \item A framework is a set of prefabricated software building blocks that programmers can use, extend, or customize for specific computing solutions [Taligent] - \item Ein framework (Rahmenwerk, Anwendungsgerüst) ist eine Menge von zusammengehörigen Klassen, die einen abstrakten Entwurf für eine Problemfamilie darstellen [nach Pomberger/Blaschek] - \end{itemize*} - - Ziele - \begin{itemize*} - \item Wiederverwendung von Code, Architektur, Entwurfsprinzipien und Verhaltensschema + \item Menge von zusammengehörigen Klassen, für eine Problemfamilie + \item Wiederverwendung von Code, Architektur, Entwurfsprinzipien \item Ähnliche Benutzungsschnittstelle - \end{itemize*} - - Klassifikation I - \begin{itemize*} - \item Anwendungs-Framework (application framework) + \item Klassifikation I \begin{itemize*} - \item Gibt Systemarchitektur für typische Anwendungsstruktur vor - \item GUI-Framework: Motif, Qt, Swing, ... - \end{itemize*} - \item Bereichsspezifisches Framework (domain framework) - \begin{itemize*} - \item Expertenwissen für Anwendungsbereich - \item für typische Anwendungen u.a. in den Bereichen Luftfahrt, Produktion, Finanzwesen, Automotive, ... - \item Beispiel: AUTOSAR - \end{itemize*} - \item Infrastrukturgerüst (support framework) - \begin{itemize*} - \item Gerätetreiber, Anpassung an Hardware - \item Middleware: DCOM, Java RMI, CORBA, WebSphere, ... - \end{itemize*} - \end{itemize*} - - Klassifikation II - \begin{itemize*} - \item Offene Programmgerüste (white box) - \begin{itemize*} - \item Erweiterbarkeit durch Vererbung und dynamische Bindung - \item Funktionen konkretisieren durch Ableitung von Basisklassen des Programmgerüsts und Überschreiben vordefinierter Methoden - \end{itemize*} - \item Geschlossene Programmgerüste (black box) - \begin{itemize*} - \item Erweiterbarkeit durch Definition von Schnittstellen für Module, die für eine konkrete Anwendung in das Gerüst eingesetzt werden können - \item Wiederverwendung durch Komponenten, die sich an Schnittstellen halten; Aufruf über Delegation - \end{itemize*} - \end{itemize*} - - - Webframeworks - Angular JS - \begin{itemize*} - \item Clientseitiges Webframework von Google - \item Frei verwendbar (Open Source) - \item Erstellung von Single-Page-Webanwendungen - \item Model View Prinzip - \end{itemize*} - - \begin{itemize*} - \item Vorteile - \begin{itemize*} - \item Weitergabe von Expertenwissen - \item Durchdachtes Design: langfristige Aufwandsersparnis - \item Wartungsaufwand reduziert, systematische Tests möglich - \item Prinzipiell sehr hohe Produktivität möglich - \item Erleichtert Integration und Konsistenz verwandter Anforderungen - \end{itemize*} - \item Nachteile - \begin{itemize*} - \item Erstellung und Einarbeitung aufwändig - \item Zusätzlicher Dokumentations- und Wartungsaufwand - \item Fehlersuche erschwert durch Overhead des Frameworks - \item Kombination verschiedener Frameworks sehr schwierig + \item Anwendungs-Framework (application framework) + \item Bereichsspezifisches Framework (domain framework) + \item Infrastrukturgerüst (support framework) \end{itemize*} + \item Klassifikation II + \begin{description*} + \item[Offene Programmgerüste] (white box) Erweiterbarkeit durch Vererbung und dynamische Bindung + \item[Geschlossene Programmgerüste] (black box) Erweiterbarkeit durch Definition von Schnittstellen für Module + \end{description*} + \item Webframeworks \end{itemize*} \subsection{Systemarchitektur und Verteilung} - Systemarchitektur \begin{itemize*} \item Aufbau und Elemente der Ablaufumgebung, Hardware \item Häufig enger Zusammenhang mit Softwarearchitektur - \begin{itemize*} - \item Architekturmuster - \item Ablaufmuster - \end{itemize*} \item Besonders bei eingebetteten Systemen \item Systemarchitektur hat Einfluss auf Softwarearchitektur - \begin{itemize*} - \item Grenzobjekte, Schnittstellen, ... - \end{itemize*} - \item Gute Systemarchitektur? - \begin{itemize*} - \item Nichtfunktionale Anforderungen - \item Modellierung und Simulation, Lastmessungen - \end{itemize*} - \end{itemize*} - - Typische Strukturen - \begin{itemize*} - \item Zentralrechner (mainframe) mit Terminals - \item Server und einfache Stationen - \item PCs und Server - \item Kommunikationsverbindungen, Sensoren, Speicher, ... - \end{itemize*} - - - \begin{itemize*} - \item Blockdiagramm - \begin{itemize*} - \item Klassisches Beschreibungsmittel für Systemaufbau - \item Nicht Teil von UML - \end{itemize*} - \item Konfigurationsdiagramm - \begin{itemize*} - \item meistverbreitetes Hilfsmittel zur Beschreibung der physikalischen Verteilung von System-Komponenten - \item Nicht Teil von UML - \end{itemize*} - \item Verteilungsdiagramm (UML deployment diagram) - \begin{itemize*} - \item Darstellung der Hardwaretopologie - \item Zuordnung von Artefakten zu Hardwareeinheiten (Knoten) - \begin{itemize*} - \item Verteilung von Systembestandteilen auf Hardware - \end{itemize*} - \item Kommunikationsverbindung und Abhängigkeiten zwischen Knoten - \item Relativ spät im Projekt Installation / Wartung des Systems - \end{itemize*} \end{itemize*} \subsection{Globaler Kontrollfluss} - Globaler Kontrollfluss \begin{itemize*} \item Ablaufsicht der Architektur \begin{itemize*} @@ -1261,15 +835,13 @@ \item Steuerung der Abfolge von Einzelfunktionen \item Synchronisation und Koordination \item Reaktion auf externe Ereignisse - \item Darstellung z.B. durch Sequenzdiagramme \end{itemize*} \item Nebenläufigkeit auf Architekturebene \begin{itemize*} \item Threads , Prozesse, verteiltes System \item Asynchroner Nachrichtenaustausch \end{itemize*} - \item Einfluss auf Architektur / abhängig von Architektur! - \item Ablaufmuster + \item Einfluss auf Architektur / abhängig von Architektur \begin{itemize*} \item Zentral \begin{itemize*} @@ -1281,35 +853,14 @@ \item Ereignisgesteuert (event-driven) \item interrupts \item publish-subscribe (ähnlich observer) - \item (selective) broadcast \item Datenflussgesteuert (data flow architecture) \end{itemize*} \end{itemize*} \end{itemize*} - \subsection{Sonstiges} - Ablauf des OO-Systementwurfs [B. Oesterreich] + \subsection{Weitere Aufgaben beim Grobentwurf} \begin{itemize*} - \item Schichtenmodell definieren - \item Verteilungsmodell definieren - \item Fachliches Subsystemmodell definieren - \item Ablaufverantwortlichkeiten definieren - \item Komponentenspezifisches Klassenmodell entwickeln - \item Komponentenschnittstelle entwerfen - \item Zustandsmodelle weiterentwickeln - \item Objektfluss modellieren - \item Interaktionsmodelle entwickeln, Attribute definieren - \item Dialoge spezifizieren - \item Design-Diskurs - \item Testgetriebene Entwicklung - \end{itemize*} - - Weitere Aufgaben beim Grobentwurf - \begin{itemize*} - \item Entwurf einer persistenten Datenverwaltung - \begin{itemize*} - \item Dateisystem, Datenbank - \end{itemize*} + \item Entwurf einer persistenten Datenverwaltung (Datenbank) \item Sicherheit \begin{itemize*} \item Zugriffskontrolle @@ -1317,43 +868,43 @@ \item Protokollfunktionen \end{itemize*} \item Kontrollfluss - \begin{itemize*} - \item Ausnahmen - \item Starten, Initialisieren und Beenden der Anwendung - \item „Randanwendungsfälle“ - \end{itemize*} - \end{itemize*} - - Notwendigkeit der Architekturdokumentation + \item Dokumentation \begin{itemize*} - \item Quellcode aufgrund niedrigen Abstraktionsniveaus ungünstig für Dokumentation - \item Überblick und Arbeitsteilung - \item Lebensdauer von Systemen länger als geplant - \item Fehler und Probleme leichter finden und beseitigen - \item Neue Anforderungen mit angemessenem Aufwand erfüllen - \item Vereinfachung der Wartung, Pflege, Erweiterung, Wiederverwendung + \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*} + +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*} + +Peer-to-peer +\begin{itemize*} + \item Gleichberechtigte Partner, Föderation + \item Verteilte kommunizierende Subsysteme + \item Orts- und Umgebungsunabhängigkeit +\end{itemize*} - \subsection{Dokumentation} - \begin{itemize*} - \item Grundprinzipien - \begin{itemize*} - \item Verständlich aus Sicht des Lesers formulieren (Glossar) - \item Das Warum beschreiben (Entwurfsentscheidungen) - \item Annahmen, Voraussetzungen, Randbedingungen dokumentieren - \item Wiederholungen vermeiden - \item Notation erklären oder Standards verwenden (UML) - \begin{itemize*} - \item Legende hinzufügen - \end{itemize*} - \item Auf Zweckdienlichkeit prüfen, Reviews durchführen (Inhalt, Qualität) - \item Verschiedene Sichten für verschiedene Zielgruppen - \end{itemize*} - \end{itemize*} \newpage \section{Feinentwurf} - %| Analyse-Modell | Entwurfs-Modell | %| -\item | -\item | %| Fachliche Domäne | Lösungsdomäne |