Diplombericht - Berner Fachhochschule
Werbung
Diplombericht Nr. MAS-06-01.15 Grafischer Transaktionssimulator MAS-IT-06-01, 11. September 2008 Abstract Der Transaktionssimulator simuliert Datenbank-Benutzer, und lässt diese in gegenseitiger Konkurrenz auf eine reale Datenbank zugreifen. Simulationen sind parametrisierbar: Anzahl gelesener und geschriebener Datensätze, Isolationsgrad, Häufigkeit und Nebenläufigkeit der User usw. sind einstellbar. Gemessen werden u.a. Anzahl Transaktionen, Phantoms, Deadlocks und Lost Updates. Die Parametereingabe und Resultatdarstellung erfolgt im GUI. Simulationsmodelle werden in XML erfasst. Schlüsselwörter Simulation, Transaktion, Datenbank Autor: Paul Klarenberg Sandrainstrasse 60a 3007 Bern +41 31 372 92 82 Betreuer: Dr. Arno Schmidhauser Wankdorffeldstrasse 102 Postfach 325 CH-3000 Bern 22 +41 31 84 83 275 Experte: Max Kleiner Kasernenstrasse 41 3001 Bern Versionskontrolle Datum Version Autor Beschreibung 2008-08-27 0.1 P. Klarenberg Initialversion 2009-09-07 0.2 P. Klarenberg Überarbeitung, Diagramme 2009-09-08 0.3 P. Klarenberg Korrekturen 2009-09-11 1.0 P. Klarenberg Zum uploaden zur SWS Seite 2 von 66 Inhaltsverzeichnis 1 EINLEITUNG ............................................................................................. 5 1.1 1.2 1.3 1.4 1.5 2 ZWECK DES DOKUMENTS ..................................................................................... 5 ZIELPUBLIKUM ..................................................................................................... 5 VORBEMERKUNGEN ............................................................................................. 5 DEFINITIONEN UND ABKÜRZUNGEN ..................................................................... 5 REFERENZEN ........................................................................................................ 6 ANALYSE .................................................................................................. 7 2.1 ALLGEMEINE BESCHREIBUNG .............................................................................. 7 2.2 ZUSAMMENHANG ZWISCHEN SIMULATION UND WIRKLICHKEIT .......................... 7 2.3 FACHKLASSEN ..................................................................................................... 8 2.4 ARCHITEKTUR ...................................................................................................... 9 2.5 GUI ................................................................................................................... 10 2.6 PRODUKT PERSPEKTIVE ..................................................................................... 11 2.6.1 WICHTIGSTE ANFORDERUNGEN ................................................................. 11 2.6.2 BENUTZER ................................................................................................. 11 3 ARCHITEKTUR/DESIGN ......................................................................... 13 3.1 ARCHITEKTUR .................................................................................................... 13 3.2 PACKAGES ......................................................................................................... 13 3.3 SOURCING .......................................................................................................... 14 3.4 ÜBERSICHT ........................................................................................................ 15 3.4.1 PACKAGE NET.CLEARMOUNTAIN.TRANSIM ................................................ 16 3.4.2 PACKAGE NET.CLEARMOUNTAIN.TRANSIM.GUI .......................................... 16 3.4.3 PACKAGE NET.CLEARMOUNTAIN.TRANSIM.OPTIONSPANEL ........................ 17 3.4.4 PACKAGE NET.CLEARMOUNTAIN.TRANSIM.SIMULATOR ............................. 18 3.4.5 PACKAGE NET.CLEARMOUNTAIN.TRANSIM.MODEL .................................... 18 3.4.6 PACKAGE NET.CLEARMOUNTAIN.TRANSIM.DATABASE .............................. 19 3.4.7 PACKAGE NET.CLEARMOUNTAIN.TRANSIM.STATISTICS .............................. 20 3.5 ABLÄUFE ........................................................................................................... 20 3.5.1 HAUPTABLÄUFE ......................................................................................... 20 3.5.1.1 Screen Refresh Zyklus 21 3.5.1.2 Transaction Statistics Zyklus 21 3.5.2 KOMMUNIKATION ZWISCHEN GUI UND ANDERE MODULE......................... 22 4 IMPLEMENTATION ................................................................................. 23 4.1 GUI ................................................................................................................... 23 4.1.1 SIMULATIONS-HAUPTFENSTER .................................................................. 23 4.1.2 MYMENUBAR............................................................................................ 24 4.1.3 OPTIONSPANEL .......................................................................................... 24 4.1.3.1 Simulatoroptionen 24 4.1.3.2 Datenbankoptionen 24 4.1.3.3 Skalierungsoptionen 25 4.1.3.4 Farboptionen 25 4.2 SIMULATOR ........................................................................................................ 26 4.3 KONFIGURATOR ................................................................................................. 29 4.3.1 MODEL.XML ............................................................................................... 29 4.3.1.1 parameterSets 31 4.3.1.2 transactionModels 31 4.3.1.3 userModels 32 Seite 3 von 66 4.3.1.4 simulationModels 33 4.3.1.5 shows 35 4.3.2 DATABASES.XML ........................................................................................ 37 4.3.3 ACCOUNTS.XML ......................................................................................... 38 5 TESTS ..................................................................................................... 40 5.1 5.2 5.3 6 UNITS TESTS ...................................................................................................... 40 INTEGRATIONSTESTS .......................................................................................... 40 ABNAHMETEST .................................................................................................. 40 BESPRECHUNG ....................................................................................... 42 6.1 BEURTEILUNGSRELEVANTE KRITERIEN ............................................................. 42 6.2 ABWEICHUNGEN ZUM PFLICHTENHEFT .............................................................. 42 6.2.1 ANFORDERUNGSABDECKUNG .................................................................... 42 6.2.2 NICHT UMGESETZTE ANFORDERUNGEN ..................................................... 46 6.3 VORGEHEN......................................................................................................... 46 6.3.1 VORGEHENSMODELL.................................................................................. 46 6.3.2 ZEITPLAN ................................................................................................... 48 6.4 ERFAHRUNGEN .................................................................................................. 49 6.4.1 ANALYSE PHASE ........................................................................................ 49 6.4.2 DESIGN / ENTWICKLUNGSPHASE ................................................................ 49 6.4.3 REALISIERUNGSPHASE ............................................................................... 49 6.4.4 GRÖSSTE PROBLEME .................................................................................. 50 6.4.5 GRÖSSTE AUFSTELLER ............................................................................... 51 6.5 AUFWANDSCHÄTZUNG....................................................................................... 51 6.6 AUSBLICK .......................................................................................................... 51 ANHANG A. UML DIAGRAMME ................................................................... 52 ANHANG B XML-SCHEMAS ......................................................................... 60 Seite 4 von 66 1 Einleitung 1.1 Zweck des Dokuments Dieses Dokument beschreibt das Projekt "Grafischer Transaktionssimulator". Das Dokument dient dem Experten als Grundlage für die Beurteilung der der Diplomarbeit des Autors. 1.2 Zielpublikum Das Dokument soll insbesondere auch interessierten Kreisen, wie z.B. Unterhaltsentwickler, aufzeigen, wie die Software aufgebaut ist. Als Vorkenntnisse werden empfohlen: • • • Übung in der Verwendung von GUIs und technischen Anwendungen XML Anwenderkenntnisse Kenntnis der Datenbank-Theorie, insbesondere der Themen Transaktion und Nebenläufigkeit 1.3 Vorbemerkungen Das vorliegende Dokument wiederholt aus dem Pflichtenhefts [1] nur wenige, wichtige Inhalte. Für eine vollständige Darlegung der Anforderungen wird auf das Pflichtenheft verwiesen. Das vorliegende Dokument dient ebenfalls nicht als Benutzeranleitung, welche in einem separaten Dokument [4] erfasst wurde. Die Software ist als binäre Distribution (bedingt zum Laufen eine Java VM), sowie als Source in der Form von ZIP Dateien erhältlich. 1.4 Definitionen und Abkürzungen Begriff / Abkürzung Definition Application Der Transaktionssimulator DBConnection Die aktuelle Verbinding via JDBC mit einer Datenbank. DatabaseConnectionProfile Die produktspezifische Spezifikation für eine DatenbankVerbindung (u.a. User Account Daten, Treiber-Name, usw.) Isolation Level / Isolationsgrad Isolationsgrad gemäss SQL Standard: 0 = read uncommitted, 1 = read committed, 2 = repeatable read, 3 = serializable Operation Primitive Datenbankoperation Read (R), Update (U), Delete (D) und Insert (I). Werden mit SQL-Befehle implementiert. Show Eine Menge benannte Simulationsmodelle samt Simulationsparameter welche als ganzes konfiguriert und geladen werden kann. Simulation Das ausgeführte Simulationsmodell (auch: Seite 5 von 66 Begriff / Abkürzung Definition Simulationslauf). Simulationsmodell Ein lauffähiges Modell einer Simulation, bestehende aus einem oder mehreren Transaktionsmodellen und relativen Mengen. z.B. "2*RR1 + 1*RU1" Simulationsparameter SimulationThread Ein Thread der, stellvertretend für einen User, gemäss einem Transaktionsmodell auf die Datenbank zugreift. Software Design Description (SDD) Spezifikation des Software-Designs gemäss IEEE 1016. Die SDD beschreibt die Lösung, die SRS dagegen die Anforderungen. Software Requirements Specification (SRS) Spezifikation der Software Anforderungen gemäss IEEE 830. Die SRS beschreibt die Anforderungen, die SDD dagegen die Lösung. TransactionModel Transaktionmodell, welche den Verlauf einer Transaktion beschreibt. Elemente: Transaktionsmuster und Transaktionsparameter unf Isolationsgrad. Transaktionsmuster Eine Reihe von Operationen (z.B. RR oder RU) Transaktionsparameter - Anzahl gelesene Datensätze in Prozent (R%) - Anzahl geänderte Datensätze in Prozent von R% (U%) - Absolute Anzahl geänderte Datensätze (I) - Anzahl der gelöschten datensätze in Prozent (D%) - Pausezeit (P) vor und zwischen den Operationen Usage Pattern User Type Tabelle 1: Begriffe und Abkürzungen 1.5 Referenzen [1] "Pflichtenheft Diplomarbeit Grafischer Transaktionssimulator", P. Klarenberg, 22. April 2008 [2] "Der Transaktionssimulator", Dr. Arno Schmidhauser, Dezember 2004 [3] Transaktionssimulator Java Code, Dr. Arno Schmidhauser [4] "Benutzeranleitung Transaktionssimulator 1.0" [5] Dokumentation zum Swing Application Framework, https://appframework.dev.java.net/ [6] Dokumentation zu SwingX, https://swingx.dev.java.net/ [7] Dokumentation zum JFreeChart, http://www.jfree.org/jfreechart/ [8] Dokumentation zum MiGLayout, http://www.miglayout.com/ [9] "Core Java 2", Band 1. Grundlagen (Zur Java 2 Standard Edition Version 5.0), von Cay S. Horstmann, Gary Cornell [10] "Core Java 2", Band 2. Expertenwissen (Zur Java 2 Standard Edition Version 5.0), von Cay S. Horstmann, Gary Cornell [11] "Java Swing", Marc Loy, Brian Cole, Jim Elliot, und Robert Eckstein, O'Reilly Media Seite 6 von 66 2 Analyse Die Ergebnisse der Analysephase (-> siehe Vorgehensmodell 6.3.1) wurden im Pflichtenheft [1] dokumentiert. In diesem Kapitel werden die wichtigsten und teilweise überarbeitete Ergebnisse der Analyse aufgeführt, und wo nötig kommentiert. 2.1 Allgemeine Beschreibung Der Transaktionssimulator soll die Performance und das Auftreten möglicher Inkonsistenzen simulieren, wenn viele Transaktionen gleichzeitig auf eine Datenbank zugreifen. Diagramm 1 zeigt die Analogie zwischen der Simulation und der simulierten Wirklichkeit. Der Transaktionssimulator soll nicht die Mechanismen demonstrieren wonach diese Inkonsistenzen entstehen, sondern statistische Daten über deren Auftreten erheben und Visualisieren. Der Transaktionssimulator soll im Rahmen des Unterrichts des Fachs Datenbanken eingesetzt werden. Primär vom Dozenten (Frontalunterricht) und möglicherweise auch von Studenten (Praktikum). 2.2 Zusammenhang zwischen Simulation und Wirklichkeit Diagramm 1 zeigt auf, wie der Transaktionssimulator versucht die Wirklichkeit abzubilden. Jeder Benutzer-Typ wird mittels eines seinem Verhalten entsprechenden User-Models definiert. Ein Simulationslauf besteht aus einen oder mehreren Instanzen von einen oder mehreren Benutzer-Typen. Jeder Benutzer-Instanz wird einen eigenen Simulations-Thread samt Datenbank-Verbindung zugeteilt. Der Simulations-Thread führt die im User-Model definierten Operationen samt benutzerspezifischen Parametern auf der Datenbank aus. Im Pflichtenheft wurde den vereinfachten Ansatz präsentiert, die Benutzer über ein mathematisches Verfahren abzubilden. Diese Methode wurde in der Design-Phase jedoch verworfen. Seite 7 von 66 Diagramm 1: Analogie zwischen Simulation und simulierter Wirklichkeit 2.3 Fachklassen Diagramm 2 zeigt ein Fachklassendiagramm mit den wichtigsten fachlichen Begriffen und deren Zusammenhängen. Seite 8 von 66 class Fachklassenmodell Transaktionssimulator Application Die Simulationsproperties können auf Ebene Application, Show und Simulation spezifiziert werden. Application ist die "höchste" Stufe, Simulation die "tiefste". Es wird von hoch nach tief vererbt. Die tiefere Ebene kan "überschreiben". Hiermit wird z.B. den Vergleich eine und derselbe Simulation auf zwei verschiedenen DB ermöglicht. SimulationProperties has 1 1 0..* 0..* loads 0..* refers to Show DatabaseConne ctionProfile 1 1 1 1 has composed of 0..* Simula tionsm odell 0..* 1 Simul ation runs 1 Simulati onThread uses 0..* 1 DBConnection uses 0..* 1 1 0..* composed of 1. .* TransactionModel Isola tionLev el has 1 0..* - R% U% I D% P applies 1 0..* refers 0..* Während der Simulation können die Isolationsgrade, die Pausezeit, sowie die R%, U%, I und D% der verwendeten Thread-Modelle übersteuert werden. Re ad Operation Update Ins ert Del ete Diagramm 2: Fachklassendiagramm Dieses Fachklassendiagram diente in der Analysephase als Hilfsmittel zur Klärung der Fachterminologie. Der gegenwärtige Massstab für die Klassennamen und Fachbegriffe des Transaktionssimulators sind die Klassendiagramme in Kapitel 3.4 und Anhang A. 2.4 Architektur Die im Pflichtenheft vorgeschlagene Grobarchitektur in Diagramm 3: Systemübersicht" ist nach wie vor gültig. Das Package-Diagramm in Kapitel 3.2 zeigt wie die Architektur in die aktuelle Package-Struktur übernommen und ergänzt wurde. Seite 9 von 66 Transaktionssimulator Dozent GUI Simulator RDBMS Konfigurator Studenten Filesystem Diagramm 3: Systemübersicht 2.5 GUI Aufgrund der während der Analyse festgestellten Wichtigkeit des GUI, wurde in der Analysephase ein LoFi-Prototyp entwickelt, um frühzeitig diesbezügliche Anforderungen zu erheben. Diagramm 4: Visio Zeichnung eines möglichen GUI Seite 10 von 66 Diagramm 4 zeigt eine Visio-Zeichnung, welche Bestandteil dieses Prototyps war. Diagramm 7 zeigt die Umsetzung der Anforderungen im realisierten Programm. 2.6 Produkt Perspektive 2.6.1 Wichtigste Anforderungen Der Transaktionssimulator bietet folgende Hauptfunktionen: • • • Verwalten von Simulationsmodellen Durchführen von Simulationen Visualisieren und Präsentieren von Simulationsergebnissen Der Transaktionssimulator soll folgende Informationen anzeigen: a) b) c) d) e) f) Anzahl Transaktionen Anzahl Deadlocks Anzahl Lost-Updates Anzahl Phantoms Transaktionszeit Deadlock-Zeit Der Transaktionssimulator soll folgende Einstellungen erlauben a) b) c) d) e) f) g) Transaktionsmuster (z.B. RR oder RU) Isolationsgrad (0-3) Anzahl gelesene Datensätze in Prozent (R%) Anzahl geänderte Datensätze in Prozent von R% (U%) Absolute Anzahl geänderte Datensätze (I) Anzahl der gelöschten Datensätze in Prozent (D%) (Optional) Flag ob Transaktion mit Commit abgeschlossen wird Es ist keine Funktionalität zum kreieren von Reports vorgesehen. Der Transaktionssimulator soll als Rich-Client implementiert werden, der (evt. über ein Netzwerk) auf eine Datenbank zugreift. Die Simulationsmodelle und andere Konfigurationsdaten werden als XML Dateien lokal gespeichert. 2.6.2 Benutzer Der Transaktionssimulator soll von zwei Benutzergruppen verwendet werden: Dozenten und Studenten. Dozent Der Dozent bedient den Transaktionssimulator, um Simulationsmodelle zu definieren und Präsentationen vorzubereiten, sowie die Simulationen durchzuführen. Er arbeitet mit Mouse, Keyboard und PC-Bildschirm. Die Zweckmässigkeit des GUI-Entwurfs für diese Arbeiten muss anhand eines Prototyps erhoben und vom Kunden beurteilt werden. Student Der Transaktionssimulator-Rechner kann zum Zweck der Präsentation in einem Unterrichts-Raum an einen Beamer angeschlossen sein. Die Studenten sitzen im Vorlesungszimmer und verfolgen die Simulationen auf der Projektionsfläche. Die Seite 11 von 66 Qualität der Darstellung, insbesondere die Anordnung von Inhalten, Kontrast und Helligkeit, Schriftart und -grösse müssen experimentell anhand eines Prototyps erhoben und vom Kunden beurteilt werden. Optional können Studenten im Rahmen eines Praktikums individuell oder in kleinen Gruppen mit dem Transaktionssimulator experimentieren. Seite 12 von 66 3 Architektur/Design 3.1 Architektur Es gilt die in Diagramm 3: Systemübersicht" abgebildete Top-Level Architektur, mit den drei Hauptmodulen GUI, Simulator und Konfigurator, sowie den Umsystemen RDBMS (Datenbank) und lokales Filesystem. 3.2 Packages Im Design wurden die Modulen der Top-Level Architektur mittels Packages entsprochen. Siehe Diagramm 5: Packagediagramm" sowie pkg Komponenten 2 gui statistics «visualise» (from transim) «visualise & edit» (from transim) «control» mode l «produce» simulator «execute» (from transim) (from transim) «use» ma in database (from transim) (from transim) Diagramm 5: Packagediagramm Seite 13 von 66 Modul / Schnittstelle Package GUI net.clearmountain.transim.gui Simulator net.clearmountain.transim.simulator Konfigurator net.clearmountain.transim.model Schnittstelle zum RDBMS net.clearmountain.transim.database zusätzlich net.clearmountain.transim.statistics Tabelle 2: Modulen und Packages 3.3 Sourcing Aufgrund der Anforderungen [1] wurde untersucht welche - möglichst Open Source Komponenten für das Projekt in Frage kämen. Mittels Internet-Recherche wurden viele Pakete gefunden, und schlussendlich folgende Pakete ausgewählt: Paket Erwartung Swing Application Framework [5] Soll die Entwicklung von Swing-Anwendungen für den Anfänger einfach ermöglichen. swingX [6] Soll das gewünschte zuklappbare Panel, welches im Standard Swing-Bibliothek fehlt, beitragen. JFreeChart [7] Soll eine fixfertige Lösung für das zeichnen von Grafiken bieten. MiGLayout [8] Wurde erst später zugefügt: Soll eine benutzerfreundliche Alternative zu den Standard Swing Layout-Managern bieten. Tabelle 3: Extern bezogene Komponenten Für eine (subjektive) Bewertung dieser Pakete siehe 6.4 "Erfahrungen". Das Design dieser Komponenten ist kein Bestandteil dieses Berichts. Seite 14 von 66 3.4 Übersicht class IntegratedView «interface» SimulationVisualizer Stac kedP anel 1 2 1 1 «use» «use» 1 Task TranSim ModelSta tistics StatisticsTra nsferProcess 1 «use» 0..* 1 0..* +userModelStatistics +TransactionModelStatistics 1 1 «use» ModelFactory DisplayValues 1 «create» 1 «use» 2 ArrayList<SimulationModel> SimulationContext Show 1 1 Simulation Statistics 1 1 1 «use» 1 TransactionStatistics simulationContext +simulationModel 0..* +dataTierFactory 1 ArrayList<UserModel> +simulationModel Simul ationModel 1 1 «interface» Simulator 1 «interface» DataTierFactory «create» 1 DefaultS imulator «create» JDBCDataTierFactory 0..* +simulation 0..* 0..* ArrayList<TransactionModel> +userModel Use rMo del 1 1 Simulati onThread +dataTier 0..* 1 «interface» DataTier 1 0..* JPADataTier ArrayList<Operation> TransactionModel JDBCDa taTier «create» «use» 1 1 1 DatabaseConne ctionProfile «use» 1 0..* «enumeration» Opera tion Conne ction Database Profile «use» Diagramm 6: Übersichts Klassendiagramm Seite 15 von 66 3.4.1 Package net.clearmountain.transim Klasse Verantwortlichkeit ApplicationGlobals Diese Singleton Klasse enthält Variablen welche in verschiedenen Teilen des Programms benötigt werden. Änderungen werden als PropertyChange Events an Subscribers propagiert. So wird z.B. die Kommunikation zwischen GUI und anderen Objekte realisiert. SimulationContext Bietet eine Umgebung für alle für eine Simulation benötigten Objekte. Der Transaktions-simulator verfügt über zwei unabhängige SimulationContext, je eine für die linke und rechte Hälfte des Simulatorfensters. StatisticsTransferProcess Diese Klasse läuft in einem separaten Thread, und transferiert im Takt (Transfer Rate) statistische Werte aus dem SimulationStatistics Objekt in das StackedPanel Objekt, das die Grafiken umfasst. TranSim Die Applikations-Klasse. TranSimException Die Spezialisierung von Exception für TranSim. Utils Verschiedene allgemeine Methoden. 3.4.2 Package net.clearmountain.transim.gui Klasse Verantwortlichkeit AboutDialog Copyrights präsentieren. BarChartPanel Mehrere unabhängige Bar Charts horizontal neben einander präsentieren. Ist die Basisklasse für ResultsPerUserModelPanel und ResultsPerTransactionModelPanel. ControlPanel Dem Benutzer ermöglichen, ein Simulationsmodell auszuwählen, sowie ein Simulationslauf zu starten, anzuhalten oder zu stoppen. DefaultSimulationVisualizer Als Top-Level GUI-Objekt alle andere GUIElemente enthalten. Ist die DefaultImplementierung des Interface SimulationVisualizer. LegendPanel Die Messwerte (Anzahl Transaktionen, Phantome usw.), mit ihren aktuellen Farben Seite 16 von 66 präsentieren. MyMenuBar Der JMenuBar der Anwendung. ParameterPanel Dem Benutzer ermöglichen, die Parameter aller Transaktions-Modelle des aktuell selektierten Simulationmodells zu ändern. ResultsPerTransactionModelPanel Die Messwerte für alle Transaktions-Modelle des aktuellen Simulationsmodells präsentieren (Subklasse von BarChartPanel). ResultsPerUserModelPanel Die Messwerte für alle User-Modelle des aktuellen Simulationsmodells präsentieren (Subklasse von BarChartPanel). SimulationPanel Sammelt alle graphische Objekte für eine Hälfte (links oder rechts) des Hauptfensters. SimulationVisualizer (Interface) Den Einsatz verschiedener Implementierungen ermöglichen. StackedBox Zuklappbare Container (mit entsprechenden Bedienungselemente) für die graphischen Komponenten zur Verfügung stellen. (Bestandteil des externen SwingX Package) StackedPanel Container für sämtliche StackedBox Objekte. Kapselt die externe SwingX Komponente. TotalResultsPanel Die aggregierten Messwerte über die ganze Simulation hinweg präsentieren. 3.4.3 Package net.clearmountain.transim.optionspanel Klasse Verantwortlichkeit AbstractCard Eine abstrakte Klasse, welche die gemeinsamen Eigenschaften einer Card implementiert. Eine Card ist der Teil des Optionspaneel, welcher die Felder und Buttons für eine Gruppe von Optionen umfasst. ColorsCard Spezialisierung der Klasse Card für die Farbeinstellungen. DatabaseCard Spezialisierung der Klasse Card für die Datenbankeinstellungen. DatabaseConfiguration Bestandteil der DatabaseCard, je ein Objekt pro SimulationContext. (Jeder SimulationContext verfügt über eigene Datenbankeinstellungen.) Seite 17 von 66 FilePathCard Spezialisierung der Klasse Card für die Dateipfadeinstellungen. (Nicht implementiert.) ICard Interface welches vom AbstractCard implementiert wird. OptionsPanel Ein Dialog in welcher mehrere Gruppen von Optionen verwaltet werden können. ScalesCard Spezialisierung der Klasse Card für die Skalierungseinstellungen (der Achsen der Grafiken). SimulatorCard Spezialisierung der Klasse Card für die Simulatoreinstellungen. SimulatorConfiguration Bestandteil der SimulatorCard, je ein Objekt pro SimulationContext. (Jeder SimulationContext verfügt über eigene Simulatoreinstellungen.) 3.4.4 Package net.clearmountain.transim.simulator Klasse Verantwortlichkeit Simulator Interface, welches verschiedene Implementierungen von Simulator ermöglicht. DefaultSimulator Eine Simulator Implementierung, welche aber so generisch ist, dass sie für alle Implementierungen vom Interface DataTier verwendet werden kann. SimulationThread Eine Spezialisierung der Klasse Runnable, welches ein zugewiesenes Benutzermodell in einer Endlosschleife "ausführt". 3.4.5 Package net.clearmountain.transim.model Klasse Verantwortlichkeit ModelChangeEvent Event für ModelChangeListener. ModelChangeListener Observer Implementierung für Objekte, welche Änderungen im Simulationsmodell nachvollziehen müssen. ModelFactory Factory zum produzieren von Modellen auf allen Ebenen der Aggregation (Show, SimulationsModell, Benutzermodell usw.) ModelParseException Exception Spezialisierung für Probleme beim Seite 18 von 66 Parsen einer Modell-Datei. ModelParser Eine Spezialisierung der Klasse DefaultHandler, für das Parsen der XML Modell-Datei. Operation Eine Enumeration von Datenbank-Operationen (d.h. Read, Update usw.) ParameterSet Tiefste Stufe des Modells. Ermöglicht das einmalige definieren mehrfach verwendeter Parameter für Transaktionsmodelle. Show Die höchste Stufe des Modells. Fasst eine oder mehrere Simulationsmodelle zusammen in einem "Show". Showparameters Erlaubt das Setzen von mehreren showbezogenen Parametern im ApplicationGlobals auf ein Mal. SimulationModel Die Stufe des Modells, welche als ganzen vom Simulator simuliert wird. Es kann eine oder mehrere Benutzermodelle umfassen. TransactionModel Die Stufe des Modell, welche eine Reihefolge von Datenbankoperationen festlegt. UserModel Die Stufe des Modells, welche eine Menge Benutzertypen definiert, jeder bestehende aus einer Menge von Transaktionsmodellen. 3.4.6 Package net.clearmountain.transim.database Klasse Verantwortlichkeit AccountProfile Enthält alle für ein Benutzer-Account auf einer Datenbank notwendigen Angaben. AccountProfileParser Eine Spezialisierung der Klasse DefaultHandler, für das Parsen der XML Accounts-Datei. DatabaseProfile Enthält alle für ein bestimmtes Datenbankprodukt spezifische (also nicht JDBC-Standard entsprechende) Angaben. DatabaseProfileParser Eine Spezialisierung der Klasse DefaultHandler, für das Parsen der XML Databases-Datei. DataTier Ein Interface, welche von der Art der Datenablage abstrahiert. Bietet Methoden wie read(), update(), commit() usw. Kann für eine Klasse von Datenablagen, z.B. RDBMS oder eine Persistenzschicht implementiert werden. Seite 19 von 66 Jede Simulation verfügt über eine eigene DataTier-Instanz, welche eine eigene Verbindung mit der Datenbank unterhält. DataTierFactory Ein Interface für die Factory, welche DataTierInstanzen kreiert. JDBCDataTier Implementation von DataTier für eine JDBC Datenablage. JDBCDataTierFactory Implementation von DataTierFactory für das Kreieren von JDBCDataTier Instanzen. 3.4.7 Package net.clearmountain.transim.statistics Klasse Verantwortlichkeit DisplayValues Datenobjekt, welches genau die Werte enthält, welche im GUI angezeigt werden können. ModelStatistics Datenobjekt, welche die Werte Definiert worin die statistischen Transaktionsdaten gespeichert und verwaltet werden können. SimulationStatistics Interface für das Objekt, welches für ein SimulationContext die statistischen Transaktionsdaten speichert und verwaltet. Es kreiert auf Anfrage des StatisticsTransferProcess DisplayValuesInstanzen. SlidingAverageSimulationStatistics Implementation von SimulationStatistics welche den gleitenden Durchschnitt aller statistischen Transaktiondaten errechnen kann. TransactionStatistics Datenobjekt, dass die statistischen Transaktiondaten umfasst. Wird von einem DataTier-Instanz auf Anfrage eines SimulationThread erzeugt. 3.5 Abläufe 3.5.1 Hauptabläufe Das Kernstück des Transaktionssimulators bilden die zwei Hauptabläufe "Screen Refresh Zyklus" und "Transaction Statistics Zyklus". Die beiden Zykli greifen also über das SimulationStatistics Objekt in einander, haben aber sehr unterschiedliche Frequenzen. Der Screen Refresh Zyklus wird durch einen Timer getaktet, und so regelmässig angestossen. Der Transaction Statistics Zyklus wird dagegen vom Abschluss einer Transaktion, der in nicht deterministischer Zeit abläuft, angestossen. Seite 20 von 66 3.5.1.1 Screen Refresh Zyklus Der Screen Refresh Zyklus wird getrieben vom StatisticsTransferProcess, welches in einem separaten Thread und von einem Time getaktet, DisplayValue-Objekte beim SimulationsStatistics Objekt anfordert, und sie an das StackedPanel des GUI (zur unvermittelter Ausgabe weitergibt. Die Refresh Rate kann vom Benutzer eingestellt werden. Weil mehrere Transfers pro Sekunde verarbeitet werden können, entsteht ein "live" Effekt bei der Simulation. sd Display-Zyklus main::StatisticsTransferProcess statistics::SimulationStatistics «interface» lang::Thread gui::SimulationVisualizer getSnapshot() :DisplayValues :DisplayValues processStatistics(SimulationStatistics) sleep() getSnapshot() :DisplayValues :DisplayValues processStatistics(SimulationStatistics) sleep() 3.5.1.2 Transaction Statistics Zyklus Der Transaction Statistics Zyklus wird getrieben vom SimulationThread, wovon es für jede Benutzer-Instanz eine gibt. Ein SimulationThread arbeitet in einer Endlosschleife alle Transaktionsmodelle seines Benutzermodells ab. Am Ende jeder Transaktion fordert der SimulationThread bei seinem DataTier-Instanz die statistischen Transaktionsdaten in Form eines TransactionStatistics Objekts an. Danach liefert er das TransactionStatistics Objekt an das SimulationStatistics ab, welches damit seine Administration von Messwerte aktualisiert. Seite 21 von 66 sd Simulationszyklus simulator::SimulationThread model::SimulationModel model::UserModel model::TransactionModel database::JDBCDataTier statistics::SimulationStatistics next() :UserModel :UserModel next() :Tran sactionModel execute(DataTier) read(int) update(int) etc...() getTransactionStatistics() :TransactionStatistics processTransactionStatistics(TransactionStatistics) 3.5.2 Kommunikation zwischen GUI und andere Module Die Abläufe der interaktiven Steuerung finden sequentiell auf dem s.g. EDT (Event Dispatch Thread) von Java's Swing statt. Die Betätigung von Controlls wird in Form von ActionEvents an andere Objekte weitergegeben. Langdauernde Aktionen müssen zwingend in separaten Thread ablaufen, weil sie sonst den EDT blockieren und das GUI dadurch nicht mehr flüssig bis gar nicht mehr reagiert. Eine wichtige Entkopplung zwischen GUI und andere Komponenten, deren Parameter mittel GUI geändert werden, ist die Singleton Klasse ApplicationGlobals, welche als Schaltzentrale für die Kommunikation des GUI mit dem Rest dient. Seite 22 von 66 4 Implementation 4.1 GUI 4.1.1 Simulations-Hauptfenster Diagramm 7: Simulations-Hauptfenster Seite 23 von 66 4.1.2 MyMenuBar XYZ 4.1.3 OptionsPanel Der Umgang des OptionsPanel rechtfertigt ein eigenes Package. 4.1.3.1 Simulatoroptionen 4.1.3.2 Datenbankoptionen Seite 24 von 66 4.1.3.3 Skalierungsoptionen Die Skalierungsoptionen ermöglichen das Einstellen von globalen Werten für die Skalen der Achsen aller Grafiken. In der Modell-Datei können entsprechende Default Werte konfiguriert werden. 4.1.3.4 Farboptionen Für die Farbe-Optionen gibt es keine entsprechenden Anforderungen. Es wurde als Prototyp entwickelt für die Simulator-, Datenbank- und Skalierungseinstellungen. Seite 25 von 66 4.2 Simulator Zusammenfassung von [1] und [2]. Die Testtabelle TrxTable, auf der alle Transaktionen operieren, hat folgende Attribute: name typ Beschreibung pkey numeric(10,0) autoincrement Primärschlüssel. Wir in der Applikation für den Update benötigt. searchKey double Nach diesem Attribut wird beim Lesen gesucht. Die Werte sind zufällig zwischen 0 und 100 verteilt. Auf diesem Feld besteht ein Index. data int Dieses Feld wird gelesen und in nachfolgenden UpdateBefehlen jeweils um 1 inkrementiert. tranCount int Dieses Attribut wird unmittelbar bei jedem Update-Befehl um 1 inkrementiert. Bemerkungen Standardmässig wird die Testtabelle mit 100 Datensätze initialisiert. Wesentlich mehr oder weniger Datensätze erhöhen oder erniedrigen die Wahrscheinlichkeit für Deadlocks, Phantoms, Lost Updates in nicht-linearer Weise: Um didaktisch anschauliche Resultate zu demonstrieren, müssen entsprechende Tests gefahren werden.Jeder Thread-Instanz akkumuliert die Ergebnisse jeder einzelne Transaktion in seine TransactionStatistics Seite 26 von 66 Die Klasse SimulationStatistics akkumuliert die TransactionStatistics Erste R-Operation (in den Transaktionsmodellen R, RR und RU) Sollen beispielsweise 10% der Datensätze gelesen werden, sucht die Simulation einen zufälligen Startwert für searchKey zwischen 0 und 90. Ausgehend von diesem Startwert werden die nächsten 10% gelesen, d.h. SEL_PRCNT = 10 lowSelBound = Random * (100 - SEL_PRCNT) maxSelBound = lowSelBound + SEL_PRCT (lowSelBound, maxSelBound) werden in folgendem SQL-Statement für die Fragezeichen substituiert SELECT primKey, data, tranCount FROM TrxTable WHERE searchKey >= ? AND searchKey < ? das Statement ausgeführt, und die Daten in einen RecordSet rs eingelesen. U-Operation Die Simulation nimmt nur eine einzige Art Änderung auf dem Wert von data vor: Der Wert wird in der Applikation um 1 erhöht und anschliessend zurück geschrieben. Der Wert von tranCount wird im Update-Befehl um 1 erhöht (wenn der Datensatz also bereits mit einer exklusiven Sperre belegt ist). Der in der R-Operation eingelesene RecordSet rs wird jetzt durchlaufen. Wenn für einen Datensatz gilt: Random * 100 <= UPD_PRCNT denn werden die gelesenen Werte für (data, primKey) in folgendem SQL Statement UPDATE TrxTable SET data = ? + 1, tranCount = tranCount + 1 WHERE primKey = ? substituiert und schliesslich das Statement ausgeführt. Das UPDATE Statement gibt die Anzahl mutierte Datensätze zurück. Es wird im Normalfall den Wert 1 zurück erwartet. Wenn aber der Wert 0 zurück kommt heisst das, dass der Datensatz nicht mehr vorhanden ist, weil eine D-Operation diesen vorher gelöscht hat. Diesen Fall wird als «Missed Update» d.h. ein Lost Update gezählt und in totalMissedUpdates totalisiert. Seite 27 von 66 Die zweite und weitere R-Operation (in Transaktionsmodellen RR...) Die Datensätze im RecordSet rs werden mit rs.next() gezählt und die Summe in count1 gespeichert. Danach wird denselben SQL-Code wie in der ersten ROperation ausgeführt, wobei (lowSelBound, maxSelBound) wieder substituiert werden SELECT primKey, data, tranCount FROM TrxTable WHERE searchKey >= ? AND searchKey < ? und die Datensätze in einen neuen RecordSet rs eingelesen und anschliessend mit rs.next() gezählt, und die Summe in count2 gespeichert. Und so weiter für 3 und mehrere R-Operationen. I-Operation INSERT TrxTable WHERE searchKey >= ? AND searchKey < ? D-Operation DELETE FROM TrxTable WHERE serachKey >= ? AND searchKey < ? Es wird ein Prozentsatz der in der vorangegangenen R-Operation gelesenen Datensätze gelöscht. Lost Updates Lost Updates können auftreten, wenn mehrere Transaktionen denselben Wert lesen, bearbeiten, und später das Ergebnis zurück schreiben bzw. einen Datensatz löschen, also beim Transaktionsmuster RU und einer Mischung von RU und D. Die Differenz zwischen data und tranCount entspricht der Anzahl Lost-Updates. SELECT SUM(tranCount - data) FROM TrxTable hinzugezählt werden müssen aber noch die totalMissedUpdates. Phantoms Phantome treten nur bei wiederholtem lesen, also bei Transaktionsmuster RR auf in Kombination mit einer I-Operation. Die Zahl ergibt sich aus abs(count2 - count1). Seite 28 von 66 Deadlocks Die Deadlocks werden gezählt nach der entsprechende Anzahl SQLExceptions welche geworfen werden mit SQLState = 40001. 4.3 Konfigurator Der Konfigurator besteht aus folgenden XML Dateien: Datei Zweck TRANSIM_HOME\model.xml Definiert die Simulationsmodelle TRANSIM_HOME\databases.xml Definiert datenbank-produkspezifische Angaben TRANSIM_HOME\accounts.xml Definiert Datenbankbenutzer-Accounts Die Modellhierarchie ist im Diagramm 8: Modellhierarchie Der Transaktionssimulator verwendet für alle Modelle eine einzige Konfigurationsdatei, welche standardmässig TRANSIM_HOME\model.xml ist. In der Anwendung kann im Menü Datei -> Öffnen eine andere XML-Datei geladen werden. 4.3.1 model.xml Die Datei model.xml definiert das Modell in fünf Ebenen auf: Tag Ebene parameterSets Mit Parametersets können oft verwendete Parameterwerte für ein Transaktions-Modell einmal definiert und mehrfach Seite 29 von 66 Tag Ebene referenziert werden. transactionModels Das Transaktionsmodell (transaction model) repräsentiert eine Reihefolge von Datenbank-Operationen aus welcher eine bestimmter Transaktions-Typ besteht. Die mögliche Operationen sind: Read, Update, Insert, Delete und Commit. So bedeutet die Notation "RR" Read-Read, also zwei LeseOperationen nach einander. userModels Das Benutzermodell (user model) repräsentiert ein Benutzertyp. Es besteht aus eine Reihefolge von Transaktionsmodellen. So bedeutet die Notation "Benutzertyp A: 2 x RR + 1 x RU", dass ein Benutzer vom Typ A zweimal eine Transaktion vom Typ "RR" und danach eine Transaktion vom Typ "RU" ausführt. simulationModels Das Simulationsmodell (simulation model) ist das, was der Simulator während einer Simulation "ausführt", d.h. eine oder mehrere Instanzen von einem oder mehreren Benutzertypen. Der Benutzer der Transaktions-simulators kann in jeder Hälfte des Simulations-Fensters ein Simulationmodell selektieren und simulieren. Das Simulationsmodell besteht aus einem oder mehreren Benutzermodelle. So bedeutet die Notation 1 x A + 2 x B, dass die Simulation Benutzertypen A und B in einem Mengenverhältnis 1:2 enthält. Wenn der Simulation z.B. über 30 Simulations-Threads verfügt, gäbe dies 10 simulierte Instanzen von Benutzertyp A und 20 von Benutzertyp B. shows Eine Show fasst eine oder mehrere Simulationsmodelle zusammen. Eine model.xml Datei kann mehrere Shows umfassen, welche über das Datei-Menu selektierbar sind. Eine Model muss nur einmal definiert werden, und kann über seinen id von anderen Modellen mehrfach referenziert werden. Beispiel: Das Simulationsmodell mit dem Namen "Demo 3" hat die id "Demo3". <simpleSimulationModel id="Demo3"> <name>Demo 3</name> <transactionModelRef ref="RU_2" qty="2"/> <transactionModelRef ref="RR_2" qty="1"/> </simpleSimulationModel> Das Simulationsmodell referenziert u.A. das Transaktionsmodell mit dem id "RU_2", das anderswo wie folgt definiert wurde <transactionModel id="RU_2"> <name>RU2</name> <isolationLevel>2</isolationLevel> <parameterSetRef ref="default_RU"/> </transactionModel> Die ids und Namen sind frei wählbar. Seite 30 von 66 4.3.1.1 parameterSets Im Element parameterSets können null oder mehrere Elemente vom Typ parameterSet definiert werden. Ein parameterSet verfügt über ein id Attribut anhand wovon es von einem oder mehreren Transaktionsmodellen referenziert werden kann. Folgende Angaben gelten immer für eine Transaktion. Der parameterSet kann folgende Elemente beinhalten: Element Verwendung Steuert Bereich pattern obligatorisch Das Transaktionsmuster, d.h. die Sequenz von DatenbankOperationen. Der Syntax in EBNF: (R | RU | RD | I )+ readPercent optional Wie viel Prozent der Datensätze eine R-Operation in der Datenbank liest 0-100 updatePercent optional Wie viel Prozent der in der vorangegangenen R-Operation gelesenen Datensätze von der UOperation geändert wird 0-100 insertAmount optional Wie viele Datensätze in die Datenbank eingefügt werden deletePercent optional Wie viel Prozent der in der vorangegangenen R-Operation gelesenen Datensätze von der DOperation gelöscht wird 0-100 operationDelay obligatorisch Wie gross der Zeitabstand in Millisekunden zwischen zwei Operationen durchschnittlich sein soll. Der Transaktionssimulator erzeugt Zufallswerte mit uniformer Verteilung. nicht-negative Ganzzahl commitDelay Wie gross der Zeitabstand in Millisekunden zwischen der letzten Operation und dem COMMIT ist. Ein negativer Wert repräsentiert das Ausbleiben eines COMMIT, d.h. führt i.d.R. zu einem Timeout. obligatorisch nicht-negative Ganzzahl Ganzzahl 4.3.1.2 transactionModels Im Element transactionModels können null oder mehrere Elemente vom Typ transactionModel definiert werden. Ein Transaktionsmodell verfügt über ein id Attribut, anhand wovon es von Benutzermodellen referenziert werden kann. Ein transactionModel, dass ohne Hilfe eines parameterSet definiert wird, kann dieselbe Elemente enthalten wie ein parameterSet, und zusätzlich die folgenden Elemente: Element Verwendung Steuert Bereich name obligatorisch Syntax in EBNF: [AZa-z_]+[A-Za-z_0-9 Den Namen, unter welche das Transaktionsmodell im GUI sowie Seite 31 von 66 Element Verwendung Steuert in den Statistiken bekannt ist. Wenn mehrere Transaktionsmodelle in einer Simulation denselben Namen haben, werden sie bezüglich Anzeige und statistischen Werten nicht unterschieden. isolationLevel obligatorisch parameterSetRef optional / mehrfach Bereich \-]* Der Isolationsgrad unter welchem die Transaktion auf der Datenbank läuft. 0-3 Die Referenz auf ein parameterSet, welches die weiteren des Transaktionsmodells Elemente enthält. Attribut "ref" mit Syntax in EBNF: [AZa-z_]+[A-Za-z_0-9 \-]* Beispiel: <transactionModel id="RI_10"> <name>RI1_1</name> <isolationLevel>1</isolationLevel> <pattern>RI</pattern> <readPercent>1</readPercent> <operationDelay>10</operationDelay> <commitDelay>0</commitDelay> </transactionModel> Ein Transaktionsmodell, dass die Werte eines parameterSets verwendet, hat neben den Attributen in Tabelle XYZ mittels des Elements parameterSetRef eine Referenz auf den parameterSet: Beispiel: <transactionModel id="I_0"> <name>I0</name> <isolationLevel>0</isolationLevel> <parameterSetRef ref="default_I"/> </transactionModel> 4.3.1.3 userModels Im Element userModels können null oder mehrere Elemente vom Typ userModel definiert werden. Ein Benutzermodell verfügt, wie alle Modelle, über eine id anhand wovon es von Simulationsmodellen referenziert werden kann. Das userModel hat folgende Elemente: Seite 32 von 66 Element Verwendun g Steuert Bereich name obligatorisc h Den Namen, unter welche das Benutzermodell im GUI sowie in den Statistiken bekannt ist. Wenn mehrere Benutzermodelle in einer Simulation denselben Namen haben, werden sie bezüglich Anzeige und statistischen Werten nicht unterschieden. Syntax in EBNF: [A-Za-z_]+[A-Zaz_0-9 \-]* interTransactionDela y obligatorisc h Wie gross der Zeitabstand in Millisekunden zwischen Transaktionen desselben Benutzers durchschnittlich sein soll. Der Transaktionssimulator erzeugt Zufallswerte mit uniformer Verteilung. transactionModelRef optional / mehrfach Die Referenz auf ein transactionModel. Das Attribut "ref" enthält die id des referenzierten Transaktionsmodells. Das Attribut "qty" definiert die relative Menge des Transaktionsmodells innerhalb des Benutzermodells. nicht-negative Ganzzahl Attribut "ref": Syntax in EBNF: [A-Za-z_]+[A-Zaz_0-9 \-]* Attribut "qty": nichtnegative Ganzzahl Beispiel: <userModel id="oltp"> <name>OLTP-Benutzer</name> <interTransactionDelay>100</interTransactionDelay> <transactionModelRef ref="RR_10" qty="2"/> <transactionModelRef ref="RU_10" qty="1"/> <transactionModelRef ref="RD_10" qty="1"/> <transactionModelRef ref="RI_10" qty="1"/> </userModel> 4.3.1.4 simulationModels Simulationsmodelle gibt es in zwei Varianten: das simulationModel und das simpleSimulationModel. Das simpleSimulationModel lässt die Modellierungsebene des userModel aus, und besteht somit lediglich aus Transaktionsmodellen. Die Anwendung schiebt später automatisch das Benutzermodell "default" zwischendrin. Das simpleSimulationModel erlaubt eine einfache Modellierung für Fälle worin nur das Verhalten von Transaktionsmodellen interessiert. Im Element sumlationModels können null oder mehrere Elemente vom Typ simulationModel oder simpleSimulationModel definiert werden. Ein Seite 33 von 66 Simulationsmodell verfügt wieder über eine id anhand wovon es von Shows referenziert werden kann. Das simpleSimulationModel hat folgende Elemente: Element Verwendung Steuert Bereich name obligatorisch Den Namen worunter das Simulation in der Anwendung aus einer Liste gewählt werden kann. Syntax in EBNF: [A-Zaz_]+[A-Za-z_09 \-]* transactionModelRef optional / mehrfach Die Referenz auf ein transactionModel. Das Attribut "ref" enthält die id des referenzierten Transaktionsmodells. Das Attribut "qty" definiert die relative Menge des Transaktionsmodells innerhalb des Simulationsmodells. Attribut "ref": Syntax in EBNF: [A-Zaz_]+[A-Za-z_09 \-]* Attribut "qty": nicht-negative Ganzzahl Beispiel: <simpleSimulationModel id="Demo3"> <name>Demo 3</name> <transactionModelRef ref="RU_2" qty="2"/> <transactionModelRef ref="RR_2" qty="1"/> </simpleSimulationModel> Das simulationModel hat folgende Elemente: Element Verwendung Steuert Bereich name obligatorisch Den Namen worunter das Simulation in der Anwendung aus einer Liste gewählt werden kann. Syntax in EBNF: [A-Za-z_]+[A-Zaz_0-9 \-]* userModelRef optional / mehrfach Die Referenz auf ein userModel. Das Attribut "ref" enthält die id des referenzierten Benutzermodells. Das Attribut "qty" definiert die relative Menge des Benutzermodells innerhalb des Simulationsmodells. Attribut "ref": Syntax in EBNF: [A-Za-z_]+[A-Zaz_0-9 \-]* Attribut "qty": nicht-negative Ganzzahl Beispiel: <simulationModel id="sim1"> <name>Simulation 1</name> <userModelRef ref="olap" qty="1"/> Seite 34 von 66 <userModelRef ref="oltp" qty="1"/> </simulationModel> 4.3.1.5 shows Eine model.xml Datei kann mehrere Shows umfassen, welche über das DateiMenu selektierbar sind. Das Element shows umfasst null oder mehrere Elemente vom Typ show. Das show Element kann null oder mehrere Simulationsmodelle umfassen. Folgende Elemente sind definiert: Element Verwendung Steuert Bereich name obligatorisch Den Namen worunter das Simulation in der Anwendung aus einer Liste gewählt werden kann. Syntax in EBNF: [A-Zaz_]+[A-Za-z_09 \-]* simulationModelRef optional / mehrfach Die Referenz auf ein simulatonModel. Das Attribut "ref" enthält die id des referenzierten Simulationsmodells. Attribut "ref": Syntax in EBNF: [A-Zaz_]+[A-Za-z_09 \-]* Zusätzlich diesen Elementen können im showParameters Element Einstellungen für diverse Parameter gemacht werden. Diese sind unterteilt in drei Gruppen: scalesParameters, simulatorParameters und databaseParameters. scalesParameters resultsTotalInNumberPerSecond Höhe der Achse der 1. Grafik "Resultate Total" resultsTotalInMilliseconds Höhe der Achse der 2. Grafik "Resultate Total" resultsPerUserModelInNumberPerSecond Höhe der Achse der Grafik "Resultate pro Benutzermodell" resultsPerTransactionModelInNumberPerSecond Höhe der Achse der Grafik "Resultate pro Transaktionsmodell" numberOfUserModelGraphPositions Anzahl Bar Charts welche in der Grafik "Resultate pro Benutzermodell" nebeneinander Platz haben numberOfTransactionModelGraphPositions Anzahl Bar Charts welche in der Grafik "Resultate pro Transaktionsmodell" nebeneinander Platz haben simulatorParameters concurrentThreadsInNumber Die Anzahl gleichzeitige Threads. Jeder Thread simuliert einen konkreten Benutzer. Die userModel werden gemäss ihrer durch "qty" spezifizierten relativen Mengen an die Threads zugeteilt (Maximum 1'000). refreshRateInNumberPerSecond Die Frequenz womit die gesammelten Seite 35 von 66 Statistik-Daten im GUI erneuert werden (Maximum 20). simulationTimeInSeconds Die Zeitdauer bevor die Simulation automatisch beendet wird. NICHT IMPLEMENTIERT. windowLengthInSeconds Das Zeitfenster worüber der gleitende Durchschnitt über alle Messgrössen berechnet wird. Bei einem Wert 0, d.h. null, wird der aggregierte Durchschnitt über die ganze Simulationszeit berechnet. databaseParameters numberOfRecords Die Anzahl Datensätze in der Simulations-Datenbank. Nach jedem Stopp der Simulation wird die Datenbank wieder neu aufgebaut und mit dieser Anzahl Datensätze abgefüllt. defaultAccountProfile Das zu verwendete Account-Profil, welches in accounts.xml definiert sein muss. Alle Parameter sind optional und wenn sie nicht spezifiziert sind, werden einprogrammierte Defaults verwendet. Die scalesParameters gelten für beide Simulatoren. Die simulatorParameters und die databaseParameter können jedoch für jeden Simulator separat eingestellt werden. Dies bietet die Möglichkeit z.B. verschiedene Datenbanksystem zu vergleichen. Beispiel: <show> <name>1. Demo-Ablauf</name> <simulationModelRef ref="Demo1"/> <simulationModelRef ref="Demo2"/> <simulationModelRef ref="Demo3"/> <simulationModelRef ref="Demo4"/> <simulationModelRef ref="Demo5"/> <simulationModelRef ref="Demo7"/> <showParameters> <scalesParameters> <resultsTotalInNumberPerSecond>100</ resultsTotalInN...> <resultsTotalInMilliseconds>600</resultsTotalInMill...> <resultsPerUserModelInNumberPerSecond>80</resultsPe...> <resultsPerTransactionModelInNumberPerSecond>80</re...> Seite 36 von 66 <numberOfUserModelGraphPositions>6</numberOfUserMod...> <numberOfTransactionModelGraphPositions>6</numberOf...> </scalesParameters> <simulatorParameters> <concurrentThreadsInNumber>10</concurrentThreadsInN...> <refreshRateInNumberPerSecond>5</refreshRateInNumbe...> <simulationTimeInSeconds>0</simulationTimeInSeconds> <windowLengthInSeconds>10</windowLengthInSeconds> </simulatorParameters> <databaseParameters> <numberOfRecords>100</numberOfRecords> <defaultAccountProfile>My Account</defaultAccountPr...> </databaseParameters> </showParameters> </show> 4.3.2 databases.xml Damit der Transaktionssimulator mit verschiedenen Datenbankprodukten funktioniert, sind gewisse Konfigurationsdaten in der Datei databases.xml ausgelagert. Diese sind: Konfigurationselement Zweck createTrxTableStatement Der SQL-Befehl womit die Simulationstabelle erzeugt wird. createTrxIndexStatement Der SQL-Befehl womit der Index für die Simulationstabelle erzeugt wird. perConnectionOptionsStatements SQL-Befehle womit pro JDBC-Session Optionen in der Datenbank eingestellt werden. driverClass Der vollständige Klassename des zu verwendenden JDBC-Drivers. Zusätzlich muss in der Umgebungsvariable CLASSPATH der Verzeichnispfad zur .class oder .jar Datei des JDBC-Treibers angegeben sein. Beispiel: <?xml version="1.0" encoding="UTF-8"?> <databases> <database name="Sybase SQL Anywhere 9"> <createTrxTableStatement> CREATE TABLE TrxTable_$ID$ ( primKey NUMERIC( 10,0) NOT NULL DEFAULT AUTOINCREMENT, Seite 37 von 66 searchKey DOUBLE NOT NULL CHECK ( searchKey &gt;= 0 AND searchKey &lt;= 100 ), data INT NOT NULL DEFAULT 0, tranCount INT NOT NULL DEFAULT 0, PRIMARY KEY ( primKey ) ) </createTrxTableStatement> <createTrxIndexStatement>CREATE INDEX i_TrxTable_$ID$_SearchKey ON TrxTable_$ID$( searchKey ) </createTrxIndexStatement> <perConnectionOptionsStatements> <option>SET OPTION COOPERATIVE_COMMITS = OFF</option> <option>SET OPTION DELAYED_COMMITS = OFF</option> </perConnectionOptionsStatements> <driverClass>com.sybase.jdbc2.jdbc.SybDriver</driverClass> </database> <database name="MySQL 5.0"> <createTrxTableStatement> CREATE TABLE TrxTable_$ID$ ( primKey INTEGER NOT NULL AUTO_INCREMENT, searchKey DOUBLE NOT NULL CHECK ( searchKey &gt;= 0 AND searchKey &lt;= 100 ), data INT NOT NULL DEFAULT 0, tranCount INT NOT NULL DEFAULT 0, PRIMARY KEY ( primKey ) ) </createTrxTableStatement> <driverClass>com.mysql.jdbc.Driver</driverClass> </database> </databases> Das Format der Simulationstabelle sowie die Funktionsweise des Simulators ist ausserhalb des Rahmens dieser Benutzeranleitung. 4.3.3 accounts.xml Damit der Transaktionssimulator Zugriff auf eine Datenbank erhält muss mindestens ein Account in der Datei accounts.xml konfiguriert sein. Ein Account kann als Default markiert sein, ansonsten wird nach Starten der Anwendung das erste Account als Default gewählt. Beispiel: <?xml version="1.0" encoding="UTF-8"?> <accounts> <account name="My local SQL Anywhere 9 Server" default="yes"> <databaseRef ref="Sybase SQL Anywhere 9"/> <userName>dba</userName> <password>sql</password> <connectionURL>jdbc:sybase:Tds:localhost:2638?ServiceName=asademo</conne...> Seite 38 von 66 </account> <account name="My network SQL Anywhere 9 Server"> <databaseRef ref="Sybase SQL Anywhere 9"/> <userName>dba</userName> <password>sql</password> <connectionURL>jdbc:sybase:Tds:localhost:2638?ServiceName=asademo</conne...> </account> <account name="My local MySQL 5.0 Server"> <databaseRef ref="MySQL 5.0"/> <userName>root</userName> <password>sql</password> <connectionURL>jdbc:mysql://localhost/test</connectionURL> </account> </accounts> Seite 39 von 66 5 Tests 5.1 Units Tests Aufgrund des visuellen Charakters des GUI müssen alle Tests manuell vorgenommen werden. Aufgrund des nicht-deterministischen Charakters (multithreading) des Simulators, können auch hier nur manuelle Tests vorgenommen werden. Weil somit kein automatisierter Integrationstest möglich ist, wurde für die übrigen Module auf flächendeckende Unit-Tests verzichtet. Beim Konfigurator wurden die toString() implementiert, womit auch komplexe hierarchische Strukturen, wie die Modelle sind, zur Kontrolle auf der Konsole ausgedruckt werden können. 5.2 Integrationstests In einer ersten Phase wurde das GUI weitgehend entwickelt, und danach der Konfigurator. Dies erlaubte das Testen des Konfigurators, durch die Visualisierung des Modells im GUI. Die verwendeten Szenarien sind im Beispiel model.xml definiert. Die Kontrolle fand handmässig bzw. mit dem Auge statt. Mit der GUIDebugger Klasse konnte jeweils die gesamt Objektstruktur des GUI erzeugt und kontrolliert werden. In einer zweiten Phase sollte ein Simulator eingebaut werden. Dies geschah in einem ersten Schritt mit einem Dummy, der MockSimulator, welche mit Zufallszahlen funktioniert. Zum vergleich wurde einen zweiten Dummy beigezogen, welche mit deterministischen Zahlen funktioniert, der ConstantMockSimulator. So konnten GUI und Kondigurator weiter entwickelt und getestet werden. In der dritten Phase wurde der Simulator entwickelt, und mit dem lauffähigen GUI und Konfigurator integriert. Es stellte sich heraus, dass der Simulator völlig frei von Datenbank-Details aufgebaut, und der Datenbankzugriff an eine DataTier-Instanz delegiert werden konnte. Zuerst wurden der DataTier und seine DataTierFactory durch die Dummies MockDataTier und MockDataTierFactory vertreten. Als der Simulator weit genug entwickelt war, indem er vom GUI steuerbar war, und die Modelle "ausführen" konnte, wurde effektive Implementierungen entwickelt und in den Rest integriert. Mit dem mittlerweile funktionsfähigen Gesamtprogramm wurde mehrmals zusammen mit dem Auftraggeben experimentiert, und die Simulationsergebnisse verifiziert. 5.3 Abnahmetest CON.6 Für den Abnahmetests müssen folgende zwei Konfigurationen (Szenarien) konfiguriert werden können: a) Szenario "OLTP-Benutzer" Seite 40 von 66 Anteil Transaktionsmuster gelesen 2 R 10% 1 RU 10% 10 1 RD 1% 10 1 RI 1% 10 b) Pause (ms) Szenario "OLAP-Benutzer" Anteil Transaktionsmuster gelesen Pause (ms) 3 RR 10% 100 2 RRR 70% 500 1 RRRR 100% 1000 Die Simulationsergebnisse wurden vom Betreuer als plausibel eingeschätzt und das Programm abgenommen. Weitere Feedbacks werden aus der Nutzung im Unterricht erwartet. Seite 41 von 66 6 Besprechung 6.1 Beurteilungsrelevante Kriterien Kriterium Grundlagen Projektdefinition, Pflichtenheft Pflichtenheft [1] Aufwandschätzung, Zeitplanung - Kap. 6.5 Aufwandschätzung - Kap. 6.3.2 Zeitplan Implementation - Kap. 3 Architektur/Design - Kap. 4 Implementation - Code Verifizierung, Test - Diverse Workshops mit dem Betreuer (Auftraggeber) - Kap. 5 Tests Projektmanagement 6.3.2 Zeitplan Kreativität, Initiative, Selbständigkeit Übereinstimmung Produkt / Anforderungen Kap. 6.2 Abweichungen zum Pflichtenheft Dokumentation - Benutzeranleitung [4] - Kap. 3 Architektur/Design - Code (Bezeichner), Kommentar im Code Abnahme Diverse Meetings mit dem Betreuer bzw. dem Auftraggeber und dem Experten, sowie Abnahme durch den Auftraggeber. Schlusspräsentation der Diplomarbeit Findet nach Abgabe diesen Berichts statt 6.2 Abweichungen zum Pflichtenheft 6.2.1 Anforderungsabdeckung AnforderungsID PRO.1 #1 PRO.1 #2 PRO.1 #3 PRO.2 Formulierung Umsetzung Der Transaktionssimulator soll als Rich-Client implementiert werden, ... ... der über ein Netzwerk auf eine Datenbank zugreift. Im Trivialfall muss die Datenbank auf demselben Rechner wie der Transaktionssimulator laufen können. Die Simulationsmodelle und andere Konfigurationsdaten werden auf einer Dateiablage des Benutzers gespeichert. 100% 100% 100% 100% Seite 42 von 66 SCH.1 Folgende Software Schnittstellen sind zu unterstützen: SCH.1 a a) Java Runtime Environment Version ab 1.4 (kapselt u.a. den Zugriff auf das Filesystem) b) JDBC für die Kommunikation mir der Datenbank (JDBC kapselt den Zugriff auf die Datenbank) Der Transaktionssimulator muss mit 1 GB RAM oder mehr [sic!] im Rechner laufen können. Der Transaktionssimulator muss weniger als 30 GB Festplattenspeicher benötigen. Die Installation soll für den Benutzer einfach sein, z.B. mittels eines einzigen jar-File zum auspacken, oder on-the-fly Laden und Starten über Internet via Java Webstart. Der Transaktionssimulator muss in Java programmiert werden. Die Schnittstelle zur Datenbank soll so konzipiert werden, dass eine spätere Einbindung eines auf Java Persistence Framework (JPA) basierten Persistence Layer ohne grosse Änderungen am Design zwischengeschoben werden kann. Das GUI muss die Resultate von zwei Simulationen nebeneinander («sideby-side») anzeigen können. Das GUI muss die Resultate einer Simulation in einem BalkenDiagramm visualisieren. Die Achsen der Resultat-Grafiken dürfen fix eingestellt sein, d.h. müssen sich nicht dynamisch an die Messwerte anpassen. Das GUI muss dem User ermöglichen die Maximalwerte der Achsen der Resultat-Grafiken auf der Show -Ebene ein zu stellen. SCH.1 b MEM.1 MEM.2 BET.1 RES.1 RES.2 GUI.1 GUI.2 GUI.3 GUI.4 GUI.5 #1 GUI.5 #2 GUI.6 GUI.7 GUI.7 a #1 GUI.7 a #2 GUI.7 b GUI.8 GUI.9 GUI.9 a z GUI.9 a l GUI.9 b GUI.9 c GUI.9 d GUI.9 e - Wenn anzuzeigende Ergebniswerte den Maximalwert einer Achse übertreffen, muss das GUI im Resultat-Grafik nur den Maximalwert zeigen ... ... und muss das GUI im Status-Bar eine entsprechende Fehlermeldung zeigen. Das GUI muss dem User ermöglichen auf Applikations-Ebene ein zu stellen wie oft die Grafiken pro Sekunde geupdated werden («Refresh-Rate»). Das GUI muss Simulations-Resultate darstellen: a) Pro Transaktionsmodell der Simulation die in SIM.2.a bis SIM.2.d definierten Werte. a) Für die gesamte Simulation die in SIM.2.a bis SIM.2.d definierten Werte. Pro User-Modell der Simulation die in SIM.2.a bis SIM.2.d definierten Werte. b) Für die gesamte Simulation die in SIM.2.e und SIM.2.f definierten Werte. Das GUI muss dem User ermöglichen eine Simulation zu laden, zu starten, anzuhalten, und zu stoppen. Wenn eine Simulation angehalten ist, muss das GUI dem User ermöglichen folgende Parameter zu ändern: a) Transaktionsmodell (zufügen) a) Transaktionsmodell (löschen) b) Relative Menge eines Transaktionsmodells c) Isolationsgrad für ein Transaktionsmodell d) Prozent gelesener Datensätze (R%) e) Prozent geänderte Datensätze von R% (U%) 0% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 0% 100% 100% 100% Seite 43 von 66 GUI.9 f GUI.9 g GUI.10 #1 GUI.10 #2 GUI.11 DAT.1 DAT.2 DAT.3 SIM.1 SIM.2 SIM.2 a SIM.2 b SIM.2 c f) Anzahl geänderte Datensätze pro Transaktion (I) g) Prozent gelöschter Datensätze (D%) Das GUI muss dem User ermöglichen eine angehaltene Simulation weiterlaufen zu lassen. ... ... Die Simulation muss dabei die eventuell angepassten Parameter verwenden. Das GUI ermöglicht dem User das Zeitfenster für die Berechnung der gleitenden Durchschnittswerte auf Applikations-Ebene ein zu stellen. Die Anwendung muss auf Simulations-Ebene auf unterschiedliche Datenbank-Produkte zugreifen können (innerhalb desselben Programmlaufes). Der Zugriff auf die Datenbank muss über JDBC erfolgen. 100% 100% 100% 100% 100% 100% 100% Die Anwendung muss die benötigten Datenbank-Treiber laden. Die Treiber selber sind nicht im Lieferumfang des Transaktionssimulators. Der Simulator funktioniert gemäss dem im [1] und [2] sowie Anhang A dargelegten Prinzip. Der Simulator erfasst pro Transaktionsmodell für das eingestellte Zeitfenster folgende Werte: a) Anzahl Transaktionen b) Anzahl Deadlocks c) Anzahl Missed Updates 100% 100% 100% 100% - SIM.2 d SIM.2 e SIM.2 f SIM.3 d) Anzahl Phantoms e) Transaktionszeit f) Deadlock-Zeit SQL-Ausdrücke insbesondere für Locking, Transaktionen sowie Datanbank-Optionen, müssen als Konfigurationsdaten produktspezifisch einstellbar sein. 100% 100% 100% 100% SIM.4 Der Simulator muss die Isolationsgrade 0 bis 3 unterstützen. 100% SIM.5 SIM.5 a Der Simulator muss folgende Parameter verwenden: a) Simulationszeit in Sekunden. 0 = kontinuierlicher Lauf SIM.5 b SIM.5 c b) Zeitfenster für die Berechnung gleitender Durchschnitte c) Anzahl gleichzeitige Threads 100% 100% SIM.5 d d) DatabaseConnectionProfile welche die Datenbank definiert worauf die Simulation ausgeführt werden soll e) (Optional) Database-Spezifische Optionen können ausgewählt werden Der Konfigurator bietet dem User die Möglichkeit folgende Entitäten zu verwalten (siehe auch Fachklassendiagramm): a) Show b) Simulation c) Transaktions-Modell d) Simulationsparameter e) DatabaseConnectionProfile 100% SIM.5 e CON.1 CON.1 a CON.1 b CON.1 c CON.1 d CON.1 e CON.2 CON.3 0% Ein Simulationsmodell besteht aus (k)einem oder mehreren Transaktionsmodellen und deren relativen Mengen. Ein Transaktionsmodell hat besteht aus folgenden Parametern: 100% 100% 100% 100% 100% 100% 100% - Seite 44 von 66 CON.3 a CON.3 b CON.3 c CON.3 d CON.3 e CON.3 f CON.3 g DES.1 a a) Transaktionsmuster (z.B. RR oder RU) b) Isolationsgrad (0-3) c) Anzahl gelesene Datensätze in Prozent (R%) d) Anzahl geänderte Datensätze in Prozent von R% (U%) e) Absolute Anzahl geänderte Datensätze (I) f) Anzahl der gelöschten Datensätze in Prozent (D%) g) (Optional) Flag ob Transaktion mit Commit abgeschlossen wird Die Konfiguration der Modelle muss in einer lokal abgelegten XML-Datei erfolgen. Optional bietet das GUI dem Benutzer die Möglichkeit die Konfiguration der Modelle im GUI vor zu nehmen. Für den Abnahmetests müssen folgende zwei Konfigurationen (Szenarien) konfiguriert werden können: a) Szenario "OLTP-Benutzer" b) Szenario "OLAP-Benutzer" Für folgende Modulen müssen abstrakte Schnittstellen verwendet werden, damit verschiedene Implementationen verwendet werden können (compiletime): a) Simulator DES.1 b DES.1 c b) Visualisierung der Simulationsergebnisse c) Datenbank-Produkt 100% 100% DES.1 d d) Optional: Datenzugriff (JDBC und JPA) 100% DES.2 #1 Die in GUI.6 definierten Parameter müssen auf der Ebene Application, Show und Simulationsmodell definiert werden können, wobei die tiefere Ebene Vorrang über die höhere Ebene hat. Die in SIM.5 definierten Parameter müssen auf der Ebene Application, Show und Simulationsmodell definiert werden können, wobei die tiefere Ebene Vorrang über die höhere Ebene hat. 100% CON.4 CON.5 CON.6 CON.6 a CON.6 b DES.1 DES.2 #2 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% WAR.1 Der Code soll angemessen kommentiert sein. 100% EK.1 Die Beschaffungskosten eingekaufter Komponenten dürfen SFr. 200.- nicht übersteigen. Die Berner Fachhochschule erhält die Verwertungsrechte auf das Produkt für nicht-kommerzielle Zwecke im Rahmen ihrer Ausbildungsaufgaben. Bei der Verwendung von Softwaremodulen von Dritter (u.a. auch Open Source) müssen die in den Lizenzvereinbarungen festgehaltenen Restriktionen und Auflagen eingehalten werden. Urheber der Software und Begleitdokumente ist Paul Klarenberg. Bei der Verwendung von Modulen Dritter (u.a. Open Source) müssen die in den Lizenzvereinbarungen verlangte Vermerke 100% LIZ.1 LIZ.2 LEG.1 LEG.2 50% 100% Seite 45 von 66 umgesetzt werden. # -> Später zugefügte Unterteilung um nicht-atomische Anforderungen zu splitten 6.2.2 Nicht umgesetzte Anforderungen GUI.9 b b) Wenn eine Simulation angehalten ist, muss das GUI dem User ermöglichen folgende Parameter zu ändern: Relative Menge eines Transaktionsmodells Nicht umgesetzt, weil in der Analyse nicht davon ausgegangen war, dass dadurch Parameter manipuliert werden müssen sowohl des Transaktionsmodell wie des Benutzermodells. Dies würde das GUI überladen. Gemäss Auftraggeber würde es reichen, die Parameter der Transaktionsmodelle einzustellen, und auf darauf dem Benutzermodell zu verzichten. SIM.5 a Der Simulator muss folgende Parameter verwenden: a) Simulationszeit in Sekunden. 0 = kontinuierlicher Lauf Nicht umgesetzt, weil sich für diese Funktion kein Nutzen herausstellte. Das interaktive Starten und Stoppen der Simulation reicht völlig aus. 6.3 Vorgehen 6.3.1 Vorgehensmodell Zum Anfang des Projekts wurde mit Unterstützung des Experten ein iteratives Vorgehen für das Projekt zusammengestellt (siehe Diagramm 9). Das Bedürfnis für iteratives Vorgehen war vorhergesehen aufgrund der Komplexität sowie des Werkzeug-Charakters des Transaktionssimulators. Das Vorgehen konnte nur grob eingehalten werden. Wegen der starke Abhängigkeit der drei Hauptmodule und die noch grösser als erwartete Komplexität im GUI, musste öfters iteriert werden als vorgesehen. Diese hohe Anzahl Iteration wurde ermöglicht wegen der grossen Verfügbarkeit sowohl des Betreuers (Auftraggebers) wie des Experten. Das Vorgehen wurde dem Umständen entsprechend angepasst, mit Tendenz zum agilen Vorgehen. Seite 46 von 66 Vorgehensmodell Transaktionssimulator v1.0 / 2008-03-17 Aktivität 1 2 3 4 Diagramm 9: Vorgehensmodell 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 Projektmanagement Vorgehen festlegen Feinplanung erstellen Aufwand schätzen Statusbericht erstellen Software-Entwicklung Fachl. Anf. GUI erheben Fachl. Anf. SIM erheben Fachl. Anf. CON erheben Glossar erstellen Grob-Architektur erstellen Alle Fachl. + NFR konsolidieren Module/Schnittstellen designen GUI Design (2 Incr.) GUI Implementation (2 Incr.) SIM Design SIM Implementation CON Design CON Implementation Integration (2 incr.) Konfigurationsmgt. Benutzeranleitung erstellen Gesamtdoku. erstellen Qualitätssicherung Unit Tests Integrationstest Systemabnahme Ergebnis Phase Seq. Vorgehensmodell Kalender Aufwandschätzung Statusbericht 1 2 2 2 LoFi Prototyp/Storyboard UML Activity/State, SQL, ERD UML Class Glossar Kontext/Component Diagram Pflichtenheft UML Package/Class, Patterns UML Class/Object/Sequence Java Code UML Class/Data, SQL Java Code UML Class, DTD/XML-Schema Java Code Jar File 1 1 1 1 1 2 3 4 5 6 7 8 9 10 Benutzeranleitung Diplombericht 1 2 Fehlerliste Fehlerliste Mängelliste 1 2 3 Init. Seite 47 von 66 GUI = Modul Graphical User Interface (für Vorführungen der Simulationsergebnisse) SIM = Modul Simulator CON = Modul Konfigurator NFR = Nicht-funktionale Anforderungen Incr. = Increment Analyse Design Incr. 1 Incr. 2 Data Realisierung Incr. 1 Incr. 2 Integration Incr. 1 Incr. 2 GUI Data GUI GUI,SIM GUI,SIM,CON Einführung Version 0.1 2007-03-08 / P. Klarenberg ProjektW KW <11 Montag Diagramm 10: Zeitplan Seite 48 von 66 Verfügbarkeit Schmidhauser Verfügbarkeit Max Kleiner SOLL-Zeit (Std.) SOLL-Zeit (Std.) kumulativ Verfügbar Kla Mo-Fr Verfügbar Kla Sa/So Verfügbar Kla Tot. kumulativ Saldo SOLL/Verfügbar Kla kum. B Betreuer 1: Kick-off B Betreuer 2: Follow-up E Experte 1: Kick-off 1 17:30 E Experte 2: Kick-off 2 18:30 B Betreuer 3: Storyboard 13:00 E Experte 3: Entwurf PH 17:00 B Betreuer 4: Entwurf PH 15:30 B Betreuer: Abnahme PH MS Abgabe Pflichtenheft MS Upload Abstract Bericht E Experte 4: Design Interf./Patt. 17:00 K Kurs Präsentationstechnik E Experte 5: Design GUI 17:00 14:30 B Betreuer: Feedback E Experte 6: Design SIM/CON 17:00 B Betreuer: Abnahmetest 1 Betreuer: Testen Termin: abmachen! 17:00 E Experte 7: 95% Check B Betreuer: Abnahmetest E Experte: Abnahme MS Upload Diplomarbeit E = Experte B = Betreuer 0 11 +1 12 +2 13 +3 14 Schulferien 15 16 +4 17 +5 18 +6 19 +7 20 +8 21 +9 22 +10 23 10.3.08 17.3.08 24.3.08 31.3.08 7.4.08 14.4.08 21.4.08 28.4.08 5.5.08 12.5.08 19.5.08 26.5.08 2.6.08 364.4 0.0 18.0 18.0 18.0 36.0 53.0 10.0 10.0 10.0 10.0 20.0 2.0 15.0 35.0 -1.0 18.0 54.0 18.0 18.0 71.0 17.0 18.0 72.0 0.0 72.0 71.0 -1.0 71.0 -1.0 0.0 72.0 18.0 18.0 18.0 18.0 90.0 108.0 126.0 144.0 0.0 0.0 0.0 71.0 71.0 71.0 71.0 71.0 -1.0 -19.0 -37.0 -55.0 -73.0 +11 24 +12 25 +13 26 +14 27 +19 36 +20 37 9.6.08 16.6.08 23.6.08 30.6.08 7.7.08 14.7.08 21.7.08 28.7.08 4.8.08 11.8.08 18.8.08 25.8.08 1.9.08 8.9.08 28 Schulferien 29 30 31 +15 32 +16 33 +17 34 +18 35 18.0 18.0 18.0 18.0 18.0 18.0 18.0 0.0 0.0 0.0 0.0 17.2 17.2 17.2 17.2 17.2 8.4 162.0 180.0 198.0 216.0 234.0 252.0 270.0 270.0 270.0 270.0 270.0 287.2 304.4 321.6 338.8 356.0 364.4 71.0 71.0 71.0 71.0 71.0 71.0 71.0 71.0 71.0 71.0 71.0 71.0 71.0 71.0 71.0 71.0 71.0 -91.0 -109.0 -127.0 -145.0 -163.0 -181.0 -199.0 -199.0 -199.0 -199.0 -199.0 -216.2 -233.4 -250.6 -267.8 -285.0 -293.4 22.2. 10.3. 17.3. 20.3. 7.4. 18.4. 18.4. 24.04 24.04 23.5. 19.5. 21.5. 6.6. 15.6. 20.6. 27.6. 4.7. 31.7. 17.8. 2.6. 9.7. 14.7. 8.8. 18.8. 25.8. 29.8. 1.9. 11.9. 6.3.2 Zeitplan Planung Transaktionssimulator 6.4 Erfahrungen 6.4.1 Analyse Phase 1. IEEE 830 sehr nützlich 2. LoFi Prototyp für Graphisch Anwendung notwendig, und im Vergleich zu Programmieren nicht aufwendig. 3. Frühzeitiges Suchen nach bestehenden Lösungen/Komponenten hilft ein Urteil über das Machbare zu erhalten. 6.4.2 Design / Entwicklungsphase 1. Wiederverwendung bestehender Komponenten für ein einziges Projekt kostet u.U. mehr Zeit, als man spart. Einlesen, Ausprobieren, Bugs und unerwünschte Einschränkungen entdecken und korrigieren. Speziell Zeitraubend ist die ungenügende Dokumentation für Problembehebung- und Analyse. 2. Die Standard Swing Layout Managers sind problematisch: - ungenügende Funktionalität - Verhalten in komplexen Kombinationen unvorhersehbar - "early prototyping" nötig für Risiko-Management - bottom-up technisches Design anhand LoFi User Interface Prototyp Die Layout Managers war eine Leidensweg, bis zur Entdeckung des MiGLayout Layout Managers im Internet. 3. Swing Application Framework [5] - zu wenig Dokumentation um schwierige Probleme zu lösen - unerwartetes Verhalten (nicht-funktionieren des Frameworks wie erwartet) - unerwartete Nebenwirkungen (nicht funktionieren normaler JavaFunktionen) Das Framework hat am Anfang sicher einige Zeit gespart. Später hat es aber ein Vielfaches mehr Zeit gekostet. Das Framework wurde in der Folge wo möglich umgangen. Beim besseren Verständnis des Swing EDT, würde ich das Framework, was m.E. nicht ausgereift ist, vollständig durch eigene Patterns ersetzen. 4. Sehr positiv wenn der Experte wirklich einer ist und auch noch Zeit freimacht. 5. Mit einem agilen Ansatz, ein Iterationsplan sowie einer Agenda, kann man seine Zeit sehr gut einteilen, und sogar noch jede Menge Überraschungen zu einem guten Ende führen. 6.4.3 Realisierungsphase 1. Wenn Programmierung nicht die tägliche Arbeit ist, gibt es verschiedene Tätigkeiten die unerwartet viel Zeit kosten: - UML Tool kennen lernen - EDI (Eclipse) kennen lernen - Deployment Optionen kennen lernen - Alles im API nachschlagen müssen Seite 49 von 66 2. Man unbedingt die Anforderungen bereits in einer Form produzieren, welche die spätere Gegenüberstellung des Designs und der Implementierung vereinfacht. Dank des Kurses Requirements Engineering was dies glücklich der Fall. 3. Ürsprünglich war die Integration des GUI mit einer alten Version des Simulators vorgesehen. Die Unterschiede zwischen alten und neuen Simulators stellten sich jedoch als so gross heraus, dass es schade um den Aufwand gewesen wäre, die nötigen Anpassungen zu machen. Es wurde dafür einen inkrementellen Ansatz gewählt, welche in 5.2 "Integrationstests" dargelegt ist. 6.4.4 Grösste Probleme Die grösste Probleme welche während des Projekts aufgetreten sind: 1. Unterschätzung des Spezifikationbedarfs aufgrund nicht vorhergesehene Zusammenhänge zwischen den Anforderungen bzw. Konsequenzen im Zusammenspiel von Anforderungen, z.B. 2. Explodierende Permutationen von an und für sich erwünschten Variationen erhöht die Komplexität exponentiell. 3. Nicht zu Ende gedachte Anforderungen (fachliche Unvollständigkeit), die erst bei Detail-Design auffällt. (-> durch agiles vorgehen aber frühzeitig entdeckt.) 4. Denkfehler, oft durch zu einfache Vorstellung eines Problems (aufgrund ungenügende Erfahrung des Entwicklers mit der Domäne oder der Realisierung) führen zu Fehlern bei der Implementation, die nur mit sehr viel Aufwand zu finden sind. 5. Unterschätzte Konsequenzen für "Erweiterungen" gegenüber bestehendem Programm 6. Schwierigkeit des Debuggen bzw. des Definieren von Tests bei einer MultiThreaded Applikation. 7. Überschätzen der Wiederverwendbarkeit alten Codes bzw. Unterschätzen des Änderungsbedarfs und des Aufwands für Erweiterungen. 8. Testfehler werden zuerst lange in Implementationsfehlern vermutet und gesucht, und erst sehr viel später in der Form von Spezifikations-Fehlern gefunden. 9. Abgrenzung Fachlich / IT schwierig, wenn das Fachliche selbst schon sehr informatiklastig ist. Grund für Unterschätzung der eigenen Aufwände sowohl auf fachlicher wie auf IT Seite. 10. Java Swing ist m.E. unvorstellbar unorthogonal und zwang zu eine lange Phase von Versuch-und-Irrtum. Für Swing-unerfahrene Entwickler ist ein inkrementelles Vorgehen mit sehr vielen Iterationen unabdingbar. 11. GUI Programmierung scheint mir eine sehr spezielle Disziplin. Die angestrebte hierarchische Gliederung sowie die objektorientierte Kapselung von Funktionalität im GUI, wurden von der anarchistischen Art der GUI-Interaktivität völlig in Frage gestellt. Kurzfristig die optimalen Patterns zu finden und zu verstehen ist viel zu aufwändig im Rahmen dieses Auftrags. Die Handbücher [9], [10] und [11] bieten z.B. kein Einziges Beispiel, wie ein Fomular erstellt, mit Daten abgefüllt und die Daten wieder weitergegeben werden können. 12. Das Swing Application Framework ist nicht ausgereift und schlecht dokumentiert. Es ist nicht einsichtlich woher Behauptungen kommen, es würde Teil des nächsten Java Releases sein. Seite 50 von 66 6.4.5 Grösste Aufsteller 1. Das Paket JFreeChart [7] ist sehr brauchbar, sehr gut dokumentiert, und auch für die kommerzielle Verwendung gratis. Die Komponente hat die Erwartungen erfüllt und sehr viel Zeit eingespart. 2. Der LayoutManager MiGLayout [8] tut das, was die vielen Java LayoutManager [9], [10], [11] nicht schaffen: Eine einfache Schnittstelle für praktisch alle LayoutWünsche bereit zu stellen. Leider stand MiGLayout erst spät im Projekt zur Verfügung. Bei einer Grossüberarbeitung empfehlt es sich, das durch die Verwendung der Java LayoutManager unnötig komplex gewordene GUI mit Hilfe von MiGLayout zu sanieren. 3. Es ist seht interessant ein Projekt von A bis Z durchzuführen. Es werden viele neue Kenntnisse aus dem Studium verwendet. Die Erfahrung gibt eine breite Erfahrungsbasis für den Beruf. 6.5 Aufwandschätzung Am Anfang des Projekts wurde eine Aufwandschätzung erstellt, welches das düstere Bild ergab, dass das Projekt nur 600 LOC produzieren würde. Am Schluss gab es 7'000 LOC für 86 Klassen in 7 Packages. Aufwandschätzung Transaktionssimulator Pos 1 2 3 4 5 6 7 8 9 10 11 12 Version 0.1 2007-03-08 / P. Klarenberg Total Projekt Budget 360.00 100% Total - eingeplant 451.80 126% Total - unverplant -91.80 Aktivität Total / Pos Aufwand Anzahl Details Meeting Experte 12.00 3% 4.00 3 1 Std. Präsenz + 1 Std. Reise + 2 Std. Vor/Nachbereitung Meeting Begleiter 45.00 13% 4.50 10 1.5 Std. Präsenz + 1 Std. Reise + 2 Std. Vorbereitung Statusbericht 5.00 1% 0.50 10 Unter 30 Min. geht nichts Präsentationskurs 8.40 2% 8.40 1 Präsentation 8.40 2% 8.40 1 Pflichtenheft 45.00 13% 45.00 1 Use Cases, Storyboard, NFR (IEEE 830 Doku) Design 40.00 11% 40.00 1 Architektur, Schnittstellen, Patterns, UML ... Implementation 40.00 11% 40.00 1 Reines codieren (15 LOC/Std.) => 600 LOC Tests 40.00 11% 40.00 1 Testcases, Testcode, testen Overhead 80.00 22% 80.00 1 Swing, JDBC, DB-Prod/SQL-Dial, Tools (JUnit, ... Diplombericht 20.00 6% 20.00 1 Copy/Paste bestehender Doku? Unvorhergesehenes 108.00 30% 108.00 1 30% des Budgets Der "Trick" ist offensichtlich gewesen, bei jede Aktivität darauf zu achten, dass daraus mehr laufender Code entsteht. Aus Design, Test und Overhead, wofür 4 mal mehr Zeit als für die Implementation vorgesehen war, trugen mittels inkrementelles Vorgehen an die Code-Produktion bei. Samt dem Posten Unvorhergesehenes standen somit statt der ursprünglichen 40 deren 308 Stunden als produktive Zeit zur Verfügung was rechnerisch in etwa 4'600 ergeben müsste. Wenn wir davon ausgehen, dass der produzierte Code nicht Produktionsqualität hat, würde dies mit den aktuellen 7'000 (inkl. Kommentare) ziemlich gut übereinstimmen. 6.6 Ausblick Der Transaktionssimulator wird künftig im Unterricht für das Fach Datenbanken ausprobiert. Hieraus werden neue Anforderungen sowie Feedbacks über Bugs gewonnen werden. Seite 51 von 66 Anhang A. UML Diagramme Alle public Attribute sind als Properties zu betrachten, welche mit entsprechenden Getters und Setters implementiert werden. Ebenfalls mit Getters/Setters werden die Assoziationen implementiert. Anhang A1. Package net.clearmountain.transim class transim ApplicationGlobals + getInstance() : ApplicationGlobals «interface» DataTierFactory TranSim + 1 Stac kedP anel name: String +dataT ierFactory 1 1 stackedPanel 2 Simulatio nContext «interface» Simulator 1 1 simulationContext «interface» +simulationStatistics SimulationStatistics + + + concurrentThreads: int simulationT ime: double windowLength: double + propertyChange(PropertyChangeEvent) : void 1 1 1 1 +currentShow 1 ArrayList<SimulationModel> Task Show StatisticsTra nsferProcess + + # # 1 +simulationModel start() : void stop() : void doInBackgrou nd() : void process(display Values) : void +simulationModel 0..* 1 ArrayList<UserModel> Simul ation Model 1 Seite 52 von 66 Anhang A2. Package net.clearmountain.transim.gui class gui «interface» SimulationVisualizer MyMenubar 1 1 DefaultSimulationVisualizer 1 +simulationPanel 1 +leftStackedPanel Simul ationPanel Stac kedP anel ControlP anel 1 1 +rightStackedPanel 1 1 1 1 Param eterP anel +resultsPerUserModelPanel StackedBox 1 1 BarChartP anel 1 +resultsPerTransactionModelPanel 1 1 1 1 1 TotalResultsPanel Das UML-Diagram zeigt nur die wichtigsten Klassen. Damit die verschiedenen Layoutmanager das gewünscht Layout erzeugen, müssen viele Panels oder andere Container-Objekte "zwischengeschaltet" werden. Die effektive Objektstruktur ist zu komplex und umfangreich für ein A-4-formatiges UML-Diagramm. Die nachfolgende Liste zeigt eine programmatisch generierte Objektstruktur, welche mit Version 1.0 des Transaktionssimulators übereinstimmt. Es wird auf jeder Zeile den Klassenname, den Objektname ("null" wenn keinen vorhanden) plus mittels Minuszeichen den Level im Objektbaum angezeigt. javax.swing.JFrame "mainFrame" -javax.swing.JRootPane "null" --javax.swing.JPanel "null.glassPane" --javax.swing.JLayeredPane "null.layeredPane" ---javax.swing.JPanel "null.contentPane" ----javax.swing.JPanel "mainPanel" -----javax.swing.JScrollPane "scrollPane" ------javax.swing.JViewport "null" -------net.clearmountain.transim.gui.SimulationPanel "simulationPanel" --------net.clearmountain.transim.gui.StackedPanel "leftBox" ---------net.clearmountain.transim.gui.ControlPanel "controlPanel" ----------javax.swing.Box "controlPanel2" Seite 53 von 66 -----------javax.swing.JComboBox "combo" ------------javax.swing.plaf.basic.BasicArrowButton "ComboBox.arrowButton" ------------javax.swing.CellRendererPane "null" -----------javax.swing.JToolBar "controls" ------------javax.swing.JButton "playButton" ------------javax.swing.JButton "pauseButton" ------------javax.swing.JButton "stopButton" ------------javax.swing.JButton "clearButton" -----------javax.swing.Box$Filler "null" ----------javax.swing.Box "null" -----------javax.swing.JPanel "null" ------------javax.swing.JTextArea "null" ----------net.clearmountain.transim.gui.LegendPanel "null" -----------javax.swing.Box "null" ------------javax.swing.JLabel "transactionsLabel" ------------javax.swing.JLabel "deadlocksLabel" ------------javax.swing.JLabel "lostUpdatesLabel" ------------javax.swing.JLabel "phantomsLabel" ------------javax.swing.JLabel "transactionTimeLabel" ------------javax.swing.JLabel "deadlockTimeLabel" ---------net.clearmountain.transim.gui.StackedBox "stackedBox" ----------org.jdesktop.swingx.JXHyperlink "null" ----------org.jdesktop.swingx.JXCollapsiblePane "null" -----------org.jdesktop.swingx.JXCollapsiblePane$WrapperContainer "null" ------------javax.swing.JPanel "null" -------------net.clearmountain.transim.gui.TotalResultsPanel "null" --------------org.jfree.chart.ChartPanel "null" --------------org.jfree.chart.ChartPanel "null" --------------javax.swing.Box$Filler "null" ----------org.jdesktop.swingx.JXHyperlink "null" ----------org.jdesktop.swingx.JXCollapsiblePane "null" -----------org.jdesktop.swingx.JXCollapsiblePane$WrapperContainer "null" ------------javax.swing.JPanel "null" -------------net.clearmountain.transim.gui.ResultsPerUserModelPanel "null" --------------org.jfree.chart.ChartPanel "null" ----------org.jdesktop.swingx.JXHyperlink "null" ----------org.jdesktop.swingx.JXCollapsiblePane "null" -----------org.jdesktop.swingx.JXCollapsiblePane$WrapperContainer "null" ------------javax.swing.JPanel "null" -------------net.clearmountain.transim.gui.ResultsPerTransactionModelPanel "null" --------------org.jfree.chart.ChartPanel "null" ----------org.jdesktop.swingx.JXHyperlink "null" ----------org.jdesktop.swingx.JXCollapsiblePane "null" -----------org.jdesktop.swingx.JXCollapsiblePane$WrapperContainer "null" ------------javax.swing.JPanel "null" -------------net.clearmountain.transim.gui.ParameterPanel "null" --------------javax.swing.table.JTableHeader "null" ---------------javax.swing.CellRendererPane "null" --------------net.clearmountain.transim.gui.ParameterPanel$1 "null" ---------------javax.swing.CellRendererPane "null" --------------javax.swing.JPanel "null" ---------------javax.swing.Box "null" ----------------javax.swing.Box$Filler "null" ----------------javax.swing.JButton "null" ----------------javax.swing.Box$Filler "null" --------javax.swing.Box "null" --------net.clearmountain.transim.gui.StackedPanel "rightBox" ---------net.clearmountain.transim.gui.ControlPanel "controlPanel" ----------javax.swing.Box "controlPanel2" -----------javax.swing.JComboBox "combo" ------------javax.swing.plaf.basic.BasicArrowButton "ComboBox.arrowButton" ------------javax.swing.CellRendererPane "null" -----------javax.swing.JToolBar "controls" ------------javax.swing.JButton "playButton" ------------javax.swing.JButton "pauseButton" ------------javax.swing.JButton "stopButton" ------------javax.swing.JButton "clearButton" -----------javax.swing.Box$Filler "null" ----------javax.swing.Box "null" -----------javax.swing.JPanel "null" ------------javax.swing.JTextArea "null" ----------net.clearmountain.transim.gui.LegendPanel "null" -----------javax.swing.Box "null" ------------javax.swing.JLabel "transactionsLabel" ------------javax.swing.JLabel "deadlocksLabel" Seite 54 von 66 ------------javax.swing.JLabel "lostUpdatesLabel" ------------javax.swing.JLabel "phantomsLabel" ------------javax.swing.JLabel "transactionTimeLabel" ------------javax.swing.JLabel "deadlockTimeLabel" ---------net.clearmountain.transim.gui.StackedBox "stackedBox" ----------org.jdesktop.swingx.JXHyperlink "null" ----------org.jdesktop.swingx.JXCollapsiblePane "null" -----------org.jdesktop.swingx.JXCollapsiblePane$WrapperContainer "null" ------------javax.swing.JPanel "null" -------------net.clearmountain.transim.gui.TotalResultsPanel "null" --------------org.jfree.chart.ChartPanel "null" --------------org.jfree.chart.ChartPanel "null" --------------javax.swing.Box$Filler "null" ----------org.jdesktop.swingx.JXHyperlink "null" ----------org.jdesktop.swingx.JXCollapsiblePane "null" -----------org.jdesktop.swingx.JXCollapsiblePane$WrapperContainer "null" ------------javax.swing.JPanel "null" -------------net.clearmountain.transim.gui.ResultsPerUserModelPanel "null" --------------org.jfree.chart.ChartPanel "null" ----------org.jdesktop.swingx.JXHyperlink "null" ----------org.jdesktop.swingx.JXCollapsiblePane "null" -----------org.jdesktop.swingx.JXCollapsiblePane$WrapperContainer "null" ------------javax.swing.JPanel "null" -------------net.clearmountain.transim.gui.ResultsPerTransactionModelPanel "null" --------------org.jfree.chart.ChartPanel "null" ----------org.jdesktop.swingx.JXHyperlink "null" ----------org.jdesktop.swingx.JXCollapsiblePane "null" -----------org.jdesktop.swingx.JXCollapsiblePane$WrapperContainer "null" ------------javax.swing.JPanel "null" -------------net.clearmountain.transim.gui.ParameterPanel "null" --------------javax.swing.table.JTableHeader "null" ---------------javax.swing.CellRendererPane "null" --------------net.clearmountain.transim.gui.ParameterPanel$1 "null" ---------------javax.swing.CellRendererPane "null" --------------javax.swing.JPanel "null" ---------------javax.swing.Box "null" ----------------javax.swing.Box$Filler "null" ----------------javax.swing.JButton "null" ----------------javax.swing.Box$Filler "null" ------javax.swing.JScrollPane$ScrollBar "null" -------com.sun.java.swing.plaf.windows.WindowsScrollBarUI$WindowsArrowButton "null" -------com.sun.java.swing.plaf.windows.WindowsScrollBarUI$WindowsArrowButton "null" ------javax.swing.JScrollPane$ScrollBar "null" -------com.sun.java.swing.plaf.windows.WindowsScrollBarUI$WindowsArrowButton "null" -------com.sun.java.swing.plaf.windows.WindowsScrollBarUI$WindowsArrowButton "null" -----javax.swing.JLabel "statusBar" ---net.clearmountain.transim.gui.MyMenuBar "myMenuBar" ----javax.swing.JMenu "fileMenu" ----javax.swing.JMenu "settingsMenu" ----javax.swing.JMenu "helpMenu" Seite 55 von 66 Anhang A3. Package net.clearmountain.transim.simulator class simulator transim:: Simulatio nContext 1 simulationContext 1 + «interface» Simulator concurrentThreads: int + + + + + start() : void stop() : void pause() : void resume() : void reset() : void +simulationModel 1 ArrayList<UserModel> +simulationModel mode l:: Simul ationModel 1 1 DefaultS imulator + concurrentThreads: int + + + + + start() : void stop() : void pause() : void resume() : void reset() : void +simulation 1 0..* «interface» database::DataTier +dataTier 1 0..* ArrayList<TransactionModel> Simulati onThread +userModel + + run() : void stop() : void 0..* model::User Model 1 Seite 56 von 66 Anhang A4. Package net.clearmountain.transim.model class model Show Par ameters + + + + ArrayList<SimulationModel> + + Show + name: String +showParameters + + deepClone() : Show 1 + getSimulationModelByName(String) : SimulationModel + + + 0..* + 1 +showTemplates + 0..* resultsTotalInNumberPerSecond: int resultsTotalInMilliseconds: int resultsPerUserModelInNumberPerSecond: int resultsPerTransactionModelInNumberPerSecond: int numberOfUserModelGraphPositions: int numberOfTransactionModelGraphPositions: int concurrentThreadsInNumber: int refreshRateInNumberPerSecond: int simulationT imeInSeconds: double windowLengthInSeconds: double numberOfRecords: int defaultAccountP rofile: String clone() : ShowParameters ArrayList<UserModel> Simul ationModel + + - id: S tring name: String quantities: Integer (HashMap) + + + + + + + + + + setQuantity(String, int) : void getQuantity(String) : int getTransactionModelquantity(String) : int getTransactionModel(String) : TransactionModel deepClone() : S imulationModel getNumberOfUserModels() : int getNumberOfTransact ionModels() : void getUserModelNam es() : String[] getTransactionModel Names() : String[] setTransactionModelParameters(String, int, int, int, int, int, int, int) : void 1 0..* 0..* simulationModelTemplates ArrayList<TransactionModel> Use rModel + + + - id: int name: String interTransactionDelay: int quantities: Integer (HashMap) + + + setQuantity(String, int) : void getQuantity(String) : int deepClone() : UserModel 0..* ModelFactory + + + + + + + + + + + loadModel(File) : void getShowByNumber(int) : Show getShowByName(String) : Show getNumberOfShows() : int getShowNames() : String[] getSimulationModelNam es(String) : String[] getTransactionModel Names() : String[] getTransactionModelByName(String) : TransactionModel createShow(String) : Show addModelChangeListener(Mo delChangeListener) : void removeModelChangeListener(M odelChangeListener) : void +userModelTemplates parameterSetTemplates 1 0..* ArrayList<Operation> TransactionModel + + + + + + + + + name: String isolationLevel: int pattern: String[] readPercentage: int updatePercentage: int insertAmount: int deletePercentage: int operationDelay: int commitDelay: int + deepClone() : T ransactionModel 0..* Parame terSet +transactionModelTemplates 0..* + + + + + + + + id: int pattern: String readPercent: int updatePercent: int insertAmount: int deletePercent: int operationDelay: int commitDelay: int 1 0..* «enumeration» Opera tion «enum» RE AD UPDATE INS ERT DEL ET E BEGIN_TRA NSACT ION COMMIT_TRANSACTION Alle public Attribute sind als Properties zu betrachten, welche mit entspechenden Getters und Setters implementiert werden. Ebenfalls mit Getters/Setters werden die Assoziationen implementiert. Seite 57 von 66 Anhang A5. Package net.clearmountain.transim.database class database transim:: SimulationContext 1 1 «interface» DataTierFactory + accountProfile Name: String + numberOfRecords: int +/ numberOfLostUpdates: int + + + + + «interface» DataTier getAccountsProfileNames()() : String[] setSelectedAccountProfileName(String) : void initDatabase() : void resetDatabase() : void connectionTestOK() : boolean «use» + + + + + + + + JDBCDataTierFactory JDBCDa taTier + accountProfile Name: String + numberOfRecords: int +/ numberOfLostUpdates: int + + + + + read(int) : void update(int) : void insert(int) : void delete(int) : void beginTransaction(int) : void commitTransaction(int) : void getTransactionStatistics() : TransactionStatistics close() : void getAccountsProfileNames()() : String[] setSelectedAccountProfileName(String) : void initDatabase() : void resetDataba se() : void connectionTest OK() : boolean «use» + + + + + + + + read(int ) : void update(in t) : void insert(in t) : void delete(in t) : void beginTransacti on(int) : void commitTransacti on(int) : void getTransactionStatistics() : TransactionStatistics close() : void «interface» beans::PropertyChangeListener «use» «use» AccountProfile Database Profile «use» «use» AccountProfileParser DatabaseProfileParser Seite 58 von 66 Anhang A6. Package net.clearmountain.transim.statistics pkg statistics transim:: SimulationContext ArrayList<UserModel> +simulationModel mode l:: Simul ationModel 1 +simulationModel 1 1 «interface» SimulationStatistics + + + + + + + reset() : void start() : void stop() : void pause() : void resume() : void processTransactionStatistics() : void getSnapshot() : DisplayValues +simulationStatistics 1 SlidingAv erageSim ulationStatistics + + + + + + + TransactionStatistics reset() : void start() : void stop() : void pause() : void resume() : void processTransactionStatistics(TransactionStatistics) : void getSnapshot() : DisplayValues «use» + + + + + + numberOfDeadlocks: int numberOfLostUpdates: int numberOfPhantoms: int durationOfDeadlocks: int durationOfTransactions: int timeOut: Boolean «use» DisplayValues ModelSta tistics +TransactionModelStatistics 0..* + + + 0..* + + +totalModelStatistics + + 1 +userModelStatistics + name: String numberOfTransactions: int durationOfTransactions: int numberOfDeadlocks: int durationOfDeadlocks: int numberOfLostUpdates: int numberOfPhantoms: int copy() : ModelStatistics Seite 59 von 66 Anhang B XML-Schemas Anhang B1. Schema model.xsd <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="transactionSimulator" type="transactionSimulatorType"> <xs:key name="simulationModelId"> <xs:selector xpath="simulationModels/simulationModel | simulationModels/simpleSimulationModel"/> <xs:field xpath="@id"/> </xs:key> <xs:keyref refer="simulationModelId" name="simulationModelRef"> <xs:selector xpath="shows/show/simulationModelRef"/> <xs:field xpath="@ref"/> </xs:keyref> <xs:key name="userModelId"> <xs:selector xpath="userModels/userModel"/> <xs:field xpath="@id"/> </xs:key> <xs:keyref refer="userModelId" name="userModelIdRef"> <xs:selector xpath="simulationModels/simulationModel/userModelRef"/> <xs:field xpath="@ref"/> </xs:keyref> <xs:key name="transactionModelId"> <xs:selector xpath="transactionModels/transactionModel"/> <xs:field xpath="@id"/> </xs:key> <xs:keyref refer="transactionModelId" name="transactionModelRef"> <xs:selector xpath="simulationModels/simpleSimulationModel/transactionModelRef | userModels/userModel/transactionModelRef"/> <xs:field xpath="@ref"/> </xs:keyref> <xs:key name="parameterSetId"> <xs:selector xpath="parameterSets/parameterSet"/> <xs:field xpath="@id"/> </xs:key> <xs:keyref refer="parameterSetId" name="parameterSetRef"> <xs:selector xpath="transactionModels/transactionModel/parameterSetRef"/> <xs:field xpath="@ref"/> </xs:keyref> </xs:element> <xs:complexType name="transactionSimulatorType"> <xs:sequence> <xs:element name="parameterSets" type="parameterSetsType" minOccurs="0" maxOccurs="1"/> <xs:element name="transactionModels" type="transactionModelsType" minOccurs="1" maxOccurs="1"/> <xs:element name="userModels" type="userModelsType" minOccurs="0" maxOccurs="1"/> <xs:element name="simulationModels" type="simulationModelsType" minOccurs="1" maxOccurs="1"/> <xs:element name="shows" type="showsType" minOccurs="1" maxOccurs="1"/> </xs:sequence> </xs:complexType> Seite 60 von 66 <xs:complexType name="showsType"> <xs:sequence> <xs:element name="show" type="showType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:complexType name="simulationModelsType"> <xs:sequence> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element name="simulationModel" type="simulationModelType"/> <xs:element name="simpleSimulationModel" type="simpleSimulationModelType"/> </xs:choice> </xs:sequence> </xs:complexType> <xs:complexType name="userModelsType"> <xs:sequence> <xs:element name="userModel" type="userModelType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:complexType name="transactionModelsType"> <xs:sequence> <xs:element name="transactionModel" type="transactionModelType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:complexType name="parameterSetsType"> <xs:sequence> <xs:element name="parameterSet" type="parameterSetType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:complexType name="showType"> <xs:sequence> <xs:element name="name" type="nameType" minOccurs="1" maxOccurs="1"/> <xs:element name="simulationModelRef" type="refType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="showParameters" type="showParametersType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:complexType name="simulationModelType"> <xs:sequence> <xs:element name="name" type="nameType" minOccurs="1" maxOccurs="1"/> <xs:element name="userModelRef" type="qtyRefType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="id" type="idType" use="required"/> </xs:complexType> <xs:complexType name="simpleSimulationModelType"> <xs:sequence> <xs:element name="name" type="nameType" minOccurs="1" maxOccurs="1"/> Seite 61 von 66 <xs:element name="transactionModelRef" type="qtyRefType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="id" type="idType" use="required"/> </xs:complexType> <xs:complexType name="userModelType"> <xs:sequence> <xs:element name="name" type="nameType" minOccurs="1" maxOccurs="1"/> <xs:element name="interTransactionDelay" type="xs:nonNegativeInteger" minOccurs="1" maxOccurs="1"/> <xs:element name="transactionModelRef" type="qtyRefType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="id" type="idType" use="required"/> </xs:complexType> <xs:complexType name="transactionModelType"> <xs:sequence> <xs:element name="name" type="nameType" minOccurs="1" maxOccurs="1"/> <xs:element name="isolationLevel" type="isolationLevelType" minOccurs="1" maxOccurs="1"/> <xs:choice> <xs:element name="parameterSetRef" type="refType" minOccurs="1" maxOccurs="1"/> <xs:sequence> <xs:element name="pattern" type="patternType" minOccurs="1" maxOccurs="1"/> <xs:element name="readPercent" type="percentType" minOccurs="0" maxOccurs="1"/> <xs:element name="updatePercent" type="percentType" minOccurs="0" maxOccurs="1"/> <xs:element name="insertAmount" type="xs:nonNegativeInteger" minOccurs="0" maxOccurs="1"/> <xs:element name="deletePercent" type="percentType" minOccurs="0" maxOccurs="1"/> <xs:element name="operationDelay" type="xs:nonNegativeInteger" minOccurs="1" maxOccurs="1"/> <xs:element name="commitDelay" type="xs:integer" minOccurs="1" maxOccurs="1"/> </xs:sequence> </xs:choice> </xs:sequence> <xs:attribute name="id" type="idType" use="required"/> </xs:complexType> <xs:complexType name="parameterSetType"> <xs:sequence> <xs:element name="pattern" type="patternType" minOccurs="1" maxOccurs="1"/> <xs:element name="readPercent" type="percentType" minOccurs="0" maxOccurs="1"/> <xs:element name="updatePercent" type="percentType" minOccurs="0" maxOccurs="1"/> <xs:element name="insertAmount" type="xs:nonNegativeInteger" minOccurs="0" maxOccurs="1"/> <xs:element name="deletePercent" type="percentType" minOccurs="0" maxOccurs="1"/> <xs:element name="operationDelay" type="xs:nonNegativeInteger" minOccurs="1" maxOccurs="1"/> Seite 62 von 66 <xs:element name="commitDelay" type="xs:integer" minOccurs="1" maxOccurs="1"/> </xs:sequence> <xs:attribute name="id" type="idType" use="required"/> </xs:complexType> <xs:complexType name="showParametersType"> <xs:sequence> <xs:element name="scalesParameters" type="scalesParametersType" minOccurs="0" maxOccurs="1"/> <xs:element name="simulatorParameters" type="simulatorParametersType" minOccurs="0" maxOccurs="1"/> <xs:element name="databaseParameters" type="databaseParametersType" minOccurs="0" maxOccurs="1"/> </xs:sequence> </xs:complexType> <xs:complexType name="simulationModelParametersType"> <xs:sequence> <xs:element name="simulatorParameters" type="simulatorParametersType" minOccurs="0" maxOccurs="1"/> <xs:element name="databaseParameters" type="databaseParametersType" minOccurs="0" maxOccurs="1"/> </xs:sequence> </xs:complexType> <xs:complexType name="scalesParametersType"> <xs:sequence> <xs:element name="resultsTotalInNumberPerSecond" type="xs:positiveInteger" minOccurs="0" maxOccurs="1"/> <xs:element name="resultsTotalInMilliseconds" type="xs:positiveInteger" minOccurs="0" maxOccurs="1"/> <xs:element name="resultsPerUserModelInNumberPerSecond" type="xs:positiveInteger" minOccurs="0" maxOccurs="1"/> <xs:element name="resultsPerTransactionModelInNumberPerSecond" type="xs:positiveInteger" minOccurs="0" maxOccurs="1"/> <xs:element name="numberOfUserModelGraphPositions" type="xs:positiveInteger" minOccurs="0" maxOccurs="1"/> <xs:element name="numberOfTransactionModelGraphPositions" type="xs:positiveInteger" minOccurs="0" maxOccurs="1"/> </xs:sequence> </xs:complexType> <xs:complexType name="simulatorParametersType"> <xs:sequence> <xs:element name="concurrentThreadsInNumber" type="concurrentThreadsType" minOccurs="0" maxOccurs="1"/> <xs:element name="refreshRateInNumberPerSecond" type="xs:nonNegativeInteger" minOccurs="0" maxOccurs="1"/> <xs:element name="simulationTimeInSeconds" type="xs:nonNegativeInteger" minOccurs="0" maxOccurs="1"/> <xs:element name="windowLengthInSeconds" type="xs:nonNegativeInteger" minOccurs="0" maxOccurs="1"/> Seite 63 von 66 </xs:sequence> </xs:complexType> <xs:complexType name="databaseParametersType"> <xs:sequence> <xs:element name="numberOfRecords" type="xs:nonNegativeInteger" minOccurs="0" maxOccurs="1"/> <xs:element name="defaultAccountProfile" type="xs:string" minOccurs="0" maxOccurs="1"/> </xs:sequence> </xs:complexType> <xs:simpleType name="nameType"> <xs:restriction base="xs:string"> <!--<xs:pattern value="[A-Za-z_]+[A-Za-z_0-9 \-]*"/>--> <xs:pattern value="[A-Za-z_0-9 \-\.]+"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="idType"> <xs:restriction base="xs:string"> <xs:pattern value="[A-Za-z_]+[A-Za-z_0-9 \-]*"/> </xs:restriction> </xs:simpleType> <xs:complexType name="refType"> <xs:attribute name="ref" type="idType"/> </xs:complexType> <xs:complexType name="qtyRefType"> <xs:attribute name="ref" type="idType" use="required"/> <xs:attribute name="qty" type="xs:nonNegativeInteger"/> </xs:complexType> <xs:simpleType name="isolationLevelType"> <xs:restriction base="xs:byte"> <xs:minInclusive value="0"/> <xs:maxInclusive value="3"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="patternType"> <xs:restriction base="xs:string"> <xs:pattern value="(R|RU|RD|I)+"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="percentType"> <xs:restriction base="xs:byte"> <xs:minExclusive value="0"/> <xs:maxInclusive value="100"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="concurrentThreadsType"> <xs:restriction base="xs:positiveInteger"> <xs:minInclusive value="1"/> <xs:maxInclusive value="100"/> </xs:restriction> </xs:simpleType> </xs:schema> Seite 64 von 66 B2. Schema accounts.xsd <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="accounts" type="accountsType"> <xs:key name="accountName"> <xs:selector xpath="accounts/account"/> <xs:field xpath="@name"/> </xs:key> </xs:element> <xs:complexType name="accountsType"> <xs:sequence> <xs:element name="account" type="accountType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:complexType name="accountType"> <xs:sequence> <xs:element name="databaseRef" type="databaseRefType" minOccurs="1" maxOccurs="1"/> <xs:element name="userName" type="xs:string" minOccurs="1" maxOccurs="1"/> <xs:element name="password" type="xs:string" minOccurs="1" maxOccurs="1"/> <xs:element name="connectionURL" type="xs:string" minOccurs="1" maxOccurs="1"/> </xs:sequence> <xs:attribute name="name" type="xs:string" use="required"/> <xs:attribute name="default" type="xs:string" use="optional"/> </xs:complexType> <xs:complexType name="databaseRefType"> <xs:attribute name="ref" type="xs:string" use="required"/> </xs:complexType> </xs:schema> Seite 65 von 66 B3. Schema databases.xsd <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="databases" type="databasesType"> <xs:key name="databaseName"> <xs:selector xpath="databases/database"/> <xs:field xpath="@name"/> </xs:key> </xs:element> <xs:complexType name="databasesType"> <xs:sequence> <xs:element name="database" type="databaseType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:complexType name="databaseType"> <xs:sequence> <xs:element name="createTrxTable" type="xs:string" minOccurs="0" maxOccurs="1"/> <xs:element name="createTrxIndex" type="xs:string" minOccurs="0" maxOccurs="1"/> <xs:element name="perConnectionStatementOptions" type="statementOptionType" minOccurs="0" maxOccurs="1"/> <xs:element name="driverClass" type="xs:string" minOccurs="1" maxOccurs="1"/> </xs:sequence> <xs:attribute name="name" type="xs:string" use="required"/> </xs:complexType> <xs:complexType name="statementOptionType"> <xs:sequence> <xs:element name="option" type="xs:string" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:schema> Seite 66 von 66
