In diesem Kapitel befassen wir uns mit der Qualität und der Absturzsicherheit der implementierten Features.
In diesem Kapitel befassen wir uns mit der Qualität und der Absturzsicherheit der implementierten Features.
\section{Find Bugs}
\section{Find Bugs}
Um in der Benutzung keine Programmabstürze durch Programmierfehler zu erhalten wurde der Code mit Findbugs überprüft. % Kurze Erklärung, was Findbugs ist, welche Fehler es finden kann und am besten eine Quellenangabe für das Literaturverzeichnis
Um in der Benutzung keine Programmabstürze durch Programmierfehler zu erhalten wurde der Code mit Findbugs \cite{FB} überprüft.
Alle Fehlerquellen die Findbugs untersucht, sind in dem Code beseitigt worden.
Findbugs untersucht den Java bytecode nach Bug Patterns.
Lediglich die Fehler in der JHotDraw GUI Bibliothek, auf dem der SBA aufbaut, wurden nicht behoben. % Du solltest erklären warum dieses nicht gemacht wurde.
Vermutliche Fehler z.B. Nullpointer oder auch schlechter Stil wie == Operator anstelle der equels Methode wird von der Bibliothek erkannt und dem Nutzer zur Verbesserung vorgeschlagen.
Das Parsen der XML Dokumente im ResultHandler ist hier insbesondere überprüft worden. %``Hier'' im JHotDraw GUI oder wo?
In der Implementierung wurden alle Anmerkungen von Findbugs behoben.
Viele Felder sind optional und werden im CSDAdapter und im SBA ausgelesen.
Lediglich die Fehler in der JHotDraw GUI Bibliothek, auf dem der SBA aufbaut, wurden nicht behoben.
Es ist ein exaktes Verständnis vom gesamten JHotDraw Frameworks von Notwendigkeit um z.B. die gefundenen Bitmaskenfehler zu beheben.
Das Parsen der XML Dokumente im ResultHandler der CSDCommons Bibliothek ist insbesondere überprüft worden.
Viele Felder des XML Dokuments der CSD sind optional und werden im CSDAdapter und im SBA ausgelesen.
Es muss also immer darauf geachtet werden, ob die Informationen vorhanden sind und auch verwendet werden können.
Es muss also immer darauf geachtet werden, ob die Informationen vorhanden sind und auch verwendet werden können.
Bei der Nutzereingabe zum Schreiben in die CSD wird die Richtigkeit und Notwendigkeit der einzelnen Felder direkt bei der Eingabe überprüft.
Bei der Nutzereingabe zum Schreiben in die CSD wird die Richtigkeit und Notwendigkeit der einzelnen Felder direkt bei der Eingabe überprüft.
Übergibt man ein unvollständiges XML Dokument an die Isaac.lib, so wirft diese Fehler.
Übergibt man ein unvollständiges XML Dokument an die Isaac.lib, so wirft diese Fehler.
Um das zu vermeiden, kann der Nutzer die Anfrage nicht absenden, bevor alle Eingaben korrekt erfolgt sind.
Um das zu vermeiden, kann der Nutzer die Anfrage nicht absenden, bevor alle Eingaben korrekt erfolgt sind.
\section{Testing}
\section{Testing}
Die Testcases das CSDAdapters sind erhalten geblieben. % Es waren also schon vorher welche vorhanden. Mussten dies angepasst werden, damit man sie weiternutzen kann? Wieviele Testcases sind im Testset?
Die Testcases die im CSDAdapters vorhanden waren sind in die aktuelle Implementierung übertragen worden.
Das Parsen des XML Dokuments im SBA und im CSDAdapter unterscheidet sich nur unwesentlich % stimmt es noch nach meiner Änderung?
Zum testen werden einige XML Dokumente vom Dateisystem geladen und an den ResultHandler übergeben.
\todo{testcases überprüfen}
Das Parsen des XML Dokuments im SBA und im CSDAdapter wird fast komplett durch dir abstrakte Implementierung in der CSDCommons Bibliothek übernommen.
Dieser Teil des Codes wird dementsprechend in den Testcases des CSDADapters
und ist hauptsächlich im allgemeinen ResultHandler der CSDCommons Bibliothek enthalten.
und ist hauptsächlich im allgemeinen ResultHandler der CSDCommons Bibliothek enthalten.
Dieser Test ist also durch den Test des CSDAdapters abgedeckt. Deshalb wurden für den SBA keine eigenen Testcases erstellt.
Dieser Test ist also durch den Test des CSDAdapters abgedeckt. Deshalb wurden für den SBA keine eigenen Testcases erstellt.
