664 lines
42 KiB
TeX
664 lines
42 KiB
TeX
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||
% writeLaTeX Example: A quick guide to LaTeX
|
||
%
|
||
% Source: Dave Richeson (divisbyzero.com), Dickinson College
|
||
%
|
||
% A one-size-fits-all LaTeX cheat sheet. Kept to two pages, so it
|
||
% can be printed (double-sided) on one piece of paper
|
||
%
|
||
% Feel free to distribute this example, but please keep the referral
|
||
% to divisbyzero.com
|
||
%
|
||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||
% How to use writeLaTeX:
|
||
%
|
||
% You edit the source code here on the left, and the preview on the
|
||
% right shows you the result within a few seconds.
|
||
%
|
||
% Bookmark this page and share the URL with your co-authors. They can
|
||
% edit at the same time!
|
||
%
|
||
% You can upload figures, bibliographies, custom classes and
|
||
% styles using the files menu.
|
||
%
|
||
% If you're new to LaTeX, the wikibook is a great place to start:
|
||
% http://en.wikibooks.org/wiki/LaTeX
|
||
%
|
||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||
|
||
\documentclass[10pt,landscape]{article}
|
||
\usepackage{amssymb,amsmath,amsthm,amsfonts}
|
||
\usepackage{multicol,multirow}
|
||
\usepackage{calc}
|
||
\usepackage{ifthen}
|
||
\usepackage[landscape]{geometry}
|
||
\usepackage[colorlinks=true,citecolor=blue,linkcolor=blue]{hyperref}
|
||
\usepackage{helvet}
|
||
\renewcommand{\familydefault}{\sfdefault}
|
||
%%Packages added by Sebastian Lenzlinger:
|
||
\usepackage{enumerate} %% Used to change the style of enumerations (see below).
|
||
|
||
\usepackage{enumitem}
|
||
\usepackage{fancyhdr}
|
||
\newtheorem{definition}{Definition}
|
||
\newtheorem{theorem}{Theorem}
|
||
\newtheorem{axiom}{Axiom}
|
||
\newtheorem{lem}{Lemma}
|
||
\newtheorem{corr}{Corollary}
|
||
|
||
\usepackage{tikz} %% Pagacke to create graphics (graphs, automata, etc.)
|
||
\usetikzlibrary{automata} %% Tikz library to draw automata
|
||
\usetikzlibrary{arrows} %% Tikz library for nicer arrow heads
|
||
%%End
|
||
\usepackage{wrapfig}
|
||
|
||
\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} }
|
||
}
|
||
\pagestyle{empty}
|
||
\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
|
||
\setcounter{secnumdepth}{0}
|
||
\setlength{\parindent}{0pt}
|
||
\setlength{\parskip}{0pt plus 0.5ex}
|
||
% -----------------------------------------------------------------------
|
||
\pagestyle{fancy}
|
||
\fancyhead{}
|
||
\fancyfoot{}
|
||
% Set the right side of the footer to be the page number
|
||
\fancyfoot[R]{\thepage}
|
||
\title{Software Engineeriung HS22 UniBas}
|
||
|
||
\begin{document}
|
||
|
||
\raggedright
|
||
\footnotesize
|
||
|
||
\begin{center}
|
||
\Large{\textbf{Sweng HS22}} \\
|
||
\end{center}
|
||
\begin{multicols*}{3}
|
||
\setlength{\premulticols}{1pt}
|
||
\setlength{\postmulticols}{1pt}
|
||
\setlength{\multicolsep}{1pt}
|
||
\setlength{\columnsep}{1pt}
|
||
|
||
\section{Intro}
|
||
\subsection{Warum ist Sweng Wichtig?}
|
||
\begin{itemize}
|
||
\item Komplexität geht stetig rauf.
|
||
\item Technologien sind reif und Infrastruktur vorhanden: 80J Computer, 60J $\mu$Prozessor, 40J Internet, 20 Jahre Smartphones.
|
||
\item Probleme der Komplexität:
|
||
\begin{itemize}
|
||
\item Wie versteht man ein Multi-File Programm?
|
||
\item Wie ändert man ein Multi-File/riesiges Programm/Code-base?
|
||
\item Wie findet man in solchen Projekten Fehler?
|
||
\end{itemize}
|
||
\end{itemize}
|
||
\subsection{Was ist Sweng?}
|
||
\begin{itemize}
|
||
\item "The application of a systematic, disciplined, and quantifiable approach to the developement, operation, and maintenance of software"\textsubscript{-IEEE Standard Glossary of S.E.T.}
|
||
\item "The multi-person construction of multi-version software"\textsubscript{-David Parnas}
|
||
\item More than coding; At the center of informatics but more than that; Teamwork/Interdisciplinary.
|
||
\end{itemize}
|
||
|
||
\section{Eigenschaften von Software}
|
||
|
||
\subsection{Das Produkt "Software"}
|
||
|
||
Was ist speziell an Software als Produkt?
|
||
\begin{itemize}
|
||
\item Formbarkeit(\textit{Software is malleable}): Software als Produkt lässt sich leicht und ohne teuren Änderungen an den Produktionsanlagen verändern. Software Design ist jedoch starr; Software wird ohne Designänderungen angepasst: \textbf{Produktion \& Design divergieren}.
|
||
\item Immaterialität: Traditionelles Produkt: Herestellung grösster Kostenfaktor. Fokus auf garantie reibungslose Produktion. QS in Produktion. \textbf{Software:} Herstellung is trivial (kopieren). Fokus liegt auf \textit{Design \& Implementation}. QS geschieht \textit{im Entwicklungsprozess}.
|
||
\item Keine Naturgesetze: Es gibt meine/wenige vordefinierte Regeln/Strukturen. Der Lösungsraum ist nicht von Vornherein klar. Das logsiche Folgern/Ableiten von Eigenschaften ist schwierig: Entwicklung und Verifikation dadurch erschwert. \textbf{Alle logischen Strukturen und Regeln müssen explizit design und dokumentiert werden.}
|
||
\item \textbf{Zusammenfassung: }Software leicht änderbar - Design nicht. Qualität der Sw. in der Entwicklung gesichert. Keine verlässlichen Strukturen vorgegeben. Folgerung: \textbf{Sw.entwicklung braucht disziplin und gute Prozesse.} Enter Sweng.
|
||
\end{itemize}
|
||
|
||
\subsection{Qualitätsmerkmale von Software}
|
||
Intern: Sieht Entwicklerteam. Extern: Sieht Benutzer.
|
||
\includegraphics[scale=0.2]{images/taxonomieQS.png}\\
|
||
|
||
\textbf{Korrektheit: }•Spezifische \textit{Anforderungen} erforderlich. •Korrektheit ist absolut (Code ist NICHT "ein bisschen falsch"). •Formale Spezifikation erlauben Korrektheitsbeweise.
|
||
\textit{Softzware ist korrekt, wenn sie die spezifizierten funktionalen Anforderungen erfüllt.}\\
|
||
\textbf{Zuverlässigkeit: }\textit{W.keit, dass in einem bestimmten Zeitintervall kein Fehler auftritt.}. Aka. Benutzer kann sich auf Sw. verlassen. $\text{Korrekt}\subseteq \text{Zuverlässig}$.\\
|
||
\textbf{Robustheit: }Software verhält sich auch in unvorhergesehenen Situationen Sinnvoll: Netzwerkausfall, Hardwareausfall, Input ist Quatsch. Diese Eigenschaft ist nicht leicht zu spezifizieren. Korrektheit vs. Robustheit: Anforderung spezifiziert -> Korrektheit. Anforderung nicht spez. -> Robustheit.\\
|
||
\textbf{Wartbarkeit: }Wie einfach lässt sich die Sw. weiterentwickeln und neuen Gegebenheiten anpassen?
|
||
Wieso Wartbarkeit: Software Aging. Wieso gibt es Software-Aging?: •Neue Hardware •Neue OS •Neue Anforderungen an SW. (Gesetzte, Marktdruck) •Fehlerbehebung • Verbesserung (Performance/Wartbarkeit etc.). \textbf{Meisten kosten NACH der Entwicklung.}\\
|
||
\textbf{Verständlichkei: }Wie gut findet man isch im Code zurecht. Ist er einfach zu verstehen? Für jemand der es nicht selbst geschrieben hat?\\
|
||
\textbf{Wiederverwendbarkeit: }Ist es einfach die SW. in einem anderen Kontext wiederzuverwenden? Lsg.ansatz:•Komponentenbasierte Entwicklung: Kosten für Verifikation, Wartung etc. /Komponente und nicht /Produkt.\\
|
||
\textbf{Portabilitzät: }Grad der Platformabhängikeit. Bsp. Plattformen: •Browser •OS •Hardware(AMD, Apple Silicon, Intel)\\
|
||
\textbf{ZF: } \\•Korrektheit von SW. wird immer durch Anforderungen bestimmt - Ohne Anforderungen keine Korrektheit, nur Robustheit.\\•Gute Software is Wartbar: Wartung verursacht Grossteil der Kosten. Das Qualitätskriterum "Wartbarkeit" ist durch viele andere Q.krit. beeinflusst.
|
||
|
||
\textbf{Prozessmerkmale:}•Transparenz •Verfpgbarkeit •Produktivität
|
||
|
||
\subsection{No Silver Bullet. Frederick P. Brooks, Jr. ZF. und Analyse}
|
||
"Fashioning complex conceptual constructss is the \textit{essence; accidental}-tasks arise im representing the constructs in language. Past progress has so reduced the accidental tasks that future progress now depends upon addressing the essence."\textsubscript{-F.P.Brooks,Jr.}\\
|
||
Weder techonolgische noch management Entwicklungen versprechen eine Verbesserung der Produktivität, der Einfachheit und der Verlässlichkeit um grössenordnungen. \\
|
||
•Essence: Difficulties inherent in Sw.\\
|
||
•Accidents: those that attend but are not inherent\\
|
||
Hard Part of Building Sw.: Specification, design, testing of the conceptual construct, not the labour of representing it and testing the fidelity thereof.\\
|
||
Essentielle Eigenschaften von Sw.:
|
||
•Complexity: Erschwierigt kommunizieren in und zwischen Teams führt zu Fehler im Produkt, zu hoehn Kosten, verspätungen. Erwietern ist nicht repetitive sondern Produziert neue Komplexitäten. Die Enumerierung und das Verstehen werden der möglichen Zustände der Sw. führt zu Unzuverlässlichkeit. Die Komplexität v. Funktionen führt dazu, dass sie schwierig aufzurufen sind. Die Copmlexe Struktur führt zur Schwierigkeit, die Sw. zu erweitern, ohne Seiteneffekte einzuführen.\\
|
||
•Conformity: SW. muss Menschen gerecht werden und verschieden Sprachen, Kulturen, Gewohnheiten gerecht werden. Das ist arbiträre Komplexität die nicht aufgehoben werden kann. Aka: Die interfaces sind unendlich vielfältig und verändern sich nicht weil sie müssen, sondern weil sie von verschieden Personen designt wurden. Die komplexität der Konformität von Sw. zu Interfaces kann nicht durch redesign simplifiziert werden.\\
|
||
•Changeability: Weil Sw. in einer ewig-verändernder Matrix aus Applikationen, Gesetzten, HW lebt, wird sie ewig zum anpassen und assimilieren gezwungen. \\
|
||
•Invisibility: Sw. ist unsichtbar und undarstellbar. Die Strukturen der Sw. sind also schwer zu überschauen. Tools etc. können zwar helfen, aber werden nicht eine verbesserung in der Grössenordung versprechen.\\
|
||
\textbf{Möglcihe Silver bullets, und wieso sie doch nicht solche sind.}\\
|
||
Die meisten Verbesserungen haben die Accidents aber nicht die Essenz v. SW. verbessert.
|
||
\textit{HighLvlLang:}Address: Accidental complexity of LowLvl Programming into more abstract realm. why not: Complexities have now been removed and marginal reduciton will not be order of magnitude.\\
|
||
\textit{Obect-Oriented programming: }Addresses: Removes higher order accidental complexity of representation in teh computer to express the design one wants to achieve. Why not: can only remove all accidental problems from the expression of design. The complexity of the design itself is unchanged.
|
||
\textit{AI: }problem is knowign what to say not saying it. expert systems need experts. \\
|
||
\textit{Graphical Programming: }sw. is fundamentally not visaalizable.\\
|
||
\textit{Sw. verification:} Sw. verification does not mean a error proof sw. Verification can only establish that sw. meets its specification, but that mustn't be a complete not consistent specification. The specification itself must be debugged...\\
|
||
\textbf{Promising attacks on conceptual essence: }\\
|
||
Problem w/ techonogical breakthroughs/attacks on the essence is that they're limited by productivity. If no more improvements can be made in that respect, attacks on the essence of software should be done:\\
|
||
•Buy don't Build: Specialization und tried and teseted sofware is probably better, cheaper\\
|
||
•Requirements refinement and rapid prototyping: Hardest part of building system is deciding what to build: Iterative extraction and refinement of the requirements. So developeing approaches for rapid prototyping and iterative specification refinement would attack the essence of the problem.: formulating what one wants and knowing how it looks.\\
|
||
•Incremental dev. - grow dont build: First get it to run and then piece by piece build it up.Then, at every stage of the process, one has a working system.\\
|
||
•Great designers\\
|
||
\section{Prinzipien der Softwareentwicklung}
|
||
$\text{Prinzipien(=stabiler Kern)}\subset\text{Methoden/Techniken(um Prinzipien zu folgen)}\subset\text{Methodologien(Begründen weshalb eine Methode gut ist)}\subset\text{Tools=schnelllebige Werkzeuge}$.
|
||
\textbf{Was sind gute Prinzipien?} Abstrakt und Falifizierbar. Bsp. Schlecht: use JUnit/ schreibe qualitativ gute Sw. Bsp. gut: Schreibe Tests immer zuerst.
|
||
\textbf{Wichtige Prinzipien: }\\
|
||
•Genauigkeit und formales Vorgehen: (unereichbares) Ideal: Mathematische Präzision. Erreichbar: klare Regeln; klare Prozesse; eindeutig defi. Anforderungen; rigurose Tests.\\
|
||
•Seperation of cencerns: Devide and Conquer; reduziert komplexität; Aufgaben und Verantwortung können verteilt un Paralellisiert werden. Produkt: Anforderungen Separat betrachten: Funktionalität; Performance; GUI etc. Prozess: Testing und Entwicklung (versch. Teams?); Phasen im Wasserfallmodell.\\
|
||
•Modularität: Komplexes System in kleine Teile zerlegt;\textbf{Wichtigstes Prinzip der Sw. Entwicklung}; reduziert Komplexität und somit erlaubt erst Trennung der Verantwortung\\
|
||
•Abstraktion: Details ignorieren; Spetialfall v. trennung der Verantwortung: wichtig(Funktion) und unwichtig (Details)\\
|
||
•Design for Change \\
|
||
•Allgemeinheit: gibt es ein Generelles Problem hinter meinem Problem? Bsp. Funktion Generisch schrieben statt für Strings \\
|
||
•Incrementality: Grow statt build; Erstes Resultat nur approximierung dafür in jedem Schritt etwas Brauchbares.
|
||
|
||
\subsection{Modularität: }
|
||
Ein Modul ist ein wohldefinierter Teil der Software. z.B. Funktion/Methode, Klasse, Sammlung v. Daten, Packete etc. \\
|
||
Modularität erlaubt \textbf{Dekomposition und Komposition} und \textbf{Seperation of Concers} in zwei phasen:\\
|
||
1. Bottom-up Design: Ausarbeiten der Details eines Moduls ohne odere Module zu beachten. 2.Top-Down design: Integration ins Gesamte unter berücksichtigung der Beziehungen zw. den Modulen: Vernachlässigung der Details der Module.\\
|
||
\textbf{Verschiedene Modulbeziehungen: }\\
|
||
•"Uses": A "uses" b. A nutzt Funktionalität v. B. B stellt Funktionalität zur Verfügung.\\
|
||
•"is component of"(Komposition): Modul ist aus einfacherern Moduln zusammengesetzt. Beschreibung eines Moduls auf höherer Abstraktionsebene.\\
|
||
•Hierarchie: gdw. keine Zyklen. Ebene in einer Hierarchie: $M_i$ is auf Ebene 0, falls $\not\exists M_j$, s.t. $M_iRM_j$. Sei k die höchste eben aller Module $M_j$, s.t. $M_i R M_j$. Dann ist $M_i$ auf Ebene k+1.
|
||
\subsection{Software Aging}
|
||
Wieso altert Sofwtare?:\\
|
||
•Sie wird nicht neuen gegebenheiten Angepasst\\
|
||
•Die Anpassungen sind nicht gut(neue Bugs werden eigeführt, Dokumentation nicht erneuert)\\
|
||
•Nicht selbs software aging: Allocated memory isn't released\\
|
||
Kosten v. Sw.-Alterung:\\
|
||
•Clienten wechslens auf neue Produkte weil Sw. nicht mehr das kann was Kunden wollen.\\
|
||
•Leistung nimmt ab: Sw. wird langsamer auch wegen schlechtem Design\\
|
||
•Maintenece introduces bugs and thus decreases reliability.\\
|
||
Reducing costs of Sw. againg:\\
|
||
•Focus on maintenence. Focus on good, solid engineering!\\
|
||
How do we slow down sw.aging and limit it's effects?\\
|
||
Preventing Sw. aging:\\
|
||
•Design for Succes: Design for Change + Focus on what is most likely to change, since it's impossible to make everything equally easy to change. Make it so that future changes only effect a small amount of code.\\
|
||
•Take dokumentation seriously\\
|
||
•Do peer reviews.\\
|
||
Dealing w/ old software:\\
|
||
•Stopp deterioration: Introduce, or recereate, structure when changes are made.
|
||
•Retroactive dokumentation.\\
|
||
|
||
\section{Software Design}
|
||
\subsection{Aufbau von Moduln}
|
||
\subsubsection{Interface und Implementation}
|
||
•Trennung Implementation und Interface\\
|
||
•Ermöglich Trennung der Verantwortlichkeiten\\
|
||
•Client nutzt Funktionalität, Server sorgt dafür das Fuktionalität richtig Implementiert ist.\\
|
||
•\textit{Interface } abstrahiert Funktionalität. Nur was Client wissen muss wird beschrieben.$\Rightarrow$ Details der Implementation sind unsichtbar für Client. $\Rightarrow$ \textit{Implementation soll geändert werden könnnen ohne dass Client geändert werden muss.}\\
|
||
•\textit{Information Hiding:} Komponenten die sich (eher) ändern werden sollten immer hinter einem Interface vor dem Client versteckt werden. In OO durch Klassen.\\
|
||
•\textbf{Information Hiding is Prinzip, Kapselung die Methode wodurch das Prinzip erwirkt wird.}
|
||
|
||
\subsection{Sw. Architecture \& Design}
|
||
\textbf{Was ist Design? }\textit{Formgebende und funktionaleGestaltgebung eines Produkts.}
|
||
•Strukturiert ein Artefakt\\
|
||
•Zerlegung eines Systems in (einfachere) Komponenten $\Rightarrow$ Trennung der Verantwortlichkeiten.\\
|
||
•Sicherstellen das Anforderungen erfüllt sind.\\
|
||
•Ästhetik is nicht primäre Aufgabe.\\
|
||
•Interaktion muss auch Design werden.
|
||
\\
|
||
\textbf{Design in Sweng:}\\
|
||
•Softwaredesign: Struktur und Entwurf der Module\\
|
||
Zwei Bedeutungen in Sweng $\rightarrow$\\
|
||
1. Schritt zwischen Anforderungsanalyse undf Implementation: Erstellen der Softwarearchitektur/Softwaredesigns\\
|
||
2. Strukturierung eines Artefakts: Klassendesign in einem OO-System; Design des Anforderungsdokuments.\\
|
||
\textbf{Design vs. Arch.}\\
|
||
\textit{Softwarearchitektur:} Struktur der Module (Design des gesamten Systems)\\
|
||
\textit{Software-/Moduldesign:} Entwurf individueller Module (Design der Teile)\\
|
||
Aber: Module enthalten selbst Module $\Rightarrow$ Keine Strikte Trennung möglich.\\
|
||
\textbf{Design Ziele:}\\
|
||
•Struktur so festlegen, dass hohe Sw.-qualität erreicht \textit{werden kann}.\\
|
||
•Wichtigstes Prinzip: \textit{Design for Change.} aka. Wahrscheinliche Änderungen sollten einfach zu implementierensein.\\
|
||
• "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies." -Tony Hare.
|
||
•\textbf{Kopplung: }Wie starks sind Module verknüpft.\\
|
||
•\textbf{Bindung: }Wie gut bilden die Module eine logische Einheit?\\
|
||
•\textbf{Ideal: }Schwache Kopplung, starke Bindung.\\
|
||
\includegraphics[width=\linewidth]{images/einfachesdesign.png}\\
|
||
\includegraphics[width=\linewidth]{images/einfachesdesign2.png}\\
|
||
\includegraphics[width=\linewidth]{images/layering.png}\\
|
||
\includegraphics[width=\linewidth]{images/bsplayering.png}\\
|
||
\textbf{Pipelining: }\\
|
||
Virtuelles Fliessband:\\
|
||
•Hintereinander ausführen der Arbeitschritte\\
|
||
•Module nutzen nur ein weiteres Modul\\
|
||
\includegraphics[width=\linewidth]{images/fliessband.png}\\
|
||
\includegraphics[width=\linewidth]{images/fliessbandbsp.png}\\
|
||
\textbf{Blckboard/Datarepository}\\
|
||
•Gute Orga wenn viele Module miteinander kommunizieren müssen\\
|
||
•Zentrales Modul dient als globaler Speicher\\
|
||
\includegraphics[width=\linewidth]{images/blkboard.png}\\
|
||
|
||
\section{OO-Design}
|
||
\textbf{Polymorphismus: }Variablen können zur Laufzeit an verschiedene (verwandte) Typen gebunden werden.\\
|
||
\textbf{Dynamische Bindung: }(late binding)Methode wird zur Laufzeit entsprechend dem Objekttyp verwendet.\\
|
||
•OO Sprachen helfen Design direkt abzubilden. Nicht OO Sprachen verlangen eienen Mehraufwand. Wichtig sind jedoch die Prinzipien, nicht die Sprache.
|
||
\textbf{Designtipps: }\\
|
||
•Fokus auf Konzepten nicht Klassen oder Daten\\
|
||
•Inkrementel aufbauen/nicht alles auf einmal\\
|
||
•Prototyping\\
|
||
•Optimierungskriterien: Trennung der Verantwortlichkeit; Reduziere Modulkopplung; Köhesion verbessern. In der objektorientierten Programmierung beschreibt Kohäsion, wie gut eine Programmeinheit eine logische Aufgabe oder Einheit abbildet(v. Wikipedia).\\
|
||
|
||
\subsection{SOLID Prinzipien}
|
||
Klassiche Sweng Prinzipien auf OO angewandt.
|
||
•\textbf{S}ingle Responsibility Principle\\
|
||
Es sollte nie mehr als einen Grund geben eine Klasse zu ändern. Objecte sollten hohe Kohäsion aufweisen. Jede Klasse soll nur für eine Sache verantwortlich sein. Verwandtes Prinzip: Seperation of Concerns. Bsp. Schlecht: Klasse führt Konto und erstatted bericht - Gut: Führt nur Konto.\\
|
||
•\textbf{O}pen Closed Principle\\
|
||
Module sollten offen für Erweiterungen, aber geschlossen für Modifikationen sein. Ermöglicht neue Features ohne ursprünglichen Code zu verändern. Minimeirt Risk, dass existierende Funktionen wegen Änderung kaputt gehen. $\Rightarrow$ Verwende Interfaces in Klassen statt Spezifische Klassen.
|
||
Verwandes Prinzip: Design for Change\\
|
||
•\textbf{L}ukovsches Substitutionsprinzip\\
|
||
Sei $\phi(x)$ eine beweisbare Eigenschaft v. Objekt $x$ von Type $T$. Dann gilt $\phi(y)$ für Objekte $y$ von Typ $S$, falls $S$ ein Untertyp von $T$ ist::Jedes Objekt kann durch ein Objekt der Subklasse ersetzt werden, ohne dass sich das Verhalten ändert. Kein überarschendes Verhalten $\rightarrow$ einfacherer Code. Bei nicht gut Definierten Schnittstellen und Klassen schwierig zu prüfen und verlangt Spezifikation.\\
|
||
•\textbf{I}nterface Segregation\\
|
||
Clients sollten nicht gezwungen werden von Interfaces abzuhängen, die sie nicht verwenden. $\Rightarrow$ Kleine Interfaces mit wohldefinierter Funktionalität; Klassen entkoppeln. Verwandtes Prinzip: Seperation of Concerns/Trennung der Verantwortlichkeiten\\
|
||
•\textbf{D}ependency Inversion\\
|
||
Module auf höherer Ebene sollten nicht von tiefer gelegenen abhängen. Abstraktionen sollten nicht v. Details abhängen. Details sollten v. Abstr. abhängen. Verwandte Printipien: Design for Change; Modularität.\\
|
||
\includegraphics[width=\linewidth]{images/dependencyinversion.png}\\
|
||
\textbf{Gesetz v. Demeter}\\
|
||
Methode $m$ aus Klasse $K$ soll nur auf folgende Programm-Teile zugreifen dürfen:\\
|
||
•Methoden v. $K$ selbst\\
|
||
•Methoden v. Objekten die als Argumente an $m$ übergeben werden\\
|
||
• " " ", die in Instanzvaariablen von $K$ abgelegt sind\\
|
||
• " " ", die $m$ erzeugt\\
|
||
|
||
\section{Anforderungsanalyse}
|
||
\subsection{Aufgabe der Aa.}
|
||
Anforderung an System\\
|
||
•ermittlen\\
|
||
•spezifizieren\\
|
||
•analysieren\\
|
||
•validieren\\
|
||
und daraus Lösungen herleiten. Ergebniss: Anforderungsspezifikation (Pflichtenheft)\\
|
||
Wieso braucht es Spezifikation? Abstimmung m/ Kunde;Entwurf und Implementation; Benutzerhandbuch; Testvorbereitung; Wiederverwendung.
|
||
|
||
\subsection{Schematischer Ablauf}
|
||
\begin{wrapfigure}{l}{0.09\textwidth}
|
||
\centering
|
||
\includegraphics[width=0.09\textwidth]{images/aa2.png}
|
||
\end{wrapfigure}
|
||
\textbf{Lastenheft:} Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines Auftrags aus Auftraggebersicht. Dient als Vertragsgrundlage. Kann vage, lückenhaft, inkonsistent sein. Beantwortet Frage: Was mus gemacht werden? $\Rightarrow$ z.B. Github Issue.
|
||
|
||
\textbf{Pflichtenheft: }Erarbeitete Realisierungsvorgaben basierend auf Lastenheft.• Anwendervorgaben werden detailliert; Realisierungsforderungen werden beschrieben; Definiert wie und womit die Anforderungen zu realisieren
|
||
sind; Muss vollständig klar und konsistent sein. Beantwortet Frage: Wie wird es umgesetzt? $\Rightarrow$ z.B. Unser Pflichtenheft mit Details.
|
||
|
||
\underline{Lösung in einem Schritt wird zum Problem des nächsten:}
|
||
\includegraphics[width=\linewidth]{images/rueckkopplung.png}\\
|
||
|
||
\subsection{Anforderungen}
|
||
Anforderungen müssen
|
||
Inhaltlich:
|
||
\begin{itemize}
|
||
\item Korrekt
|
||
\item Eindeutig
|
||
\item Vollständig
|
||
\item Konsistent
|
||
\item Klassifizierbar nach Wichtigkeit
|
||
\item """ Stabilität
|
||
\item Testbar/überprüfbar
|
||
\item verfolgbar
|
||
\end{itemize}
|
||
sein.\\
|
||
Formal:\\
|
||
\begin{itemize}
|
||
\item verständlich
|
||
\item präzise
|
||
\item leicht erstellbar
|
||
\item leicht verwaltbar
|
||
\end{itemize}
|
||
Anforderungen legen fest was Stakeholder von einem Sw.system al Eigenschaften erwartet.
|
||
|
||
|
||
\textbf{Funktionale Eigenschaften:}\\
|
||
Legen von Sw. bereitzustellende Funktionen fest. Leitfrage: Was muss die Sw. tun? Z.B. "Sw. muss von Kunde PIN abfragen".\\
|
||
\textbf{nicht-fkntale Eigenschaften:}\\
|
||
Alle anderen. Qualitätsmerkmale(Performance, Wartbarkeit..); Sicherheitsanforderungen etc.\\
|
||
|
||
\textbf{Individualsoftware:} -Stakeholder einfacher zu identifizieren weil im Kundenauftrag entwickelt und somit Benutzer auch meist bekannt und als Stakeholder eingebunden werden\\
|
||
- (Kunden/Benutzer) Anforderungen können eher schon zu beginn vollständig ermittelt werden. Aber: sind widersprüchlich.\\
|
||
- Sw. langlebig und hat Schnittstellen zu anderen Systemen des Kunden.\\
|
||
- Durch Integration in vorhandene Prozesse und Nachbarsysteme entstehen viele detaillierte Vorgaben.\\
|
||
- Lange Ermittlung und Priorisierung v. Anf. meist nicht gemacht.\\
|
||
- PROBLEMATISCH: Konsolidierung der Anforderungen , bei der Inkonsistenzen und Anforderungslücken eliminiert werden.\\
|
||
- Software meist einmal installiert und selten geupdatet.
|
||
\textbf{Standardsoftware: }\\
|
||
- Anforderungen stammen aus vielfältigen Infokanälen.\\
|
||
- Spätere User zum Entwicklungszeitpunkt nicht bekannt. Sind die Benutzerdaten die erhoben wurden repräsentativ?\\
|
||
- Spätere Art der Nutzeung und Arbeitsabläufe beim Kunden können sich sehr von den Ideen des Marketings unterscheiden.\\
|
||
- Customizing sollte daher möglich sein.\\
|
||
- Wird in vielen verschieden Installationen betrieben, in unterschiedlichen Versionen.\\
|
||
\includegraphics[width=\linewidth]{images/sprachschablonen.png}
|
||
|
||
\section{Sw.spezifikation}
|
||
\begin{wrapfigure}{l}{0.09\textwidth}
|
||
\centering
|
||
\includegraphics[width=0.09\textwidth]{images/spezifikation.png}
|
||
\end{wrapfigure}
|
||
\textbf{Arten v. Spez.}\\
|
||
\begin{itemize}
|
||
\item Lastenheft: Was User erwartet
|
||
\item Pflichtenheft: Welche Funktionen System zur verfügung stellt
|
||
\item Schnittstellenspezifikaiton: Externes Verhalten v. Moduln
|
||
\item Architekturspez/Design
|
||
\item Laufzeitverhalten
|
||
\item Interne Struktur v. Moduln: Hilfreich bei Wartung/Erweitern
|
||
\end{itemize}
|
||
Spezifikation is Vereinbarung zw. Produzent/Konsument.\\
|
||
\textbf{Zweck v. Sw.spez.?}\\
|
||
\begin{itemize}
|
||
\item Ohne Spezifikation ist Sw. weder korrekt noch zuverlässig(vgl. jeweilige Def.)
|
||
\item "W/o requirements and design, programming is the art of adding bugs to an empty text file." - Louis Srygley
|
||
\item IEEE Glossar Definition: A document that specifies, in a complete, precise, verifiable manner, the requirements, design, behavior, or other characteristics of a system or component and, often, the procedures for determining whether these provisions have been satisfied.
|
||
\item $\Rightarrow$ Anforderungen festhalten
|
||
\item $\Rightarrow$ Schnittstellen festhalten
|
||
\begin{itemize}
|
||
\item Klare Def./Abgrenzung d. Sw.sys.
|
||
\item Def. User-/Sensorinputraum
|
||
\item Mehrdeutigkeiten und Inkonsistenzen eliminieren
|
||
\end{itemize}
|
||
\end{itemize}
|
||
Spez. ist ein WICHTIGER Ref.punkt. während der Entwicklung und Wartung.\\
|
||
\textbf{Qualitätsmerkmale v. Sw.spez. und wieso sie schwierig zu erreichen sind}\\
|
||
\begin{itemize}
|
||
\item Präzise, Korrekt, Eindeutig
|
||
\item Konsistent (Widerspruchsfrei)
|
||
\item Vollständig
|
||
\item Inkrementell: \begin{itemize}
|
||
\item Prozess: Grob zu fein
|
||
\item Spez. kann auf versch. Detailebenen verstanden werden
|
||
\end{itemize}
|
||
Probleme: Mögliche Interessenskonflikte versch. Stakeholder; Sprachliche Barrieren/Missverständnisse; unklare oder gar unbekannte technische Rahmenbedingungen; Sich ändernde Anforderungen und Prioritäten.\\
|
||
\end{itemize}
|
||
\textbf{Konstruktiv vs. Deskriptive Spez. Methoden}\\
|
||
Generelle Methoden: Sprachlich; Logische/Mathematisch aka. Formal; Grafisch. Normalerweise kombi. Übergeordnetes Ziel: max. Klarheit und Verständlichkeit.\\
|
||
•Konstruktive Methoden: Verhalten anhand einer "Abstrakten Maschine" definiert. Z.b. Beschreibung wie mit Schnur, bleistift etc. ein Kreis gezeichnet werden kann.\\
|
||
•Deskriptiv: Verhalten anhand v. Eigenschaften definiert: z.B. Kreis def. mit Radius etc.\\
|
||
Dann jeweils noch auf Spektrum von Informell bis Formal.\\
|
||
\textbf{Wie Methoden zur Verifikation eines Systems verwendet werden können}\\
|
||
•Kosntruktiv: Verhalten beobachten; Simulation;Protoypin.\\
|
||
•Deskriptiv: Analysieren/ Ableiten v. Eigenschaften.
|
||
\textbf{Wie sieht ein Ideal Sw.spez. Prozess aus, und wieso der in der Praxis nie erreicht werden kann}\\
|
||
\subsection{A Rational Design Process. D.L. Parnas and P.C. Clemens}
|
||
\section{UML}
|
||
\begin{itemize}
|
||
\item Ist einge Grafische Modellierungssprache
|
||
\item erlaubt somit Sw. auf hoher Abstraktionsebene zu verfstehen
|
||
\item Hilft beim \begin{itemize}
|
||
\item Modellieren
|
||
\item Dokumentieren
|
||
\item Kommunizieren
|
||
\end{itemize}
|
||
\item Zwei Diagrammarten: Strukturdiagramme (statisch) und Verhaltensdiagramme (dynamisch)
|
||
\end{itemize}
|
||
|
||
\subsection{Klassendiagramme (statisch)}
|
||
\includegraphics[width=0.7\linewidth]{images/klassendiagramme.png}
|
||
\includegraphics[width=0.2\linewidth]{images/umlklassen.png}
|
||
|
||
\subsection{Assoziationen(1.) und Aggregation(2.)}
|
||
\includegraphics[width=0.6\linewidth]{images/assozation.png}
|
||
\includegraphics[width=0.3\linewidth]{images/aggregation.png}
|
||
2. Impliziert "is componenet of" Beziehung. Verwandt mit Komposition: Bei Komp. können die Teile NICHT ohne das ganze existieren (gezeichent mit leerer Raute). Von Raute zu ursprung ist es eine "besteht aus" Beziehung. Dabei sind sie gleich.
|
||
\subsection{Assoziationsklassen}
|
||
Eine Assoziationsklasse (auch Beziehungsklasse) ist in der objektorientierten Analyse eine Klasse, deren Attribute und Operationen die Assoziation zwischen anderen Klassen beschreibt.
|
||
\includegraphics[width=0.5\linewidth]{images/assosiationsklassen.png}
|
||
Assoziationsklassen werden in Analysephasen von Prozessmodellen verwendet und später zum Entwurf aufgelöst. Dazu werden entweder die Attribute (und Operationen) auf die Klassen der Assoziation verteilt, oder die Assoziation wird aufgeteilt, indem die Assoziationsklasse als eigenständige Klasse eingefügt wird.
|
||
Assoziationsklassen beschreiben in der UML, wie Relationships mit ihren Attributen in Entity-Relationship-Diagrammen, eine Beziehung (Relationship) zwischen zwei Klassen (Entities), nehmen also die Eigenschaften auf, die gerade durch diese Beziehung entstehen (Von Wikipedia Copy Paste).
|
||
\subsection{Vererbung}
|
||
Modelliert Varianten: Publikation ist Buch oder Artikel.
|
||
\includegraphics[width=0.5\linewidth]{images/vererbung.png}
|
||
\subsection{Use-case Diagramm(dynamisch)/Paketdiagramm(statisch)}
|
||
Beschreibt in Funktion involvierte Akteure/Zeigt Struktur auf ebene der Pakete\\
|
||
\includegraphics[width=0.5\linewidth]{images/usecasedia.png}
|
||
\includegraphics[width=0.3\linewidth]{images/paketdia.png}
|
||
Eigentlich nur logische Spez/OCL Deskriptiv, da sie Mitteld Formeln der Aussagenlogik Eigenschaften Spezifiziert.
|
||
\subsection{Sequenziagramme (dynamisch)}
|
||
Konstruktive Methode; Beschreibt Interaktion/Nachrichtenzw. Objekten; Fokus auf Sequenz der Nachrichten\\
|
||
\includegraphics[width=\linewidth]{images/sequenzdia.png}
|
||
\subsection{Kommunikationsdiagramme(dynamsich)}
|
||
Semantisch äquivalent zu Sequenzdia; Fokus auf Objektinteraktion\\
|
||
\includegraphics[width=\linewidth]{images/kommunikationsdia.png}
|
||
\subsection{Aktivitätsdiagramme(dynamisch)}
|
||
Konstruktive Spez.methode;Modelliert Ablauf v. Anwendungsfall; Sequenzielle und parallele Aktivitäten möglich; Semantik basiert auf Petrinetze.
|
||
\includegraphics[width=0.5\linewidth]{images/aktivitaetsdia.png}
|
||
\subsection{Zustandsdiagramme(dynamsich)}
|
||
Basierend auf Theorie der endlichen Automaten.
|
||
\includegraphics[width=0.5\linewidth]{images/zustandsdia.png}
|
||
\subsection{UML für Spezifikation}
|
||
\includegraphics[width=\linewidth]{images/umlspezdia.png}
|
||
|
||
\section{Verifikation/Grundlagen des Testens}
|
||
\subsection{Validierung und Verifikation}
|
||
\begin{tabular}{l l}
|
||
\textbf{Validierung} & \textbf{Verifikation} \\
|
||
• Bauen wir das & • Bauen wirt das \\
|
||
\emph{richtige Produkt}? & \emph{Produkt richtig}?\\
|
||
• Bsp. Nachweis & • Nachweis, dass Funktion erfüllt\\
|
||
medizinischen Nutzens &\\
|
||
\end{tabular}
|
||
Validierung Insgesamt schwierig: Kaum formale Dokumente / Spezifikationen auf denen die Anforderungen aufbauen Ansätze:
|
||
• Frühe Prototypen / Modelle
|
||
• Inkrementelles Entwickeln
|
||
• Reviews
|
||
• Simulationen
|
||
• Transparente Prozesse mit Stakeholder in Loop
|
||
\subsection{Wieso muss Software immer Verifiziert werden?}
|
||
\begin{itemize}
|
||
\item Fehler lassen sich nie ganz verhindern \begin{itemize}
|
||
\item Können jeden Prozesschritt betreffen
|
||
\end{itemize}
|
||
\item \textbf{Probleme} \begin{itemize}
|
||
\item Unklarheiten/Mehrdeutigkeiten
|
||
\item Falsche Annahmen
|
||
\item Falsche Schlussfolgerungen /Fehler
|
||
\item Fehler in System Umgebung
|
||
\end{itemize}
|
||
\item \textbf{Ansätze:} \begin{tabular}{l l}
|
||
\emph{Analyse} & \emph{Experimentieren} \\
|
||
\emph{ (statisch)}& \emph{(dynamisch)} \\
|
||
• Code Review & • Verhalten des \\
|
||
& Programms testen\\
|
||
• Automatisierte & - Manuelle Ausführung \\
|
||
Codeanalyse & \\
|
||
• Formale & - Automatisierte Tests \\
|
||
Korrektheitsbeweise & \\
|
||
\end{tabular}
|
||
\end{itemize}
|
||
|
||
\subsection{Diverse Methoden zur Verifikaiton}
|
||
\textbf{Code Review: }Jemand anderes Schaut Programm an. \emph{Ziele: }\\- Missverständnisse und Fehler entdecken\\ - Codequalität verb. \\- Zusammenarbeit stärken \\ - Wissen verbreiten \\
|
||
\textbf{(statische) Codeanalyse: }Code auf typesche Probleme durchgehen \\ - Uninitializierte Vars\\- Index out of bounds\\- off by one\\- Zugriff auf Null werte\\- unused methods etc. \\
|
||
Oft durch Entwocklertoolsunterstützt\\
|
||
\textbf{Korrektheitsbeweise: }\emph{Ziel: } Beweisen, dass Programm Spezifikationen erfüllt.\\- Spezifikationen müssen formal definiert sein.\\
|
||
- Braucht "automatische Theorembeweiser" für nicht-triviale Programme\\
|
||
\textbf{Testen: }Verhalten v. Sw. durch Stichproben Eingaben prüfen. \emph{Ziel: }Beispiele von Inkorrektem Verhalten finden.
|
||
\subsection{Types of Testing}
|
||
\includegraphics[width=0.9\linewidth]{images/testbigsmall.png}
|
||
\begin{tabular}{l l}
|
||
\emph{Whitebox T.} & \emph{Blackbox T.} \\
|
||
• strukturelles T. & • Funktionales T. \\
|
||
Partitionierung der T.fälle &\\
|
||
basierend auf &\\
|
||
- interne Struktur & - Spezifikation\\
|
||
Testen was die Sw. &\\
|
||
- macht & - machen \emph{sollte}\\
|
||
\end{tabular}
|
||
\includegraphics[width=0.9\linewidth]{images/testenueberblick.png}
|
||
•\textbf{Soll-Resultate}\\
|
||
\emph{Idealfall}\\
|
||
• Soll Resultat ist eindeutig definiert und entspricht bekanntem Wert\\
|
||
\emph{Praxis}\\
|
||
• Mehrere verschiedene richtige Ergebnisse möglich\\
|
||
• Ergebnis nur vage definiert (Beispiel: Positionierung eines Ausgabefensters)\\
|
||
• Richtiges Resultat nicht exakt darstellbar (Beispiel: Resultat von $\frac{1}{3}$)\\
|
||
• Richtiges Resultat nicht bekannt (Beispiel: Berechnung der Zahl $\pi$)\\
|
||
\emph{Lösung}\\
|
||
• Eigenschaften der Lösung werden definiert\\
|
||
Beispiel: assertTrue($3.141\leq pi \leq 3.142$)\\
|
||
|
||
•\textbf{Regressionstests}\\
|
||
IEEE Std. 610.12: Selective retesting of a system or component to verify that modifications have not caused unintended effects and that the system or component still complies with its specified requirements.\\
|
||
• Änderung an Programm sollte keine unbeabsichtigen Effekte haben.\\
|
||
• Reale Daten von frühreren Programmläufen können als Soll-Daten verwendet werden.\\
|
||
\textbf{Typen v. Fehler}\\
|
||
\begin{tabular}{l l}
|
||
\emph{Bereichsf.} & \emph{Punktf.}\\
|
||
- Bestimmter Teilraum & - tritt für genau Einen\\
|
||
von Eingaberaum & Testfall auf\\
|
||
reproduziert fehler & \\
|
||
& - Liegen oft an Bereichsgrenzen\\
|
||
\end{tabular}
|
||
$\Rightarrow$ Äquivalenzklassen verwenden.
|
||
Bereiche wo ähnliches Verhalten erwartet wird bestimmen.\\
|
||
\emph{Überdeckungskriterium: }\\
|
||
- Ein Testfall pro Äquivalenzklasse\\
|
||
- Ein Testfall pro Grenze\\
|
||
• \textbf{Modultests}\\
|
||
• \textbf{Integrationstests} more in next Section\\
|
||
• \textbf{Systemtest} Testen des ganzen Systems gegen die Funktionalen Anforderungen
|
||
• Wird häufig auf separater Testumgebung durchgeführt • Testumgebung soll Kundenumgebung simulieren\\
|
||
• \textbf{Akzeptanztest} Test aus Kundensicht - von Kunden durchgeführt
|
||
Testet die im Pflichtenheft definierten Akzeptanzkriterien Resultat entscheidet ob nachbessert werden muss.\\
|
||
\subsection{Stubs and Drivers}
|
||
Modultests benötigen Hilfskonstrukte, falls abhängige Module noch in Entwicklung sind.\\
|
||
\includegraphics[width=0.9\linewidth]{images/driverstubs.png}\\
|
||
\textbf{Integrationstest: }
|
||
Module werden im Verbund getestet\\
|
||
2 Möglichkeiten\\
|
||
1. BigBang\\
|
||
• Alle Module werden nur in Isolation getestet\\
|
||
• Danach ganzes System testen\\
|
||
2. Progressivesintegrierenundtesten\\
|
||
• top down: stub ersetzten\\
|
||
• bottom up: driver ersetzen\\
|
||
\subsection{Vor-/Nachteile Top-Down/Bottom-up Integration}
|
||
\emph{Top-level Module werden gut getestet: }Vorteil Top-Down\\
|
||
\emph{Benötigt viele Driver: }Nachteil Bottom-Up\\
|
||
\emph{Das Programm als solches existiert erst am Ende: }Nachteil Bottom-Up\\
|
||
\emph{Benötigt viele Stubs: }Nachteil Top-Down\\
|
||
\emph{Fehler in Schnittstellen werden früh entdeckt: }Vorteil Top-Down\\
|
||
\emph{Früher Prototyp, den man Benutzer zeigen kann: }Vorteil Top-Down\\
|
||
\emph{Testbedingungen sind einfach zu bestimmen: }Vorteil Bottom-Up\\
|
||
\emph{Testoutput ist schwierig nachzuvollziehen: }Nachteil Top-Down\\
|
||
\section{Testen im Kleinen}
|
||
\subsection{Blackbox}
|
||
Kriterium: Möglichst gute Abdeckung der spezifizierten Anforderungen\\
|
||
\emph{Testen aus Spezifikationen: }\\
|
||
Beispielspezifikation\\
|
||
Das Programm bekommt als Input eine Repräsentation (Datenstruktur) einer Einzahlung. Diese Einzahlung muss in eine Tabelle von Einzahlungen eingeordnet werden, welche nach Datum sortiert ist. Falls andere Einzahlungen mit demselben Datum existieren, wird die neue Einzahlung nach dem letzten Eintrag dieses Datums einsortiert. Es sollen auch verschiedene Konsistenzchecks durchgeführt werden:
|
||
• Ist der Kunde bereits im Kundenverzeichnis
|
||
• Stimmt der Name in den Verzeichnissen überein •...\\
|
||
Mögliche Äquivalenzklassen\\
|
||
• Das aktuelles Datum liegt in der Vergangenheit/Zukunft
|
||
• Es gibt keine/mehrere Zahlungen an diesem Tag
|
||
• Name ist/ist nicht im Kundenverzeichnis
|
||
• Zahlung ist mit Datenbank konsistent/inkonsistent\\
|
||
Grenzfälle\\
|
||
• Heute
|
||
• 1 Zahlung\\
|
||
\emph{Ursache-Wirkung Diagramm:}\\
|
||
\includegraphics[width=0.9\linewidth]{images/uwdia.png}\\
|
||
Beispielspezifikation\\
|
||
Ein Kunde kommt in die Bibliothek und will sich ein Buch ausleihen. Die Bibliothekarin prüft als erstes seinen Ausweis und ob das Benutzerkonto aktiv ist. Falls der Ausweis nicht gültig ist und oder falls der Kunde fällige Mahngebühren nicht bezahlt hat, wird das Konto gesperrt. Falls das Konto aktiv ist, wird zusätzlich überprüft ob der Kunde bereits die maximal mögliche Anzahl von Büchern ausgeliehen hat. Falls dies der Fall ist wird der Ausleihwunsch zurückgewiesen. Ansonsten wird dem Kunden das gewünschte Buch ausgeliehen.\\
|
||
|
||
|
||
|
||
\emph{Entscheidungstabellen:}\\
|
||
Überdeckungskriterium: Jede Spalte entspricht einem Testfall.\\
|
||
\includegraphics[width=0.3\linewidth]{images/entscheidungstabelle.png}\\
|
||
|
||
\subsection{Whitebox}
|
||
Kriterium: Möglichst vollständige Überdeckung vom Code\\
|
||
- Ableiten von Testfällen anhand interner Struktur\\
|
||
- Spezifikation nicht im Vordergrund um Testfälle zu finden - Testfälle hängen von Implementation ab\\
|
||
Struktur vom Code definiert Äquivalenzklassen.\\
|
||
Überdeckungskriterien:\\
|
||
\emph{Anweisungsüberdeckung: } \\
|
||
Wähle Testmenge $T$ so, dass jedes Statement in Programm $P$ mindestens einmal ausgeführt wird (für beliebiges $d\in T$). PROBLEM: Test Menge kann kleiner als Äquivalenzklassen sein. Bsp: if$(x<l) {x =-x;}z=x; x=-3$ deckt alle Statements ab, kein Test für $x>0$.\\
|
||
\emph{Zweigüberdeckung (Edge Coverage):}\\
|
||
Die Testmenge $T$ wird so gewählt, dass jeder Zweig des Kontrollflusses mindestens einmal durchlaufen wird.
|
||
Formalisiert durch \emph{Kontrollflussgraphen}. Jede Kante in Graph muss abgedeckt sein:\\
|
||
\includegraphics[width=0.3\linewidth]{images/kontrollflussgraph.png}
|
||
\includegraphics[width=0.65\linewidth]{images/kfg2.png}\\
|
||
\includegraphics[width=0.9\linewidth]{images/kfproblems.png}\\
|
||
\emph{Bedingungsüberdeckung:}\\
|
||
|
||
\begin{wrapfigure}{l}{0.12\textwidth}
|
||
\centering
|
||
\includegraphics[width=0.12\textwidth]{images/bedproblems.png}
|
||
\end{wrapfigure}
|
||
Die Testmenge $T$ wird so gewählt, dass jeder Zweig des Kontrollflusses mindestens einmal durchlaufen wird und alle möglichen Elemente von zusammengesetzten Bedingungen mindestens einmal aktiv sind.\\
|
||
|
||
\emph{Pfadüberdeckung:} \\
|
||
Die Testmenge $T$ wird so gewählt, dass jeder Pfad zwischen initial und Endknoten durchlaufen wird \\- Bestes Testkriterium, aber nicht praktikabel\\
|
||
- Explosion der Anzahl Pfade bei langen Programmen oder Loops\\
|
||
|
||
\section{Softwareprozesse}
|
||
- Bestimmen was man tut\\
|
||
- Legen Ordung und Beziehung der Aktivitäten fest\\
|
||
- Definieren auch WANN man zur nächsten Aktivität übergeht\\
|
||
\textbf{Tiele: }\\
|
||
- Standardisierung \\
|
||
- Vorhersehbarkeit \\
|
||
- Produktivität \\
|
||
- Hohe Produktqualität \\
|
||
- Zeit und Budget Planung\\
|
||
\textbf{Blackbox Sicht: }
|
||
- Interaktion mit User nur Am Anfang/Ende
|
||
- Nicht für Sw. geeignet: Fehler in Anforderungen erst am ende entdeckt; Qualitätseigenschaften nicht v. Produkt ableitbar.
|
||
\textbf{Whitebox-Sicht:} Interaktion mit USer in jeder Projektphase; eingehen auf Veränderung möglich.
|
||
\textbf{1st try: Code and Fix: }Unmöglich vorhersagen zu treffen und zu managen.
|
||
\subsection{Wasserfall Modell}
|
||
Machbarkeitsstudie>Anforderungsanalyse>Design>Implementation>Integration und Systemtest>Release/Wartung\\
|
||
• Stark strukturierter Prozess
|
||
• Dokumentlastig (Dokument nach jeder Phase)
|
||
• Prozess strukturiert und planbar
|
||
• Implementation erst wenn Anforderungen verstanden
|
||
sind
|
||
\textbf{Wasserfall Modell: Probleme}
|
||
|
||
• Änderung in Anforderungen nicht berücksichtigt
|
||
• Kein Feedback zwischen den Phasen
|
||
• Keine Parallelisierung
|
||
• Fixes Einführungsdatum für ganzes System\\
|
||
Variante 2: Mit Prototyeing während Schritte 1 2 3\\
|
||
Variante 3: Mit Feedbach an vorige Stufe: REICHT OFT NICHT\\
|
||
Model war beispiel in Paper Royce, Winston W. "Managing the Development of Large Software Systems", Proceedings of IEEE WESCON 26 (August): 1–9. wie nicht zumachen.
|
||
\subsection{V-Modell}
|
||
Wasserfallmodel mot Feedback über mehrere Stufen
|
||
Ablauf Prozess:
|
||
1 Anforderungsanalyse $>$ 2 Systementwurf(Architecture)$>$ 3 Programmentwurf $>$ 4 Implementation $>$ 5 Unit/Integrationstest $>$ 6 Systemtest $>$ 7 Akzeptanztest $>$ 8 Release/Wartung\\
|
||
Feedback: 1-7;2-6;3-5
|
||
\subsection{Spiralmodel}
|
||
\includegraphics[width=\linewidth]{images/Spiralmodel_nach_Boehm.png}
|
||
Risikoabschätzung in jedem Durchlauf.
|
||
\end{multicols*}
|
||
\end{document} |