diff options
| author | manuel <manuel@nc8430.lan> | 2009-04-27 00:24:16 +0200 |
|---|---|---|
| committer | manuel <manuel@nc8430.lan> | 2009-04-27 00:24:16 +0200 |
| commit | 384539f7cc9feaa7ef7cee385cce472c6966c843 (patch) | |
| tree | 42d3cbc96d44087c0b6bbe8d41710e5c5f1efced /ue1/protokoll/protokoll.tex | |
| download | ooprog-384539f7cc9feaa7ef7cee385cce472c6966c843.tar.gz ooprog-384539f7cc9feaa7ef7cee385cce472c6966c843.tar.bz2 ooprog-384539f7cc9feaa7ef7cee385cce472c6966c843.zip | |
Adding ue1
Diffstat (limited to 'ue1/protokoll/protokoll.tex')
| -rw-r--r-- | ue1/protokoll/protokoll.tex | 226 |
1 files changed, 226 insertions, 0 deletions
diff --git a/ue1/protokoll/protokoll.tex b/ue1/protokoll/protokoll.tex new file mode 100644 index 0000000..a8c7928 --- /dev/null +++ b/ue1/protokoll/protokoll.tex | |||
| @@ -0,0 +1,226 @@ | |||
| 1 | \documentclass[12pt,a4paper,titlepage,oneside]{article} | ||
| 2 | \usepackage[utf8]{inputenc} | ||
| 3 | \usepackage{oop_prot} | ||
| 4 | \usepackage{url} | ||
| 5 | \usepackage{pdfpages} | ||
| 6 | \usepackage{booktabs} | ||
| 7 | |||
| 8 | \title{Beispiel 1} | ||
| 9 | |||
| 10 | \author{Manuel Mausz, \matrnr 0728348\\ | ||
| 11 | {\small manuel-tu@mausz.at} | ||
| 12 | } | ||
| 13 | |||
| 14 | \begin{document} | ||
| 15 | |||
| 16 | % create titlepage | ||
| 17 | \maketitle | ||
| 18 | |||
| 19 | \tableofcontents | ||
| 20 | \newpage | ||
| 21 | |||
| 22 | %------------------------------------------------------------------ | ||
| 23 | %------------------------------------------------------------------ | ||
| 24 | |||
| 25 | \section{Aufgabenstellung - Beispiel 1} | ||
| 26 | \includegraphics[width=\textwidth,page=1]{../angabe.pdf} | ||
| 27 | \includegraphics[width=\textwidth,page=2]{../angabe.pdf} | ||
| 28 | |||
| 29 | %------------------------------------------------------------------ | ||
| 30 | %------------------------------------------------------------------ | ||
| 31 | |||
| 32 | \section{Beispiel 1} | ||
| 33 | |||
| 34 | \subsection{Design}\label{Design} | ||
| 35 | |||
| 36 | Abbildung~\ref{fig:classdiagram1} zeigt das Klassendiagramm der Aufgabe. | ||
| 37 | |||
| 38 | |||
| 39 | Die Klasse CScriptParser übernimmt das Parsen der per Commandlineparameter | ||
| 40 | übergebenen Scriptdatei als String, wobei dieser bereits im Konstruktor | ||
| 41 | übergeben werden muss. Zum Anstoßen des Parsen dient die Funktion parse(). | ||
| 42 | Der (simple) Parser arbeitet Zeilenbasiert und erwartet pro Zeile einen | ||
| 43 | Funktionsaufruf im Syntax: funktionsname(param1, ... paramX). Schachteln von | ||
| 44 | Funktionen ist nicht erlaubt. Der erste Befehl eines Blocks muss der Befehl | ||
| 45 | ``read'' sein, der Befehl ``write'' beendet einen Block. Alle Funktionsparameter | ||
| 46 | werden zusammen in einer Liste gespeichert und den entsprechenden Funktionen | ||
| 47 | übergeben. Whitespaces und Anführungszeichen werden bereits vorab gelöscht. | ||
| 48 | |||
| 49 | |||
| 50 | Tritt ein Fehler während des Parsens auf, werden Instanzen der Klasse | ||
| 51 | \mbox{CSriptError::ParserError} als Exception geworfen. Über die Methode | ||
| 52 | \mbox{getLine()} der Exception kann die aktuelle Zeile der Scriptdatei, die den | ||
| 53 | Fehler erzeugt hat, ausgelesen werden.\\ | ||
| 54 | |||
| 55 | |||
| 56 | Da der Scriptbefehl ``read'' und ``write'' einen Dateitypparameter enthält, | ||
| 57 | ist es potentiell möglich verschiedene Dateitypen zu öffnen und zu bearbeiten. | ||
| 58 | Um dies aus der Sicht des Parsers generisch durchzuführen, müssen alle Klassen, | ||
| 59 | die Dateioperationen durchführen können, von der Abstrakten Klasse \mbox{CFile} | ||
| 60 | abgeleitet sein und somit mindestens dessen virtuelle Methoden implementieren. | ||
| 61 | Alle Implementation müssen weiters im Konstruktor die unterstützten Dateitypen | ||
| 62 | in die Membervariable m\_types hinzufügen, damit der Parser die jeweils | ||
| 63 | zuständige Implementation verwenden kann. | ||
| 64 | |||
| 65 | |||
| 66 | Die Methode \mbox{callFunc(...)} dient zum Aufruf von dateitypspezifische | ||
| 67 | Scriptfunktionen. Hierzu übergibt der Parser automatisch alle unbekannten | ||
| 68 | Funktionen und dessen Parameter innerhalb eines Block (abgesehen von ``read'' | ||
| 69 | und ``write'') der jeweils zuständigen Instanz. | ||
| 70 | |||
| 71 | |||
| 72 | Zur Fehlerbehandlung sollen Implementationen von CFile Instanzen der | ||
| 73 | Klasse \mbox{CFile::FileError} als Exception werfen. Diese werden vom Parser | ||
| 74 | gefangen und in Instanzen der eigenen Exception des Parsers | ||
| 75 | \mbox{CSriptError::ParserError} übersetzt.\\ | ||
| 76 | |||
| 77 | |||
| 78 | Die Klasse \mbox{CBitmap} implementiert die Abstrakte Klasse \mbox{CFile} und | ||
| 79 | kann Dateien des Types ``BMP'' (Windows Bitmap) bearbeiten. Beim Lesen der | ||
| 80 | Datei werden rudimentäre Checks des Dateiheaders durchgeführt. Der Speicher der | ||
| 81 | Pixel, wird wie gewünscht dynamisch alloziert. Um aber die verschiedenen | ||
| 82 | möglichen Farbtiefen von Windows Bitmap zu unterstützen, werden die | ||
| 83 | Schreiboperationen auf die Pixeldaten an eine Instanz der je nach Farbtiefe | ||
| 84 | zuständigen Implementation der Abstrakten Klasse \mbox{CPixelFormat} delegiert. | ||
| 85 | Diese Instanz wird während der Analyse des Dateiheaders ebenfalls dynamisch | ||
| 86 | allokiert.\\ | ||
| 87 | |||
| 88 | |||
| 89 | Damit Implementationen der abstrakten Klasse \mbox{CPixelFormat} direkt auf die | ||
| 90 | Daten des Windows Bitmap zugreifen können, wird im Konstruktor ein Pointer auf | ||
| 91 | die Instanz von \mbox{CBitmap} übergeben. Über die Public Getter-Methoden von | ||
| 92 | \mbox{CBitmap} erfolgt der direkt Zugriff. Fehlerbehandlung erfolgt | ||
| 93 | Exceptions der Klasse \mbox{CPixelFormat::PixelFormatError}. | ||
| 94 | |||
| 95 | %================================================================== | ||
| 96 | \begin{figure}[htb] | ||
| 97 | \begin{center} | ||
| 98 | \epsfxsize=0.9\textwidth\epsfbox{ClassDiagram1.png} | ||
| 99 | \end{center} | ||
| 100 | \caption{Klassendiagramm 1} | ||
| 101 | \label{fig:classdiagram1} | ||
| 102 | \end{figure} | ||
| 103 | %================================================================== | ||
| 104 | |||
| 105 | |||
| 106 | \subsection{Verwaltung der Ressourcen} | ||
| 107 | |||
| 108 | Alle Klassen, die im Laufe ihrer Existenz Ressourcen dynamische | ||
| 109 | allozieren, initialisieren die jeweiligen Membervariablen im Konstruktor auf | ||
| 110 | NULL und geben diese, sofern tatsächlich alloziert, im spätestens Destruktor | ||
| 111 | wieder frei.\\ | ||
| 112 | Alle Dateien, die geöffnet werden, werden nach dem Abfangen der Exception auch | ||
| 113 | wieder geschlossen, sofern alle möglichen, auftretenden Exceptions | ||
| 114 | (\mbox{std::bad\_alloc} ausgenommen) auch vorab übersetzt wurden. | ||
| 115 | |||
| 116 | \subsection{Fehlerbehandlung} | ||
| 117 | |||
| 118 | Alle Implementationen der abstrakten Klasse \mbox{CPixelFormat} werfen | ||
| 119 | Exceptions der Klasse \mbox{CPixelFormat::PixelFormatError}. Diese werden von | ||
| 120 | \mbox{CBitmap} gefangen und in Exceptions der Klasse \mbox{CFile::FileError} | ||
| 121 | übersetzt, welche wiederum von der Klasse \mbox{CScriptParser} gefangen und in | ||
| 122 | Exceptions der Klasse \mbox{CScriptParser::ParserError} übersetzt werden.\\ | ||
| 123 | Diese Exceptions sowie Exceptions des Typs \mbox{std::exception} werden | ||
| 124 | schlussendlich vom Hauptprogramm gefangen und geben eine entsprechende | ||
| 125 | Fehlermeldung an den Benutzer auf stderr aus. | ||
| 126 | |||
| 127 | \subsection{Implementierung} | ||
| 128 | Siehe Punkt~\ref{Design} und Abbildung~\ref{fig:classdiagram1} sowie | ||
| 129 | Punkt~\ref{Listings}. | ||
| 130 | |||
| 131 | |||
| 132 | Alle Exceptions wurden von \mbox{std::invalid\_argument} abgeleitet und der | ||
| 133 | Konstruktor gemäß den üblichen Konventionen implementiert: | ||
| 134 | |||
| 135 | %================================================================== | ||
| 136 | \begin{lstlisting}{} | ||
| 137 | ParserError(const std::string& what) | ||
| 138 | : std::invalid_argument(what) | ||
| 139 | {} | ||
| 140 | \end{lstlisting} | ||
| 141 | %================================================================== | ||
| 142 | |||
| 143 | |||
| 144 | %------------------------------------------------------------------ | ||
| 145 | %------------------------------------------------------------------ | ||
| 146 | |||
| 147 | \section{Projektverlauf} | ||
| 148 | |||
| 149 | |||
| 150 | \subsection{Probleme und Fallstricke} | ||
| 151 | |||
| 152 | In der Hoffnung das in der nächsten Aufgabe weitere Funktionen, Dateitypen | ||
| 153 | und/oder Farbtiefen des Windows Bitmaps-Formats verlangt werden, wurden | ||
| 154 | diese sehr generisch implementiert.\\ | ||
| 155 | Ursprünglich wollte ich die jeweilig unterstützen Scriptfunktionen mittels | ||
| 156 | \mbox{std::map<std::string, (void *)()>} an den Scriptparser zurückgeben, | ||
| 157 | sodass dieser direkt die jeweilige Methode (per Pointer) aufrufen kann. Dies | ||
| 158 | funktioniert jedoch logischerweise nur bei statischen Methoden. Daher die | ||
| 159 | einfacher Methode über die callFunc-Methoden, die die Parameter an die | ||
| 160 | jeweiligen internen Methoden weiterdelegieren. | ||
| 161 | |||
| 162 | |||
| 163 | Da sich \mbox{CBitmap} und \mbox{CPixelFormat} gegenseitig referenzieren, | ||
| 164 | müssen die jeweiligen Klassen im Headerfile der anderen Klasse vorab deklariert | ||
| 165 | werden. Andernfalls kann der Compiler die Klasse aufgrund der rekursiven | ||
| 166 | Inklusion nicht finden. | ||
| 167 | |||
| 168 | \subsection{Arbeitsaufwand} | ||
| 169 | |||
| 170 | \begin{tabular}{ll} | ||
| 171 | \toprule | ||
| 172 | Entwicklungsschritt / Meilenstein & Arbeitsaufwand in Stunden\\ | ||
| 173 | \midrule | ||
| 174 | Erstes Design & 15 Minuten\\ | ||
| 175 | \hline | ||
| 176 | Implementierung (und leichte Anpassung des Designs) & 1 Tag\\ | ||
| 177 | \hline | ||
| 178 | Dokumentation (Doxygen) und Überprüfung alle\\ | ||
| 179 | Anforderungen gemäß der Programmierrichtlinien & 2 Tage\\ | ||
| 180 | \hline | ||
| 181 | Erstellung des Protokolls & 1 Tag\\ | ||
| 182 | \bottomrule | ||
| 183 | \end{tabular} | ||
| 184 | |||
| 185 | %------------------------------------------------------------------ | ||
| 186 | %------------------------------------------------------------------ | ||
| 187 | |||
| 188 | \section{Listings}\label{Listings} | ||
| 189 | |||
| 190 | \subsection{imgsynth.cpp} | ||
| 191 | \lstinputlisting{../imgsynth/imgsynth.cpp} | ||
| 192 | |||
| 193 | \newpage | ||
| 194 | \subsection{cscriptparser.h} | ||
| 195 | \lstinputlisting{../imgsynth/cscriptparser.h} | ||
| 196 | |||
| 197 | \newpage | ||
| 198 | \subsection{cscriptparser.cpp} | ||
| 199 | \lstinputlisting{../imgsynth/cscriptparser.cpp} | ||
| 200 | |||
| 201 | \newpage | ||
| 202 | \subsection{cfile.h} | ||
| 203 | \lstinputlisting{../imgsynth/cfile.h} | ||
| 204 | |||
| 205 | \newpage | ||
| 206 | \subsection{cbitmap.h} | ||
| 207 | \lstinputlisting{../imgsynth/cbitmap.h} | ||
| 208 | |||
| 209 | \newpage | ||
| 210 | \subsection{cbitmap.cpp} | ||
| 211 | \lstinputlisting{../imgsynth/cbitmap.cpp} | ||
| 212 | |||
| 213 | \newpage | ||
| 214 | \subsection{cpixelformat.h} | ||
| 215 | \lstinputlisting{../imgsynth/cpixelformat.h} | ||
| 216 | |||
| 217 | \newpage | ||
| 218 | \subsection{cpixelformat\_24.h} | ||
| 219 | \lstinputlisting{../imgsynth/cpixelformat_24.h} | ||
| 220 | |||
| 221 | \newpage | ||
| 222 | \subsection{cpixelformat\_24.cpp} | ||
| 223 | \lstinputlisting{../imgsynth/cpixelformat_24.cpp} | ||
| 224 | |||
| 225 | \end{document} | ||
| 226 | |||
