In diesem Blog-Beitrag möchten wir Ihnen einen Prozess zur Validierung von System-Architekturen gegenüber den System-Anforderungen vorstellen, um den System-Architekten im Umgang mit den sich ständig ändernden Anforderungen und bei der Analyse der Auswirkungen dieser Änderungen (Impact-Analyse) auf die System-Architektur zu unterstützen. Dazu verwenden wir die Modellierungssprache Unified Modelling Language (UML), die Sie im optimalen Fall bereits für die modellbasierte Dokumentation Ihres Systems einsetzen. Mit Hilfe des Validierungsprozesses lassen sich reproduzierbare Validierungsergebnisse erstellen, wobei der Arbeits- und Zeitaufwand des Architekten durch Automatisierungen und Werkzeugunterstützung reduziert wird. Er lässt sich an den aktuellen Entwicklungsstand anpassen, so dass zu Beginn der Entwicklung weniger detaillierte Informationen zur Validierung verwendet werden, die dann im Laufe der Entwicklung durch immer detailliertere ersetzt werden können. Auf diese Weise erhalten Sie auch eine fortschreitende Dokumentation des Architektur-Designs.
Mit steigender Komplexität der Systeme steigen auch die Anzahl der Anforderungen und deren Beziehungen untereinander. Der Architekt muss anhand der architekturrelevanten Anforderungen eine Architektur entwerfen und sicherstellen, dass diese auch wirklich den Anforderungen entspricht. Diese Validierung der Architektur gegenüber den Anforderungen ist ein arbeitsintensiver und zeitaufwendiger Vorgang, der bei jeder Änderung eines Einflussfaktors, z.B. einer Anforderung, wiederholt werden muss. Dabei beobachten wir häufig folgendes Vorgehen:
Der Architekt erstellt einen ersten Architekturentwurf und verfeinert diesen iterativ. Für die Validierung wird die Methode des scharfen Hinsehens verwendet. Damit ist ein manueller Abgleich der Architektur mit den Anforderungen ohne ein definiertes Vorgehen gemeint, was zum unabsichtlichen Auslassen einiger Aspekte führen kann. Die Validierung beruht auf Abschätzungen, die auf Erfahrungen des Architekten basieren, und nur selten, meist bei kritischen Anforderungen, auf belegbaren Zahlen. Aufgrund des Zeit- und Arbeitsaufwands wird die Dokumentation und Validierung nur für bestimmte, beispielsweise Review-Termine vollständig durchgeführt.
Wir halten dieses Vorgehen für die Entwicklung komplexer Systeme für unzureichend, da Entscheidungen auf Basis von Gefühlen getroffen werden und die Dokumentation vernachlässigt wird. Zur Unterstützung des Architekten haben wir einen partiell automatisierbaren, modellgetriebenen Validierungsprozess entwickelt, der in das iterative Vorgehen zum Entwurf der System-Architektur integriert wird.
Aus den System-Anforderungen ermittelt der System-Architekt die Anforderungen, die bei der Erstellung der System-Architektur zu berücksichtigen sind. Hier sind vor allem die nicht-funktionalen Anforderungen von Bedeutung, weil sie die grundsätzlich möglichen Architektur-Designs einschränken. Für die Anforderungen wird mindestens vorausgesetzt, dass sie getestet werden können. Der System-Architekt ordnet den ermittelten Anforderungen Validierungsziele zu. Ein Validierungsziel entspricht einem architekturspezifischen Aspekt, der bei der Validierung berücksichtigt werden muss. Beispiele für solche Aspekte sind Energieverbrauch, Kosten, Verarbeitungsgeschwindigkeit, Datenkommunikation usw., vereinfacht gesagt die verschiedenen Arten nicht-funktionaler Anforderungen.
Für jedes Validierungsziel legt der System-Architekt nun ein Validierungszielverfahren fest, mit dem festgestellt werden kann, ob die modellierte System-Architektur auch den zugeordneten Anforderungen entspricht. Das Verfahren lässt sich im Zuge der Entwicklung auswechseln, um den für die Validierung benötigten und vom Entwicklungsstand möglichen Detaillierungsgrad gerecht zu werden. Für das Beispiel Energieverbrauch kann in einer frühen Entwicklungsphase zunächst die Summe aller vom Hersteller angegebenen Werte der Hardware-Bauteile zur Bestimmung des Gesamtenergieverbrauchs gebildet werden. Im Laufe der Entwicklung lässt sich dieses Verfahren verändern, so dass beispielsweise die Auslastung von Prozessoren, Speichernutzung und Kommunikation berücksichtigt werden. Falls Sie bereits Simulationen besitzen, deren Ergebnisse zur Validierung verwendet werden können, erlaubt Ihnen der Validierungsprozess auch die Einbindung dieser als Validierungszielverfahren.
Aus den Validierungszielverfahren folgt, welche Informationen für die Validierung benötigt werden. Diese legt er in einem separaten UML-Modell auf Basis einer validierungszielspezifischen Notation ab. Dieses sogenannte Validierungsmodell dient einerseits Dokumentationszwecken und andererseits als Datenquelle für die Validierungszielverfahren. Falls Sie bereits eine modellbasierte Dokumentation Ihrer System-Entwicklung besitzen, können Sie die in diesem Entwicklungsmodell vorhandenen und für die Validierung benötigten Daten in das Validierungsmodell übernehmen.
Nun kann der System-Architekt die Validierung der System-Architektur starten. Sie ist erfolgreich, falls die Ergebnisse aller Validierungszielverfahren die Testkriterien der betrachteten Anforderungen erfüllen. Ist dies nicht der Fall, muss der System-Architekt ein passendes Design finden. Hierzu bearbeitet er zunächst das Validierungsmodell, bis er eine System-Architektur gefunden hat, die die Validierungsziele erfüllt. In diesem Fall werden dann alle im Validierungsmodell durchgeführten für das Entwicklungsmodell relevanten Änderungen in eben dieses übernommen.
Die System-Architektur muss erneut validiert werden, sobald sich Anforderungen ändern, wegfallen oder neue hinzukommen. Bei neuen Anforderungen müssen diese vorhandenen oder neuen Validierungsziele zugeordnet werden, und der weitere Prozess kann erneut durchgeführt werden.
Für Fragen zu dem beschrieben Validierungsprozess und Unterstützung in Ihren Projekten stehen Ihnen die SOPHISTen gerne zur Verfügung.