Erste Schritte

Hier werden die wesentlichen Tätigkeiten beschrieben, die im Entwicklungszyklus durchgeführt werden.

Modellieren

Zur Modellierung wird Enterprise Architect (im Folgenden EA) verwendet. Das UML-Modell ist in der Datei "src/model/fallbeispiel.EAP" gespeichert. Nach dem Öffnen der Datei mit EA ist in der Projekt-Ansicht (Project View) der Knoten "Fallbeispiel/ROOT" zu öffnen, dieser enthält die Pakete "OOGPM" und "OOAD". Für die Generierung ist das Paket "OOAD" von Bedeutung.



Regeln, die bei der Modellierung beachtet werden müssen, sind in Modellierungs-Regeln beschrieben.

Exportieren des Modells in XMI

Zum Exportieren des Modells muss das Paket "OOAD" markiert werden. Über die Funktion "Project/Import,Export/Export Package to XMI" (oder alternativ über das Kontext-Menü der rechten Maustaste) wird der Dialog zum XMI-Export aufgerufen. Darin muss die Option "XMI 1.2" aktiviert sein, weiterhin kann auch "Format XML Output" aktiviert werden. Das XMI sollte in das Verzeichnis "src/xmi" exportiert werden.



Um das exportierte Modell als Quelle für die Generierung zu verwenden, muss die Eigenschaft genfw.instantiator.design in der Datei "project.properties" angepasst werden.

Instanziieren und Visualisieren des Metamodells

Das Exportierte XMI stellt die Quelle für das Instanziieren des Metamodells durch Open ArchitectureWare (im Folgenden OAW) dar.



Wie bereits zuvor beschrieben, wird in der Datei project.properties über die Eigenschaft genfw.instantiator.design bestimmt, welche XMI-Datei dazu verwendet werden soll.



Mit dem Aufruf von 

maven swingui
wird die Swing-Oberfläche gestartet, die ein Navigieren durch das instanziierte Metamodell ermöglicht.

Es ist übrigens auch möglich, Maven in einem Konsolenmodus zu starten (maven console), so dass die so genannten Goals (z.B. swingui) dort direkt eingegeben werden können. Damit muss nicht für jede Aktion die JVM neu gestartet werden.



Achtung

Die Generierung, die auch von der SwingUI aus gestartet werden kann, sollte dort nicht iniziiert werden! Dadurch würden zuvor implementierte Code-Anteile überschrieben werden und wären nicht mehr verfügbar.

Statt dessen muss die Generierung durch das Maven-Goal generate gestartet werden, siehe auch den folgenden Abschnitt.

Generieren von Sourcecode

Die Generierung von Code wird mit dem Maven-Goal generate gestartet, z.B. durch den Aufruf von 

maven generate
.



Dabei werden die Quellen aus "src/gen" in ein anderes Verzeichnis kopiert, um eventuell bereits implementierte Code-Anteile zu sichern. Die Generierung erfolgt ebenfalls in das Verzeichnis "src/gen", dabei werden aus den zuvor gesicherten Quellen die Inhalte der geschützten Bereiche (Protected Regions) ausgelesen und in das neue Generat integriert.

Implementieren nicht-modellierter Sachverhalte

Die Implementierung fachlicher und/oder technischer Aspekte, die nicht im Modell abgebildet sind, erfolgt in dem Verzeichnis "src/gen". Dazu sind in den generierte Dateien so genannte Protected Regions (Geschützte Bereiche) vorgesehen, die bei einer erneuten Generierung erhalten bleiben.

Vorbereiten der Laufzeitumgebung

Vorbereiten der Datenbank

Zur Laufzeit der Webanwendung wird eine Datenbank benötigt; die Konfiguration sieht einen MySQL-Server in Version 4.x vor (getestet ist Version 4.0.20), siehe mysql.com.



1. Anlegen der Datenbank

Das Installieren eines MySQL-Servers und das Anlegen der Datenbank wird hier nicht beschrieben, dazu sei auf die Website mysql.com verwiesen.

Hinweis

Als Datenbank-Name sollte "ooseminars" gewählt werden, auch der Benutzername und das Passwort für den Datenbank-Benutzer sollten "ooseminars" lauten.

Ansonsten ist es nötig, die Dateien

  • "src/conf/hibernate-db-gen.properties" (Erzeugen des Schemas durch hibernate:schema-export)
  • "src/conf/spring-test.xml" (Spring-Konfiguration für UnitTests)
  • "src/gen/spring.xml" (Generierte Spring-Konfiguration)
anzupassen.



2. Anlegen der Tabellen

Nach dem Anlegen einer Datenbank können die Tabellen mit Hilfe des SQL-Scripts "src/sql/ooseminars-0.9.6-schema.sql" angelegt werden. Alternativ ist es möglich, das mit 
maven hibernate:schema-export
zu erledigen, dabei wird die Schema-Datei neu generiert und das Schema in der Datenbank angelegt - dazu muss der Datenbank-Server also gestartet sein.



3. Laden von Beispiel-Daten

Da die Applikation bisher keine Anwendungsfälle zum Anlegen von Seminaren und Veranstaltungen unterstützt, müssen für diese manuell in der Datenbank Datensätze angelegt werden. Dafür sind die Tabellen SEMINAR und EVENT relevant. Wurde das Modell nicht bearbeitet, bzw. die Struktur der Entitäten nicht geändert, kann für das Laden von Beispieldaten das SQL-Script "src/sql/example-data.sql" verwendet werden. Alternativ ist es möglich, die DBUnit-Tests ("src/test/") zu verwenden, diese stellen einen definierten Ausgangszustand in der Datenbank her, dieser ist in der Datei "src/test/test-data.xml" definiert. Für die DBUnit-Tests ist noch kein Maven-Goal definiert, sie können aber aus einer Entwicklungsumgebung wie z.B. Eclipse gestartet werden. Es sind nur zwei DBUnit-Tests geschrieben, für Seminare und Veranstaltungen. Die Klasse de.javakaffee.ooseminars.seminar.dataaccess.SeminarDAOUnitTest kann z.B. für das Füllen der Datenbank verwendet werden - als Nebeneffekt wird getestet ob die generierte und implementierte Datenzugriffsschicht für Seminare fehlerfrei ist.

Vorbereiten des Servlet-Containers

Das entwickelte Softwaresystem ist eine Java-basierte Webanwendung. Sie kann in Servlet-Containern installiert werden, die die Servlet-Spezifikation 2.3 unterstützen, wie z.B. Tomcat 4 und 5. Getestet wurde die Anwendung bisher unter Tomcat 5.0.27, dieser Container wird bei der weiteren Erklärung beispielhaft referenziert.



In dem Servlet-Container muss ein neuer Application-Context angelegt werden, dieser weist auf das Verzeichnis "target/ooseminars". In Tomcat kann der Context z.B. mit dem Eintrag <Context path="/ooseminars" docBase="/data/proj/ooseminars/trunk/target/ooseminars" debug="3" /> innerhalb eines Host-Elements definiert werden - das Attribut "docBase" muss allerdings angepasst werden.

Deployen der Webanwendung

Das Maven-Goal 

maven war:webapp
ist verantwortlich für das Deployen der Webanwendung. Danach kann der Tomcat gestartet werden.



Ist der Tomcat bereits gestartet, ist es notwendig den Context neu zu laden, damit der Servlet-Container die Änderungen übernimmt und die geänderten Klassen neu lädt. Das kann mit dem Maven-Tomcat-Plugin gemacht werden. Das Plugin kann z.B. mit 
maven -Dmaven.repo.remote=http://www.codeczar.com/maven \
	 -DartifactId=maven-tomcat-plugin \
	 -DgroupId=codeczar-tomcat \
	 -Dversion=1.1 \
	 plugin:download
(oder eine Zeile ohne Backslashes) installiert werden.



Mit dem Aufruf von 
maven tomcat:reload
werden schließlich geänderte Klassen neu übersetzt und anschließend der Context neu geladen.



Nach dem Deployen der Webanwendung kann mit dem Aufruf von z.B. "http://localhost:8080/ooseminars/listSeminars.do" die Anwendung gestartet werden.