Klassendiagramme sind ein zentraler Bestandteil der UML und deren Einsatz im Requirements Engineering weit verbreitet. Zumeist werden Klassendiagramme genutzt, um die Struktur eines Systems zu verdeutlichen. Dabei werden Klassen mit deren Attributen in Beziehung zueinander gesetzt. Inhaltlich geht es dabei um fachlich wertvolle Objekte, deren Eigenschaften und Beziehungen untereinander, um datenorientierte Sichten auf ein System oder um die modellbasierte Darstellung von Glossaren.
Eine weitere Anwendungsmöglichkeit von UML-Klassendiagrammen stellt die Modellierung von User Interfaces dar. Wir konzentrieren uns in diesem Beitrag auf die Strukturen der Oberflächen, nicht auf deren Verhalten (wofür die Zustandsdiagramme der UML ein geeignetes Beschreibungsmittel sein können). Da wir diesen Modellierungsansatz weniger häufig als die oben genannten in der Praxis vorfinden, stellen wir ihn hier vor.
Problembeschreibung
Wir stellen uns ein Projekt vor, dessen Aufgabe es ist ein Onlineportal zu entwickeln, in dem Kunden Formulare online ausfüllen und einreichen können. Die folgenden drei Aspekte gibt es zu beachten:
- Für die Datenschutzabteilung muss ein Dokument erstellt werden, welches alle für die Nutzenden sichtbaren Bildschirmmasken enthält. Dieses Dokument soll nicht nur die Screenshots der Formularseiten beinhalten, sondern zu jeder Formularseite auch eine Ausgabe aller Oberflächentexte, Hilfetexte und die möglichen Validierungen eines jeden Feldes ausgeben.
- Zusätzlich gibt es die Anforderung ein Dokument für die Support-Abteilung zu erstellen. Dieses soll inhaltlich dem Dokument für die Datenschutzabteilung gleichen. Es soll den Mitarbeitenden im Support aber ermöglichen schnell zwischen den Formularseiten zu navigieren. So sollen Kundenanfragen zielgerichteter beantworten können.
- Darüber hinaus verfügt das eingesetzte Modellierungstool über eine API, die aus Diagrammen Code generieren kann. Hier stellt sich die Frage, ob die Modellierung von Oberflächen sinnvoll genutzt werden könnte, um Code zu generieren und den Entwicklern die Arbeit zu erleichtern.
Modellierungsbeispiel
Um diese drei Aspekte zu lösen, wurde ein Ansatz entwickelt, den wir zur besseren Visualisierung anhand folgender fiktiver Formularseite „Buchung“ vorstellen:
Für jede im System umgesetzte Formularseite wird ein Screenshot erzeugt, der im Modell abgelegt wird. Pro Formularseite gilt es eine eigene Klasse zu modellieren und diese mit der Oberflächengrafik der Formularseite zu verbinden. Die Attribute der Klasse entsprechen dabei den Eingabefeldern auf der Oberfläche. Je nach Art der Eingabe wird ihnen ein bestimmter Datentyp zugewiesen.
Für jedes Attribut können weitere oberflächenspezifische Angaben erfasst werden. Hierzu zählt zum Beispiel der Labeltext und eventuell vorhandene Hilfetexte (in unserem Fallbeispiel das Fragezeichen hinter der Checkbox zum Datenschutz).
Texte ohne Eingabefeld werden ebenfalls als Attribut der Klasse modelliert und der zugehörige Text erfasst. Diesen Textattributen wird kein Datentyp zugewiesen.
Darüber hinaus kann jedes Eingabefeld mit Validierungsregeln verknüpft werden. Diese werden als eigene Modellelemente modelliert und möglichst generisch gehalten, um sie mehrfach verwenden zu können. Das Feld „Vorname“ ist zum Beispiel ein Pflichtfeld. Versucht der Benutzer ohne Eingabe weiter zu navigieren, erscheint die Fehlermeldung “Bitte geben Sie einen Text ein“. Außerdem müssen mindestens drei Zeichen eingegeben werden und es sind nicht alle Sonderzeichen erlaubt. Verletzt der Benutzer einer dieser Validierungsregeln, erscheint ebenfalls eine Fehlermeldung.
Alle drei Validierungen gelten sowohl für das Eingabefeld „Vorname“ als auch für das Feld „Nachname“ und werden demnach mit beiden Feldern verknüpft. Welche Validierung vom System zuerst geprüft werden soll, kann mittels eines Zahlenwerts in einer weiteren Stereotypeigenschaft festgelegt werden. Je niedriger der vergebene Wert, desto höher ist die Priorität der Prüfung.
Falls bestimmte Eingabefelder auf mehreren Formularseiten vorhanden sind und deren Validierungen und Labeltexte die gleichen sind, werden diese Attribute in eigene Klassen ausgelagert. So können diese Klassen immer wieder verwendet werden. Ein typisches Beispiel hierfür sind Adressfelder.
Fazit
Dieses Vorgehen ermöglicht es, alle drei oben genannten Anforderungen zufriedenstellend zu bedienen:
- Für die Datenschutzabteilung wurde eine Exportfunktion entwickelt, die aus den Oberflächenmodellen ein Dokument mit allen benötigten Informationen generieren kann. Durch einen Knopfdruck kann zu jeder Zeit ein zielgruppenorientiertes Dokument erstellt und der Datenschutzabteilung übergeben werden.
- Für die Support-Abteilung wurde eine weitere Exportfunktion zur Verfügung gestellt, die eine Datei im HTML-Format erzeugt. So können die Mitarbeitenden im Support bequem und schnell auf die benötigte Formularseite springen.
- Über die API des Modellierungstools wird aus den Oberflächendiagrammen Code generiert. Dieser generierte Code dient den Entwicklern dann als Grundgerüst für die Implementierung der Oberfläche. In einer generierten Datei sind sämtliche Oberflächentexte zu finden. Dies erspart das Abtippen der Texte und minimiert Tippfehler seitens der Entwicklung. Bei Textänderungen ist es möglich, die Texte im Modellierungstool zu ändern und eine neue Datei zu generieren, welche dann im Code ersetzt werden kann.
Jedoch birgt das Vorgehen auch Nachteile:
- Gibt es viele Änderungen auf der Oberfläche, ist der Pflegeaufwand des Modells hoch. Bei jeder kleinen Textänderung auf der Oberfläche, muss das entsprechende Attribut im Modell angepasst, Code generiert, der Screenshot ausgetauscht und die Dokumente aktualisiert werden.
- Die Entwickler sind nur bedingt glücklich damit, dass ihnen der Code von einem Codegenerator zur Verfügung gestellt wird. Manuelle Anpassungen an den generierten Dateien durch die Entwickler sind nicht möglich, da die manuellen Änderungen durch das erneute Einfügen generierter Dateien überschrieben werden.
- Inzwischen sind wir daher dazu übergegangen, den Code einmal initial aus dem Modellierungstool zu generieren und bei späteren Änderungen nur noch die Datei mit den Oberflächentexten zu generieren.
Obwohl die Modellierung der Oberflächen relativ aufwändig ist, ergibt dieses Vorgehen in unserem Projektkontext Sinn. Das Oberflächenmodell dient im Projekt als „Single Point of truth“, aus dem sämtliche Dokumente, Textdateien für die Entwickler und fachliche Beschreibungen generiert werden. Die Pflege der verschiedenen Dokumente erfolgt daher aus einer verlässlichen und aktuellen Datenquelle und trägt somit zu einer konsistenten Dokumentation bei.
Da Anpassungen auf der Oberfläche aufgrund von Gesetzesänderungen häufiger vorkommen, besteht ein weiterer großer Vorteil für das Projekt darin, dass die Dokumente für den Support gleichzeitig mit dem Ausrollen der neuen Softwareversion jederzeit aktualisiert werden können.
Theresa Mühl
Theresa ist Requirements Engineer bei isento
