From c78472d9e36202c510a7e00774e5e875cc96207b Mon Sep 17 00:00:00 2001 From: manuel Date: Sat, 30 May 2009 16:13:22 +0200 Subject: klassendiagramm --- ue4/protokoll.pdf | Bin 408797 -> 424450 bytes ue4/protokoll/mycpu.png | Bin 0 -> 127987 bytes ue4/protokoll/mycpu.vpp | Bin 0 -> 116228 bytes ue4/protokoll/protokoll.tex | 98 +++++++++++++++++++++++++++----------------- 4 files changed, 61 insertions(+), 37 deletions(-) create mode 100644 ue4/protokoll/mycpu.png create mode 100644 ue4/protokoll/mycpu.vpp diff --git a/ue4/protokoll.pdf b/ue4/protokoll.pdf index 06311b9..b3dc60d 100644 Binary files a/ue4/protokoll.pdf and b/ue4/protokoll.pdf differ diff --git a/ue4/protokoll/mycpu.png b/ue4/protokoll/mycpu.png new file mode 100644 index 0000000..c394605 Binary files /dev/null and b/ue4/protokoll/mycpu.png differ diff --git a/ue4/protokoll/mycpu.vpp b/ue4/protokoll/mycpu.vpp new file mode 100644 index 0000000..14730dc Binary files /dev/null and b/ue4/protokoll/mycpu.vpp differ diff --git a/ue4/protokoll/protokoll.tex b/ue4/protokoll/protokoll.tex index 87a556a..53f57df 100644 --- a/ue4/protokoll/protokoll.tex +++ b/ue4/protokoll/protokoll.tex @@ -1,4 +1,5 @@ \documentclass[12pt,a4paper,titlepage,oneside]{article} + \usepackage[utf8]{inputenc} \usepackage{oop_prot} \usepackage{url} @@ -37,31 +38,44 @@ Manuel Mausz, \matrnr 0728348\\ Abbildung~\ref{fig:classdiagram1} zeigt das Klassendiagramm der Aufgabe. -Wie gefordert, wurden die zwei zusätzliche Datentypen, \mbox{CDatSet} und \mbox{CDatN}, implementiert und der Programmcode generisch gestaltet. - -Dabei wurde \mbox{CDatSet} vom existierenden Typ \mbox{CDat} und boost::operators<\mbox{CDatSet}> mittels Mehrfachvererbung abgeleitet. -So war es möglich die Implementierung, mittels Codewiederverwendung, auf das Überschreiben eines Kopierkonstruktors und des Operators \mbox{operator>>()} zu beschränken. - -Da der Typ \mbox{CDatN} Werte variabler Bitlänge repräsentiert, war es notwendig diesen vollständig neu zu implementieren. Es wurde von boost::operators<\mbox{CDatN}> abgeleitet und dabei eine zusätzliche -Methode \mbox{align()} definiert, die sicherstellt, dass der transportierte Wert immer auf die geforderte Bitanzahl konvertiert wird. -Weiters wurde ein Kopierkonstruktor definiert, der einen Integerwert und einen vorzeichenlosen Integerwert als Argument erwartet. -Letzterer ist mit dem Defaultwert 31 deklariert und repräsentiert die Bitanzahl, auf die ersterer konvertiert wird. Damit ist es möglich alle vorhandenen Datentypen einheitlich zu verarbeiten. -Der Defaultkonstruktor wurde wie gewünscht deaktiviert. - -Um nun die Wahl des Datentyps zu ermöglichen, wurde die Synopsis des Programms mit \mbox{``-f''} erweitert. -Der Parameter dieser Option muss \mbox{``s''} oder ein Wert zwischen ``2'' und ``32'' sein. -Im Hauptprogramm wird nun anhand dieses Parameters der zuständige Datentyp instanziert und die Templatemethode -\mbox{cpu\_run()} aufgerufen, welche die Initialisierung und Abarbeitung des Programms anstößt. - -Damit das Programm mit den verschiedenen Datentypen umgehen kann, wurden \mbox{CCPU}, \mbox{CMem}, \mbox{CProgram}, \mbox{CInstuction} und die abgeleiteten \mbox{Instructions} -zu Templates umgewandelt, die als Typparameter den, im Hauptprogramm, instanzierten Datentyp erhalten. +Wie gefordert wurden die zusätzliche Datentypen \mbox{CDatSet} und +\mbox{CDatN} implementiert und der Programmcode generisch gestaltet. + +Dabei wurde \mbox{CDatSet} vom existierenden Typ \mbox{CDat} und +\mbox{boost::operators} mittels Mehrfachvererbung abgeleitet. So war es +möglich die Implementierung, mittels Codewiederverwendung, auf das Überschreiben +eines Kopierkonstruktors und des Operators \mbox{operator>>()} zu beschränken. + +Da der Typ \mbox{CDatN} Werte variabler Bitlänge repräsentiert, war es notwendig +diesen vollständig neu zu implementieren. Es wurde von +\mbox{boost::operators} abgeleitet und dabei in jeder +Methode sicherstellt, dass der transportierte Wert immer auf die geforderte +Bitanzahl beschränkt wird. Weiters wurde ein Kopierkonstruktor definiert, der +einen Integerwert und einen vorzeichenlosen Integerwert als Argument erwartet. +Letzterer ist mit dem Defaultwert 31 deklariert und repräsentiert die Bitanzahl, +auf die Ersterer beschränkt wird. Damit ist es möglich alle vorhandenen +Datentypen einheitlich zu verarbeiten. Der Defaultkonstruktor wurde wie +gewünscht deaktiviert. + +Um nun die Wahl des Datentyps zu ermöglichen, wurde die Synopsis des Programms +mit \mbox{``-f''} erweitert. Der Parameter dieser Option muss \mbox{``s''} oder +ein Wert zwischen ``2'' und ``32'' sein. Im Hauptprogramm wird anhand dieses +Parameters der zuständige Datentyp instanziert und die Templatemethode +\mbox{cpu\_run()} aufgerufen, welche die Initialisierung und Abarbeitung des +Programms anstößt. + +Damit das Programm mit den verschiedenen Datentypen umgehen kann, wurden +\mbox{CCPU}, \mbox{CMem}, \mbox{CProgram}, \mbox{CInstuction} und die +abgeleiteten \mbox{Instructions} zu Templates umgewandelt, die als +Template-Parameter den Typ des im Hauptprogramm instanzierten Datentyps, +erwarten. \newpage %================================================================== \begin{center} \begin{figure}[htb] - \epsfxsize=1.6\textwidth\epsfbox{mycpu.png} + \epsfxsize=1.1\textwidth\epsfbox{mycpu.png} \caption{Klassendiagramm 1} \label{fig:classdiagram1} \end{figure} @@ -71,43 +85,53 @@ zu Templates umgewandelt, die als Typparameter den, im Hauptprogramm, instanzier \newpage \subsection{Verwaltung der Ressourcen} -Die Register von \mbox{CCPU} werden nun, anstatt in einem Array, in einem Vector verwaltet. -Dieser wird mit der Anzahl der Register und dem, im Hauptprogramm, instanzierten Datentyp initialisiert. -Dadurch ist das Löschen der Register im Destruktor nicht mehr notwendig. +Die Register von \mbox{CCPU} werden nun, anstatt in einem Array, in einem Vector +verwaltet. Dieser wird mit der Anzahl der Register und dem, im Hauptprogramm, +instanzierten Datentyp initialisiert. Dadurch ist das eigenhändige Löschen der +Register im Destruktor nicht mehr notwendig, da dies der Destruktor des Vectors +erledigt. -Siehe auch Punkt~\ref{Probleme und Fallstricke}.\\ +Siehe auch Punkt~\ref{Probleme und Fallstricke}.\\ \subsection{Fehlerbehandlung} -Es wurden mehrere Exceptions, als Subklassen der jeweiligen Templateklassen, von Typ \mbox{std::invalid\_argument} abgeleitet. -Diese sind \mbox{CCPUError}, \mbox{CInstructionError}, \mbox{CMemError} und \mbox{CProgramError}. +Es wurden mehrere Exceptions von der Klasse \mbox{std::invalid\_argument} +abgeleitet. Diese sind \mbox{CCPUError}, \mbox{CInstructionError}, +\mbox{CMemError} und \mbox{CProgramError} und werden von ihren +zugehörigen Klassen entsprechend geworfen. -Wird zB.: eine Exception von Typ \mbox{CInstructinError} geworfen, so wird sie in \mbox{CCPU} zu \mbox{CCPUError} umgewandelt und an das Hauptprogramm weitergereicht, -wo wider eine Umwandlung in \mbox{runtime\_error()} stattfindet. Das Fangen einer \mbox{runtime\_error()} Exeption bewirkt eine fehlerbeschreibende Ausgabe auf \mbox{std::cerr} -und den Programmabbruch mit Exitstatus 1. +Wird zB.: eine Exception von Typ \mbox{CInstructinError} geworfen, so wird sie +in \mbox{CCPU} zu \mbox{CCPUError} umgewandelt und an das Hauptprogramm +weitergereicht, in dem wiederum eine Umwandlung in \mbox{runtime\_error()} +stattfindet. Das Fangen einer \mbox{runtime\_error()} Exeption bewirkt eine +fehlerbeschreibende Ausgabe auf \mbox{std::cerr} und den Programmabbruch mit +Exitstatus 1. \subsection{Implementierung} Siehe Punkt~\ref{Design} und Abbildung~\ref{fig:classdiagram1} sowie Punkt~\ref{Listings}.\\ - - \section{Projektverlauf} \subsection{Probleme und Fallstricke}\label{Probleme und Fallstricke} \mbox{CDatN}: -Mit der, in der Angabe vorgeschlagenen Methode zur Begrenzung der Bitanzahl, ist es nur möglich positive Zahlen zu verarbeiten. -Somit entspricht -1 dem Maximum der, mit der Bitanzahl, darstellbaren positiven Zahl usw.. +Mit der in der Angabe vorgeschlagenen Methode zur Begrenzung der Bitanzahl, ist +es nur möglich positive Zahlen zu verarbeiten. Somit entspricht -1 dem Maximum +der, mit der Bitanzahl, darstellbaren positiven Zahl usw.. -Ein weiteres Problem besteht darin, wenn die Anzahl der Instruktionen in CProgram, den maximal darstellbaren Wert übersteigt. -In diesen Fall ist das Programmverhalten undefiniert. +Ein weiteres Problem besteht darin, wenn Register nicht mehr gelesen werden +können, weil der Index des Registers ausserhalb des Bereichs des Datentyps +liegt. In diesen Fall ist das Programmverhalten undefiniert. -Auf Grund der Forderung, den Defaultkonstruktor von \mbox{CDatN} zu deaktivieren, wurden einige Probleme initiiert. -Es war nicht weiter möglich, die Register von \mbox{CCPU} in einem Array zu organisieren, da zur Deklaration ein Defaultkonstruktor notwendig ist. -Weiters musste eine Alternative zum, nicht mehr anwendbaren \mbox{boost::lexical\_cast} in \mbox{CMem} implementiert werden. +Auf Grund der Forderung, den Defaultkonstruktor von \mbox{CDatN} zu +deaktivieren, traten einige Probleme auf. So war es beispielsweise nicht weiter +möglich, die Register von \mbox{CCPU} in einem Array zu organisieren, da zur +Deklaration ein Defaultkonstruktor notwendig ist. Weiters musste eine +Alternative zum nicht mehr anwendbaren \mbox{boost::lexical\_cast} in +\mbox{CMem} implementiert werden. \subsection{Arbeitsaufwand} -- cgit v1.2.3