SQuirreL DB Refactoring

Transkript

1 SQuirreL DB Refactoring Datenbank-Refactoring und PostgreSQL-Funktionen im SQuirreL SQL Client Autoren: Betreuer: Studienarbeit Herbstsemester 2007 Daniel Regli Yannick Winiger Prof. Stefan Keller HSR Hochschule für Technik Rapperswil Oberseestrasse 10 Postfach 1475 CH-8640 Rapperswil 1 / 96

2 1 Abstract Abteilung Informatik Name der Studenten Daniel Regli, Yannick Winiger Semester HS 07/08 Titel der Studienarbeit SQuirreL DB Refactoring Examinator Prof. Stefan Keller Ziel der Arbeit Datenbank-Refactoring und deren Applikationen zur Durchführung stehen noch im Anfangsstadium. Wir haben uns zum Ziel gesetzt eine der ersten grafischen Refactoring Applikationen zu implementieren. Dies in Form von Plugins zum SQuirreL SQL Client (Open Source Java OR-Datenbank Mapper). Mit dieser Studienarbeit sollen zwei SQuirreL Plugins für PostgreSQL erweitert werden, welche grundlegendes Datenbank-Refactoring und PostgreSQL-spezifische Funktionen mit einer grafischen und gut verständlichen Benutzeroberfläche anbieten. Ergebnisse Mit der Studienarbeit SQuirreL DB Refactoring sind zwei Plugins mit erweiterter Funktionalität für PostgreSQL entstanden. Es wurden die beiden bestehenden Plugins postgres und refactoring des SQuirreL SQL Clients mit weiteren Refactorings und Funktionen ausgestattet. Es wurden die wichtigsten Struktur-, Datenqualitäts-, Architektur und Referenzielle Integrität Refactorings umgesetzt. Nachfolgend einige Beispiele: Struktur-Refactorings o Datenbankobjekte hinzufügen, ändern, löschen, verbinden Datenqualitäts-Refactorings o Lookup Table generieren Architektur-Refactorings o Index hinzufügen, löschen Referenzielle Integrität Refactorings o Fremdschlüssel Constraint hinzufügen, löschen PostgreSQL-spezifische Funktionalität o vacuum Tabelle Die Umsetzung des Refactorings wurde über grafische Dialoge realisiert, welche zur Konfiguration der einzelnen Refactorings dienen. Der Benutzer muss demnach keine SQL-Statements mehr komplett selber erstellen, was die Manipulation von Datenbanken erheblich erleichtert. Ausblick Der Anfang für eine erfolgreiche Datenbank-Refactoring Applikation wurde gemacht, jedoch könnten beide Plugins mit zusätzlichen Refactorings erweitert werden. In einem ersten Schritt würde es Sinn machen, die Unterstützung der neuen Refactorings auf weitere Datenbanken zu erweitern. Die Schnittstellen, sowie deren Benutzeroberflächen wurden von uns bereits erstellt und können verwendet werden. Nur gerade die Generierung der SQL- Statements müsste noch Datenbank-Dialekt-spezifisch implementiert werden. Bei Refactorings würde sich zudem eine Daten-Vorschau-Funktion lohnen, da sie dem Benutzer zeigen könnte, was bei der Ausführung des Refactorings wirklich auf der Datenbank ändern würde. 2 / 96

3 2 Management Summary 2.1 Ausgangslage Motivation Refactoring allgemein stösst immer mehr auf Interesse. Es wird dank den vielen Refactoring Applikationen stark vereinfacht und ist für jedermann zugänglich. Zum jetzigen Zeitpunkt findet man leider nur grafische Applikationen für Programmcode Refactoring und zum Leid jedes Datenbankadministrators keine für Datenbank-Refactoring. Dies obwohl auch Änderungen am Datenschema zur täglichen Arbeit eines Datenbankadministrators gehören Ziele Es besteht eine Open Source Java Applikation namens SQuirreL SQL Client, welche es erlaubt, die Struktur einer JDBC-fähigen Datenbank darzustellen, deren Daten zu bearbeiten und SQL-Statements auszuführen. Für diese Applikation gibt es zwei bestehende Plugins, welche ein paar wenige Datenbank-Refactoring, sowie PostgreSQL-spezifische Funktionalitäten anbieten. Unser Ziel war die beiden Plugins mit weiteren und komplexeren Refactorings und Funktionen auszubauen. Der Nutzen für den Anwender wäre von starker Bedeutung, er müsste sich über die Generierung der SQL-Statements keine Gedanken machen und könnte sich mehr auf seine Aufgaben konzentrieren. 2.2 Vorgehen Das Vorgehen lief nach dem klassischen RUP-Vorgehensmodell ab. Wobei erwähnt werden muss, dass nach Absprache mit Prof. Stefan Keller das Hauptaugenmerk auf die Funktionalitäten der Plugins und nicht auf Dokumentation gesetzt wurde, womit wir auch ein pragmatisches Vorgehen verfolgten Phasenplanung In der Tabelle 1 ist eine Auflistung der einzeln durchlaufenen Phasen, sowie deren kurzen Beschreibung was während jeder Phase erledigt wurde. Phase Inception Elaboration, 1.Iteration Elaboration, 2.Iteration Construction Transition Tabelle 1: Phasenbeschreibung Beschreibung Projektbeginn, Setup und Umgebung kennenlernen. Einblicke in das Framework des SQuirreL SQL Client bekommen. Anforderungen aufnehmen um Projektplanung durchzuführen. Anforderungen mittels der Beschreibung von Use Cases vertiefen. Design der Prototyparchitektur erstellen. Implementation der Prototypen anhand des erstellten Designs. Implementation der ersten Funktionen/Refactorings. Implementation aller Funktionen in beiden Plugins. Tests erstellen um die Funktionen zu prüfen. Tests durchlaufen und Use Case Tests erstellen. Dokumentationen fertigstellen. Abschluss des Projektes, sowie die Integration in die Open Source Community Arbeitsaufteilung Die Entwicklung der beiden Plugins wurde im ersten Schritt so aufgeteilt, dass jedes Teammitglied mit einem Plugin begann. Somit wurde garantiert, dass beide Teammitglieder einen Einblick in das ganze Spektrum der Plugin-Entwicklung bekamen. Yannick Winiger hatte anfangs am postgres Plugin 3 / 96

4 gearbeitet und ist in einem späteren Zeitpunkt Daniel Regli beim refactoring Plugin zur Hilfe gekommen. (Da an das postgres Plugin weniger funktionale Anforderungen gestellt wurden.) Involvierte Personen Zum Projektteam stand zusätzlich während der ganzen Projektzeit Prof. Stefan Keller als Coach und Betreuer zur Verfügung. Wir teilten ihm jeweils wöchentlich den Stand der Dinge, sowie allfällige Probleme mit. 2.3 Ergebnisse Mit der Studienarbeit SQuirreL DB Refactoring sind zwei Plugins mit erweiterter Funktionalität für PostgreSQL entstanden. Es wurden die beiden bestehenden Plugins postgres und refactoring des SQuirreL SQL Clients mit weiteren Refactorings ausgestattet. Es wurden die wichtigsten Struktur-, Datenqualitäts-, Architektur-, Referenzielle Integrität Refactorings umgesetzt. Um einige Beispiele zu nennen: Struktur-Refactorings o Datenbankobjekte hinzufügen, ändern, löschen, verbinden Datenqualitäts-Refactorings o Lookup Table generieren Architektur-Refactorings o Index hinzufügen, löschen Referenzielle Integrität Refactorings o Fremdschlüssel Constraint hinzufügen, löschen PostgreSQL spezifisch o vacuum Tabelle Die Umsetzung der Refactorings wurde über grafische Dialoge realisiert, welche zur Konfiguration der einzelnen Refactorings dienen. Der Benutzer muss demnach keine SQL-Statements mehr komplett selber erstellen, was die Manipulation von Datenbanken erheblich erleichtert. Abbildung 1 zeigt den Ablauf eines Refactorings. SQuirreL SQL starten DB-Objekt auswählen Dialog bearbeiten Aktion wählen Verbindung zur DB herstellen und Refactoring wählen Einstellungen tätigen SQL ausführen SQL editieren SQL anzeigen Abbildung 1: Durchführen eines Refactorings 4 / 96

5 2.4 Ausblick Mit dieser Studienarbeit wurden die beiden Plugins mit weiterer Funktionalität ausgestattet, es bieten sich jedoch noch viele Weiterentwicklungsmöglichkeiten an Refactoring Plugin Die wichtigste Weiterentwicklung ist sicherlich, dass man das Refactoring Plugin auch für die anderen Datenbankdialekte implementiert. Dies wäre nicht einmal so zeitaufwendig, da die Basis sowie deren Erweiterungsschnittstellen bereits durch uns erstellt wurden. Des Weiteren wäre es denkbar die restlichen Datenbank-Refactorings aus dem Buch Refactoring Databases: Evolutionary Database Design *RD06+ zu implementieren. Ein weiterer sehr interessanter Punkt wäre zudem die Plugins mit einer Vorschau-Funktion zu erweitern. Diese könnte den Zustand der Datenbank nach dem Refactoring und die Anzahl Datensätze welche geändert werden müssten zeigen. Der Benutzer hätte eine bessere Übersicht und wäre sich im Klaren darüber, was überhaupt auf der Datenbank alles geändert würde. Ausserdem ist auch eine Funktion denkbar, welches es ermöglicht Refactorings rückgängig zu machen (Historie-Funktion) Postgres Plugin Für das Postgres Plugin wäre eine grafische Darstellung des Query-Plans eine vorteilhafte Erweiterung. Die Darstellung würde für den Benutzer in einem Diagramm zeigen, was für Objekte und Abläufe bei der Ausführung eines SQL-Statements involviert sind und in welchem Zusammenhang sie dabei stehen. Zudem wäre die Implementation weiterer PostgreSQL-spezifischen Funktionen und Statements denkbar. 5 / 96

6 Inhaltsverzeichnis 1 Abstract Management Summary Ausgangslage Vorgehen Ergebnisse Ausblick Aufgabenstellung... 9 TEIL I: TECHNISCHER BERICHT Einführung Einleitung Aufbau des Dokumentes Problemstellung und Vision Ziele Rahmenbedingungen Stand der Technik Resultate Geforderte Funktionalität Schlussfolgerung Persönliche Berichte Daniel Regli Yannick Winiger TEIL II: SW-PROJEKTDOKUMENTATION Anforderungsspezifikation Anforderungen an die Studienarbeit Allgemeine Beschreibung Spezifische Anforderungen Analyse Internationalisierung (i18n) Logging Design & Implementation Externes Design Refactoring Plugin Postgres Plugin Tests / 96

7 10.1 Technologie Automatische Tests Manuelle Tests Use Case Tests Abweichungen Nicht berücksichtigte Punkte Testfazit Weiterentwicklung Möglichkeiten der Weiterentwicklung Projektmanagement Projektorganisation Management Abläufe Risiko Management Arbeitspakete Infrastruktur Qualitätsmassnahmen Sitzungs-Protokolle Projektmonitoring Softwaredokumentation Voraussetzungen Installation Konfiguration Anwendung TEIL III: ANHANG Inhalt der CD Glossar und Abkürzungsverzeichnis Literatur- und Quellenverzeichnis Testdatenbank DDL Insert Sitzungsprotokolle Sitzungsprotokoll vom Kickoff Meeting Sitzungsprotokoll vom 1. Oktober Sitzungsprotokoll vom 9. Oktober Sitzungsprotokoll vom 19. Oktober Sitzungsprotokoll vom 26. Oktober / 96

8 18.6 Sitzungsprotokoll vom 09. November Sitzungsprotokoll vom 23. November Sitzungsprotokoll vom 30. November Sitzungsprotokoll vom 14. Dezember / 96

9 3 Aufgabenstellung Der nachfolgende Text entspricht der original Aufgabenstellung, wie sie von Prof. Stefan Keller formuliert wurde. SQuirreL DB Refactoring Autoren/Studenten: Verantwortlicher/ Betreuer: Studienarbeit HS 2007 Daniel Regli, HSR, Abteilung Informatik Yannick Winiger, HSR, Abteilung Informatik Prof. Stefan Keller, HSR, Abt. Informatik Partner (Firma oder Verwaltung), externer Betreuer: Die Open Source Community Einführung SQuirreL ist ein grafisches Java-Programm, dass es erlaubt, die Struktur einer JDBC-fähigen Datenbank anzusehen, deren Tabellen-Daten zu bearbeiten und SQL-Befehle auszuführen. Über 20 Datenbankmanagementsysteme (DBMS) werden zurzeit unterstützt, darunter MySQL, Oracle und PostgreSQL, es gibt Syntax-Highlighting und dutzende von Erweiterungen (Plugins). Auch eine PostgreSQL-Anbindung und ein rudimentäres Refactoring-Plugin sind vorhanden. Diese nutzen aber noch nicht die spezifischen Möglichkeiten einzelner DBMS aus, bzw. können noch ausgebaut werden. Aufgabenstellung Das PostgreSQL- und das Refactoring-Plug-in sollen mit produkttauglichem Code erweitert werden. Beim PostgreSQL-Plug-in fehlen u.a. spezifische Funktionen wie vacuum, explain. Beim Refactoring Plug-in könnten folgende zusätzliche Funktionen realisiert werden: Structural Refactorings (create, rename, drop, merge, etc.), Data Quality Refactorings (add, remove, etc.), Referential Integrity Refactorings und weitere Refactorings wie extract view, extract method, etc. Weitere Details dazu sind auf der Projekt-Startseite aufgeführt: Die Erweiterungen werden mit z.t. noch zu erarbeitenden Daten für das systematische Testen und mit Real World -Daten getestet. Das Vorgehen ist pragmatisch. Das Resultat soll wieder in das Projekt zurückfliessen. Stichworte: Pattern, Datenbanken, PostgreSQL, Java. Lieferdokumente: Lauffähiger Code in Binärform sowie als Sourcecode (englisch). 9 / 96

10 Hinweise Build-Skripte (ANT) dazu inkl. Javadoc etc. Programm-Online-Hilfe (englisch). Short Delevopers Documentation (englisch). Technischer Bericht (Management Summary deutsch) und Software Engineering- Dokumentation (deutsch). Die funktionalen und nicht-funktionalen Anforderungen werden aus der Aufgabenstellung abgeleitet. Ev. zu erwähnen ist die Demo und dass die Plug-ins robust sind und sich gut in SQuirreL integrieren sollen. Randbedingungen, Infrastruktur, Termine und Beurteilung Randbedingungen: o Java gemäss SQuirreL o PostgreSQL, ev. eine weiteres DB-Produkt o Build-Tool o Open Source Lizenzen Termine: gemäss Angaben auf Beurteilung: gemäss Angaben auf Rapperswil, 9. Oktober 2007 Der Betreuer Die Studierenden Prof. Stefan Keller 10 / 96

11 TEIL I: TECHNISCHER BERICHT 4 Einführung 4.1 Einleitung Eine zentrale Frage ist, warum haben wir diese Studienarbeit gewählt? Wir wussten von Anfang an, dass wir an einer Studienarbeit interessiert sind, welche zum Ziel hat eine Applikation zu entwickeln. Zudem sind wird uns einig gewesen, dass die Technologie Java sein sollte. Ein weiterer Grund für uns war, dass das Endprodukt später eingesetzt wird. Diese Studienarbeit bat sich daher besonders gut an, da sie eine Erweiterung einer rege verwendeten Open Source Applikation darstellte. Zudem ist die Applikation mit Java implementiert. Weitere persönliche Eindrücke zu der Arbeit findet man in den persönlichen Berichten der beiden Autoren im Kapitel 6 Persönliche Berichte. 4.2 Aufbau des Dokumentes Das Dokument ist grösstenteils nach den Richtlinien für Studienarbeiten von SK aufgebaut. Einzelne Kapitel wurden entfernt oder geändert. Die Struktur besteht aus folgenden Teilen: Abstract Management Summary Teil 1 Technischer Bericht o Einführung, Vision, Stand der Technik, Umsetzungskonzept und Resultate Teil 2 Software Projektdokumentation o Anforderungsspezifikation, Analyse, Design und Implementation, Tests, Resultate und Weiterentwicklung, Projektmanagement, Softwaredokumentation 4.3 Problemstellung und Vision In der Informatik wird die Persistenz einer Applikation oft mittels einer Datenbank gehandhabt. Heute gibt es schon eine Unmenge von SQL-Datenbankanbietern mit ihren teils unterschiedlichen Dialekten (MySQL, Oracle, PostgreSQL, etc.). Alle diese können über unzählige verschiedene Datenbank-Tools verwaltet werden. Auf den ersten Blick scheint es so, dass man als Datenbankadministrator für jeden Dialekt ein eigenes Tool verwenden müsste, dies obwohl fast alle Dialekte mit dem SQL-Standard bis auf minimale Unterschiede, übereinstimmen. Nun gibt es eine Open Source Applikation namens SQuirreL SQL Client, welche die Funktionalität des Abfragens und Darstellen von Informationen zu verschiedenen Dialekten ermöglicht. Das weniger nützliche dieser Applikation ist, dass eine Änderung auf der Datenbank (Informations- /Strukturänderungen) nur über das eigen abgesetzte SQL-Statement gemacht werden kann. Für eine grössere Änderung (wie z.b. zwei Kolonnen einer Tabelle zusammenführen) kann dies zeitintensiv, sowie fehleranfällig sein. Unsere Vision ist es dem Abhilfe zu schaffen, indem wir zwei Plugins entwickeln, welche das mühsame Schreiben der SQL-Statements für ein Refactoring überflüssig machen. Dies durch grafische Dialoge mit allfälligen Konfigurationsmöglichkeiten. Die Dialoge generieren für den jeweils spezifischen Dialekt die SQL-Statements. Wir sprechen von simplen Struktur Änderungen wie das Hinzufügen einer Kolonne bis hin zu 11 / 96

12 komplizierteren Änderungsabläufen wie das Zusammenfügen von zwei Tabellen. Dies führt auch schon zum zentralen Begriff Refactoring, welcher auch im Datenbankumfeld eine immer wichtigere Rolle spielt. Im Buch Refactoring Databases:Evolutionary Database Design [RD06] werden viele verschiedene Datenbank-Refactoring beschrieben. Wir werden dieses Buch als Referenz verwenden und die Implementation nach dieser Beschreibung tätigen. Refactoring Plugin Das erste Plugin wird diverse Refactorings beinhalten und soll für alle Dialekte ausgelegt sein. Aus Aufwandsgründen wird nach Abschluss unserer Studienarbeit nur der PostgreSQL Dialekt unterstützt. Die Architektur des Plugins soll so ausgelegt werden, dass durch unsere vorgegebene Schnittstelle neue Datenbank-Dialekte nachträglich hinzugefügt werden können. Dieses Plugin trägt den Namen Refactoring Plugin. Postgres Plugin Das zweite Plugin wird speziell für den PostgreSQL Dialekt entwickelt, es wird einzelne PostgreSQL Funktionen beinhalten (vacuum, explain). Dieses Plugin trägt den Namen Postgres Plugin. SQuirreL DB Refactoring Die ganze Studienarbeit läuft unter dem Namen SQuirreL DB Refactoring. Die Gründe für den Namen können nochmals kurz erwähnt werden: SQuirreL die Kurzbezeichnung der Applikation in welcher die Plugins integriert werden DB Refactoring bei der Implementierten Funktionalität handelt es sich grössten Teils um Datenbank Refactorings 4.4 Ziele Wir haben uns zum Hauptziel gesetzt die Anforderungen, welche wir von SK bekommen haben zu erfüllen. Siehe Kapitel 3 Aufgabenstellung. Zu den oben erwähnten Zielen kommen auch noch persönliche Ziele dazu: Zwei Top-Plugins zu entwickeln, welche von den Anwendern des SQuirreL SQL Clients eingesetzt werden können. Eine gute Grundbasis für die Weiterentwicklung der Plugins für alle nicht realisierten Dialekte zu schaffen. Kenntnisse in dem Thema Datenbank Refactoring erlangen. Software-Projekt mit allen Software-Engineering Aspekten an einem realen Projekt realisieren und Feedbacks zu unserer Implementation von der ganzen Welt bekommen. Projektplanung, Zeitmanagement und Abschätzungen üben. Entwicklerdokumentation in einer fremden Sprache zu erstellen, welche die Weiterentwicklung in der Open Source Community erleichtern. Pragmatische Vorgehensweise kennenlernen. 12 / 96

13 4.5 Rahmenbedingungen Umfeld Das Umfeld ist durch die bestehenden Plugins vorgegeben. Die Programmiersprache ist Java in der Version 1.5. Es müssen die Komponenten des Squirrel Frameworks und Best Practice Implementation anderer Plugins sinnvoll verwendet werden. (Die Plugins sollen sich in den Programmierstil von SQuirreL einfügen.) 4.6 Stand der Technik In diesem Kapitel werden bestehende Applikationen oder Lösungen zum Zeitpunkt der Studienarbeit aufgezeigt. Diese befassen sich einerseits mit Datenbank-Refactoring und anderseits mit den spezifischen Funktionen vacuum/explain des Postgres Plugins. Zudem wird der Begriff Datenbank- Refactoring in der Literatur angesprochen Bestehende Applikationen zum Thema Datenbank-Refactoring Wir haben im Vorfeld drei Applikationen zum Thema Datenbank-Refactoring angeschaut: LiquiBase Visual Studio 2005 Team Edition for Database Professionals SQL Refactor Es werden nun diese drei Applikationen kurz beschrieben. LiquiBase LiquiBase ist eine Open Source DBMS-unabhängige Java Klassenbibliothek. Sie ermöglicht das Verwalten, sowie Ausführen und Festhalten von Datenbankänderungen. Wobei man in unserem Fall bei Datenbankänderungen von Refactorings spricht. Der Benutzer kann durch eine XML Beschreibung ein Refactoring definieren. Er hat dann die Möglichkeit dies mittels Softwareschnittstellen (Plugins, Konsole, etc.) auszuführen. Vom Funktionsaufwand bietet es viele Refactoringmöglichkeiten an. Für eine genaue Auflistung verweisen wir auf die Projektwebseite. Visual Studio 2005 Team Edition for Database Professionals Eine Applikation von Microsoft, welche es erlaubt Microsoft SQL Server zu verwalten. Datenbankänderungen können aufgezeichnet (Change Management) und wieder zurück gesetzt werden. Es erlaubt grundlegende Refactorings wie z.b. Umbenennen von Datenbankobjekten. Ein Vorteil ist, dass alles über eine grafische Benutzeroberfläche getätigt werden kann. SQL Refactor SQL Refactor ist ein kostenpflichtiges Add-In zum SQL Server Management Studio. Es bietet die Möglichkeit über eine Benutzeroberfläche einfache Refactorings durchzuführen. Es bietet jedoch nur gerade Unterstützung für den SQL Server 2000/2005. Vom Funktionsumfang her bietet es wenig, nur gerade 11 verschiedene Refactorings werden Angeboten. Für die genaue Auflistung verweisen wir auf die Projektwebseite. 13 / 96

14 Vergleich der Applikation Im Vergleich wird auf die Funktionalität bezüglich Refactoring wert gelegt und weniger auf andere zusätzliche Funktionen. Zudem werden normale Kriterien wie Preis, Benutzerfreundlichkeit, Plattform Abhängigkeit und Datenbankunterstützung verglichen. LiquiBase + grosse Funktionalität (~40 Refactorings) + unterstützt viele Dialekte + frei Verfügbar + plattformunabhängig + Plugin Integration in Eclipse / IntelliJ - wenig benutzerfreundlich, Eingabe als XML Text Visual Studio 2005 Team Edition for Database Prof. + Erweiterte Funktionalität im Bereich Changemanagement - wenig Funktionalität (nur Rename Refactorings) - kostenpflichtig - Unterstützung nur MS SQL Server - nur unter Windows SQL Refactor + mittlere Funktionalität (~11 Refactorings) + benutzerfreundlich, Aktion via Benutzeroberfläche - unterstütz nur SQL Server 2000/ kostenpflichtig - nur unter Windows Applikationen mit Postgres Funktionalität Bezüglich der Funktionen vacuum und explain in PostgreSQL wurden im Vorfeld folgende zwei Applikationen angeschaut: EMS SQL Manager for PostgreSQL pgadmin III Die beiden Applikationen werden nun kurz beschrieben. EMS SQL Manager for PostgreSQL Es handelt sich hierbei um eine kostenpflichtige Applikation für die Verwaltung und Entwicklung eines PostgreSQL Server. Die Applikation eignet sich für alle PostgreSQL Versionen bis zu 8.2. Sie bietet eine grafische Oberfläche, welche die Applikation leicht verständlich macht. Sie beinhaltet speziell die Funktionen vacuum und explain, welche für uns releveant sind. pgadmin III pgadmin III ist eine Open Source Applikation zur Verwaltung und Entwicklung eines PostgreSQL Server. Die Applikation eignet sich für alle PostgreSQL Versionen ab 7.2. Sie ist als Multiplattform- Applikation und in mehreren Sprachen verfügbar. Sie bietet eine grafische Oberfläche, sowie beinhaltet sie eine verständliche, anschauliche Darstellung der beiden Funktionen vacuum und explain. Die beiden Applikationen unterscheiden sich nur minimal. Der Hauptunterschiede sind, dass pgadmin III frei verfügbar ist und als Multiplattform-Applikation angeboten wird Datenbank Refactoring in der Literatur Zum jetzigen Zeitpunkt gibt es nur ein paar Bücher über Datenbank-Refactoring. Eines der wichtigeren und guten ist das vom Addison Wesley Verlag Refactoring Databases: Evolutionary Database Design [RD06]. Dieses Buch gibt eine gute Einführung in Datenbank-Refactoring und geht dann sehr detailiert auf einzelne Refactorings ein. 14 / 96

15 Ein weiteres Buch, welches einen kurzen Abschnitt über Datenbank-Refactoring enthält, ist vom Wiley Verlag Agile Database Techniques [AD03]. Es geht mehr auf den Programmieraspekt ein. Es beschreibt auf was alles geachtet werden muss und wie eine Applikationen darauf vorbereitet werden sollten. Refactorings werden in der Literatur nach den folgenden Gruppen gegliedert: Struktur-Refactorings o Sind Änderungen, welche die Tabellen Struktur des Datenbank Schemas ändern. Datenqualitäts-Refactorings o Sind Änderungen, welche die Qualität der Informationen in der Datenbank erhöhen. Referenzielle Integrität Refactorings o Sind Änderungen, welche sicherstellen, dass auf einer Tabelle eine referenzierte Zeile existiert oder wenn sie nicht mehr länger gebraucht, entsprechend gelöscht wird. Architektur-Refactorings o Sind Änderungen, welche das Verhalten (mit externen Programmen) verbessern. Transformation o Sind Änderungen, welche die Semantik des Datenbankschemas durch hinzufügen von neuen Funktionen verändern. 15 / 96

16 5 Resultate 5.1 Geforderte Funktionalität In der nachfolgenden Tabelle 2 findet man eine Auflistung der anfangs geforderten Funktionalität, sowie eine Beschreibung der von uns getätigten Implementation. Die kursiven geforderten Funktionalitäten sind solche, welche ansatzweise oder ganz in den bestehenden Plugins bestanden. Geforderte Funktionalität Structural Refactorings: Column: Drop, Modify, Rename, Merge Index: Drop Sequence: Add, Drop, Modify Table: Drop, Rename, Merge View: Drop, Rename Data Quality Refactorings: Add Auto-Increment Add Lookup Table Default Value Column: Add, Drop Non-Nullable Column: Add, Drop Unique Constraints: Add, Drop Referential Integrity Refactorings: Foreign Key Constraint: Add, Drop Primary Key Constraint: Add, Drop Transformations: Column: Add Column Table: Add Table Architectural Refactoring: Index: Add Index View: Add View Postgres Plugin: Vacuum Table Explain Tabelle 2: Implementierung der Anforderungen Umsetzung Wurden alle umgesetzt. Diese wurden alle umgesetzt bis auf die dritte Variante von Add Lookup Table. Es kann nicht aus einem Enum eine Lookup Table erstellt werden. Wurden alle umgesetzt. Add Table wurde aus zeitlichen Gründen nicht implementiert. Nach Absprache mit SK mache es mehr Sinn andere Funktionalität zu implementieren. Transformations sind im eigentlichen Sinne auch keine Refactorings, weshalb es zusätzlich noch einen tieferen Stellenwert bekam. Wurden alle umgesetzt. Wurden alle umgesetzt. Hierbei ist noch zu erwähnen, dass als zusätzliche Implementation das Vacuum auch global für die ganze Datenbank implementiert wurde (Vacuum Database). 5.2 Schlussfolgerung Mit dieser Studienarbeit haben wir die beiden Plugins mit vielen neuen Refactorings ausgestattet. Einerseits mit grundlegenden Refactorings wie z.b. Datenbankelemente zu kreieren oder zu löschen oder kleinere Mutationen. Anderseits auch grössere komplexere Refactorings wie z.b. Add Lookup Table oder ein Merge Table, welche viele Statements generieren und auch Daten migrieren. Aus zeitlichen Gründen konnten wir die Refactorings nur für PostgreSQL Datenbanken implementieren. Die meisten SQL-Statements die wir für PostgreSQL generieren sollten allerdings dem SQL Standard (SQL99/SQL2003) entsprechen. Um dies genauer zu untersuchen hatte die Zeit nicht gereicht und war zudem auch keine Anforderung. Die Schnittstelle für die Generierung der Dialekt-spezifischen Statements wurde definiert und somit kann relativ einfach ein neuer Dialekt hinzugefügt werden. 16 / 96

17 Als Benutzeroberflächen können die von uns Erstellten verwendet werden und es müssen nur in Spezialfällen kleine Änderungen daran vorgenommen werden. Im Vergleich zu anderen Applikationen, welche sich mit Datenbank-Refactoring befassen, können unsere Plugins sicherlich mithalten. Sie haben noch nicht ganz so viel Funktionalität wie andere, sind jedoch für den Benutzer einfacher zu bedienen. Die Fähigkeit, dass man die generierten Statements anzeigen und auch editieren kann, ermöglicht es auch Spezialfälle auszuführen. Die Grundlagen wurden gelegt. Nun gibt es viele Weiterentwicklungsmöglichkeiten, wir verweisen für diese auf Kapitel 2.4 Ausblick (im Technischen Bericht). 17 / 96

18 6 Persönliche Berichte 6.1 Daniel Regli Studienarbeitsauswahl Als die ersten s bezüglich der Wahl der Studienarbeit verschickt wurden, machte ich mir die ersten Gedanken über die Studienarbeit. Wir konnten uns über die Informations-Webseite der Studienarbeiten für drei Studienarbeiten mit unterschiedlicher Priorität bewerben. Wir bewarben uns für die Studienarbeit ''SQuirreL DB Refactoring'' mit höchster Priorität, da sie uns am meisten zusagte und interessierte. Wir bekamen, zu unserer Freude, die Zusage zu der Studienarbeit kurz bevor das neue Semester begann Durchführung der Studienarbeit Die Start-Phase gingen wir eher ruhig an, wir hatten uns entschlossen mit einem Slow-Start zu beginnen. Ich war am Anfang mit dem Festhalten der Anforderungen beschäftigt. Nachher ging es darum sich in dem Framework und der Umgebung zu Recht zu finden. Mein erster Eindruck in das Framework war, dass es riesig und unübersichtlich und zudem schlecht dokumentiert sei. Eigentlich wurde erst vieles klarer, als ich direkt im Code gelesen hatte. Die Planung wurde Grössenteils durch Yannick Winiger erstellt und wir diskutierten seine Ergebnisse danach im Team. Die Erarbeitung der Arbeitspakete, sowie die Zuteilung wurden wieder zusammen gemacht. Ich fand die Anfangsphase sehr gut, denn es wurden viele Unklarheiten bezüglich des Vorgehens zu der Studienarbeit geklärt und wir wurden langsam in Problemstellung sowie Umgebung eingeführt. Der Hauptteil begann für mich, als wir anfingen das Design der Plugin-Architektur zu erstellen. Da wir auf bestehenden Plugins aufbauten und die Architektur nicht ganz von neu auf erstellen konnten, mussten wir uns wieder mit der bestehenden Architektur vertraut machen. Diese war schlecht verständlich, da der Entwickler einen anderen Coding-Style als ich hatte und die Suche nach einer Dokumentation vergebens war. Ich hatte dann ein kleines Refactoring des Codes durchgeführt, jedoch darauf geachtet, dass es den Zeitrahmen nicht sprengte. Nachdem erstellte ich den Prototypen. Dieser bestand grob beschrieben aus einer weiteren Refactoring-Funktion. Diese ist gelungen und zeigte, dass die geplante Architektur funktionierte. Ab diesem Zeitpunkt beschäftigte ich mich hauptsächlich mit der Implementation des Refactoring Plugin. Es ging gut voran und Funktion für Funktion konnte implementiert werden. Zwischendurch traten einige Probleme auf, wobei ich diese mit Yannick Winiger oder alleine lösen konnte. Gegen Ende der Programmierphase wurde es dann immer stressiger und auch die investierte Zeit pro Woche stieg stark an. Das Testen der Applikation stellte sich dann als Problem heraus. Die einzelnen Komponenten haben eine grosse Abhängigkeit mit dem ganzen Framework und können somit nicht einzelnen getestet werden. Ich habe vergebens versucht die bestehenden Mock-Objekte zum Laufen zu bringen. Danach hatte ich mich entschieden nur die Funktionalität des Generierens zu testen, sowie Use Case Tests zu entwerfen. 18 / 96

19 In einem späteren Schritt habe ich die Use Case Tests auch durchgeführt und feststellen müssen, dass seit dem letzten Check-In im SVN fast nichts mehr funktionierte. Yannick Winiger hatte viele kleine Änderungen gemacht und keine Tests durchgeführt und daher sein Fehler an einer zentralen Stelle nicht bemerkt. (Dieser Fehler hatte Auswirkungen auf alle Funktionen.) An diesem Zeitpunkt wurde mir klar, weshalb das Testen und speziell automatische Tests so wertvoll sind und wichtig sind. Die Programmierphase war abgeschlossen und ich begann mit der Dokumentation des Technischen Berichtes. Es stellte sich heraus, dass dieser viel Zeit in Anspruch nahm. Wir konnten diese Hürde jedoch auch noch nehmen und haben dieses Dokument erfolgreich erstellt und damit auch die Studienarbeit abgeschlossen Mein Fazit Mein persönliches Fazit ist, dass das Projekt definitiv erfolgreich Abgelaufen ist. Ich konnte alle meine persönlichen Ziele erreichen und bin gespannt was für Feedbacks auch noch aus der Open Source Community kommen. Ich freue mich jetzt schon auf das kommende Semester, wo wir unsere Bachelorarbeit absolvieren dürfen. 6.2 Yannick Winiger Durchführung der Studienarbeit Die ersten paar Wochen unserer SA verliefen relativ ruhig. Wir konzentrierten uns darauf einen sauberen Projektplan zu erstellen und uns mit SQuirreL und PostgreSQL vertraut zu machen. Von Woche 6 bis Woche 10 habe ich mich ausschliesslich mit der Implementation des Postgres Plugins beschäftigt, während Daniel Regli das Refactoring Plugin erweiterte. Anschliessend arbeitete ich noch bis Woche 12 am Refactoring Plugin mit. Nachdem fast alle Refactorings implementiert waren nahmen wir uns noch 1,5 Wochen Zeit ein Code Refactoring des Refactoring Plugin und ausführliche Use Case und Unit Tests bei beiden Plugins durchzuführen. Etwas unterschätzt hatten wir den Dokumentationsaufwand am Schluss des Projektes, so dass die Arbeitsstunden pro Woche gegen Ende des Projekts immer auf über 20 stiegen. Dies war allerdings in Anbetracht unseres eher ruhigeren Starts ( Slow-Start ) genau wie geplant SQuirreL Bei der Einarbeitung in das SQuirreL Framework und die Architektur der Plugins wurde schnell klar was eine Herausforderung bei diesem Projekt sein könnte: Die fast komplett fehlende Dokumentation. Um wirklich zu verstehen was eine Klasse oder Methode macht musste man sich immer intensiv mit dem Code und sonstige Verwendungen dieser Klasse/Methode ( Find Usage Funktion von IntelliJ war hierbei sehr hilfreich) auseinandersetzen oder alternativ (riskante) Annahmen nach dem Try & Error Prinzip treffen. Hilfreich bei der Implementation neuer Funktionen waren auch die vielen anderen Plugins (meist auch undokumentiert) von SQuirreL. Sie lieferten meist gute Ideen wie man gewisse Probleme mit den passenden Klassen des Frameworks lösen konnte. 19 / 96

20 6.2.3 Code Refactoring Bei vielen Projekten wird das Code Refactoring meist auf einen späteren Zeitpunkt nach dem Final Release verschoben und schlussendlich dann doch nicht durchgeführt. Wir haben uns deshalb gegen Ende des Projekts nochmal Zeit genommen um einige Code Refactorings durchzuführen um den SQuirreL Developers nicht nur ein funktional erweitertes Plugin zu liefern, sondern auch die zukünftige Erweiterung dieses Plugins so einfach wie möglich zu gestalten (gute Dokumentation und gutes Design um redundanten Code/Funktionalität zu verhindern). Mir persönlich hat das Refactoring des Refactoring Plugin enorm Spass gemacht und auch wenn es bei einem Open Source Projekt eher um Funktionalität als um Design geht, war die Entscheidung für ein Code Refactoring absolut richtig Unit Tests Beim Code Refactoring wurde zudem klar, wie wichtig es ist bei der Plugin Entwicklung funktionierende Mock-Objekte zur Verfügung zu haben. Ohne diese Mock-Objekte konnten wir leider keine ausführlichen Unit Tests schreiben und nur die Generierung der SQL-Statements testen. Dies führte nach meinem Code Refactoring dazu, dass sich einige schwere Fehler unbemerkt in die Plugins eingeschlichen hatten. Dank gründlichen Use Case Tests durch Daniel Regli wurden diese Fehler allerdings schnell entdeckt Mein Fazit Für mich war das Projekt ein voller Erfolg und ich bin gespannt auf das Feedback der SQuirreL- Community. Das Projekt verschaffte mir einen interessanten Einblick in ein aktuelles Open Source Projekt (mit allen Vor- und Nachteilen) und das mir früher völlig unbekannte Thema Datenbank-Refactoring. Zudem konnte ich mein Wissen zu Datenbanken & SQL vertiefen. Ich freue mich jetzt schon auf unsere Bachelorarbeit um das in diesem Projekt Erlernte direkt wieder anwenden zu können. 20 / 96

21 TEIL II: SW-PROJEKTDOKUMENTATION 7 Anforderungsspezifikation 7.1 Anforderungen an die Studienarbeit Der folgende Text ist ein Auszug von der Wiki-Seite von Prof. Stefan Keller für die Anforderungen an einer Studienarbeit. Gerne betreue ich Studien-, Diplom- und Bachelor-Arbeiten, denn dies sind Projektarbeiten, die typischerweise eine Win-Win-Win-Situation für alle Beteiligten darstellen. Die Beteiligten sind Sie als Studierende und Lernende, dann kommen eventuelle externe Firmen oder eine Community und als Drittes sind da noch meine Interessenschwerpunkte, wie (Geo-)Informationssysteme, Information Retrieval, Datenbanken und Java (ev. Skriptingsprachen). Folgendes wird u.a. von Ihnen erwartet: Wöchentliche Meetings mit: o "Was wurde gemacht, was ist geplant, wo liegen Schwierigkeiten?" o Feedback und Hilfestellung meinerseits. o Plan für Meeting jeweils am Vortag/12h vorher an mich. Regelmässige/wöchentliche Abgabe von Code/Dokumentation zum Review, idealerweise jeweils 1 Tag vor Statusmeeting, bei umfangreicheren Doks 1/2-1 Woche vorher Build Prozess (z.b. ANT), automatische Tests (JUnit) und Repository (CVS, SVN) Vorgehensweise: ganz gemäss IFS-Richtlinien - für eine pragmatische aber trotzdem geordnete Vorgehensweise. Grundsätzlich wird gemäss Angaben auf i.hsr.ch bewertet. Dabei gilt, dass für Studentenprojekte manches ein "Muss" ist, dass bei einer ergebnisorientierten Sichtweise im Berufsleben vielleicht nicht nötig wäre. Aber es ist immer notwendig, sinnvoll zu dokumentieren, damit die Arbeit auch von anderen begutachtet werden kann. So sollten zum Beispiel die Anforderungen als Use Cases beschrieben sein. Priorisiert man diese, hat man eine Möglichkeit einen "open scope" Contract zu vereinbaren, wobei ein Mindestmass ein Funktionalität (-> ~4.0) eine wünschenswerte Funktionalität (->~5.0) und das Maximum (->5.5-6) beschrieben werden können. 7.2 Allgemeine Beschreibung Einführung Auszug aus der Aufgabenstellung von Stefan Keller. SQuirreL ist ein graphisches Java-Programm, dass es erlaubt, die Struktur einer JDBC-fähigen Datenbank anzusehen, deren Tabellen-Daten zu bearbeiten und SQL-Befehle auszuführen. Über 20 Datenbanksysteme werden z.zt. unterstützt, darunter MySQL, Oracle und PostgreSQL, es gibt Syntax-Highlighting und dutzende von Plug-ins. Auch eine PostgreSQL-Anbindung und ein rudimentäres Refactoring-Plug-in ist vorhanden. Diese nutzen aber noch nicht die spezifischen Möglichkeiten aus, bzw. können noch ausgebaut werden. Beim Projekt SQuirreL DB Refactoring handelt es sich um Erweiterungen (Plugins) für die bestehende Software SQuirreL SQL Client. Es sollen die folgenden zwei Plugins erweitert werden: Refactoring Plugin Postgres Plugin 21 / 96

22 Die nachfolgende Abbildung 2 zeigt grob die Domäne des SQuirreL SQL Client und in welchem Kontext die Plugins stehen. Abbildung 2: SQuirreL SQL Client Domäne Produkt Perspektive Die erweiterten Plugins des Projekts SQuirreL DB Refactoring werden zur Zeitersparnis und Benutzerfreundlichkeit bei der Verwendung des SQuirreL SQL Client beitragen. Es werden für verschiedene Datenbankoperationen Vereinfachungen mittels grafischer Oberfläche ermöglicht Produkt Funktion Es lassen sich folgende Funktionen für die beiden Plugins festhalten: Postgres Plugin: vacuum o Garbage Collector und Datenbank-Analyzer explain o Refactoring Plugin: Ausführungsplan eines Statements anzeigen Structural Refactorings o Create, Rename, Drop Table o Split / Merge Table o Create, Rename View, Drop View o Add, Rename Column, Modify Column, Drop Column, Merge Columns o Alter Sequence o Create/Drop Index Data Quality Refactorings o Add Lookup Table (Aufzähltyp/DOMAIN) o Add/Remove Not-Null Constraint o Add/Drop Unique Constraint 22 / 96

23 o o o Create/Drop Sequence Add Auto-Increment Add/Drop Default Value Referential Integrity Refactorings o Add/Drop Foreign Key Constraint o Add/Drop Primary Key Constraint Es ist möglich, dass während dem Verlauf des Projektes weitere Funktionen hinzukommen oder weggelassen werden. Die aktuelle Liste der Funktionen findet man auf dem Wiki Benutzer Charakteristik Die Zielgruppe der Refactoring Plugins sind Benutzer, welche ihre Operationen über eine grafische Oberfläche tätigen. Hierzu gehören auch diejenigen Benutzer, welche bis anhin die Funktionen per Statement auf der Datenbank ausgeführt haben sowie alle Neuanwender von SQuirreL SQL Client. Zur Bedienung werden keine zusätzlichen Computerkenntnisse vorausgesetzt Betriebsumgebung Die Betriebsumgebung der Plugins ist der bestehende SQuirreL SQL Client. Für die genauere Betriebsumgebung für den SQuirreL SQL Client verweisen wir auf deren Projektwebseite. (siehe auch Einschränkungen sowie Abhängigkeiten) Benutzer Dokumentation Zu jedem Plugin wird eine Hilfeseite zur bestehenden Hilfe des SQuirreL SQL Clients hinzugefügt. Diese wird die einzelnen Funktionen erklären, sowie Beispiele aufzeigen. Es wird keine eigene Webseite für die beiden Plugins erstellt Einschränkungen Die Plugins werden vorerst nur für PostgreSQL Datenbank zur Verfügung gestellt. Eine spätere Erweiterung auf andere Datenbank-Dialekte ist möglich, ist jedoch zurzeit kein Thema und somit nicht eingeplant. Die Architektur sollte jedoch so ausgelegt werden, dass der Aufwand des hinzufügen von weiterer Datenbanken-Dialekten möglichst gering gehalten wird Abhängigkeiten Es wird die Version des SQuirreL SQL Client Version 2.6 vorausgesetzt. Die Plugins werden mit Java 1.5 entwickelt, daher wird eine lauffähige Java Version ab 1.5 vorausgesetzt. 1 Wiki von SK: 23 / 96

24 7.2.9 Use Cases im Überblick /-Diagramm Use Case Diagramm Abbildung 3: Use Case Diagramm Übersicht Use Case Überblick Es folgt nun eine brief Beschreibung der Use Cases. UC01: ACD Table Primary Actor: SQuirreL SQL Client Benutzer Der Benutzer kann eine Tabelle erstellen, umbenennen oder löschen. UC02: ACD View Primary Actor: SQuirreL SQL Client Benutzer Der Benutzer kann eine View erstellen, umbenennen oder löschen. UC03: ACD Column Primary Actor: SQuirreL SQL Client Benutzer Der Benutzer kann eine Kolone erstellen, umbenennen, modifizieren oder löschen. UC04: AD Index Primary Actor: SQuirreL SQL Client Benutzer 24 / 96

25 Der Benutzer kann einen Index erstellen oder löschen. UC05: AD Sequence Primary Actor: SQuirreL SQL Client Benutzer Der Benutzer kann eine Sequenz erstellen oder löschen. UC06: Merge Column Primary Actor: SQuirreL SQL Client Benutzer Der Benutzer kann eine Kolone mit einer anderen zusammenlegen (vereinigen). UC07: AD Foreign Key Primary Actor: SQuirreL SQL Client Benutzer Der Benutzer kann einen Fremdschlüssel zu einer Tabelle hinzufügen oder löschen. UC08: AD Primary Key Primary Actor: SQuirreL SQL Client Benutzer Der Benutzer kann einen Primärschlüssel zu einer Tabelle hinzufügen oder löschen. UC09: Add Lookup Table Primary Actor: SQuirreL SQL Client Benutzer Der Benutzer kann eine Lookup Tabelle hinzufügen aus einem Aufzähltyp oder einer DOMAIN. UC10: AD NOT-NULL Primary Actor: SQuirreL SQL Client Benutzer Der Benutzer kann eine NOT-NULL Beschränkung für eine Spalte hinzufügen oder entfernen. UC11: AD UNIQUE Condition Primary Actor: SQuirreL SQL Client Benutzer Der Benutzer kann eine UNIQUE Beschränkung für eine Spalte hinzufügen oder entfernen. UC12: AD AUTO-INCREMENT Primary Actor: SQuirreL SQL Client Benutzer Der Benutzer kann eine AUTO-INCREMENT Beschränkung für eine Spalte hinzufügen oder entfernen. UC13: Default Value Condition Primary Actor: SQuirreL SQL Client Benutzer Der Benutzer kann ein DEFAULT Wert für eine Spalte hinzufügen oder löschen. UC14: Execute VACUUM Primary Actor: SQuirreL SQL Client Benutzer Der Benutzer kann ein vacuum auf einer Tabelle oder mehreren Tabellen ausführen. UC16: Execute EXPLAIN 25 / 96

26 Primary Actor: SQuirreL SQL Client Benutzer Der Benutzer kann sich den Ausführungsplan für ein SQL-Statement anzeigen lassen. 7.3 Spezifische Anforderungen Funktionale Anforderungen Die funktionalen Anforderungen werden in Form von Use Cases im fully dressed Format beschrieben. Für alle Use Cases die eine SQL Operation auf der Datenbank zur Folge haben gilt folgende zusätzliche Erweiterung: Erweiterungen (Nachdem der Benutzer die Einstellungen für die Operation getätigt hat, aber noch bevor die Operation ausgeführt wird.) - Der Benutzer lässt sich den SQL Befehl für die Operation anzeigen. 1. Das System zeigt den SQL-Befehl an. 2. Weiter bei 5. - Der Benutzer möchte den SQL-Befehl für die Operation editieren. 1. Das System zeigt den SQL-Befehl so an, dass der Benutzer ihn ändern kann. 2. Weiter bei 5. Zudem gelten folgende Bestimmungen für jeden Use Case: Stufe User Hauptaktor Benutzer Vorkonditionen Verbindung zu einer Datenbank in SQuirreL SQL Client UC01: ACD Table Systemgrenzen SQuirreL DB Refactoring: Refactoring Plugin Übersicht Der Benutzer kann eine Tabelle erstellen, umbenennen oder löschen. Interessengruppe Benutzer: Möchte eine Tabelle über das GUI manipulieren. Erfolgsgarantie Die manipulierte Tabelle ist gespeichert. Erfolgsszenario 1. Der Benutzer erstellt eine neue Tabelle. 2. Das System stellt die Erstellungsmöglichkeiten für eine Tabelle dar. 3. Der Benutzer tätigt die Einstellungen. 4. Das System kreiert die Tabelle. 26 / 96

27 Erweiterungen *a. {jederzeit nach 1} 1. Der Benutzer bricht ab. 1a. Der Benutzer benennt eine Tabelle um: 1. Der Benutzer selektiert die Tabelle und führt die Umbenennen- Operation aus. 2. Das System stellt ihm die Möglichkeit für das Umbenennen dar. 3. Das System setzt den neuen Namen. a. Das System meldet der Name ist schon vergeben. weiter 1a,2 1b. Der Benutzer löscht eine Tabelle: 1. Der Benutzer selektiert die Tabelle und führt die Lösch-Operation aus. 2. Das System fragt nach für das Endgültige löschen. 3. Der Benutzer bestätigt. a. Der Benutzer bricht die Aktion durch nicht bestätigen ab. -> UC Abbruch 4. Das System löscht die Tabelle. a. Das System kann die Tabelle nicht löschen-> UC Abbruch Spezielle Anforderungen Die Referenzielle Integrität darf beim Löschen nicht verletzt werden. Auftrittshäufigkeit Beliebig oft UC02: ACD View Systemgrenzen SQuirreL DB Refactoring: Refactoring Plugin Übersicht Der Benutzer kann eine View erstellen, umbenennen oder löschen. Interessengruppe Benutzer: Möchte eine View über das GUI manipulieren. Erfolgsgarantie Die manipulierte View ist gespeichert. Erfolgsszenario 1. Der Benutzer erstellt eine neue View. 2. Das System stellt die Erstellungsmöglichkeiten für ein View dar. 3. Der Benutzer tätigt die Einstellungen. 4. Das System kreiert die View. Erweiterungen *a. {jederzeit nach 1} 1. Der Benutzer bricht ab. 1a. Der Benutzer benennt eine View um: 1. Der Benutzer selektiert die View und führt die Umbenennen- Operation aus. 2. Das System stellt ihm die Möglichkeit für das Umbenennen dar. 27 / 96

28 3. Das System setzt den neuen Namen. a. Das System meldet der Name ist schon vergeben weiter 1a,2 1b. Der Benutzer löscht eine View: 1. Der Benutzer selektiert die View und führt die Lösch-Operation aus. 2. Das System fragt für das Endgültige löschen nach. 3. Der Benutzer bestätigt. a. Der Benutzer bricht die Aktion durch nicht bestätigen ab. -> UC Abbruch 4. Das System löscht die View. a. Das System kann die View nicht löschen-> UC Abbruch Spezielle Anforderungen - Auftrittshäufigkeit Beliebig oft UC03: ACD Column Systemgrenzen SQuirreL DB Refactoring: Refactoring Plugin Übersicht Interessengruppe Der Benutzer kann eine Kolonne erstellen, umbenennen, modifizieren oder löschen. Benutzer: Möchte eine Kolonne (Column) über das GUI manipulieren. Erfolgsgarantie Die manipulierte Kolonne ist gespeichert. Erfolgsszenario 1. Der Benutzer selektiert eine Tabelle und führt die Kolonne-Hinzufügen Operation aus. 2. Das System stellt die Erstellungsmöglichkeiten für eine Kolonne dar. 3. Der Benutzer tätigt die Einstellungen. 4. Das System fügt die neue Kolonne hinzu. Erweiterungen *a. {jederzeit nach 1} 1. Der Benutzer bricht ab. 1a. Der Benutzer benennt eine Kolonne um: 1. Der Benutzer selektiert die Kolonne und führt die Umbenennen- Operation aus. 2. Das System stellt ihm die Möglichkeit für das Umbenennen dar. 3. Das System setzt den neuen Namen. a. Das System meldet der Name ist schon vergeben weiter 1a,2 1b. Der Benutzer löscht eine Kolonne: 1. Der Benutzer selektiert die View und führt die Lösch-Operation aus. 28 / 96

29 2. Das System fragt für das Endgültige löschen nach. 3. Der Benutzer bestätigt. a. Der Benutzer bricht die Aktion durch nicht bestätigen ab. -> UC Abbruch 4. Das System löscht die Kolonne. a. Das System kann die Kolonne nicht löschen-> UC Abbruch Spezielle Anforderungen Die Referenzielle Integrität darf nicht verletzt werden. Auftrittshäufigkeit Beliebig oft UC04: AD Index Systemgrenzen SQuirreL DB Refactoring: Refactoring Plugin Übersicht Der Benutzer kann einen Index erstellen oder löschen. Interessengruppe Erfolgsgarantie Benutzer: Möchte einen Index zu bestehenden Kolonne oder mehreren Kolonnen hinzufügen oder löschen. Der manipulierte Index ist gespeichert. Erfolgsszenario 1. Der Benutzer selektiert eine Tabelle und führt die Index-Hinzufügen Operation aus. 2. Das System stellt die Erstellungsmöglichkeiten für einen Index dar. 3. Der Benutzer tätigt die Einstellungen. 4. Das System fügt den neuen Index hinzu. Erweiterungen *a. {jederzeit nach 1} 1. Der Benutzer bricht ab. 1a. Der Benutzer löscht einen Index: 1. Der Benutzer selektiert den Index und führt die Lösch-Operation aus. 2. Das System fragt für das Endgültige löschen nach. 3. Der Benutzer bestätigt. a. Der Benutzer bricht die Aktion durch nicht bestätigen ab. -> UC Abbruch 4. Das System löscht den Index. a. Das System kann den Index nicht löschen-> UC Abbruch Spezielle Anforderungen - Auftrittshäufigkeit Beliebig oft. 29 / 96

30 UC05: ACD Sequence Systemgrenzen SQuirreL DB Refactoring: Refactoring Plugin Übersicht Der Benutzer kann eine Sequenz erstellen, bearbeiten oder löschen. Interessengruppe Erfolgsgarantie Benutzer: Möchte eine Sequenz (Sequence) über das GUI hinzufügen, bearbeiten oder löschen. Die manipulierte Sequenz wird gespeichert oder entfernt. Erfolgsszenario 1. Der Benutzer führt die Sequenz-Hinzufügen Operation aus. 2. Das System stellt die Erstellungsmöglichkeiten für eine Sequenz dar. 3. Der Benutzer tätigt die Einstellungen. 4. Das System fügt die neue Sequenz hinzu. Erweiterungen *a. {jederzeit nach 1} 1. Der Benutzer bricht ab. 1a. Der Benutzer löscht eine Sequenz: 1. Der Benutzer selektiert die Sequenz und führt die Lösch-Operation aus. 2. Das System fragt für das Endgültige löschen nach. 3. Der Benutzer bestätigt. a. Der Benutzer bricht die Aktion durch nicht bestätigen ab. -> UC Abbruch 4. Das System löscht die Sequenz. a. Das System kann die Sequenz nicht löschen-> UC Abbruch 2a: Der Benutzer bearbeitet eine Sequenz: 1. Der Benutzer selektier die Sequenz und führt die Bearbeiten- Operation aus. 2. Das System stellt ihm die Bearbeitungsmöglichkeiten dar. 3. Der Benutzer tätigt die Einstellungen. 4. Das System übernimmt die Einstellungen. Spezielle Anforderungen Zahlenbereich ist begrenzt und darf nicht unter und überschritten werden. Auftrittshäufigkeit Beliebig oft UC06: Merge Column Systemgrenzen SQuirreL DB Refactoring: Refactoring Plugin 30 / 96

31 Übersicht Der Benutzer kann Kolonnen zusammenlegen (vereinigen). Interessengruppe Erfolgsgarantie Erfolgsszenario Benutzer: Möchte zwei Kolonnen und deren Werte über das GUI zu einer Kolonne vereinen. Die neuen Kolonnen werden erstellt und deren Werte der alten Kolonnen aufgefüllt. 1. Der Benutzer führt die Kolonnen zusammenlegen Operation aus. 2. Das System stellt die möglichen zusammenlegen Optionen dar. 3. Der Benutzer tätigt die Einstellungen und wählt die Kolonnen aus. 4. Das System fügt die neuen Kolonnen zusammen. Erweiterungen *a. {jederzeit nach 1} 1. Der Benutzer bricht ab. 4a. Das System kann die Kolonnen nicht zusammenfügen. 1. System generiert eine Meldung. 2. System bricht Operation ab und tätigt ein Rollback. -> UC Abbruch Spezielle Anforderungen - Auftrittshäufigkeit Beliebig oft UC07: AD Foreign Key Systemgrenzen SQuirreL DB Refactoring: Refactoring Plugin Übersicht Interessengruppe Der Benutzer kann einen Fremdschlüssel zu einer Tabelle hinzufügen oder löschen. Benutzer: Möchte einen Fremdschlüssel hinzufügen oder löschen. Erfolgsgarantie Erfolgsszenario Der Fremdschlüssel ist entweder auf der Datenbank gelöscht oder hinzugefügt worden. 1. Der Benutzer selektiert die Tabelle. 2. Der Benutzer führt die Fremdschlüssel-hinzufügen Operation aus. 3. Das System stellt die Erstellungsmöglichkeiten für einen Fremdschlüssel dar. 4. Der Benutzer tätigt die Einstellungen. 5. Das System fügt den neuen Fremdschlüssel hinzu. Erweiterungen *a. {jederzeit nach 1} 1. Der Benutzer bricht ab. 2a. Der Benutzer löscht einen Fremdschlüssel: 1. Der Benutzer wählt den Fremdschlüssel aus und führt die Lösch- 31 / 96

32 Operation aus. 2. Das System fragt für das Endgültige löschen nach. 3. Der Benutzer bestätigt. a. Der Benutzer bricht die Aktion durch nicht bestätigen ab. -> UC Abbruch 4. Das System löscht den Fremdschlüssel. a. Das System kann den Fremdschlüssel nicht löschen. -> UC Abbruch Spezielle Anforderungen - Auftrittshäufigkeit Beliebig oft UC08: AD Primary Key Systemgrenzen SQuirreL DB Refactoring: Refactoring Plugin Übersicht Interessengruppe Der Benutzer kann einen Primärschlüssel zu einer Tabelle hinzufügen oder löschen. Benutzer: Möchte einen Primärschlüssel hinzufügen oder löschen. Erfolgsgarantie Erfolgsszenario Der Primärschlüssel ist entweder auf der Datenbank gelöscht oder hinzugefügt worden. 1. Der Benutzer selektiert die Tabelle. 2. Der Benutzer führt die Primärschlüssel-hinzufügen Operation aus. 3. Das System stellt die Erstellungsmöglichkeiten für einen Primärschlüssel dar. 4. Der Benutzer tätigt die Einstellungen. 5. Das System fügt den neuen Primärschlüssel hinzu. Erweiterungen *a. {jederzeit nach 1} 1. Der Benutzer bricht ab. 2a. Der Benutzer löscht einen Primärschlüssel: 1. Der Benutzer wählt den Primärschlüssel aus und führt die Lösch- Operation aus. 2. Das System fragt für das Endgültige löschen nach. 3. Der Benutzer bestätigt. a. Der Benutzer bricht die Aktion durch nicht bestätigen ab. -> UC Abbruch 4. Das System löscht den Primärschlüssel. a. Das System kann den Fremdschlüssel nicht löschen. -> UC Abbruch Spezielle Anforderungen Die Referenzielle Integrität muss beachtet und darf nicht verletzt werden. 32 / 96

33 Auftrittshäufigkeit Beliebig oft UC09: Add Lookup Table Systemgrenzen SQuirreL DB Refactoring: Refactoring Plugin Übersicht Interessengruppe Der Benutzer kann eine Lookup Tabelle aus einem Aufzähltyp oder einer DOMAIN hinzufügen. Benutzer: Möchte einen neuen Lookup Tabelle hinzufügen. Erfolgsgarantie Erfolgsszenario Alle Werte müssen aus den Domain/Aufzähltypen müssen in die Lookup Tabelle übernommen werden. 1. Der Benutzer selektiert die Tabelle. 2. Der Benutzer führt die Lookup Tabelle extrahieren Operation aus. 3. Das System stellt die Extrahierungsmöglichkeiten für eine Lookup Tabelle dar. 4. Der Benutzer tätigt die Einstellungen. 5. Das System fügt die neue Lookuptabelle hinzu. Erweiterungen *a. {jederzeit nach 1} 1. Der Benutzer bricht ab. 5a. Das System kann die Operation nicht ausführen: 1. Das System generiert eine Meldung an den Benutzer. 2. Die Operation wird abgebrochen und das System tätigt ein Rollback -> UC Abbruch Spezielle Anforderungen - Auftrittshäufigkeit Beliebig oft UC10: AD NOT-NULL Condition Systemgrenzen SQuirreL DB Refactoring: Refactoring Plugin Übersicht Interessengruppe Der Benutzer kann eine NOT-NULL Beschränkung für eine Spalte hinzufügen oder entfernen. Benutzer: Möchte einen Not-Null Beschränkung hinzufügen oder löschen. Erfolgsgarantie Der Beschränkung muss auf der Datenbank hinzugefügt oder gelöscht worden sein. 33 / 96

34 Erfolgsszenario 1. Der Benutzer selektiert die Tabelle. 2. Der Benutzer führt die Not-Null Constraint Operation aus. 3. Das System stellt die Erstellungsmöglichkeiten für eine Not-Null Constraint Operation dar. 4. Der Benutzer tätigt die Einstellungen. 5. Das System fügt die Beschränkung hinzu. Erweiterungen *a. {jederzeit nach 1} 1. Der Benutzer bricht ab. 2a. Der Benutzer löscht eine Not-Null Constraint: 1. Der Benutzer wählt die Not-Null Constraint aus und führt die Lösch- Operation aus. 2. Das System fragt für das Endgültige löschen nach. 3. Der Benutzer bestätigt. a. Der Benutzer bricht die Aktion durch nicht bestätigen ab. -> UC Abbruch 4. Das System löscht die Not-Null Constraint. a. Das System kann die Constraint nicht löschen. b. Das System generiert eine Fehlermeldung -> UC Abbruch Spezielle Anforderungen - Auftrittshäufigkeit Beliebig oft UC11: AD UNIQUE Condition Systemgrenzen SQuirreL DB Refactoring: Refactoring Plugin Übersicht Interessengruppe Der Benutzer kann eine UNIQUE Beschränkung für eine Spalte hinzufügen oder entfernen. Benutzer: Möchte einen UNIQUE Beschränkung hinzufügen oder löschen. Erfolgsgarantie Erfolgsszenario Der Beschränkung muss auf der Datenbank hinzugefügt oder gelöscht worden sein. 1. Der Benutzer selektiert die Tabelle. 2. Der Benutzer führt die Unique Constraints Operation aus. 3. Das System stellt die Erstellungsmöglichkeiten für eine Unique Constraint Operation dar. 4. Der Benutzer tätigt die Einstellungen. 5. Das System fügt die Beschränkung hinzu. Erweiterungen *a. {jederzeit nach 1} 1. Der Benutzer bricht ab. 34 / 96

35 2a. Der Benutzer löscht eine Unique: 1. Der Benutzer wählt die Unique Constraint aus und führt die Lösch- Operation aus. 2. Das System fragt für das Endgültige löschen nach. 3. Der Benutzer bestätigt. a. Der Benutzer bricht die Aktion durch nicht bestätigen ab. -> UC Abbruch 4. Das System löscht die Unique Constraint. a. Das System kann die Constraint nicht löschen. b. Das System generiert eine Fehlermeldung. Spezielle Anforderungen - Auftrittshäufigkeit Beliebig oft UC12: AD AUTO-INCREMENT Condition Systemgrenzen SQuirreL DB Refactoring: Refactoring Plugin Übersicht Interessengruppe Erfolgsgarantie Erfolgsszenario Der Benutzer kann eine AUTO-INCREMENT Beschränkung für eine Spalte hinzufügen oder entfernen. Benutzer: Möchte einen AUTO-INCREMENT Beschränkung hinzufügen oder löschen. Der Beschränkung muss auf der Datenbank hinzugefügt oder gelöscht worden sein. 1. Der Benutzer selektiert die Tabelle. 2. Der Benutzer führt die Auto-Increment Operation aus. 3. Das System stellt die Erstellungsmöglichkeiten für eine Auto-Increment Operation dar. 4. Der Benutzer tätigt die Einstellungen. 5. Das System fügt die Beschränkung hinzu. Erweiterungen *a. {jederzeit nach 1} 1. Der Benutzer bricht ab. 2a. Der Benutzer löscht eine Auto-Increment Constraint: 1. Der Benutzer wählt die Spalte aus und führt die Auto-Increment- Lösch-Operation aus. 2. Das System fragt für das Endgültige löschen nach. 3. Der Benutzer bestätigt. a. Der Benutzer bricht die Aktion durch nicht bestätigen ab. 4. Das System löscht die Auto-Increment Constraint. a. Das System kann die Constraint nicht löschen. 35 / 96

36 b. Das System generiert eine Fehlermeldung. -> UC Abbruch Spezielle Anforderungen - Auftrittshäufigkeit Beliebig oft UC13: AD Default Value Condition Systemgrenzen SQuirreL DB Refactoring: Refactoring Plugin Übersicht Interessengruppe Erfolgsgarantie Erfolgsszenario Der Benutzer kann ein DEFAULT Wert für eine Spalte hinzufügen oder löschen. Benutzer: Möchte einen DEFAULT Wert für eine Spalte hinzufügen oder löschen. Der Beschränkung muss auf der Datenbank hinzugefügt oder gelöscht worden sein. 1. Der Benutzer selektiert die Tabelle. 2. Der Benutzer führt die Default Wert Operation aus. 3. Das System stellt die Erstellungsmöglichkeiten für eine Default Wert Operation dar. 4. Der Benutzer tätigt die Einstellungen. 5. Das System fügt die Definition hinzu. Erweiterungen *a. {jederzeit nach 1} 1. Der Benutzer bricht ab. 2a. Der Benutzer löscht eine Default Wert: 1. Der Benutzer wählt die Spalte aus und führt die Default-Wert-Lösch- Operation aus. 2. Das System fragt für das Endgültige löschen nach. 3. Der Benutzer bestätigt. a. Der Benutzer bricht die Aktion durch nicht bestätigen ab. -> UC Abbruch 4. Das System löscht die Default-Wert Definition. a. Das System kann die Default-Wert Definition nicht löschen. b. Das System generiert eine Fehlermeldung. -> UC Abbruch Spezielle Anforderungen - Auftrittshäufigkeit Beliebig oft. 36 / 96

37 UC14: Execute VACUUM Systemgrenzen SQuirreL DB Refactoring: PostgreSQL Plugin Übersicht Interessengruppe Erfolgsgarantie Erfolgsszenario Der Benutzer kann bei einer oder mehrere Tabellen in einer PostgreSQL Datenbank die VACUUM Operation ausführen. Benutzer: Möchte die VACUUM Operation auf einer oder mehreren Tabellen in einer PostgreSQL Datenbank auslösen. Ein VACUUM muss auf der Datenbank durchgeführt worden sein und ein Ergebnisbericht wird dem Benutzer angezeigt. 1. Der Benutzer selektiert eine oder mehrere Tabellen oder ein Schema/Datenbank. 2. Der Benutzer wählt die VACUUM Operation aus. 3. Das System stellt die Optionen für die VACUUM Operation dar. 4. Der Benutzer selektiert die gewünschten Optionen. 5. Der Benutzer lässt die VACUUM Operation ausführen. 6. Das System führt die VACUUM mit den gegebenen Optionen aus. 7. Das System zeigt dem Benutzer das Resultat an. Erweiterungen *a. {jederzeit nach 1} 1. Der Benutzer bricht ab. Spezielle Anforderungen - Auftrittshäufigkeit Beliebig oft UC15: Execute EXPLAIN Systemgrenzen SQuirreL DB Refactoring: PostgreSQL Plugin Übersicht Interessengruppe Erfolgsgarantie Erfolgsszenario Der Benutzer kann bei einem SQL-Statement die EXPLAIN Operation ausführen. Benutzer: Möchte die EXPLAIN Operation bei einem SQL-Statement ausführen. Ein EXPLAIN muss auf der Datenbank durchgeführt worden sein und das Resultat wird dem Benutzer angezeigt. 1. Der Benutzer selektiert ein SQL-Statement. 2. Der Benutzer wählt die EXPLAIN Operation aus. 3. Das System stellt die Optionen für die EXPLAIN Operation dar. 4. Der Benutzer selektiert die gewünschten Optionen. 5. Der Benutzer lässt die EXPLAIN Operation ausführen. 6. Das System führt die EXPLAIN mit den gegebenen Optionen aus. 37 / 96

38 7. Das System stellt das Resultat der Operation dar. Erweiterungen *a. {jederzeit nach 1} 1. Der Benutzer bricht ab. Spezielle Anforderungen - Auftrittshäufigkeit Beliebig oft UC 16: Merge Table Systemgrenzen SQuirreL DB Refactoring: Refactoring Plugin Übersicht Interessengruppe Der Benutzer kann zwei Tabellen verbinden indem entweder eine neue erstellt oder eine bestehende ergänzt wird. Benutzer: Möchte zwei Tabellen über das GUI verbinden/vereinigen. Erfolgsgarantie Die zu verbindenden Kolonnen sind zusammen in einer Tabelle. Erfolgsszenario 1. Der Benutzer selektiert eine Tabelle. 2. Der Benutzer wählt Tabellen verbinden Operation aus. 3. Das System stellt die Erstellungsmöglichkeiten für das Verbinden der Tabellen dar. 4. Der Benutzer tätigt die Einstellungen. 5. Das System erstellt das Verbinden der Tabellen. Erweiterungen *a. {jederzeit nach 1} 1. Der Benutzer bricht ab. Spezielle Anforderungen Keine Auftrittshäufigkeit Beliebig oft Nicht-funktionale Anforderungen Im Folgenden werden die nicht funktionalen Anforderungen in Anlehnung an FURPS+ und ISO 9126 beschrieben. Sicherheit Passwörter oder sonstige Login-Daten dürfen nicht offen angezeigt werden, sondern müssen mit Sternchen oder desgleichen versteckt werden. Zudem dürfen diese nicht unverschlüsselt übertragen oder lokal gespeichert werden. Error Handling 38 / 96

39 Die Plugins müssen den Benutzer vor Fehlern schützen. Dies bedeutet, dass präventiv dem Benutzer nur das dargestellt / erlaubt wird, was ihm auch gestattet ist. (Fehlerprävention) Falls dennoch einen Fehler auftritt, wird dem Benutzer eine ausführliche Fehlermeldung angezeigt. Bedienbarkeit Die Bedienung der Plugins erfolgt mittels grafischer Oberfläche, diese muss selbsterklärend und intuitiv sein. Dies bedeutet, dass die verwendeten Begriffe und Operationen sich nicht von den Datenbankbegriffen unterscheiden. Sollte es dennoch vorkommen, dass ein neuer Begriff eingeführt werden muss, muss dieser in der Hilfedokumentation beschrieben werden. Die Lernzeiten für die Plugins müssen möglichst gering sein. Nachdem erstmaligen Benützen der Plugins sollte der Ablauf klar sein. Zuverlässigkeit Es wird eine 100% Verfügbarkeit, sowie eine 100% Kompatibilität zum SQuirreL SQL Client angestrebt. Der Benutzer muss jederzeit über den Status der Plugins (z.b. Operation in Arbeit) informiert sein. Leistung /Antwortzeit Wenn wir von Antwortzeit sprechen, meinen wir die Zeit bis eine Reaktion, nachdem ein Benutzer eine Eingabe getätigt hat, gezeigt wird. Wir streben eine Antwortzeit von weniger als einer Sekunde an. Eine Antwortzeit bis zu einer Sekunde kann von einem Benutzer gerade noch akzeptiert werden, ist sie jedoch länger wird der Benutzer sich irritiert fühlen. Wenn sie länger wäre, ist er sich nicht mehr sicher, ob die Aktion nun ausgelöst wurde oder nicht. Wartbarkeit Die Plugins müssen am Ende des Projektes in einer stabilen Form für den Benutzer zur Verfügung stehen. Durch den englischen developers guide und dem durchdachten Design sollten die Plugins auch für Erweiterungen einfach zugänglich sein. Es besteht die Möglichkeit ein Bugreport auf SourceForge.net einzugeben Schnittstellen Benutzer Als Benutzerschnittstelle dient ein graphisches User Interface, das einfach und intuitiv bedienbar sein muss. Die Eingaben werden über die Maus und die Tastatur getätigt. Hardware Die beiden normalen Schnittstellen Maus und Tastatur werden verwendet. Diese werden automatisch vom Betriebssystem konfiguriert und adressiert. Ansonsten werden keine weiteren Hardwareschnittstellen vorgesehen. Software Die einzigen Softwareschnittstellen ist diejenige zu Java 1.5 und zum SQuirreL SQL Client. Ansonsten sind keine weiteren Softwareschnittstellen vorgesehen. 39 / 96

40 Datenbank Die Datenbankschnittstelle wird nicht durch die Plugins realisiert, sondern wird vom SQuirreL SQL Client getätigt. Daher gibt es keine direkte Schnittstelle von den Plugins zu einer Datenbank. Kommunikation Die Kommunikation zwischen den Plugins und dem SQuirreL SQL Client wird vom Plugin Handler des SQuirreL SQL Clients gehandhabt Lizenzanforderungen Es werden keine Lizenzen für allfällige Klassenbibliotheken, Programmiersprachen oder Konzepte benötigt. Die Plugins stehen wie der SQuirreL SQL Client nach der Veröffentlichung (Integration in den SQuirreL SQL Client) unter der GNU Lesser General Public License. 40 / 96

41 8 Analyse In der Analyse haben wir uns mit dem bereits vorhandenen Code der beiden Plugins befasst. Dabei ging es darum die Struktur der Plugins und deren Zusammenspiel mit dem SQuirreL Framework herauszuarbeiten. Die Erweiterungen sollten so gut wie möglich in dieses Open Source Projekt eingefügt werden können. 8.1 Internationalisierung (i18n) Alle Beschriftungen, Fehlermeldungen und andere Texte werden in der Datei I18NStrings.properties gespeichert (maximal 1 pro Package): Syntax: [Klassenname].[Textkurzfassung]=Text{0}Text{1} ({0..n} sind Parameter) Beispiel: Shared.singleObjectMessage=You must have a single table selected in order to {0}. Für den Zugriff auf diese internationalisierten Texte stellt das Framework eine Factory zur Verfügung. Diese kann jede Klasse verwenden um einen StringManager für den Zugriff zu initialisieren: Initialisierung in jeder Klasse (falls i18n-strings benötigt): private static final StringManager s_stringmgr = StringManagerFactory.getStringManager([Klassenname].class); Aufrufen, Text auslesen: String msg = s_stringmgr.getstring("[klassenname].[textkurzfassung]", [ParameterObjectArray[]]); 8.2 Logging Für das Logging verwendet SQuirreL log4j und stellt auch hierfür eine Factory zur Verfügung: Definition in jeder Klasse (falls Logging benötigt): private final static ILogger log = LoggerController.createLogger([Klassenname].class); Verwendung: log.[kategorie]([nachricht]); (Kategorien: info, error, warn, debug) 41 / 96

42 9 Design & Implementation 9.1 Externes Design Der Aufbau aller Dialoge ist gleich. Jeder Dialog, welcher die SQL-Statements generiert, verfügt über ein Button Panel. Dieses befindet sich am unteren Rande des Dialogs und beinhaltet immer folgende Buttons: Execute um die SQL-Statements auszuführen Edit SQL um die SQL-Statements im Hauptfenster für das Editieren zu laden Show SQL um die SQL-Statements in einem neuen Dialog anzuzeigen Cancel um den Dialog abzubrechen und zu beenden Es gibt zwei Typen von Dialoge. Normale und solche mit mehreren Registerkarten (Tabs). Auf der Abbildung 4 sind die zwei Dialoge im Entwurf gezeigt. Abbildung 4: Entwurf der Dialogtypen 9.2 Refactoring Plugin Packages Das Refactoring Plugin besteht aus vier Packages und der Pluginklasse RefactoringPlugin, welche vom SQuirreL Framework zur Initialisierung des Plugins verwendet wird. Abbildung 5: Refactoring Plugin Package Übersicht 42 / 96

43 actions Das actions-package enthält alle Aktionen wie z.b. AddColumnAction, AddPrimaryKeyAction. Alle diese Actions erweitern dieselbe abstrakte Basisklasse AbstractRefactoringAction und sind durch das IObjectTreeAction Interface nur im ObjectTree Tab von SQuirreL ausführbar. Jede einzelne Aktion definiert in der Implementation der abstrakten Methoden, ob sie für mehrere oder ein einzelnes selektierte Objekt im ObjectTree ausgeführt werden kann. Zudem wird definiert, welcher Command für die Ausführung der Aktion aufgerufen werden soll commands Das commands-package enthält alle Befehle wie z.b. AddColumnCommand. Abbildung 6: refactoring: actions Package Abbildung 7: refactoring: commands Package Alle diese Befehle erweitern dieselbe abstrakte Basisklasse AbstractRefactoringCommand. Durch die abstrakte Basisklasse sind die Befehle gezwungen mehrere abstrakte Methoden zu implementieren. Über diese abstrakten Methoden delegiert die Basisklasse den Subklassen verschiedene Befehl-spezifische Aufgaben wie die Generierung der SQL-Statements, das Ausführen eines SQL-Scripts oder das Initialisieren des passenden Dialogs bei der Ausführung des Befehls gui Das gui-package enthält alle Dialoge für die einzelnen Refactorings wie z.b. AddIndexDialog. 43 / 96

44 Abbildung 8: refactoring: gui Package Alle Dialoge erweitern die abstrakten Basisklassen AbstractRefactoringDialog für normale Dialoge oder AbstractRefactoringTabbedDialog für Dialoge mit mehreren Tabs. Die abstrakten Basisklassen stellen einen leeren JDialog mit dem standardmässigen ButtonPanel zur Verfügung, den die konkreten Dialoge mit Refactoring-spezifischen Elementen erweitern hibernate Das hibernate-package enthält alle HibernateDialects-Erweiterungen wie z.b. PostgreSQLDialectExtension oder das Interface HibernateDialectExtension. Die HibernateDialects dienen zur Datenbank-spezifischen Generierung von SQL-Statements und bieten eine Vielzahl von Methoden wie z.b. getaddindexsql, getinsertintosql. Zudem enthält das Package Hilfsklassen die zur Statement-Generierung verwendet werden Sequenzdiagramme / Zusammenspiel der Packages Die folgenden Sequenzdiagramme zeigen das Zusammenspiel der einzelnen Packages und Klassen des Refactoring Plugins. 44 / 96

45 Refactoring in SQuirreL einfügen Dieses Sequenzdiagramm beschreibt das Einfügen eines Refactorings in den SQuirreL SQL Client. Abbildung 9: Refactoring in SQuirreL SQL Client einfügen Die Einstiegsstelle für jedes Refactoring ist ein Menüeintrag und die damit verbundene Aktion. Daher müssen die Action-Klassen aller Refactorings im SQuirreL SQL Client eingebaut und registriert werden. 1. Bei der Initialisierung des RefactoringPlugins (SQuirreL Start) werden die Aktionen aller Refactorings (AddIndexAction, etc.) in die ActionCollection der SQuirreL Applikation geschrieben. Dies dient dazu die Aktionen, je nach Fenster oder Tab das gerade in SQuirreL geöffnet ist, zu aktivieren oder deaktivieren. 2. Danach wird jedesmal, wenn eine neue Session gestartet wird, die Menüstruktur mit den zuvor registrierten Aktionen als Menüeinträge aufgebaut. 3. Die Menüs werden anschliessend mit addtopopup(databaseobjecttype, JMenu) den Kontextmenüs der verschiedenen Knotentypen des ObjectTree s angehängt. 45 / 96

46 Refactoring Dialog öffnen Dieses Sequenzdiagramm beschreibt, was passiert wenn ein Refactoring in einem Menu des SQuirreL SQL Clients selektiert wird und sich der Refactoring Dialog öffnet. Abbildung 10: Refactoring Dialog öffnen 1. Klickt ein Benutzer (z.b. in einem Menü) auf ein Refactoring wird deren Action-Klasse aufgerufen. Diese holt sich ein Array mit allen selektieren DatabaseObjects (Knoten und Blätter im ObjectTree). 2. Anschliessend wird eine neue Instanz der Command-Klasse des Refactorings instantziert und mit execute ausgeführt. Bei execute handelt es sich um eine Methode von AbstractRefactoringCommand, die über die DialectFactoryExtension den passenden HibernateDialect besorgt und allfällige Exceptions behandelt. 3. Nach allfälligen anderen Überprüfungen (z.b. ob eine Tabelle, Sequenz oder View selektiert wurde) und Abfragen (z.b. Dialog zur Selektion einer Spalte) wird der eigentliche Refactoring Dialog instanziiert. 4. Beim Dialog setzt der Command noch eigene Listener für die Execute, Edit SQL und Show SQL Buttons auf und zeigt den Dialog an. (Falls kein spezielles Verhalten benötigt wird, werden als Listener die der Basisklasse AbstractRefactoringCommand verwenden.) 46 / 96

47 Refactoring SQL-Script ausführen Dieses Sequenzdiagramm zeigt den Ablauf, wenn in einem Refactoring Dialog der Execute Button gedrückt wird um die SQL-Statements des Refactoring auszuführen. Abbildung 11: Refactoring ausführen - execute Button betätigen 1. Klickt der Benutzer in einem Refactoring Dialog auf den Execute-Button, wird (normalerweise) der ExecuteListener (Inner Class des AbstractRefactoringCommands) aufgerufen. 2. Der Listener ruft die getsqlstatements Methode auf, welche dafür sorgt, dass die eigentliche Generierung des SQL-Statements (generatesqlstatements Methode) nicht im GUI-Thread sondern in einem separaten Thread des ThreadPools ausgeführt wird. 3. In der Refactoring-spezifischen Statement-Generierung werden die Einstellungen des Benutzers aus dem Dialog gelesen und verarbeitet. 4. Zur eigentlichen Generierung der SQL-Statements ruft der Command die passenden Methoden der HibernateDialectExtension auf, diese liefert dann die Datenbank-spezifischen Statements. 5. Sind alle benötigten Statements zusammen, wird das Resultat an den ExecuteListener über die Methode finished zurück gegeben. (Listener implementieren SQLResultListener) 6. Dort werden die Statements korrekt aufbereitet und wieder dem Command zur Ausführung übergeben. 7. Der Command kann somit selber bestimmen, wie die Statements ausgeführt werden sollen. Vor allem welcher ExecutionHandler dem SQLExecutorTask übergeben werden soll um auf die Ereignisse bei der Ausführung der SQL-Statements z.b. mit einem ProgressDialog oder einem Transaction-Rollback im Fehlerfall zu reagieren. 47 / 96

48 9.3 Postgres Plugin Für die Implementation der vacuum Funktion wurde das fast identische Action/Command/GUI- Konzept des Refactoring Plugins verwendet. Die einzige Ausnahme ist lediglich das fehlende Exception-Handling im AbstractPostgresCommand und es muss kein HibernateDialect über eine Factory initialisiert werden, da direkt Postgres-spezifisches SQL von Hand geschrieben werden kann. Eine genauere Beschreibung des Action/Command/GUI-Konzepts ist im Kapitel 9.2 Refactoring Plugin zu finden Packages In der Abbildung 12 sind nur die Packages zu sehen, die mit einer der beiden Funktionen VACUUM oder EXPLAIN etwas zu tun haben. Alle anderen Packages sind Teil der früheren Implementation des Plugins und wurden nicht dargestellt. Abbildung 12: Postgres Plugin Package Übersicht Actions Abbildung 13: postgres: actions Package 48 / 96

49 9.3.3 commands handler Im Package handler befinden sich spezielle SQLExecutionHandler die von beiden vacuum Commands bei der Ausführung der SQL- Statements verwendet werden. Der ProgressSQLExecutionHandler benutzt einen ProgressCallbackDialog um den Fortschritt der SQL-Ausführung darzustellen. Der MessageSQLExecutionHandler zeigt ebenfalls einen Fortschrittsdialog an, füllt aber zusätzlich noch einen MessageDialog Abbildung 14: postgres: commands Package mit allen Warnungen, die die Datenbank bei Abbildung 15: execution handler der Ausführung zurückgibt. (Bei vacuum Statements sind das nützliche Informationen zum Fragmentierungszustand einer betroffenen Tabelle.) 49 / 96

50 9.3.4 gui Abbildung 16: postgres: gui Package explain Das explain Package beinhaltet alle Klassen für die explain Funktion. Abbildung 17: postgres: explain Package Das ExplainExecuterPanel implementiert einen ISQLResultExecuter der im SQL Panel von SQuirreL mit addexecutor angehängt werden kann. (Dies geschieht beim Start einer Session und jedesmal wenn ein weiteres SQL Panel geöffnet wird.) Der SQLExecutionHandler ist eine innere Klasse des Panels und wird bei der Ausführung eines explain Statements dem SQLExecuterTask mitgegeben. Es sorgt dafür, das bei jedem Resultat (ein Query Plan) ein neuer ExplainTab dem Panel hinzugefügt wird. Die ExplainTabs zeigen den Query Plan eines Select-Statements in einer Tabelle an. 50 / 96

51 9.3.6 Sequenzdiagramme / Zusammenspiel der Packages Die folgenden Sequenzdiagramme zeigen das Zusammenspiel der einzelnen Packages und Klassen des Postgres Plugins Query Plan eines Statements abfragen Abbildung 18: Query Plan abfragen 1. Wird im SQLPanel ein Statement ausgeführt und ist der ExplainExecuterPanel als Executor ausgewählt, wird der Explain Executer ausgeführt. 2. Über das ISQLEntryPanel beschafft sich der Executer die auszuführenden SQL-Statements und generiert für jedes das entsprechende explain Statement. 3. Zur Ausführung werden die Statements zusammen mit einem eigenen Handler einem SQLExecuterTask übergeben und dieser asynchron in einem separaten Thread im ThreadPool ausgeführt. 4. Für jedes ResultSet, das die Datenbank zurück gibt, wird ein neuer ExplainTab mit den ResultSet-Informationen erstellt und im ExplainExecuterPanel in ein TabbedPane eingefügt. 5. Der Benutzer sieht nun einen neuen Tab mit einer Tabelle die den Query Plan des ausgeführten Statements anzeigt. 51 / 96

52 10 Tests 10.1 Technologie Die Funktionalität der Klassen, welche SQL-Statements generieren, wurde mit JUnit Tests verifiziert. Da die Plugins an vielen Stellen das Framework verwenden und dies keine funktionierenden Mock- Objekte zur Verfügung stellt, konnten keine weitere Funktionalität automatisch verifiziert werden. Die restliche Funktionalität wurde mit manuellen Tests geprüft (Use Cases Tests) Automatische Tests Die automatischen Tests wurden mit JUnit durchgeführt. Abbildung 19 und Abbildung 20 sind Screenshots aus IntelliJ IDEA, welche nach der Testdurchführung erstellt wurden. Erstere gibt einen Überblick über die Tests und die zweite zeigt die getesteten Methoden auf. Abbildung 19: Testauswertung Übersicht Abbildung 20: Testauflistung und Auswertung 10.3 Manuelle Tests Use Case Tests Jegliche nicht automatisierten Tests werden von Daniel Regli durchgeführt. Als Testszenarien dienen die definierten Use Cases. 52 / 96

53 Das Feld über jedem Test zeigt an, ob der ganze Use Case Test erfolgreich war oder nicht. Die rote Bar besagt, dass einer der Test nicht korrekt abgelaufen ist. Bei einer grünen Bar sind alle Tests erfolgreich abgelaufen Test Setup Für die Durchführung der Tests wurde folgende Konfiguration verwendet. Betriebssystem Windows XP Home Edition (5.1 Build 2600) Java Version Java SE Runtime Environment Build 1.6.0_02 SQuirreL SQL Client Version PostgreSQL JDBC Treiber PostgreSQL 8.3devel JDBC4 with SSL (build 601) PostgreSQL Datenbank Server Version Postgres Plugin Version 0.20 Refactoring Plugin Version 0.20 Tabelle 3: Konfiguration für Test Testdatenbank Das auf Abbildung 21 sichtbare ERM stellt die Testdatenbank dar. Es ist eine einfache ABC-Datenbank ohne Logik. Sie beinhaltet alle Elemente, welche zum Testen benötigt werden. Abbildung 21: Testdatenbank ERM Diagramm Das DDL- und Insert-Script für die Testdatenbank ist im Anhang in Kapitel 17 und auf der CD zu finden UC01: ACD Table Funktionsbeschreibung OK NOK Tabelle kann umbenennt werden 53 / 96

54 Tabelle kann gelöscht werden Optionen: ohne Cascade Tabelle kann gelöscht werden Optionen: mit Cascade UC02: ACD View Funktionsbeschreibung OK NOK View kann umbenennt werden View kann gelöscht werden Optionen: ohne Cascade View kann gelöscht werden Optionen: mit Cascade View kann hinzugefügt werden Optionen: Name, Check Option, Definition UC03: ACD Column Funktionsbeschreibung OK NOK Kolonne einer Tabelle kann gelöscht werden Kolonne einer Tabelle kann geändert werden Optionen: Name, Typ, Länge, Default Wert, Nullwerte, Kommentar Neue Kolonne kann einer Tabelle hinzugefügt werden Optionen: Name, Typ, Länge, Default Wert, Nullwerte, Kommentar UC04: AD Index Funktionsbeschreibung OK NOK Index kann gelöscht werden Index kann hinzugefügt werden Optionen: Name, Tablespace, Zugriffs Methode, Kolonne(n), Constraint, Unique UC05: ACD Sequence 54 / 96

55 Funktionsbeschreibung OK NOK Sequence kann gelöscht werden Sequence kann hinzugefügt werden Sequence kann geändert werden Optionen: Erhöhungsschritt, Restart/Minium/Maximum Wert, Cache, Cycled UC06: Merge Column Funktionsbeschreibung OK NOK Zwei Kolonnen können zusammengelegt (merge) werden Optionen: Kolonne 1, Kolonne 2, in bestehende Kolonne / neue Kolonne zusammenlegen, Verbindungs-String UC07: AD Foreign Key Funktionsbeschreibung OK NOK Fremdschlüssel kann hinzugefügt werden Optionen: Name, Referenzierungstabelle, Deferrable, Match Full, Index, Kolonnen, on Delete / on Update Action Fremdschlüssel kann gelöscht werden Optionen: mit Cascade Fremdschlüssel kann gelöscht werden Optionen: ohne Cascade UC08: AD Primary Key Funktionsbeschreibung OK NOK Primärschlüssel kann hinzugefügt werden Optionen: Kolonnenauswahl Primärschlüssel kann gelöscht werden UC09: Add Lookup Table Funktionsbeschreibung OK NOK 55 / 96

56 Lookup Tabelle generieren Optionen: Kolonnen, Fremdschlüssel, Inhalt von der Kolonne behalten als Referenz, Integer Wert als Referenz (Originalkolonne löschen ja/nein), neuer Tabellennamen, Kolonnenname UC10: AD NOT-NULL Condition Funktionsbeschreibung OK NOK Kolonne einer Tabelle kann geändert werden Optionen: Name, Typ, Länge, Default Wert, Nullwerte, Kommentar UC11: AD UNIQUE Condition Funktionsbeschreibung OK NOK Unique Constraint kann hinzugefügt werden Optionen: Name, Kolonnen Unique Constraint kann gelöscht werden UC12: AD AUTO-INCREMENT Condition Funktionsbeschreibung OK NOK Auto-Increment kann zu einer Kolonne hinzugefügt werden Auto-Increment kann gelöscht werden (über Modify Column Dialog, Default Wert ändern. nextval( sequence ) löschen Optionen: Default Wert UC13: AD Default Value Condition Funktionsbeschreibung OK NOK Kolonne einer Tabelle kann geändert werden(über Modify Column Dialog, Default Wert ändern) Optionen: Default Wert UC14: Execute VACUUM Funktionsbeschreibung OK NOK 56 / 96

57 VACUUM kann auf Tabelle ausgeführt werden Optionen: Name, Typ, Länge, Default Wert, Nullwerte, Kommentar VACUUM kann auf die ganze Datenbank ausgeführt werden Optionen: FULL, ANALIZE UC15: Execute EXPLAIN Funktionsbeschreibung OK NOK EXPLAIN kann auf Select Statement ausgeführt werden Option: mit folgenden Statement: SELECT * FROM test.table_c, test.table_e, test.table_d WHERE c_ca = e_fk_ca AND c_cb = e_fk_cb AND c_da = e_fk_da EXPLAIN kann nicht auf andere Statements (INSERT, UPDATE, DELETE, etc.). Eine Fehlermeldung wird ausgegeben UC 16: Merge Table Funktionsbeschreibung OK NOK Merge Table auf Tabellen anwenden Optionen: Zweite Tabelle, Merge Data, Verbindungsschlüsselpaare, Kolonnen für das verbinden 10.4 Abweichungen 10.5 Nicht berücksichtigte Punkte Einige Spezialfälle aus den Use Cases wurden nicht berücksichtigt. Diese sind nicht in den Use Cases beschrieben oder sind nicht als Anforderung aufgelistet ACD Table Eine neue Tabelle kann nicht erstellt werden. Die Anforderungen haben während der Projektdauer geändert und diese Funktion wurde weggelassen ACD View Postgres unterstützt in der getesteten Version den SQL Zusatz WITH CHECK OPTION nicht ACD Column Die Definition einer Kolone kann bei gewissen Datentypen nur Teils geändert werden. Der Scale Wert wird z.b. bei Numeric nicht übernommen. Das Problem liegt nicht am Plugin sondern am Framework (HibernateDialects), welches nicht geändert werden kann. 57 / 96

58 Merge Column Es findet keine Überprüfung der Datentypverträglichkeit statt. Es wird der Datentyp der Kolonne verwendet, in welche zusammengefasst wird. Beim Zusammenfassen in eine neue Kolonne wird als Typ ein Varchar mit der Länge des grössten Datensatzes gewählt Ad AUTO-INCREMENT Condition Es wird nicht direkt ein Dialog zum Löschen des Auto-Increment zur Verfügung gestellt. Da in PostgreSQL Auto-Increment mit einer Sequenz und dem Default Value next_val( sequenz ) hat man indirekt die Möglichkeit das Auto-Increment zu löschen. Dies indem man den Default Value und die Sequenz löscht Merge Table Bei der Quelltabelle von welcher die Kolonnen kopiert und in die Zieltabelle eingefügt werden, werden die not-null Constraints, sowie alle Indexe oder Unique Constraints gelöscht Testfazit Alle Tests sind erfolgreich abgelaufen und können zu jederzeit erfolgreich wiederholt werden. 58 / 96

59 11 Weiterentwicklung 11.1 Möglichkeiten der Weiterentwicklung Wie schon im Kapitel 2.4 Ausblick erwähnt, gibt es viele Möglichkeiten die Plugins zu erweitern. Wir gehen in diesem Abschnitt auf die technischen Möglichkeiten und die nötigen Schritte ein Refactoring Plugin Datenbankdialekte erweitern Es wäre sinnvoll die jetzige Funktionalität der Refactoring, welche nur gerade auf PostgreSQL Datenbanksystem funktionieren, für die restlichen Datenbankdialekte zu implementieren. Die Erweiterung wurde von uns vorbereitet. Es könnte eine neue Klasse xyzdialectextension erstellt werden, welche das Interface IHibernateDialectExtension implementiert. Diese Methoden müssten für den Dialekt ausprogrammiert werden. Nachdem dies getan wurde, muss noch eine Änderung in der bestehenden Klasse DialectFactoryExtension gemacht werden. Es muss der Klasse mitgeteilt werden, dass es nun einen weiteren Dialekt kennt. Weitere Refactorings Man könnte sich vorstellen weitere Refactoring-Funktionen von dem Buch Refactoring Databases: Evolutionary Database Design [RD06] zu implementieren. Für jede zusätzliche Refactoring Funktion müssten folgenden Klassen hinzugefügt werden: [Funktionsname]Action Klasse (erbt von AbstractRefactoringAction) [Funktionsname]Command Klasse (erb von AbstractRefactoringCommand) Dialog-Klasse, welche die Benutzeroberfläche für die Konfiguration darstellt Zudem müssten in folgenden Klassen Änderungen gemacht werden: RefactoringPlugin Klasse o Neue Action bei der Action Collection registrieren und an als Menueintrag in den Object Tree hinzufügen IHibernateDialectExtension Interface, welches die verwendeten SQL-Generierung-Methoden definiert o In allen xyzdialectextension Klassen diese implementieren Vorschau Funktion Da wir diese Erweiterung noch nicht speziell vorbereitet haben, können wir auch keine konkrete Vorgehensweise abgeben. Es würde Sinn machen das Ganze von dem bestehenden entkoppelt zu implementieren. Eine andere Variante wäre es in die xyzcommand Klassen hinein zu nehmen, was jedoch den Software Engineering Prinzipien widersprechen würde. Der Ansatz die Funktionalität in einem eigenen Package zu entwickeln wäre sinnvoller. Möglicherweise reicht es schon, wenn man die Eingaben des Benutzers direkt mittels Hilfsmethoden von den GUI Klassen holen und separat verarbeiten würde. 59 / 96

60 Testen Ein wichtiger Aspekt ist auch das automatische Testen. Wir haben für unsere SQL-Generierungs- Klasse ein JUnit Test erstellt. Um die weiteren Dialekte auf ihre generierten SQL-Statements zu testen, muss die eigene Testklasse von der AbstractDialectExtensionTest Klasse erben. Die geerbten Methoden müssen danach noch ausprogrammiert und können dann mit JUnit ausgeführt werden Postgres Plugin Grafischer Query Plan Eine Erweiterung für das Postgres Plugin wäre anstatt der textuellen Anzeige des Query Plans eine grafische Darstellung. Es folgt nun eine grobe Beschreibung für eine mögliche Implementation. Die Resultate (ResultSet s), welche von den Anfragen zurück gegeben werden, könnten in der Klasse ExplainExecutorPanel geparst werden. Dieser könnte die neue Anzeige Klasse ExplainTabGraphical (müsste noch erstellt werden und sollte die Darstellung beinhalten) instanziieren und als neue Registerkarte hinzufügen. Weitere Funktionen Weitere spezifische PostgreSQL Funktionen könnten wie die vacuum Funktion implementiert werden (mit dem Action, Controller, GUI Aufteilungsprinzip). 60 / 96

61 12 Projektmanagement 12.1 Projektorganisation Das Projektteam besteht aus zwei Personen. Jede Person übernimmt einen oder mehrere Teilbereiche des Projekts. Die Zuständigkeiten der Teammitglieder werden jeweils vor der nächsten Iteration zum Zeitpunkt der Iterationsplanung verteilt. Zusätzlich steht dem Projekt ein Dozent als Betreuer zur Seite Organisationsstruktur Projektmitglieder: Betreuer: DR / Daniel Regli (dregli@hsr.ch) YW / Yannick Winiger (ywiniger@hsr.ch) SK / Prof. Steffan Keller (sfkeller@hsr.ch) Externe Schnittstelle Als externe Schnittstelle dienen der Betreuer des Projektes, sowie die Open-Source Community von SQuirreL SQL Client Management Abläufe Aufwand Der Zeitaufwand beträgt zwischen Stunden pro Projektmitglied. (12-16 h/woche) Das Projekt startet am und endet am (14 Wochen) Die Arbeitszeit pro Woche kann variieren, am Ende des Projekts sollte der gesamte Zeitaufwand jedoch in dem besagten Rahmen liegen Zeitplan Für den detailierten Zeitplan verweisen wir auf das Dokument Zeitplan.pdf auf der CD Meilensteine Datum Bezeichnung Kurzbeschreibung MS1 End of Inception Initialisierung des Projektes Anforderungsspezifikation und Projektplan MS2 Design-Entwurf Design-Entwurf MS3 End of Elaboration Architekturprototyp MS4 End of Construction Fertigstellung der beiden Plugins MS5 Abgabe Abgabe der Schlussdokumentation Phasen-/Iterationsplanung Inception Dauer Ziele Initialisierung des Projektes, sowie die Anforderungsspezifikation und den Projektplan erstellen. Arbeitspakete Einarbeitung & Setup Projektplanung 61 / 96

62 Artefakte Meilensteine Zeitplanung Spezifikation Use Cases brief Anforderungsspezifikation Projektplan Zeitplan MS1 (Markiert den Abschluss dieser Phase) ( ) ( ) ( ) Elaboration (1. Iteration) Dauer Ziele Analyse in die bestehende Codestruktur und der neuen Anforderungen, sowie der Entwurf eines Designs. Arbeitspakete Use Cases fully dressed Analyse Diagramme Design Diagramme Artefakte Use Cases fully dressed Design Model ( ) ( ) Meilensteine MS2 (Markiert den Abschluss dieser Phase) Elaboration (2. Iteration) Dauer Ziele Umsetzung des Design-Entwurfs und die komplette Implementation einiger Funktionen der Plugins. Arbeitspakete Design Diagramme Implementation: PostgreSQL Plugin Prototyp Implementation: Refactoring Plugin Prototyp Artefakte Architekturprototyp der Plugins ( ) Meilensteine MS3 (Markiert den Abschluss dieser Phase) Construction Dauer Ziele Implementation aller Anforderungen an die Plugins. Arbeitspakete Implementation: PostgreSQL Plugin Implementation: Refactoring Plugin Tests Artefakte Funktional vollständige Version der Plugins ( ) Meilensteine MS4 (Markiert den Abschluss dieser Phase) Transition Dauer Ziele Test der Plugins, Abschluss des Projekts, Integration der geleisteten Arbeit in das SQuirreL Open-Source Projekt. Arbeitspakete Tests Schlussdokumentation Plugin-Beschreibungen Artefakte Finale Version der Plugins ( ) 62 / 96

63 Meilensteine Plugin-Beschreibungen Schlussdokumentation MS5 (Markiert den Abschluss dieser Phase) ( ) ( ) 63 / 96

64 12.3 Risiko Management Risk Cost Summary (Summary of all Risk Costs) Risiko Analyse Projektnahme: Team Squirrel DB Refactoring Daniel Regli Yannick Winiger Datum: Risiken Strategy Risiko Bezeichnung Beschreibung Maximaler Wahrscheinlichkeit Gewichteter Massnahmen Massnahmen Dauer von ID Schaden (h) in % Schaden (h) zur Verhinderung bei Eintritt Massnahmen (h) R01 Planungsfehler Die geplanten Reserven reichen bei weitem nicht aus % 2 Sorgfältige Planung, genügend Reserven einplanen Projektumfang verkleinern 1 R02 Datenverlust Teile oder Ganzes des Erschaffenen geht verloren % 10 Lokale Kopie auf jedem Notebook, Lokale Sicherung des SVN Servers (sofern möglich) Aufsetzen eines neuen CVS Projekts; Rückspielung von Backup (sofern möglich) 2 64 / 96

65 R03 Ausfall von Teammitglied Unvorsehener Verlust von Arbeitsstunden durch Ausfall eines Teammitgliedes % 10 kaum Möglichkeiten (Krankheit früh erkennen und warnen); Zeitreserven einplanen Umverteilung der Arbeit auf andere Mitglieder; Projektumfang anpassen 2 R04 Erreichbarkeit von SVN Server unzureichend Der SVN Server ist nicht erreichbar; Code kann nicht ausgecheckt oder commited werden % 1 saubere Evaluation des SVN Servers kein direkter Einfluss, da SVN Server nicht unter Kontrolle des Teams, jedoch Kontaktperson bekannt 0 R05 Unstimmigkeiten im Team Diskussion um Code eskaliert zu einem Bruch im Team % 1 Saubere Kommunikation im Team, keine Chefalüren Teamsitzung mit offenem Gespräch 2 R06 Höhere Gewalt Überschwemmung, Erdbeben, Kriegserklärung, Sintflut oder anderes % 0 Keine Beeinflussung möglich Je nach Vorfall ist ein Projektabbruch oder ein minimiertes Arbeiten vorzuschlagen 0 65 / 96

66 R07 Framework von SQuirreL SQL Client Das Framework von SQuirreL SQL Client braucht zum Einarbeiten mehr Zeit als geplant % 1 Sorgfältige Plaung, Statusmeetings um Zeitproblematik früh zu erkennen Mehr Ressourcen einsetzen 10 R08 Refactoring Plugin Das bestehende Plugin lässt sich nicht wie gewünscht erweitern. Eine neue Architektur muss erstellt werden % 3 Analyse der Architektur in einem frühen Zeitpunkt, Prototyp erstellen Architektur mit Refactorings anpassen und/oder erweitern 5 R09 PostgreSQL Plugin Das bestehnde Plugin lässt sich nicht wie gewünscht erweitern. Eine neue Architektur muss erstellt werden % 3 Analyse der Architektur in einem frühen Zeitpunkt, Prototyp erstellen Architektur mit Refactorings anpassen und/oder erweitern 5 TOTAL / 96

67 12.4 Arbeitspakete Name Inhalt Aufwand in h Projektmanagement Projektplanung Erstellen des Projektplans 10 Zeitplanung Erstellen und Aktualisieren des Zeitplans, Rapportieren 25 der Arbeitsstunden Sitzungen Wöchentliche Sitzungen im Team und mit dem Betreuer 28 Sonstiges Sonstige Administrative Tätigkeiten 20 (Wiki, SVN, Build-Script/Server, Backup) Anforderungen Spezifikation Funktionelle und nicht-funktionelle Anforderungen 10 identifizieren und als Spezifikation definieren Use Cases - brief Verfassen der Use Cases im brief Format 2 Analyse Use Cases - fully Ausschreiben der Use Cases im fully dressed Format 10 dressed Analyse Diagramme Erstellen der benötigten Analyse Diagramme (Domain Model, SSD, Contracts, External Design, etc.) 10 Design Design Diagramme Erstellen der benötigen Design Diagramme (Design Model, Internal Design, etc.) Implementation PostgreSQL Plugin Implementation des PostgreSQL Plugin Prototyp 30 Prototyp Refactoring Plugin Implementation des Refactoring Plugin Prototyp 30 Prototyp PostgreSQL Plugin Implementation des PostgreSQL Plugin 40 Refactoring Plugin Implementation des Refactoring Plugin 90 Sonstiges Tests Definieren und Ausführen von Unit und Use Case Tests 40 Plugin- Beschreiben der Plugin-Funktionen für die Hilfeseite im 10 Beschreibungen SQuirreL SQL Client. Schlussdokumentation Erstellen der Schlussdokumentation 25 Totalaufwand Infrastruktur Programmiersprache Die Applikation SQuirreL SQL Client und die Plugins sind mit Java implementiert, wodurch auch die Erweiterungen in den Refactoring und PostgreSQL Plugins mit Java realisiert werden Design und Programmierrichtlinien Als Richtlinie für das Design dient das Buch Applying UML and Patterns [AU04]. Als Richtlinie für den Quellcode gelten primär die verwendeten Namensgebungen und Konventionen in den ursprünglichen PostgreSQL und Refactoring Plugins von Rob Manning (Autor der Plugins). Ansonsten gelten die Java Programming Style Guidelines von GeoSoft / 96

68 Räumlichkeiten Für dieses Projekt gibt es keine speziell reservierten Arbeitsplätze. Alle Arbeiten werden mobil, zu Hause und in den zugänglichen HSR Räumen durchgeführt Hardware Notebook Alle Teammitglieder verfügen mindestens über ein funktionierendes Notebook um Arbeiten am Projekt durchzuführen SVN / Trac Für das zentrale Versionsmanagement des Programmcodes steht uns ein Server der HSR mit installiertem SVN / Trac zur Verfügung Backup Für die Datensicherung des Codes und der Projektdokumente steht ein privater FTP Server von Daniel Regli zur Verfügung. Die Logindaten können bei dregli@hsr.ch bezogen werden Software IDE OOA / OOD SVN Dokumentation Datenbank Als Entwicklungsumgebung wird IDEA IntelliJ 6 verwendet. Für Designzwecke wird die Community Version von JUDE 5 verwendet. Als Code und Versions Management System wird das projekteigene SVN auf einem HSR Server verwendet. Für die Dokumentation werden Microsoft Office 2007 Produkte verwendet. Die Veröffentlichung der Dokumente erfolgt im Adobe PDF Format. Um den SQuirreL SQL Client und die von uns erweiterten Plugins mit einer echten Datenbank zu testen, verwenden wir PostgreSQL in der Version Kommunikation Für die Kommunikation zwischen den Beteiligten des Projekts nutzen wir folgende Mittel: Mittel (HSR) MSN Messenger / Skype Sitzungen Wiki / Trac del.icio.us Beschreibung Verwendet wird der -Verkehr für Terminvereinbarungen und Informationen, welche an mehrere Beteiligte gehen. Tägliches abrufen der HSR- -Adresse wird vorausgesetzt. Für die Echtzeitkommunikation zwischen den Teammitgliedern. Vorwiegend für die Koordination der Aufgaben und für den Kontakt zum Betreuer. Das Entwicklungswiki (Trac) dient dem Datenaustausch und als Sammlung von Projektinformationen: ToDo-Liste Projektedokumente und Vorlagen wichtige Links und Kontaktinformationen verwendete Programme und Bibliotheken dient der Verwaltung der Links, welche mit dem Projekt direkt oder indirekt zusammenhangen. Die Konvention ist, dass sie mit dem Tag sa2007 versehen werden. 68 / 96

69 12.6 Qualitätsmassnahmen Teamarbeit Alle Teammitglieder arbeiten primär in den ihnen zugeteilten Bereichen des Projekts. Zugriffe auf Bereiche eines anderen Teammitglieds müssen mit diesem vorgängig abgesprochen werden. Dem Team stehen pro Woche drei bis vier Stunden für den intensiven Informationsaustausch zur Verfügung. Diese Termine müssen von allen Mitgliedern zwingend wahrgenommen werden, ausser das Team ist sich einig, dass das Projekt zurzeit auch ohne ein Team-Meeting reibungslos weitergeführt werden kann. Zusätzlich ist das gesamte Team über weite Strecken der Woche gemeinsam unterwegs, wodurch ein kontinuierlicher Informationsaustausch praktisch garantiert ist. Änderungen in kritischen Bereichen des zuvor erfolgreich getesteten Systems müssen dem gesamten Team vorgängig bekannt gegeben werden Dokumentation Alle Dokumente werden während dem Projekt kontinuierlich aktualisiert. Geänderte Dokumente werden am Ende einer Phase von einem Teammitglied gegengelesen und auf Korrektheit und Umfang geprüft. Die Ergebnisse dieser Reviews werden in den jeweiligen Dokumenten unter dem Kapitel Qualitätsmanagement eingetragen. Zudem wird der Quellcode des Systems mit Javadoc und Kommentaren beschrieben. Kommentare werden jedoch nur dort eingesetzt, wo dies für das Verständnis des Codes wichtig ist Coding Guidelines Durch den Einsatz von Coding Guidelines (siehe Design und Programmierrichtlinien) wird der einheitliche Stil des Quellcodes gewährleistet. Alle Teammitglieder sind verpflichtet sich an die Coding Guidelines zu halten und eventuell sinnvolle Änderungen an den Guidelines mit dem Team zu besprechen Code Reviews/Inspections Während dem Projekt werden einzelne Systemelemente und Designkonzepte durch den Betreuter reviewt und an den wöchentlichen Meetings besprochen. Zusätzlich wird vor dem Ende der Implementation wird der gesamte Quellcode vom Projektteam mit Hilfe von IntelliJ Code Inspection auf Optimierungsmöglichkeiten überprüft. Diese können die Performance sowohl als auch die Leserlichkeit des Codes verbessern Versionsmanagement Alle Daten des Systems werden im Projekt-SVN verwaltet. Änderungen können somit jederzeit nachvollzogen oder rückgängig gemacht werden. Die Dokumente befinden sich auf dem Projekt-Trac und werden manuell durch eine Versionsnummer im Dateinamen unterschieden. 69 / 96

70 Tests Als Testtechnik für Unit Tests wird JUnit verwendet. Die jeweiligen Test Cases werden vor der Implementation einer Klasse definiert und müssen die Funktionalität aller Schnittstellen der Klasse abdecken und überprüfen. Zusätzlich werden die Plugins am Ende der Implementation auf ihre Funktionalität gemäss Anforderungsspezifikation getestet (Black Box Test anhand der Use Cases). Ist genügend Zeit vorhanden wird das Refactoring Plugin zudem noch auf Kompatibilität zu anderen Datenbanken als PostgreSQL getestet und falls möglich angepasst. (Mögliche Datenbanken: Oracle 10g, MySQL) Automatisierung Der Buildprozess wird mit Hilfe von Apache Ant automatisiert. Zu jedem Release-Build wird eine aktuelle Java Dokumentation, ein JUnit Report, ein Archiv mit dem Quellcode und sonstigen Projektdateien (Bilder, Bibliotheken, Build-Script, etc.), JAR-Files (pro Plugin, werden in das lokale Installationsverzeichnis von SQuirreL SQL Clients kopiert) generiert Sitzungs-Protokolle Es wurde zu jeder Sitzung mit SK ein Sitzungsprotokoll erstellt. Dies war nach spätestens einem Tag nach der Sitzung für die Teilnehmenden auf dem Trac abrufbar. Die verfassten Sitzungsprotokolle befinden sich alle im Anhang D im Kapitel 18 Sitzungsprotokolle Projektmonitoring Zeitaufwand Dieser Abschnitt zeigt den Zeitaufwand über die 14 Wochen, sowie die Verteilung bezüglich der Tätigkeitsbereiche. Teammitglied Summe (Stunden) Durchschnitt (Stunden/Woche) Daniel Regli Yannick Winiger / 96

71 Arbeitsstunden 35.0 Aufwand pro Woche und Teammitglied Daniel Regli Yannick Winiger Projektwochen Stundenaufwand pro Tätigkeitsbereich 74.0; 16% 78.0; 17% 86.5; 18% 8.0; 2% 23.0; 5% 6.5; 1% Projektmanagement Anforderungen Analyse Design Implementation Sonstiges Abschluss 190.0; 41% Für eine detailierte Aufstellung des Zeitaufwands verweisen wir auf das Dokument Zeitplan.pdf auf der CD. 71 / 96

72 Codestatistik Dieser Abschnitt zeigt den Umfang des erarbeiteten Codes gruppiert nach Packages. Da wir in unserem Projekt zwei existierende Plugins erweitert haben, werden in folgenden Diagrammen die Plugins der offiziellen SQuirreL Version mit unseren Erweiterten verglichen Anzahl Klassen Klassen (Refactoring) Offiz. Version Unsere Version refactoring-root actions commands gui gui.util hibernate Offiz. Version Klassen (Postgres) 2 Unsere Version postgres-root actions commands commands.handler explain gui 72 / 96

73 Anzahl Codezeilen Codezeilen (Refactoring) Offiz. Version Unsere Version refactoring-root actions commands gui gui.util hibernate Offiz. Version Codezeilen (Postgres) 193 Unsere Version postgres-root actions commands commands.handler explain gui 73 / 96

74 Anzahl Kommentarzeilen Kommentarzeilen (Refactoring) Offiz. Version Unsere Version refactoring-root actions commands gui gui.util hibernate Offiz. Version Kommentarzeilen (Postgres) 78 Unsere Version postgres-root actions commands commands.handler explain gui 74 / 96

75 13 Softwaredokumentation 13.1 Voraussetzungen Diese Anleitung beschreibt die Installation, Konfiguration und die Anwendung der beiden Plugins. Entwickelt und getestet wurden die beiden Plugins für die SQuirreL SQL Client Version Diese Version muss installiert sein bevor man mit der Installation der Plugins beginnen kann. Hilfe zur Installation für den SQuirreL SQL Client findet man auf der SQuirreL Webseite. Die Version des SQuirreL SQL Client kann bei gestarteter Applikation über das Menu Help About getan werden (Abbildung 22). Abbildung 22: Help/About Menu in SQuirreL SQL Client 13.2 Installation Zur Installation der beiden Plugins werden deren Dateien benötigt. Diese befinden sich auf der CD oder können auf der Webseite heruntergeladen werden. Die beiden Archive (*.zip) müssen sollten folgende Dateien beinhalten: postgres plugin postgres Ordner postgres.jar im postgres Ordner: o images Ordner o changes.txt o licence.txt o readme.html o src.jar o TODO.txt Tabelle 4: Plugin Dateien refactoring plugin refactoring Ordner refactoring.jar im refactoring Ordner folgende Dateien: o images Ordner o changes.txt o licence.txt o readme.html o src.jar o TODO.txt Nun können beide Archive in das Installationsverzeichnis des SQuirreL SQL Clients in den Ordner plugins entpackt werden. Wahrscheinlich ist eine ältere Version der Plugins vorhanden. Die bereits vorhandenen Dateien müssen überschrieben werden. Die Installation ist nun abgeschlossen und SQuirreL SQL Client kann (neu-)gestartet werden Konfiguration Die beiden Plugins können nicht konfiguriert werden. Die einzige Konfiguration im Zusammenhang mit den Plugins kann im SQuirreL SQL Client getätigt werden. Im Menu Plugins/Summary können die Plugins aktiviert/deaktiviert werden (Abbildung 23). 75 / 96

76 Abbildung 23: Plugin Summary Dialog 13.4 Anwendung Die Anwendung der Plugins wird im Hilfedialog von SQuirreL SQL Client beschrieben. Man kann den Hilfedialog über das Menü Help/Help oder mittels Taste F1 erreichen. Ein Dialog öffnet sich und man kann die Hilfe für die Plugins anzeigen (Abbildung 24). Abbildung 24: Hilfe Seite / Anwendung der Plugins 76 / 96