neue MindMap und Seminar
This commit is contained in:
parent
99d5547051
commit
de942db3fa
10
README.md
10
README.md
@ -23,7 +23,9 @@ Unterlagen zu Informatik Vorlesungen der TU Ilmenau
|
||||
- [Praktikum A1](Rechnerarchitekturen%201%20-%20Praktikum%20A1.pdf)
|
||||
- [Praktikum A2](Rechnerarchitekturen%201%20-%20Praktikum%20A2.pdf)
|
||||
- [Rechnerarchitekturen 2](Rechnerarchitekturen%202.md) (ongoing)
|
||||
- [Softwaretechnik](Softwaretechnik%201.md) (ongoing)
|
||||
- [Softwaretechnik](Softwaretechnik.md) (ongoing)
|
||||
- [MindMap](Softwaretechnik%20-%20MindMap.pdf) (ongoing)
|
||||
- [Seminar](Softwaretechnik%20-%20Seminar.pdf) (ongoing)
|
||||
- [Stochastik](Stochastik.md) (ongoing)
|
||||
- [Telematik 1](Telematik%201.md)
|
||||
- [Telematik Cheatsheet](Telematik1-cheatsheet.pdf)
|
||||
@ -41,9 +43,9 @@ Wir freuen uns über jeden der mitmacht.
|
||||
Eine kleine Beschreibung für Leute die noch nie auf Github zusammengearbeitet haben. Vorraussetzung für diese Aktionen ist es, ein Github-Konto zu besitzen.
|
||||
- Erstelle ein 'issue'. Gehe davor die offene 'issues' durch (oder überlege dir welches Fach/Seminar noch fehlt)
|
||||
- Klone das Repository oder erstelle einen Fork. Über die Kommandozeile: ```git clone https://github.com/wieerwill/Informatik.git```
|
||||
- Erstelle deinen eigenen Feature Branch, damit deine Version nicht mit anderen kollidiert: ```git checkout -b my-new-feature``` (in "" kannst du frei wählen wie du deinen Branch nennst)
|
||||
- Nachdem du Änderungen vorgenommen hast, stelle deine Änderungen bereit: ```git add * && git commit -m "dein Kommentar"``` (in "" kommt dein Kommentar was sich geändert hat bzw woran du gearbeitet hast. Nicht der Dateiname!)
|
||||
- Lade die Änderung auf deinen Branch hoch: ```git push origin my-new-feature```
|
||||
- Erstelle deinen eigenen Feature Branch, damit deine Version nicht mit anderen kollidiert: ```git checkout -b <my-new-feature>``` (in <> kannst du frei wählen wie du deinen Branch nennst)
|
||||
- Nachdem du Änderungen vorgenommen hast, stelle deine Änderungen bereit: ```git add * && git commit -m <dein Kommentar>``` (in <> kommt dein Kommentar was sich geändert hat bzw woran du gearbeitet hast. Nicht der Dateiname!)
|
||||
- Lade die Änderung auf deinen Branch hoch: ```git push origin <my-new-feature>```
|
||||
- Erstelle ein 'pull request' damit deine Änderungen in diesem Repository übernommen werden können. Dies kannst du über dein Github Dashboard machen.
|
||||
|
||||
## Bild- und Textrechte
|
||||
|
||||
BIN
Softwaretechnik - MindMap.pdf
Normal file
BIN
Softwaretechnik - MindMap.pdf
Normal file
Binary file not shown.
402
Softwaretechnik - MindMap.tex
Normal file
402
Softwaretechnik - MindMap.tex
Normal file
@ -0,0 +1,402 @@
|
||||
\documentclass{article}
|
||||
\usepackage[utf8]{inputenc}
|
||||
\usepackage{tikz}
|
||||
\usetikzlibrary{mindmap}
|
||||
|
||||
\pagestyle{empty}
|
||||
\begin{document}
|
||||
|
||||
\begin{tikzpicture}[mindmap, grow cyclic, every node/.style=concept, concept color=orange!40,
|
||||
level 1/.append style={level distance=5cm,sibling angle=120},
|
||||
level 2/.append style={level distance=3cm,sibling angle=45}]
|
||||
|
||||
\node{Modell}
|
||||
child { node {Beschreibung eines Ausschnitts der Realität}}
|
||||
child { node {Modelle}
|
||||
child { node {Analysemodell}}
|
||||
child { node {Entwurfsmodell}}
|
||||
child { node {Implementierung (-smodell)}}
|
||||
child { node {Vorgehensmodell}}
|
||||
child { node {Produktmodell}}
|
||||
child { node {Dokumentation, Alternativen-Auswahl}}
|
||||
}
|
||||
child { node {für}
|
||||
child { node {Sichten}}
|
||||
child { node {Funktionen}}
|
||||
child { node {Daten}}
|
||||
child { node {Algorithmen}}
|
||||
child { node {Systemumgebung}}
|
||||
child { node {Dynamisches Verhalten}}
|
||||
child { node {Objektorientierte Modelle}}
|
||||
};
|
||||
\end{tikzpicture}
|
||||
|
||||
|
||||
\begin{tikzpicture}[mindmap, grow cyclic, every node/.style=concept, concept color=orange!40,
|
||||
level 1/.append style={level distance=5cm,sibling angle=72},
|
||||
level 2/.append style={level distance=3cm,sibling angle=45}]
|
||||
|
||||
\node{Klassische Modelle}
|
||||
child [concept color=blue!30]{ node {Funktionen}
|
||||
child { node {Funktionsbaum}
|
||||
child { node {Hierarchische Dekomosition der Fkt}}
|
||||
child { node {nummerieren der Ebenen/Funktionen möglich}}
|
||||
child { node {Bsp: Abonnement Verwaltung}}
|
||||
}
|
||||
child { node {Blockschaltbild}
|
||||
child { node {eingebettetes System, HW/SW}}
|
||||
}
|
||||
}
|
||||
child { node {Daten}
|
||||
child { node {Data Dictionary}
|
||||
child { node {Verzeichnis von Daten mit Strukturinformationen}}
|
||||
child { node {Backus-Naur-Form, kontextfreie Grammatik}}
|
||||
}
|
||||
child { node {Entity Relationship Diagram}
|
||||
child { node {Daten und ihre Beziehungen}}
|
||||
}
|
||||
}
|
||||
child { node {Systemumgebung}
|
||||
child { node {Datenflussdiagramm}
|
||||
child { node {Fluss und Transformation von Daten zwischen Funktionen, Speichern und Schnittstellen}}
|
||||
child { node {kein Kontrollfluss}}
|
||||
}
|
||||
}
|
||||
child { node {Algorithmen}
|
||||
child { node {Entscheidungstabelle}
|
||||
child { node {Regelbasierte Beschreibung}}
|
||||
child { node {Bedingung}}
|
||||
child { node {Aktionen}}
|
||||
child { node {Reduktionsregeln}}
|
||||
}
|
||||
child { node {Pseudocode}
|
||||
child { node {von Programmiersprache abstrahierende, detaillierte Beschreibung eines Algorithmus}}
|
||||
}
|
||||
child { node {Programmablaufplan}
|
||||
child { node {Grafische Beschreibung des Kontrollflusses}}
|
||||
child { node {DIN 66001}}
|
||||
child { node {Unstrukturiert}}
|
||||
}
|
||||
child { node {Struktogramm}
|
||||
child { node {Nassi-Shneidermann-Diagramm}}
|
||||
child { node {keine Sprünge}}
|
||||
}
|
||||
}
|
||||
child { node {Dynamisches Verhalten}
|
||||
child { node {diskrete Zustände und atomare Zustandübergänge}}
|
||||
child { node {Zustandsautomat}
|
||||
child { node {Verhalten mit Zuständen und -übergängen}}
|
||||
child { node {Automatenmodelle und -theorie}}
|
||||
child { node {Ggf zerlegung oder kommunizierende Automaten}}
|
||||
}
|
||||
child { node {Flow-Chart}}
|
||||
child { node {Ereignisgesteuerte Prozesskette (EPK)}
|
||||
child { node {Geschäftsprozesse}}
|
||||
child { node {BPM}}
|
||||
}
|
||||
child { node {Petri-Netz (ggf. mit Zeitmodell)}
|
||||
child { node {Grafische Beschreibung von Nebenläufigkeit und Synchronisation}}
|
||||
}
|
||||
}
|
||||
child { node {Objektorientierte Modelle}
|
||||
child { node {Klassendiagramme}}
|
||||
child { node {UML}}
|
||||
};
|
||||
\end{tikzpicture}
|
||||
|
||||
\begin{tikzpicture}[mindmap, grow cyclic, every node/.style=concept, concept color=orange!40,
|
||||
level 1/.append style={level distance=5cm,sibling angle=90},
|
||||
level 2/.append style={level distance=3cm,sibling angle=45}]
|
||||
|
||||
\node{Objektorientierung}
|
||||
child { node {Grundprinzip: Teile und Herrsche}}
|
||||
child { node {ein System besteht aus vielen Objekten}}
|
||||
child { node {ein Objekt hat}
|
||||
child { node {definiertes Verhalten}}
|
||||
child { node {inneren Zustand}}
|
||||
child { node {eindeutige Identität}}
|
||||
}
|
||||
child { node {Klasse}
|
||||
child { node {Gleichartige Objekte mit ggf. verschiedenen Zuständen}}
|
||||
child { node {Verhaltensschema – Operationen}}
|
||||
child { node {Innere Struktur – Attribute}}
|
||||
}
|
||||
child { node {Vorteile}
|
||||
child { node {Zuständigkeitsbereiche}
|
||||
child { node {Daten, Operationen und Zustand: lokal und gekapselt}}
|
||||
}
|
||||
child { node {Klare Schnittstellen}
|
||||
child { node {Definiertes Objektverhalten, Nachrichten}}
|
||||
}
|
||||
child { node {Hierarchie}
|
||||
child { node {Vererbung und Polymorphie (Spezialisierung), Klassenschachtelung}}
|
||||
}
|
||||
child { node {Baukastenprinzip}
|
||||
child { node {Benutzung vorgefertigter Klassenbibliotheken}}
|
||||
child { node {Anpassung durch Spezialisierung (mittels Vererbung)}}
|
||||
}
|
||||
};
|
||||
\end{tikzpicture}
|
||||
|
||||
\begin{tikzpicture}[mindmap, grow cyclic, every node/.style=concept, concept color=orange!40,
|
||||
level 1/.append style={level distance=5cm,sibling angle=90},
|
||||
level 2/.append style={level distance=3cm,sibling angle=45}]
|
||||
|
||||
\node{UML (Unified Modeling Language)}
|
||||
child { node {Use-Case-Diagramm}
|
||||
child { node {Beschreiben Systemfunktion aus Benutzersicht (Was, nicht Wie)}}
|
||||
child { node {Erste Anforderungsspezifikation (requirements)}}
|
||||
child { node {Planbare Einheiten als Inkremente für die Entwicklung}}
|
||||
child { node {Keine Modellierung eines Ablaufs!}}
|
||||
child { node {Erstellen von Testfällen (test case generation)}}
|
||||
child { node {Grundelemente}
|
||||
child { node {Anwendungsfall: Use Case}}
|
||||
child { node {Beteiligte: Aktor}}
|
||||
}
|
||||
child { node {Verfeinerung mittels Use-Case-Realisierung notwendig}
|
||||
child { node {Textuelle Beschreibung}}
|
||||
child { node {Verhaltensdiagramme}}
|
||||
}
|
||||
}
|
||||
child { node {Klassendiagramm}
|
||||
child { node {Modellierung der Struktur (Aufbau) eines Systems}}
|
||||
child { node {Modellierung von statischen Aspekten}}
|
||||
child { node {Modellierung der Struktur von Daten}}
|
||||
child { node {Klasse im Mittelpunkt}
|
||||
child { node {Aufbau: Attribute, Operationen}}
|
||||
child { node {Beziehungen zueinander: Assoziationen, Vererbung}}
|
||||
}
|
||||
child { node {Verbreitetstes und bekanntestes Diagramm der UML}}
|
||||
}
|
||||
child { node {Objektdiagramm}
|
||||
child { node {Struktur des Systems zur Laufzeit zu einem Zeitpunkt}}
|
||||
child { node {Tatsächliche Zusammenhänge und Belegungen von Attributen von Objekten zu einem Zeitpunkt}}
|
||||
child { node {Eine detaillierte Sicht auf einen Aspekt}
|
||||
child { node {Keine vollständige Beschreibung (zu komplex)}}
|
||||
child { node {Für kompliziertere Abhängigkeiten (z.B. Rekursion)}}
|
||||
}
|
||||
child { node {Objektdiagramm für alle Arten von Exemplaren}
|
||||
child { node {z.B.: Klasse (Objekt), Komponente, Knoten, ...}}
|
||||
}
|
||||
child { node {Keine Exemplare von Operationen -> Ablauf -> Verhaltensdiagramme / Interaktionsdiagramme}}
|
||||
child { node {Kein Verlauf der Wertebelegung über die Zeit}}
|
||||
}
|
||||
child { node {Paketdiagramm}
|
||||
child { node {Gliederung (Strukturierung) des Systems in Teile (Pakete)}}
|
||||
child { node {Zuordnung von Elementen zu einem Paket}}
|
||||
child { node {Bildung von Hierarchien (Enthält-Beziehung)}}
|
||||
child { node {Abhängigkeiten zwischen den Paketen}
|
||||
child { node {"Include" von Quellcode-Dateien (<<import>>)}}
|
||||
}
|
||||
child { node {Anwendung:}
|
||||
child { node {Zum Grobentwurf von Systemen}}
|
||||
child { node {Definition von Schichten}}
|
||||
}
|
||||
}
|
||||
child { node {Komponentendiagramm}
|
||||
child { node {Strukturierung des Systems durch Komponenten}}
|
||||
child { node {Komponente: Modulare, austauschbare Einheit (Substitution)}}
|
||||
child { node {Modellierung der Abhängigkeiten zwischen Komponenten}}
|
||||
child { node {Modellierung der inneren Struktur von Komponenten}}
|
||||
child { node {Definition von Schnittstellen}}
|
||||
}
|
||||
child { node {Kompositionsstrukturdiagramm}
|
||||
child { node {Teile-Ganzes-Strukturen -> Kompositionsstruktur}}
|
||||
child { node {Strukturell statische Kompositionsstrukturen:}
|
||||
child { node {Kurzschreibweise bei vielen Kompositionen}}
|
||||
child { node {Modellierung des Aufbaus komplexer Systeme}}
|
||||
}
|
||||
child { node {Strukturell dynamische Kompositionsstrukturen:}
|
||||
child { node {Notwendige Strukturen zur Realisierung eines Verhaltens}}
|
||||
child { node {Definition von Rollen, zur Lösung wiederkehrender Probleme -> Modellierung von Mustern}}
|
||||
}
|
||||
child { node {Starke Verwandtschaft mit dem Klassendiagramm}}
|
||||
child { node {Spezialisierte Kompositionsbeziehung -> erweiterte Semantik}}
|
||||
}
|
||||
child { node {Aktivitätsdiagramm}
|
||||
child { node {Modellierung von}
|
||||
child { node {Kontrollflüssen}}
|
||||
child { node {Datenflüssen}}
|
||||
child { node {Parallelem Verhalten}}
|
||||
child { node {Verzweigungen, bedingten und gewichteten Abläufen}}
|
||||
}
|
||||
child { node {Geschäftsprozessmodellierung möglich}}
|
||||
child { node {Abstrakte und detaillierte Verhaltensbeschreibung möglich}}
|
||||
child { node {Grundlage zur Codegenerierung}}
|
||||
child { node {Zur Verfeinerung von}
|
||||
child { node {Use-Cases}}
|
||||
child { node {Operationen / Interaktionen}}
|
||||
child { node {anderen Aktionen und Aktivitäten}}
|
||||
}
|
||||
}
|
||||
child { node {Interaktionsdiagramme}
|
||||
child { node {Modellierung von}
|
||||
child { node {Kommunikation zwischen Kommunikationspartnern (Lebenslinie)}}
|
||||
child { node {Operationen (Modellierung eines Programms)}}
|
||||
child { node {Informationsaustausch / Nachrichten}}
|
||||
}
|
||||
child { node {Gemeinsames Grundkonzept der Interaktionsdiagramme}}
|
||||
child { node {Sehr detaillierte Diagramme}
|
||||
child { node {Meist nicht zur vollständigen Beschreibung eines Systems}}
|
||||
child { node {Betrachtung eines wichtigen Teilaspekts}}
|
||||
}
|
||||
child { node {Grundlage zur Codegenerierung}}
|
||||
}
|
||||
child { node {Sequenzdiagramm}
|
||||
child { node {Genaue zeitliche Abfolge von Nachrichten}}
|
||||
child { node {Umfangreichstes Interaktionsdiagramm}}
|
||||
child { node {Kontrollelemente möglich (Schleifen, Verzweigungen)}}
|
||||
child { node {Nachrichten ohne Sender}
|
||||
child { node {z.B. am Beginn einer Interaktion}}
|
||||
}
|
||||
child { node {Verlorene Nachrichten (ohne Empfänger)}
|
||||
child { node {Nachricht ohne dargestellten Empfänger}}
|
||||
child { node {z. B. am Ende einer Interaktion}}
|
||||
}
|
||||
child { node {Erzeugen von Lebenslinien}
|
||||
child { node {Gestrichelte Linie mit geöffnetem Pfeil}}
|
||||
child { node {Keine Rückgabenachricht}}
|
||||
child { node {Zeitliche Einrückung des Rechtecks}}
|
||||
}
|
||||
child { node {Zerstören von Lebenslinien}
|
||||
child { node {Durchgezogene Linie mit Dreieckende}}
|
||||
child { node {Kann Rückgabenachricht erzeugen}}
|
||||
}
|
||||
}
|
||||
child { node {Kommunikationsdiagramm}
|
||||
child { node {Kommunikationsbeziehungen der Kommunikationspartner stehen im Vordergrund}}
|
||||
child { node {Welche Komponenten arbeiten wie zusammen, um eine Funktion zu erfüllen}}
|
||||
}
|
||||
child { node {Timing-Diagramm}
|
||||
child { node {Genaue zeitliche Darstellung von Zustandsübergängen}}
|
||||
child { node {Kommunikation abhängiger Zustandsautomaten}}
|
||||
child { node {Modellierung einzelner Interaktion}}
|
||||
child { node {Zeitlicher Verlauf senkrecht}}
|
||||
child { node {Kommunikationspartner waagerecht (unsortiert)}}
|
||||
child { node {Lebenslinie}
|
||||
child { node {Rechteck mit gestrichelter senkrechter Linie}}
|
||||
child { node {Start, Ende und Dauer der Ausführung einer Operation}}
|
||||
child { node {Rekursive Aufrufe möglich}}
|
||||
}
|
||||
child { node {Ereignisspezifikation}
|
||||
child { node {Stelle des Sendens / Empfangens der Nachricht}}
|
||||
child { node {Definition der Reihenfolge des Auftretens}}
|
||||
child { node {Trace: Folge von Sende-und Empfangsereignissen}}
|
||||
}
|
||||
child { node {Nachrichten in Interaktionsdiagrammen}
|
||||
child { node {Ereignis des Sendens bzw. Empfangens von Nachrichten}}
|
||||
child { node {Typen:}
|
||||
child { node {Operationsaufruf (synchron / asynchron)}}
|
||||
child { node {Antwort Nachricht}}
|
||||
child { node {Signal (asynchron), Create-/ Delete Message}}
|
||||
}
|
||||
child { node {Operationsaufruf: Parameterliste muss kompatibel sein}}
|
||||
child { node {Nachrichtentypen}}
|
||||
}
|
||||
}
|
||||
child { node {Zustandsdiagramm}
|
||||
child { node {Modellierung des (vollständigen?) Verhaltens}
|
||||
child { node {Zustände von Klassen / Objekten / Komponenten}}
|
||||
child { node {Übergänge zwischen den Zuständen}}
|
||||
child { node {Ereignisse, die Zustandswechsel auslösen}}
|
||||
}
|
||||
child { node {Modellierung von endlichen Automaten (Zustandsmaschinen)}
|
||||
child { node {Deterministische}}
|
||||
child { node {Nichtdeterministische}}
|
||||
}
|
||||
child { node {Verfeinerung von Zuständen möglich}}
|
||||
child { node {Modellierung von verteilten Systemen / parallelem Verhalten}}
|
||||
child { node {Grundlage zur Codegenerierung}}
|
||||
};
|
||||
\end{tikzpicture}
|
||||
|
||||
\begin{tikzpicture}[mindmap, grow cyclic, every node/.style=concept, concept color=orange!40,
|
||||
level 1/.append style={level distance=5cm,sibling angle=90},
|
||||
level 2/.append style={level distance=3cm,sibling angle=45}]
|
||||
|
||||
\node{Analyse}
|
||||
child { node {Anforderungen}
|
||||
child { node {Funktional}
|
||||
child { node {Was leistet das System}}
|
||||
child { node {Welche Funktionen bietet es}}
|
||||
child { node {Wie interagiert es mit der Umgebung}}
|
||||
}
|
||||
child { node {Nicht-Funktional}
|
||||
child { node {qualitative oder quantitative Eigenschaften}}
|
||||
child { node {Hängen oft von Verhalten ab}}
|
||||
}
|
||||
child { node {Arten der Funktionalität (ISO 9126)}
|
||||
child { node {Functionality (Funktionalität)}
|
||||
child { node {Angemessen}}
|
||||
child { node {Genauigkeit}}
|
||||
child { node {Sicherheit}
|
||||
child { node {Vertraulichkeit}}
|
||||
child { node {Informationssicherheit}}
|
||||
child { node {Datenintegrität}}
|
||||
child { node {Verfügbarkeit}}
|
||||
}
|
||||
}
|
||||
child { node {Usability (Benutzbarkeit)}
|
||||
child { node {Verständlichkeit}}
|
||||
child { node {Erlernbarkeit}}
|
||||
child { node {Bedienbarkeit}}
|
||||
child { node {Attraktivität}}
|
||||
}
|
||||
child { node {Reliability (Zuverlässigkeit)}
|
||||
child { node {Reife (Fehler-Anzahl)}}
|
||||
child { node {Fehlertoleranz}}
|
||||
child { node {Wiederherstellbarkeit}}
|
||||
}
|
||||
child { node {Performance (Effizienz)}
|
||||
child { node {Zeitverhalten}}
|
||||
child { node {Verbrauchsverhalten}}
|
||||
child { node {Wirtschaftlichkeit}}
|
||||
}
|
||||
child { node {Portability (Übertragbarkeit)}
|
||||
child { node {Anpassbarkeit}}
|
||||
child { node {Installierbarkeit}}
|
||||
child { node {Koexistenz}}
|
||||
child { node {Austauschbarkeit}}
|
||||
}
|
||||
child { node {Supportability (Änderbarkeit/ Wartbarkeit)}
|
||||
child { node {Analysierbarkeit}}
|
||||
child { node {Änder-und Erweiterbarkeit}}
|
||||
child { node {Stabilität (bei Änderungen)}}
|
||||
child { node {Testbarkeit}}
|
||||
}
|
||||
child { node {Weitere}
|
||||
child { node {Konformität zu Konventionen und Bestimmungen}}
|
||||
child { node {Interoperabilität zu anderen Systemen}}
|
||||
child { node {Implementierungsanforderungen}}
|
||||
child { node {Schnittstellenanforderungen}}
|
||||
child { node {Skalierbarkeit (Änderungen des Problemumfangs)}}
|
||||
child { node {Betriebliche und rechtliche Rahmenbedingungen}}
|
||||
child { node {Liefer-und Verpackungsanforderungen}}
|
||||
}
|
||||
}
|
||||
}
|
||||
child { node {Randbedingungen}
|
||||
child { node {Werden nicht umgesetzt}}
|
||||
child { node {Schränken Lösungsraum ein}}
|
||||
child { node {Beispiele:}
|
||||
child { node {Kosten}}
|
||||
child { node {Durchlaufzeit: Time to Market}}
|
||||
child { node {Vorgaben durch Marketing und Vertrieb}}
|
||||
child { node {Technische Randbedingungen (nichtfunktionale Anforderung)}}
|
||||
}
|
||||
}
|
||||
child { node {Geforderte (Meta-)Eigenschaften}
|
||||
child { node {Vollständig}}
|
||||
child { node {Konsistent}}
|
||||
child { node {Eindeutig}}
|
||||
child { node {Korrekt}}
|
||||
child { node {Realistisch}}
|
||||
child { node {Überprüfbar}}
|
||||
child { node {Rückverfolgbar}}
|
||||
child { node {Klassifizierbar (Risiko, Priorität, Dringlichkeit, Nutzen ...)}}
|
||||
child { node {Validierung mit dem Kunden}}
|
||||
}
|
||||
;
|
||||
\end{tikzpicture}
|
||||
|
||||
\end{document}
|
||||
BIN
Softwaretechnik - Seminar.pdf
Normal file
BIN
Softwaretechnik - Seminar.pdf
Normal file
Binary file not shown.
142
Softwaretechnik - Seminar.tex
Normal file
142
Softwaretechnik - Seminar.tex
Normal file
@ -0,0 +1,142 @@
|
||||
\documentclass{article}
|
||||
\usepackage[utf8]{inputenc}
|
||||
\usepackage[ngerman]{babel}
|
||||
\usepackage{datetime}
|
||||
\usepackage[]{amsmath}
|
||||
\usepackage[]{amsthm}
|
||||
\usepackage[]{amssymb}
|
||||
\usepackage{tikz}
|
||||
\usetikzlibrary{trees}
|
||||
|
||||
\title{Softwaretechnik - Seminar}
|
||||
\begin{document}
|
||||
|
||||
\section{Werkzeuge der Softwareentwicklung}
|
||||
\subsection{Aufgabe 1}
|
||||
\textit{In der Softwaretechnik gibt es eine große Menge an Programmen und Systemen, die bei der Entwicklung eines Softwareprojekts verwendet werden.}\\
|
||||
\textit{In welche Kategorien können die Werkzeuge unterteilt werden? Nennen Sie jeweils ein Beispiel. Welchen Zweck verfolgen Werkzeuge der einzelnen Kategorien?}\\
|
||||
\begin{description}
|
||||
\item[Analyse] Lastenheft
|
||||
\item[Modellierung/Entwurf] UML, Diagramme
|
||||
\item[Implementierung/Programmierung] IDE, VSCode,
|
||||
\item[Fehler tracken] BugZilla
|
||||
\item[Versionsverwaltung] Git, GitLab
|
||||
\end{description}
|
||||
|
||||
\subsection{Aufgabe 2}
|
||||
\textit{Machen Sie sich mit den Möglichkeiten zur Planung von Softwareprojekten am Beispiel von Github vertraut.}\\
|
||||
\textit{(a) Welche Instrumente der Projektplanung bietet die Plattform Github und was sind deren wichtigste Funktionen und Eigenschaften?}\\
|
||||
\begin{description}
|
||||
\item[Code Viewer] schnelle Einsicht in alle Teile des Codes
|
||||
\item[Issues] Bug-Tracking/Sammlung und offene Lösungsfindung
|
||||
\item[Pull Requests] Code von anderen einfach implemenieren
|
||||
\item[Actions] Automation von wiederholenden Aktionen bei bestimmten Events (z.B. Merge/Pull)
|
||||
\item[Tasks] Aufgaben sammeln, erledigen und überblicken
|
||||
\item[Notifications] Nachrichtenaustausch und Repository Informationen
|
||||
\end{description}
|
||||
\noindent\textit{(b) Welche Personengruppen können am Prozess der Projektplanung beteiligt sein?}\\
|
||||
Programmierer, DevOps, Redakteur, Prüfer, Konfigurationsmanager, Architekt, Analytiker, u.U. Kunden und/oder Endbenutzer
|
||||
|
||||
\subsection{Aufgabe 3}
|
||||
\textit{Versionierung ist ein zentrales Element bei der konsistenten Gruppenarbeit an Projekten.}\\
|
||||
\textit{(a) Welche Funktionen bietet eine Versionsverwaltung und welche Vorteile ergeben sich für die Entwicklung?}\\
|
||||
\begin{itemize}
|
||||
\item Protokolliert Änderungen an einer oder mehreren Dateien über Zeit hinweg
|
||||
\item Dateien oder Projekte auf bestimmten Zeitpunkt zurücksetzten
|
||||
\item Nachverfolgen der Aktivität und Qualität von beteiligten Personen
|
||||
\item Problemfindung
|
||||
\end{itemize}
|
||||
|
||||
\textit{(b) Was bedeuten die folgenden Begriffe im Kontext der Versionsverwaltung der Git-Software?}\\
|
||||
\begin{description}
|
||||
\item[Branch] unterteilung der Entwicklung in mehrere Zweige/Pfade
|
||||
\item[Checkout] Wechseln zu einem existierenden Zweig/Branch
|
||||
\item[Pull-Request \& Merge] Vereinigen neuer und alter Commits
|
||||
\item[Tags] wichtige Punkte in Historie markieren, z.B. Releases
|
||||
\end{description}
|
||||
|
||||
\textit{(c) Wie sollte die Versionierung während der Entwicklung verwendet werden?}\\
|
||||
Sehr viel Committen; jede Abteilung/Leitung ein eigener Branch; Merge nur durch DevOp/Architekt;
|
||||
|
||||
\subsection{Aufgabe 4}
|
||||
\textit{Welche Funktionen bringt eine Entwicklungsumgebung (IDE) mit und wie integrieren sie sich in den Entwicklungsprozess?}
|
||||
\begin{itemize}
|
||||
\item Anbindung an Versionsverwaltung
|
||||
\item Debugger und Fehlerfindung
|
||||
\item Formatierung (prettify/beautify)
|
||||
\item Automatisierung
|
||||
\item Verwaltung verschiedener Projekte
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Aufgabe 5}
|
||||
\textit{Dokumentation ist ein Teil des kompletten Entwicklungsprozesses.}\\
|
||||
\textit{(a) Nennen Sie verschiedene Arten der Dokumentation. Welche Programme oder Hilfsmittel können dabei verwendet werden?}\\
|
||||
\begin{description}
|
||||
\item[Lastenheft]
|
||||
\item[Pflichtenheft]
|
||||
\item[Git Wiki] GitHub
|
||||
\end{description}
|
||||
|
||||
\noindent\textit{(b) Welche Rolle spielen Modellierung und UML in diesem Prozess?}\\
|
||||
|
||||
|
||||
\newpage
|
||||
\section{Anforderungsanalyse}
|
||||
\subsection{Aufgabe 1}
|
||||
\textit{Die Anforderungsanalyse ist ein wichtiger Teilschritt zu Beginn eines Softwareentwicklungsprozesses und ist der erste Schritt nach Erhalt des Lastenheftes Ihres Auftraggebers. Das Ergebnis der Anforderungsanalyse ist das Pflichtenheft als ein zentraler Ausgangspunkt des Entwicklungsprozesses. Welche Bestandteile und Informationen muss ein Pflichtenheft enthalten?}\\
|
||||
|
||||
|
||||
\subsection{Aufgabe 2}
|
||||
\textit{Die Anforderungsdefinition ist ein Teil des Pflichtenheftes.}\\
|
||||
\textit{(a) Stellen Sie ausgehend von der Beschreibung aus dem Video die funktionalen sowie nichtfunktionalen Anforderungen an das zu entwickelnde Umweltplaketten-Spiel
|
||||
auf. Halten Sie die Beschreibung der Anforderungen in Ihrem Dokument fest (z.B. in Form einer Liste oder einer Tabelle). Zur Beschreibung einer Anforderung sollen mindestens die folgenden Eigenschaften gehören:}\\
|
||||
\begin{itemize}
|
||||
\item eine eindeutige ID (z.B. F01, F02, ... für funktionale, NF01, NF02, ... für nichtfunktionale Anforderungen)
|
||||
\item ein für den Menschen verständlicher Name
|
||||
\item die eigentliche Beschreibung
|
||||
\item Ihre Bewertung der Priorität der Anforderung (z.B. nach ’Muss’, ’Kann/Sollte’ und ’Optional/Nice-to-have’)
|
||||
\end{itemize}
|
||||
\textit{(b) In der Vorlesung haben Sie etwas über Meta-Anforderungen, also Anforderungen an Anforderungen gelernt (z.B. Vollständigkeit, Eindeutigkeit, Korrektheit, usw.). Überprüfen Sie, ob die von Ihnen aufgestellten Anforderungen diesen Kriterien gerecht werden. Überarbeiten Sie Ihre Anforderungen gegebenenfalls. Am Ende sollen Ihre beschriebenen Anforderungen bestmöglich den Meta-Anforderungen genügen.}\\
|
||||
|
||||
|
||||
\subsection{Aufgabe 3}
|
||||
\textit{Stellen Sie die Haupt-Anwendungsfälle und Akteure der zu entwickelnden Software in Form von Use-Case-Diagrammen dar und legen Sie die Systemgrenzen fest. Wenn möglich, verfeinern Sie einen der Use-Cases.}\\
|
||||
|
||||
\newpage
|
||||
\section{Grobentwurf 1: Klassendiagramm}
|
||||
\textit{Im Folgenden ist eine Liste einiger Anforderungen an das zu entwickelnde Umweltplaketten-Spiel aus der Anforderungsanalyse dargestellt:}
|
||||
\begin{enumerate}
|
||||
\item 1. Ausführung der Anwendung im Fenstermodus
|
||||
\begin{enumerate}
|
||||
\item 1.1. Darstellung mit einer festen Auflösung von 1024x786 Pixeln
|
||||
\item 1.2. Aktualisierung der Szene mit (mindestens) 25 Bildern pro Sekunde
|
||||
\end{enumerate}
|
||||
\item 2. Beim Spielstart wird die Szene mit bis zu vier Bäumen gefüllt
|
||||
\begin{itemize}
|
||||
\item 2.1. Ein Baum erhält fixe Koordinaten
|
||||
\item 2.2. Seine Koordinaten können zur Lebenszeit nicht geändert werden
|
||||
\end{itemize}
|
||||
\item 3. Während des Spiels werden außerhalb des linken Randes Fahrzeuge erzeugt, welche anschließend gerade nach rechts durchs Bild fahren
|
||||
\begin{enumerate}
|
||||
\item 3.1. Jedes Fahrzeug erhält eine Umweltplakette. Diese drückt die dem Auto zugeordnete Emission aus.
|
||||
\item 3.2. Die Geschwindigkeit sowie tatsächliche Emission des Autos werden durch seinen Motor bestimmt.
|
||||
\item 3.3. Die Geschwindigkeit eines Fahrzeugs wird bei Erzeugung zufällig gewählt, beträgt jedoch maximal 130 km/h
|
||||
\item 3.4. Die Emission wird durch Abgaswolken hinter dem Fahrzeug dargestellt und hat drei Arten (schwach, mittel, stark)
|
||||
\item 3.5. Die Umweltplakette wird auf dem Auto dargestellt und existiert in drei Varianten (grün, gelb, rot)
|
||||
\item 3.6. Folgende Kombinationen werden im Sinne der Schadstoffklassen als richtig akzeptiert: (stark, rot), (mittel, gelb), (schwach, grün)
|
||||
\end{enumerate}
|
||||
\item 4. Durch einen Mausklick auf die Umweltplakette eines Fahrzeugs wechselt die Farbe der Plakette (gelb, rot, grün, gelb, . . . )
|
||||
\item 5. Beim Verlassen des rechten Randes wird geprüft, ob das Fahrzeug die richtige Umweltplakette hat.
|
||||
\begin{enumerate}
|
||||
\item 5.1. Passt die Plakette zur Emissionshöhe wird, erhält der Spieler Punkte
|
||||
\item 5.2. Passt die Plakette nicht zur Emissionshöhe, wird ein Leben abgezogen
|
||||
\end{enumerate}
|
||||
\end{enumerate}
|
||||
\textit{Aufgabe: Auf Basis der oben beschriebenen Anforderungen soll ein erster struktureller Grobentwurf des Spiels erstellt werden.}\\
|
||||
|
||||
\newpage
|
||||
\section{Grobentwurf 2: Sequenzdiagramm}
|
||||
\textit{Nachdem Sie die grundlegende Struktur des zu entwickelnden Spiels entworfen haben, soll nun ein Grobentwurf des Verhaltens erstellt werden. Verwenden Sie das UML-Sequenzdiagramm um den beispielhaften Ablauf des Spiels vom Zeitpunkt der Erzeugung bis zum Zeitpunkt der Zerstörung eines Fahrzeugs zu modellieren.}
|
||||
|
||||
|
||||
\end{document}
|
||||
@ -1,778 +0,0 @@
|
||||
---
|
||||
title: Softwaretechnik 1
|
||||
date: Wintersemester 20/21
|
||||
author: Robert Jeutter
|
||||
---
|
||||
|
||||
> Software: Menge von Programmen oder Daten zusammen mit begleitenden Dokumenten, die für Ihre Anwendung notwendig oder hilfreich sind [Hesse]
|
||||
|
||||
Gute Software ist schwer herzustellen
|
||||
- Entspricht Kundenwünsche, Vollständigkeit
|
||||
- Funktioniert Korrekt
|
||||
- Kosten- und Termintreue bei der Erstellung
|
||||
- weitere nicht-funktionale Qualitätsforderungen
|
||||
- Benutzerfreundlichkeit, Ergonomie
|
||||
- Sicherheit
|
||||
- Zuverlässigkeit, Fehlertoleranz
|
||||
- Performanz
|
||||
- Ressourcen-Effizienz, Skalierbarkeit, Übertragbarkeit
|
||||
- Wartbarkeit, Änder- und Erweiterbarkeit
|
||||
|
||||
Softwaretechnik
|
||||
- Technische Disziplin der Software Herstellung
|
||||
- Zielorientierte Bereitstellung uns systematische Verwendung von Prinzipien, Methoden und Werkzeugen für die arbeitsteilige, ingenieurmäßige Entwicklung und Anwendung von umfangreichen Softwaresystemen [Balzert]
|
||||
|
||||
Wie kann man Software besser entwickeln?
|
||||
- Ingenieursmäßige Herangehensweise
|
||||
- Verwendung bekannter Prinzipien und Methoden
|
||||
- Systematische Vorgehensweise
|
||||
- Verwendung von:
|
||||
- Abstraktion, Modelle, Notation, Simulation
|
||||
- Wiederverwendung:Muster, Komponenten, Framework
|
||||
- Organisation
|
||||
- Arbeitsteilung, Integration, Planung
|
||||
- Verwendung von Werkzeugen
|
||||
- IDE (Integrated Development Environment)
|
||||
- Versionierung, Bugtracker, Modellierungswerkzeug
|
||||
|
||||
# Modellierungskonzepte
|
||||
> Modell: ist eine Abstraktion eines Systems mit der Zielsetzung, das Nachdenken über ein System zu vereinfachen, indem irrelevante Details ausgelassen werden [Brügge]
|
||||
$\rightarrow$ Beschreibung eines Ausschnitts der Realität
|
||||
|
||||
- erstellen einer Abstraktion
|
||||
- abbilden signifikanter Eigenschaften
|
||||
- Deskriptiv/präskriptiv (real oder geplant)
|
||||
- Sichtweise auf ein System (Struktur, Verhalten, Zustand,...)
|
||||
- heißt Weglassen
|
||||
- setzt Verstehen voraus
|
||||
- ist nicht automatisierbar
|
||||
|
||||
Verschiedene Modelle:
|
||||
- Analysemodell
|
||||
- Entwurfsmodell
|
||||
- Implementierung (-smodell)
|
||||
- Vorgehensmodell
|
||||
- Produktmodell
|
||||
- Dokumentation, Alternativen-Auswahl
|
||||
|
||||
Modelle für:
|
||||
- Sichten
|
||||
- Funktionen
|
||||
- Daten
|
||||
- Algorithmen
|
||||
- Systemumgebung
|
||||
- Dynamisches Verhalten
|
||||
- Objektorientierte Modelle
|
||||
|
||||
## Klassische Modelle
|
||||
- Funktionen:
|
||||
- Funktionsbaum
|
||||
- Hierarchische Dekomosition der Fkt
|
||||
- nummerieren der Ebenen/Funktionen möglich
|
||||
- Bsp: Abonnement Verwaltung
|
||||
- Blockschaltbild
|
||||
- eingebettetes System, HW/SW
|
||||
- Daten
|
||||
- Data Dictionary
|
||||
- Verzeichnis von Daten mit Strukturinformationen
|
||||
- Backus-Naur-Form, kontextfreie Grammatik
|
||||
- Entity Relationship Diagram
|
||||
- Daten und ihre Beziehungen
|
||||
- Systemumgebung
|
||||
- Datenflussdiagramm
|
||||
- Fluss und Transformation von Daten zwischen Funktionen, Speichern und Schnittstellen
|
||||
- kein Kontrollfluss
|
||||
- Algorithmen
|
||||
- Entscheidungstabelle
|
||||
- Regelbasierte Beschreibung
|
||||
- Bedingung
|
||||
- Aktionen
|
||||
- Reduktionsregeln
|
||||
- Pseudocode
|
||||
- von Programmiersprache abstrahierende, detaillierte Beschreibung eines Algorithmus
|
||||
- Programmablaufplan
|
||||
- Grafische Beschreibung des Kontrollflusses
|
||||
- DIN 66001
|
||||
- Unstrukturiert
|
||||
- Struktogramm
|
||||
- Nassi-Shneidermann-Diagramm
|
||||
- keine Sprünge
|
||||
- Dynamisches Verhalten (diskrete Zustände und atomare zustandübergänge)
|
||||
- Zustandsautomat
|
||||
- Verhalten mit Zuständen und -übergängen
|
||||
- Automatenmodelle und -theorie
|
||||
- Ggf zerlegung oder kommunizierende Automaten
|
||||
- Flow-Chart
|
||||
- Ereignisgesteuerte Prozesskette (EPK)
|
||||
- Geschäftsprozesse
|
||||
- BPM
|
||||
- Petri-Netz (ggf. mit Zeitmodell)
|
||||
- Grafische Beschreibung von Nebenläufigkeit und Synchronisation
|
||||
- Objektorientierte Modelle
|
||||
- Klassendiagramme
|
||||
- UML
|
||||
|
||||
|
||||
## Objektorientierung
|
||||
- bessere Strukturierung für komplexe Zusammenhänge
|
||||
- Abstraktere Sichtweise
|
||||
- Grundprinzip: Zerlegung; Teile und Herrsche
|
||||
- ein System besteht aus vielen Objekten
|
||||
- ein Objekt hat
|
||||
- definiertes Verhalten
|
||||
- Menge genau definierter Operationen
|
||||
- Operation wird beim Empfang einer Nachricht ausgeführt
|
||||
- inneren Zustand
|
||||
- Zustand des Objekts ist Privatsache
|
||||
- Resultat einer Operation hängt vom aktuellen Zustand ab
|
||||
- eindeutige Identität
|
||||
- Identität ist unabhängig von anderen Eigenschaften
|
||||
- Mehrere verschiedene Objekte mit identischem Verhalten und identischem inneren Zustand im gleichen System möglich
|
||||
- Klasse
|
||||
- Gleichartige Objekte mit ggf. verschiedenen Zuständen
|
||||
- Verhaltensschema – Operationen
|
||||
- Innere Struktur – Attribute
|
||||
|
||||
Vorteile der Objektorientierung
|
||||
- Zuständigkeitsbereiche
|
||||
- Daten, Operationen und Zustand: lokal und gekapselt
|
||||
- Klare Schnittstellen
|
||||
- Definiertes Objektverhalten, Nachrichten
|
||||
- Hierarchie
|
||||
- Vererbung und Polymorphie (Spezialisierung), Klassenschachtelung
|
||||
- Baukastenprinzip
|
||||
- Benutzung vorgefertigter Klassenbibliotheken, Anpassung durch Spezialisierung (mittels Vererbung)
|
||||
|
||||
|
||||
## Unified Modeling Language
|
||||
- Grafisches Beschreibungsmittel für Aspekte des Softwareentwurfs diskreter Systeme
|
||||
- Spezifikation, Entwurf, Visualisierung, Konstruktion, Dokumentation von Software
|
||||
- Für OO-Softwareentwicklung und -prozess geeignet
|
||||
- UML ist weder Methode noch Prozess
|
||||
|
||||
Warum UML?
|
||||
- Objektorientierung ist zur Zeit das vorherrschende Modellierungs-Paradigma, Industrie-Standard
|
||||
- Kombination von Struktur-, Verhaltens-, Interaktions-, und Verteilungsmodellen
|
||||
- Für Analyse, Entwurf, Implementierung und Test einsetzbar
|
||||
- Gute Werkzeugunterstützung für Editieren, Versionierung, Codegenerierung
|
||||
- Erweiterbarkeit der UML mit Stereotypen und Tags
|
||||
- Semi-formale Modelle, z.T. verschiedene Interpretationen
|
||||
- Offenheit: Erweiterung mit stereotypes, tags, constraints
|
||||
|
||||
Nachteile UML
|
||||
- UML ist in vielen Facetten nicht präzise festgelegt
|
||||
- Werkzeuge für Transformation, Analyse etc. fehlen noch
|
||||
- UML ist keine „kleine Sprache“: Lernaufwand notwendig
|
||||
- Komponenten sind nicht adäquat darstellbar
|
||||
- Sprachen wie die UML werden erlernt durch Übung!
|
||||
- Aber: LV SWT ist kein kompletter UML-Kurs
|
||||
|
||||
### Überblick über Modelle
|
||||
- 14 Diagrammarten
|
||||
- Struktur-Diagramme
|
||||
- Klassen-, Objekt-, Komponenten-, Kompositions-Struktur-,
|
||||
- Paket- und Verteilungsdiagramm
|
||||
- Profildiagramm – zur UML-Erweiterung
|
||||
- Verhaltens-Diagramme
|
||||
- Use-Case-, Aktivitäts- und Zustandsdiagramms
|
||||
- Interaktionsdiagramme: Sequenz-, Kommunikations-, Timing- und Interaktionsübersichts-Diagramm
|
||||
|
||||
#### Use-Case-Diagramm
|
||||
- Beschreiben Systemfunktion aus Benutzersicht (Was, nicht Wie)
|
||||
- Erste Anforderungsspezifikation (requirements)
|
||||
- Planbare Einheiten als Inkremente für die Entwicklung
|
||||
- Keine Modellierung eines Ablaufs!
|
||||
- Erstellen von Testfällen (test case generation)
|
||||
- Grundelemente
|
||||
- Anwendungsfall: Use Case
|
||||
- Beteiligte: Aktor
|
||||
- Verfeinerung mittels Use-Case-Realisierung notwendig
|
||||
- Textuelle Beschreibung
|
||||
- Verhaltensdiagramme
|
||||
|
||||
#### Klassendiagramm
|
||||
- Modellierung der Struktur (Aufbau) eines Systems
|
||||
- Modellierung von statischen Aspekten
|
||||
- Modellierung der Struktur von Daten
|
||||
- Klasse im Mittelpunkt
|
||||
- Aufbau: Attribute, Operationen
|
||||
- Beziehungen zueinander: Assoziationen, Vererbung
|
||||
- Verbreitetstes und bekanntestes Diagramm der UML
|
||||
|
||||
#### Objektdiagramm
|
||||
- Struktur des Systems zur Laufzeit zu einem Zeitpunkt
|
||||
- Tatsächliche Zusammenhänge und Belegungen von Attributen von Objekten zu einem Zeitpunkt
|
||||
- Eine detaillierte Sicht auf einen Aspekt
|
||||
- Keine vollständige Beschreibung (zu komplex)
|
||||
- Für kompliziertere Abhängigkeiten (z.B. Rekursion)
|
||||
- Objektdiagramm für alle Arten von Exemplaren
|
||||
- z.B.: Klasse (Objekt), Komponente, Knoten, ...
|
||||
- Keine Exemplare von Operationen -> Ablauf -> Verhaltensdiagramme / Interaktionsdiagramme
|
||||
- Kein Verlauf der Wertebelegung über die Zeit
|
||||
|
||||
#### Paketdiagramm
|
||||
- Gliederung (Strukturierung) des Systems in Teile (Pakete)
|
||||
- Zuordnung von Elementen zu einem Paket
|
||||
- Bildung von Hierarchien (Enthält-Beziehung)
|
||||
- Abhängigkeiten zwischen den Paketen
|
||||
- "Include" von Quellcode-Dateien (<<import>>)
|
||||
- Anwendung:
|
||||
- Zum Grobentwurf von Systemen
|
||||
- Definition von Schichten
|
||||
|
||||
#### Komponentendiagramm
|
||||
- Strukturierung des Systems durch Komponenten
|
||||
- Komponente: Modulare, austauschbare Einheit (Substitution)
|
||||
- Modellierung der Abhängigkeiten zwischen Komponenten
|
||||
- Modellierung der inneren Struktur von Komponenten
|
||||
- Definition von Schnittstellen
|
||||
|
||||
#### Kompositionsstrukturdiagramm
|
||||
- Teile-Ganzes-Strukturen -> Kompositionsstruktur
|
||||
- Strukturell statische Kompositionsstrukturen:
|
||||
- Kurzschreibweise bei vielen Kompositionen
|
||||
- Modellierung des Aufbaus komplexer Systeme
|
||||
- Strukturell dynamische Kompositionsstrukturen:
|
||||
- Notwendige Strukturen zur Realisierung eines Verhaltens
|
||||
- Definition von Rollen, zur Lösung wiederkehrender Probleme -> Modellierung von Mustern
|
||||
- Starke Verwandtschaft mit dem Klassendiagramm
|
||||
- Spezialisierte Kompositionsbeziehung -> erweiterte Semantik
|
||||
|
||||
#### Aktivitätsdiagramm
|
||||
- Modellierung von
|
||||
- Kontrollflüssen
|
||||
- Datenflüssen
|
||||
- Parallelem Verhalten
|
||||
- Verzweigungen, bedingten und gewichteten Abläufen
|
||||
- Geschäftsprozessmodellierung möglich
|
||||
- Abstrakte und detaillierte Verhaltensbeschreibung möglich
|
||||
- Grundlage zur Codegenerierung
|
||||
- Zur Verfeinerung von
|
||||
- Use-Cases
|
||||
- Operationen / Interaktionen
|
||||
- anderen Aktionen und Aktivitäten
|
||||
|
||||
#### Interaktionsdiagramme
|
||||
- Modellierung von
|
||||
- Kommunikation zwischen Kommunikationspartnern (Lebenslinie)
|
||||
- Operationen (Modellierung eines Programms)
|
||||
- Informationsaustausch / Nachrichten
|
||||
- Gemeinsames Grundkonzept der Interaktionsdiagramme
|
||||
- Sehr detaillierte Diagramme
|
||||
- Meist nicht zur vollständigen Beschreibung eines Systems
|
||||
- Betrachtung eines wichtigen Teilaspekts
|
||||
- Grundlage zur Codegenerierung
|
||||
|
||||
#### Sequenzdiagramm
|
||||
- Genaue zeitliche Abfolge von Nachrichten
|
||||
- Umfangreichstes Interaktionsdiagramm
|
||||
- Kontrollelemente möglich (Schleifen, Verzweigungen)
|
||||
|
||||
#### Kommunikationsdiagramm
|
||||
- Kommunikationsbeziehungen der Kommunikationspartner stehen im Vordergrund
|
||||
- Welche Komponenten arbeiten wie zusammen, um eine Funktion zu erfüllen
|
||||
|
||||
#### Timing-Diagramm
|
||||
- Genaue zeitliche Darstellung von Zustandsübergängen
|
||||
- Kommunikation abhängiger Zustandsautomaten
|
||||
- Modellierung einzelner Interaktion
|
||||
|
||||
##### Prinzipieller Aufbau
|
||||
- Zeitlicher Verlauf senkrecht
|
||||
- Kommunikationspartner waagerecht (unsortiert)
|
||||
- Lebenslinie
|
||||
- Rechteck mit gestrichelter senkrechter Linie
|
||||
- Start, Ende und Dauer der Ausführung einer Operation
|
||||
- Rekursive Aufrufe möglich
|
||||
- Ereignisspezifikation
|
||||
- Stelle des Sendens / Empfangens der Nachricht
|
||||
- Definition der Reihenfolge des Auftretens
|
||||
- Trace: Folge von Sende- und Empfangsereignissen
|
||||
|
||||
##### Weitere Elemente des Sequenzdiagramms
|
||||
- Nachrichten ohne Sender
|
||||
- z.B. am Beginn einer Interaktion
|
||||
- Verlorene Nachrichten (ohne Empfänger)
|
||||
- Nachricht ohne dargestellten Empfänger
|
||||
- z. B. am Ende einer Interaktion
|
||||
- Erzeugen von Lebenslinien
|
||||
- Gestrichelte Linie mit geöffnetem Pfeil
|
||||
- Keine Rückgabenachricht
|
||||
- Zeitliche Einrückung des Rechtecks
|
||||
- Zerstören von Lebenslinien
|
||||
- Durchgezogene Linie mit Dreieckende
|
||||
- Kann Rückgabenachricht erzeugen
|
||||
|
||||
##### Nachrichten in Interaktionsdiagrammen
|
||||
- Ereignis des Sendens bzw. Empfangens von Nachrichten
|
||||
- Typen:
|
||||
- Operationsaufruf (synchron / asynchron)
|
||||
- Antwort Nachricht
|
||||
- Signal (asynchron), Create-/ Delete Message
|
||||
- Operationsaufruf: Parameterliste muss kompatibel sein
|
||||
- Nachrichtentypen
|
||||
|
||||
#### Zustandsdiagramm
|
||||
- Modellierung des (vollständigen?) Verhaltens
|
||||
- Zustände von Klassen / Objekten / Komponenten
|
||||
- Übergänge zwischen den Zuständen
|
||||
- Ereignisse, die Zustandswechsel auslösen
|
||||
- Modellierung von endlichen Automaten (Zustandsmaschinen)
|
||||
- Deterministische
|
||||
- Nichtdeterministische
|
||||
- Verfeinerung von Zuständen möglich
|
||||
- Modellierung von verteilten Systemen / parallelem Verhalten
|
||||
- Grundlage zur Codegenerierung
|
||||
|
||||
|
||||
# Analyse
|
||||
- Einordnung in den Projektablauf
|
||||
- Was ist eine Anforderung?
|
||||
- Merkmal, Eigenschaft, Bedingung oder Einschränkung eines Systems
|
||||
- Notwendig für die Akzeptanz vom Kunden
|
||||
- Definition (IEEE 610.12-1990)
|
||||
- Dokumentierte Darstellung einer Fähigkeit oder Eigenschaft
|
||||
- von Anwender benötigt zur Problemlösung bzw. um Ziel zu erreichen
|
||||
- Muss von System oder Komponente erfüllt werden, um Vertrag oder Standard zu erfüllen
|
||||
|
||||
- Funktionale Anforderungen - Was soll es tun?
|
||||
- „...Legt eine vom Softwaresystem oder einer seiner Komponenten bereitzustellende Funktion oder Service dar“ [Balzert]
|
||||
- Was leistet das System
|
||||
- Welche Funktionen bietet es
|
||||
- Wie interagiert es mit der Umgebung
|
||||
- Anforderungen an:
|
||||
- Verhalten
|
||||
- Struktur
|
||||
- (Alternativ: Statik, Dynamik, Logik)
|
||||
- Nichtfunktionale Anforderungen – Wie?
|
||||
- „...legen qualitative oder quantitative Eigenschaften des Softwareprojektes oder einer Komponente fest“ [Balzert]
|
||||
- Auch Bezeichnet als:
|
||||
- Quality of Service
|
||||
- Qualitätsanforderungen
|
||||
- Arten - FURPS (ISO 9126):
|
||||
- Functionality (Funktionalität)
|
||||
- Usability (Benutzbarkeit)
|
||||
- Reliability (Zuverlässigkeit)
|
||||
- Performance (Effizienz) / Portability (Übertragbarkeit)
|
||||
- Supportability (Änderbarkeit/ Wartbarkeit)
|
||||
|
||||
- Funktionalität
|
||||
- Angemessen, Genauigkeit
|
||||
- Sicherheit: Vertraulichkeit, Informationssicherheit, Datenintegrität, Verfügbarkeit
|
||||
- (Nicht ausreichend spezifizierte funktionale Anforderung)
|
||||
- Benutzbarkeit
|
||||
- Verständlichkeit, Erlernbarkeit, Bedienbarkeit, Attraktivität
|
||||
- Zuverlässigkeit
|
||||
- Reife (Fehler-Anzahl), Fehlertoleranz, Wiederherstellbarkeit
|
||||
- Effizient/ Leistungsanforderungen
|
||||
- Zeitverhalten, Verbrauchsverhalten, Wirtschaftlichkeit
|
||||
- Portabilität
|
||||
- Anpassbarkeit, Installierbarkeit, Koexistenz, Austauschbarkeit
|
||||
- Wartbarkeit
|
||||
- Analysierbarkeit, Änder- und Erweiterbarkeit, Stabilität (bei Änderungen), Testbarkeit
|
||||
- Weitere:
|
||||
- Konformität zu Konventionen und Bestimmungen
|
||||
- Interoperabilität zu anderen Systemen
|
||||
- Implementierungsanforderungen
|
||||
- Schnittstellenanforderungen
|
||||
- Skalierbarkeit (Änderungen des Problemumfangs)
|
||||
- Betriebliche und rechtliche Rahmenbedingungen
|
||||
- Liefer- und Verpackungsanforderungen
|
||||
|
||||
### Nichtfunktionale Anforderungen
|
||||
Schwierigkeit nichtfunktionaler Anforderungen
|
||||
- Hängen oft von Verhalten ab: daher komplex und nicht direkt sichtbar
|
||||
- „Das Auto hat vier Räder“ (Struktur)
|
||||
- „Wenn der Blinker betätigt wird, blinkt das Auto dreimal wenn die Zündung an ist; ansonsten wird das Standlicht einseitig eingeschaltet“ (Korrektes Verhalten)
|
||||
- „Das Motorsteuergerät darf innerhalb von 5 Jahren und 150.000km Laufleistung höchstens mit 0.1% Wahrscheinlichkeit ausfallen“ (Zuverlässigkeit)
|
||||
|
||||
Umgang mit nichtfunktionalen Eigenschaften
|
||||
- Nicht direkt „by construction“ zu realisieren
|
||||
- Naive Herangehensweise: Ignorieren!
|
||||
- Entwerfen und Implementieren der Software ohne
|
||||
- Berücksichtigung nichtfunktionaler Eigenschaften
|
||||
- Testen der nichtfunktionalen Eigenschaften
|
||||
- Wenn nicht erfüllt: Entwurf und Implementierung ändern!
|
||||
- Funktioniert nur bei sehr einfachen Systemen, bzw. wenn nichtfunktionale Eigenschaften nicht wichtig sind!
|
||||
|
||||
Sinnvoller Umgang mit nichtfunktionalen Eigenschaften
|
||||
- Untersuchung der Projektrisiken bereits in der Analysephase
|
||||
- größte Risiken zuerst betrachten!
|
||||
- Immer fragen: Geht das so überhaupt?
|
||||
- Festlegungen des Entwurfs möglichst früh gegen Anforderungen prüfen – aber wie?
|
||||
- Modellbasierter Entwurf
|
||||
- Modellierung des Systems und seiner Umwelt
|
||||
- Bewertung des Modells (Simulation)
|
||||
- Lehrveranstaltungen Systementwurf, KIS, LTS
|
||||
|
||||
Randbedingungen
|
||||
- „... Eine Randbedingung ist eine organisatorische oder technologische Vorgabe, die die Art und Weise einschränkt, wie das betrachtete System realisiert werden kann.“
|
||||
- Werden nicht umgesetzt
|
||||
- Schränken Lösungsraum ein
|
||||
- Beispiele:
|
||||
- Kosten
|
||||
- Durchlaufzeit: Time to Market
|
||||
- Vorgaben durch Marketing und Vertrieb
|
||||
- Technische Randbedingungen (nichtfunktionale Anforderung)
|
||||
|
||||
|
||||
|
||||
|
||||
Geforderte (Meta-)Eigenschaften
|
||||
- Vollständig: alle Szenarien sind beschrieben
|
||||
- Konsistent: keine Widersprüche
|
||||
- Eindeutig: nur eine Interpretation möglich
|
||||
- Korrekt: genaue und richtige Darstellung
|
||||
- Realistisch: unter geg. Einschränkungen implementierbar
|
||||
- Überprüfbar: durch Tests am Endprodukt nachweisbar
|
||||
- Rückverfolgbar: Auswirkungen bis zur Implementierung nachvollziehbar (Testfälle, Auswirkung von Änderungen)
|
||||
- Klassifizierbar (Risiko, Priorität, Dringlichkeit, Nutzen ...)
|
||||
- Validierung mit dem Kunden
|
||||
|
||||
- Requirements Engineering
|
||||
- Ermittlung, Analyse und Verwaltung von Anforderungen
|
||||
- Ausgangspunkt: Projektidee
|
||||
- Anforderungsermittlung
|
||||
- requirements elicitation, requirements definition
|
||||
- Bestimmen und dokumentieren der Anforderungen an das geplante System
|
||||
- Beteiligt: Entwickler, Kunde, Benutzer
|
||||
- Ergebnis: Anforderungsspezifikation - Glossar, Vertrag, Lastenheft
|
||||
- Anforderungs-Analyse
|
||||
- requirements analysis, system modeling
|
||||
- Beschreibung im Detail und formal strukturiert
|
||||
- Beteiligt: Entwickler
|
||||
- Ergebnis: funktionale Spezifikation - Produktdefinition, Analysemodell, Pflichtenheft
|
||||
|
||||
|
||||
|
||||
| | Anforderungsermittlung | Systemmodellierung |
|
||||
| -- | -- | -- |
|
||||
| Ergebnis | Anforderungsspezifikation im Lastenheft, Glossar, Lastenheft | funktionale Spezifikation in Produktdefinition, Analysemodell, Pflichtenheft |
|
||||
| Notation | Text | Text + (semi-) formales Modell |
|
||||
| Kommunikation | mit dem Kunden | zwischen Entwicklern |
|
||||
| Sichtweise | des Anwenders | äußere Systemaspekte |
|
||||
Vor allem: Kommunikationsleistung!
|
||||
|
||||
Bedeutung:
|
||||
- Falsche Anforderungen führen zu falschem System
|
||||
- Frühe Fehler im Entwicklungsprozess sind teuer!
|
||||
|
||||
Fehlerentstehung und Fehlerquellen bei Anforderungserfassung
|
||||
- 83% sprachliche Fehler (Un- bzw. Missverständlich)
|
||||
- 75% Logische Fehler (Widersprüchlichkeit, Redundanz)
|
||||
- 73% Inhaltliche Fehler (Falsche Sachverhalte, Unvollständig)
|
||||
|
||||
## Ermiteln von Anforderungen
|
||||
Woher kommen Anforderungen?
|
||||
- Ausgangspunkt
|
||||
- Projektidee, schriftliche Skizze
|
||||
- Kurz und knapp
|
||||
- Stichpunkte der wichtigsten Funktionen
|
||||
- Lastenheft (falls schon existiert)
|
||||
- Interessenhalter (stakeholder)
|
||||
- Identifizieren, Wichtigkeit bewerten (berücksichtigen?)
|
||||
- Ansprechpartner? Interessen und Erwartungen
|
||||
- Fachexperten, Verantwortliche, Betroffene
|
||||
|
||||
Beteiligte Rollen
|
||||
- Endbenutzer
|
||||
- Aufnahme Ist-Zustand, Domänenwissen, Anforderungen
|
||||
- Kunde
|
||||
- Definiert Ziel des Systems, Vertragsverhandlung
|
||||
- Konfigurationsmanager
|
||||
- Revisionsgeschichte der Dokumente, Nachvollziehbarkeit
|
||||
- Architekt
|
||||
- Integration von Anwendungsfall- und Objektmodellen
|
||||
- Analytiker
|
||||
- Modelliert das System und erstellt Anwendungsfälle
|
||||
- Redakteur
|
||||
- Prüfer
|
||||
|
||||
Wie ermittelt man Anforderungen?
|
||||
- Problem: Entwickler müssen sich in Begriffs- und Denkwelt des Kunden einarbeiten, sonst Kommunikationsprobleme
|
||||
- Systematische Vorgehensweise
|
||||
- Kommunikation mit Kunden
|
||||
- Geschäftsprozess (business process)
|
||||
- fachlicher Ablauf, der Wert oder Kosten verursacht
|
||||
- Akteur (actor)
|
||||
- Benutzer, Schnittstelle nach außen
|
||||
- Szenario (scenario)
|
||||
- Interaktion mit System als Ablauf
|
||||
- Anwendungsfall (use case)
|
||||
- Automatisierter Arbeitsschritt, vom System ausgeführt
|
||||
- Interviews mit Fachanwendern
|
||||
- Mitschrift, später strukturierter Text und Tabelle
|
||||
- Strukturierte Spezifikation
|
||||
- Vorlagen / sprachliche Anforderungsschablonen
|
||||
- Formulare
|
||||
- Reduzierung sprachlicher Mehrdeutigkeiten
|
||||
- Anwendungsfalldiagramm (Use-Case-Diagramm)
|
||||
- Arbeitsschritt eines Geschäftsprozesses, der durch das System ausgeführt wird
|
||||
- Anforderungen an das System modellieren – was soll das System leisten
|
||||
- Systemgrenzen / Systemkontext festlegen
|
||||
- Systembeteiligte modellieren
|
||||
- Planbare Einheiten als Schritte für die Entwicklung
|
||||
- Verwendung bereits ab Projektbeginn
|
||||
- Keine Modellierung eines Ablaufs!
|
||||
- Umgang mit Szenarien und Anwendungsfällen
|
||||
- Zunächst nur zum Verständnis kurz aufstellen
|
||||
- Systemgrenze definieren
|
||||
- Beschreibungen verfeinern
|
||||
- Änderungen mit Kunden abstimmen
|
||||
- Prototypen nur zur visuellen Unterstützung
|
||||
- Benutzungsschnittstelle erst beginnen, wenn funktionale Anforderungen in etwa klar sind
|
||||
|
||||
Leitfaden für Anwendungsfälle
|
||||
- Benennen mit Verbalphrasen, die Anwendersicht beschreiben (Simuliere)
|
||||
- Akteure mit Substantiven benennen (Anwender)
|
||||
- Systemgrenzen klären. Arbeitsschritte von Akteuren und System kennzeichnen
|
||||
- Schritte im aktiven Stil beschreiben (Auto bremst)
|
||||
- Ursächliche Beziehung zwischen Folgeschritten
|
||||
- 1 Anwendungsfall = 1 vollständige Transaktion
|
||||
- Normalfall darstellen; Ausnahmen gesondert beschreiben
|
||||
- Nicht die Benutzungsschnittstelle beschreiben (statt dessen visuellen Prototypen verwenden)
|
||||
- Übersichtlichkeit (max. 2-3 Seiten), sonst zerlegen
|
||||
|
||||
- Typische Probleme
|
||||
- Kommunikations- und Verständnisprobleme
|
||||
- Viele verschiedene Beteiligte
|
||||
- Kunden wissen nicht, was sie genau wollen und was geht
|
||||
- Verwendung von Fachsprachen
|
||||
- Widersprüchliche Anforderungen, verschiedene Interessen
|
||||
- Nicht-technische organisatorische, historische oder rechtliche Rahmenbedingungen
|
||||
- Zusätzliche Beteiligte können auftauchen
|
||||
- Anforderungen ändern sich während der Entwicklung
|
||||
- Anforderungsänderungen
|
||||
- Sind die Regel
|
||||
- Tätigkeiten der Anforderungsanalyse
|
||||
- Anforderungen strukturieren
|
||||
- Eigenschaften der Anforderungen bestimmen
|
||||
- Anforderungen priorisieren
|
||||
- Anforderungen in Textform, Grafiken, Modellen dokumentieren
|
||||
- Anforderungen modellieren
|
||||
- Anforderungen auf inhaltliche Qualität prüfen
|
||||
- Auf Übereinstimmung mit den Zielen prüfen
|
||||
- Ziel Abnahme der Anforderung
|
||||
- Hängt mit Analyse des Systems zusammen
|
||||
- Anforderungen strukturieren
|
||||
- Unterteilung
|
||||
- Funktional, Nichtfunktional
|
||||
- Muss, Kann,... oder Haupt- und Nebenanforderung
|
||||
- Hierarchische Zerlegung
|
||||
- Unterteilen, Verfeinern
|
||||
- Ordnung festlegen, eindeutig Nummerieren
|
||||
- auf Einmaligkeit achten
|
||||
- Beziehungen festhalten
|
||||
- Verwendung von Werkzeugen
|
||||
- MS-Project, Doors, Git issues, Trac, Bugzilla, MKS,...
|
||||
- Modellierungswerkzeuge
|
||||
- Eigenschaften bestimmen
|
||||
- Wahl der Eigenschaften firmen- bzw. projektspezifisch
|
||||
- Wichtige Eigenschaften
|
||||
- Identifikationsnummer
|
||||
- Kurzbezeichnung
|
||||
- Beschreibung (Text, ggf. Grafik, Modell)
|
||||
- Aufwand
|
||||
- Priorität der Anforderung
|
||||
- Bearbeitungsstatus / Restaufwand
|
||||
- Zugeordnet (wer ist verantwortlich / bearbeitet)
|
||||
- Querverbindungen zu anderen Anforderungen
|
||||
- Ggf. zusätzliche Dokumente oder Bemerkungen
|
||||
- Stabilität der Anforderung (Änderungswkt.)
|
||||
- Kritikalität der Anforderung: Schäden bei Fehlern?
|
||||
- Entwicklungsrisiko: Erfolgsaussichten der Umsetzung
|
||||
- Abnahmekriterien / Erfüllungsnachweis durch?
|
||||
- Anforderungstyp: Funktional, nicht funktional ,...
|
||||
- Anforderungssicht: Dynamik, Statik, Logik, Struktur, Funktion
|
||||
- Mögliche Konflikte
|
||||
- Autor
|
||||
- Quelle: Wer möchte die Anforderung umgesetzt haben?
|
||||
- Status der Beschreibung: Idee, grober Inhalt, detailliert
|
||||
- Anforderungsversion
|
||||
- Anforderungen priorisieren
|
||||
- MuSCoW-Priorisierung
|
||||
- Muss-, Kann-, Optional, Nicht (Abgrenzungskriterien) (must, should, could, won‘t)
|
||||
- Ad-hoc: Stakeholder priorisiert Anforderungen
|
||||
- Priorisierungsmatrix / Kosten-Wert-Analyse
|
||||
- Eigenschaften bewerten (Punkte vergeben)
|
||||
- Werte gewichten
|
||||
- Priorität berechnen $Prioritäten = \frac{Nutzen - Nachteil}{Kosten + Risiko}$
|
||||
- Kano-Klassifikation
|
||||
- Basiseigenschaften: Werden vorausgesetzt (fehlen stört, wenig zusätzliche Zufriedenheit)
|
||||
- Leistungseigenschaften: Sonderwünsche
|
||||
- Begeisterungseigenschaften: Wird nicht erwartet
|
||||
- Abfragen per Fragenkatalog
|
||||
- Reihenfolge festlegen
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Objektorientierte Analyse und Systemmodellierung
|
||||
- Übersicht
|
||||
- Aufgabe: Systemmodell erstellen, funktionale Spezifikation
|
||||
- Beschreibung der Systembenutzung und des Verhaltens
|
||||
- Was, nicht wie – Implementierungsaspekte ausklammern
|
||||
- Nicht: Datenhaltung, Verteilung, Technologien, Architektur, ..
|
||||
- Zusammenhang mit Anforderungsspezifikation
|
||||
- OO: Modell des Anwendungsbereichs
|
||||
- Analysemodell
|
||||
- Korrekt, vollständig, konsistent und nachprüfbar
|
||||
- Struktur und Verhalten
|
||||
- Verschiedene Sichten (OO, Strukturiert, ...)
|
||||
- Eingangsdokumente
|
||||
- Lastenheft, Anforderungsspezifikation
|
||||
- Typische Ergebnisse
|
||||
- Funktionales Modell
|
||||
- Geschäftsprozesse und Anwendungsfälle
|
||||
- Objektmodell
|
||||
- Dynamisches Modell – Systemverhalten
|
||||
- Zustands- und Sequenzdiagramme
|
||||
- Vor- und Nachbedingungen von Systemoperationen
|
||||
- Prototyp / Spezifikation Benutzungsschnittstelle
|
||||
- Pflichtenheft
|
||||
- Objektorientierte Analyse nach [Brügge / Dutoit]
|
||||
- Verdeutlicht iterativen Ablauf
|
||||
- Unterteilung des Analysemodells in:
|
||||
- Funktionales Modell (Anwendungsfälle)
|
||||
- Objektmodell (Klassen und Objektdiagramme)
|
||||
- Dynamisches Modell (Zustands- und Sequenzdiagramme)
|
||||
- Unterscheidung der Objekttypen
|
||||
|
||||
|
||||
|
||||
|
||||
- Heuristik Sprache $\rightarrow$ OO-Modell
|
||||
- Objektarten im Systemmodell
|
||||
- Entitätsobjekte – vom System verwaltete Informationen
|
||||
- Grenzobjekte – Interaktion zwischen System und Akteuren
|
||||
- Steuerungsobjekte – Durchführung der Anwendungsfälle
|
||||
- Identifizierung von Entitätsobjekten
|
||||
- Begriffe, die klargestellt werden müssen
|
||||
- Wiederkehrende Substantive in Anwendungsfällen
|
||||
- Heuristiken
|
||||
- Reale Objekte, die das System kennen muss
|
||||
- Reale Prozesse, die das System verfolgen muss
|
||||
- Anwendungsfälle
|
||||
- Datenquellen und -senken
|
||||
- Artefakte, mit denen der Nutzer interagiert
|
||||
- Identifizierung von Grenzobjekten
|
||||
- Elemente der Benutzungsschnittstelle
|
||||
- Formulare für Eingaben
|
||||
- Nachrichten, Rückmeldungen
|
||||
- Endgeräte
|
||||
- In der Begriffswelt des Anwenders bleiben!
|
||||
- Schnittstellen grafisch skizzieren bzw. Prototyp!
|
||||
- Identifizierung von Steuerungsobjekten
|
||||
- Koordination von Grenz- und Entitätsobjekten
|
||||
- Abarbeitung von Anwendungsfällen
|
||||
- Reihenfolge von Schritten
|
||||
- Informationen übernehmen und weiterleiten
|
||||
- Oft ein Steuerungsobjekt pro Anwendungsfall
|
||||
- Beispiel: Simulationsszenario
|
||||
- Verhaltensmodell sinnvoll! Im folgenden: dynamische Modelle
|
||||
|
||||
- Abläufe der Anwendungsfälle modellieren
|
||||
- Ziel - Objekte finden
|
||||
- Klassen identifizieren
|
||||
- Verhalten / Operationen finden
|
||||
- Use Case durch Interaktion verfeinern
|
||||
- einfacher kurzer Ablauf: textuelle Beschreibung, Aktivitätsdiagramm
|
||||
- Ablauf mit Verzweigungen, Parallelitäten: Aktivitätsdiagramm (Kontrollflussmodellierung)
|
||||
- datengetriebener Ablauf: Aktivitätsdiagramm (Objektflussmodellierung)
|
||||
- Interaktion zwischen den Objekten wichtig: Kommunikationsdiagramm, Aktivitätsdiagramm (Aktivitätsbereiche), Sequenzdiagramm
|
||||
- zeitliche Abfolge steht im Mittelpunkt: Sequenzdiagramm
|
||||
- Zustandswechsel / zeitliche Abfolge von Zuständen: Zustandsdiagramm / Timing-Diagramm
|
||||
- komplexe Abläufe mit Verzweigungen und Parallelitäten: Interaktionsübersichtsdiagramm
|
||||
- komplexe Abläufe ohne Verzweigungen und Parallelitäten: weitere Verfeinerung durch Use-Case-Diagramm
|
||||
- komplexer strukturierter Ablauf: Kollaboration aus dem Kompositionsstrukturdiagramm
|
||||
|
||||
- Dynamische UML-Modelle
|
||||
- Abläufe
|
||||
- Aktivitätsdiagramm (activity diagram)
|
||||
- Kommunikationsdiagramm (communication diagram)
|
||||
- Sequenzdiagram (sequence diagram)
|
||||
- Zeitdiagramm (timing diagram)
|
||||
- Zustandsabhängiges Verhalten von Objekten
|
||||
- Zustandsautomat (state chart diagram)
|
||||
|
||||
- Aktivitätsdiagramm
|
||||
- Aktion – einzelner Schritt
|
||||
- Aktivität
|
||||
- Beschreibt einen Ablauf / repräsentiert ein Verhalten
|
||||
- Beinhaltet eine Folge Aktionen, Kontroll- oder Objektknoten
|
||||
- Schachtelung von Aktivitäten und Aktionen
|
||||
- Aktionen in Aktivitäten enthalten
|
||||
- Aktionen durch Aktivitäten verfeinerbar
|
||||
- Aktivitäten beschreiben / verfeinern
|
||||
- Aktionen, Use Cases, Interaktionen, Operationen ...
|
||||
- Ein- und Ausgabeparameter in Form von Objekten
|
||||
- Parameterknoten entsprechend Pins der aufrufenden Aktion
|
||||
- Alternativ: Parameterangabe mit Name und Typ
|
||||
- Angabe von Vor- und Nachbedingungen möglich
|
||||
- Optional: Parameter unter Aktivitätsnamen
|
||||
|
||||
- Verfeinerung der Aktionen durch Aktivitäten
|
||||
- Aktion durch Interaktionen verfeinern
|
||||
- Detaillierte Diagramme
|
||||
- Meist entwurfsnah
|
||||
- Verfeinerung der Aktionen durch StateChart
|
||||
- Objekte zusammenstellen und klassifizieren
|
||||
- Toolunterstützung (Möglichkeiten stark toolabhängig)
|
||||
- Objekte Ergebnis der Verhaltensmodellierung
|
||||
- Ergebnis Verhaltensdiagramm: Operationen der Klassen
|
||||
- Klassen generalisieren / spezialisieren $\rightarrow$ Klassenhierarchie
|
||||
- Übergang zum Entwurf
|
||||
- Klassenstruktur festlegen
|
||||
- Spezifikation von Benutzungsschnittstellen
|
||||
- Skizzieren, Prototyp generieren, Spezialwerkzeuge
|
||||
- Klassen und Operationen in Funktionen
|
||||
- Gestaltung MMI, style guides, Standards
|
||||
|
||||
## Dokumentation von Anforderungen
|
||||
- Lastenheft
|
||||
- Gesamtheit der Forderungen eines Auftraggebers (AG) an die Lieferungen und Leistungen eines Auftragnehmers (AN), manchmal Vertragsbasis
|
||||
- Muss-Kriterien, Kann-Kriterien, Abgrenzungskriterien
|
||||
- Pflichtenheft
|
||||
- Entwurf aus AN-Sicht, Umsetzung des Lastenhefts
|
||||
- Meist Vertragsbasis
|
||||
- Inhalt Anforderungsspezifikation
|
||||
- Zielsetzung
|
||||
- Allgemeine Beschreibung
|
||||
- Umgebung, generelle Funktion, Restriktionen, Benutzer
|
||||
- Spezifische funktionale Anforderungen
|
||||
- möglichst quantitativ (z.B. Tabellenform)
|
||||
- eindeutig identifizierbar (Nummern)
|
||||
- Spezifische nicht-funktionale Anforderungen
|
||||
- z.B. Antwortzeit, Speicherbedarf, HW/SW-Plattform
|
||||
- Entwicklungs- und Produkt-Standards
|
||||
- Qualitäts-Zielbestimmung
|
||||
- Zu erwartende Evolution des Systems, Versionen
|
||||
- Abkürzungsverzeichnis, Glossar, Index, Referenzen
|
||||
|
||||
|
||||
Pflichtenheft (Beispiel)
|
||||
1. Einleitung, Zielbestimmung
|
||||
2. Übersicht
|
||||
- Einsatzbereich, Zielgruppen
|
||||
- Produkt-Umgebung
|
||||
- Produkt-Funktionen
|
||||
- Restriktionen
|
||||
- Annahmen und Abhängigkeiten
|
||||
- Vorhandenes System (ggf.)
|
||||
3. Vorgeschlagenes System
|
||||
- Übersicht
|
||||
- Funktionale Anforderungen
|
||||
- Benutzungsschnittstelle
|
||||
- Nichtfunktionale Anforderungen
|
||||
- Systembeschreibung
|
||||
- Szenarien
|
||||
- Anwendungsfälle
|
||||
4. Glossar
|
||||
|
||||
|
||||
# Grobentwurf
|
||||
# Feinentwurf
|
||||
# Implementierung
|
||||
# Vorgehensweise
|
||||
# Projektmanagement
|
||||
Loading…
Reference in New Issue
Block a user