Enterprise Architect – Teamarbeit mit Versionskontrolle

Wer nicht alleine an einem Projekt in Enterprise Architect (EA) arbeitet, wird schnell feststellen, dass der EA nicht für die Gruppenarbeit geschaffen wurde: Es kann immer nur eine Person gleichzeitig an einem EA-Projekt arbeiten! Zumindest in der Standardeinstellung.

Prinzipiell hat man im Team drei Möglichkeiten mit dem EA zu arbeiten:

• Man wechselt sich bei der Bearbeitung ab oder tauscht Packages per Im-/Export aus
• Man verwendet eine zentrale relationale Datenbank
• Man verwendet eines der vom EA unterstützen Versionskontrollsysteme

Die erste Variante ist unpraktisch und zeitintensiv, da man hier nicht parallel arbeiten kann und der Im- und Export es auch nicht praktikabel, da man beim Import vorhandene Packages nicht einfach überschreiben kann. Die zweite Variante ist relativ aufwändig in der Konfiguration und verlangt nach einem relationalen Datenbanksystem. Die dritte Variante ist dagegen relativ einfach in der Konfiguration und benötigt “nur” ein Repository in einem der folgenden Versionskontollsysteme:

• SCC
• CVS – Concurrent Versions System
• SVN – Subversion
• TFS – Team Foundation Server

Dieser Artikel wird sich mit der Integration von Subversion in den EA beschäftigen. Neben der Möglichkeit effizient im Team zu arbeiten erhält man natürlich die von einer Versionskontrolle gewohnte Historisierung seiner Arbeit und kann somit jederzeit zu einem früheren Entwicklungsstand zurückkehren.

Funktionsweise und Begriffe

Der EA verwendet den Kommandozeilen-Client von Subversion zur Versionierung und keine integrierte Lösung. Die EA-Projektdatei ist technisch betrachtet eine Access-Datenbank die vom Versionskontrollsystem nicht verwaltet werden kann. Sie kann zwar im Repository liegen, Änderungen von verschiedenen Personen können aber nicht vom Versionskontrollsystem automatisch eingearbeitet werden (Merge). Es macht dennoch Sinn sie ins Repository zu stellen, da in ihr sämtliche Konfigurationen gespeichert sind, sowohl die SVN-Grundkonfiguration, als auch welche Packages versioniert sind (s.u.). Für die Aktualisierung der Projektdatei sollte aber nur eine Person verantwortlich sein und jeder holt sich die aktuelle Version und speichert sie außerhalb des Repository-Verzeichnisses.

Packages, die unter Versionskontrolle gestellt sind, werden vom EA automatisch importiert und exportiert und liegen dann als XML-Dateien im Repository.

Hier einige Beriffe wie sie bei EA verwendet werden und im Kontextmenü der versionierten Packages zu finden sind (Package Control).

Begriff	Bedeutung
Check Out	Exklusiven Zugriff erlangen (SVN: get lock)
Undo Check Out	Exklusiven Zugriff freigeben und Änderungen verwerfen (SVN: revert + release lock)
Check In	Neue Version im Repository speichern (SVN: commit)
Check In Branch	Neue Version mehrerer Packages im Repository speichern (SVN: commit) für mehrere Dateien
Get Latest / Get All Latest	Aktuelle Version aus dem Repository (bestimmtes / alle Packages) holen (SVN: update)

Voraussetzungen

Folgende Voraussetzungen müssen erfüllt sein und werden im Folgenden vorausgesetzt:

• Der Enterprise Architect ist auf den Rechnern der Teammitglieder installiert und eingerichtet.
• Ein zentraler Subversion-Server mit dem Projekt-Repository ist installiert und so eingerichtet, dass die Teammitglieder darauf zugreifen können.
• Der Kommandozeilen Subversion-Client  ist auf den Rechnern der Teammitglieder installiert.
• Optional: Es empfiehlt sich den Windows Subversion-Client Tortoise zu installieren.

Bevor die eigentliche Konfiguration des EA beginnen kann, muss noch der initiale Checkout des Projekt-Repositories in ein lokales Verzeichnis erfolgen. Dieses Verzeichnis ist dann die Arbeitskopie (im EA: “Working Copy”).

Subversion im EA einrichten

Die Konfiguration von Versionskontrollsystemen erfolgt im EA Projektbezogen. Zuerst wird also die Projektdatei (*.eap) aufgerufen, anschließend werden über

Project >Version Control > Version Control Settings…

die Grundeinstellungen zur Subversion-Einbindung vorgenommen.

Feld	Wert
Working Copy path	Die ist der Pfad zur lokalen Arbeitskopie des Repositories, in dem das Projekt versioniert werden soll.
Subversion Exe path	Programmpfad zum SVN Kommandozeilen-Client.

Sind alle Einstellungen getroffen, wird die Konfiguration mit einem Klick auf “Save” gesichert.

Bisher haben wir nur die Grundeinstellungen für die Versionskontrolle vorgenommen, verwendet wird sie aber noch nicht.

Ein EA-Projekt ist meist in mehrere Packages aufgeteilt und jedes dieser Packages kann einzeln (auch verschachtelt) unter Versionskontrolle gestellt werden.

Im Vorfeld sollte man sich über eine sinnvolle Unterteilung des Projektes Gedanken machen. Es können zwar mehrere Personen parallel an verschiedenen Packages arbeiten, an einem Package aber immer nur einer zur Zeit. Nur das Root-Package zu versionieren macht daher wenig Sinn, das andere Extrem (jedes Package) aber ebenfalls nicht, da man dann erst mehrere Packages zur Arbeit Freischalten muss (“auschecken”) bevor man loslegen kann. Wie das Projekt sinnvoll unterteilt werden kann, ist aber Projektabhängig und kann hier nicht allgemein beschrieben werden.

Packages werden folgendermaßen unter Versionskontrolle gestellt: im Project Browser mit der rechten Maustaste auf das zu versionierende Package klicken und im Kontextmenü

Package Control > Configure…

auswählen.

Feld	Wert
Control Package	Diese Checkbox muss angehakt sein. Hiermit wird ein Packages unter Versionskontrolle gestellt, oder dort wieder herausgenommen.
Version Control	Das Pulldown-Menü bietet eine Auswahl vorhandener Konfigurationen für Versionskontrollsysteme. Hier sollte mindestens die von uns oben im “Version Control Settings”-Dialog erzeugte Konfiguration SVN_PROJECT auftauchen. Diese wird auch ausgewählt.
XMI Filename	Pfad an dem das Package im Repository gespeichert werden soll.

ACHTUNG: Der XMI-Dateiname darf keine Umlaute enthalten, ebensowenig das Verzeichnis in dem die Datei gespeichert werden soll. Wenn der Packagename also Umlaute enthält (was kein Problem ist) muss man dies beim Dateinamen ändern.

Es ist wichtig, dass alle Teammitglieder nach dieser Änderung die neue, aktualisierte EA-Projektdatei übernehmen.

Nach dieser Konfiguration kann man nach einem “Check Out” das Package bearbeiten und mit einem “Check In” im Repository aktualisieren und für andere freigeben.

Fazit

Die Grundkonfiguration ist schnell erledigt und je nach Anzahl der Packages auch deren Versionierung. Der Gewinn, den man durch die Möglichkeit des parallelen Arbeitens erhält, ist jedoch enorm, auch schon ab zwei Personen, besonders wenn man das Projekt geschickt unterteilt hat. Dann hört man auch nur selten: “Wer hat Package X schon wieder ausgecheckt?