Das „P“ im RLFP-Ansatz von SPES2020
Im letzten Blogbeitrag haben wir Ihnen den Logical Viewpoint vorgestellt. Der Logical Viewpoint beschreibt, welche Informationen ein Architekturelement grundsätzlich empfangen, berechnen und bereitstellen muss. Dies ist nötig, um bei hoher technischer Varianz der Architekturelemente flexibel reagieren zu können. Jedoch lässt der Logical Viewpoint offen, um welche konkreten Architekturelemente es sich handelt. Der Logical Viewpoint gibt keine Aussagen über Hardwaredesignentscheidungen und konkrete Technologien. Diese und weitere Informationen hingegen liefert der Physical Viewpoint, den wir Ihnen heute vorstellen.
Ziel und Zweck
Der Physical Viewpoint (auch Technical Viewpoint genannt) beschreibt die technische Realisierung des betrachteten Systems über verschiedene Abstraktionsebenen. Er stellt die physikalischen Architekturelemente und deren Zusammenspiel (Kommunikation und Schnittstellen) dar. Er dient als Anknüpfungspunkt für weitere Entwicklungsdisziplinen beispielsweise Konstruktion und Elektronik. Der Physical Viewpoint beschreibt konkrete Technologien, während der Logical Viewpoint Wirkkonzepte beschreibt. Der Physical Viewpoint enthält Informationen, die für die Produktion eines konkreten Produkts nötig sind, wie z.B. Anforderungen an Oberflächen, Hardware, Wärmeabfuhr, Größe und Gewicht von mechanischen Bauteilen.
Physikalische (technische) Architekturelemente befinden sich in den Bereichen von Hardware, Software und Mechanik. Diese Architekturelemente haben eine Objektnummer und zumindest Hardware- und Mechanikelemente können wir anfassen. Physikalische Elemente sind beispielsweise Stecker, Kabel, Verstärker und Kondensatoren. Software wie Anwendungs- und Betriebssysteme kann man zwar nicht anfassen, haben jedoch eine eindeutige Objektnummer und sind deshalb ebenfalls physikalische Elemente.
Der Physical Viewpoint ist, wie der Requirements Viewpoint, ein Muss bei der Modellierung von Systemen. Ohne den Physical Viewpoint kann ein System nicht produziert werden.
Inhalte, Diagramme und Notationselemente
Im Modell empfehlen wir Ihnen, eine Sicht anzulegen, die den Aufbau und die Struktur der physikalischen Elemente, welche die Anforderungen an das System realisieren (Blackbox), betrachtet. In einer zweiten Sicht zeigen Sie das Zusammenspiel der physikalischen Elemente inkl. physikalischer Schnittstellen (Whitebox) auf.
Die Diagramme, die Sie zur Modellierung nutzen können, sind das Komponentendiagramm der UML und das Blockdefinitionsdiagramm aus der SysML für die Blackbox-Sicht. Für die Whitebox-Sicht nutzen Sie das Kompositionsstrukturdiagramm aus der UML oder das interne Blockdiagramm der SysML. Die Notationselemente dieser Diagrammtypen kennen Sie schon aus dem letzten Blockbeitrag. Diesen finden Sie hier.
Nun haben wir Ihnen alle RFLP-Viewpoints im Detail vorgestellt. Mit welchem der RFLP-Viewpoints kommen Sie am besten zurecht bzw. arbeiten Sie? Hinterlassen Sie uns gerne einen Kommentar. Oder schreiben Sie uns Ihre Erfahrungen per Email an vertrieb@sophist.de.
Im nächsten Blogbeitrag stellen wir Ihnen unsere Erkenntnisse zum RFLP-Ansatz vor. Wir werden nicht nur auf die Vor- und Nachteile des RFLP-Ansatzes eingehen, sondern auch das Innovationsprojekt „Architektur im SE“ Revue passieren lassen. Freuen Sie sich auf den letzten Blogbeitrag dieser Reihe und vielleicht können Sie sich aus unseren Erfahrungen etwas mitnehmen, das Ihnen zukünftig in Ihren Projekten hilft.
Viele Grüße!
Ihre SOPHISTen
Lesen Sie auch 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 5: RFLP: Logical Viewpoint
Teil 7: Erkenntnisse aus Innovationsprojekt „Architektur im SE“