RFLP: Logical Viewpoint

Das „L“ im RFLP-Ansatz von SPES2020

Im letzten Blogbeitrag im Januar haben wir Ihnen den Functional Viewpoint vorgestellt. Im Functional Viewpoint werden aus Anforderungen aus Kundensicht Funktionen erzeugt, welche das System umsetzt. Zur Umsetzung der Funktionen benötigt das System Architekturelemente. Heute zeigen wir Ihnen, wie Sie logische Architekturelemente dokumentieren können.

Ziel und Zweck

Der Logical Viewpoint stellt logische Architekturelemente des betrachteten Systems dar. Logische Architekturelemente sind beispielsweise Controllerkomponenten, die später von physischen Architekturelementen realisiert werden.

Somit entkoppelt der Logical Viewpoint die konkreten technischen Anforderungen an die physischen Architekturelemente von den Anforderungen an das logische System und verbessert die Wiederverwendung von Anforderungen und Funktionen in unterschiedlichen technischen Realisierungen. Zum einen hilft der Logical Viewpoint die Komplexität zu beherrschen und zum anderen verringert der Logical Viewpoint Aufwände in der Entwicklung bei hoher technischer Varianz, da physikalische Architekturelemente im Physical Viewpoint verändert werden können, ohne dass die logischen Elemente im Logical Viewpoint beeinflusst werden.

Inhalte, Diagramme und Notationselemente

Der Logical Viewpoint sollte unbedingt strukturelle Sichten zur logischen Repräsentation der physischen Architekturelemente (Blackbox) und deren Zusammenspiel untereinander inkl. Schnittstellen (Whitebox) enthalten.

Für die Modellierung der Blackbox-Sicht können Sie das Komponentendiagramm aus der UML oder das Blockdefinitionsdiagramm aus der SysML verwenden.

Folgende Notationselemente zur Ausgestaltung der Diagramme empfehlen wir:

  • Komponenten (Blöcke)
  • Schnittstellen
  • Ein- und ausgehende Schnittstellen
  • Ports und Informationsflüsse
Blackbox-Sicht als Blockdefinitionsdiagramm (SysML) auf ein logisches Architekturelement des SHS-Beispiels

Für die Modellierung der Whitebox-Sicht können Sie das Kompositionsstrukturdiagramm aus der UML oder das interne Blockdiagramm aus der SysML verwenden.

Folgende Notationselemente zur Ausgestaltung der Diagramme empfehlen wir:

  • Komponenten (Blöcke)
  • Schnittstellen
  • Ein- und ausgehende Schnittstellen
  • Ports und Informationsflüsse

Die Logical Viewpoint gibt Auskunft darüber, welche Arten von Informationen ein Architekturelement grundsätzlich für die Umsetzung der Funktionen liefern muss. In der Abbildung erkennt man, dass das logische System beispielsweise einen Gebäudestatus senden muss.  Es ist jedoch nicht zu erkennen, wie der Status technisch realisiert wird. In Branchen mit häufiger technischer Veränderung ist der Logical Viewpoint ein großer Vorteil.  

Haben Sie schon Erfahrung mit dem Functional Viewpoint gemacht oder haben Sie Anmerkungen? Hinterlassen Sie uns gerne einen Kommentar. Oder schreiben Sie uns Ihre

Erfahrungen per Email an vertrieb@sophist.de.

Letztendlich können nur physikalische Architekturelemente die Funktionen des Systems ausführen und die Anforderungen des Kunden umsetzen. Im nächsten Beitrag beschäftigen wir uns mit den physikalischen Architekturelementen, also dem letzten Viewpoint des RFLP-Ansatzes, dem Physical Viewpoint.

Viele Grüße!

Lesen Sie die weiteren Beiträge aus dieser Serie:

Teil 1: Architektur im SE: Anforderungs- und Architekturmodelle strukturiert aufbauen

Teil 2: RFLP: Gelebte Trennung zwischen Aspekten im Systems Engineering

Teil 3: RFLP: Requirements Viewpoint

Teil 4: RFLP: Functional Viewpoint

Teil 6: RFLP: Physical Viewpoint

Teil 7: Erkenntnisse aus Innovationsprojekt „Architektur im SE“

2 Gedanken zu „RFLP: Logical Viewpoint

  1. Hallo Sophisten,

    mir erscheint es so, als ob der Kern der logischen Sicht gemäß RFLP (aus dem SPES Ansatz) nicht getroffen wurde.
    Im Buch steht dazu (als zweiter Satz der Beschreibung der logischen Sicht):
    “The main task in the logical viewpoint is the distribution of functions to a hierarchy of logical components.”
    Sie schreiben: “Logische Architekturelemente sind beispielsweise Controllerkomponenten, die später von physischen Architekturelementen realisiert werden.”

    Die Entstehung der logischen Systeme ist somit sehr unterschiedlich definiert. Bei SPES rein aus den identifizierten und (fachlich passenden) Funktionen und bei ihnen aus einer Abstraktion einer erwarteten technischen Realisierung.

    Im weiteren Verlauf schreiben sie:
    “Der Logical Viewpoint sollte unbedingt strukturelle Sichten zur logischen Repräsentation der physischen Architekturelemente (Blackbox) und deren Zusammenspiel untereinander inkl. Schnittstellen (Whitebox) enthalten.”

    Diesen Satz versteh ich nicht so ganz, aber wenn es heißen soll, dass eine Struktursicht von logischen Elementen eine Blackbox-Sicht der physischen Architektur ist, dann passt das nicht mit meinem Verständnis vom Zusammenhang zwischen funktional-logischen Architekturen und funktional-technischen Architekturen.
    Aus meiner Sicht muss bei der Ableitung von technischen Architekturen aus einer logischen Architektur darauf geachtet werden, dass der Funktionsschnitt (da die Funktionen ja zu “ihren” Systemen korrespondieren müssen) entsprechend des Systemschnitt ggf. angepasst wird.

    Grüße,
    Ingo

    • Hallo Ingo,

      vielen Dank für Ihren Kommentar.

      Zu Ihrem ersten Punkt:
      Sie haben Recht, wenn Sie sagen, dass SPES die logischen Systeme aus den Funktionen ableitet. Jedoch sehe ich keinen Widerspruch dazu in diesem Blogbeitrag.
      Es geht darum, die im Functional View identifizierten Funktionen auf logische Architekturelemente aufzuteilen. Logische Systeme haben den Vorteil eine Zuordnung zu Funktionen zu ermöglichen ohne technische Komponenten und Schnittstellen vorzugeben.
      Somit könnten technische Architekturelemente ohne Auswirkung auf die Zuordnung von Funktionen auf logische Architekturelemente ausgetauscht werden.
      Ein Beispiel:
      Das Batteriemanagementsystem in einem Elektroauto ist ein logisches System, welches u.a. dafür zuständig ist den Ladezustand des Autos zu bestimmen.
      Die Funktion der Bestimmung des Ladezustandes wird dem logischem Architekturelement “Batteriemanagementsystem” zugeordnet.
      Es spielt dabei für die Funktion der Bestimmung des Ladezustandes nur eine sehr untergeordnete Rolle aus welchen technischen Bestandteilen das Batteriemanagementsystem besteht.

      Zu Ihrem zweiten Punkt:
      Der Logical Viewpoint bietet Sichten an, um die logische Realisierung des Systems darzustellen.
      Die Blackbox-Sicht stellt nur Inputs in das logische System und Outputs aus dem logischen System dar.
      Die Whitebox-Sicht stellt auch zudem das Innenleben (logische Komponenten und Schnittstellen zwischen logischen Komponenten) des logischen Systems dar.
      Genau so gibt es auch bei dem Physical Viewpoint eine Blackbox- und Whitebox-Sicht. Diese bezieht sich jedoch auf konkrete Komponenten, Signale, etc.
      Auf welche Aspekte bei einer Ableitung von einer technischen Architektur aus einer logischen Architektur geachtet werden muss, ist damit nicht gemeint.
      Auch hier haben Sie Recht. System- und Funktionsschnitt müssen zusammenpassen und sollten aufeinander angepasst werden.

      Ich hoffe es ist erkennbar, dass unsere Ansichten gar nicht so weit voneiander entfernt liegen.
      In unseren Systems Engineering und agilen Systems Engineering Trainings erläutern wir den Zusammenhang zwischen den Viewpoints mit ausführlichen Beispielen.
      Falls Sie weiteren Bedarf haben, besuchen Sie gerne eines dieser Trainings.

      Systems Engineering
      Agiles Systems Engineering

      Viele Grüße und ein schönes Wochenende,
      Tim Heuermann von SOPHIST

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert