Mit STABLE liefern wir bereits eine Methode, um die Struktur einer Spezifikation auf Basis der Inhalte eines Modells zu erstellen. Im Buch „Requirements Engineering und -Management“ ist STABLE in Kapitel 21 ausführlich beschrieben.
Wie aber strukturieren Sie ein Modell? Nach welchen Inhalten können Sie eine Modellstruktur aufbauen? Welche Inhalte werden benötigt, um Anforderungen und Architektur eines Systems modellbasiert darzustellen?
Diese und weitere Fragen beantworten wir Ihnen in dieser Blogserie. Mit dem ersten Blogartikel stellen wir heute unser Innovationsprojekt „Architektur im SE“ (SE = Systems Engineering) vor.
Vorher erläutern wir grundsätzliche Begrifflichkeiten im Systems Engineering, um ein gemeinsames Verständnis zu erlangen.
System
Ein System ist ein Konglomerat von mehreren Elementen, die zusammen ein Ganzes bilden. Die Elemente können aus Menschen, Hardware, Software sowie Dokumenten bestehen. Der Wert des Ganzen ergibt sich durch die Beziehung der einzelnen Elemente. Beispiele für Systeme sind Züge, Industriemaschinen und Geldautomaten. [1]
Systems Engineering
Systems Engineering ist ein integrativer Ansatz, um die Realisierung, Nutzung und Wartung von komplexen Systemen zu ermöglichen. Systems Engineering betrachtet sowohl das gewünschte System als Ganzes als auch Bereiche seinen Lebenszyklus. [2]
Das Systems Engineering beschäftigt sich u.a. mit Systemanalyse. In der Systemanalyse wird das gewünschte Verhalten des betrachteten Systems herausgearbeitet. Im Bereich der Architektur werden die Systembestandteile festgelegt und das gewünschte Verhalten des betrachteten Systems den Systembestandteilen zugeordnet. Die Systembestandteile müssen in der Lage sein, über Schnittstellen miteinander zu kommunizieren, damit sich das System wie gewünscht verhält. Durch die Aufteilung des Systems in Systembestandteile ergeben sich zusätzliche Anforderungen an die Systembestandteile. Danach werden die Systembestandteile analysiert und wiederum in Systembestandteile aufgeteilt.
Modell
Da die Systeme immer komplexer werden und somit die Anzahl an Systembestandteilen immer größer wird, kann die Dokumentation des Systems Engineering in rein textueller Form schnell unübersichtlich werden und zu Redundanzen führen. Modelle können das System aus verschiedenen Perspektiven zeigen und helfen dabei Redundanzen zu vermeiden.
Ein Modell bildet einen relevanten Ausschnitt der Realität in reduzierter Form für einen bestimmten Zweck ab. Zur Visualisierung des relevanten Ausschnitts der Realität verwenden wir Modellierungssprachen. Diese bieten verschiedene Diagrammarten und Notationselemente an, um den Kontext, die gewünschten Funktionen und das gewünschte Verhalten, aber auch die gewünschte Kommunikation zwischen Systembestandteilen abzubilden. Mit jedem erzeugten Diagramm schafft man eine neue Sicht auf den relevanten Ausschnitt der Realität. Die Notationselemente können in verschiedenen Diagrammen wiederverwendet werden, sodass redundante Modellelemente vermieden werden können.
Innovationsprojekt „Architektur im SE“
Nun stellen wir Ihnen unser Innovationsprojekt vor. Das Innovationsprojekt „Architektur im SE“ verfolgt das Ziel, ein Modelltemplate für ein Modellierungstool zu generieren, welches die Inhalte, die im Kontext des Systems Engineering dokumentiert werden sollten, strukturiert. Dabei stellt sich uns eine zentrale Frage: Wie können diese Inhalte möglichst nachvollziehbar in einem Modell dokumentiert und durch Sichten auf die Modellelemente sinnvoll dargestellt und verknüpft werden? Für die Erzeugung der Sichten nutzen wir Best Practices, die wir auf Basis unserer Erfahrungen in unterschiedlichen Entwicklungsprojekten entwickelt haben. Dabei orientieren wir uns an der Theorie aus SPES, den RFLP-Viewpoints.
Die RFLP-Viewpoints wurden im Rahmen des nationalen Forschungsprojekts „Software Plattform Embedded Systems 2020“ von Wirtschaftsunternehmen und Wissenschaftlern aus verschiedenen Branchen entwickelt. [3] Jeder Buchstabe von RFLP stellt eine Perspektive auf das gewünschte System dar. Das System wird somit aus den Belangen der Anforderungen (R-Requirements Viewpoint), der Funktionen (F-Functional Viewpoint), der logischen (L-Logical Viewpoint) und der physikalischen (P-Physical Viewpoint) Architektur heraus betrachtet. Die im Modelltemplate enthaltenen Sichten und Modellierungsrichtlinien sind praxiserprobt und richten sich am aktuellen Stand der Forschung aus.
In den kommenden Blogbeiträgen stellen wir Ihnen zunächst unsere Interpretation des RFLP-Ansatzes von SPES2020 und anschließend die Viewpoints im Einzelnen vor.
Bleiben Sie dran!
Viele Grüße!
Ihre SOPHISTen
Lesen Sie die weiteren Beiträge aus dieser Serie:
Teil 2: RFLP: Gelebte Trennung zwischen Aspekten im Systems Engineering
Teil 3: RFLP: Requirements Viewpoint
Teil 4: RFLP: Functional Viewpoint
Teil 5: RFLP: Logical Viewpoint
Teil 6: RFLP: Physical Viewpoint
Teil 7: Erkenntnisse aus Innovationsprojekt „Architektur im SE“
[1] INCOSE – General System Definition; abgerufen am 03.11.2021 von https://www.incose.org/about-systems-engineering/system-and-se-definition/general-system-definition
[2] INCOSE – Systems Engineering; abgerufen am 03.11.2021 von https://www.incose.org/about-systems-engineering/system-and-se-definition/general-system-definition
[3] TU München – SPES 2020; abgerufen am 03.11.2021 von http://spes2020.informatik.tu-muenchen.de/
.