wieerwill/Informatik
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Grobentwurf hydrated

Browse Source
This commit is contained in:
WieErWill 2021-03-15 20:25:36 +01:00
parent 67c58c762c
commit 560e6aa01c
2 changed files with 184 additions and 633 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

BIN
Softwaretechnik - Cheatsheet.pdf
View File

Binary file not shown.

725
Softwaretechnik - Cheatsheet.tex
View File

@ -185,48 +185,17 @@
\end{itemize*} \end{itemize*}
\subsection{Klassische Modelle} \subsection{Klassische Modelle}
\begin{itemize*} \begin{description*}
\item Funktionen \item[Funktionen] Funktionsbaum, Blockschaltbild
\begin{itemize*} \item[Daten] Data Dictionary, Entity Relationship Diagram
\item Funktionsbaum \item[Systemumgebung] Datenflussdiagramm
\item Blockschaltbild \item[Algorithmen] Entscheidungstabelle, Pseudocode, Programmablaufplan
\end{itemize*} \item[Dynamisches Verhalten] diskrete Zustände und atomare zustandübergänge; Zustandsautomat, Flow-Chart
\item Daten \item[Objektorientierte Modelle] Klassendiagramme, UML
\begin{itemize*} \item[Struktur] Klassen-, Objekt-, Komponenten-, Kompositions-Strukturdiagramm
\item Data Dictionary (Daten mit Strukturinformationen) \item[Verhalten] Use-Case-, Aktivitäts- und Zustandsdiagramms
\item Entity Relationship Diagram \item[Interaktion] Sequenz-, Kommunikations-, Timing-Diagramm
\end{itemize*} \end{description*}
\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*}
\paragraph{Use-Case-Diagramm} \paragraph{Use-Case-Diagramm}
\begin{itemize*} \begin{itemize*}
@ -259,6 +228,12 @@
\item Bildung von Hierarchien (Enthält-Beziehung) \item Bildung von Hierarchien (Enthält-Beziehung)
\item Abhängigkeiten zwischen den Paketen \item Abhängigkeiten zwischen den Paketen
\item Zum Grobentwurf von Systemen \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*} \end{itemize*}
\paragraph{Komponentendiagramm} \paragraph{Komponentendiagramm}
@ -268,6 +243,16 @@
\item Modellierung der Abhängigkeiten zwischen Komponenten \item Modellierung der Abhängigkeiten zwischen Komponenten
\item Modellierung der inneren Struktur von Komponenten \item Modellierung der inneren Struktur von Komponenten
\item Definition von Schnittstellen \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*} \end{itemize*}
\paragraph{Kompositionsstrukturdiagramm} \paragraph{Kompositionsstrukturdiagramm}
@ -284,11 +269,7 @@
\item Geschäftsprozessmodellierung möglich \item Geschäftsprozessmodellierung möglich
\item Abstrakte und detaillierte Verhaltensbeschreibung möglich \item Abstrakte und detaillierte Verhaltensbeschreibung möglich
\item Grundlage zur Codegenerierung \item Grundlage zur Codegenerierung
\item Zur Verfeinerung von \item Zur Verfeinerung von Use-Cases
\begin{itemize*}
\item Use-Cases
\item Operationen / Interaktionen
\end{itemize*}
\end{itemize*} \end{itemize*}
\paragraph{Interaktionsdiagramme} \paragraph{Interaktionsdiagramme}
@ -315,16 +296,15 @@
\item Weitere Elemente des Sequenzdiagramms \item Weitere Elemente des Sequenzdiagramms
\begin{itemize*} \begin{itemize*}
\item Nachrichten ohne Sender z.B. am Beginn einer Interaktion \item Nachrichten ohne Sender z.B. am Beginn einer Interaktion
\item Verlorene Nachrichten (ohne Empfänger) z. B. am Ende einer Interaktion \item Verlorene Nachrichten (ohne Empfänger)
\item Erzeugen von Lebenslinien \item Erzeugen/Zerstören von Lebenslinien
\item Zerstören von Lebenslinien
\end{itemize*} \end{itemize*}
\end{itemize*} \end{itemize*}
\paragraph{Kommunikationsdiagramm} \paragraph{Kommunikationsdiagramm}
\begin{itemize*} \begin{itemize*}
\item Kommunikationsbeziehungen der Kommunikationspartner stehen im Vordergrund \item Kommunikationsbeziehungen der Kommunikationspartner stehen
\item Welche Komponenten arbeiten wie zusammen, um eine Funktion zu erfüllen \item Welche Komponenten arbeiten zusammen $\rightarrow$ Funktion erfüllen
\end{itemize*} \end{itemize*}
\paragraph{Timing-Diagramm} \paragraph{Timing-Diagramm}
@ -334,7 +314,6 @@
\item Modellierung einzelner Interaktion \item Modellierung einzelner Interaktion
\item Zeitlicher Verlauf senkrecht \item Zeitlicher Verlauf senkrecht
\item Kommunikationspartner waagerecht (unsortiert) \item Kommunikationspartner waagerecht (unsortiert)
\item Ereignisspezifikation
\item Trace: Folge von Sende- und Empfangsereignissen \item Trace: Folge von Sende- und Empfangsereignissen
\end{itemize*} \end{itemize*}
@ -347,14 +326,30 @@
\item Ereignisse, die Zustandswechsel auslösen \item Ereignisse, die Zustandswechsel auslösen
\end{itemize*} \end{itemize*}
\item Modellierung von endlichen Automaten (Zustandsmaschinen) \item Modellierung von endlichen Automaten (Zustandsmaschinen)
\begin{itemize*} \item Modellierung von verteilten Systemen/parallelem Verhalten
\item Deterministische
\item Nichtdeterministische
\end{itemize*}
\item Modellierung von verteilten Systemen / parallelem Verhalten
\item Grundlage zur Codegenerierung \item Grundlage zur Codegenerierung
\end{itemize*} \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 \newpage
\section{Analyse} \section{Analyse}
@ -617,287 +612,91 @@
\newpage \newpage
\section{Grobentwurf} \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
\end{itemize*}
Teile und herrsche
\begin{itemize*}
\item Grobentwurf
\begin{itemize*} \begin{itemize*}
\item Entwurfsziele identifizieren \item Entwurfsziele identifizieren
\item Grobe Systemstruktur festlegen (Architektur) \item Grobe Systemstruktur festlegen (Architektur)
\item Zerlegung in Subsysteme, Spezifikation \item Zerlegung in Subsysteme, Spezifikation
\begin{itemize*}
\item Schichten, Pakete, Komponenten
\end{itemize*}
\item Bewerten der Zerlegung anhand der Entwurfsziele \item Bewerten der Zerlegung anhand der Entwurfsziele
\item Schnittstellen festlegen \item Schnittstellen festlegen
\end{itemize*} \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} \subsection{Systemzerlegung}
Vorgehen Kopplung/Abhängigkeiten von Subsystemen
\begin{itemize*} \begin{itemize*}
\item Zerlegung eines Systems in Subsysteme \item Möglichst lose Kopplung
\item Betrachtung der Lösungsdomäne!
\item Subsysteme weiter zerlegen bis Komplexität ausreichend klein ist z.B. für Arbeitspakete
\end{itemize*}
Was macht ein Subsystem aus?
\begin{itemize*} \begin{itemize*}
\item Schnittstellen, Funktionen, „Verantwortung“ \item Änderungen haben geringe Auswirkungen
\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 \item Erleichtert Wartbarkeit und Arbeitsteilung
\end{itemize*} \end{itemize*}
\item Mittel zur Verringerung
Mittel zur Verringerung der Kopplung
\begin{itemize*} \begin{itemize*}
\item Zusätzliche Unterteilung in Subsysteme \item Zusätzliche Unterteilung in Subsysteme
\item Aber: dann größere Komplexität! \item Aber: dann größere Komplexität!
\end{itemize*} \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*}
Abhängigkeiten von Subsystemen Kohäsion (cohesion)
%| 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*} \begin{itemize*}
\item Elemente eines Subsystems: Kohäsion (cohesion)
\item Maß für Zusammengehörigkeit der Elemente \item Maß für Zusammengehörigkeit der Elemente
\item Möglichst hohe Kohäsion \item hohe Kohäsion erleichtert Verständnis, Wartung und Anpassung
\begin{itemize*} \item Mittel zum Erreichen hoher Kohäsion: Datenkapselung
\item Enge Beziehung oder ähnliche Aufgaben der Elemente
\item Erleichtert Verständnis, Wartung und Anpassung
\end{itemize*} \end{itemize*}
\item Mittel zum Erreichen hoher Kohäsion \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*} \begin{itemize*}
\item Datenkapselung, Objektorientierung
\item Benutzung geeigneter Patterns (Kapitel 5)
\end{itemize*}
\end{itemize*}
Metriken für modulare Entwürfe
\begin{itemize*}
\item Fan-in / fan-out-Metrik [S.Henry, D. Kafura 1981]:
\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 \item Heuristik Kopplung / Kohäsion
\begin{itemize*} \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 \item Hoher Fan-in kann auf geringe Kohäsion von M hindeuten
\end{itemize*} \end{itemize*}
\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 Prinzipien des OO-Entwurfs
\begin{itemize*} \begin{itemize*}
\item So-einfach-wie-möglich-Prinzip (KISS) \item Keep it simple stupid (KISS)
\item Fehler berücksichtigen (Strukturierung, Kapselung, Modularisierung, Wiederverwendung)
\item Entwerfen nach Verantwortlichkeiten \item Entwerfen nach Verantwortlichkeiten
\item Hohe Kohäsion / Geringe Kopplung \item Hohe Kohäsion / Geringe Kopplung
\item Zyklische Abhängigkeiten vermeiden \item Zyklische Abhängigkeiten vermeiden
\item Auf Schnittstellen konzentrieren \item Auf Schnittstellen konzentrieren
\begin{itemize*} \begin{itemize*}
\item Abhängigkeiten nur von Schnittstellen \item Abhängigkeiten nur von Schnittstellen
\item Abtrennung von Schnittstellen (eher viele kleine als eine große) \item Abtrennung von Schnitts. (viele kleine statt wenig große)
\item Umkehr der Abhängigkeiten (dependency inversion-Prinzip) \item Umkehr der Abhängigkeiten (dependency inversion)
\end{itemize*} \end{itemize*}
\item Offen / Geschlossen Prinzip \item Offen / Geschlossen Prinzip
\end{itemize*} \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 Symptome schlechten Designs
\begin{itemize*} \begin{itemize*}
\item Starrheit \item Starrheit (Änderungen schwer machbar)
\begin{itemize*} \item Zerbrechlichkeit (Änderungen werfen Fehler)
\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 Schlechte Wiederverwendbarkeit \item Schlechte Wiederverwendbarkeit
\begin{itemize*}
\item Komponenten können Aufgrund spezieller Anhängigkeiten kaum wiederverwendet werden
\end{itemize*}
\end{itemize*} \end{itemize*}
Wann ist ein Entwurf „gut“? Wann ist ein Entwurf „gut“?
\begin{itemize*} \begin{itemize*}
\item Korrekt \item Korrekt (Anforderungen erfüllen)
\begin{itemize*}
\item Erfüllung der Anforderungen
\item Wiedergabe aller Funktionen des Systemmodells
\item Sicherstellung der nichtfunktionalen Anforderungen
\end{itemize*}
\item Verständlich und präzise, gut dokumentiert \item Verständlich und präzise, gut dokumentiert
\item Anpassbar \item Anpassbar
\item Hohe Kohäsion innerhalb der Komponenten \item Hohe Kohäsion innerhalb der Komponenten
\item Schwache Kopplung zwischen den Komponenten \item Schwache Kopplung zwischen den Komponenten
\item Wiederverwendung \item Wiederverwendung
\item Kriterien gelten auf allen Ebenen des Entwurfs! (Architektur, Subsysteme, Komponenten) \item Kriterien gelten auf allen Ebenen des Entwurfs!
\end{itemize*} \end{itemize*}
\subsection{Architekturmodelle} \subsection{Architekturmodelle}
\begin{itemize*} \begin{itemize*}
\item Modellierung mit UML \item Definition Diagrammunabhängig: Meist Klassendiagramm
\begin{itemize*} \item Ähnlich Semantik einer Klasse: Nur public-Attribute und Operationen
\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 <<component>>
\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 `<<provided interfaces>>`
\item Benötigte Funktionalität `<<required interfaces>>`‚
\end{itemize*}
\item White-Box-Darstellung
\begin{itemize*}
\item Interner Aufbau der Komponente `<<realization>>`
\item Artefakte `<<artifacts>>`‚ 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 Definiert Verpflichtung zur Implementierung von \item Definiert Verpflichtung zur Implementierung von
\begin{itemize*} \begin{itemize*}
\item Operationen \item Operationen
@ -905,89 +704,27 @@
\item Verpflichtungen (z.B.: Vor- / Nachbedingungen) \item Verpflichtungen (z.B.: Vor- / Nachbedingungen)
\end{itemize*} \end{itemize*}
\item Meist abstrakte Klassen mit abstrakten Operationen \item Meist abstrakte Klassen mit abstrakten Operationen
\item Abstrakt - muss überschrieben werden
\item Notation
\begin{itemize*}
\item Stereotyp: <<Interface>>
\item Meist kursiv geschrieben, da abstrakte Klasse
\end{itemize*}
\end{itemize*}
Schnittstellenrealisierung, Implementierungsbeziehung
\begin{itemize*}
\item Schnittstellen werden realisiert, nicht instanziiert
\item Schnittstellenkonform
\begin{itemize*}
\item Klasse realisiert alle Attribute und Operationen \item Klasse realisiert alle Attribute und Operationen
\end{itemize*} \item Schnittstellen werden realisiert, nicht instanziiert
\item Schnittstelle kann von anderen Schnittstellen erben \item Schnittstelle kann von anderen Schnittstellen erben
\item Keine Schnittstellenrealisierung zwischen zwei Interface-Klassen $\rightarrow$ Generalisierung verwenden \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 Wiederverwendung auf sehr hoher Abstraktionsstufe
\item Falls geplante Anwendung passt, anwenden!
\end{itemize*} \end{itemize*}
Schichten-Architektur (layers) 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*} \begin{itemize*}
\item Zuordnung von Subsystemen zu horizontalen Schichten gleicher Abstraktionsebene \item Zuordnung von Subsystemen zu horizontalen Schichten gleicher Abstraktionsebene
\item Komponenten einer Schicht bieten Dienste der darüber liegenden Schicht an \item Komponenten einer Schicht bieten Dienste der darüber liegenden Schicht an
\end{itemize*} \end{itemize*}
\end{itemize*}
Client-Server (Klient/Anbieter) Client-Server (Klient/Anbieter) Two-tier
\begin{itemize*} \begin{itemize*}
\item Client (front-end) \item Client (front-end): Benutzungsschnittstelle
\begin{itemize*} \item Server (back-end): Datenhaltung, evtl. Fachlogik
\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 Asynchroner Kontrollfluss \item Asynchroner Kontrollfluss
\item Aufteilung Funktionen Client / Server \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 \item Vorteile
\begin{itemize*} \begin{itemize*}
\item Leicht verständlich
\item Änderungen bleiben lokal \item Änderungen bleiben lokal
\item Geringere Kopplung zwischen den Schichten \item Geringere Kopplung zwischen den Schichten
\item Schichten austauschbar und wiederverwendbar \item Schichten austauschbar und wiederverwendbar
@ -998,26 +735,21 @@
\begin{itemize*} \begin{itemize*}
\item Geringere Performance \item Geringere Performance
\item Zusätzlicher Verwaltungs- oder Datenoverhead \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*}
\end{itemize*} \end{itemize*}
Pipes and Filters Pipes and Filters
\begin{itemize*} \begin{itemize*}
\item Datenstrom- oder Kontrollflussorientiertes System \item Datenstrom- oder Kontrollflussorientiertes System
\item Lose verbundene Berechnungskomponenten
\item Kombination der Berechnungskomponenten nur vom Typ der Ein- und Ausgabedaten abhängig \item Kombination der Berechnungskomponenten nur vom Typ der Ein- und Ausgabedaten abhängig
\item Leicht erweiterbar System gewünscht \item Verwendung von globalen Steuerungskontrollstrukturen
\item Parallele Verarbeitung vorteilhaft
\item Verwendung von globalen Steuerungskontrollstrukturen (Parallelisierung, Verzweigung, Schleifen) gewünscht
\item Vorteile \item Vorteile
\begin{itemize*} \begin{itemize*}
\item Stark entkoppelte Komponenten
\item Hohe Flexibilität gegenüber Änderungen \& Erweiterungen \item Hohe Flexibilität gegenüber Änderungen \& Erweiterungen
\item Hoher Wiederverwendungsgrad der Komponenten \item Hoher Wiederverwendungsgrad der Komponenten
\item Unabhängige Entwicklung der Komponenten \item Unabhängige Entwicklung der Komponenten
\item Leichte Parallelisierung der Berechnungen möglich \item Leichte Parallelisierung der Berechnungen möglich
\item Überprüfung der Datenkompatibilität dynamisch / statisch
\end{itemize*} \end{itemize*}
\item Nachteile \item Nachteile
\begin{itemize*} \begin{itemize*}
@ -1027,21 +759,12 @@
\end{itemize*} \end{itemize*}
\end{itemize*} \end{itemize*}
Plug-In Architektur (Microkernel) Plug-In Architektur (Microkernel)
\begin{itemize*} \begin{itemize*}
\item Zielstellung \item Stabile, schlanker verbreitete Standard-Anwendung (Kern)
\begin{itemize*} \item Funktionalität durch Komponenten leicht erweiterbar sein
\item Stabile, verbreitete Standard-Anwendung (Kern)
\item Funktionalität soll durch Komponenten leicht erweiterbar sein
\item Dritte sollen Komponenten leicht erstellen können \item Dritte sollen Komponenten leicht erstellen können
\end{itemize*} \item Plugin-Manager verwaltet Komponenten: Laden, Entladen
\item Lösung
\begin{itemize*}
\item Möglichst schlanker zentraler Kern
\item Plugin-Manager verwaltet Komponenten: Laden, Entladen, Zugriffskontrolle, Konfiguration
\end{itemize*}
\item Plugin
\begin{itemize*} \begin{itemize*}
\item Komponente mit Standard-Schnittstelle \item Komponente mit Standard-Schnittstelle
\item Erweitert Funktionalität (extension point) \item Erweitert Funktionalität (extension point)
@ -1052,7 +775,6 @@
\item Trennung der Zuständigkeiten \item Trennung der Zuständigkeiten
\item Erweiterbar, Austauschbar, Wiederverwendbar \item Erweiterbar, Austauschbar, Wiederverwendbar
\item Geringe Kopplung zu den Komponenten \item Geringe Kopplung zu den Komponenten
\item Anpassung an eigene Bedürfnisse möglich
\item Leichte Aufteilung der Entwicklung der Arbeitspakete \item Leichte Aufteilung der Entwicklung der Arbeitspakete
\end{itemize*} \end{itemize*}
\item Nachteile \item Nachteile
@ -1061,199 +783,51 @@
\item Verwaltungsoverhead zur Laufzeit \item Verwaltungsoverhead zur Laufzeit
\item Versionsverwaltung der Komponenten nötig \item Versionsverwaltung der Komponenten nötig
\item Abhängigkeiten unter den Komponenten schwierig realisierbar \item Abhängigkeiten unter den Komponenten schwierig realisierbar
\item Geschickte Definition der Extension Points nötig
\end{itemize*} \end{itemize*}
\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) Model-View-Controller (MVC)
\begin{itemize*} \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 Erlauben Austausch von Anzeige- und Speichersystem
\item Kontrollfluss \begin{description*}
\begin{itemize*} \item[Model] verwaltet Domänenwissen, Daten und Zustand; Datenbank
\item Controller steuert \item[View] Darstellung, Anzeige, GUI
\item View wird über Datenänderungen benachrichtigt (callback) \item[Controller] Steuerung der Interaktion, Nutzerbefehle
\end{itemize*} \end{description*}
\item Geeignet für interaktive Systeme \item Geeignet für interaktive Systeme
\item Problem \item Daten enthält Kernfunktionalität, kapselt und speichert Daten
\begin{itemize*} \item Sichten stellt die Daten in unterschiedlicher Art dar
\item Lose Kopplung zwischen verschiedenen Komponenten \item Steuerung realisiert die Interaktion mit dem Benutzer, übernimmt die Eingaben vom View und ändert die Daten im Modell
\item Daten werden in verschiedenen Sichten dargestellt
\item Realisierung von GUI‘s
\end{itemize*} \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*}
\end{itemize*}
\subsection{Frameworks} \subsection{Frameworks}
Was ist ein Framework?
\begin{itemize*} \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 Menge von zusammengehörigen Klassen, für eine Problemfamilie
\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] \item Wiederverwendung von Code, Architektur, Entwurfsprinzipien
\end{itemize*}
Ziele
\begin{itemize*}
\item Wiederverwendung von Code, Architektur, Entwurfsprinzipien und Verhaltensschema
\item Ähnliche Benutzungsschnittstelle \item Ähnliche Benutzungsschnittstelle
\end{itemize*} \item Klassifikation I
Klassifikation I
\begin{itemize*} \begin{itemize*}
\item Anwendungs-Framework (application framework) \item Anwendungs-Framework (application framework)
\begin{itemize*}
\item Gibt Systemarchitektur für typische Anwendungsstruktur vor
\item GUI-Framework: Motif, Qt, Swing, ...
\end{itemize*}
\item Bereichsspezifisches Framework (domain framework) \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) \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
\end{itemize*} \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*} \end{itemize*}
\subsection{Systemarchitektur und Verteilung} \subsection{Systemarchitektur und Verteilung}
Systemarchitektur
\begin{itemize*} \begin{itemize*}
\item Aufbau und Elemente der Ablaufumgebung, Hardware \item Aufbau und Elemente der Ablaufumgebung, Hardware
\item Häufig enger Zusammenhang mit Softwarearchitektur \item Häufig enger Zusammenhang mit Softwarearchitektur
\begin{itemize*}
\item Architekturmuster
\item Ablaufmuster
\end{itemize*}
\item Besonders bei eingebetteten Systemen \item Besonders bei eingebetteten Systemen
\item Systemarchitektur hat Einfluss auf Softwarearchitektur \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*} \end{itemize*}
\subsection{Globaler Kontrollfluss} \subsection{Globaler Kontrollfluss}
Globaler Kontrollfluss
\begin{itemize*} \begin{itemize*}
\item Ablaufsicht der Architektur \item Ablaufsicht der Architektur
\begin{itemize*} \begin{itemize*}
@ -1261,15 +835,13 @@
\item Steuerung der Abfolge von Einzelfunktionen \item Steuerung der Abfolge von Einzelfunktionen
\item Synchronisation und Koordination \item Synchronisation und Koordination
\item Reaktion auf externe Ereignisse \item Reaktion auf externe Ereignisse
\item Darstellung z.B. durch Sequenzdiagramme
\end{itemize*} \end{itemize*}
\item Nebenläufigkeit auf Architekturebene \item Nebenläufigkeit auf Architekturebene
\begin{itemize*} \begin{itemize*}
\item Threads , Prozesse, verteiltes System \item Threads , Prozesse, verteiltes System
\item Asynchroner Nachrichtenaustausch \item Asynchroner Nachrichtenaustausch
\end{itemize*} \end{itemize*}
\item Einfluss auf Architektur / abhängig von Architektur! \item Einfluss auf Architektur / abhängig von Architektur
\item Ablaufmuster
\begin{itemize*} \begin{itemize*}
\item Zentral \item Zentral
\begin{itemize*} \begin{itemize*}
@ -1281,35 +853,14 @@
\item Ereignisgesteuert (event-driven) \item Ereignisgesteuert (event-driven)
\item interrupts \item interrupts
\item publish-subscribe (ähnlich observer) \item publish-subscribe (ähnlich observer)
\item (selective) broadcast
\item Datenflussgesteuert (data flow architecture) \item Datenflussgesteuert (data flow architecture)
\end{itemize*} \end{itemize*}
\end{itemize*} \end{itemize*}
\end{itemize*} \end{itemize*}
\subsection{Sonstiges} \subsection{Weitere Aufgaben beim Grobentwurf}
Ablauf des OO-Systementwurfs [B. Oesterreich]
\begin{itemize*} \begin{itemize*}
\item Schichtenmodell definieren \item Entwurf einer persistenten Datenverwaltung (Datenbank)
\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 Sicherheit \item Sicherheit
\begin{itemize*} \begin{itemize*}
\item Zugriffskontrolle \item Zugriffskontrolle
@ -1317,43 +868,43 @@
\item Protokollfunktionen \item Protokollfunktionen
\end{itemize*} \end{itemize*}
\item Kontrollfluss \item Kontrollfluss
\begin{itemize*} \item Dokumentation
\item Ausnahmen
\item Starten, Initialisieren und Beenden der Anwendung
\item „Randanwendungsfälle“
\end{itemize*}
\end{itemize*}
Notwendigkeit der Architekturdokumentation
\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
\end{itemize*}
\subsection{Dokumentation}
\begin{itemize*}
\item Grundprinzipien
\begin{itemize*} \begin{itemize*}
\item Verständlich aus Sicht des Lesers formulieren (Glossar) \item Verständlich aus Sicht des Lesers formulieren (Glossar)
\item Das Warum beschreiben (Entwurfsentscheidungen) \item Das Warum beschreiben (Entwurfsentscheidungen)
\item Annahmen, Voraussetzungen, Randbedingungen dokumentieren \item Annahmen, Voraussetzungen, Randbedingungen
\item Wiederholungen vermeiden
\item Notation erklären oder Standards verwenden (UML) \item Notation erklären oder Standards verwenden (UML)
\begin{itemize*} \item Auf Zweckdienlichkeit prüfen, Reviews durchführen
\item Legende hinzufügen
\end{itemize*}
\item Auf Zweckdienlichkeit prüfen, Reviews durchführen (Inhalt, Qualität)
\item Verschiedene Sichten für verschiedene Zielgruppen \item Verschiedene Sichten für verschiedene Zielgruppen
\end{itemize*} \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*}
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*}
\newpage \newpage
\section{Feinentwurf} \section{Feinentwurf}
%| Analyse-Modell | Entwurfs-Modell | %| Analyse-Modell | Entwurfs-Modell |
%| -\item | -\item | %| -\item | -\item |
%| Fachliche Domäne | Lösungsdomäne | %| Fachliche Domäne | Lösungsdomäne |