Grobentwurf hydrated
This commit is contained in:
parent
67c58c762c
commit
560e6aa01c
Binary file not shown.
@ -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 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}
|
||||
|
||||
@ -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
|
||||
\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
|
||||
\end{itemize*}
|
||||
|
||||
Was macht ein Subsystem aus?
|
||||
\item Möglichst lose Kopplung
|
||||
\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 Änderungen haben geringe Auswirkungen
|
||||
\item Erleichtert Wartbarkeit und Arbeitsteilung
|
||||
\end{itemize*}
|
||||
|
||||
Mittel zur Verringerung der Kopplung
|
||||
\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*}
|
||||
|
||||
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) |
|
||||
|
||||
Kohäsion (cohesion)
|
||||
\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
|
||||
\item hohe Kohäsion erleichtert Verständnis, Wartung und Anpassung
|
||||
\item Mittel zum Erreichen hoher Kohäsion: Datenkapselung
|
||||
\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*}
|
||||
\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
|
||||
\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 <<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 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: <<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
|
||||
\end{itemize*}
|
||||
\item Schnittstellen werden realisiert, nicht instanziiert
|
||||
\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*}
|
||||
\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 Stabile, schlanker verbreitete Standard-Anwendung (Kern)
|
||||
\item Funktionalität 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 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
|
||||
\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*}
|
||||
\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}
|
||||
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
|
||||
\item Klassifikation I
|
||||
\begin{itemize*}
|
||||
\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)
|
||||
\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
|
||||
\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
|
||||
\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
|
||||
\item Dokumentation
|
||||
\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 Annahmen, Voraussetzungen, Randbedingungen
|
||||
\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 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*}
|
||||
|
||||
|
||||
\newpage
|
||||
\section{Feinentwurf}
|
||||
|
||||
%| Analyse-Modell | Entwurfs-Modell |
|
||||
%| -\item | -\item |
|
||||
%| Fachliche Domäne | Lösungsdomäne |
|
||||
|
||||
Loading…
Reference in New Issue
Block a user