Taxi System. CheckUp Tutorial Version 4.3 Institut für Softwaretechnik und interaktive Systeme

Transkript

1 Taxi System Document: CheckUp Tutorial Version 4.3 Institut für Softwaretechnik und interaktive Systeme 1 / 6

2 1 Erstellen und Übersetzten eines Java-Programms Bevor man mit dem Programmieren beginnen kann, ist es eine Vorraussetzung die grundlegenden Befehle der Umgebung im Betriebssystem zu kennen (MS DOS). Abbildung 1: Hello.java im Windows Notepad 1 Das Erstellen von Quelldateien ist in jedem beliebigen Texteditor möglich, zu beachten ist jedoch die korrekte Verwendung von Upper und Lower-Case Dateinamen. Das Übersetzen der Quelldateien erfolgt mit dem Kommando javac (so heißt der Java- Compiler des JDK). Wenn kein Fehler gemacht wurde, wird der Compileraufruf kommentarlos akzeptiert. Nun können Sie mit dem Kommando java Programmklasse das Programm starten. 2 Kompilieren und Ausführen von Hello.java in der Kommandozeile: 1. Kompilieren: javac Hello.java 2. Ausführen: java Hello 1.1 Klassen Eine Klassendefinition in Java wird durch das Schlüsselwort class eingeleitet. Anschließend folgt innerhalb von geschweiften Klammern eine beliebige Anzahl von Variablen- und Methodendefinitionen. Das folgende Listing zeigt ein Beispiel für eine einfache Klassendefinition: /* Auto.java */ public class Auto 004 { 005 public String name; 006 public int erstzulassung; 007 public int leistung; 008 } Listing 1: Eine einfache Klassendefinition 4 Um von einer Klasse ein Objekt anzulegen, muß eine Variable vom Typ der Klasse deklariert und dieser mit Hilfe des new-operators ein neu erzeugtes Objekt zugewiesen werden: 001 Auto meinkombi; 002 meinkombi = new Auto(); Listing 2: Erzeugen eines Objekts mit new 5 1 Handbuch der Java-Programmierung, 3. Aufl., Addison Wesley, Online-Version 3.0.1: 2.2 Erste Gehversuche Abbildung Handbuch der Java-Programmierung, 3. Aufl., Addison Wesley, Online-Version 3.0.1: 2.2 Erste Gehversuche 3 Vgl. Mössenböck: Sprechen Sie Java? 2003/Heidelberg S Handbuch der Java-Programmierung, 3. Aufl., Addison Wesley, Online-Version 3.0.1: 7.2 Klassen und Objekte in Java Listing / 6

3 1.1.1 Konstruktoren In jeder objektorientierten Programmiersprache lassen sich spezielle Methoden definieren, die bei der Initialisierung eines Objekts aufgerufen werden: die Konstruktoren. In Java werden Konstruktoren als Methoden ohne Rückgabewert definiert, die den Namen der Klasse erhalten, zu der sie gehören. Konstruktoren dürfen eine beliebige Anzahl an Parametern haben und können überladen werden. Die Erweiterung unserer Auto-Klasse um einen Konstruktor, der den Namen des Auto-Objekts vorgibt, sieht beispielsweise so aus: public class Auto 002 { 003 public String name; 004 public int erstzulassung; 005 public int leistung; public Auto(String name) 008 { 009 this.name = name; 010 } public Auto(String name, 013 int erstzulassung, 014 int leistung) 015 { 016 this.name = name; 017 this.erstzulassung = erstzulassung; 018 this.leistung = leistung; 019 } 020 } Listing 3: Klassen mit mehreren Konstruktoren 7 2 UML-Sequenzdiagramm (Sequence Diagram) Definition Sequenzdiagramme sind die wichtigsten Interaktionsdiagramme und zeigen den zeitlichen Ablauf einer Reihe von Nachrichten (Methodenaufrufen) zwischen bestimmten Objekten in einer zeitlich begrenzten Situation. Dabei kann auch das Erzeugen und Entfernen von Objekten enthalten sein. 8 Sequenzdiagramme legen den Schwerpunkt auf den zeitlichen Nachrichtenverlauf, während andere Diagramme (z.b. Kommunikationsdiagramm) die Zusammenarbeit der Objekte verdeutlichen. 2.2 Nachrichtenaustausch, Methodenaufruf Nachrichtenaustausch zwischen Objekten wird durch Methodenaufrufe bewerkstelligt, deren Namen (und Parameter) zusammen mit einem Pfeil dargestellt werden. 5 Handbuch der Java-Programmierung, 3. Aufl., Addison Wesley, Online-Version 3.0.1: 7.2 Klassen und Objekte in Java Listing Vgl. Mössenböck: Sprechen Sie Java? 2003/Heidelberg S Handbuch der Java-Programmierung, 3. Aufl., Addison Wesley, Online-Version 3.0.1: 7.3 Methoden Listing UML Unified Modeling Language - Sequenzdiagramm 3 / 6

4 Testdiagramm CPU RAM store() save() save_ok() Abbildung 2 Einfaches Sequenzdiagramm In Abbildung 2 wird durch einen Aufruf der Methode store der Klasse CPU die Methode save der Klasse RAM aufgerufen. Diese ruft wiederum die Methode save_ok der Klasse CPU auf. 3 Testen Testen dient der systematischen Aufdeckung von Fehlern eines Systems und Abweichungen von seiner Spezifikation. In der CheckUp Session kommt die Blackbox-Methode zur Anwendung. Im Zentrum dieser Methoden steht hierbei der Testfall, welcher eine spezifische Situation darstellt, die das System bestehen muss. Man teilt dabei Testfälle in unterschiedliche Klassen ein: Normalfall: gültige Eingaben an das System Fehlerfall: ungültige Eingaben Sonderfall: Eingaben an der Grenze Normalfall / Fehlerfall (z.b.: ) Die Ergebnisse des Testens werden in weiterer Folge herangezogen, um das System zu verbessern BlackBox-Testen Dieses Testverfahren betrachtet das zu testende Element (egal ob Klasse oder das ganze System) an seinen Eingabe- und Ausgabeschnittstellen und lässt dabei technische Details der Implementierung außer Acht. Die Tests werden hierbei basierend auf den in den Anforderungen beschriebenen Anwendungsfällen durchgeführt. Notwendige Informationen über die Eingabedaten werden dabei aus dem Domänenmodell abgelesen. Der genaue Ablauf gliedert sich dabei, wie folgt 10 : 1. Untersuchung des konkreten Anwendungsfalles und Identifizierung der Ein- und Ausgabe des Systems, als auch seiner Grenzen 2. Erstellung der Äquivalenzklassen. (In einer Äquivalenzklasse sind jeweils Werte zusammengefasst, die ein identisches funktionales Verhalten bewirken, d.h. dieselbe Programmfunktion auslösen. Für den Test werden Werte aus diesen Äquivalenzklassen genommen, wobei üblicherweise Grenzwerte verwendet werden da dort erfahrungsgemäß die meisten Fehler auftreten. Beispiel: Äquivalenzklasse C2: Zahlen im Bereich von 0 bis 20, hier würden die gewählten Testwerte 0 und 20 sein.) 3. Aufstellung der Testfälle, dabei wird für jede Äquivalenzklasse ein Testfall formuliert der die korrekte Funktion bei der Eingabe von Daten dieser Klasse überprüfen soll. Jeder Testfall wird klassifiziert (Normalfall, Fehlerfall oder Sonderfall). Zusätzlich 9 Vgl. Zuser, Biffl, Grechenig & Köhle: Software Engineering mit UML und dem Unified Process / München 2001, Kapitel Testen, Seiten Vgl. Zuser, Biffl, Grechenig: Seiten / 6

5 verfügt jeder Testfall über eine kurze Beschreibung, ein erwartetes Ergebnis und eine oder mehrere beispielhafte Eingabedaten 3.2 Beispiel zu BlackBox-Testfällen Dieses Beispiel betrachtet als zu testendes System die Methode getbyid(int id, int tb). Der konkrete Anwendungsfall besteht aus der Verwendung dieser Methode; es ist dabei nicht wichtig wie diese aufgebaut ist. Als Ausgabe ist ein Feld von Strings definiert. Im Designdokument ist festgelegt, dass sich die Variablen id und tb im Bereich aller positiven Integer inklusive 0 befinden ([0; int]). Zusätzlich ist noch definiert, dass die Variable tb immer kleiner gleich id ist (tb <= id). Aus dieser Spezifikation lässt sich ableiten: - die Eingabe: zwei Werte (id, tb) vom Typ int - die erwartet Ausgabe: ein Feld von Strings Im nächsten Schritt werden die Äquivalenzklassen definiert. Dabei wird jeder Äquivalenzklasse ein Kürzel zugeordnet welches sich in einen Buchstaben und einer Zahl aufschlüsselt. (Beispiel: A1, A2 und A3, welche die möglichen Unterbereiche einer Variable X abdecken) In diesem Beispiel stellen wir Äquivalenzklasse K für die Variable id (int), L für die Variable tb und M für das Verhältnis zwischen id und tb auf, welche sich in die folgenden Unterbereiche gliedern: K0: gültige Eingabe: 0 <= id < int K1: ungültige Eingabe: -int < id < 0 K2: ungültige Eingabe: id > int K3: ungültige Eingabe: id < -int L0: gültige Eingabe: 0 <= tb < int L1: ungültige Eingabe: -int < tb < 0 L2: ungültige Eingabe: tb > int L3: ungültige Eingabe: tb < -int M0: gültiges Verhältnis: tb <= id M1: ungültiges Verhältnis: tb > id Abschließend werden die Testfälle gebildet, wobei jede Äquivalenzklasse mindestens einmal in den Testfällen vorkommen sollte, im Idealfall auch NUR EINMAL. Somit ergeben sich folgende Testfälle: Lfd. Nr. Typ Beschreibung, abgedeckte Äquivalenzklassen Erwartetes Ergebnis 1 NF K0,L0,M0 : gültige Eingabe Feld aus Strings 2 FF K1,L1,M0: ungültige Eingabe Fehlermeldung 3 FF K2,L2,M1: ungültige Eingabe Fehlermeldung 4 FF K3,L3,M1: ungültige Eingabe Fehlermeldung 5 / 6

6 4 Literaturverzeichnis [1] Guido Krüger (2002) Handbuch der Java-Programmierung 3. Auflage, Addisson-Wesley [2,3] Hanspeter Mössenböck (2003) Sprechen Sie Java? 2. überarbeitete Auflage, Heidelberg: dpunkt.verlag [4] Dipl.-Ing. Torsten Horn Ingenieurbüro für Software und Internet (2004) UML Unified Modeling Language WWW-Dokument vom (Addresse: [5,6] Wolfgang Zuser, Stefan Biffl, Thomas Grechenig & Monika Köhle (2001): Software Engineering mit UML und dem Unified Process. 1.Auflage, München: Pearson Studium 6 / 6