Waren Sie schon einmal 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. Abbildung 1 zeigt ein Diagramm für unser Beispiel, notiert in UML.
Wozu dient das alles? Zunächst finden Sie so potenzielle Schnittstellen zum Zielsystem. Die Anbindung eines Fremdsystems ist regelmäßig ein technisches Risiko – solche frühzeitig zu erkennen kann entscheidend für den Erfolg Ihres Projekts sein. Darüber hinaus können Sie mithilfe des Systemkontexts damit beginnen, 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 Systemkontexts 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 Ticketshop Kundendaten speichern oder macht das ein anderes System? Wenn ja, dann 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: "Brillant, Holmes, brillant!". Vorhang zu!
Stefan Zörner ist Anwendungsarchitekt, Berater, Trainer und Coach bei der oose Innovative Informatik GmbH in Hamburg. Er arbeitet dort im Bereich Software-Engineering, ist Autor zweier Bücher und zahlreicher Fachartikel rund um Java, u.a. im Java Magazin und bei IBM developerWorks. Darüber hinaus ist er seit 2005 Committer im Directory Project der Apache Software Foundation.
