4385 lines
183 KiB
TeX
4385 lines
183 KiB
TeX
|
\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 (<<import>>)
|
|||
|
|
\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*}
|
|||
|
|
|
|||
|
|
%
|
|||
|
|
%
|
|||
|
|
|
|||
|
|
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*}
|
|||
|
|
|
|||
|
|
%
|
|||
|
|
|
|||
|
|
%| | 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*}
|
|||
|
|
|
|||
|
|
|
|||
|
|
%
|
|||
|
|
%
|
|||
|
|
|
|||
|
|
\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*}
|
|||
|
|
|
|||
|
|
%
|
|||
|
|
%
|
|||
|
|
|
|||
|
|
\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 <<component>>
|
|||
|
|
\begin{itemize*}
|
|||
|
|
\item Kapselt Funktionalitäten (Physisch gruppierte Klassen)
|
|||
|
|
\item „Spezialisierte“ Klasse (Vererbung, Exemplare möglich)
|
|||
|
|
\item Stellt Funktionalitäten über Schnittstellen bereit
|
|||
|
|
\item Definiert benötigte Schnittstellen
|
|||
|
|
\item Enthält Klassen oder weitere Komponenten
|
|||
|
|
\item Modulares Element: Substitution (Austauschbarkeit) steht im Vordergrund
|
|||
|
|
\end{itemize*}
|
|||
|
|
\item Black-Box-Darstellung
|
|||
|
|
\begin{itemize*}
|
|||
|
|
\item Zur Verfügung gestellte Funktionalität `<<provided interfaces>>`
|
|||
|
|
\item Benötigte Funktionalität `<<required interfaces>>`‚
|
|||
|
|
\end{itemize*}
|
|||
|
|
\item White-Box-Darstellung
|
|||
|
|
\begin{itemize*}
|
|||
|
|
\item Interner Aufbau der Komponente `<<realization>>`
|
|||
|
|
\item Artefakte `<<artifacts>>`‚ Realisierende physische Einheit (z.B.: .dll)
|
|||
|
|
\end{itemize*}
|
|||
|
|
\end{itemize*}
|
|||
|
|
\end{itemize*}
|
|||
|
|
|
|||
|
|
Schnittstellen / Interfaces
|
|||
|
|
\begin{itemize*}
|
|||
|
|
\item Definition Diagrammunabhängig
|
|||
|
|
\begin{itemize*}
|
|||
|
|
\item Meist Klassendiagramm
|
|||
|
|
\end{itemize*}
|
|||
|
|
\item Ähnlich Semantik einer Klasse
|
|||
|
|
\begin{itemize*}
|
|||
|
|
\item Nur public-Attribute und Operationen
|
|||
|
|
\end{itemize*}
|
|||
|
|
\item Definiert Verpflichtung zur Implementierung von
|
|||
|
|
\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: <<Interface>>
|
|||
|
|
\item Meist kursiv geschrieben, da abstrakte Klasse
|
|||
|
|
\end{itemize*}
|
|||
|
|
\end{itemize*}
|
|||
|
|
|
|||
|
|
Schnittstellenrealisierung, Implementierungsbeziehung
|
|||
|
|
\begin{itemize*}
|
|||
|
|
\item Schnittstellen werden realisiert, nicht instanziiert
|
|||
|
|
\item Schnittstellenkonform
|
|||
|
|
\begin{itemize*}
|
|||
|
|
\item Klasse realisiert alle Attribute und Operationen
|
|||
|
|
\end{itemize*}
|
|||
|
|
\item 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 <<abstract>>
|
|||
|
|
\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 <<interface>> 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 <<precondition>>
|
|||
|
|
\item Nachbedingung: Prädikat, das nach Aufruf gelten muss <<postcondition>>
|
|||
|
|
\item Invariante: Prädikat, das immer gilt <<invariant>>
|
|||
|
|
\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*}
|
|||
|
|
|
|||
|
|
%
|
|||
|
|
|
|||
|
|
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 %
|
|||
|
|
\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
|
|||
|
|
\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
|
|||
|
|
%
|
|||
|
|
\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 %
|
|||
|
|
\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*}
|
|||
|
|
|
|||
|
|
%
|
|||
|
|
|
|||
|
|
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 %
|
|||
|
|
\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*}
|
|||
|
|
%
|
|||
|
|
|
|||
|
|
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 %
|
|||
|
|
\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 %
|
|||
|
|
\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 %
|
|||
|
|
\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 %
|
|||
|
|
\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 %
|
|||
|
|
\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 %
|
|||
|
|
\item Matrixorganisation %
|
|||
|
|
\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}
|