"Was man zu verstehen gelernt hat, fürchtet man nicht mehr."
(Marie Curie)

Analysemuster

"Analysemuster" (engl.: "analysis patterns") sind - wie der Name schon sagt - Muster, also wiederkehrende Konstellationen von Irgendwas, die während der Analyse der Anforderungen hochkommen bzw. angewandt werden.

Dies kann beispielsweise eine Beziehung zwischen Lieferanten und Kunden sein, die beispielsweise in Form von Ärzten und Patienten, Beratern und Mandanten, Wohnungsverwaltern und Mietern oder auch Unternehmen und Subunternehmen in der Fachlichkeit auftauchen. Typischerweise handelt es sich hier immer um eine 1:n-Beziehung (ein Rechtsanwalt hat viele Mandanten) und beide haben eine Adresse, die die gleiche Struktur hat und deshalb letztendlich in der gleichen Basisklasse und damit in der gleichen Datenbanktabelle geführt wird. Hier kommt es dann auch im Datenmodell zu einer "Eltern-Kind"-Beziehung (engl.: "Parent-Child"), bei der ein Datensatz mit einem Fremdschlüssel auf einen anderen Datensatz der gleichen Tabelle verweist.

Ein ganz ähnliches Muster findet sich zwischen Organisationseinheiten, seien es Abteilungen oder Niederlassungen eines Unternehmens. Hier sehen Sie aber schon die Unterscheidung zwischen intern und extern, was im zweiten Schritt zu wesentlichen Unterschieden führen kann. So werden Abteilungen oft die gleiche Adresse haben, während Niederlassungen in aller Regel andere Adressen haben. Eine Niederlassung wird oft auch eine Angabe zur Unternehmensform haben, während eine Abteilung eher nur eine einfache Bezeichnung hat.

An dieser Stelle eine Warnung: wir sind in der Analysephase, so dass uns noch nicht interessiert, wie genau hinterher die Klassen oder gar die Datenbanktabellen aussehen. Das werden wir in der Designphase ermitteln, die sich dann ja sehr genau um das technische "wie" kümmert. Hier ist es im Moment erst einmal wichtig, dass vorherige Projekte gezeigt haben, dass Dinge wiederholt ähnlich implementiert wurden, die in folgenden Projekten bereits im Design als ähnlich wiedererkannt wurden und mittlerweile bereits in der Analyse als sich wiederholendes Muster erkannt werden. Wenn ich also in der Analyse der Fachlichkeit schon das bekannte Muster einer Standard-Lieferanten-Kunden-Beziehung erkenne, so sollte ich das auch in der Spezifikation der Anwendungsfälle erwähnen, um dem Designer bereits einen Hinweis zu geben.

Wenn Sie hier in einer kleinen Besetzung in einem kleinen Projekt unterwegs sind und der Analytiker auch das Design durchführt (Mehrfachrolle der Projektteilnehmer) und die Beauftragung der Designphase auch bereits klar oder sehr wahrscheinlich ist, so kann es natürlich auch durchaus hilfreich sein, hier ein wenig vorweg zu greifen, um den Sachverhalt bereits in einer ersten konzeptionellen Sicht auf ein logisches Klassenmodell darzustellen - wenn man sich des Vorgriffs bewusst ist, wird das nicht schaden! Ich persönlich halte es sogar auch bei größeren Projekten und größeren Teams für sehr sinnvoll, wenn der schon eingeplante Designer bereits so früh mit einbezogen wird (vielleicht nur mit einem halben Tag pro Woche), denn besser kann eine Einarbeitung für ihn nicht laufen und die Diskussion zwischen Analytiker und Designer ist hier oft sehr fruchtbar. Wir sollten nicht vergessen, dass hier die Schnittstelle zwischen Fachlichkeit und Technik bzw. zwischen "was" und "wie" liegt - oft ist dies die wichtigste, kleinste und schwierigste Schnittstelle im ganzen Team!

Es gibt auch Analysemuster, die einen viel stärkeren Einfluss auf die Anwendungsfälle und Prototypen als auf das Design der Modelle haben. Beispielsweise die CRUDs, eine Abkürzung für: Create (dt.: Erstellen oder Neu), Retrieve (dt.: Abrufen), Update (dt.: Aktualisieren oder Ändern) und Delete (dt.: Löschen). Sie werden bei der Analyse der Anforderungen und der damit verbundenen Fachlichkeiten immer wieder feststellen, dass Sie Fenster oder Seiten oder was auch immer benötigen werden, um den Umgang mit Informationen anwenderfreundlich zu gestalten.

Eine Adresse beispielsweise muss immer ein erstes Mal angelegt werden können und wird auch immer zur Verarbeitung an anderen Stellen abgerufen werden können müssen. In aller Regel wird eine Adresse auch mal verändert werden können müssen und oft muss eine Adresse sogar löschbar sein (auch wenn zur Historisierung oder Revisionssicherheit die Adresse nicht physikalisch gelöscht, sondern nur über ein Flag als gelöscht gekennzeichnet wird). Sie werden also in Ihrer Software wahrscheinlich Schaltflächen, Links, Menüpunkte, Funktionstastenbelegungen oder Ähnliches für "Neu", "Ändern" und "Löschen" finden und an verschiedenen Stellen noch so etwas wie "Adresse in Briefkopf einfügen", "Mitteilung senden an:" oder "Lieferadresse festlegen".

Diese Funktionalitäten werden in Applikationen sehr häufig gebraucht und in ihren Details leider sehr häufig unterschätzt; ganz einfach deshalb, weil sie kein nennenswertes technisches Problem darstellen, weil jedem klar ist, dass diese Funktionalität gebraucht wird und weil es immer noch wichtigere Dinge zu besprechen gibt als diese. Bei der genauen Analyse und Spezifikation und auch bei der Konstruktion und sogar bei der Beschreibung in der Bedienungsanleitung geht aber immer sehr viel Zeit für genau diese Routinearbeiten drauf und deshalb sollte man sie so früh wie möglich erkennen und fixieren können. Wenn ich in der Analysephase bei einem Anwendungsfall in einer ersten Iteration einfach erstmal nur "Muster CRU" notiere, so weiss jeder Leser, dass hier auf jeden Fall das besprochene Faktum erzeugt, abgerufen und geändert werden können muss (Löschen ist offensichtlich nicht gefordert). Das können beispielsweise drei Fenster sein: ein leeres zum Ausfüllen (Pflichtfelder, Reihenfolgen der Abhängigkeiten und Plausibilitäten beachten!), eins zum Suchen (ggf. Volltextrecherche mit Trefferliste mit verschiedenen Spalten und Sortiermöglichkeiten) und eins zum Anzeigen und Ändern (ggf. mit separat zu aktivierendem Schreibmodus nur bei besonderer Berechtigung nur für bestimmte Anwenderrollen; Plausibilitäten und Abhängigkeiten anderer Produktfunktionalitäten beachten!). Sie sehen, dass sich hier durchaus schnell drei mal drei Tage verstecken können und der Aufwand sehr von den Details abhängen kann! Es lohnt sich allemal, hierfür Prototypen zu skizzieren und diese mit dem Kunden zu besprechen.

Nebenstehend sehen Sie mich vor dem DIN A0 Ausdruck eines Dialog-Prototypen eines Anwendungsfalls für die Verwaltung von Verträgen mit Unterlieferanten in einer Intranet-Applikation. Dieser Anwendungsfall wurde eigentlich nur durch die CRUDs für "Projektliste", "Leistungsbilder" und "Vertragsprüfungen" erst komplex und ist auch in mehreren Analyse-Iterationen mit dem Kunden deutlich verändert und umgestaltet worden. Daher hing das Ding auch mehrere Wochen in meinem Büro an der Wand und war immer wieder mal für eine kleine Aufregung gut ;-) Ich war jedenfalls froh, dass ich frühzeitig die insgesamt fünf CRUDs in diesem AF erkannt und großzügig bei der Abschätzung berücksichtigt hatte.