MBSE erleben

Diese Woche findet in Hamburg die Konferenz der Gesellschaft für Systems Engineering statt. Am heutigen Tag startete das Event mit halbtägigen Tutorials. Den Vormittag hielt Tim Weilkiens zum Thema „Modellbasiertes Systems Engineering erleben“.

Auch wenn ich durch Tims Consulting-Tätigkeiten bei uns das Vorgehensmodell schon kenne, habe ich ich doch wieder einige Best Practices und Infos notieren können. Teilweise waren es Details, die mir noch nicht so klar waren, teilweise aber auch nur Dinge, die ich vielleicht noch deutlicher in unserer eigenen MBSE-Guideline klarstellen könnte.

Nach einem zügigen Durchlaufen über den Sinn und Zweck von MBSE (schließlich war es ein Anfänger-Tutorial), haben wir als Beispiel ein Waldbrandmelde-System in MagicDraw modelliert.

Hier mal in Kurzform meine Notizen, vielleicht hilft es jemandem:

• Um Pakete global unterscheidbar zu machen, sollten sie immer den Systemnamen enthalten. Für das Forest Fire Detection System (FFDS) also bspw.  FFDS_Requirements, FFDS_Structure usw.
• So wie ein Buch ein Inhaltsverzeichnis hat, sollte jedes Paket ein Content-Diagramm haben. Das ist ein Package-Diagramm, das den Inhalt des Pakets aufzeigt. In MagicDraw gibt es übrigens ein spezielles Content Diagram, das auch Inhalte der eingebunden Diagramme anzeigen kann.
• SysML kennt als Akteur nur die Strichmännchen. Man sollte sich eigene Kategorien (Akteur-Stereotypen) definieren, mindestens aber «External System», um zwischen menschlichen und nicht-menschlichen Akteuren unterscheiden zu können.
• Bei der Definition des Systemkontextes ist es oft schwierig abzugrenzen, ob es zum System gehört oder zum Systemkontext, also als Akteur modelliert wird. Als Faustregel kann gelten: Alles, was im Verantwortungsbereich des Systems liegt, gehört zum System. So wird klar, dass dies unabhängig von der Tatsache ist, ob eine Komponente extern entwickelt wird oder nicht.
• Es ist zu beachten, dass es sich bei der Modellierung des Systemkontexts um eine logische Systemgrenze handelt, nicht um eine physikalische.
• Als Akteure modelliert man die eigentlichen Fachadressaten, also im Beispiel das Fire Department und nicht etwa Internet.
• Stakeholder werden in der Regel nicht als Akteure des Systemkontextes modelliert, da sie nicht mit dem System interagieren. Dennoch kann es Sinn machen, wichtige Stakeholder zu modellieren, dann aber als Akteure in einem eigenen Diagramm.
• Die «include»-Beziehung zwischen Use Cases sollte nur verwendet werden, wenn der referenzierte Anwendungsfall von mehr als einem Anwendungsfall eingebunden wird, wenn als Redundanz vermieden wird.
• Beim Modellieren von Anwendungsfällen identifiziert man zunächst alle Anwendungsfälle zu einem bestimmten Akteur und assoziiert dann zu jedem gefundenen Anwendungsfall die anderen beteiligten Akteure.
• Das Modellieren von Aktivitätsdiagrammen ist eine Gradwanderung der Abstraktionsebene. Gewisse Design-Entscheidungen sind an dieser Stelle schon notwendig, damit die Aktivitäten nicht zu abstrakt und somit nutzlos bleiben. Andererseits befindet man sich bei der Modellierung von Anwendungsfällen immer noch in der Analyse, so dass die Aktivitäten nicht zu konkret werden dürfen, um sich spätere Design-Entscheidungen nicht zu verbauen.
• Nicht jeder Use Case muss durch ein Aktivitätsdiagramm verfeinert werden. Überlegen, was wirklich hilft!
• Anwendungsfälle können in Ausnahmefällen auch durch Zustandsdiagramme beschrieben werden. In der Regel passen aber Aktivitätsdiagramme besser. Zustandsdiagramme nur verwenden, wenn der Use Case sehr zustands-fokusiert ist.
• Use Cases sind eine Verfeinerung von funktionalen Anforderungen, so dass man eine «refine»-Beziehung vom Use Case zum Requirement zieht.
• Die SysML hat drei Abstraktionsebenen: (1) die Typebene in den Blockdefinitionsdiagrammen, (2) die Rollenebene in den Internen Blockdiagrammen, (3) die Instanzebene in den Parametrischen Diagrammen.
• In den bald erscheinenden SysML 1.3 sind einige Verbesserungen zum Einheitensystem (bspw. Umrechnung zwischen Einheiten) sind zu erwarten.
• In SysML sind für Anforderungen nur Name, ID und Text definiert. Alles andere (wie Priorität und dergleichen) wären Vorgaben, die dem SysML-Standard nicht zustehen.
• Im Produktbaum stellt man die Blöcke, aus denen das System besteht, mit einer gerichteten Kompositionsbeziehung dar. Im internen Blockdiagramm des System-Blocks werden diese Blöcke dann als Part Properties dargestellt. Diese entsprechen im bdd den Pfeilen (Assoziationsende) der gerichteten Komposition und bedeutet, dass das Part Property  nach dem Bauplan des entsprechenden Blocks gebaut ist.
• Die Konnektoren im Internen Blockdiagramm (ibd) stehen für Kommunikation im weitesten Sinne zwischen den beteiligten Parts.
• Man sollte für jeden Aspekt (information, electrical, mechanical) ein Internes Blockdiagramm erstellen.
• Der Name „Standard Port“ ist eigentlich unglücklich, „Service Port“ wäre netter gewesen, denn die Ports bieten Dienste an.
• Das SysML-Interface (Lolli-Darstellung) steht für eine Liste von Funktionen und hängt an einem Standard-Port.
• Um die drei Aspekte (information, electrical, mechanical) entsprechend darzustellen, erhält man auch drei Ports. Damit man weiß, dass diese zusammen gehören, sollten diese alle auf einem Standard Port liegen. Solche Nested Ports sind in SysML explizit erlaubt.
• In SysML 1.3 sind die Interfaces (Lollies) nicht mehr notwendig. Funktionen stehen dann in der Port-Definition selbst.

Ich werde bestimmt einige der Punkte in Zukunft nochmal aufgreifen.