Seite 1. Abbildung 1: Einrichtung der Datenbank

Transkript

1 Machbarkeitsstudie Sprinter Dieses Beispiel führt exemplarisch einige der Technologien rund um das Thema JEE vor. Dabei liegt der Schwerpunkt darauf, kompakt den Ansatz vorzustellen, ohne im Detail alle Möglichkeiten aufzuzeigen. Weiterhin werden die Techniken teilweise in einem nicht optimalen Kontext eingesetzt, so dass die Idee wie es funktioniert deutlich vor wo ist der beste Einsatz bei der Entwicklung stand. Weiterhin stand bei der Entwicklung die Software-Architektur nicht im Mittelpunkt. Etwas erfahrene Entwickler sollten schnell den Drang nach einer Zwischenschicht oder der Aufteilung einer Klasse spüren. Positiv formuliert steht der einfache Einsatz der Technologien im Mittelpunkt, der bei der Entwicklung eigener Programme sicherlich viele übertragbare Ideen aufzeigt. Dieses Dokument zeigt, wie das Projekt unter NetBeans mit dem Glassfish-Server 4.1 gestartet werden kann, eine Übertragung auf Eclipse ist leicht möglich. Das Projekt selbst realisiert eine Web-basierte Software zur Verwaltung von Sprints des agilen Vorgehensmodells Scrum. Sehr vereinfacht beschreibt ein Sprint die konkreten Projektaufgaben (hier Backlog-Elemente genannt), die in einem festen Zeitrahmen von den Mitarbeitern des Teams bearbeitet werden sollen. Zu jeder Aufgabe gibt es eine Aufwandsschätzung und jeder Bearbeiter der Aufgabe hält kontinuierlich, z.b. täglich, fest, zu welchem Prozentanteil die Aufgabe abgeschlossen ist und viele Stunden mit der Bearbeitung verbracht wurden. Weitere Informationen zu Scrum und Sprints findet man z. B. in [Kle13]. Gibt man dann einen gewissen Zeitrahmen für einen Sprint vor, unterstützt das Werkzeug dabei festzustellen, ob die Arbeiten im kalkulierten Zeitrahmen abgeschlossen werden können. Eine informelle Anforderungsanalyse befindet sich am Ende des Dokuments. Bei der folgenden Darstellung der Installation wird davon ausgegangen, dass einige Grundkenntnisse in NetBeans vorliegen, Details kann man z. B. entnehmen. Abbildung 1: Einrichtung der Datenbank Nachdem das Projekt in NetBeans geöffnet wurde, muss eine Datenbank angelegt und integriert werden. Dazu wird auf dem üblichen Weg eine Datenbank angelegt, es sollte dazu ein Nutzer mit Passwort angegeben werden, wie es in Abbildung 1 angedeutet ist. Seite 1

2 Abbildung 2: Einrichtung der Datenbankverbindung Im nächsten Schritt muss die Datei persistence.xml angelegt werden, was über einen Rechtsklick auf dem Projekt erfolgt (New > Other > Persistence > Persistence Unit). Zunächst muss der Persistence Unit Name SprinterPU sein. Der Persistence Provider ist EclipseLink (JPA 2.1). Unter Data Source wird rechts zunächst Create New Data Source ausgewählt. Dann wird als JNDI Name java:app/jdbc/sprinterdb eingetragen und bei der Database Connection die zuvor angelegte Datenbank ausgewählt, wie es Abbildung 2 zeigt. Abbildung 3: Übersicht über Verbindungsdaten Abbildung 3 zeigt den gesamten Eintrag für die neue Persistence Unit. Abbildung 4: Neu entstandener Ordner Server Resources Die gerade vorgenommen Einstellungen werden in NetBeans in einem neu entstehenden Ordner Server Resources abgespeichert. Die Einstellungen liegen in der Server-individuellen Datei glassfishresources.xml, wie Abbildung 4 zeigt. Seite 2

3 Abbildung 5: Vorbereitung zum Kopieren von glassfish-resources.xml Diese Datei muss allerdings nach dem Standard im Ordner WEB-INF liegen. Im konkreten Fall wird die Datei einfach in den passenden Ordner kopiert. Dazu wird ein Rechtsklick auf der Datei gemacht und Copy ausgewählt, wie es Abbildung 5 zeigt. Abbildung 6: Einfügen der kopierten Datei Danach wird mit einem Rechtsklick auf dem Ordner WEB-INF die Datei mit Paste eingefügt, wie in Abbildung 6 dargestellt. Abbildung 7: Aktualisiertes WEB-INF-Verzeichnis Ein Ausschnitt aus Endergebnis zeigt Abbildung 7. Seite 3

4 Man beachte, dass Änderungen in der persistence.xml, die die Data Source betreffen, immer in der Datei glassfish-resources.xml im falschen Ordner gespeichert werden, so dass die Datei nach der Änderung erneut in den richtigen Ordner zu kopieren ist. Dazu ist die alte Datei vorher zu löschen. Danach kann das Projekt mit Run einfach gestartet werden, Server und Datenbank werden mitgestartet, dürften aber auch schon vorher gestartet werden. Abbildung 8: Erneute Übersetzung des Projekts Sollte die Applikation nicht starten und der Glassfish eine Fehlermeldung werfen, könnten die Probleme bei Start von Glassfish liegen (Problem wurde mit NetBeans eingeführt). Die Meldung sieht dann ähnlich zu folgendem Text aus. Incrementally redeploying Sprinter GlassFish Server 4.1, redeploy, null, false F:\workspaces\NetbeansWork_WS14\Sprinter\nbproject\build-impl.xml:1051: The module has not been deployed. Zunächst ist das Projekt vor dem erneuten Startversuch neu zu übersetzen, wie es Abbildung 8 zeigt. Abbildung 9: Notwendiger Restart bei Server-Problemen Der Server ist dann unter Services neu zu starten, wie es Abbildung 9 zeigt. Es ist vorher zu prüfen, dass die Datenbank läuft. [Kle13] S. Kleuker, Grundkurs Software-Engineering mit UML, 3. aktualisierte Auflage, Springer Vieweg, Wiesbaden, 2013 Seite 4

5 Anhang: Anforderungsspezifikation Sprinter Bei unserer Sprintplanung wird festgelegt, welche Backlog-Elemente in dem aktuellen Sprint abgearbeitet werden sollen. Zusammen mit den Mitarbeitern wird dazu jeweils der Aufwand in Stunden geschätzt und dem Element ein Titel gegeben. Weiterhin wird festgelegt, welcher Mitarbeiter mit welcher Stundenanzahl an dem Element arbeitet. Während des Sprints sollen die Mitarbeiter möglichst täglich für ihre Backlog-Elemente festhalten, wieviele Stunden sie insgesamt schon daran gearbeitet haben und wie sie für ihren Teil den Fertigstellungsgrad beurteilen. Zu erstellen ist ein kleines Verwaltungswerkzeug, das festhält, welche Mitarbeiter an welchen Backlog-Elementen arbeiten und es ermöglicht, die verbrauchten Stunden und den Fertigstellungsgrad zu erfassen. Aus den eingegebenen Daten soll für ein Backlog-Element berechnet werden, wie hoch der Fertigstellungsgrad ist, wieviele Stunden bereits daran gearbeitet wurde und wie der daraus prognostizierte finale Aufwand ist. Weiterhin ist sicherzustellen, dass maximal so viele Stunden auf die Mitarbeiter verteilt werden, wie für das jeweilige Backlog-Element geschätzt wurden. Die auf die Mitarbeiter verteilte Stundenzahl muss nicht genau dem Aufwand des Backlog- Elements entsprechen, da wir so Risikopuffer einplanen. Zur Verwaltung müssen die Mitarbeiter mit Namen und Mitarbeiternummer und die Backlog- Elemente erfasst werden können. Diese Eingaben sollen alle editierbar und löschbar sein. Da das Unternehmen wächst und mehrere Software-Produktentwicklungen parallel stattfinden, soll das Werkzeug auch die Verwaltung mehrerer Sprints erlauben, die mit ihren Start- und Endterminen zu erfassen sind. Jedem Sprint werden dann mehrere Backlog-Elemente zugeordnet, weiterhin hat jeder Sprint einen maximal zur Verfügung stehenden Aufwand an Stunden. Neben dem Anlegen und Verändern von Sprints soll die Software auch prüfen, dass nur der zur Verfügung stehende Aufwand auf die Backlog-Elemente verteilt wird. Weiter soll auch für Sprints berechnet werden können, wie hoch der Fertigstellungsgrad ist, wieviele Stunden bereits daran gearbeitet wurde und wie der daraus prognostizierte finale Aufwand ist. Auch Sprints können Risikopuffer enthalten, so dass nicht der gesamte Aufwand auf Backlog-Elemente verteilt sein muss. Die Software soll durch eine Visualisierung mit Hilfe eines Kanban-Brettes aktualisiert werden, dabei wird jedem Backlog-Element einer der in der Kopfzeile genannten Zustände zugeordnet. Es ist sicherzustellen, dass der Zustand fertig nur angenommen wird, wenn der Fertigstellungsgrad bei 100% liegt. Seite 5