Teil 2: Aufbau der Programmierschnittstelle im Project Browser, Plausibilisierungsfunktionen, Versionsmanagement

UML – Modellierungswerkzeuge richtig konfigurieren [Teil 2]
Keine Kommentare

Die Modellierungssprache UML gehört für viele Entwicklungsprojekte seit Jahren zum Standard. Aber was passiert, wenn die UML auch im Fachbereich für die Modellierung von fachlichen Anforderungen eingesetzt werden soll? In Teil 2 des Artikels stehen der Aufbau der Programmierschnittstelle, das Bereitstellen von Pflegeoberflächen, die Schnittstelle zu Testwerkzeugen und das Versionsmanagement im Mittelpunkt.

Dass Entwickler keine Berührungsängste haben müssen, wenn sie mit den entsprechenden Modellierungswerkzeugen arbeiten, haben wir im ersten Teil dieses Artikels nach einer Einleitung zur Modellierungssprache UML, einem Blick auf UML-Erweiterungsmöglichkeiten mithilfe von UML-Profilen sowie der Konfiguration des Tools MDG Technology etabliert. Im zweiten Teil geht es um den Aufbau der Programmierschnittstelle im Project Browser, das Bereitstellen von Pflegeoberflächen für die modellierten Elemente, Plausibilisierungsfunktionen, die Schnittstelle zu Testwerkzeugen und das Versionsmanagement.

Aufbau der Programmierschnittstelle

Bevor die Programmierschnittstelle erläutert werden kann, muss noch ein zentrales Element der Modellierungswerkzeuge beschrieben werden: der Project Browser. Alle modellierten Elemente und Diagramme werden in einer vom Anwender selbst zu definierenden Ordnerstruktur abgelegt. Über diese Ordnerstruktur kann dann im Project Browser navigiert und auch die Ordnerstruktur verändert werden. Abbildung 4 zeigt den Project Browser zu dem weiter oben beschriebenen Modell.

Abb. 4: Project Browser mit erweitertem Menü

Abb. 4: Project Browser mit erweitertem Menü

Der Enterprise Architect stellt nun mit Interop.EA.dll ein API zur Verfügung, mit dem sämtliche in dem Werkzeug abgelegten Informationen abgefragt werden können. Als zentraler Einstiegspunkt dient dabei die Klasse Repository. Über dieses Repository kann zum Beispiel durch die angelegte Ordnerstruktur navigiert werden, oder es können die im Project Browser selektierten Elemente abgefragt werden. Das API kann in einem zu erstellenden Programm eingebunden werden, sodass die jeweiligen Informationen abgefragt werden können. Aber wie kann das zu erstellende Programm nun das richtige Repository ermitteln?

Dafür gibt es zwei Wege. Zum einen kann die Modelldatei über einen Parameter beim Aufruf einer Main-Methode übergeben werden (Listing 1). Zum anderen stellt der Enterprise Architect aber auch ein sehr umfangreiches Event Handling zur Verfügung, sodass über abgefangene Eventmethoden das aktuelle Repository ermittelt werden kann (Listing 2). Der zweite Weg bedeutet aber, dass dem Enterprise Architect das erstellte Programm bekannt gemacht wird, sodass er weiß, wohin er die Events versenden muss. Das wird dadurch erreicht, dass aus dem Programm eine DLL erzeugt wird, die registriert und dann über einen Eintrag in der Registry als AddIn dem Enterprise-Architekten bekannt gemacht wird.

Eine weitere Funktion, die über die Programmierschnittstelle bereitgestellt wird, ist die Erweiterung von Menüs. Zum Beispiel soll dem Fachbereich die Möglichkeit gegeben werden, die erstellten Modelle zu plausibilisieren oder die Informationen zu modellierten Elementen mit einfachen Pflegeoberflächen zu ändern. In Abbildung 4 ist eine solche Erweiterung des Menüs dargestellt und in Listing 2 die zugehörige Programmierung. Der gesamte Ablauf ist in Abbildung 5 zusammengefasst.

Listing 1
static void Main(string[] args){
  Repository lRepository = new Repository();
  lRepository.OpenFile(args[0]);
}
Listing 2
public void EA_MenuClick(EA.Repository pRepository, string pLocation, string pMenuName, string pItemName){
  switch (pItemName){
    case "Pflegen":
    pflege(pRepository);
    break;
    case "Plausibilisieren":
    plausibilisiere(pRepository.GetTreeSelectedPackage());
    break;
  }
}
Abb. 5: Programmierschnittstelle

Abb. 5: Programmierschnittstelle

Bereitstellen von Pflegeoberflächen

Nun stellt ein Modellierungswerkzeug natürlich auch entsprechende Pflegeoberflächen für die modellierten Elemente bereit. In Abbildung 6 ist so eine Pflegeoberfläche für die Klasse Kunde dargestellt. Es ist zu sehen, dass alleine elf Reiter für die Erfassung von Informationen zur Verfügung stehen. Auf dem Reiter UML-Profil befinden sich zum Beispiel die definierten Tagged Values Author und Change Date. Für den Anwender interessant sind aber nur die drei Felder Name, Author und Change Date. Abbildung 7 zeigt eine selbst programmierte Oberfläche, die genau diese drei Felder zur Pflege anbietet. Diese Oberfläche kann über das AddIn bereitgestellt werden. Neben der in Listing 2 beschriebenen Eventmethode EA_MenuClick(…), die für selbst definierte Menüpunkte verwendet werden kann, gibt es auch eine Methode, die bei einem Doppelklick aufgerufen wird: EA_OnContextItemDoubleClicked(…).

Das normale Verhalten des Enterprise Architect bei einem Doppelklick auf ein Element ist das Öffnen der Pflegeoberfläche. Dieses Verhalten kann mit der genannten Methode überschrieben werden, sodass bei einem Doppelklick die Pflegeoberfläche des AddIns geöffnet wird. Um den Enterprise Architect darüber zu informieren, dass der Doppelklick durch eine eigene Programmierung bearbeitet wird, ist der Rückgabewert dieser Eventmethode auf true zu setzen. Ansonsten würden beide Pflegeoberflächen geöffnet. Damit kann der Anwender auf einfache Weise die modellierten Elemente bearbeiten. Die komplexere Pflegeoberfläche des Enterprise Architect ist weiterhin über einen Menüpunkt im Pop-up zu einem Element verfügbar (in Abb. 4 der Menüpunkt Propertys).

Abb. 6: Pflegeoberfläche Enterprise Architect

Abb. 6: Pflegeoberfläche Enterprise Architect

Abb. 7: Pflegeoberfläche für den Fachbereich

Abb. 7: Pflegeoberfläche für den Fachbereich

Plausibilisierungsfunktionen

Mit den Plausibilisierungsfunktionen ist es nun ähnlich. Zwar stellt der Enterprise Architect hierfür ein eigenes kleines Framework zu Verfügung, sodass über die Standardmenüfunktion Model Validation projektspezifische Plausibilisierungen integriert und die Ergebnisse in einer Konsole des Enterprise Architect ausgegeben werden können. Vielleicht sollen aber ja die Plausibilisierungsergebnisse in eine Datei geschrieben werden, oder – noch eleganter – bei Fehlern direkt in ein Defect-Managementwerkzeug übertragen werden (siehe nächster Abschnitt).

Des Weiteren ergibt es eventuell auch Sinn, die Prüfungen in einen nächtlichen Standbau zu integrieren. Da funktioniert dann der Aufruf eines Menüpunkts in der Anwendung nur bedingt. Als Empfehlung bleibt also, auch die Validierungsfunktionen über eigene Methoden abzuhandeln, die dann sowohl über selbstdefinierte Menüpunkte direkt aus der Anwendung, als auch über externe Anwendungen (ähnlich Listing 1) aufgerufen werden können.

Aber was können denn nun solche zusätzlichen Plausibilisierungen genau sein? Da bietet sich vieles an, und auch hier gilt, wenn der Fachbereich erst mal auf den Geschmack gekommen ist, sind die Grenzen offen:

  • Einhaltung von Namenskonventionen
  • Einhaltung von Formatvorgaben
  • Einhaltung von Pflichtfeldern
  • Hat jede Beziehung zwischen zwei Elementen einen Namen

Schnittstelle zu Testwerkzeugen

Die Programmierschnittstelle kann natürlich auch genutzt werden, um Schnittstellen zu anderen Werkzeugen zu programmieren. Für einen Mitarbeiter aus dem Fachbereich ist es mitunter hilfreich, wenn er direkt aus dem Modellierungswerkzeug identifizierte Fehler in dem Modell in ein Fehlermanagementwerkzeug übertragen kann. Abbildung 8 zeigt eine Oberfläche, die über einen zusätzlichen Menüpunkt im Modellierungswerkzeug, wie oben beschrieben, aufgerufen werden kann.

Abb. 8: Oberfläche Fehler/Change

Abb. 8: Oberfläche Fehler/Change

Über eine entsprechende Programmierschnittstelle des Testmanagementwerkzeugs können dann die Daten übertragen und automatisch ein Fehler generiert werden. Der Vorteil dabei ist, dass der Anwender nicht in ein anderes Werkzeug wechseln muss (Defect-Managementwerkzeug, Outlook, Excel, o. Ä.) und auch Verweise auf Modellelemente, an denen der Fehler aufgetreten ist, mit übertragen werden können. Das kann zum Beispiel durch die Übermittlung des vollständigen Namensraums eines Elements als Zeichenkette geschehen oder durch die Übermittlung eines Links auf die Beschreibung des Elements in einem HTML-Export des gesamten Modells. Für das Werkzeug HP-ALM sei das in Listing 3 kurz skizziert.

Listing 3
private void createDefect(EA.Repository pRepository, TDConnection pTDConnection ){
  IBugFactory2 lBugFactory = (IBugFactory2)pTDConnection.BugFactory;
  IBug2 lBugItem = (IBug2)lBugFactory.AddItem(DBNull.Value);
  lBugItem.Summary = "Generiert aus Enterprie Architect";
  // Weitere Felder füllen    
  lBugItem.Post();
  MessageBox.Show("Defect für " + getLogInUser() + " erstellt");
}

Die Methode createDefect bekommt neben dem Repository des Enterprise Architect den zentralen Einstiegspunkt für das HP-ALM, die TDConnection, als Parameter übergeben. Über eine BugFactory wird ein Defect im HP-ALM erzeugt, mit den notwendigen Feldern befüllt und dann mit der Methode Post() persistent gespeichert. Über das Repository kann das aktuell selektierte Element erfragt und dem Defect übergeben werden. Anzumerken bleibt, dass über die Factory und die Methode Post() alle Berechtigungen des angemeldeten Benutzers für das HP-ALM überprüft werden, sowie auch die korrekte Befüllung aller für einen Defect notwendigen Pflichtfelder.

Versionsmanagement

Wird nun die Modellierung im Fachbereich mit einem Modellierungswerkzeug durchgeführt und arbeiten mehrere Mitarbeiter mit dem Werkzeug, wird es zwingend notwendig, die Modelle über ein Versionierungswerkzeug zu archivieren. Der Enterprise Architect bietet die Möglichkeit, unterschiedliche Versionierungswerkzeuge so zu integrieren, dass das Arbeiten mit der Versionierung für den Endanwender völlig transparent ist. Über zusätzliche Menüpunkte stehen ihm neben den Funktionen Check out und Check in auch komplexere Versionierungsfunktionen wie zum Beispiel das Auschecken kompletter Zweige oder das Laden von älteren Versionen zur Verfügung.

Zu beachten ist, dass auf Paketebene versioniert wird und nicht auf Elementebene. So kann in Abbildung 4 nur das Paket Modell und nicht das Geschäftsobjekt Kunde als Archiv erstellt werden. Ein Entwickler würde vielleicht beide Möglichkeiten erwarten, da Sourcecode meistens auf Klassenebene versioniert wird. Die Versionierung selbst erfolgt in Form von XML-Dateien. Der Enterprise Architect erstellt aus einem Paket eine XML-Datei, die dann in dem konfigurierten Arbeitsbereich zum Versionierungswerkzeug abgelegt wird.

Abb. 9: Empfohlenes Vorgehen

Abb. 9: Empfohlenes Vorgehen

In der Abbildung 9 ist ein empfohlenes Vorgehen verdeutlicht, mit dem zwei Ziele verfolgt werden sollen. Zum einen kann der Anwender in einer lokalen Version des Modells Änderungen vornehmen, die noch nicht sofort für alle anderen sichtbar sind. Grundsätzlich ist es nämlich möglich, dass mehrere Anwender auf demselben Modell arbeiten. Das würde aber bedeuten, dass sobald eine Klasse A angelegt wird, sie sofort für alle sichtbar ist und auch verwendet werden kann. Das ist aber nicht zielführend, da nur konsistente und in sich abgeschlossene Änderungen als neue Versionen freigegeben werden sollten. Zum anderen soll auch ein Continuous-Integration-Prozess unterstützt werden, der dann in folgenden Schritten abläuft:

  • Ein Anwender arbeitet auf einer lokalen Version des Modells (Sandkastenprinzip) und kann dort in Ruhe seine Änderungen vornehmen.
  • Sind diese Änderungen abgeschlossen und in sich konsistent, so kann der Anwender die Änderungen in das Versionierungswerkzeug einchecken.
  • Mit dem Einchecken startet das Versionierungswerkzeug den Continuous-Integration-Prozess, in dem das Modellierungswerkzeug darüber informiert wird, dass neue Versionen bereitstehen.
  • Das Modellierungswerkzeug aktualisiert nun über ein Skript ein Continuous-Integration-Modell (C-I-Modell) mit den neuen Änderungen und führt die Plausibilisierungen durch.
  • Bei erfolgreicher Plausibilisierung wird eine neue aktuelle Version des Modells (Kopie des C-I-Modells) an einer zentralen Stelle bereitgestellt.
  • Ein Anwender kann sich bei Bedarf dieses aktuelle Modell auf seinen Arbeitsplatz kopieren.

Fazit

Fachbereiche stehen Modellierungswerkzeugen grundsätzlich feindlich gegenüber. Dass das nicht so sein muss und auch nicht unbedingt Schuld der Modellierungswerkzeuge ist, konnte dieser Artikel hoffentlich verdeutlichen. Aber die beschriebenen Konfigurationsmöglichkeiten sind nur der Anfang, um dem Fachbereich das Arbeiten mit Modellierungswerkzeugen zu erleichtern. In einem nächsten Schritt stehen ihm dann natürlich alle zusätzlichen Auswertungsmöglichkeiten dieser Werkzeuge zu Verfügung: beliebig konfigurierbare Suchfunktionen auf den Modellen, Abhängigkeitsanalysen von modellierten Elementen, Dokumentengenerierung aus den Modellen, Erstellen von Berichten etc.

Was aber auch deutlich werden sollte, ist die Tatsache, dass der Fachbereich für den Einsatz von Modellierungswerkzeugen tatkräftige Unterstützung und Betreuung aus der IT benötigt. Dabei sollte allerdings nicht vergessen werden, dass auch die IT immens von modellierten Anforderungen profitiert. Und auch das Testen kann dann durch die Generierung von Testfällen aus den modellierten Anforderungen vereinfacht werden.

Entwickler Magazin

Entwickler Magazin abonnierenDieser Artikel ist im Entwickler Magazin erschienen.

Natürlich können Sie das Entwickler Magazin über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist das Entwickler Magazin ferner im Abonnement oder als Einzelheft erhältlich.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -