Modellgetriebene Architektur: Vergleiche von Code und Modell

worked on by: Julian Meyer

Seit einem halben Jahr arbeite ich als Werkstudent, und zwar als Backend Entwickler, bei der Intervista AG (Berliner Str. 111, 14163 Potsdam), einem mittelständischen Unternehmen, dessen Kerngeschäft die Software Entwicklung ist. In dieser Firma werden die Anforderungen an die Software mit den Kunden anhand Prozessmodellen abgesprochen. Entwickler erkennen dann aus diesen wie die Software zu funktionieren hat und implementieren sie entsprechend. Firmenintern werden die Modelle immer Prozessmodelle genannt, weil sie Modelle einzelner Prozesse sind. Streng genommen sind es aber eher Aktivitätsdiagramme nach den Petri-Netz Regeln.

Die Intervista AG wünscht sich die Möglichkeit, die Modelle mit der aktuellen Implementierung vergleichen zu können, um so direkt zu erkennen, wo der Code nicht dem Modell entspricht. Zum einen kann der Code nicht richtig implementiert worden oder das Modell nicht mehr aktuell sein.

Da das Entwickeln des Tools sehr aufwendig ist, muss man die Entwicklung in 3 Schritte aufteilen:

• Modell → XML: Aus der Modell-Datei alle wichtigen Elemente herauslesen und die Relationen zwischen diesen erkennen bzw. herstellen. Dann dass Resultat in einer XML-Datei speichern.
• Code → XML: Aus dem Code heraus eine XML-Datei (nach dem gleichen Schema wie bei ‚Modell → XML‘) erstellen.
• Vergleich der XML-Dateien: Worin unterscheiden sie sich? Welche Änderung ist früher bzw. später gemacht worden? Haben sie trotz Unterschiede die gleiche Funktionalität?

Da das komplette Entwickeln eines solchen Tools viel zu umfangreich für eine Bachelorarbeit wäre, wird sich mein Hauptaugenmerk auf den Vergleich richten, und das Extrahieren einer vergleichbaren Struktur aus Code und Modell auf nur wenige Elemente beschränken. Für viele Zwischenschritte gibt es schon Werkzeuge, diese müssen im Laufe dieser Arbeit evaluiert werden.

Das Prozessmodell ist wie folgt zu lesen (aus Sicht des Entwicklers):

• Die meiste Logik kommt in die (Haupt-)Klasse, die so heißt wie das Prozessmodell (z.B. Identifizierung).
• Kreise mit dickem Rand haben einen Namen, dieser ist auch daran erkennbar, weil er unterstrichen ist. Dies sind Wartezustände und repräsentieren auch jeweils eine Klasse.
• Events können eingehend oder ausgehend sein, was man an der Pfeilrichtung erkennt. Events können von anderen Prozessen kommen, vom Frontend oder manuell erzeugt werden.
• Für jeden Typ von Event der reinkommt muss es eine Methode geben die auf diesen reagiert.
• Bedingungen stehen an den Pfeilen.
• In Rechtecken steht was der Prozess tun soll.

Vieles davon ist sehr leicht zu erkennen, wie z.B. Klassennamen, Vererbungen und Methodennamen, so dass dieser Schritt automatisiert werden könnte.

Die Prozessmodelle werden in Microsoft Visio erstellt, diese können mit einem Zip-Programm geöffnet werden und bestehen hauptsächlich aus XML. (https://docs.microsoft.com/en-us/previous-versions/windows/desktop/opc/open-packaging-conventions-overview).

In Java gibt es eine Bibliothek, die das Auslesen vereinfacht. (http://poi.apache.org/components/diagram/index.html)

Endresultat dieser Bachelorarbeit: Eine funktionierende Lösung für simple Vergleiche von Code und Modell.

Thesis Requirements

formulate requirements here (together with your adviser)

Milestones and Planning

A milestone is a scheduled event signifying the completion of a major deliverable or a set of related deliverables. A milestone has zero duration and no effort -- there is no work associated with a milestone. It is a flag in the workplan to signify some other work has completed. Usually a milestone is used as a project checkpoint to validate how the project is progressing and revalidate work. (Source: http://www.mariosalexandrou.com/definition/milestone.asp)

Milestone no.	Past		CW	Goals	accomplished
1		1	CWXX	Goals	accomplished

…

Weekly Status

Week 1 (CW XX)

Activities

• been there, done that
• …

Results

• achieved XYZ

Next Steps

• planning …

Problems

• …