Im ersten Teil unserer Blog-Serie haben wir Ihnen zwei Verbindungsmöglichkeiten von den Kunden-Anforderungen zu den Use Cases vorgestellt. Sie können dazu die Anforderungselemente aus der System Modeling Language (SysML) oder die Kommentarfelder der Use Cases, gefüllt mit den Anforderungen oder deren IDs, verwenden. Im zweiten Teil haben wir Ihnen die Modellierung der System-Architektur am Beispiel von drei Sichten beschrieben, die Verbindung der Design-Elemente untereinander und mit den Analyse-Elementen aber ausgelassen, um diese im Gesamtzusammenhang des Nachverfolgbarkeits-Konzeptes in diesem dritten und letzten Teil zu beschreiben. Das Konzept ermöglicht es Ihnen, die Kunden-Anforderungen über die UML-Elemente der Analyse bis hin zur System-Architektur zu verfolgen, was beispielsweise eine große Unterstützung bei der Impact-Analyse nach Anforderungsänderungen oder bei der Wartung des realisierten Systems ist.
Wir beschreiben zunächst in Kapitel 7 das Nachverfolgbarkeits-Konzept mit seinen Verbindungen zwischen den UML-Elementen und in Kapitel 8 einige Möglichkeiten zur Auswertung dieser Verbindungen. Zu guter Letzt fassen wir die Inhalte der Blog-Serie noch einmal in Kurzform zusammen.
Wir haben uns in dieser Übersicht für die Requirements-Elemente der SysML zur Modellierung der Kunden-Anforderungen entschieden.
Abbildung 1: Übersicht Nachverfolgbarkeits-Konzept
Die Kunden-Anforderungen werden über trace-Verbindungen mit den UML-Elementen in der Analyse, hier stellvertretend durch Aktivitäten, Zustände und Use Cases dargestellt, verbunden. Um die Elemente der Analyse während der Designphase nicht nachträglich zu verändern, werden sie nicht direkt, sondern über duplizierte Elemente verwendet. Dadurch können Sie beispielsweise den Name einer Analyse-Aktivität im Design verändern oder eine architekturspezifische Verfeinerung modellieren, selbst wenn Sie diese Aktivität bereits in der Analyse architekturunabhängig verfeinert haben. Durch eine trace-Beziehung bleibt die Verbindung zwischen diesen Elementen erhalten. Die in Abbildung 1 dargestellten Duplikate der Use Cases, Aktivitäten und Zustände stehen stellvertretend für die möglichen UML-Elemente aus der Analyse, die von einer Software-Komponente realisiert werden können.
Welche Funktionalitäten des Systems eine Software-Komponente realisieren muss, wird über realize-Beziehungen festgelegt. Diese werden von den Software-Komponenten zu den Duplikaten der Analyse-Elemente und zu den architekturspezifischen Elementen modelliert. Architekturspezifische Elemente werden benötigt, um Verhalten, das nur durch die Wahl der System-Architektur entsteht, zu modellieren. Dies kann zum Beispiel die Umwandlung von optische in elektrische Signale oder die Aufteilung und das anschließende Zusammenfügen einer Datenmenge zur Verarbeitung auf mehreren Prozessoren sein. Da diese Elemente architekturspezifisch sind, ist keine Verbindung zu den Kunden-Anforderungen, die lösungsneutral formuliert sein sollten, erforderlich.
Die realize-Beziehungen müssen nicht zwingend zu den einzelnen Komponenten der Architektur gezogen werden. Je nach Anwendungsgebiet bietet es sich an, die Funktionalitäten aus der Systemanalyse mit Anforderungen an die Komponenten zu verbinden. Dies dient insbesondere bei Fremdbeauftragungen der Komponenten zur Nachvollziehbarkeit zu den Systemanforderungen, wenn während der Realisierung der Komponenten Änderungen an den Komponentenanforderungen auftreten.
Unter der Voraussetzung, dass die vorgestellten Beziehungen zwischen den UML-Elementen richtig und vollständig modelliert wurden, können Sie die beispielsweise die folgenden Auswertungen automatisiert oder von Hand vornehmen:
- Suche von Goldrandlösungen,
- Finden der von Anforderungsänderungen betroffenen UML-Elemente,
- Vollständigkeitsprüfung der im Design modellierten Funktionalitäten gegenüber den Analyse-Ergebnissen,
- Vollständigkeitsprüfung der durch die Software-Komponenten realisierten Funktionalitäten gegenüber den modellierten Funktionalitäten und
- Prüfen, ob jede Software-Komponente einer Hardware-Komponente zugeordnet ist.
Durch das Hinzufügen zusätzlicher Informationen zu den UML-Elementen des Modells, sind noch weitergehende Prüfungen, beispielsweise die Auslastung der einzelnen Prozessoren, und der Abgleich der Ergebnisse gegenüber den (System-) Anforderungen möglich. Auf dieses Thema werden wir in dieser Blog-Serie aber nicht näher eingehen.
Unter Goldrandlösungen verstehen wir Funktionalitäten, für die es keine Anforderungen von Seiten des Kunden gibt. Sie entstehen zum Beispiel durch die Interpretation der Entwickler, dass ein Kunde eine Funktionalität benötigt oder hilfreich finden wird. Obwohl das vorgestellte Konzept nicht ausreichend für kritische Systeme ist, lässt sich an diesem trotzdem das Prinzip erklären. Die einer Software-Komponenten zugeordneten, nicht architekturspezifischen Funktionalitäten müssen direkt oder indirekt über weitere UML-Elemente durch trace– und realize-Beziehungen mit Kunden-Anforderungen verbunden sein. Alle nicht auf eine Kunden-Anforderung verweisenden architekturunabhängigen Funktionalitäten sind Goldrandlösungen.
Das Nachverfolgbarkeits-Konzept unterstützt Sie bei der Impact-Analyse nach Anforderungsänderungen, indem Sie alle mit einer veränderten Kunden-Anforderung verbundenen UML-Elemente ermitteln. Dazu verfolgen Sie die trace-Beziehungen der Kunden-Anforderung zu den Analyse-Elementen, von diesen aus weiter zu den Duplikaten und über deren realize-Verbindung(en) zu den Software-Komponenten. Über die executedOn-Beziehung finden Sie sogar heraus auf welcher Hardware-Komponente die von den Änderungen betroffenen Software-Komponenten ausgeführt werden.
Beim Übergang zwischen der Analyse und dem Design kann es vorkommen, dass einige Elemente in der Analyse bei der Erstellung des Designs übersehen werden. Je später dies festgestellt wird, desto höher sind im Allgemeinen der Aufwand und die damit verbundenen Kosten zur Behebung des Fehlers. Durch die Auswertung der trace-Beziehungen zwischen den Analyse-Elementen und deren Duplikate im Design können Sie diesem Problem bereits während der Designphase aus dem Weg gehen. Besitzt ein Analyse-Element keine trace-Verbindung zu einem Element im Design, wurde es übersehen und das Design muss nachgebessert werden.
Ein wichtiges Ziel der Designphase ist die Zuordnung der Funktionalitäten zu den Software-Komponenten. Ähnlich wie beim Übergang zwischen Analyse und Design darf hier keine Funktionalität, jetzt aber architekturunabhängig und –spezifisch, übersehen werden. Dies ist sichergestellt, falls jedes Analyse-Duplikat oder architekturspezifisches Element eine realize-Verbindung zu einer Software-Komponente besitzt.
In unserer dreiteiligen Blog-Serie haben wir Ihnen einen praxisorientierten Überblick zur modellbasierten Dokumentation der Systementwicklung mit Hilfe der Unified Modeling Language (UML) gegeben. Im ersten Teil haben wir uns auf die Ziele der Analyse-Phase, den Modellierungsmöglichkeiten der UML zur Beschreibung des Systemverhaltens, die Verbindung der Anforderungen mit den UML-Elementen und dem Problem des unterschiedlichen Sprachverständnisses durch verschiedene Stakeholder konzentriert. Im zweiten Teil haben wir Ihnen die Ziele der Designphase und die Modellierung der System-Architektur mit Hilfe von verschiedenen Sichten vorgestellt. Wir haben dazu das bereits im ersten Teil verwendete Bibliotheksbeispiel erweitert und die System-Architektur mit Hilfe der logischen, physikalischen und funktionalen Sicht modelliert. Die Verbindung der Analyse- und Design-Elementen, der Design-Elemente untereinander und die Auswertungsmöglichkeiten durch die Anwendung dieses Nachverfolgbarkeits-Konzept haben wir Ihnen im dritten Teil vorgestellt. Die Möglichkeit zur Auswertung ist der große Vorteil bei der Verwendung von Modellen für die Dokumentation. Der anfängliche Mehraufwand egalisiert sich unserer Erfahrung nach bereits nach kurzer Entwicklungszeit. Für Fragen und Unterstützung in Ihren Projekten stehen die SOPHISTen Ihnen gerne zur Verfügung.