Blockdefinitionsdiagramm – ist das noch gut oder kann das weg?

Aufräumen, aussortieren und entsorgen – dafür nutzen gerade jetzt viele von uns ihre Zeit. Manchmal findet man dabei etwas wieder und entdeckt ganz neu, dass man einen wahren Schatz hortet. Holen wir doch einmal die Kiste mit der schon ein wenig verblassten Aufschrift „UML/SysML“ hervor. Schauen wir hinein und entdecken wir Schätze.

In dieser Kiste ist einiges drin: z.B. die Verhaltens- und Strukturdiagramme der SysML, außerdem das Requirements Diagramm, das eine Kategorie für sich darstellt. Wenn wir in den Strukturdiagrammen weiter stöbern, stoßen wir auf das Blockdefinitionsdiagramm (BDD). Wie steht es damit? Kann das weg oder gehört das vielleicht zu den Schätzen? Sehen wir genauer hin:

Was sind Blockdefinitionsdiagramme?

In BDDs wird die Struktur eines Systems und seiner Bestandteile beschrieben. Formal basieren BDDs auf Klassendiagrammen der UML – mit Ergänzungen und Einschränkungen durch die SysML. Wie in Klassendiagrammen können Elementhierarchien und Klassifikationsstrukturen abgebildet werden, darüber hinaus aber auch Interaktionen zwischen den zentralen Systemelementen, den Blöcken. Außerdem kann man in BDDs Beziehungen zwischen den Komponenten eines Systems und den Anforderungen, die sie erfüllen, sichtbar und nachvollziehbar machen. Allein das spricht bereits dafür, dass wir es hier mit einem Schatz zu tun haben.

Wann sollte man Blockdefinitionsdiagramme erstellen?

BDDs werden häufig ausschließlich der Designphase von Software bzw. von softwareintensiven Systemen zugeordnet. Diese Betrachtung ist viel zu eng. Es gibt nicht den einen Zeitpunkt für BDDs im Lebenszyklus von Software oder Systemen. Die logische oder physische Gliederung von Systemen findet im Verlauf der Entwicklung mehrfach statt – aus wechselnden Perspektiven und auf unterschiedlichem Abstraktionsniveau. Hier sind einige Beispiele für die Einsatzmöglichkeiten von BDDs:

• Lean Portfolio Management: BDDs können eingesetzt werden, wenn es darum geht, eine Makroarchitektur im Rahmen der Portfolioplanung zu entwickeln. Die Makroarchitektur hilft bei der Ausprägung der Portfolio-Vision und der Identifikation von Value Streams.
• SAFe^® Solution Management: BDDs sind bei großen SAFe^® Vorhaben ein nützlicher Bestandteil des Solution Intent, d.h. der Sammlung aller Informationen über das aktuelle und geplante Verhalten der angestrebten Lösung.
• Programminkrement-Planung in Vorhaben nach Essential SAFe^®: BDDs helfen zum Auftakt der Programminkrement-Planung die Sicht aller Beteiligten auf das Big Picture einer gemeinsamen Lösungsarchitektur auszurichten.
• Business Analyse und Requirements Engineering: BDDs sind zusammen mit den Requirements Diagrammen der SysML ein wirksames Instrument zur schrittweisen und koordinierten Verfeinerung von Anforderungsspezifikationen und Architekturentwurf sowie zur Herstellung von Traceability.
• Modellgetriebene Entwicklung (MDD): BDDs können – z.B. mit objectiF RPM – zur Codegenerierung für spezifische Technologie Stacks genutzt werden.

Blockdefinitionsdiagramme in objectiF RPM

Die Vielfalt der Einsatzmöglichkeiten von BDDs spiegelt sich auch in objectiF RPM wider. In den Portfolio-, Programm- und Projektvorlagen von objectiF RPM finden Sie bereits alles für die versionssichere Verwaltung von BDDs und ihren Elementen. Der schnelle Zugriff auf BDDs über die Themenleiste ist in allen Vorlagen ebenso vorbereitet wie die Generierung der Diagramme in die jeweilige Dokumentation.

Bleiben also keine Wünsche mehr offen, oder? Naja, die Antwort lautet:

Mehr Struktur geht immer

Nach der SysML hat jedes BDD einen Rahmen und Header-Informationen. Bestandteil des Headers ist u.a. der Name des mit dem Diagramm beschriebenen Modellelements. Das Modellelement definiert den Namespace, d.h. den Container für die im Diagramm gezeigten Elemente innerhalb der Modellhierarchie. objectiF RPM unterstützt neben UML/SysML Diagrammen auch Diagrammarten, die aus anderen methodischen Kontexten stammen und nicht in das Konzept einer strengen Modellhierarchie passen. Der Diagramm-Header besteht bei objectiF RPM deshalb aus dem „kleinsten gemeinsamen Nenner“: Diagrammtyp und Diagrammname. Natürlich werden BDDs und ihre Blöcke mit objectiF RPM in Packages verwaltet, haben also jeweils eine Zuordnung zu einem Namespace. objectiF RPM erlaubt es sogar, in einem BDD Blöcke darzustellen, die in verschiedenen Packages liegen. Die Zuordnung der Blöcke zu Namespaces sollte jedoch in BDDs sichtbar gemacht werden können. Das war eine Anforderung von Anwendern, die wir mit der aktuellen Version 6.4 von objectiF RPM umgesetzt haben.

Um Namespaces in BDDs abzubilden, nutzen wir das Konzept der Region, ähnlich wie Sie es aus den Aktivitätsdiagrammen kennen. Wie Namespaces in BDDs konkret sichtbar gemacht werden, zeigt das nachfolgende kurze Video.

Blockdefinitionsdiagramme sind ohne Zweifel ein methodischer Schatz, der sich auf vielen Ebenen der Entwicklung auszahlt. Heben Sie diesen Schatz doch mit objectiF RPM. Hier können Sie die aktuelle Version der Software kostenlos kennenlernen.