Stefan Zörner
01.11.2008
Java Magazin, Kolumne "Architekturen dokumentieren", Folge 2
Waren Sie schon mal im Krimitheater? Samstagabend, 20:00 Uhr: Auf der Bühne liegt eine Leiche, ein Mord ist geschehen. Der Detektiv beginnt seine Arbeit und untersucht auf der Jagd nach Verdächtigen als erstes das Umfeld des Opfers, den Kontext. Wer hatte ein Motiv? Mit wem hat das Opfer zuletzt gesprochen?
Ihrer Softwarelösung wünsche ich natürlich nicht den baldigen IT-Tod – eine Umfeldanalyse ist aber auch hier von zentraler Bedeutung. Software agiert nicht allein, stets gibt es Beteiligte außerhalb des Systems. Anwendergruppen etwa, die Funktionalität nutzen und erwarten, oder Fremdsysteme, die zur Ausführung erforderlich sind.
Betrachten wir als Beispiel das Krimitheater. Zusätzlich zum traditionellen Verkauf möchte es seine Tickets in Zukunft über das Internet anbieten. Kunden sollen selbst Plätze aussuchen, und über Kreditkarte und PayPal bezahlen. Der Versand der Karten erfolgt als PDF über E-Mail. Ihre Aufgabe: Ein neues System entwerfen, das diese Anforderungen abdeckt, und sich in die bestehende IT-Landschaft der Theaterverwaltung einbettet. Nehmen Sie sich ein Beispiel am Detektiv und betrachten das Umfeld! Im Gespräch mit dem Auftraggeber finden Sie heraus, dass für die Verwaltung des Spielplans und das Drucken von Tickets bereits Systeme in Betrieb sind. Neben den Kunden sollen auch die Mitarbeiter der telefonischen Kartenvorbestellung in Zukunft Ihre neue Anwendung nutzen.
Zur Visualisierung des Umfelds ist das Systemkontextdiagramm ein nützliches Werkzeug. Es stellt das zu beschreibende System im Mittelpunkt als Blackbox dar. Drum herum sind die direkt beteiligten Benutzer und Fremdsysteme angeordnet. Eine Verbindung zwischen einem solchen Akteur und dem System drückt Interaktion aus. Die Abbildung zeigt ein Diagramm für unser Beispiel notiert in UML.
Wozu dient das alles? Zunächst einmal finden Sie so potenzielle Schnittstellen zum Zielsystem. Die Anbindung eines Fremdsystems ist regelmäßig ein technisches Risiko; solche frühzeitig zu erkennen kann entscheidend sein für den Erfolg Ihres Projektes.
Darüber hinaus können Sie mit Hilfe des Systemkontextes starten Verantwortlichkeiten zu klären. Welche Fremdsysteme müssen Sie integrieren? Was leistet Ihr System, und vor allem: was leistet es nicht? Wo ist die Systemgrenze? Zuweilen erfordert das Klären des Systemkontextes wirklich detektivischen Spürsinn: Die Wahrnehmungen unterschiedlicher Zeugen (Stakeholder) des aufzuklärenden Sachverhaltes variieren mitunter erheblich. Manch üblicher Verdächtige (Akteur) entpuppt sich als unschuldig, andere haben sich womöglich Pseudonyme zugelegt.
Zu unserem Beispiel: Muss der Ticket-Shop Kundendaten speichern, oder macht das ein anderes System? Wenn ja welches? Liegt es in unserem Verantwortungsbereich sicherzustellen, dass jeder Platz nur einmal pro Vorstellung verkauft wird? Oder macht das das TicketSystem? Was passiert, wenn eine Vorstellung abgesagt wird? Müssen wir die betroffenen Kunden benachrichtigen? Wie soll die Kreditkartenbezahlung integriert werden?
Neben der Analyse für neu zu entwerfende Systeme kann der Systemkontext auch eingesetzt werden, um ein abzulösendes System zu modellieren (nun doch eine Softwareleiche). Wenn Sie die Komplexität eines solchen Vorhabens abschätzen, ist es interessant zu wissen, mit welchen Fremdsystemen und Benutzern das alte System interagiert. Wer nutzt gegenwärtig die Funktionalität? Auf welche Systeme stützt es sich ab, um seine Leistungen zu erbringen? Diese Verbindungen werden vermutlich auch zum neuen System bestehen.
Ich habe das Diagramm oft erfolgreich in Workshops eingesetzt, bei Neuentwicklungen wie auch bei Systemablösungen. Schnell auf Flipchart oder Whiteboard geworfen ist es auch für UML-Laien intuitiv verständlich. Es hat stets frühzeitig wichtige Fragen herbeigeführt. Auch Sie werden bei der Erstellung viele offene Punkte ermitteln. Hier Verantwortlichkeiten festzulegen und Entscheidungen zu treffen ist Ihre Aufgabe als Architekt!
Zurück ins Theater. 22:30 Uhr, der Täter ist identifiziert. Er stammt aus dem Umfeld des Opfers, und stand in enger Beziehung zu ihm. Zur Entlarvung stellte der Detektiv viele Fragen. Schlusssatz Dr. Watson: „Brilliant, Holmes, brilliant“. Vorhang.
Zuerst erschienen hier:
Stefan Zörner: Kolumne Architekturen dokumentieren.
“Kombiniere – der Systemkontext”, Java Magazin, 11/2008, 1 Seite, S. 43
(mit freundlicher Genehmigung)