Seite 3: Externe Schnittstellen

Inhaltsverzeichnis

Reviewer sollten die Außenwelt des Systems analysieren, also dessen externe Schnittstellen. Dazu ist erst mal sicherzustellen, dass sie überhaupt sämtliche Außenschnittstellen kennen – gerade in Business-Informationssystemen können das oft mehrere Dutzende sein. Ein Kontextdiagramm mag hier helfen – und falls es keines gibt, gibt es schon einen hilfreichen Verbesserungsvorschlag.

Welche dieser externen Schnittstellen verursachen im laufenden Betrieb Probleme? Hier sind möglicherweise die Verantwortlichen der Nachbarsysteme zu befragen, weil das System ja eventuell bei anderen Probleme verursacht. Wie schaut es mit eventuellen Service-Level Agreements dieser Schnittstellen bezüglich Verletzungen aus? Externen Schnittstellen im laufenden Betrieb "auf die Finger" zu schauen, funktioniert über die Untersuchung von Logfiles oder Monitoring nach Auffälligkeiten. Letztlich gilt es, die Implementierung externer Schnittstellen durch gezielte Code-Reviews zu überprüfen.

Besonderes Augenmerk benötigen solche externen Schnittstellen, deren Nutzung direkte Kosten verursacht (etwa: Aufrufe kostenpflichtiger Dienste) oder deren Definition oder Spezifikation sich häufig ändert.

Qualität im Griff?

Reviewer sollten untersuchen, inwieweit das System seine Qualitätsanforderungen erfüllt oder welche Qualitätseigenschaften nicht angemessen erreicht werden. Offensichtlich müssen sie dazu erst mal die Qualitätsanforderungen genau kennen: In vielen Jahren Review-Praxis hat der Autor nur wenige Systeme erlebt, bei denen es eine halbwegs aktuelle Übersicht davon gab. Meist war die spezifischen Qualitätsanforderungen im Rahmen des Reviews erst aufzuarbeiten.

Zum Glück gibt es dafür im Software- und Requirements Engineering etablierte Methoden, beispielsweise ATAM, die sich in Reviews in vereinfachter Form anwenden lassen. Zur Beschreibung von Qualitätsanforderungen verwendet der Autor sogenannte Szenarien (s. Abb. 3). Sie beschreiben in Umgangssprache, wie das System sich bei bestimmten Ereignissen verhalten soll. Falls das zu abstrakt klingt – in Tabelle 2 finden sich einige Beispiele.

Eigenschaft	Auslöser	Reaktion
Performance	Nutzer fordert den Monatsreport der Kostenstelle xyz an.	Das System erzeugt den Report innerhalb von 3 Sekunden.
Performance	Produktsuche mit Standardkriterien (Artikelbezeichnung/-nummer)	Dauert maximal 500 ms bis zur Anzeige der ersten 5 Treffer
Robustheit, Fehlertoleranz	Das externe System xyz antwortet mehr als 3 Sekunden lang nicht mehr.	Das System meldet diesen Fehler innerhalb von 30 Sekunden an den „Administrator vom Dienst“.
Flexibilität, Änderbarkeit	Der Fachbereich fordert eine Änderung des xyz-Tarifs im System.	Diese Änderung lässt sich innerhalb von 4 Stunden im System umsetzen.

Mit solchen konkreten Qualitätsanforderungen gestaltet sich die Analyse relativ einfach: Gemeinsam mit Architekten oder dem Entwicklungsteam untersuchen Reviewer, ob das System oder dessen Architektur die definierten Szenarien (= Qualitätsanforderungen) erfüllen kann. Hierzu sollte man sich die zugehörigen Architekturentscheidungen und -ansätze erläutern lassen. Hier hilft, gemeinsam mit den Beteiligten aus dem Entwicklungsteam diese Szenarien in Form von Walkthroughs durchzuspielen, möglichst detailliert und feingranular. Und es ist herauszufinden, wie die Bausteine des Systems zum Erreichen dieses Szenarios zusammenspielen und welche Entwurfsentscheidungen das jeweilige Szenario unterstützen. Dabei kann man sich einen Eindruck verschaffen, wie sicher sich die jeweiligen Qualitätsanforderungen erreichen lassen.

Aus Erfahrung bekommen Reviewer bereits in den Interviews viele Hinweise, welche Qualitätseigenschaften im System die meisten Probleme bereiten, sodass die detaillierte Analyse im Grunde die Bestätigung (oder Widerlegung) der geäußerten Defizite darstellt.

Architektur prüfen

Bevor der Artikel auf Details zu diesem wichtigen Aspekt von Reviews eingeht, eine kurze Zusammenfassung, was unter dem Begriff "Softwarearchitektur" zu verstehen und was demzufolge unter der Rubrik Architektur zu untersuchen ist. Es geht um folgende Aspekte:

• interne Struktur des Systems: die Modularisierung, den Schnitt des Systems, die Zerlegung in Subsysteme oder Komponenten. Idealerweise entspricht dieser Schnitt der fachlichen Struktur, neudeutsch der Domänenstruktur. Hierzu zählt auch das große Thema der internen Schnittstellen.
• querschnittliche Konzepte: Vorgaben zu Themen, die übergreifenden Charakter besitzen und sicherstellen, dass die Implementierung des Systems passenden Regeln folgt. Beispiele sind Aufbau und Gestaltung von Benutzungsschnittstellen (UI), Mechanismen zur Persistenz, Monitoring/Logging, Integration von Fremdsystemen.

Über die Prüfung der internen Struktur gibt es ganze Bücher [1] – kurz gefasst müssen Architekten dazu intensiv in den Code schauen (oder für ganz Mutige: Der hoffentlich vorhandenen Dokumentation glauben – wovon dringend abzuraten ist). Vermutlich ist der Code eines Systems jedoch so umfangreich, dass man für das Review lieber ein Analysewerkzeug (wie Sonargraph, Structure-101, ReSharper, Sotograph oder Lattix), einsetzt, dass aus dem Code eine Übersicht von Komponenten und deren Abhängigkeiten erzeugen kann. Die Abbildungen 4 und 5 zeigen zwei Beispiele solcher Analysen. Architekten bleibt die anspruchsvolle Aufgabe, diese grafischen Darstellungen zu interpretieren: Sind diese Komponentenstruktur respektive diese Abhängigkeiten angemessen für das System? Wo besteht zu enge Kopplung, und stellt die wirklich ein Problem dar?