diff --git a/README.md b/README.md index 0c976f3..f7c509f 100644 --- a/README.md +++ b/README.md @@ -27,7 +27,7 @@ Unterlagen zu Informatik Vorlesungen der TU Ilmenau - [Praktikum A2](Rechnerarchitekturen%201%20-%20Praktikum%20A2.pdf) - [Rechnerarchitekturen 2](Rechnerarchitekturen%202.md) - [Softwaretechnik](Softwaretechnik.md) - - [MindMap](Softwaretechnik%20-%20MindMap.pdf) (work in progress) + - [Zusammenfassung](Softwaretechnik%20-%20Cheatsheet.pdf) (work in progress) - [Seminar](Softwaretechnik%20-%20Seminar.pdf) (work in progress) - [Beispiel Flowchart](Softwaretechnik%20Flowchart.tex) - [Stochastik](Stochastik.md) diff --git a/Softwaretechnik - Cheatsheet.pdf b/Softwaretechnik - Cheatsheet.pdf new file mode 100644 index 0000000..d7230e1 Binary files /dev/null and b/Softwaretechnik - Cheatsheet.pdf differ diff --git a/Softwaretechnik - Cheatsheet.tex b/Softwaretechnik - Cheatsheet.tex new file mode 100644 index 0000000..8d80be6 --- /dev/null +++ b/Softwaretechnik - Cheatsheet.tex @@ -0,0 +1,4385 @@ +\documentclass[a4paper]{article} +\usepackage[ngerman]{babel} +\usepackage{multicol} +\usepackage{calc} +\usepackage{ifthen} +\usepackage[landscape,left=1cm,top=1cm,right=1cm,nohead,nofoot]{geometry} +\usepackage{amsmath,amsthm,amsfonts,amssymb} +\usepackage{color,graphicx,overpic} +\usepackage{listings} +\usepackage[compact]{titlesec} %less space for headers +\usepackage{mdwlist} %less space for lists +\usepackage[utf8]{inputenc} +\usepackage{tikz} +\usepackage{pdflscape} +\usepackage{verbatim} +\usetikzlibrary{mindmap, arrows,shapes,positioning,shadows,trees} +\tikzstyle{every node}=[draw=black,thin,anchor=west, minimum height=2em] +\usepackage[hidelinks,pdfencoding=auto]{hyperref} + +\pdfinfo{ + /Title (Softwaretechnik - Cheatsheet) + /Creator (TeX) + /Producer (pdfTeX 1.40.0) + /Author (Robert Jeutter) + /Subject () +} +% Information boxes +\newcommand*{\info}[4][16.3]{ + \node [ annotation, #3, scale=0.65, text width = #1em, inner sep = 2mm ] at (#2) { + \list{$\bullet$}{\topsep=0pt\itemsep=0pt\parsep=0pt + \parskip=0pt\labelwidth=8pt\leftmargin=8pt + \itemindent=0pt\labelsep=2pt} + #4 + \endlist + }; +} + +% This sets page margins to .5 inch if using letter paper, and to 1cm +% if using A4 paper. (This probably isn't strictly necessary.) +% If using another size paper, use default 1cm margins. +\ifthenelse{\lengthtest { \paperwidth = 11in}} + { \geometry{top=.5in,left=.5in,right=.5in,bottom=.5in} } + {\ifthenelse{ \lengthtest{ \paperwidth = 297mm}} + {\geometry{top=1cm,left=1cm,right=1cm,bottom=1cm} } + {\geometry{top=1cm,left=1cm,right=1cm,bottom=1cm} } + } + +% Redefine section commands to use less space +\makeatletter +\renewcommand{\section}{\@startsection{section}{1}{0mm}% + {-1ex plus -.5ex minus -.2ex}% + {0.5ex plus .2ex}%x + {\normalfont\large\bfseries}} +\renewcommand{\subsection}{\@startsection{subsection}{2}{0mm}% + {-1explus -.5ex minus -.2ex}% + {0.5ex plus .2ex}% + {\normalfont\normalsize\bfseries}} +\renewcommand{\subsubsection}{\@startsection{subsubsection}{3}{0mm}% + {-1ex plus -.5ex minus -.2ex}% + {1ex plus .2ex}% + {\normalfont\small\bfseries}} +\makeatother + +% Define BibTeX command +\def\BibTeX{{\rm B\kern-.05em{\sc i\kern-.025em b}\kern-.08em + T\kern-.1667em\lower.7ex\hbox{E}\kern-.125emX}} + +% Don't print section numbers +\setcounter{secnumdepth}{0} + +\setlength{\parindent}{0pt} +\setlength{\parskip}{0pt plus 0.5ex} +% compress space +\setlength\abovedisplayskip{0pt} +\setlength{\parskip}{0pt} +\setlength{\parsep}{0pt} +\setlength{\topskip}{0pt} +\setlength{\topsep}{0pt} +\setlength{\partopsep}{0pt} +\linespread{0.5} +\titlespacing{\section}{0pt}{*0}{*0} +\titlespacing{\subsection}{0pt}{*0}{*0} +\titlespacing{\subsubsection}{0pt}{*0}{*0} + +%Tikz global setting +\tikzset{ + topic/.style={ + text centered, + text width=5cm, + level distance=1mm, + sibling distance=5mm, + rounded corners=2pt + }, + subtopic/.style={ + yshift=1.5cm, + text centered, + text width=3cm, + rounded corners=2pt, + fill=gray!10 + }, + theme/.style={ + grow=down, + xshift=-0.6cm, + text centered, + text width=3cm, + edge from parent path={(\tikzparentnode.205) |\item (\tikzchildnode.west)} + }, + description/.style={ + grow=down, + xshift=-0.5cm, + right, + text centered, + edge from parent path={(\tikzparentnode.200) |\item (\tikzchildnode.west)} + }, + level 1/.style={sibling distance=5.5cm}, + level 1/.append style={level distance=2.5cm}, +} + +% Turn off header and footer +\pagestyle{empty} +\begin{document} + +\raggedright +\begin{multicols}{3}\scriptsize + % multicol parameters + % These lengths are set only within the two main columns + %\setlength{\columnseprule}{0.25pt} + \setlength{\premulticols}{1pt} + \setlength{\postmulticols}{1pt} + \setlength{\multicolsep}{1pt} + \setlength{\columnsep}{2pt} + + Gute Software ist schwer herzustellen + \begin{itemize*} + \item Entspricht Kundenwünsche, Vollständigkeit + \item Funktioniert Korrekt + \item Kosten- und Termintreue bei der Erstellung + \item weitere nicht-funktionale Qualitätsforderungen + \begin{itemize*} + \item Benutzerfreundlichkeit, Ergonomie + \item Sicherheit + \item Zuverlässigkeit, Fehlertoleranz + \item Performanz + \item Ressourcen-Effizienz, Skalierbarkeit, Übertragbarkeit + \item Wartbarkeit, Änder- und Erweiterbarkeit + \end{itemize*} + \end{itemize*} + + Softwaretechnik + \begin{itemize*} + \item Technische Disziplin der Software Herstellung + \item Zielorientierte Bereitstellung uns systematische Verwendung von Prinzipien, Methoden und Werkzeugen für die arbeitsteilige, ingenieurmäßige Entwicklung und Anwendung von umfangreichen Softwaresystemen [Balzert] + \end{itemize*} + + Wie kann man Software besser entwickeln? + \begin{itemize*} + \item Ingenieursmäßige Herangehensweise + \begin{itemize*} + \item Verwendung bekannter Prinzipien und Methoden + \item Systematische Vorgehensweise + \end{itemize*} + \item Verwendung von: + \begin{itemize*} + \item Abstraktion, Modelle, Notation, Simulation + \item Wiederverwendung:Muster, Komponenten, Framework + \end{itemize*} + \item Organisation + \begin{itemize*} + \item Arbeitsteilung, Integration, Planung + \end{itemize*} + \item Verwendung von Werkzeugen + \begin{itemize*} + \item IDE (Integrated Development Environment) + \item Versionierung, Bugtracker, Modellierungswerkzeug + \end{itemize*} + \end{itemize*} + + \section{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 + + \begin{itemize*} + \item erstellen einer Abstraktion + \item abbilden signifikanter Eigenschaften + \item Deskriptiv/präskriptiv (real oder geplant) + \item Sichtweise auf ein System (Struktur, Verhalten, Zustand,...) + \item heißt Weglassen + \item setzt Verstehen voraus + \item ist nicht automatisierbar + \end{itemize*} + + Verschiedene Modelle: + \begin{itemize*} + \item Analysemodell + \item Entwurfsmodell + \item Implementierung (-smodell) + \item Vorgehensmodell + \item Produktmodell + \item Dokumentation, Alternativen-Auswahl + \end{itemize*} + + Modelle für: + \begin{itemize*} + \item Sichten + \item Funktionen + \item Daten + \item Algorithmen + \item Systemumgebung + \item Dynamisches Verhalten + \item Objektorientierte Modelle + \end{itemize*} + + \subsection{Klassische Modelle} + \begin{itemize*} + \item Funktionen: + \begin{itemize*} + \item Funktionsbaum + \begin{itemize*} + \item Hierarchische Dekomosition der Fkt + \item nummerieren der Ebenen/Funktionen möglich + \item Bsp: Abonnement Verwaltung + \end{itemize*} + \item Blockschaltbild + \begin{itemize*} + \item eingebettetes System, HW/SW + \end{itemize*} + \end{itemize*} + \item Daten + \begin{itemize*} + \item Data Dictionary + \begin{itemize*} + \item Verzeichnis von Daten mit Strukturinformationen + \item Backus-Naur-Form, kontextfreie Grammatik + \end{itemize*} + \item Entity Relationship Diagram + \begin{itemize*} + \item Daten und ihre Beziehungen + \end{itemize*} + \end{itemize*} + \item Systemumgebung + \begin{itemize*} + \item Datenflussdiagramm + \begin{itemize*} + \item Fluss und Transformation von Daten zwischen Funktionen, Speichern und Schnittstellen + \item kein Kontrollfluss + \end{itemize*} + \end{itemize*} + \item Algorithmen + \begin{itemize*} + \item Entscheidungstabelle + \begin{itemize*} + \item Regelbasierte Beschreibung + \item Bedingung + \item Aktionen + \item Reduktionsregeln + \end{itemize*} + \item Pseudocode + \begin{itemize*} + \item von Programmiersprache abstrahierende, detaillierte Beschreibung eines Algorithmus + \end{itemize*} + \item Programmablaufplan + \begin{itemize*} + \item Grafische Beschreibung des Kontrollflusses + \item DIN 66001 + \item Unstrukturiert + \end{itemize*} + \item Struktogramm + \begin{itemize*} + \item Nassi-Shneidermann-Diagramm + \item keine Sprünge + \end{itemize*} + \end{itemize*} + \item Dynamisches Verhalten (diskrete Zustände und atomare zustandübergänge) + \begin{itemize*} + \item Zustandsautomat + \begin{itemize*} + \item Verhalten mit Zuständen und -übergängen + \item Automatenmodelle und -theorie + \item Ggf zerlegung oder kommunizierende Automaten + \end{itemize*} + \item Flow-Chart + \item Ereignisgesteuerte Prozesskette (EPK) + \begin{itemize*} + \item Geschäftsprozesse + \item BPM + \end{itemize*} + \item Petri-Netz (ggf. mit Zeitmodell) + \begin{itemize*} + \item Grafische Beschreibung von Nebenläufigkeit und Synchronisation + \end{itemize*} + \end{itemize*} + \item Objektorientierte Modelle + \begin{itemize*} + \item Klassendiagramme + \item UML + \end{itemize*} + \end{itemize*} + + + \subsection{Objektorientierung} + \begin{itemize*} + \item bessere Strukturierung für komplexe Zusammenhänge + \item Abstraktere Sichtweise + \item Grundprinzip: Zerlegung; Teile und Herrsche + \item ein System besteht aus vielen Objekten + \item ein Objekt hat + \begin{itemize*} + \item definiertes Verhalten + \begin{itemize*} + \item Menge genau definierter Operationen + \item Operation wird beim Empfang einer Nachricht ausgeführt + \end{itemize*} + \item inneren Zustand + \begin{itemize*} + \item Zustand des Objekts ist Privatsache + \item Resultat einer Operation hängt vom aktuellen Zustand ab + \end{itemize*} + \item eindeutige Identität + \begin{itemize*} + \item Identität ist unabhängig von anderen Eigenschaften + \item Mehrere verschiedene Objekte mit identischem Verhalten und identischem inneren Zustand im gleichen System möglich + \end{itemize*} + \end{itemize*} + \item Klasse + \begin{itemize*} + \item Gleichartige Objekte mit ggf. verschiedenen Zuständen + \item Verhaltensschema - Operationen + \item Innere Struktur - Attribute + \end{itemize*} + \end{itemize*} + + Vorteile der Objektorientierung + \begin{itemize*} + \item Zuständigkeitsbereiche + \begin{itemize*} + \item Daten, Operationen und Zustand: lokal und gekapselt + \end{itemize*} + \item Klare Schnittstellen + \begin{itemize*} + \item Definiertes Objektverhalten, Nachrichten + \end{itemize*} + \item Hierarchie + \begin{itemize*} + \item Vererbung und Polymorphie (Spezialisierung), Klassenschachtelung + \end{itemize*} + \item Baukastenprinzip + \begin{itemize*} + \item Benutzung vorgefertigter Klassenbibliotheken, Anpassung durch Spezialisierung (mittels Vererbung) + \end{itemize*} + \end{itemize*} + + + \subsection{Unified Modeling Language} + \begin{itemize*} + \item Grafisches Beschreibungsmittel für Aspekte des Softwareentwurfs diskreter Systeme + \item Spezifikation, Entwurf, Visualisierung, Konstruktion, Dokumentation von Software + \item Für OO-Softwareentwicklung und -prozess geeignet + \item UML ist weder Methode noch Prozess + \end{itemize*} + + Warum UML? + \begin{itemize*} + \item Objektorientierung ist zur Zeit das vorherrschende Modellierungs-Paradigma, Industrie-Standard + \item Kombination von Struktur-, Verhaltens-, Interaktions-, und Verteilungsmodellen + \item Für Analyse, Entwurf, Implementierung und Test einsetzbar + \item Gute Werkzeugunterstützung für Editieren, Versionierung, Codegenerierung + \item Erweiterbarkeit der UML mit Stereotypen und Tags + \item Semi-formale Modelle, z.T. verschiedene Interpretationen + \item Offenheit: Erweiterung mit stereotypes, tags, constraints + \end{itemize*} + + Nachteile UML + \begin{itemize*} + \item UML ist in vielen Facetten nicht präzise festgelegt + \item Werkzeuge für Transformation, Analyse etc. fehlen noch + \item UML ist keine „kleine Sprache“: Lernaufwand notwendig + \item Komponenten sind nicht adäquat darstellbar + \item Sprachen wie die UML werden erlernt durch Übung! + \item Aber: LV SWT ist kein kompletter UML-Kurs + \end{itemize*} + + \paragraph{Überblick über Modelle} + \begin{itemize*} + \item 14 Diagrammarten + \item Struktur-Diagramme + \begin{itemize*} + \item Klassen-, Objekt-, Komponenten-, Kompositions-Struktur-, + \item Paket- und Verteilungsdiagramm + \item Profildiagramm - zur UML-Erweiterung + \end{itemize*} + \item Verhaltens-Diagramme + \begin{itemize*} + \item Use-Case-, Aktivitäts- und Zustandsdiagramms + \item Interaktionsdiagramme: Sequenz-, Kommunikations-, Timing- und Interaktionsübersichts-Diagramm + \end{itemize*} + \end{itemize*} + + \paragraph{Use-Case-Diagramm} + \begin{itemize*} + \item Beschreiben Systemfunktion aus Benutzersicht (Was, nicht Wie) + \item Erste Anforderungsspezifikation (requirements) + \item Planbare Einheiten als Inkremente für die Entwicklung + \item Keine Modellierung eines Ablaufs! + \item Erstellen von Testfällen (test case generation) + \item Grundelemente + \begin{itemize*} + \item Anwendungsfall: Use Case + \item Beteiligte: Aktor + \end{itemize*} + \item Verfeinerung mittels Use-Case-Realisierung notwendig + \begin{itemize*} + \item Textuelle Beschreibung + \item Verhaltensdiagramme + \end{itemize*} + \end{itemize*} + + \paragraph{Klassendiagramm} + \begin{itemize*} + \item Modellierung der Struktur (Aufbau) eines Systems + \item Modellierung von statischen Aspekten + \item Modellierung der Struktur von Daten + \item Klasse im Mittelpunkt + \begin{itemize*} + \item Aufbau: Attribute, Operationen + \item Beziehungen zueinander: Assoziationen, Vererbung + \end{itemize*} + \item Verbreitetstes und bekanntestes Diagramm der UML + \end{itemize*} + + \paragraph{Objektdiagramm} + \begin{itemize*} + \item Struktur des Systems zur Laufzeit zu einem Zeitpunkt + \item Tatsächliche Zusammenhänge und Belegungen von Attributen von Objekten zu einem Zeitpunkt + \item Eine detaillierte Sicht auf einen Aspekt + \begin{itemize*} + \item Keine vollständige Beschreibung (zu komplex) + \item Für kompliziertere Abhängigkeiten (z.B. Rekursion) + \end{itemize*} + \item Objektdiagramm für alle Arten von Exemplaren + \begin{itemize*} + \item z.B.: Klasse (Objekt), Komponente, Knoten, ... + \end{itemize*} + \item Keine Exemplare von Operationen -> Ablauf -> Verhaltensdiagramme / Interaktionsdiagramme + \item Kein Verlauf der Wertebelegung über die Zeit + \end{itemize*} + + \paragraph{Paketdiagramm} + \begin{itemize*} + \item Gliederung (Strukturierung) des Systems in Teile (Pakete) + \item Zuordnung von Elementen zu einem Paket + \item Bildung von Hierarchien (Enthält-Beziehung) + \item Abhängigkeiten zwischen den Paketen + \begin{itemize*} + \item "Include" von Quellcode-Dateien (<>) + \end{itemize*} + \item Anwendung: + \begin{itemize*} + \item Zum Grobentwurf von Systemen + \item Definition von Schichten + \end{itemize*} + \end{itemize*} + + \paragraph{Komponentendiagramm} + \begin{itemize*} + \item Strukturierung des Systems durch Komponenten + \item Komponente: Modulare, austauschbare Einheit (Substitution) + \item Modellierung der Abhängigkeiten zwischen Komponenten + \item Modellierung der inneren Struktur von Komponenten + \item Definition von Schnittstellen + \end{itemize*} + + \paragraph{Kompositionsstrukturdiagramm} + \begin{itemize*} + \item Teile-Ganzes-Strukturen -> Kompositionsstruktur + \item Strukturell statische Kompositionsstrukturen: + \begin{itemize*} + \item Kurzschreibweise bei vielen Kompositionen + \item Modellierung des Aufbaus komplexer Systeme + \end{itemize*} + \item Strukturell dynamische Kompositionsstrukturen: + \begin{itemize*} + \item Notwendige Strukturen zur Realisierung eines Verhaltens + \item Definition von Rollen, zur Lösung wiederkehrender Probleme -> Modellierung von Mustern + \end{itemize*} + \item Starke Verwandtschaft mit dem Klassendiagramm + \item Spezialisierte Kompositionsbeziehung -> erweiterte Semantik + \end{itemize*} + + \paragraph{Aktivitätsdiagramm} + \begin{itemize*} + \item Modellierung von + \begin{itemize*} + \item Kontrollflüssen + \item Datenflüssen + \item Parallelem Verhalten + \item Verzweigungen, bedingten und gewichteten Abläufen + \end{itemize*} + \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 + \item anderen Aktionen und Aktivitäten + \end{itemize*} + \end{itemize*} + + \paragraph{Interaktionsdiagramme} + \begin{itemize*} + \item Modellierung von + \begin{itemize*} + \item Kommunikation zwischen Kommunikationspartnern (Lebenslinie) + \item Operationen (Modellierung eines Programms) + \item Informationsaustausch / Nachrichten + \end{itemize*} + \item Gemeinsames Grundkonzept der Interaktionsdiagramme + \item Sehr detaillierte Diagramme + \begin{itemize*} + \item Meist nicht zur vollständigen Beschreibung eines Systems + \item Betrachtung eines wichtigen Teilaspekts + \end{itemize*} + \item Grundlage zur Codegenerierung + \end{itemize*} + + \paragraph{Sequenzdiagramm} + \begin{itemize*} + \item Genaue zeitliche Abfolge von Nachrichten + \item Umfangreichstes Interaktionsdiagramm + \item Kontrollelemente möglich (Schleifen, Verzweigungen) + \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 + \end{itemize*} + + \paragraph{Timing-Diagramm} + \begin{itemize*} + \item Genaue zeitliche Darstellung von Zustandsübergängen + \item Kommunikation abhängiger Zustandsautomaten + \item Modellierung einzelner Interaktion + \end{itemize*} + + \paragraph{Prinzipieller Aufbau} + \begin{itemize*} + \item Zeitlicher Verlauf senkrecht + \item Kommunikationspartner waagerecht (unsortiert) + \item Lebenslinie + \begin{itemize*} + \item Rechteck mit gestrichelter senkrechter Linie + \item Start, Ende und Dauer der Ausführung einer Operation + \item Rekursive Aufrufe möglich + \end{itemize*} + \item Ereignisspezifikation + \begin{itemize*} + \item Stelle des Sendens / Empfangens der Nachricht + \item Definition der Reihenfolge des Auftretens + \item Trace: Folge von Sende- und Empfangsereignissen + \end{itemize*} + \end{itemize*} + + \paragraph{Weitere Elemente des Sequenzdiagramms} + \begin{itemize*} + \item Nachrichten ohne Sender + \begin{itemize*} + \item z.B. am Beginn einer Interaktion + \end{itemize*} + \item Verlorene Nachrichten (ohne Empfänger) + \begin{itemize*} + \item Nachricht ohne dargestellten Empfänger + \item z. B. am Ende einer Interaktion + \end{itemize*} + \item Erzeugen von Lebenslinien + \begin{itemize*} + \item Gestrichelte Linie mit geöffnetem Pfeil + \item Keine Rückgabenachricht + \item Zeitliche Einrückung des Rechtecks + \end{itemize*} + \item Zerstören von Lebenslinien + \begin{itemize*} + \item Durchgezogene Linie mit Dreieckende + \item Kann Rückgabenachricht erzeugen + \end{itemize*} + \end{itemize*} + + \paragraph{Nachrichten in Interaktionsdiagrammen} + \begin{itemize*} + \item Ereignis des Sendens bzw. Empfangens von Nachrichten + \item Typen: + \begin{itemize*} + \item Operationsaufruf (synchron / asynchron) + \item Antwort Nachricht + \item Signal (asynchron), Create-/ Delete Message + \end{itemize*} + \item Operationsaufruf: Parameterliste muss kompatibel sein + \item Nachrichtentypen + \end{itemize*} + + \paragraph{Zustandsdiagramm} + \begin{itemize*} + \item Modellierung des (vollständigen?) Verhaltens + \begin{itemize*} + \item Zustände von Klassen / Objekten / Komponenten + \item Übergänge zwischen den Zuständen + \item Ereignisse, die Zustandswechsel auslösen + \end{itemize*} + \item Modellierung von endlichen Automaten (Zustandsmaschinen) + \begin{itemize*} + \item Deterministische + \item Nichtdeterministische + \end{itemize*} + \item Verfeinerung von Zuständen möglich + \item Modellierung von verteilten Systemen / parallelem Verhalten + \item Grundlage zur Codegenerierung + \end{itemize*} + + + \section{Analyse} + \begin{itemize*} + \item Einordnung in den Projektablauf + \item Was ist eine Anforderung? + \begin{itemize*} + \item Merkmal, Eigenschaft, Bedingung oder Einschränkung eines Systems + \item Notwendig für die Akzeptanz vom Kunden + \item Definition (IEEE 610.12-1990) + \begin{itemize*} + \item Dokumentierte Darstellung einer Fähigkeit oder Eigenschaft + \item von Anwender benötigt zur Problemlösung bzw. um Ziel zu erreichen + \item Muss von System oder Komponente erfüllt werden, um Vertrag oder Standard zu erfüllen + \end{itemize*} + \end{itemize*} + \end{itemize*} + + \begin{itemize*} + \item Funktionale Anforderungen - Was soll es tun? + \begin{itemize*} + \item „...Legt eine vom Softwaresystem oder einer seiner Komponenten bereitzustellende Funktion oder Service dar“ [Balzert] + \item Was leistet das System + \item Welche Funktionen bietet es + \item Wie interagiert es mit der Umgebung + \item Anforderungen an: + \begin{itemize*} + \item Verhalten + \item Struktur + \item (Alternativ: Statik, Dynamik, Logik) + \end{itemize*} + \end{itemize*} + \item Nichtfunktionale Anforderungen - Wie? + \begin{itemize*} + \item „...legen qualitative oder quantitative Eigenschaften des Softwareprojektes oder einer Komponente fest“ [Balzert] + \item Auch Bezeichnet als: + \begin{itemize*} + \item Quality of Service + \item Qualitätsanforderungen + \end{itemize*} + \item Arten - FURPS (ISO 9126): + \begin{itemize*} + \item Functionality (Funktionalität) + \item Usability (Benutzbarkeit) + \item Reliability (Zuverlässigkeit) + \item Performance (Effizienz) / Portability (Übertragbarkeit) + \item Supportability (Änderbarkeit/ Wartbarkeit) + \end{itemize*} + \end{itemize*} + \end{itemize*} + + \begin{itemize*} + \item Funktionalität + \begin{itemize*} + \item Angemessen, Genauigkeit + \item Sicherheit: Vertraulichkeit, Informationssicherheit, Datenintegrität, Verfügbarkeit + \item (Nicht ausreichend spezifizierte funktionale Anforderung) + \end{itemize*} + \item Benutzbarkeit + \begin{itemize*} + \item Verständlichkeit, Erlernbarkeit, Bedienbarkeit, Attraktivität + \end{itemize*} + \item Zuverlässigkeit + \begin{itemize*} + \item Reife (Fehler-Anzahl), Fehlertoleranz, Wiederherstellbarkeit + \end{itemize*} + \item Effizient/ Leistungsanforderungen + \begin{itemize*} + \item Zeitverhalten, Verbrauchsverhalten, Wirtschaftlichkeit + \end{itemize*} + \item Portabilität + \begin{itemize*} + \item Anpassbarkeit, Installierbarkeit, Koexistenz, Austauschbarkeit + \end{itemize*} + \item Wartbarkeit + \begin{itemize*} + \item Analysierbarkeit, Änder\item und Erweiterbarkeit, Stabilität (bei Änderungen), Testbarkeit + \end{itemize*} + \item Weitere: + \begin{itemize*} + \item Konformität zu Konventionen und Bestimmungen + \item Interoperabilität zu anderen Systemen + \item Implementierungsanforderungen + \item Schnittstellenanforderungen + \item Skalierbarkeit (Änderungen des Problemumfangs) + \item Betriebliche und rechtliche Rahmenbedingungen + \item Liefer\item und Verpackungsanforderungen + \end{itemize*} + \end{itemize*} + + \paragraph{Nichtfunktionale Anforderungen} + Schwierigkeit nichtfunktionaler Anforderungen + \begin{itemize*} + \item Hängen oft von Verhalten ab: daher komplex und nicht direkt sichtbar + \item „Das Auto hat vier Räder“ (Struktur) + \item „Wenn der Blinker betätigt wird, blinkt das Auto dreimal wenn die Zündung an ist; ansonsten wird das Standlicht einseitig eingeschaltet“ (Korrektes Verhalten) + \item „Das Motorsteuergerät darf innerhalb von 5 Jahren und 150.000km Laufleistung höchstens mit 0.1\% Wahrscheinlichkeit ausfallen“ (Zuverlässigkeit) + \end{itemize*} + + Umgang mit nichtfunktionalen Eigenschaften + \begin{itemize*} + \item Nicht direkt „by construction“ zu realisieren + \item Naive Herangehensweise: Ignorieren! + \begin{itemize*} + \item Entwerfen und Implementieren der Software ohne Berücksichtigung nichtfunktionaler Eigenschaften + \item Testen der nichtfunktionalen Eigenschaften + \item Wenn nicht erfüllt: Entwurf und Implementierung ändern! + \end{itemize*} + \item Funktioniert nur bei sehr einfachen Systemen, bzw. wenn nichtfunktionale Eigenschaften nicht wichtig sind! + \end{itemize*} + + Sinnvoller Umgang mit nichtfunktionalen Eigenschaften + \begin{itemize*} + \item Untersuchung der Projektrisiken bereits in der Analysephase + \begin{itemize*} + \item größte Risiken zuerst betrachten! + \item Immer fragen: Geht das so überhaupt? + \item Festlegungen des Entwurfs möglichst früh gegen Anforderungen prüfen - aber wie? + \end{itemize*} + \item Modellbasierter Entwurf + \begin{itemize*} + \item Modellierung des Systems und seiner Umwelt + \item Bewertung des Modells (Simulation) + \item Lehrveranstaltungen Systementwurf, KIS, LTS + \end{itemize*} + \end{itemize*} + + Randbedingungen + \begin{itemize*} + \item „... Eine Randbedingung ist eine organisatorische oder technologische Vorgabe, die die Art und Weise einschränkt, wie das betrachtete System realisiert werden kann.“ + \item Werden nicht umgesetzt + \item Schränken Lösungsraum ein + \item Beispiele: + \begin{itemize*} + \item Kosten + \item Durchlaufzeit: Time to Market + \item Vorgaben durch Marketing und Vertrieb + \item Technische Randbedingungen (nichtfunktionale Anforderung) + \end{itemize*} + \end{itemize*} + + %![Analysebaum von Sommerville](Assets/Softwaretechnik1_Analyseformen1.png) + %![Analysebaum von Sommerville](Assets/Softwaretechnik1_Analyseformen2.png) + + Geforderte (Meta-)Eigenschaften + \begin{itemize*} + \item Vollständig: alle Szenarien sind beschrieben + \item Konsistent: keine Widersprüche + \item Eindeutig: nur eine Interpretation möglich + \item Korrekt: genaue und richtige Darstellung + \item Realistisch: unter geg. Einschränkungen implementierbar + \item Überprüfbar: durch Tests am Endprodukt nachweisbar + \item Rückverfolgbar: Auswirkungen bis zur Implementierung nachvollziehbar (Testfälle, Auswirkung von Änderungen) + \item Klassifizierbar (Risiko, Priorität, Dringlichkeit, Nutzen ...) + \item Validierung mit dem Kunden + \end{itemize*} + + \begin{itemize*} + \item Requirements Engineering + \begin{itemize*} + \item Ermittlung, Analyse und Verwaltung von Anforderungen + \item Ausgangspunkt: Projektidee + \end{itemize*} + \item Anforderungsermittlung + \begin{itemize*} + \item requirements elicitation, requirements definition + \item Bestimmen und dokumentieren der Anforderungen an das geplante System + \item Beteiligt: Entwickler, Kunde, Benutzer + \item Ergebnis: Anforderungsspezifikation - Glossar, Vertrag, Lastenheft + \end{itemize*} + \item Anforderungs-Analyse + \begin{itemize*} + \item requirements analysis, system modeling + \item Beschreibung im Detail und formal strukturiert + \item Beteiligt: Entwickler + \item Ergebnis: funktionale Spezifikation - Produktdefinition, Analysemodell, Pflichtenheft + \end{itemize*} + \end{itemize*} + + %![Anforderungsentwicklung von Balzert](Assets/Softwaretechnik1_Anforderungsentwicklung.png) + + %| | Anforderungsermittlung | Systemmodellierung | + %| -\item | -\item | -\item | + %| 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: + \begin{itemize*} + \item Falsche Anforderungen führen zu falschem System + \item Frühe Fehler im Entwicklungsprozess sind teuer! + \end{itemize*} + + Fehlerentstehung und Fehlerquellen bei Anforderungserfassung + \begin{itemize*} + \item 83\% sprachliche Fehler (Un- bzw. Missverständlich) + \item 75\% Logische Fehler (Widersprüchlichkeit, Redundanz) + \item 73\% Inhaltliche Fehler (Falsche Sachverhalte, Unvollständig) + \end{itemize*} + + \subsection{Ermiteln von Anforderungen} + Woher kommen Anforderungen? + \begin{itemize*} + \item Ausgangspunkt + \begin{itemize*} + \item Projektidee, schriftliche Skizze + \item Kurz und knapp + \item Stichpunkte der wichtigsten Funktionen + \item Lastenheft (falls schon existiert) + \end{itemize*} + \item Interessenhalter (stakeholder) + \begin{itemize*} + \item Identifizieren, Wichtigkeit bewerten (berücksichtigen?) + \item Ansprechpartner? Interessen und Erwartungen + \item Fachexperten, Verantwortliche, Betroffene + \end{itemize*} + \end{itemize*} + + Beteiligte Rollen + \begin{itemize*} + \item Endbenutzer + \begin{itemize*} + \item Aufnahme Ist-Zustand, Domänenwissen, Anforderungen + \end{itemize*} + \item Kunde + \begin{itemize*} + \item Definiert Ziel des Systems, Vertragsverhandlung + \end{itemize*} + \item Konfigurationsmanager + \begin{itemize*} + \item Revisionsgeschichte der Dokumente, Nachvollziehbarkeit + \end{itemize*} + \item Architekt + \begin{itemize*} + \item Integration von Anwendungsfall- und Objektmodellen + \end{itemize*} + \item Analytiker + \begin{itemize*} + \item Modelliert das System und erstellt Anwendungsfälle + \end{itemize*} + \item Redakteur + \item Prüfer + \end{itemize*} + + Wie ermittelt man Anforderungen? + \begin{itemize*} + \item Problem: Entwickler müssen sich in Begriffs- und Denkwelt des Kunden einarbeiten, sonst Kommunikationsprobleme + \item Systematische Vorgehensweise + \item Kommunikation mit Kunden + \item Geschäftsprozess (business process) + \begin{itemize*} + \item fachlicher Ablauf, der Wert oder Kosten verursacht + \end{itemize*} + \item Akteur (actor) + \begin{itemize*} + \item Benutzer, Schnittstelle nach außen + \end{itemize*} + \item Szenario (scenario) + \begin{itemize*} + \item Interaktion mit System als Ablauf + \end{itemize*} + \item Anwendungsfall (use case) + \begin{itemize*} + \item Automatisierter Arbeitsschritt, vom System ausgeführt + \end{itemize*} + \item Interviews mit Fachanwendern + \begin{itemize*} + \item Mitschrift, später strukturierter Text und Tabelle + \end{itemize*} + \item Strukturierte Spezifikation + \begin{itemize*} + \item Vorlagen / sprachliche Anforderungsschablonen + \item Formulare + \item Reduzierung sprachlicher Mehrdeutigkeiten + \end{itemize*} + \item Anwendungsfalldiagramm (Use-Case-Diagramm) + \begin{itemize*} + \item Arbeitsschritt eines Geschäftsprozesses, der durch das System ausgeführt wird + \item Anforderungen an das System modellieren - was soll das System leisten + \item Systemgrenzen / Systemkontext festlegen + \item Systembeteiligte modellieren + \item Planbare Einheiten als Schritte für die Entwicklung + \item Verwendung bereits ab Projektbeginn + \item Keine Modellierung eines Ablaufs! + \end{itemize*} + \item Umgang mit Szenarien und Anwendungsfällen + \begin{itemize*} + \item Zunächst nur zum Verständnis kurz aufstellen + \item Systemgrenze definieren + \item Beschreibungen verfeinern + \item Änderungen mit Kunden abstimmen + \item Prototypen nur zur visuellen Unterstützung + \item Benutzungsschnittstelle erst beginnen, wenn funktionale Anforderungen in etwa klar sind + \end{itemize*} + \end{itemize*} + + Leitfaden für Anwendungsfälle + \begin{itemize*} + \item Benennen mit Verbalphrasen, die Anwendersicht beschreiben (Simuliere) + \item Akteure mit Substantiven benennen (Anwender) + \item Systemgrenzen klären. Arbeitsschritte von Akteuren und System kennzeichnen + \item Schritte im aktiven Stil beschreiben (Auto bremst) + \item Ursächliche Beziehung zwischen Folgeschritten + \item 1 Anwendungsfall = 1 vollständige Transaktion + \item Normalfall darstellen; Ausnahmen gesondert beschreiben + \item Nicht die Benutzungsschnittstelle beschreiben (statt dessen visuellen Prototypen verwenden) + \item Übersichtlichkeit (max. 2-3 Seiten), sonst zerlegen + \end{itemize*} + + \begin{itemize*} + \item Typische Probleme + \begin{itemize*} + \item Kommunikations- und Verständnisprobleme + \item Viele verschiedene Beteiligte + \item Kunden wissen nicht, was sie genau wollen und was geht + \item Verwendung von Fachsprachen + \item Widersprüchliche Anforderungen, verschiedene Interessen + \item Nicht-technische organisatorische, historische oder rechtliche Rahmenbedingungen + \item Zusätzliche Beteiligte können auftauchen + \item Anforderungen ändern sich während der Entwicklung + \end{itemize*} + \item Anforderungsänderungen + \begin{itemize*} + \item Sind die Regel + \end{itemize*} + \item Tätigkeiten der Anforderungsanalyse + \begin{itemize*} + \item Anforderungen strukturieren + \item Eigenschaften der Anforderungen bestimmen + \item Anforderungen priorisieren + \item Anforderungen in Textform, Grafiken, Modellen dokumentieren + \item Anforderungen modellieren + \item Anforderungen auf inhaltliche Qualität prüfen + \item Auf Übereinstimmung mit den Zielen prüfen + \begin{itemize*} + \item Ziel Abnahme der Anforderung + \end{itemize*} + \item Hängt mit Analyse des Systems zusammen + \end{itemize*} + \item Anforderungen strukturieren + \begin{itemize*} + \item Unterteilung + \begin{itemize*} + \item Funktional, Nichtfunktional + \item Muss, Kann,... oder Haupt- und Nebenanforderung + \end{itemize*} + \item Hierarchische Zerlegung + \begin{itemize*} + \item Unterteilen, Verfeinern + \end{itemize*} + \item Ordnung festlegen, eindeutig Nummerieren + \begin{itemize*} + \item auf Einmaligkeit achten + \end{itemize*} + \item Beziehungen festhalten + \item Verwendung von Werkzeugen + \begin{itemize*} + \item MS-Project, Doors, Git issues, Trac, Bugzilla, MKS,... + \item Modellierungswerkzeuge + \end{itemize*} + \end{itemize*} + \item Eigenschaften bestimmen + \begin{itemize*} + \item Wahl der Eigenschaften firmen- bzw. projektspezifisch + \item Wichtige Eigenschaften + \begin{itemize*} + \item Identifikationsnummer + \item Kurzbezeichnung + \item Beschreibung (Text, ggf. Grafik, Modell) + \item Aufwand + \item Priorität der Anforderung + \item Bearbeitungsstatus / Restaufwand + \item Zugeordnet (wer ist verantwortlich / bearbeitet) + \item Querverbindungen zu anderen Anforderungen + \item Ggf. zusätzliche Dokumente oder Bemerkungen + \item Stabilität der Anforderung (Änderungswkt.) + \item Kritikalität der Anforderung: Schäden bei Fehlern? + \item Entwicklungsrisiko: Erfolgsaussichten der Umsetzung + \item Abnahmekriterien / Erfüllungsnachweis durch? + \item Anforderungstyp: Funktional, nicht funktional ,... + \item Anforderungssicht: Dynamik, Statik, Logik, Struktur, Funktion + \item Mögliche Konflikte + \item Autor + \item Quelle: Wer möchte die Anforderung umgesetzt haben? + \item Status der Beschreibung: Idee, grober Inhalt, detailliert + \item Anforderungsversion + \end{itemize*} + \end{itemize*} + \item Anforderungen priorisieren + \begin{itemize*} + \item MuSCoW-Priorisierung + \item Muss-, Kann-, Optional, Nicht (Abgrenzungskriterien) (must, should, could, won‘t) + \item Ad-hoc: Stakeholder priorisiert Anforderungen + \item Priorisierungsmatrix / Kosten-Wert-Analyse + \begin{itemize*} + \item Eigenschaften bewerten (Punkte vergeben) + \item Werte gewichten + \item Priorität berechnen $\text{Prioritäten} = \frac{\text{Nutzen} - \text{Nachteil}}{\text{Kosten} + \text{Risiko}}$ + \end{itemize*} + \item Kano-Klassifikation + \begin{itemize*} + \item Basiseigenschaften: Werden vorausgesetzt (fehlen stört, wenig zusätzliche Zufriedenheit) + \item Leistungseigenschaften: Sonderwünsche + \item Begeisterungseigenschaften: Wird nicht erwartet + \item Abfragen per Fragenkatalog + \end{itemize*} + \item Reihenfolge festlegen + \end{itemize*} + \end{itemize*} + + + %![Kano Klassifikation von Balzert](Assets/Softwaretechnik1_Kano1.png) + %![Kano Klassifikation von Balzert](Assets/Softwaretechnik1_Kano2.png) + + \subsection{Objektorientierte Analyse und Systemmodellierung} + \begin{itemize*} + \item Übersicht + \begin{itemize*} + \item Aufgabe: Systemmodell erstellen, funktionale Spezifikation + \item Beschreibung der Systembenutzung und des Verhaltens + \item Was, nicht wie - Implementierungsaspekte ausklammern + \begin{itemize*} + \item Nicht: Datenhaltung, Verteilung, Technologien, Architektur, .. + \end{itemize*} + \item Zusammenhang mit Anforderungsspezifikation + \item OO: Modell des Anwendungsbereichs + \end{itemize*} + \item Analysemodell + \begin{itemize*} + \item Korrekt, vollständig, konsistent und nachprüfbar + \item Struktur und Verhalten + \item Verschiedene Sichten (OO, Strukturiert, ...) + \end{itemize*} + \item Eingangsdokumente + \begin{itemize*} + \item Lastenheft, Anforderungsspezifikation + \end{itemize*} + \item Typische Ergebnisse + \begin{itemize*} + \item Funktionales Modell + \begin{itemize*} + \item Geschäftsprozesse und Anwendungsfälle + \end{itemize*} + \item Objektmodell + \item Dynamisches Modell - Systemverhalten + \begin{itemize*} + \item Zustands- und Sequenzdiagramme + \end{itemize*} + \item Vor- und Nachbedingungen von Systemoperationen + \item Prototyp / Spezifikation Benutzungsschnittstelle + \item Pflichtenheft + \end{itemize*} + \item Objektorientierte Analyse nach [Brügge / Dutoit] + \begin{itemize*} + \item Verdeutlicht iterativen Ablauf + \item Unterteilung des Analysemodells in: + \begin{itemize*} + \item Funktionales Modell (Anwendungsfälle) + \item Objektmodell (Klassen und Objektdiagramme) + \item Dynamisches Modell (Zustands- und Sequenzdiagramme) + \item Unterscheidung der Objekttypen + \end{itemize*} + \end{itemize*} + \end{itemize*} + + %![Analyse nach Brügge/Dutoit](Assets/Softwaretechnik1_Bruegge1.png) + %![Analyse nach Brügge/Dutoit](Assets/Softwaretechnik1_Bruegge2.png) + + \begin{itemize*} + \item Heuristik Sprache $\rightarrow$ OO-Modell + \item Objektarten im Systemmodell + \begin{itemize*} + \item Entitätsobjekte - vom System verwaltete Informationen + \item Grenzobjekte - Interaktion zwischen System und Akteuren + \item Steuerungsobjekte - Durchführung der Anwendungsfälle + \end{itemize*} + \item Identifizierung von Entitätsobjekten + \begin{itemize*} + \item Begriffe, die klargestellt werden müssen + \item Wiederkehrende Substantive in Anwendungsfällen + \begin{itemize*} + \item Heuristiken + \end{itemize*} + \item Reale Objekte, die das System kennen muss + \item Reale Prozesse, die das System verfolgen muss + \item Anwendungsfälle + \item Datenquellen und -senken + \item Artefakte, mit denen der Nutzer interagiert + \end{itemize*} + \item Identifizierung von Grenzobjekten + \begin{itemize*} + \item Elemente der Benutzungsschnittstelle + \item Formulare für Eingaben + \item Nachrichten, Rückmeldungen + \item Endgeräte + \item In der Begriffswelt des Anwenders bleiben! + \item Schnittstellen grafisch skizzieren bzw. Prototyp! + \end{itemize*} + \item Identifizierung von Steuerungsobjekten + \begin{itemize*} + \item Koordination von Grenz- und Entitätsobjekten + \item Abarbeitung von Anwendungsfällen + \begin{itemize*} + \item Reihenfolge von Schritten + \item Informationen übernehmen und weiterleiten + \item Oft ein Steuerungsobjekt pro Anwendungsfall + \end{itemize*} + \item Beispiel: Simulationsszenario + \item Verhaltensmodell sinnvoll! Im folgenden: dynamische Modelle + \end{itemize*} + \end{itemize*} + + \begin{itemize*} + \item Abläufe der Anwendungsfälle modellieren + \begin{itemize*} + \item Ziel - Objekte finden + \item Klassen identifizieren + \item Verhalten / Operationen finden + \end{itemize*} + \item Use Case durch Interaktion verfeinern + \begin{itemize*} + \item einfacher kurzer Ablauf: textuelle Beschreibung, Aktivitätsdiagramm + \item Ablauf mit Verzweigungen, Parallelitäten: Aktivitätsdiagramm (Kontrollflussmodellierung) + \item datengetriebener Ablauf: Aktivitätsdiagramm (Objektflussmodellierung) + \item Interaktion zwischen den Objekten wichtig: Kommunikationsdiagramm, Aktivitätsdiagramm (Aktivitätsbereiche), Sequenzdiagramm + \item zeitliche Abfolge steht im Mittelpunkt: Sequenzdiagramm + \item Zustandswechsel / zeitliche Abfolge von Zuständen: Zustandsdiagramm / Timing-Diagramm + \item komplexe Abläufe mit Verzweigungen und Parallelitäten: Interaktionsübersichtsdiagramm + \item komplexe Abläufe ohne Verzweigungen und Parallelitäten: weitere Verfeinerung durch Use-Case-Diagramm + \item komplexer strukturierter Ablauf: Kollaboration aus dem Kompositionsstrukturdiagramm + \end{itemize*} + \end{itemize*} + + Dynamische UML-Modelle + \begin{itemize*} + \item Abläufe + \begin{itemize*} + \item Aktivitätsdiagramm (activity diagram) + \item Kommunikationsdiagramm (communication diagram) + \item Sequenzdiagram (sequence diagram) + \item Zeitdiagramm (timing diagram) + \end{itemize*} + \item Zustandsabhängiges Verhalten von Objekten + \begin{itemize*} + \item Zustandsautomat (state chart diagram) + \end{itemize*} + \end{itemize*} + + \begin{itemize*} + \item Aktivitätsdiagramm + \begin{itemize*} + \item Aktion - einzelner Schritt + \item Aktivität + \begin{itemize*} + \item Beschreibt einen Ablauf / repräsentiert ein Verhalten + \begin{itemize*} + \item Beinhaltet eine Folge Aktionen, Kontroll- oder Objektknoten + \end{itemize*} + \item Schachtelung von Aktivitäten und Aktionen + \begin{itemize*} + \item Aktionen in Aktivitäten enthalten + \item Aktionen durch Aktivitäten verfeinerbar + \end{itemize*} + \item Aktivitäten beschreiben / verfeinern + \begin{itemize*} + \item Aktionen, Use Cases, Interaktionen, Operationen ... + \end{itemize*} + \item Ein- und Ausgabeparameter in Form von Objekten + \begin{itemize*} + \item Parameterknoten entsprechend Pins der aufrufenden Aktion + \item Alternativ: Parameterangabe mit Name und Typ + \end{itemize*} + \item Angabe von Vor- und Nachbedingungen möglich + \item Optional: Parameter unter Aktivitätsnamen + \end{itemize*} + \end{itemize*} + \end{itemize*} + + \begin{itemize*} + \item Verfeinerung der Aktionen durch Aktivitäten + \item Aktion durch Interaktionen verfeinern + \begin{itemize*} + \item Detaillierte Diagramme + \item Meist entwurfsnah + \end{itemize*} + \item Verfeinerung der Aktionen durch StateChart + \item Objekte zusammenstellen und klassifizieren + \begin{itemize*} + \item Toolunterstützung (Möglichkeiten stark toolabhängig) + \item Objekte Ergebnis der Verhaltensmodellierung + \item Ergebnis Verhaltensdiagramm: Operationen der Klassen + \item Klassen generalisieren / spezialisieren $\rightarrow$ Klassenhierarchie + \end{itemize*} + \item Übergang zum Entwurf + \begin{itemize*} + \item Klassenstruktur festlegen + \end{itemize*} + \item Spezifikation von Benutzungsschnittstellen + \begin{itemize*} + \item Skizzieren, Prototyp generieren, Spezialwerkzeuge + \item Klassen und Operationen in Funktionen + \item Gestaltung MMI, style guides, Standards + \end{itemize*} + \end{itemize*} + + \subsection{Dokumentation von Anforderungen} + \begin{itemize*} + \item Lastenheft + \begin{itemize*} + \item Gesamtheit der Forderungen eines Auftraggebers (AG) an die Lieferungen und Leistungen eines Auftragnehmers (AN), manchmal Vertragsbasis + \item Muss-Kriterien, Kann-Kriterien, Abgrenzungskriterien + \end{itemize*} + \item Pflichtenheft + \begin{itemize*} + \item Entwurf aus AN-Sicht, Umsetzung des Lastenhefts + \item Meist Vertragsbasis + \end{itemize*} + \item Inhalt Anforderungsspezifikation + \begin{itemize*} + \item Zielsetzung + \item Allgemeine Beschreibung + \begin{itemize*} + \item Umgebung, generelle Funktion, Restriktionen, Benutzer + \end{itemize*} + \item Spezifische funktionale Anforderungen + \begin{itemize*} + \item möglichst quantitativ (z.B. Tabellenform) + \item eindeutig identifizierbar (Nummern) + \end{itemize*} + \item Spezifische nicht-funktionale Anforderungen + \begin{itemize*} + \item z.B. Antwortzeit, Speicherbedarf, HW/SW-Plattform + \item Entwicklungs- und Produkt-Standards + \end{itemize*} + \item Qualitäts-Zielbestimmung + \item Zu erwartende Evolution des Systems, Versionen + \item Abkürzungsverzeichnis, Glossar, Index, Referenzen + \end{itemize*} + \end{itemize*} + + + Pflichtenheft (Beispiel) + \begin{enumerate} + \item Einleitung, Zielbestimmung + \item Übersicht + \begin{itemize*} + \item Einsatzbereich, Zielgruppen + \item Produkt-Umgebung + \item Produkt-Funktionen + \item Restriktionen + \item Annahmen und Abhängigkeiten + \item Vorhandenes System (ggf.) + \end{itemize*} + \item Vorgeschlagenes System + \begin{itemize*} + \item Übersicht + \item Funktionale Anforderungen + \item Benutzungsschnittstelle + \item Nichtfunktionale Anforderungen + \item Systembeschreibung + \begin{itemize*} + \item Szenarien + \item Anwendungsfälle + \end{itemize*} + \end{itemize*} + \item Glossar + \end{enumerate} + + + \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 -> 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 + \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? + \begin{itemize*} + \item Schnittstellen, Funktionen, „Verantwortung“ + \item Was bietet es an? + \item Was benutzt es? + \item Was tut es intern? + \end{itemize*} + + Operation + \begin{itemize*} + \item Name und Parameter + \item Funktion, Prozedur, Methode, Eintrittspunkt ... + \end{itemize*} + + Dienst: Satz von Operationen, die bereitgestellt werden + + Abhängigkeiten von Subsystemen + \begin{itemize*} + \item Subsysteme untereinander: Kopplung (coupling) + \item Maß für die Abhängigkeit von Subsystemen + \end{itemize*} + + Möglichst lose Kopplung + \begin{itemize*} + \item Änderungen in einem beteiligten Subsystem haben geringe Auswirkungen (Stabilität) + \item Erleichtert Wartbarkeit und Arbeitsteilung + \end{itemize*} + + Mittel zur Verringerung der Kopplung + \begin{itemize*} + \item Zusätzliche Unterteilung in Subsysteme + \item Aber: dann größere Komplexität! + \end{itemize*} + + Abhängigkeiten von Subsystemen + %| Kopplungsart | Bemerkung | + %| -\item | -\item | + %| Datenkopplung (gemeinsame Daten) | Möglichst vermeiden! Wenn nicht möglich, Verwaltung zentralisieren und Zugriff über Schnittstelle | + %| Schnittstellenkopplung (gegenseitiger Aufruf) | Akzeptabel | + %| Strukturkopplung (gemeinsame Strukturelemente) | Vermeiden! (z.B. keine Vererbung über Paketgrenzen hinweg) | + + \begin{itemize*} + \item Elemente eines Subsystems: Kohäsion (cohesion) + \item Maß für Zusammengehörigkeit der Elemente + \item Möglichst hohe Kohäsion + \begin{itemize*} + \item Enge Beziehung oder ähnliche Aufgaben der Elemente + \item Erleichtert Verständnis, Wartung und Anpassung + \end{itemize*} + \item Mittel zum Erreichen hoher Kohäsion + \begin{itemize*} + \item Datenkapselung, Objektorientierung + \item Benutzung geeigneter Patterns (Kapitel 5) + \end{itemize*} + \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-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 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) + \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 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 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) + \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 -> kein Verhalten + \item Komponente <> + \begin{itemize*} + \item Kapselt Funktionalitäten (Physisch gruppierte Klassen) + \item „Spezialisierte“ Klasse (Vererbung, Exemplare möglich) + \item Stellt Funktionalitäten über Schnittstellen bereit + \item Definiert benötigte Schnittstellen + \item Enthält Klassen oder weitere Komponenten + \item Modulares Element: Substitution (Austauschbarkeit) steht im Vordergrund + \end{itemize*} + \item Black-Box-Darstellung + \begin{itemize*} + \item Zur Verfügung gestellte Funktionalität `<>` + \item Benötigte Funktionalität `<>`‚ + \end{itemize*} + \item White-Box-Darstellung + \begin{itemize*} + \item Interner Aufbau der Komponente `<>` + \item Artefakte `<>`‚ Realisierende physische Einheit (z.B.: .dll) + \end{itemize*} + \end{itemize*} + \end{itemize*} + + Schnittstellen / Interfaces + \begin{itemize*} + \item Definition Diagrammunabhängig + \begin{itemize*} + \item Meist Klassendiagramm + \end{itemize*} + \item Ähnlich Semantik einer Klasse + \begin{itemize*} + \item Nur public-Attribute und Operationen + \end{itemize*} + \item Definiert Verpflichtung zur Implementierung von + \begin{itemize*} + \item Operationen + \item Merkmale -> Attribute dürfen definiert werden + \item Verpflichtungen (z.B.: Vor- / Nachbedingungen) + \end{itemize*} + \item Meist abstrakte Klassen mit abstrakten Operationen + \item Abstrakt - muss überschrieben werden + \item Notation + \begin{itemize*} + \item Stereotyp: <> + \item Meist kursiv geschrieben, da abstrakte Klasse + \end{itemize*} + \end{itemize*} + + Schnittstellenrealisierung, Implementierungsbeziehung + \begin{itemize*} + \item Schnittstellen werden realisiert, nicht instanziiert + \item Schnittstellenkonform + \begin{itemize*} + \item Klasse realisiert alle Attribute und Operationen + \end{itemize*} + \item Schnittstelle kann von anderen Schnittstellen erben + \item Keine Schnittstellenrealisierung zwischen zwei Interface-Klassen -> 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) + \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 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 + \item Getrennte Entwicklung der Schichten möglich + \item Vorhandene / stabilere Schnittstellen + \end{itemize*} + \item Nachteile + \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) + \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 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*} + \item Schwierige Fehlerbehandlung, kein expliziter Kontrollfluss + \item Fehler durch inkompatible Datentypfehler erst zur Laufzeit + \item Häufig zusätzliche Datenkonvertierungen notwendig + \end{itemize*} + \end{itemize*} + + + Plug-In Architektur (Microkernel) + \begin{itemize*} + \item Zielstellung + \begin{itemize*} + \item Stabile, verbreitete Standard-Anwendung (Kern) + \item Funktionalität soll durch Komponenten leicht erweiterbar sein + \item Dritte sollen Komponenten leicht erstellen können + \end{itemize*} + \item Lösung + \begin{itemize*} + \item Möglichst schlanker zentraler Kern + \item Plugin-Manager verwaltet Komponenten: Laden, Entladen, Zugriffskontrolle, Konfiguration + \end{itemize*} + \item Plugin + \begin{itemize*} + \item Komponente mit Standard-Schnittstelle + \item Erweitert Funktionalität (extension point) + \end{itemize*} + \item Vorteile + \begin{itemize*} + \item Robustes Verhalten + \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 + \begin{itemize*} + \item Höherer initialer Aufwand + \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*} + \item Geeignet für interaktive Systeme + \item Problem + \begin{itemize*} + \item Lose Kopplung zwischen verschiedenen Komponenten + \item Daten werden in verschiedenen Sichten dargestellt + \item Realisierung von GUI‘s + \end{itemize*} + \item Lösung durch drei Komponenten + \begin{itemize*} + \item Daten (Model) enthält die Kernfunktionalität / Durchführung der Geschäftsprozesse, kapselt und Speichert die Daten + \item Sichten bzw. Dialoge (View) stellt die Daten für den Anwender in unterschiedlicher Art dar + \item Logik bzw. Steuerung (Controller) Realisiert die Interaktion mit dem Benutzer, übernimmt die Eingaben vom View und ändert die Daten im Modell, legt die Darstellungsart der Sichten fest + \end{itemize*} + \item Vorteile + \begin{itemize*} + \item Unabhängige Entwicklung der Komponenten + \item Änderung der Oberfläche ohne Änderung des Modells + \item Unterschiedliche Oberflächen für das selbe Modell + \end{itemize*} + \item Nachteile + \begin{itemize*} + \item Performance + \item Erhöhter initialer Entwicklungsaufwand + \end{itemize*} + \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 Ähnliche Benutzungsschnittstelle + \end{itemize*} + + 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*} + \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*} + \item Definition nebenläufiger Systemeinheiten (z.B. Prozesse) + \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 + \begin{itemize*} + \item Zentral + \begin{itemize*} + \item Call/Return (prozedural, synchron) + \item Master/Slave (nebenläufig mit zentraler Steuerung) + \end{itemize*} + \item Dezentral + \begin{itemize*} + \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] + \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 Sicherheit + \begin{itemize*} + \item Zugriffskontrolle + \item Fehlertoleranz (Daten und Hardware) + \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 + \begin{itemize*} + \item Verständlich aus Sicht des Lesers formulieren (Glossar) + \item Das Warum beschreiben (Entwurfsentscheidungen) + \item Annahmen, Voraussetzungen, Randbedingungen dokumentieren + \item Wiederholungen vermeiden + \item Notation erklären oder Standards verwenden (UML) + \begin{itemize*} + \item Legende hinzufügen + \end{itemize*} + \item Auf Zweckdienlichkeit prüfen, Reviews durchführen (Inhalt, Qualität) + \item Verschiedene Sichten für verschiedene Zielgruppen + \end{itemize*} + \end{itemize*} + + \section{Feinentwurf} + + %| Analyse-Modell | Entwurfs-Modell | + %| -\item | -\item | + %| Fachliche Domäne | Lösungsdomäne | + %| Teilweise unvollständig in Attributen und Operationen | Vollständige Angabe aller Attribute und Operationen | + %| Datentypen und Parameter können noch fehlen | Vollständige Angabe von Datentypen und Parametern | + %| Noch kaum Bezug zur Realisierungssprache | Auf Umsetzung in gewählter Programmiersprache bezogen | + %| Keine Überlegungen zur Realisierung von Assoziationen | Navigationsangaben, Qualifikation, Ordnung, Verwaltungsklassen | + %| | Entscheidung über Datenstrukturen, Anbindung GUI | + + Schließen der Lücke zwischen Grobentwurf und Implementierung + \begin{itemize*} + \item Identifizieren und Entwerfen von Klassen der Lösungsdomäne + \item Identifikation und Verwendung von Entwurfsmustern + \item Detaillierte Beschreibung der Klassen + \item Beschreibung von Schnittstellen + \item Iterativer Prozess! + \begin{itemize*} + \item Verbesserung des Entwurfs - Refactoring + \item Optimieren des Entwurfsmodells zur Erfüllung nichtfunktionaler Anforderungen + \end{itemize*} + \end{itemize*} + + Objektorientierter Feinentwurf + \begin{itemize*} + \item Ausgangspunkt + \begin{itemize*} + \item Grobdefinition der Architektur, Zerlegung in Subsysteme (evtl. unter Verwendung von Standardarchitekturen) + \item Verteilungskonzept + \item Ablaufmodell + \end{itemize*} + \item Ergebnis + \begin{itemize*} + \item OO-Modell für jedes Subsystem der Architektur + \item OO-Modell für unterstützende Subsysteme unter Berücksichtigung gewählter Technologien + \item Spezifikationen der Klassen + \item Spezifikationen von externen Schnittstellen + \end{itemize*} + \end{itemize*} + + \subsection{Klassen- und Objektentwurf} + \begin{itemize*} + \item Klassen der Lösungsdomäne + \begin{itemize*} + \item Klassen, die nicht durch objektorientierte Analyse der Anwendungsdomäne entstehen + \end{itemize*} + \item Entstehungsgründe + \begin{itemize*} + \item Architektur von Software und System + \item nichtfunktionale Anforderungen + \item Beispiele: Kommunikation, Fehlertoleranz, Adapter, Datenhaltung, Effizienz, Benutzerschnittstellenobjekte, Middleware, ... + \item Sichtbare (Grenz- und Steuerungsobjekte) werden schon in der Analyse identifiziert + \end{itemize*} + \end{itemize*} + + Klassen identifizieren (responsibility-driven design (Wirfs-Brock, McKean)) + > Verantwortlichkeits-Prinzip: Sichtweise: Objekte und Klassen sind nicht nur Behälter für Verhalten und Daten, sondern erfüllen in Zusammenarbeit mit anderen Objekten bestimmte Aufgaben eigenverantwortlich + + Responsibility-Driven Design - Begriffe + \begin{itemize*} + \item Sichtweise auf Softwaresystem + \item Application = set of interacting objects + \item Object = implementation of role(s) + \item Role = set of related responsibilities + \item Responsibility = obligation to perform a task or know information + \item Collaboration = interaction of objects or roles + \item Contract = agreement outlining collaboration terms + \end{itemize*} + + Arten von Rollen + + \begin{itemize*} + \item Information holder | knows and provides information | + \item Structurer | maintains relationship between objects and information about relationships | + \item Service provider | performs work, offers computing services | + \item Coordinator | reacts to events by delegating tasks to others | + \item Controller | makes decisions and directs other’s actions | + \item Interfacer | transforms information and requests between system parts | + \end{itemize*} + + Hilfsmittel: CRC-Karten + \begin{itemize*} + \item Candidate (or class), Responsibility, Collaboration + \item Informelles Mittel zum + \begin{itemize*} + \item Finden, + \item Beschreiben und + \item iterativen Verändern von Klassen + \end{itemize*} + \end{itemize*} + + Ein Objekt + \begin{itemize*} + \item implementiert eine Schnittstelle und beeinflusst andere Objekte + \item wird in drei Teilen entworfen + \begin{itemize*} + \item Öffentliche Schnittstelle + \item Art und Weise der Benutzung + \item Innere Details der Funktionsweise + \end{itemize*} + \item Kohärenz: zusammengehörende Verantwortlichkeiten in einer Klasse konzentrieren! + \end{itemize*} + + + \subsection{Entwurfsprinzipien} + \begin{itemize*} + \item Kapselung + \begin{itemize*} + \item Probleme: Zugriff auf private oder ebenen-fremde Attribute + \item Verwenden von get- und set-Operationen + \item Zusicherungen einhalten + \item Zugriffe zentralisieren + \item Verbalisierung + \item Zugriffsbeschränkung + \end{itemize*} + \item Zerlegung + \begin{itemize*} + \item Teile und Herrsche + \item Zerlegen in Komponenten + \item Verantwortlichkeitsprinzip: Komponente ist klar für eine Aufgabe verantwortlich + \item Eigenschaften und Schnittstellen im Klassendiagramm + \item Beziehungen zwischen Klassen: Assoziationen + \item Aggregation + \begin{itemize*} + \item „besteht aus“, „ist Teil von“ oder „Ganzes-/Teile-Beziehung“ + \item Schwache Bindung der Teile mit dem Ganzen + \item Notation: ungefüllte Raute am Ganzen + \end{itemize*} + \item Komposition + \begin{itemize*} + \item Wie Aggregation, jedoch stärkere Bindung + \item Teil nur einem Ganzen zugeordnet + \item Nur Multiplizität von 1 oder 0..1 möglich! + \item Gefüllte Raute am Ganzen + \end{itemize*} + \item Polymorphie + \begin{itemize*} + \item Reaktion auf eine Nachricht abhängig vom Typ des Objektes + \item Variablen können Objekte verschiedener Klassen aufnehmen (Voraussetzung: Typ der Variablen ist eine gemeinsame Basisklasse der (davon) abgeleiteten Klasse(n) der Objekte) + \item Überladen von Operationen + \item gleicher Operationsname, unterschiedliche Signatur + \item abstrakte Operationen: Virtuelle Operationen ohne Implementierung + \item abstrakte Klasse: Klasse mit abstrakten Operationen + \item Folgen: + \item von abstrakten Klassen können keine Objekte angelegt werden (Implementierung fehlt) + \item Abgeleitete Klassen müssen Operation implementieren, damit Objekte angelegt werden können + \end{itemize*} + \end{itemize*} + \end{itemize*} + + Vererbung im Entwurf + \begin{itemize*} + \item In der Analyse: Klassifikation von Objekten, Taxonomie, Spezialisierung/Verallgemeinerung, Organisation von Klassen in Hierarchien + \item Verringerung von Redundanz und damit Inkonsistenzen + \begin{itemize*} + \item Funktionalität nur einmal implementieren! + \item Spezifikations-Wiederverwendung + \item Implementierungs-Wiederverwendung + \end{itemize*} + \item Verbesserung der Erweiterbarkeit + \begin{itemize*} + \item Abstrakte Schnittstellen einsetzen! + \end{itemize*} + \end{itemize*} + + Vererbung oder Assoziation + \begin{itemize*} + \item Schlüsselwort Vererbung: ist ein + \item Schlüsselwort Assoziation: besteht aus, ist Teil, hat,... + \item Vererbung: Unterscheidungsmerkmal definierbar (Diskriminator) + \item Vermeide Vererbung, wenn es Alternativen gibt + \item Mehrfachvererbung + \begin{itemize*} + \item Problem: Unabhängige Aspekte der Vererbungshierarchie + \item Vermeidung: abstrakte Klassen oder Komposition + \end{itemize*} + \end{itemize*} + + Abstrakte Klassen + \begin{itemize*} + \item Nur Unterklassen, keine Instanzen + \item Attribute in Unterklassen füllen + \item Notation: Kursiv oder Stereotyp <> + \end{itemize*} + + Offen / Geschlossen-Prinzip [Meyer 1988] + \begin{itemize*} + \item Erweiterbarkeit eines Entwurfs + \item Offen für Erweiterungen, + \begin{itemize*} + \item z.B. durch Vererbung / Polymorphie + \item Virtuelle Operationen verwenden + \item Verändert vorhandenes Verhalten nicht + \item Erweiterung um zusätzliche Funktionen oder Daten + \end{itemize*} + \item Geschlossen für Änderungen + \begin{itemize*} + \item private Attribute + \item Möglichst protected Operationen + \end{itemize*} + \item Beschränkung der Erweiterbarkeit + \begin{itemize*} + \item Keine Einschränkungen der Funktionalität der Basisklasse! + \end{itemize*} + \end{itemize*} + + Liskovsches Ersetzungsprinzip + \begin{itemize*} + \item Wenn S eine Unterklasse von T ist, dann können Objekte des Typs T in einem Programm durch Objekte des Typs S ersetzt werden, ohne die Funktion des Programms zu verändern. [Barbara Liskov 1987] + \item Engere Definition als „ist-ein“-Beziehung + \item Kein unerwartetes Verhalten eines Objektes eines Subtyps + \item Methoden, die Objekte der Basisklasse erwarten, müssen auch mit Objekten der abgeleiteten Klasse funktionieren + \item Zusicherungen der Basisklasse müssen von der abgeleiteten Klasse erfüllt werden! + \end{itemize*} + + Gesetz von Demeter (LoD) + \begin{itemize*} + \item Gesetz von „schüchternen“ Objekten + \item Objekte sollen nur mit Objekten in ihrer unmittelbaren Umgebung kommunizieren + \item Aus einer Methode M dürfen (sollten) nur Nachrichten an Objekte gesendet werden, die ... + \begin{itemize*} + \item unmittelbarer Bestandteil des Objekts von M sind (super) + \item M als Argument übergeben wurden + \item direkt in M erzeugt wurden + \item (oder sich in globalen Variablen befinden) + \end{itemize*} + \item Als Metrik überprüfbar + \end{itemize*} + + Ein Objekt sollte + \begin{itemize*} + \item Nur Methoden aufrufen, die zur eigenen Klasse gehören + \item Nur Methoden von Objekten aufrufen, die: + \begin{itemize*} + \item Von Attributen referenziert werden + \item Als Parameter übergeben wurden + \item Selbst erzeugt wurden + \end{itemize*} + \end{itemize*} + + + \subsection{Entwurfsmodelle} + Klassendiagramm + \begin{itemize*} + \item Eigenschaften + \begin{itemize*} + \item Modellierung der statischen Struktur (Aufbau) + \item Modellierung der Struktur von Daten + \item Klasse im Mittelpunkt (Aufbau, Beziehungen zueinander) + \item Wichtigstes und bekanntestes Diagramm der UML! + \end{itemize*} + \item Elemente des Klassendiagramms + \begin{itemize*} + \item Klasse (Attribute, Operationen) + \item Vererbung / Realisierung + \item Assoziationen + \item Beziehungen / Abhängigkeiten + \end{itemize*} + \item Attribute + \begin{itemize*} + \item Klassenattribut: "X" static - statisch, nur einmal pro Klasse vorhanden + \item Sichtbarkeit + \item "+" public - im Namensraum sichtbar + \item "\#" protected - nur in abgeleiteten Klassen sichtbar + \item "~" package - im Paket sichtbar + \item "-" private - nur in der Klasse selbst sichtbar + \item Ableitung "/" derived - abgeleitetes Attribut + \end{itemize*} + \item Weitere Eigenschaften + \begin{itemize*} + \item readOnly - nach Initialisierung nicht änderbar + \item composite - Aggregation: Composition + \item redefines X - überschreibe Attr. der Oberklasse + \item subsets X - Teilmenge + \item union - Attribut ist Vereinigung der subsets + \item unique - Elemente eindeutig (Schlüsselattribut) + \item ordered - Elemente sind geordnet (unordered) + \item sequence - Speicherung der Elemente als Liste + \item bag - Elemente sind Multimenge + \end{itemize*} + \item Parameterlisten + \begin{itemize*} + \item in: Eingangsparameter + \item out: Ausgangsparameter + \item inout: Eingangs- und Ausgangsparameter + \item return: Rückgabewert + \end{itemize*} + \item Beziehungen + \begin{itemize*} + \item navigierbar/unspezifiziert/nicht-navigierbar + \item ungerichtete/gerichtete Relation/assoziation + \end{itemize*} + \end{itemize*} + + Aktive Klassen + \begin{itemize*} + \item Reagieren nicht nur, sondern werden von sich aus aktiv + \item Z.B. Steuerobjekte + \item Als Thread oder Prozess realisiert + \end{itemize*} + + \subsection{Schnittstellen} + \begin{itemize*} + \item Vereinbarung über Art des Aufrufs + \begin{itemize*} + \item Homogenität gleicher Funktionen + \item Enthält: + \item Spezifikation von Operationen + \item keine Implementierung ( Java, nicht UML!) + \item keine Attribute + \item In Java außerdem anstelle von Mehrfachvererbung + \end{itemize*} + \item Schnittstellen in UML + \begin{itemize*} + \item Funktion ähnlich abstrakter Klasse + \item Meist für technische Aspekte + \item Notation: Stereotyp <> oder grafisch (lollipop notation) + \end{itemize*} + \item Verträge („design by contract“) + \begin{itemize*} + \item Schnittstelle sagt bisher nichts über Effekt der Klasse aus + \item Vollständige Beschreibung wäre Programm? + \item Vereinfachte Beschreibung für Abfolgen: + \item Vorbedingung: Prädikat, das vor Aufruf gelten muss <> + \item Nachbedingung: Prädikat, das nach Aufruf gelten muss <> + \item Invariante: Prädikat, das immer gilt <> + \item Jeweils Einschränkungen! + \end{itemize*} + \end{itemize*} + + Protokollrollen - Dynamisches Verhalten von Schnittstellen + \begin{itemize*} + \item Ohne Sicht auf innere Implementierung (anders als beim Objektlebenszyklus) + \item Protokoll = Kollaboration von Protokollrollen (protocol, protocol role) + \item Modell: Zustandsautomat + \begin{itemize*} + \item Genauer: Spezialisierung + \item Beschreibung der Synchronisation von Objekten + \end{itemize*} + \end{itemize*} + + \subsection{Entwurfsmuster} + \begin{itemize*} + \item Warum Wiederverwendung? + \begin{itemize*} + \item Geringerer Aufwand + \item Das Rad nicht noch einmal neu erfinden + \item Verwenden üblicher, aus Erfahrung gewachsener Strukturen + \end{itemize*} + \item ... und warum nicht? + \begin{itemize*} + \item Aufwand für Anpassung kann hoch sein! + \item Einarbeiten in teilweise komplexe Schnittstellen + \item Abhängigkeit von externen Komponenten, Zwang zu späterer Portierung + \end{itemize*} + \end{itemize*} + + > Was ist ein Entwurfsmuster? Eine schematische Lösung für eine Klasse verwandter Probleme (Höhere Ebene: Architekturmuster) + \begin{itemize*} + \item Wie helfen Muster im Entwurf? + \begin{itemize*} + \item Identifizieren von Klassen (Anwendungs- und Lösungsdomäne) + \item Regeln sind abstrakt oder an realen Objekten orientiert + \item Muster: Arten von Rollen bzw. Lösungshinweise für typische Strukturierungsaufgaben + \item Änderbarkeit und Lesbarkeit des Entwurfs verbessern + \end{itemize*} + \item Arten von Entwurfsmustern + \begin{itemize*} + \item Erzeugungsmuster + \item Strukturmuster + \item Verhaltensmuster + \end{itemize*} + \item Erzeugungsmuster + \begin{itemize*} + \item Factory Method, Fabrikmethode: + \item Implementierungsvarianten; Erzeugung von Objekten wird an Unterklassen delegiert + \item Abstract Factory, Abstrakte Fabrik: + \item Schnittstelle zur Erzeugung von Familien verwandter Objekte + \item Prototype, Prototyp: + \item Objekterzeugung durch Vorlage und Kopie + \item Builder, Erbauer: + \item Trennung von Erzeugung und Repräsentation komplexer Objekte, für Erzeugung unterschiedlicher Repräsentationen + \item Singleton: + \item Sicherstellung, dass nur ein Objekt einer Klasse erzeugt wird, die einen globalen Zugriff bietet + \end{itemize*} + \end{itemize*} + + Strukturmuster + \begin{itemize*} + \item Adapter + \begin{itemize*} + \item Anpassung der (inkompatiblen) Schnittstelle einer Klasse oder eines Objekts an eine erwartete Schnittstelle + \end{itemize*} + \item Bridge, Brücke + \begin{itemize*} + \item Abstraktion (Schnittstelle) von Implementierung entkoppeln, um beide unabhängig zu ändern; Impl.-Klasse nur als Verweis + \end{itemize*} + \item Decorator, Dekorierer + \begin{itemize*} + \item Objekt dynamisch um Zuständigkeiten erweitern (Alternative zur Bildung von Unterklassen) + \end{itemize*} + \item Facade, Fassade + \begin{itemize*} + \item Einheitliche Schnittstelle zu einer Schnittstellenmenge, vereinfacht Zugriff + \end{itemize*} + \item Flyweight, Fliegengewicht + \begin{itemize*} + \item Gemeinsame Nutzung kleiner Objekte zur effizienten Verwendung großer Mengen davon (Speicheraufwand) + \end{itemize*} + \item Composite, Verbund, Kompositum + \begin{itemize*} + \item Zusammenfügen verschiedener Objekte zur Repräsentation von Teil-Ganzes-Beziehungen; Objekte und Kompositionen können einheitlich behandelt werden, Baumstruktur + \end{itemize*} + \item Proxy, Stellvertreter + \begin{itemize*} + \item Kontrollierter Zugriff auf Objekt durch vorgeschaltetes Stellvertreterobjekt + \item Gründe: Schutz, entfernter Zugriff (remote proxy), smart pointer, Erzeugung on demand + \end{itemize*} + \end{itemize*} + + Adapter + \begin{itemize*} + \item Vorteile + \begin{itemize*} + \item Kommunikation unabhängiger Softwarekomponenten + \item Einfache Erweiterung um zusätzliche Funktionalität + \item Austausch der Komponente durch Änderung des Adapters leicht möglich + \end{itemize*} + \item Nachteile + \begin{itemize*} + \item Zusätzlicher Adaptierungsschritt benötigt Zeit + \item Schlechte Wiederverwendbarkeit der Adapter + \end{itemize*} + \item Bekannte Verwendung, Spezialfälle + \begin{itemize*} + \item Fassade: Adapter eines Teilsystems + \item Proxy: erweitert die Funktionalität bei gleicher Schnittstelle + \item Brücke: keine Anpassung, sondern vorherige Strukturierung + \end{itemize*} + \end{itemize*} + + Verhaltensmuster + \begin{itemize*} + \item Command, Befehl + \begin{itemize*} + \item Befehl / Operation als Objekt kapseln (Parameterübergabe, Operations-Warteschlangen, logging, Rückgängig machen) + \end{itemize*} + \item Observer, Beobachter + \begin{itemize*} + \item 1-zu-n-Beziehung zwischen Objekten, so dass die Änderung des zentralen Objekts zu einer Benachrichtigung und Aktualisierung der n (abhängigen) Zustände führt + \end{itemize*} + \item Visitor, Besucher + \begin{itemize*} + \item Beschreibung und Kapselung einer zu definierenden Operation, die auf einer Objektmenge ausgeführt wird + \end{itemize*} + \item Interpreter + \begin{itemize*} + \item Repräsentation der Grammatik einer Sprache sowie Interpreter zur Analyse von Sätzen der Sprache + \end{itemize*} + \item Iterator + \begin{itemize*} + \item Sequentieller Zugriff auf die Elemente einer Sammlung ohne Kenntnis der Implementierung der Sammlung + \end{itemize*} + \item Memento + \begin{itemize*} + \item Internen Zustand eines Objekts erfassen und speichern, um Objektzustand wiederherstellen zu können + \end{itemize*} + \item Template Method, Schablonenmethode + \begin{itemize*} + \item Beschreibung des Skeletts eines Algorithmus mit Delegation der Einzelschritte an Unterklassen; Teilschritte können von Unterklassen geändert werden + \end{itemize*} + \item Strategy, Strategie + \begin{itemize*} + \item Ermöglicht Austausch verschiedener Implementierungen einer Aufgabe ohne Beeinflussung der sie benutzenden Objekte + \end{itemize*} + \item Mediator, Vermittler + \begin{itemize*} + \item Objekt, welches das Zusammenspiel einer lose gekoppelten Objektmenge in sich kapselt. Vermeidet direkten Bezug der Objekte untereinander und ermöglicht unabhängige Änderung des Zusammenspiels + \end{itemize*} + \item State, Zustand + \begin{itemize*} + \item Ermöglicht Objekt, sein Verhalten abhängig von seinem inneren Zustand zu ändern, als ob es die Klasse wechselt + \end{itemize*} + \item Chain of Responsibility, Zuständigkeitskette + \begin{itemize*} + \item Vermeidet direkte Kopplung von Auslöser und Empfänger einer Anfrage bzw. Operation. Mehrere Objekte werden nacheinander benachrichtigt, bis die Anfrage erledigt ist + \end{itemize*} + \end{itemize*} + + Bewertung Observer + \begin{itemize*} + \item Vorteile + \begin{itemize*} + \item Entkopplung von Komponenten und Schichten möglich + \item Broadcast und selective Broadcast möglich + \end{itemize*} + \item Nachteile + \begin{itemize*} + \item Bei vielen Beobachtern: Benachrichtigung aufwendig + \item Unerwartete Änderung, Änderungskaskaden und Rekursion + \item Abmelden der Beobachter vor dem Löschen + \end{itemize*} + \item Bekannte Verwendung, Spezialfälle + \begin{itemize*} + \item Verwendung im Model-View-Controller Muster + \item Qt: Signal / Slot-Prinzip ähnlich + \end{itemize*} + \end{itemize*} + + Anwendung von Entwurfsmustern + \begin{itemize*} + \item Untersuche Anwendbarkeit und Konsequenzen + \item Analysiere Struktur, Teilnehmer und Kollaborationen + \item Wähle aus dem Anwendungskontext Namen für Teilnehmer + \item Spezifiziere die teilnehmenden Klassen + \begin{itemize*} + \item Deklariere Schnittstellen, Vererbung und Variablen + \item Identifiziere existierende Entwurfsklassen, die durch das Muster beeinflusst werden + \end{itemize*} + \item Wähle anwendungsspezifische Namen für Operationen + \item Implementiere Operationen entsprechend den Verantwortlichkeiten und Kollaborationen des Musters + \end{itemize*} + + \subsection{Klassenbibliotheken und Komponenten} + Klassenbibliotheken + \begin{itemize*} + \item Zusammenfassung von Modulen, Klassen, etc. + \item Mit einem bestimmten (abstrakten) Zweck + \begin{itemize*} + \item Abstrakte Datenverwaltung, Templates + \item Grundlegende System-Aufgaben + \item Untere Kapselungs-Schicht des Laufzeitsystems oder der Programmierumgebung + \item Numerische Routinen, Simulation, ... + \end{itemize*} + \item Wird in Anwendung eingebunden (importiert), API + \begin{itemize*} + \item Objekte instanziieren oder Klassen ableiten + \end{itemize*} + \item Meist passiv: Kontrollfluss wird von Anwendung gesteuert + \item Beispiele: stdlib, MFC, GNU scientific library, Java 3D, IPP + \end{itemize*} + + Komponentenbasierte Entwicklung + \begin{itemize*} + \item Bausteinorientierte Programmierung (component-ware) + \item Softwareentwicklung: Konstruktion aus vorgegebenen Bausteinen + \item Entsprechung für Wiederverwendung: Generische Bausteine (components) + \begin{itemize*} + \item Anpassbar, zusammensetzbar + \end{itemize*} + \item Werkzeuggestützte bzw. grafische Kompositionsmechanismen + \item Beispiele: Java Beans, Enterprise Java Beans (EJBs), Microsoft COM+ + \item Komponenten-Entwicklung oft auch projektspezifisch + \item Warum Komponenten + \begin{itemize*} + \item Monolithische, proprietäre Software führt zunehmend zu Problemen + \item Zunehmend verteilte Anwendungen mit offener Struktur und Internet-Anbindung + \item Zusammensetzen der Funktionalität aus standardisierten Elementen, die über offene Schnittstellen kommunizieren + \item Komponenten sollen Flexibilität bei sich ändernden Anforderungen erhöhen + \item Weg aus der „Software-Krise“? + \end{itemize*} + \item Eigenschaften von Komponenten + \begin{itemize*} + \item müssen von ihrer Umgebung und anderen Komponenten unabhängig und getrennt sein + \item Kontextabhängigkeiten: benötigte Komponenten-Infrastruktur und Systemressourcen + \item Kapseln ihre angebotenen Funktionen + \item Werden immer als ganze Einheit eingesetzt; alle Bestandteile sind enthalten (Archiv-Datei) + \item Sind nicht von Kopien ihrer selbst unterscheidbar + \item Klare Spezifikation der Schnittstelle nötig; explizit definierte Interaktionen mit Komponenten und Umgebung + \item Komposition durch Dritte: Endbenutzer, Komponenten-Hersteller und Komponenten-Integrator; meist nur kompilierter Code verfügbar + \end{itemize*} + \end{itemize*} + + Komponenten für Client/Server-Architekturen + \begin{itemize*} + \item Wichtige Aspekte + \begin{itemize*} + \item Transaktionen + \item Sicherheit + \item Ressourcenverwaltung + \item Persistenz + \end{itemize*} + \item Komponentenkonzept für Server-Komponenten + \begin{itemize*} + \item meist unsichtbare Komponenten + \item standardisierte Realisierung der wichtigen Eigenschaften für Client/Server-Anwendungen + \item Realisierung: Enterprise Java Beans (EJBs) innerhalb eines Java Enterprise Edition Servers + \end{itemize*} + \end{itemize*} + + \subsection{Dokumentation} + Dokumentation des Feinentwurfs + \begin{itemize*} + \item Möglichkeiten + \begin{itemize*} + \item Eigenständiges Dokument + \item Erweiterung des Lastenhefts / Grobkonzepts + \item Eingebettet in den Quellcode (Werkzeug, z.B. Javadoc) + \end{itemize*} + \item Inhalt + \begin{itemize*} + \item Ähnlich Grobkonzept + \item Zusätzlich detaillierte Modelle + \item Abwägungen des Objektentwurfs + \item Klassenschnittstellen + \end{itemize*} + \end{itemize*} + + \section{Implementierung} + Aufgaben der Implementierung + \begin{itemize*} + \item Aus Spezifikationen Programm(code) erzeugen + \item Aufbauend auf Ergebnissen des Feinentwurfs + \begin{itemize*} + \item Algorithmen konzipieren + \item Datenstrukturen realisieren + \item Umsetzen in konkreter Programmiersprache + \item Dokumentation + \item Untersuchung des Zeit- und Speicherbedarfs + \item Test und Verifikation + \end{itemize*} + \item „Programmieren im Kleinen“ + \end{itemize*} + + \subsection{Konventionen und Werkzeuge} + Konventionen beim Programmieren + \begin{itemize*} + \item (Coding Rules, -conventions, -standards) + \item Regeln für verständliche Programme + \begin{itemize*} + \item „wie“ sollte Quellcode formal und strukturell gestaltet sein + \item Bezeichner, Einrückungen, Dokumentation, Dateien, ... + \item Strukturierung: Block, Methode, Klasse, Package + \end{itemize*} + \item Firmenspezifische Regeln + \begin{itemize*} + \item Festlegung Entwurfsprinzipien (z.B. keine Mehrfachvererbung) + \end{itemize*} + \end{itemize*} + + Namenskonventionen + \begin{itemize*} + \item Klasse + \begin{itemize*} + \item (mit) Substantiv, „UpperCamelCase“ + \item Beispiele: Account, StandardTemplate + \end{itemize*} + \item Methode + \begin{itemize*} + \item (mit) Verb, Imperativ (Aufforderung), „lowerCamelCase“ + \item Beispiele: checkAvailability(), getDate() + \end{itemize*} + \item Attribut, Variable + \begin{itemize*} + \item (mit) Substantiv, „lowerCamelCase“ + \item Beispiele: anzahlAutos, fensterBreite + \end{itemize*} + \item Konstante + \begin{itemize*} + \item Nur Großbuchstaben, Worte mit "\_" zusammengesetzt + \item Standardpräfixe: "MIN\_", "MAX\_", "DEFAULT\_", ... + \item Beispiele: NORTH, BLUE, MIN\_WIDTH, DEFAULT\_SIZE + \end{itemize*} + \end{itemize*} + + Formatierungs-Richtlinien + \begin{itemize*} + \item Entsprechend Schachtelungstiefe einrücken, aber nicht zu weit + \item Einheitliche Verwendung von Leerzeilen und Leerzeichen + \item Einheitliche Dateistruktur verwenden + \begin{itemize*} + \item Eine .java-Datei pro Klasse + \item Ein Verzeichnis für jedes package + \end{itemize*} + \item Werkzeuge: source beautifier, oft in IDEs enthalten + \item Editor: syntax highlighting + \item Navigationswerkzeuge + \begin{itemize*} + \item Auf- und Zuklappen, Inhaltsverzeichnis, tagging + \item doxygen, Eclipse etc. + \end{itemize*} + \end{itemize*} + + Änderungsfreundlicher Code + \begin{itemize*} + \item Wahl von Variablen, Konstanten und Typen orientiert an der fachlichen Aufgabe, nicht an der Implementierung: + \begin{itemize*} + \item `typedef char name [NAME\_LENGTH]` + \item `typedef char firstName [FIRST\_NAME\_LENGTH]` + \end{itemize*} + \item Symbolische Konstanten statt literaler Werte verwenden, wenn spätere Änderung denkbar + \item Algorithmen, Formeln, Standardkonzepte in Methoden/Prozeduren kapseln + \item Übersichtlichkeit: Zusammenhängende Einheit nicht größer als Editorfenster (40-60 Zeilen, 70 Zeichen breit) + \item Strukturierte Programmierung (Regeln je nach Schärfe) + \begin{itemize*} + \item Kein goto verwenden (in anderen Sprachen als Java) + \item switch nur mit break-Anweisung nach jedem Fall + \item break nur in switch-Anweisungen verwenden + \item continue nicht verwenden (Effekt ähnlich goto) + \item return nur am Ende zur Rückgabe des Werts + \end{itemize*} + \item Übersichtliche Ausdrücke + \begin{itemize*} + \item Seiteneffektfreie Ausdrücke, schlecht: y += 12*x++; + \end{itemize*} + \item Variablen möglichst lokal und immer private deklarieren + \item Wiederverwendung "äußerer" Namen vermeiden + \end{itemize*} + + Werkzeuge + \begin{itemize*} + \item Integrated Development Environments (Eclipse, KDevelop) + \item Compiler, Linker; Build / Make; Versionskontrolle (git, svn) + \end{itemize*} + + \subsection{Code-Qualität} + Portierbarer Code + \begin{itemize*} + \item Code, den man ohne Änderungen in ein anderes System (Compiler, Betriebssystem, Rechner) übertragen kann + \begin{itemize*} + \item Kein implementierungsabhängiges Verhalten! + \end{itemize*} + \item ANSI C++ Standard ist nicht vollständig definiert + \begin{itemize*} + \item Ist das Verhalten nicht festgelegt, unterscheidet der ANSI C++ Standard zwischen: + \item Implementierungsabhängigem, unspezifiziertem oder undefiniertem Verhalten + \item Code, welcher auf implementierungsabhängigem, unspezifiziertem oder undefiniertem Verhalten basiert, ist + \item Nicht portabel und somit häufig verboten + \item Wird unter Umständen ungewollt wegoptimiert + \end{itemize*} + \end{itemize*} + + Implementierungsabhängiges Verhalten + \begin{itemize*} + \item Compiler übersetzen bestimmte Sprachkonstrukte unterschiedlich, Ergebnis unterscheidet sich + \item Voraussetzung: + \item Verhalten ist konsistent festgelegt und dokumentiert + \item Kompilierung von standardkonformem Code ist erfolgreich + \item Beispiel: Speichergröße von Integer-Typen + \item char kann signed oder unsigned sein: Nicht damit rechnen! + \item 32 Bit System ist wie erwartet + \item 16 Bit System: Multiplikation wird mit int durchgeführt -> Überlauf -> undefiniertes Verhalten + \end{itemize*} + + \begin{itemize*} + \item Unspezifiziertes Verhalten: + \item Wie implementierungsabhängiges Verhalten + \item Compiler muss sich für ein bestimmtes Verhalten entscheiden + \item Muss nicht dokumentiert sein + \item Beispiel: Evaluierungsreihenfolge von Funktionsargumenten `tuWas(zuerstDas(),oderDochLieberDas());` + \item Undefiniertes Verhalten: + \item Keinerlei Vorgaben + \item Compiler muss mögliches Problem nicht melden + \item Keine Voraussage welches Resultat eintritt + \item Bereits die Kompilierung kann fehlschlagen + \item Oder das laufende Programm kann falsche Resultate liefern. + \item Effekt: „Bei mir läuft es aber!?“ + \item „undefiniertes Verhalten nutzen grenzt an Sabotage!“ + \end{itemize*} + + Sicherer Code mit const + \begin{itemize*} + \item Const Variable - Konstante + \begin{itemize*} + \item Stellt sicher, dass sich der Wert nicht verändert + \end{itemize*} + \item Const Parameter + \begin{itemize*} + \item Übergabeparameter ändert sich nicht innerhalb der Operation + \item Z.B. bei Übergabe komplexer Daten als Referenz bzw. Zeiger `long calcMeanValue(const image \&i){...}` + \end{itemize*} + \item Const Operationen + \begin{itemize*} + \item Sicherstellen, dass Operation das Exemplar nicht ändert + \item Aufruf der const Operation bei const Variablen möglich + \end{itemize*} + \item Verwende const wenn möglich + \end{itemize*} + + + \subsection{Dokumentation} + \begin{itemize*} + \item Selbstdokumentierende Programme? + \begin{itemize*} + \item 2001 Int. Obfuscated C Code Contest Winner, Short Program + \end{itemize*} + \end{itemize*} + + Integrierte Dokumentation + \begin{itemize*} + \item Verständlichkeit, Wartbarkeit - auch für Programmierer! + \item Code selbst sollte möglichst verständlich sein + \item Dokumentation in Programm schreiben und aktualisieren + \item Beschreibung der Bedeutung des Codes! + \item Als Konventionen festschreiben + \item Programmvorspann + \item Kurzbeschreibung Datei / Klasse / Funktion ... + \item Verwaltungsinformationen + \begin{itemize*} + \item Autor, Datum, Version, Projekt, ToDo, FixMe, ... + \item Zustand: geplant, in Bearbeitung, vorgelegt, akzeptiert + \end{itemize*} + \item Laufende Kommentare im Quellcode + \end{itemize*} + + Programmierer-Dokumentation + \begin{itemize*} + \item Als eigenes Dokument elektronisch oder gedruckt + \item Einstieg in Programmverständnis (z.B. Bachelor-Arbeit) + \item Konsistenz mit Quelltext? Verweise? + \item Technische Unterstützung: JavaDoc (Java), doxygen (C++) + \item Ergänztes Java-Programm: Dokumentation HTML, PDF, + \end{itemize*} + % ```js + % /** @author name Mustermann */ + % /** @param name description */ + % /** @return description */ + % ``` + + Benutzerdokumentation + \begin{itemize*} + \item Benutzer-Handbuch, Online-Dokumentation + \item Unterstützung ohne Support? + \item Vollständige und fehlerfreie Beschreibung der Benutzung + \begin{itemize*} + \item Beispiele, screen shots + \end{itemize*} + \item Arten: Tutorial, Beschreibung, + \end{itemize*} + + Benutzer-Unterstützungssysteme + \begin{itemize*} + \item Integrierte Hilfe (Suchfunktion, balloon help / tool tips) + \item Assistenz-System (Zustandsabhängige Anleitung) + \item Tutor-System zum Erlernen + \item Bug-Listen, Mailinglisten, Diskussionsforen + \end{itemize*} + + \subsection{Codegenerierung} + Bezug zwischen Modell und Programmcode + \begin{itemize*} + \item Vorwärtsmodellierung: Modell - Code + \item Rückwärtsmodellierung: Code - Modell + \begin{itemize*} + \item Außerdem: Modelltransformation, Refaktorisierung + \end{itemize*} + \item Idealfall: Automatische Übersetzung durch SW-Werkzeug (in beiden Richtungen) + \begin{itemize*} + \item „Modellbasierte Entwicklung“ + \end{itemize*} + \item Statisch: Beispiel Klassendiagramm - Quelltext der Klassen mit allen Vererbungsbeziehungen, Attributen und Methodensignaturen (Klassen-Stümpfe mit leeren Methodenrümpfen zum Ausfüllen) + \item Dynamisch: Beispiel Zustandsdiagramm - Quelltext der Zustandssteuerung einer Klasse + \end{itemize*} + + %![Codegenerierung](Assets/Softwaretechnik1_Codegenerierung.png) + + Weitere statische Transformationen + \begin{itemize*} + \item Abbildung von Assoziationen auf Sammlungen + \item Abbildung von Verträgen auf Ausnahmen + \item Abbildung von Objektmodellen auf Datenbankschemata + \item Abbildung von Entwurfsmustern auf Codefragmente + \end{itemize*} + + Optimierung des Entwurfsmodells + \begin{itemize*} + \item Grund: nichtfunktionale Eigenschaften + \item Zugriffspfade + \item Klassen in Attribute umwandeln + \item Verzögerung von Berechnungen + \item Zwischenspeicherung aufwändiger Ergebnisse + \end{itemize*} + + Codegenerierung aus StateCharts + \begin{itemize*} + \item Einfachste Möglichkeit: Switch (Case) Statement + \item Zustände werden durch Datenwerte repräsentiert + \begin{itemize*} + \item Aktueller Zustand: einzelne skalare Variable + \end{itemize*} + \item Jedes Ereignis wird durch Methode implementiert + \item Ausgehend von aktivem Zustand wird bei Eintreffen eines Ereignisses der entsprechende Programmcode ausgeführt + \item Abhängig von Zustandsvariable wird Aktion ausgeführt und der Folgezustand eingestellt + \item Wird in einer Klasse realisiert + \item Sinnvoll für einfache, “flache” Modelle + \begin{itemize*} + \item Sonst Logik für Hierarchie nötig + \end{itemize*} + \end{itemize*} + + Anpassung der Generierung + \begin{itemize*} + \item Verschiedene Zielsprachen (Java, C++, ...) + \item Model2Text-Transformationen + \begin{itemize*} + \item Verschiedene Generatoren, z.B. Eclipse Modelling Project + \end{itemize*} + \item Generierung aus dem Modellierungswerkzeug + \begin{itemize*} + \item Parametrisierung der Codegenerierung + \item Generierungsvorlagen + \end{itemize*} + \end{itemize*} + + Weitere Werkzeuge + \begin{itemize*} + \item Compiler-Compiler: Syntaxbeschreibung wird in lexikalische Analyse (tokenizer) und Syntaxanalyse-Programm transformiert (lex \& yacc / flex \& bison / antlr) + \item Codegenerierung für grafische Benutzungsoberflächen aus grafischer Beschreibung: GUI toolkits + \item XML-Parser + \begin{itemize*} + \item XSLT, DOM, SAX, ... + \end{itemize*} + \end{itemize*} + + \subsection{Implementierung aktiver Objekte} + Realisierung aktiver Entwurfsobjekte + \begin{itemize*} + \item Reagieren nicht nur (Methodenaufruf), sondern implementieren eigenes Verhalten + \item Aktive Klassen, z.B. Steuerobjekte + \end{itemize*} + + Arten von Programmabarbeitung + \begin{itemize*} + \item Sequentiell: es gibt immer genau einen nächsten Schritt, alle Schritte werden nacheinander ausgeführt + \item Parallel: Spezielle Hardware bzw. Mehrkernprozessor, mehrere Befehlsfolgen werden echt parallel bearbeitet + \item Quasi-parallel: Ein Prozessor arbeitet mehrere Befehlsfolgen in freier Einteilung ab + \item Nebenläufig: Oberbegriff für Parallel und Quasi-parallel + \begin{itemize*} + \item concurrent + \end{itemize*} + \end{itemize*} + + Vorteile + \begin{itemize*} + \item Höhere Geschwindigkeit + \item Kein aktives Warten auf Ereignisse + \item Getrennte Implementierung unabhängiger Aspekte + \end{itemize*} + + Ergebnisse eines Programms + \begin{itemize*} + \item Ein Programm, dessen Ablauf eindeutig vorherbestimmt ist, nennt man deterministisch (deterministic) + \item Ein Programm, das bei gleichen Eingaben gleiche Ausgaben produziert, heißt determiniert (determined) + \item Programme in üblichen Programmiersprachen sind sequentiell, deterministisch und determiniert + \item Grund: Herkömmliche Programmiersprachen sind durch das von-Neumann-Modell geprägt + \item Determinismus nicht notwendig für Determiniertheit! + \begin{itemize*} + \item Determiniertheit nebenläufiger Programme: Synchronisation + \item Vermeidung von Schreib/Schreib und Schreib/Lese-Konflikten + \end{itemize*} + \end{itemize*} + + Java Threads + \begin{itemize*} + \item Verwaltung durch die Java Virtuelle Maschine (JVM) + \item Realisierung der Threads ist je nach Implementierung der JVM unterschiedlich + \begin{itemize*} + \item Abbildung auf Betriebssystem-Threads (z.B. unter Windows weitverbreitet) + \item Realisierung durch die JVM (z.B. unter Unix und in Java-fähigen Browsern) + \item Nachteile: Keine Ausnutzung von Multiprozessorsystemen durch die VM; Zuteilungsstrategie für Threads ist in derzeitigen Implementierungen unterschiedlich + \end{itemize*} + \item Threads arbeiten immer im Adressraum der JVM (eigener Prozess) und sind außerhalb dieser nicht sichtbar + \end{itemize*} + + Erzeugung eines Threads + \begin{itemize*} + \item Unterklasse der Basisklasse „Thread“ bilden `class MyThread extends Thread` + \item Problem: keine Mehrfachvererbung, daher Alternative nötig (Beispiel: Applet): + \begin{itemize*} + \item Schnittstelle „Runnable“ implementieren + \item `class MyThread implements Runnable` + \end{itemize*} + \item Die vordefinierte Schnittstelle Runnable ist definiert als + % ```java + % public interface Runnable + % { public abstract void run(); } + % ``` + \end{itemize*} + + Starten eines Threads + \begin{itemize*} + \item Eine Klasse, die Runnable implementiert, muss wie Unterklassen von Thread immer eine run()-Methode definieren + \item Seiteneffekt der Runnable-Schnittstelle + \begin{itemize*} + \item Instanzen der Klasse werden nebenläufig zu den anderen laufenden Threads ausgeführt + \item Ausführung beginnt mit der Methode run () + \end{itemize*} + \item Ablauf + \begin{itemize*} + \item Thread-Objekt erzeugen + \item Thread starten mit t.start() + \item start() ruft implizit run() auf + \end{itemize*} + \end{itemize*} + + Synchronisation von Threads + \begin{itemize*} + \item Gezielte Einschränkung der Nebenläufigkeit + \item Gründe + \begin{itemize*} + \item Zugriffsbeschränkung, gegenseitiger Ausschluss + \item Abhängigkeiten, einseitige Synchronisation + \end{itemize*} + \item Methoden: Semaphore, Monitore, Schlossvariablen, ... + \end{itemize*} + + Java: Monitore + \begin{itemize*} + \item Zugriffsoperationen werden in Klassen zusammengefasst + \item Gegenseitiger Ausschluss: Spezifikation der betroffenen Zugriffsoperation als synchronized + \end{itemize*} + + \subsection{Verifikation und Testen} + Wie erreicht man qualitativ hochwertige Software? + \begin{itemize*} + \item Wissen, Erfahrung und Methodenkompetenz der Programmierer + \item Projektstruktur, klare Verantwortlichkeiten + \item Kosten- und Zeitdruck? Änderungen? + \item Programmier- und Testmethoden + \begin{itemize*} + \item pair programming, code reading etc. + \item Qualitätsverantwortlicher, automatisiertes Testen + \end{itemize*} + \item Technische Unterstützung + \begin{itemize*} + \item Z.B. Versionierung, Dokumentation, Testen, Entwicklungsumgebung + \end{itemize*} + \end{itemize*} + + Begriffe + \begin{itemize*} + \item Zuverlässigkeit: Maß für Übereinstimmung des Systemverhaltens mit Spezifikation + \item Grund für Unzuverlässigkeit: + \begin{itemize*} + \item Fehler (bug, fault): fehlerhafter Programmcode o.ä. + \begin{itemize*} + \item Der Begriff „Bug“: + \begin{itemize*} + \item Schon vor Computern als Begriff für Fehler benutzt + \item Motte im Relais des Computers Mark II Aiken (1947) + \end{itemize*} + \end{itemize*} + \end{itemize*} + \item Fehlerhafter Zustand (error): Fehler hat zur Laufzeit zu einem internen fehlerhaften Zustand geführt, der möglicherweise zu einem Ausfall führt + \item Störfall, Ausfall (failure): Abweichung vom spezifizierten Verhalten, meist mit negativen Folgen + \end{itemize*} + + Vergleich System / Systemmodell + \begin{itemize*} + \item Anspruch guter Software: System entspricht Systemmodell (Korrektheit) + \item Problem: System nicht vollständig automatisch erzeugbar! + \item Auswege + \begin{itemize*} + \item Fehlervermeidung (Inspektion, pair programming, ...) + \item Nachweis, dass System dem Modell entspricht - Verifikation + \item Überprüfen, ob System dem Modell entspricht - Testen + \item Fehlertoleranz (durch Redundanz) + \end{itemize*} + \end{itemize*} + + Verifikation + \begin{itemize*} + \item Mathematisch formaler Beweis, dass ein Programm einer Spezifikation genügt + \item Vorteil: wenn anwendbar, dann vollständiger Beweis + \item Problem: für viele (realistisch große) Fälle nicht anwendbar + \begin{itemize*} + \item Zu aufwändig + \item Umgebung muss ebenfalls verifiziert werden + \item Auch in der Theorie nicht immer entscheidbar: Halteproblem, Gödelscher Unvollständigkeitssatz + \end{itemize*} + \item Theoretische Informatik: Berechenbarkeitstheorie, formale Semantik; aktives Forschungsgebiet + \begin{itemize*} + \item model checking + \end{itemize*} + \end{itemize*} + + Testen + \begin{itemize*} + \item Systematischer Versuch, Defekte in der Software zu finden + \item Ingenieurtechnik zur Erhöhung des Vertrauens in Softwaresysteme, aber: unvollständig! + \begin{itemize*} + \item Kann nur die Anwesenheit von Fehlern nachweisen, aber nicht Korrektheit (Abwesenheit von Fehlern)! + \end{itemize*} + \item Aufgabe: Unterschiede zwischen Modell und System finden + \item Destruktiv im Gegensatz zu sonstigen SWE-Aufgaben + \begin{itemize*} + \item Daher sollten nicht (nur) Entwickler selbst testen + \end{itemize*} + \end{itemize*} + + Testplanung + \begin{itemize*} + \item Testen ist aufwändig, deshalb ist gute Planung nötig! + \item Testplanung sollte bereits mit der Anforderungsanalyse beginnen und im Entwurf verfeinert werden (V-Modell, Test-First-Ansatz)! + \item Typische Bestandteile einer Test-Spezifikation (Testdrehbuch) + \begin{itemize*} + \item Phasenmodell des Testprozesses + \item Zusammenhang zur Anforderungsspezifikation, z.B. dort festgelegte Qualitätsziele + \item Zu testende Produkte + \item Zeitplan für die Tests + \item Abhängigkeiten der Testphasen + \item Aufzeichnung der Testergebnisse + \item Hardware\item und Softwareanforderungen + \end{itemize*} + \end{itemize*} + + Arten von Tests + \begin{itemize*} + \item Komponententest: Fehler in einzelnen Objekten oder Subsystemen, losgelöst vom umgebenden System + \begin{itemize*} + \item Umgebung muss nachgebildet werden + \end{itemize*} + \item Integrationstest: Zusammenspiel von Komponenten + \begin{itemize*} + \item Vollständiges System: Systemtest; Szenarios + \end{itemize*} + \item Strukturtest: innere Zustände, Interaktionen + \item Funktionstest: Anforderungen aus Lastenheft + \item Leistungstest: nichtfunktionale Anforderungen + \item Benutzbarkeitstest: Fehler in der Benutzungsschnittstelle, Verständlichkeit, Akzeptanz bei Anwendern + \begin{itemize*} + \item Prototypen + \end{itemize*} + \item Akzeptanztest, Installationstest: Kunde, Abnahme + \end{itemize*} + + Komponententests + \begin{itemize*} + \item Überprüft Verhalten einer Systemkomponenten im Vergleich zur Spezifikation + \item Da Tests bereits frühzeitig stattfinden sollten, ist Umgebung meist nicht vollständig implementiert + \begin{itemize*} + \item Teststumpf (stub, dummy) simuliert aufgerufene Komponenten + \item Testtreiber simuliert aufrufende Komponenten + \end{itemize*} + \item Vorgehensweisen + \begin{itemize*} + \item Bottom-up + \item Top-down + \item Sandwich + \item Schichtenweises Testen + \end{itemize*} + \end{itemize*} + + Systematisches Testen + \begin{itemize*} + \item Testfall + \begin{itemize*} + \item Beschreibung, Name + \item Zu testende Komponente, Testgegenstand (Pfad, Aufrufart) + \item Eingabedaten (Testdaten) + \item Erwartete Ergebnisse („Orakel“) + \item Protokoll (erzeugte Ausgaben) + \item Bewertung des Ergebnisses + \end{itemize*} + \item Weitere Begriffe + \begin{itemize*} + \item Regressionstest: erneute Durchführung eines Tests anhand einer geänderten Version des Testgegenstands + \item Alphatest: Test eines Prototypen durch Benutzer + \item Betatest: Test der vollständigen Software durch Benutzer + \end{itemize*} + \end{itemize*} + + Funktionaler Test (black box test) + \begin{itemize*} + \item Testfallauswahl beruht auf Spezifikation + \item Ohne Wissen über inneren Aufbau + \item E/A-Zusammenhang + \end{itemize*} + + Äquivalenzklassen im funktionalen Test + \begin{itemize*} + \item Problem: alle Kombinationsmöglichkeiten der Eingangsdaten sind zu umfangreich für vollständigen Test + \item Mögliche Einschränkung: Bildung von Äquivalenzklassen der Eingangsdaten, für die ähnliches Verhalten erwartet wird + \item Basierend auf Anwendungsdomäne + \item Äquivalenzklasse = Teilmenge der möglichen Datenwerte der Eingabeparameter + \item Test je eines Repräsentanten jeder Äquivalenzklasse + \item Finden von Äquivalenzklassen + \begin{itemize*} + \item Zulässige / unzulässige Teilbereiche der Datenwerte + \item Unterteilung der Bereiche nach erwarteten Ausgabewerten + \end{itemize*} + \end{itemize*} + + Grenztests + \begin{itemize*} + \item Ergänzung von Äquivalenztests: Spezialfälle + \item Rand der Äquivalenzklasse + \item Außerdem: Sonderfälle, erwartete Problemfälle (technisch) + \end{itemize*} + + Strukturtest (white box test, glass box test) + \begin{itemize*} + \item Testfallauswahl beruht auf Programmstruktur + \item Wie erreicht man möglichst vollständige Abdeckung? + \item Kontrollflussorientiert + \begin{itemize*} + \item Anweisungsüberdeckung anhand Quellcode + \item Zweigüberdeckung und + \item Pfadüberdeckung anhand des Flussgraphen reduzierte Variante: bounded interior Pfadtest + \end{itemize*} + \item Datenflussorientiert + \begin{itemize*} + \item defines / uses-Verfahren: Abarbeitungspfade von Definition zu jeder Verwendung von Variable oder Objekt durchlaufen + \end{itemize*} + \item Zustandsorientiert + \end{itemize*} + + \subsection{Testaktivitäten und Werkzeuge} + Wann wird getestet? + \begin{itemize*} + \item Während der Implementierung! + \begin{itemize*} + \item Auch wenn Schreiben von Tests scheinbar unproduktiv ist + \item Tests sind unbeliebt, da Probleme aufgezeigt werden + \item Aber: spätes Testen erhöht Aufwand! + \end{itemize*} + \item Inkrementell, d.h. für jede überschaubare Änderung + \item Spezielle Vorgehensweise: test first-Ansatz + \end{itemize*} + + Wie wird getestet? Geplant, systematisch, möglichst automatisiert, dokumentiert, wiederholbar + + Testplanung + \begin{itemize*} + \item Iterative Erstellung eines Testplans / Testdrehbuchs + \item Aktivitäten - Festlegen von + \begin{itemize*} + \item Teststrategie (Testumfang, Testabdeckung, Risikoabschätzung) + \item Testziele und Kriterien für Testbeginn, -ende und -abbruch + \item Vorgehensweise (Testarten) + \item Testumgebung (Beschreibung) + \item Hilfsmittel und Werkzeuge zum Testen + \item Testspezifikation + \item Testorganisation (Termine, Rollen, Ressourcen) + \item Fehlermanagement (Werkzeugunterstützung) + \end{itemize*} + \item Ergebnis: Inhalt des Testplans + \end{itemize*} + + Testspezifikation + \begin{itemize*} + \item Auswahl der zu testenden Testfälle + \item Definition einzelner Testfälle + \begin{itemize*} + \item Grundlage: Anwendungsfälle, Anforderungen, Fehlermeldungen (Zuordnung notwendig) + \end{itemize*} + \item Aktivitäten + \begin{itemize*} + \item Testfallfindung und Testfalloptimierung + \item Testfälle beschreiben (was genau ist zu testen) + \item Randbedingungen finden (Abhängigkeiten zu anderen Testfällen) + \item Festlegen und Erstellen der Eingabedaten + \item Festlegungen zum Testablauf und zur Testreihenfolge + \item Festlegen Soll-Ergebnis + \item Festlegung der Bedingung(en) für 'Test erfüllt'; ... + \end{itemize*} + \end{itemize*} + + Testvorbereitung + \begin{itemize*} + \item Tätigkeiten im Vorfeld des Tests + \item Aktivitäten + \begin{itemize*} + \item Vorbereitung der Tests entsprechend Testplan + \item Bereitstellen der Dokumente (Testspezifikation) + \item Verfügbar machen von Werkzeugen (Fehlermanagement) + \item Aufbauen der Testumgebung(en) + \item Integration der Entwicklungsergebnisse in die Testumgebung (Software installieren, konfigurieren, ...) + \item Bereitstellung von Testdaten bzw. Eingabedaten in die Testumgebung + \item Benutzer und Benutzerrechte anlegen + \end{itemize*} + \end{itemize*} + + Testdurchführung + \begin{itemize*} + \item Durchführung der spezifizierten Tests + \begin{itemize*} + \item Manuell + \item Automatisiert + \end{itemize*} + \item Aktivitäten + \begin{itemize*} + \item Auswählen der zu testenden Testfälle + \item Bereitstellen der Testdaten + \item Starten, Überwachen, Abbrechen, Beenden + \item Erfassung des Ist-Ergebnisses zur Auswertung + \item Besondere Vorkommnisse dokumentieren + \item Umgebungsinformationen für den Testlauf archivieren, ... + \end{itemize*} + \end{itemize*} + + Testauswertung + \begin{itemize*} + \item Überprüfung der Ergebnisse + \item Vergleich Ist-Ergebnis mit Soll-Ergebnis + \item Entscheidung Testergebnis (ok / Fehler) + \item Bei Fehler: + \begin{itemize*} + \item Klassifizierung (z. B.: Fehlerursache, Fehlerschwere etc.) + \item Fehler reproduzieren! + \item Angemessene Fehlerbeschreibung und –erläuterung: Nur ausreichend dokumentierte Fehler sind gültig und können bearbeitet werden! + \item Fehler im Fehlermanagement eintragen (Bug report) + \item Testfall bleibt offen + \end{itemize*} + \end{itemize*} + + Bugbeschreibung + \begin{itemize*} + \item Möglichst genaue Beschreibung des Fehlers + \item Ziel ist die Reproduzierbarkeit des Fehlers + \item Zuordnung zu Projektplan: Meilenstein, Version + \item Fehlerklassifikation + \begin{itemize*} + \item defect: Fehler in einer bestehenden Funktionalität + \item enhancement / feature: Funktionale Anforderung oder Erweiterung der bestehenden Funktionalität + \item task: Allgemeine Aufgabe + \end{itemize*} + \item Priorität festlegen + \begin{itemize*} + \item Unterschiedliche Stufen + \item Festlegung innerhalb eines Unternehmens / Projektes + \end{itemize*} + \item Prioritäten von Fehlern (bugs) + \end{itemize*} + + %| Stufe | Bedeutung | Verhalten | + %| -\item | -\item | -\item | + %| blocker | Schwerwiegender Fehler. Führt zur Arbeitsunfähigkeit anderer (Entwicklung, QA, Produktion,...). | Verdrängt alle anderen Aufgaben! Muss sofort gelöst werden, um Arbeitsfähigkeit wieder herzustellen. | + %| critical | Schwerer Fehler. Eine grundlegende Funktionalität des Systems ist nicht gegeben. Fehler muss bis zur nächsten Version behoben werden. System kann nicht verwendet werden. | Alle anderen Fehler (außer blocker) werden später gelöst. Bis zum nächsten Release muss dieser Bug gelöst sein. | + %| major | „normaler“ Fehler. Es tritt ein Fehler innerhalb einer Funktion des Systems auf. Das System kann jedoch weiterhin verwendet werden. | Fehler wird normal eingeplant. | + %| minor | Kleiner Fehler. Fehler behindert nicht weiter die Funktionsfähigkeit des Systems. Einfacher Work-Around vorhanden? | Je nach Aufwand und Zeitplanung erledigen. | + %| trivial | Schönheitsfehler. Fehler stört während des Betrieb des Systems nicht. | Je nach Aufwand „zwischendrin“ erledigen. Alle anderen Bugs bevorzugt lösen. | + + Testabschluss + \begin{itemize*} + \item Zusammenfassen der Tests + \item Gesamtstatus dokumentieren und kommunizieren + \item Entscheidungen herbeiführen z.B.: Auslieferung? + \begin{itemize*} + \item Ziele erreicht - nächste Schritte (Auslieferung) + \item Tests vorzeitig beenden oder unterbrechen + \item Gründe dokumentieren + \item Vollständiger Nachtest oder Teiltest möglich? + \end{itemize*} + \item Unterlagen archivieren + \end{itemize*} + + Testautomatisierung + \begin{itemize*} + \item Automatische Code-Validierung + \begin{itemize*} + \item Statisch: lint (C), Compiler + \item Dynamisch: run-time checking, memory leaks etc. + \end{itemize*} + \item Beispiel: Test-Framework JUnit + \end{itemize*} + + Behebung funktionaler Fehler + \begin{itemize*} + \item Log-Ausschriften bzw. Signale + \item Debugger: Vorwärts / Rückwärts + \item Haltepunkte setzen: Bedingte Haltepunkte für Schleifen + \item Darstellung der Variablenbelegung, Werte setzen + \item Analyse des Aufruf-Stacks + \end{itemize*} + + Behebung nichtfunktionaler Fehler + \begin{itemize*} + \item Geschwindigkeit: profiling z.B. mit Eclipse TPTP + \item Aufrufe, Zeitverbrauch in Methoden usw. + \end{itemize*} + + Memory Leaks, JProbe + \begin{itemize*} + \item Runtime heap summary: Welche Objekte verbrauchen Speicher? + \item Reference graph: Wer referenziert diese Objekte, so dass sie nicht per garbage collection gelöscht werden? + \end{itemize*} + + \subsection{Softwareverteilung} + Softwareverteilung (deployment) + \begin{itemize*} + \item Prozess zur Installation von Software auf + \begin{itemize*} + \item Anwender-PC‘s, Servern, Maschinen in Produktion ... + \end{itemize*} + \item Steuerung der Installation der Software + \item Voraussetzungen für die Software schaffen + \begin{itemize*} + \item Schulungen planen und durchführen + \end{itemize*} + \item Softwareverteilung ist ein kritischer Prozess! + \begin{itemize*} + \item Fehler können zu vielen Störungen und Ausfällen führen + \end{itemize*} + \item Ziele + \begin{itemize*} + \item Automatische Installation, Konfiguration und Wartung einer großen Anzahl von Systemen mit geringem Aufwand + \item Erreichen eines störungsarmen und sicheren Betriebs + \item Möglichst einheitliche Softwareversionen auf allen Systemen + \end{itemize*} + \end{itemize*} + + Installationsarten + \begin{itemize*} + \item Erstinstallation + \item Software-Update (Software-Aktualisierung) + \begin{itemize*} + \item Aktualisierung der Software, Daten oder Konfiguration + \end{itemize*} + \item Hotfixes und Service Packs + \begin{itemize*} + \item Nur bestimmte Teile der Software werden aktualisiert + \item Meist nur Fehlerbehebung, keine neuen Features + \end{itemize*} + \item Upgrade + \begin{itemize*} + \item Erweitert eine Software deutlich um neue Funktionen + \end{itemize*} + \item Unbeaufsichtigte (automatische) Installation + \begin{itemize*} + \item Installation erfolgt ohne Benutzereingriff + \item Periodisch, durch Aufruf des Anwenders, beim Programmstart + \item Einstellungen in einem Skript festgelegt oder werden als Parameter übergeben + \end{itemize*} + \end{itemize*} + + Installationshilfsmittel + \begin{itemize*} + \item Installationsprogramm (Installer) + \begin{itemize*} + \item Windows: Windows Installer, InstallShield + \item Linux: RPM, Port, APT + \item MAC-OS: Installer, WarpIn + \end{itemize*} + \item Installations-Script + \item Installationsanweisung + \end{itemize*} + + Software-Rollout + \begin{itemize*} + \item Vorgang des Veröffentlichens und Verteilens von Softwareprodukten auf entsprechende Clients + \item Anzahl der Clients kann weit über 10.000 liegen! + \item Rollout abhängig von verschiedenen Kriterien (Vorherige Installation, Hardwarekonfiguration, Zeit, Kunde) + \item Rollout-Varianten + \begin{itemize*} + \item Zentral / Dezentral + \item Manuell (Benutzer löst Installation aus) + \item Automatisiert (ohne Benutzerinteraktion) + \end{itemize*} + \end{itemize*} + + Vollständige Verteilung (big bang) + \begin{itemize*} + \item Alle Installationen werden mit einem Mal installiert + \item Sehr hohes Risiko + \item Eventuelle Fehler führen zu vielen fehlerhaften Zuständen oder Störfällen - führt zu hohem Druck + \item Eventuelle Fehler müssen schnell gelöst werden (Provisorium) + \item Sehr kurze Einführungsphase + \item Rollback-Mechanismus sehr empfohlen + \end{itemize*} + + Rollback + \begin{itemize*} + \item Wiederherstellung des Ursprungszustands + \item Technische Realisierung muss ermöglicht werden + \end{itemize*} + + Pilotierte Einführung + \begin{itemize*} + \item Einführung für wenige ausgewählte Installationen + \item Sehr hohe Sicherheit + \item Festlegung der späteren Rollout-Schritte + \item Benötigt zusätzliche Zeit + \item Geringere Auftrittswahrscheinlichkeit von Fehlern + \end{itemize*} + + Schrittweise (iterative) Einführung + \begin{itemize*} + \item Einführung erfolgt schrittweise mit einer definierten Anzahl + \item von Installationen (Rampe - ramp-up) + \item Höhere Fehlerwahrscheinlichkeit -> Bessere Reproduzierbarkeit -> schnelleres Finden von Fehlern -> Erfahrungsgewinn + \item Begrenztes Risiko, mittlerer Zeitaufwand + \end{itemize*} + + \section{Vorgehensmodelle} + \subsection{Einführung} + Wie läuft Softwareerstellung ab? + \begin{itemize*} + \item (oder besser, wie sollte sie ablaufen?) + \item Aufgaben und Phasen siehe vorangegangene Kapitel + \item Wann wird was getan? Abhängigkeiten? + \begin{itemize*} + \item Sequentiell / nebenläufig, + \end{itemize*} + \item Prozessmodelle der Softwareentwicklung + \begin{itemize*} + \item Regelwerke, Erfahrungen, best practices für große Projekte + \item Aktives Entwicklungsgebiet + \end{itemize*} + \item Erweiterbar zum Software-Lebenszyklus mit Inbetriebnahme, Wartung, Außerdienststellung usw. + \end{itemize*} + + Softwareentwicklungsprozess/Vorgehensmodell + \begin{itemize*} + \item Methode zur Erstellung von Softwaresystemen + \item Systematisch, rational und schrittweise erfolgender Weg vom Problem zur Lösung + \item Ziel: Softwareentwicklungsprozess übersichtlich, plan- und strukturierbar + \item Zerlegung des Softwareentwicklungsprozesses in überschaubare Einheiten + \item Unternehmensspezifisch, anpassbar, erweiterbar + \begin{itemize*} + \item Eigene Varianten, evtl. projektabhängig + \item An spezielle Bedürfnisse des Informationsbereichs angepasst + \item Kein allgemeingültiges Vorgehen + \item Einsetzbar in verschiedenartigen Projekten + \end{itemize*} + \end{itemize*} + + Phasen + \begin{itemize*} + \item Überwiegend zeitliche Zerlegung + \item Zeitlich begrenzte Phasen + \item Auch inhaltlich und organisatorisch begrenzte Phasen möglich + \item Teilprozesse / Aktivitäten + \begin{itemize*} + \item Inhaltliche Zerlegung + \item Satz von Aufgaben + \item Verteilung der Teilprozesse / Aktivitäten auf verschiedene Phasen + \item Begleitet von unterstützenden, übergreifenden Aktivitäten + \end{itemize*} + \end{itemize*} + + Aufgabe + \begin{itemize*} + \item Erzeugt Arbeitsergebnis (Artefakt) + \item Verbraucht Ressourcen (z.B. Arbeitskraft, Zeit, Ausrüstung) + \end{itemize*} + + Arbeitsergebnis (oder Artefakt) + \begin{itemize*} + \item Dokument, Modell, System, Programmcode Lastenheft, Spezifikation, Glossar, Handbuch usw. + \item Intern zu lieferndes Ergebnis + \end{itemize*} + + Teilnehmer und Rollen + \begin{itemize*} + \item Verantwortungsbereich eines Teilnehmers (z.B. Kunde, Projektmanager, Entwickler, Architekt) + \item Rolle bearbeitet / enthält Satz von Aufgaben + \end{itemize*} + + Unterstützungsprozesse / -Aktivitäten + \begin{itemize*} + \item Projektmanagement + \begin{itemize*} + \item Projektplanung, -verfolgung und -steuerung + \item Risikomanagement + \end{itemize*} + \item Anforderungsmanagement + \begin{itemize*} + \item Im Gegensatz zur Anforderungsaufnahme und -analyse + \end{itemize*} + \item Qualitätsmanagement + \begin{itemize*} + \item Problem Management + \item Softwaremetriken (Messung von Softwareeigenschaften) + \item Statische + dynamische Analyse (Bestimmung von Schwachstellen) + \end{itemize*} + \item Konfigurationsmanagement + \begin{itemize*} + \item Versionsverwaltung, Änderungsmanagement + \end{itemize*} + \item Dokumentation + \end{itemize*} + + \subsection{Sequenzielle Modelle} + \begin{itemize*} + \item Wasserfallmodell + \begin{itemize*} + \item Abhängigkeiten zwischen Teilergebnissen + \item Ursprung in System- Hardwareentwicklung + \begin{itemize*} + \item Wurde für die SW-Entwicklung übernommen + \item Auch heute verbreitetes Vorgehen bei HW-Entwicklung + \end{itemize*} + \item Sequenzielles Phasenmodell (Abschluss der Phasen) + \item Stark Dokumentengetrieben (Ergebnisse der Phasen) + \item Unterteilung in abgeschlossene Phasen: + \begin{itemize*} + \item Analyse + \item Design/Entwurf + \item Implementierung + \item Test \& Integration + \item Einführung, Betrieb \& Wartung + \end{itemize*} + \item Alternativ: + \begin{itemize*} + \item Planung + \item Definition + \item Entwurf + \item Implementierung + \item Test \& Integration + \item Einsatz und Wartung + \end{itemize*} + \item Vorteile + \begin{itemize*} + \item Einfach und verständlich, bekannt und verbreitet + \item Erleichterte Planung und Steuerung + \end{itemize*} + \item Nachteile + \begin{itemize*} + \item Idealisierte Annahme rein sequentiellen Ablaufs + \item Starke Abhängigkeiten zwischen Teilergebnissen + \item Ungeeignet, falls Anforderungen zu Beginn unklar + \item Unflexibel gegenüber Änderungen + \item Erst sehr spät greifbare Ergebnisse + \end{itemize*} + \end{itemize*} + \item Erweitertes Wasserfallmodell + \begin{itemize*} + \item Verbesserung für Änderungen und Fehler - Rückschritte + \end{itemize*} + \item Alternative Arten von Phasenmodellen + \begin{itemize*} + \item Sequenziell + \begin{itemize*} + \item Phasen strikt nacheinander, Dokumenten-orientiert + \item Keine Änderungen abgeschlossener Artefakte + \end{itemize*} + \item Nebenläufig + \begin{itemize*} + \item Phasen laufen teilweise parallel für bessere Zeitnutzung + \item Weiterhin keine Änderungen fertiger Dokumente + \end{itemize*} + \item Inkrementell + \begin{itemize*} + \item Unterteilung des Produkts in Teile + \item Schnellere Auslieferung von Teilfunktionalität nach vollständiger Aufnahme der Anforderungen + \end{itemize*} + \item Alternative: Evolutionär + \begin{itemize*} + \item Anforderungen entwickeln sich im Projekt + \item Ausgelieferte Versionen ergeben neue Anforderungen + \end{itemize*} + \item V-Modell [Boehm] + \begin{itemize*} + \item Explizite Adressierung der Qualitätssicherung + %\item %![VModell](Assets/Softwaretechnik1_VModell.png) + \item Entwicklung des V-Modells in Deutschland + \begin{itemize*} + \item Leitfaden, in Bundesbehörden ab 1990er verbindlich + \item Version V-Modell 97 erweitert um Werkzeuganforderungen, Rollen und Submodelle der Beteiligten + \item Kritik: schlecht skalier\item und anpassbar, zu unflexibel, + \item bürokratisch, nicht an moderner OO-SWEntw. orientiert + \end{itemize*} + \item V-Modell XT (extreme tailoring) + \begin{itemize*} + \item Aktuelle Version ab 2004/05 + \item Einfache projektspezifische Anpassbarkeit + \item Assistent www.v-modell-xt.de (kleines Projekt ~40 Dok.!) + \item Überprüfbarer Projektfortschritt + \item AG/AN-Sichten und Schnittstellen, Ausschreibungen + \item Gesamter SW-Lebenszyklus + \end{itemize*} + \end{itemize*} + \end{itemize*} + \end{itemize*} + + + \subsection{Iterative Modelle} + Iterativer Entwicklungsprozess + \begin{itemize*} + \item Spezifikation, Entwurf und Implementierung müssen immer wieder verändert und angepasst werden + \item Häufiges Integrieren, Validieren und Testen + \item "You should use iterative development only on projects that you want to succeed." [Fowler] + \end{itemize*} + + Inkrementelle Entwicklung + \begin{itemize*} + \item Wenn möglich, sollte es immer einen lauffähigen (unvollständigen) Prototypen geben + \item Neue Funktionen sofort integrieren + \item Neue Versionen gegenüber Anforderungen Validieren + \end{itemize*} + + %![Spiralmodell](Assets/Softwaretechnik1_Spiralmodell.png) + Spiralmodell + \begin{itemize*} + \item Risikogetrieben: Größte Projektrisiken identifizieren und als erstes bearbeiten (Prototyp?) + \item Spirale = iterativer Zyklus durch dieselben Schritte + \item Ziele jedes Durchlaufs aus alten Ergebnissen ableiten + \item Kosten/Nutzen abwägen + \item Regelmäßige Überprüfung des Prozessmodells + \item Anpassbar + \item Hoher Management-Overhead, große Projekte + \end{itemize*} + + Unified Process + \begin{itemize*} + \item Vorgehensmodelle zur objektorientierten Softwareentwicklung + \begin{itemize*} + \item Ivar Jacobson, Grady Booch and James Rumbaugh: The Unified Software Development Process, (Rational/IBM), 1999 + \end{itemize*} + \item Phasen der Entwicklung + \begin{itemize*} + \item Anfang, Ausarbeitung, Erstellung, Überleitung + \item Unterteilung in Iterationen + \item Definition von Meilensteinen + \end{itemize*} + \item Definition von Kernprozessen, die in den Phasen ablaufen + \begin{itemize*} + \item Geschäftsprozessmodellierung, Anforderungsanalyse, Analyse \& Design, Implementierung, Test, Auslieferung + \item In unterschiedlichen Anteilen parallel ablaufend! + \end{itemize*} + \end{itemize*} + + Prinzipieller Ablauf des Unified Process + %![Unified Process](Assets/Softwaretechnik1_UnifiedProcess.png) + \begin{itemize*} + \item Haupteigenschaften des UP + \begin{itemize*} + \item Inkrementell, iterativ, evolutionär + \item Anwendungsgetrieben + \item Architekturzentriert + \item Risikoorientiert + \item Ereignisorientiert + \item Nutzt die UML als Notationssprache + \item Erweiterbar / Anpassbar + \end{itemize*} + \item Verbreitete Vertreter + \begin{itemize*} + \item Rational Unified Process - RUP (Rational / IBM) + \item Open Unified Process - OpenUP (Eclipse Foundation) + \item Object Engineering Process - OEP (oose GmbH) + \end{itemize*} + \item Vorteile + \begin{itemize*} + \item Vorteile der Eigenschaften (iterativ, inkrementell, anpassbar, ...) + \item Berücksichtigung des Risikos + \item Passend für objektorientiertes Paradigmas und UML + \item Tool-Unterstützung + \item Reaktion auf Änderungen möglich + \item Industriestandard + \end{itemize*} + \item Nachteile + \begin{itemize*} + \item Hoher Bürokratischer Aufwand -> Tailoring notwendig! + \item Relativ hohe „Lernkurve“ aller Beteiligten + \item Keine schnelle Reaktion auf Änderungen + \item Keine integrierte Qualitätssicherung + \end{itemize*} + \end{itemize*} + + \subsection{Agile Methoden} + \begin{itemize*} + \item Ausgangspunkt + \begin{itemize*} + \item Ziv's Unsicherheitsprinzip des Software Engineering: "Unsicherheit ist im Software-Entwicklungsprozess und den Produkten inhärent und unvermeidlich." (Ziv, 1996) + \item Humphrey's Prinzip der Anforderungsunsicherheit: "In einem neuen Software System werden die Anforderungen solange nicht komplett bekannt sein, bis die Anwender damit arbeiten." (Humphrey, 1995) + \item Wegner's Lemma: "Es ist unmöglich, ein interaktives System komplett zu spezifizieren." (Wegner, 1995) + \end{itemize*} + \item Ziele + \begin{itemize*} + \item geringer bürokratischer Aufwand + \item Hauptziel ist die Softwareentwicklung + \item nur wenige Regeln bzw. Verhalten definiert + \item sehr flexibel gehaltenes Vorgehen + \item stark Anwendungs- und Ereignisorientiert + \item iterativ / inkrementell / evolutionär + \item sehr schnelle Entwicklungsiterationen + \item meist Architekturzentriert + \item auch testgetriebenes Vorgehen möglich + \item Berücksichtigung sozialer Aspekte + \item Softwareentwicklung: Kreative Arbeit von Kreativen + \end{itemize*} + \end{itemize*} + + Das Agile Manifest (2001) + \begin{itemize*} + \item Individuen und Interaktionen bedeutender als Prozesse und Tools + \item Funktionierende Software bedeutender als übermäßige Dokumentation + \item Stetige Zusammenarbeit mit dem Kunden bedeutender als Vertragsverhandlung + \item Mut und Offenheit für Änderungen bedeutender als Befolgen eines Plans + \end{itemize*} + + Eigenschaften agiler Vorgehensmodelle + \begin{itemize*} + \item Team ist für Ergebnis verantwortlich und organisiert sich selbst + \item Kleine Teams 5-8 Personen + \item Definition von Richtlinien, Werten und Prinzipien + \item Beispiele für Werte + \begin{itemize*} + \item Kommunikation (Kommunikation statt Dokumentation) + \item Einfachheit (KISS „Keep it small and simple“) + \item Feedback + \item Mut + \item Respekt + \end{itemize*} + \item Beispiele für Prinzipien + \begin{itemize*} + \item Beidseitiger Vorteil + \item Fehlschläge hinnehmen + \item Ständige Verbesserungen + \item Ständige Lauffähigkeit des Codes + \item Kleine Schritte + \item Wiederverwendung bestehender / bewährter Lösungen + \end{itemize*} + \item Beispiele für Praktiken + \begin{itemize*} + \item Pair-Programing, Coding Rules + \item Kollektives Eigentum / Gemeinsamer Codebesitz + \item Testgetriebene Entwicklung + \item Ständiges Refactoring + \item Keine Überstunden + \end{itemize*} + \item Vorteile agiler Methoden + \begin{itemize*} + \item Geringer bürokratischer Aufwand + \item Besseres Arbeitsklima (Berücksichtigung Sozialer Aspekte) + \item Ständige Verfügbarkeit einer lauffähigen Version + \item Mögliche / nötige Einflussnahme des Kunden + \item „Freie“ Wahl der Prinzipien/Regeln + \item Vermeidung von Spezialistentum und individuellem Besitz + \end{itemize*} + \item Nachteile + \begin{itemize*} + \item Schwierigeres Projektmanagement + \begin{itemize*} + \item Chaotische Vorgehen + \item Schwere Planbarkeit des Ergebnisses + \end{itemize*} + \item Notwendige Beteiligung des Kunden + \item Ergebnis ist schwer vorherzusagen + \end{itemize*} + \end{itemize*} + + \paragraph{eXtreme Programming (XP)} + \begin{itemize*} + \item Beck 1999, aus Kritik an „monumentalen Modellen“ + \item Evolutionäre Entwicklung in kleinen Schritten + \begin{itemize*} + \item Möglichst einfaches Design + \end{itemize*} + \item Konzentration auf Programmcode als Analyseergebnis, Entwurfsdokument und Dokumentation + \item Weglassen von explizitem Design, ausführlicher Dokumentation und Reviews + \item Code wird permanent lauffähig gehalten (täglich) + \item Schnell und flexibel + \item Erfordert Disziplin der Teilnehmer + \item Rollen: Projektleiter, Kunde (verfügbar), Entwickler + \begin{itemize*} + \item Max. 5-10 Entwickler + \end{itemize*} + \item Kunde bestimmt Anforderung und Prioritäten + \begin{itemize*} + \item planning game; story cards (use cases) + \end{itemize*} + \item Implementierung in kleinen Schritten + \begin{itemize*} + \item pair programming, collective code ownership + \item Häufige Releases inkl. Integration + \item Refactoring bei Designänderungen + \item Programmier-Konventionen + \end{itemize*} + \item Regelmäßiges automatisiertes Testen + \begin{itemize*} + \item test-first Ansatz + \end{itemize*} + \item Morgendliches Meeting im Stehen ohne Diskussionen + \item 40h-Woche + \item XP + \begin{itemize*} + \item Sammlung von 12 "best practices" + \item Test-getrieben + \item Flexibel, effizient + \item Kleine Teams + \item Erfordert Disziplin der Teilnehmer + %\item %![XP](Assets/Softwaretechnik1_XP.png) + \end{itemize*} + \end{itemize*} + + \paragraph{Scrum} + \begin{itemize*} + \item [Ken Schwaber, Jeff Sutherland und Mike Beedle] + \item Haupteigenschaften + \begin{itemize*} + \item Iterativ / Inkrementell, Evolutionär + \item stark Anwendungs- und Ereignisorientiert + \item schnelle Entwicklungsiterationen + \end{itemize*} + \item Sprint + \begin{itemize*} + \item eine schnelle Iteration: Dauer ca. 30 Tage + \item Festlegung welche Features umgesetzt werden + \end{itemize*} + \item Product Backlog + \begin{itemize*} + \item Liste der gewünschten Features des Produkts + \item Vom Produkt-Owner priorisiert / Aufwand vom Team geschätzt + \item Jeder kann Einträge beisteuern + \end{itemize*} + \item Rollen + \begin{itemize*} + \item Product Owner + \begin{itemize*} + \item Erfasst Bedürfnisse der Kunden und Stakeholder + \item Pflegt Backlog, definiert, priorisiert Features pro Sprint + \end{itemize*} + \item Scrum Master + \begin{itemize*} + \item Berät das Team, Überprüft Einhaltung von Werten und Techniken, moderiert die Meetings + \item Schützt das Team vor äußeren Störungen + \item Repräsentiert Team gegenüber Management + \end{itemize*} + \item Scrum Team (ca. 5-9 Personen) + \begin{itemize*} + \item Team organisiert sich und die Aufgaben selbst + \item Team bedeutet: Zielgerichtet und funktionsübergreifend arbeiten, gemeinsames Ziel verfolgen, selbstloses Handeln, Teamentscheidungen vertreten + \end{itemize*} + \end{itemize*} + \end{itemize*} + + Sprint Backlog + \begin{itemize*} + \item Für die aktuelle Iteration ausgewählte Aufgaben + \begin{itemize*} + \item Aufgabe nicht länger als 2 Tage Aufwand + \end{itemize*} + \item Team-Mitglieder wählen Tasks aus - keine Zuweisung + \item Restaufwand wird täglich aktualisiert - Burndown Chart + \item Team-Mitglied kann Tasks hinzufügen, löschen, ändern + \item Darstellung an prominenter Stelle + \end{itemize*} + + Daily Meeting + \begin{itemize*} + \item ca. 15 Minuten + \item Kurze Statusmeldung, Was wurde geschafft? Was ist zu tun? Was behindert den Fortschritt? + \item Weiterführende Diskussionen erst im Anschluss + \end{itemize*} + + %![Scrum Vorgehen](Assets/Softwaretechnik1_ScrumVorgehen.png) + + Sprint Review-Meeting + \begin{itemize*} + \item Präsentation des Erreichten (Feature Demo) + \item Product Owner, Kunde usw. geben Feedback + \begin{itemize*} + \item Neue Anforderungen hinzufügen / Neu priorisieren + \item Qualitätsansprüche ändern + \end{itemize*} + \end{itemize*} + + Sprint-Retrospektive + \begin{itemize*} + \item Rückkopplungsschleife + \begin{itemize*} + \item Was war gut und was hat nicht funktioniert? + \item Was kann verbessert werden? + \end{itemize*} + \item Nach jedem Sprint + \item Diskussion der identifizierten Probleme + \item Identifikation von wenigen „Action Items“ + \end{itemize*} + + Burndown Chart + \begin{itemize*} + \item Darstellung der offenen und erledigten Aufwände / Tasks + %\item %![Burndown Chart](Assets/Softwaretechnik1_Burndownchart.png) + \end{itemize*} + + \subsection{Zusammenfassung} + \begin{itemize*} + \item Software-Entwicklungsmethode + \begin{itemize*} + \item Elemente + \begin{itemize*} + \item Darstellung - Notation und Semantik für Modelle, Diagrammtypen, Dokumentvorlagen (Artefakte) + \item Vorgehensmodell - Phasen, Arbeitsschritte + \item Verfahren - Regeln, Anweisungen, Aktivitäten (+Rollen) + \item Werkzeuge + \end{itemize*} + \item Industriestandards: RUP + UML + \item Öffentliche Auftraggeber: V-Modell + \item Firmenintern: eigene Varianten, evtl. projektabhängig + \item Weitere Themen + \begin{itemize*} + \item Reifegradbeurteilung CMMI, SPICE, ISO 9000 + \end{itemize*} + \end{itemize*} + \item Charakterisierung von Vorgehensmodellen + \begin{itemize*} + \item Sequenziell + \begin{itemize*} + \item Teilprozesse strikt nacheinander + \item Keine Änderungen abgeschlossener Artefakte + \end{itemize*} + \item Nebenläufig + \begin{itemize*} + \item Teilprozesse laufen teilweise parallel für bessere Zeitnutzung + \end{itemize*} + \item Dokumentgetrieben + \begin{itemize*} + \item Erstellung von Dokumenten (Artefakte) im Vordergrund + \item Festlegung der Dokumente pro Phase + \end{itemize*} + \end{itemize*} + \item Charakterisierung von Vorgehensmodellen + \begin{itemize*} + \item Iterativ + \begin{itemize*} + \item Definition einer sich wiederholenden Abfolge von Teil-Prozessen bzw. Aktivitäten + \item Schnelles Wiederholen dieser Abfolgen + \end{itemize*} + \item Inkrementell + \begin{itemize*} + \item Definition und Kontrolle des Fortschritts pro Iteration + \item Kleine Erweiterungen + \end{itemize*} + \item Evolutionäres Vorgehen + \begin{itemize*} + \item Schnelle Prototypen + \item Lauffähiger Prototyp jederzeit vorhanden + \item Toolunterstützung (Versionierung) + \end{itemize*} + \end{itemize*} + \item Charakterisierung von Vorgehensmodellen + \begin{itemize*} + \item Ereignisorientiert + \begin{itemize*} + \item Schnelle Reaktion auf Anforderungsänderungen + \item Keine starre Abfolge von Tätigkeiten / Prozessen + \item Voraussetzung: Prozesse laufen parallel ab + \end{itemize*} + \item Architekturzentriert + \begin{itemize*} + \item Starke Gewichtung der Architektur + \item Verwendung von Modellen, Mustern und vorhandenem Wissen + \end{itemize*} + \item Anwendungsgetrieben + \begin{itemize*} + \item Orientierung an den Anwendungsfällen + \item Umsetzen, was einem Anwendungsfall zugeordnet werden kann + \item Anwender steht im Mittelpunkt (User Stories) + \end{itemize*} + \item Risikoorientiert + \begin{itemize*} + \item Risiko der Entwicklung wird in Planung berücksichtigt + \item Risiko- / Nutzen-Analyse + \end{itemize*} + \item Test- / Qualitätsgetrieben + \begin{itemize*} + \item Qualität steht im Vordergrund + \item Test wird während oder sogar vor der Implementierungs-phase erstellt + \end{itemize*} + \item Erweiterbar / Anpassbar (tailoring) + \begin{itemize*} + \item Nur Rahmen des Vorgehens festgelegt + \item Konkretes Vorgehen wird an die Bedürfnisse angepasst + \item Grundlegende Eigenschaft von Vorgehensmodellen + \end{itemize*} + \end{itemize*} + \item Softwareprojekt im Sommersemester + \begin{itemize*} + \item Auswahl aus 3 Vorgehensmodellen + \begin{itemize*} + \item Klassisches Vorgehen + \item Unified Process + \item Agiles Vorgehen + \end{itemize*} + \end{itemize*} + \end{itemize*} + + \section{Projektmanagement} + + Was ist ein Projekt? + \begin{itemize*} + \item Merkmale von Projekten + \begin{itemize*} + \item Zielgerichtetes Vorhaben + \item Einmaligkeit + \item Zeitliche, finanzielle und personelle Rahmenbedingungen + \item Abgrenzung zu anderen Vorhaben + \item Projektspezifische Organisation + \item Komplexität (Unterteilung in abhängige Teilaufgaben nötig) + \end{itemize*} + \item Unsicherheit vor allem in den Frühphasen + \item Risiko durch unbekannte Aufgabe + \end{itemize*} + + Was ist Projektmanagement? + \begin{itemize*} + \item Überbegriff für planende und durchsetzende Aktivitäten zur Vorbereitung und Durchführung eines Projekts + \item Management des Problemlösungsprozesses + \begin{itemize*} + \item Nicht die Lösung selbst, eigene Disziplin + \end{itemize*} + \item Aufgaben + \begin{itemize*} + \item Problemabgrenzung + \item Zielfestlegung, Ablaufplanung + \item Planung und Bereitstellung personeller, finanzieller und sachlicher Ressourcen + \item Führen der Projektgruppe und Koordination der Aktivitäten + \item Steuerung und Überwachung des Projektablaufes + \item Zum großen Teil Planungs- und Kommunikationsleistung! + \end{itemize*} + \end{itemize*} + + \subsection{Projektplanung} + Planung des Projektablaufs + \begin{itemize*} + \item Zunächst wieder: Teile und Herrsche! + \item Projektstruktur + \begin{itemize*} + \item Teilung der Projektaufgabe in Arbeitspakete (work packages) und darin enthaltenen Aktivitäten (activities) + \item Einteilung möglich anhand Produktstruktur, fachlicher Struktur oder Phasenmodell des Entwicklungsprozesses + \end{itemize*} + \item Überblick weiterer Planungsaufgaben + \begin{itemize*} + \item Bestimmen der Abhängigkeiten + \item Ermitteln der nötigen Ressourcen + \item Schätzen der Aufwände + \item Zeitplan aufstellen + \item Meilensteine definieren + \end{itemize*} + \end{itemize*} + %![Projektstruktur](Assets/Softwaretechnik1_Projektstruktur.png) + + Ablaufplanung + \begin{itemize*} + \item Abhängigkeiten (Anordnungsbeziehungen) zwischen Vorgängen A und B: 4 Möglichkeiten + \begin{itemize*} + \item Ende-Anfang (Normalfolge) + \begin{itemize*} + \item B kann begonnen werden, sobald A beendet worden ist + \end{itemize*} + \item Anfang-Anfang (Anfangsfolge) + \begin{itemize*} + \item B kann begonnen werden, sobald A begonnen worden ist + \end{itemize*} + \item Anfang-Ende (Sprungfolge) + \begin{itemize*} + \item B kann beendet werden, sobald A begonnen worden ist + \end{itemize*} + \item Ende-Ende (Endfolge) + \begin{itemize*} + \item B kann beendet werden, sobald A beendet worden ist + \end{itemize*} + \end{itemize*} + \item Netzplantechnik + \begin{itemize*} + \item Planungsarten + \begin{itemize*} + \item Vorwärtsplanung (ab Startzeitpunkt) + \item Rückwärtsplanung (ab gewünschtem Projektende) + \end{itemize*} + \item Berechnete Daten für Vorgänge + \begin{itemize*} + \item Frühester und spätester Anfangszeitpunkt (FAZ / SAZ) + \item Frühester und spätester Endzeitpunkt (FEZ / SEZ) + \item Pufferzeiten, z.B. freier Puffer (Verzögerung ohne Verschiebung des Nachfolgers), Gesamtpuffer (Verzögerung ohne Gefährdung des Projektendes) + \item Notation unterschiedlich + \end{itemize*} + \item Allgemein + \begin{itemize*} + \item Kritischer Pfad (Verzögerung vergrößert Projektdauer) + \item Kritische Vorgänge: Teil des kritischen Pfades + \end{itemize*} + \end{itemize*} + \end{itemize*} + + Beispiel: + \begin{itemize*} + \item Arbeitspakete laut Pflichtenheft (z.B.: Use Case) + \item Aufgaben festlegen + \item Abhängigkeiten festlegen + \item Vorwärtsrechnung durchführen + \item Rückwärtsrechnung durchführen + \item Kritischer Pfad und Puffer finden + %\item %![Projektplanung](Assets/Softwaretechnik1_ProjektplanungBeispiel.png) + \end{itemize*} + + Aufwandsschätzung + \begin{itemize*} + \item Aus Erfahrungswerten systematisiert + \item Versuch, wichtige Einflussfaktoren zu erfassen + \begin{itemize*} + \item Metriken für Spezifikationen + \item Komplexität von Teilfunktionen + \item Menge der Funktionen + \item Anpassung durch individuelle Faktoren, z.B. abhängig von Erfahrung in der Projektorganisation + \end{itemize*} + \item Methoden + \begin{itemize*} + \item Function Point Analyse + \item CoCoMo + \end{itemize*} + \end{itemize*} + + \paragraph{Function Point Analyse} + \begin{itemize*} + \item Ursprung IBM Ende 1970er Jahre + \item Funktionsumfang und Schwierigkeitsgrad von Software + \item Verschiedene Verfahren + \begin{itemize*} + \item für Echtzeit- (Full Function Point Method) und „normale“ Software (Int. Function Point User Group, ISO14143) + \end{itemize*} + %\item %![FPA](Assets/Softwaretechnik1_FPA1.png) + \item Jeweils Anzahl x Gewicht + \item Summe aller Werte = Unadjusted Function Points (UFP) + \item Function Points = UFP x EG + \item Einflussgrad EG = 1 + 0.01 x SummeEinflussfaktoren + \item Einflussfaktoren: Einfluss auf Anwendungsentwicklung + %\item %![FPA2](Assets/Softwaretechnik1_FPA2.png) + \item Berechnung der Personen-Monate aus Erfahrungen vorangegangener Projekte + \begin{itemize*} + \item Aufwand, der von einer Person in einem Monat unter Idealbedingungen erledigt werden kann + \end{itemize*} + \item Umrechnung mit Tabelle (nichtlinearer Verlauf) + %\item %![FPA3](Assets/Softwaretechnik1_FPA3.png) + \end{itemize*} + + \paragraph{CoCoMo II} + \begin{itemize*} + \item Constructive Cost Model [Boehm2000] + \item Ausgangspunkt: geschätzte Anzahl Zeilen Quellcode + \begin{itemize*} + \item SLOC, source lines of code (zB. aus UFP schätzen) + \end{itemize*} + \item Aufwand Personen-Monate (PM) $PM = A * Size^E \prod_{i=1}^n EM$ mit $E=B+0,01*\sum_{j=1}^5 SF_j$ + \item Faktoren $A=2.94$ und $B=0.91$ (anpassbare Koeffizienten) + \item Effort multiplier $EM: n=6..16$, Tabelle nach Boehm + \begin{itemize*} + \item Beispiele: Komplexität, Wiederverwendbarkeit, ... + \item Werte $0,7 .. 3,0$ + \end{itemize*} + \item Scale factor SF: Fünf Einflüsse auf Rentabilität der Softwareentwicklung + \item Notwendige Entwicklungszeit (time to develop) $TDEV = C * PM^F$ mit $F = D + 0,2 * ( E - B )$ + \item Faktoren $C=3,67$ und $D=0,28$, anpassbar + \item Ressourcenplanung %![Ressourcenplanung](Assets/Softwaretechnik1_Ressourcenplanung.png) + \item Zeitplanung + \begin{itemize*} + \item Zeitplan aus Abhängigkeiten, Aufwänden und Ressourcen sowie festen Terminen + \item Darstellung als Gantt-Chart / Balkendiagramm + \end{itemize*} + \end{itemize*} + + \subsection{Projektdurchführung} + Projektorganisation + \begin{itemize*} + \item Teilnehmer: Personen, Rollen, Verantwortung, Teams + \item Linienorganisation: + \begin{itemize*} + \item hierarchisch %![hierarchisch](Assets/Softwaretechnik1_Organisation_hierarchisch.png) + \item Matrixorganisation %![matrix](Assets/Softwaretechnik1_Organisation_matrix.png) + \item Reine Projektorganisation: Mitarbeiter werden aus Organisation herausgelöst und Projektleiter unterstellt + \end{itemize*} + \end{itemize*} + + Projektmanager - Rolle und Aufgaben + \begin{itemize*} + \item Planung, Start, Kontrolle und Beenden des Projekts + \item Schnittstelle zur Umgebung des Projekts + \begin{itemize*} + \item Kunden, Unterauftragnehmer, interne Kontakte, Verträge + \end{itemize*} + \item Team zusammenstellen und steuern + \begin{itemize*} + \item 5-7 Mitglieder gemischter Qualifikation + \item Team von äußeren Aufgaben abschirmen + \item Teilaufgaben definieren, vergeben und koordinieren + \item Fortschritt kontrollieren und Probleme beseitigen + \end{itemize*} + \item Weitere Ressourcen bereitstellen + \item Notwendige Planänderungen erkennen und reagieren + \item Wichtiger Dienstleister für den Projekterfolg + \end{itemize*} + + Projektstart + \begin{itemize*} + \item Nach Abschluss der Planungsphase + \item Festlegung von ... + \begin{itemize*} + \item Arbeitsstil und interne Organisation + \item Aufgabenverteilung und Themen-Verantwortung + \item Erste Aufgaben, Verantwortliche und Termine + \item Einigung über Meilensteine und Termine + \item Art und Termine der Projekttreffen + \item Informationen und Kommunikationswege + \item Technische Infrastruktur (Versionskontrollsystem, Entwicklungsumgebung, Dokumentverwaltung, Rechnerzugang, verwendete PM-Software usw.) + \end{itemize*} + \item Starttreffen des Projekts (kick-off meeting) + \end{itemize*} + + Meetings / Projekttreffen + \begin{itemize*} + \item Regelmäßige Abstimmung der Projektteilnehmer + \begin{itemize*} + \item Außerdem zu wichtigen Meilensteinen + \end{itemize*} + \item Inhalt und Ablauf: geplant (Tagesordnung), Moderator + \begin{itemize*} + \item Protokoll des letzten Treffens korrekt? + \item Aktueller Stand + \item Bericht über individuelle Aufgaben + \item Planung des nächsten Termins + \end{itemize*} + \item Protokoll + \begin{itemize*} + \item Datum, Zeit, Ort, Teilnehmer, Moderator + \item Bezeichnung + \item Tagesordnung mit einzelnen Punkten + \item Kurz und knapp, neutral bei Diskussionen! + \end{itemize*} + \end{itemize*} + + Fortschrittskontrolle + \begin{itemize*} + \item Meilensteine + \begin{itemize*} + \item Klar definiertes Zwischenresultat zur Beurteilung des Projektfortschritts + \item Beispiele: Feinentwurfsdokument fertiggestellt und an Auftraggeber übergeben oder Paket XYZ implementiert und fertig getestet + \end{itemize*} + \item Besprechung in Projekttreffen + \begin{itemize*} + \item Besprechung des Status jedes Meilensteins / jeder Aufgabe + \item Welche Aufgaben sind bereits erledigt? + \item Welche Probleme sind aufgetreten / gelöst? + \item Verbleibender Aufwand - Terminverschiebung nötig? + \item Planung der nächsten Schritte (Aufgabe, Verantwortlicher, Termin) + \end{itemize*} + \end{itemize*} + + Meilenstein-Trendanalyse + \begin{itemize*} + \item Technik zur Fortschrittskontrolle + \item Überwachung des Projektfortschritts zur Erkennung von Terminverzögerungen + \item Bei Verzögerungen: + \begin{itemize*} + \item Ressourcen erhöhen + \item Termine verschieben + \item Funktionen reduzieren + \end{itemize*} + \end{itemize*} + + Wie viel Planung? + \begin{itemize*} + \item Planung ist wichtig, aber nicht übertreiben! + \item Aufwand und Detaillierungsgrad der Planung an Projektgröße und „echten“ Aufwand anpassen + \item Pläne müssen sich ändern können! + \begin{itemize*} + \item Projekte sind einmalig und daher unvorhersehbar + \end{itemize*} + \item Adaptiv planen: nächste Aufgaben genau, spätere grob + \item Einsatz von Projektmanagement-Software + \item Projektende + \begin{itemize*} + \item Abschlusstreffen + \item Bewertung von Ergebnis und Organisation - was kann in Zukunft besser gemacht werden? + \end{itemize*} + \end{itemize*} + +\end{multicols} + +\end{document} \ No newline at end of file diff --git a/Softwaretechnik - MindMap.pdf b/Softwaretechnik - MindMap.pdf deleted file mode 100644 index f6d961e..0000000 Binary files a/Softwaretechnik - MindMap.pdf and /dev/null differ diff --git a/Softwaretechnik - MindMap.tex b/Softwaretechnik - MindMap.tex deleted file mode 100644 index c6dc9e9..0000000 --- a/Softwaretechnik - MindMap.tex +++ /dev/null @@ -1,402 +0,0 @@ -\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 (<>)}} - } - 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}