Funktion und funktionaler Block - eine Abgrenzung

Dieser Artikel stammt aus unserem Blog, der nicht mehr betreut wird. Für Neuigkeiten zu oose und interessante Inhalte zu unseren Themen, folgt uns gerne auf LinkedIn.

Kürzlich leitete ich einen MBSE-Workshop in dem wir die FAS-Methode einsetzten. Wir beschrieben erst die Funktionen des Systems, danach ordneten wir sie funktionalen Blöcken zu. Da einige der so gefundenen funktionalen Blöcke nur eine einzige Funktion unterstützten, stand bald die Frage im Raum: Was ist überhaupt der Mehrwert der Modellierung von funktionalen Blöcken?

Funktionaler Block am Beispiel eines Heizungssystems

Schauen wir uns das anhand des Beispiels "Heizungssystem" an.

Ein Heizungssystem kann dafür verwendet werden, ein Gebäude in kalter Witterung bewohnbar zu machen. Dieser Anwendungsfall wird analysiert, eine Basisarchitektur wird zu Grunde gelegt und nach einigen Schritten kommt man zu einer Liste von Funktionen.

Diese Funktionen haben Ein- und Ausgaben. Das können Parameter oder Nachrichten sein. Bei "do pump" ist zum Beispiel Flüssigkeit der In- und Output-Parameter und bei "control pump" sind es Signale zum Ein- und  Ausschalten der Pumpe.

Beide Funktionen werden einem funktionalen Block zugeordnet. Dadurch ergeben sich Schnittstellen, die der funktionale Block seinen Benutzern anbietet. Dies kann man direkt von den zugeordneten Funktionen ableiten. Dabei werden die Signale aus der Zustandsmaschine zu Receptions im Interface-Block und die Typen der Parameter werden zu einer Flusseigenschaft.Im folgenden Diagramm sind die Zusammenhänge zwischen Interfaces und Parameter und Nachrichten eingezeichnet. Normalerweise sind sie nicht sichtbar oder nur mit einigen Klimmzügen darstellbar. Hier habe ich einfach gestrichelte Linien verwendet.

Meine Beobachtungen aus dem "Heizungssystem"

Man sieht also: Schnittstellen definieren eine Art von Vertrag, mit dem für einen Block beschrieben wird, welche Signale und Items man an ihn schicken kann und welche er selbst unter bestimmten Umständen schicken könnte. Parameter und Signale einer Funktion definieren dagegen, durch welchen Auslöser eine Funktion gestartet oder weitergeschaltet wird und was sie - während sie läuft und am Ende - liefert. Eine Funktion kann mehrere Schnittstellen bedienen und an einer Schnittstelle können mehrere Funktionen erreichbar sein.

Die Auswirkungen könnten auch durch eine Zusicherung (Constraint) beschrieben werden, wenn der Ablauf sehr einfach ist. Zum Beispiel bei einem Widerstand, bei dem die hier gewählte Aktivität wahrscheinlich überflüssig ist. Dieses Beispiel zeigt aber sehr schön, dass auch wenn es vielleicht nicht nötig sein sollte, Funktion und Block zu modellieren, man das zum Modellierungszweck passende Element wählen sollte. Möchte man die funktionale Dekomposition darstellen, braucht man Funktionen und für eine funktionale Architektur braucht man funktionale Blöcke.

Ohne klare Trennung geht's nicht!

Meine Beobachtungen aus dem hier beschriebenen Beispiel führen mich zu folgendem Fazit: Funktionen und funktionale Blöcke müssen klar voneinander unterschieden werden. Mit Blöcken und ihren Interfaces werden nur potentielle Interaktionen definiert. Um die Auswirkungen der Interaktionen zu beschreiben, braucht man Funktionen. Wird das nicht gebraucht, kann eine Darstellung mit funktionalen Blöcken ausreichend sein. Man sollte sich dann bewusst sein, dass der funktionale Block implizit mindestens eine Funktion unterstützt.