Diese Frage habe ich mir in den letzten Jahren sehr häufig gestellt. Ich war während meiner Mitarbeit in mehreren großen Software-Projekten immer wieder mit sehr aufwändig erstellten Fachklassenmodellen konfrontiert. Die meisten dieser Projekte hatten kein agiles Vorgehen. Die Fachklassen waren deshalb Ergebnis der Fachkonzeption.

Können wir in agilen Projekten auf die Beschreibung von Fachklassen verzichten?

Zielgruppen

Eine Fachklasse ist eine fachlich motivierte Klasse, die einen komplexen Begriff aus dem Problembereich des zu entwickelnden Systems repräsentiert. Sie ist ein Ergebnis der Anforderungsanalyse. Fachklassen benutzen wir, um reale Objekte zu beschreiben.

Wir müssen bedenken, dass verschiedene Personen bezüglich der Aufbereitung von Anforderungen unterschiedliche Bedürfnisse haben. Manch einer braucht ein Bild, um Zusammenhänge zu verstehen, wo andere nur eine griffige Beschreibung brauchen. Weil wir zielgruppenorientiert sein wollen, ergibt sich allein dadurch schon der Bedarf an Fachklassen. Das bedeutet aber keineswegs, dass für jedes Informationsobjekt der Domäne ein Fachklassenmodell notwendig ist.

ktip Eine Fachklasse wird grafisch in einem UML-Klassendiagramm dargestellt. UML hat den Vorteil, dass sehr viele Stakeholder und Projektmitarbeiter so ein Klassendiagramm “lesen” können.

Eine Fachklasse enthält eine geballte Menge fachlicher Informationen: Piktogramme, Verbindungen, Stereotypen oder Annotationen, um nur die wichtigsten Elemente zu nennen. Die Elemente selbst enthalten zusätzlich noch Kommentare, mit Texten, wie wir sie von einem Glossar kennen. Es steckt also sehr viel Wissen in so einer Fachklasse.

Verfügbarkeit

Das Werkzeug für die Bearbeitung eines UML-Diagrammes (z.B. Enterprise Architect) ist nicht immer einfach in der Verwendung. Nicht jeder Projektmitarbeiter hat Zugriff auf das Programm oder kann es ausreichend sicher bedienen. Unser Ziel muss es daher sein, dass ein Fachklassenmodell für jeden Leser ohne Informationsverlust lesbar ist. Wir müssen es schaffen, dass allein durch die bildhafte Darstellung alle wesentlichen Informationen erkennbar sind. Denn dann können wir die Diagramme als einfache Bilder (z.B. als PNG) exportieren und so im Glossar verwenden. Das ist auf den ersten Blick sehr sinnvoll und in vielen Fällen auch vollkommen ausreichend.

Ein Problem ist, dass beim Export der Bilder alle Kommentare verloren gehen. Anders als in den Werkzeugen, in denen wir das Diagramm bearbeiten, öffnet ein Klick auf eine Element des Diagrammes kein Fenster mit Erläuterungen und Kommentaren. Auch die Lesbarkeit von exportierten Bilden ist nicht immer ideal. Die Darstellung von Texten im Werkzeug und exportiert als Bild unterscheidet sich. Was im Werkzeug gut lesbar und übersichtlich wirkt, ist als Bild wegen zu kleiner Schrift nicht mehr gut lesbar.

Bildsprache

Eine einfache Lösung ist es, Kommentare nicht mehr im UML-Diagramm zu hinterlegen, sondern gleich im Glossar. Das erscheint in der klassischen Verwendung von UML-Diagrammen, wie wir es aus dem technischen Design kennen, sehr umständlich. Darum empfehle ich eine besondere Verwendung von Klassendiagrammen zur Darstellung von Fachklassen in der Anforderungsanalyse.

ktip UML-Klassendiagramme im technischen Design und in der Anforderungsanalyse unterscheiden sich. Fachklassenmodelle sind nicht mehr geeignet für eine direkte Übersetzung in Code. Sie dienen vorrangig der Erklärung von Begriffen.

Die Idee ist, dass so ein Fachklassenmodell im wesentlichen nur aus Klassen und Relationen bestehen. Ein einzelnes Klassendiagramm beschreibt nur ein einziges Informationsobjekt. Es hat keine oder nur ganz wenige einfache Attribute. Wichtige Attribute modellieren wir als Klassen, mit einer Assoziation der Kardinalität 1. Dadurch machen wir diese wichtigen Attribute besser sichtbar. Attribute verwenden wir nur mehr, um wichtige Eigenschaften anzugeben, ohne Anspruch auf Vollständigkeit.

Das Ziel ist es, dass wir auf diese Weise ein Informationsobjekt der fachlichen Domäne mit einem Blick erfassen können. So ein Bild eignet sich dadurch hervorragend für die Verwendung im Glossar. Leser können sich je nach Vorliebe ein Bild anschauen oder die Beschreibung lesen, um sich über einen Begriff zu informieren.

Fazit

Fachklassen haben einen Wert für ein vertieftes Verständnis der fachlichen Domäne. Sie sind eine nützliche Ergänzung zum Glossar mit dem Ziel, Fachbegriffe gut und genau zu erklären. Es ist sehr wichtig, dass die Namen der Fachklassen für die Bezeichner von Klassen, Methoden oder Attribute im Code verwendet werden. Dadurch erhalten wir lesbaren Code. Fachklassen lassen sich nicht mehr direkt für die Implementierung verwenden. Eine Generierung von Code ist faktisch ausgeschlossen bzw. ist nicht sinnvoll.  Aufgrund der Reduktion auf das für das Verständnis Notwendige  sind die Fachklassen auch robust bei Änderungen am Code. Denn Entwickler ändern gerne und oft an den Details, aber wichtige Begriffe ändern auch Entwicklern nicht ohne triftigen Grund.