Systemmodelle austauschen mit SpecIF

Inhalt: Motivation, Ziele, Nutzungsfälle, Methode, Beispiele, Erste Schritte, Kooperation, Literatur

GfSE gibt SpecIF v1.1 frei

Am Tag des Systems Engineering (TdSE) 2021 gibt die Gesellschaft für Systems Engineering (GfSE) die SpecIF v1.1 frei. Eine Presseerklärung stellt die Bedeutung für die Zusammenarbeit beim Systementwurf heraus. Wie alle anderen Ergebnisse der Arbeitsgruppe wurde die Dokumentation auf Github veröffentlicht.

Motivation

Im Systems Engineering (SE) gibt es eine Vielzahl methodischer An­sätze, die täglich ihren Nutzen unter Beweis stellen; dazu gehört bei­spiels­weise das Anforde­rungs-Management, die Modellierung von Aufbau und Verhalten etwa mit UML/SysML sowie die Simulation unter Verwen­dung von Modelica und anderen Sprachen. Es gibt Infor­mation unterschied­licher Quellen und Formate, die mehr oder weniger starken Einfluss auf die System­konzeption und –entwick­lung haben [3].

In der Praxis gelingt es nicht oder nur mit Mühe die Daten in Verbindung zu setzen. Informationen in getrennten Umgebungen („Silos“) sind häufig inhaltlich inkonsistent. Verbreitete Modellierungs-Standards (z.B. UML/SysML) sind Notationen, überlassen jedoch die Semantik den Werkzeugherstellern und Anwendern. Zum Datenaustausch gibt es viele Ansätze die Syntax, jedoch sehr wenige die Semantik betreffend.

Mit der Specification Integration Facility (SpecIF) soll der bereits vorangeschrittene Wandel von einer dokument-zentrierten zu einer artefakt-zentrierten Arbeitsweise unterstützt werden, indem eine einfache und auf fundamentalen Eigenschaften beruhende logische Sprache (jede Sprache beruht bekanntlich auf Syntax und Semantik) für Systemmodelle definiert wird, die textuelle und graphische Inhalte in einen gemeinsamen Kontext zu stellen vermag. SpecIF schafft eine logische Ebene der Verständigung für die bekannten technischen Formate und Protokolle.

Ziele

SpecIF strebt folgende Ziele an:

  • Lifecycle-Management von Anfang an: Strukturen und Inhalte aus der Phase der Systemkonzeption, oder bestimmte Sichten davon, können nahtlos in die Entwicklung übernommen werden.
  • Disziplin-übergreifend: SpecIF bildet Systemmodelle der Disziplinen Mechanik, Elektronik, Software und ggf. andere ab.
  • Methoden-übergreifend: Texte, dynamische und statische Modelle bekannter Methoden, darunter BPMN, SysML und FMC werden in einem gemeinsamen Kontext dargestellt.
  • Technologie-neutral: SpecIF Daten lassen sich verlustlos für verschiedene „technische Träger“ transformieren: beispielsweise relationale Datenbanken, ReqIF, OSLC, XMI, Graphen-Datenbanken oder linked-data im Web (RDF).
  • Hersteller-neutral: SpecIF ist nicht auf bestimmte Werkzeuge und Hersteller beschränkt; insbesondere unterstützt SpecIF den Austausch oder die logische Integration von Daten zwischen Werkzeugen verschiedener Hersteller.
  • Schema-konform: Das Format von SpecIF Daten ist unter Verwendung einer formalen Strukturbeschreibung prüfbar, etwa XML-Schema (XSD) oder JSON-Schema. Das SpecIF-Schema ist Teil dieser Arbeitsergebnisse.
  • Standard-konform: SpecIF baut auf existierende Standards auf, darunter W3C, OMG und OASIS.
  • Offen und kooperativ: Die Ergebnisse werden unter Creative Commons 4.0 CC BY-SA veröffentlicht; damit ist jegliche auch kommerzielle Nutzung möglich, die Ergebnisse können weiter verarbeitet werden, jedoch ist die Quelle zu nennen und die Ergebnisse sind unter gleichen Bedingungen offen zu legen. Wir ermuntern alle Interessierten, an der Arbeitsgruppe mit zu wirken und direkten Einfluss auf die Ergebnisse zu nehmen.

Nutzungsfälle

Es gibt eine enge Zusammenarbeit zwischen Produkt-Herstellern, Entwicklungspartnern und Zulieferern. Auf Ebene der Geschäftsprozesse steht bereits seit einiger Zeit der Informationsaustausch zwischen den Beteiligten im Fokus:

  • Lastenhefte und modell-basierte System-Spezifikationen entlang der Lieferkette austauschen,
  • Ergebnisse aus unterschiedlichen Modellierungswerkzeugen, die zur Bedienung Expertenwissen voraus setzen, einer viel größeren Gruppe von Gelegenheitsnutzern einheitlich zur Information oder Prüfung/Kommentierung bereit stellen.
  • Änderungen über die Zeit sichtbar machen und das Änderungs-Management über Organisationsgrenzen hinweg unterstützen.

Aus inhaltlicher Sicht stammen relevante Informationen oft aus verschiedenen Teil-Organisationen und beleuchten etwa Anforderungen aus der Produktstrategie, Gesetze und Verbraucherschutz, optimierte Bediensequenzen, Funktionen, Systemaufbau oder die simulative Absicherung von Auslegungsparametern. Folgende Aufgaben sollen unterstützt werden:

  • Informationen und Modelle verschiedener Quellen zusammenführen,
  • Einheitlich suchen und navigieren,
  • Identische Elemente in verschiedenen Modellen finden und konsolidieren,
  • Abhängigkeiten und logische Beziehungen zwischen Modellelementen hinterlegen, also verschiedene Modelle semantisch verknüpfen,
  • Fehler oder Verletzung von Entwurfsregeln erkennen,
  • Artefakte in vorausgehenden und nachfolgenden Entwicklungsschritten verfolgen ohne sie zu kopieren („Reference“ und „Traceability“).

Methode

Ebenen der Informationsdarstellung

Es werden verbreitete Medien und Notationen aufgegriffen, durch ein integriertes Modell gemäß SpecIF in einen logischen Zusammenhang gebracht und mittels bekannter Technologien gespeichert.

  • Das Medium oder Format bestimmt, wie die Information dem Leser vermittelt wird, z.B. als Broschüre, als PDF-Doku­ment zur Anzeige mit einer speziellen Applikation oder als HTML5-Dokument zur Anzeige im Web-Browser.
  • Die Notation bestimmt, wie die Information dargestellt wird, also wie sie aussieht. Die gezeigten Beispiele sind gegliederter Text, strukturierte Daten in einer Tabelle, BPMN-Diagramm oder SysML-Block­diagramm.
  • Das integrierte Modell fasst die Semantik, also die Bedeutung aller Darstellungen und erschließt sie für rechner­gestützte Analyse, Suche sowie Navigation.
  • Die Objekte und Relationen auf der untersten Ebene bestimmen, wie die Information gespeichert wird.

Fundamentale Informationselemente

Ein logisches Zusammenführen der Inhalte verschiedener Nota­tionen gelingt mittels Abstraktion auf wenige funda­mentale Element-Typen. Aus wissen­schaftlicher Sicht und aus praktischen Erfah­rungen werden fünf Element-Typen vorgeschlagen [9]:

  • Ein ■ Akteur steht für ein aktives Modellelement, z.B. eine Aktivität, ein Prozess-Schritt, eine Funktion, eine System­kompo­nente oder eine Rolle.
  • Ein ● Zustand repräsentiert ein passives Modellelement, z.B. eine Form, einen Wert, eine Bedingung, einen Informations­speicher oder eine physische Beschaffenheit.
  • Ein ♦ Ereignis bezeichnet eine zeitliche Referenz, eine Änderung einer Bedingung bzw. eines Zustandes oder generell ein Signal zur Synchronisation.
  • Eine ↯ Anforderung dokumentiert einzelnes physisches oder funktionales Bedürfnis, das der betreffende Entwurf, das Produkt oder der Prozess erfüllen muss.
  • Ein ✶ Ausstattungsmerkmal beschreibt eine beabsichtigte differenzierende Eigenschaft eines Systems, oft ein Alleinstellungsmerkmal.

Die Fundamental Modelling Concepts (FMC) nach Prof. Dr. Siegfried Wendt, Gründungsrektor des Hasso-Plattner-Instituts Potsdam zeigen, dass alle Modelle gängiger Methoden aus den drei Modellelement-Typen Akteur, Zustand und Ereignis aufgebaut werden können [1,2].

Syntax

Das Informationsmodell (Metamodell) legt eine Datenstruktur für die Systemspezifikation fest. Zunächst werden Klassen für die zu verwendenden Modellelemente definiert, nämlich

  • "Ressourcen"-Klassen wie 'Requirement' oder 'System component',
  • "Aussage"-Klassen wie 'contains' oder 'satisfies', wobei die zulässigen Ressourcen-Typen für Ursprung und Ziel der stets gerichteten Relation hinterlegt sind, sowie
  • Hierarchie-Klassen wie 'Document outline', eine Gliederung als lineare, strukturierte Sicht auf das Modell.

Alle diese Klassen können Attribut-Klassen definieren, die ihrerseits einen Daten-Typ mit Wertebereich aufweisen. So lässt sich beispielsweise festlegen, dass ein 'Requirement' z.B. die Attribute 'Title', 'Description' und 'Priority' besitzen soll.

Die Ressourcen, Aussagen (Relationen) und Hierarchien mit ihren Attributen, also die Daten des Systemmodells, sind Instanzen der jeweiligen Klassen.

Semantik

Vokabular

Verständigung erfordert eine klare Begriffswelt, ein Vokabular für das betreffende Fachgebiet.

Zum Beispiel ist ReqIF ein standardisiertes Datenaustausch-Format der OMG [5], jedoch wird es in der Praxis erst effektiv nutzbar durch die Konventionen zur Benennung der Informationselemente, die vom ReqIF Implementor Forum des ProSTEP iViP e.V. erarbeitet wurden. Vergleich­bare Festlegungen werden in der Initiative OSLC getroffen. Interessanter Weise betreffen in beiden Fällen die Benennungen alleine die Attribute, nicht jedoch die übergeordneten Informations­elemente: So ist z.B. festgelegt, dass die Beschreibung einer Anforderung in einem Attribut der Bezeichnung ReqIF.Text bzw. dcterms:description enthalten ist, nicht jedoch, dass die Anforderung selbst vom Typ ReqIF.Requirement oder oslc_rm:requirement (oder welche Bezeichnung auch immer gewählt wird) ist.

SpecIF schlägt ein Vokabular vor, das Ressourcen und Prädikate sowie ihre Eigenschaften umfasst und dabei auf die Konventionen von Dublin Core, OSLC, IREB und andere offene Standards zurück greift. Das Vokabular ist selbst im SpecIF-Format verfügbar.

Aussagenlogik

Die Beziehungen zwischen Informationselementen tragen weitere Bedeutung. Bestimmte Beziehungen sind durch den Analysten oder Architekten manuell anzulegen, etwa eine Relation vom Typ satisfies zwischen einer System­kompo­nente und einer Anforderung. Viele andere Beziehungen können automatisch aus der Anordnung von Elementen in Modell­diagrammen abgeleitet werden.

Indem der logische Gehalt von Modell-Diagrammen in explizite Relationen überführt wird, wird die Navigation, Suche und Prüfung ermöglicht.

  • Die Abfrage logischer Zusammenhänge, beispielsweise welche Funktionen eine bestimmte Rolle in einem bestimmten Prozess (oder insgesamt) auszuführen hat, ist sehr einfach. Die Bedeutung eines Modells wird für die maschinelle Auswertung erschlossen.
  • Zeigt etwa ein Diagramm, dass Bauteil A ein Bauteil B enthält, und ein anderes Diagramm, dass B A enthält, so ist diese Inkonsistenz anhand der widersprüchlichen Relationen einfach zu identifizieren.

Letztlich besteht das SpecIF Integrationsmodell aus attributierten Ressourcen, den Modellelementen, und ebenfalls attributierten Aussagen, welche logische Beziehungen zwischen den Modellelementen herstellen und damit Aussagen zum System treffen. Es ist ein semantisches Netz, das auf viele technische Träger abgebildet werden kann.

Prinzipien der Modellintegration

Folgende fünf Prinzipien der semantischen Integration haben sich bereits in der Praxis bewährt [7,8]:

  1. Trennung von Darstellung und Modell: Gliederungen, Listen und Diagramme sind Sichten eines gemeinsamen logischen Modellkerns.
  2. Abstraktion der Modellelemente: Der Modellkern besteht nur aus Elementen der fundamentalen Typen Akteur, Zustand und Ereignis; hinzu kommen Produktmerkmal und Anforderung. Spezifische Modelle werden gemäß der fundamentalen Eigenart ihrer Elemente in das übergreifende SpecIF Integrations-Modell, den gemeinsamen Kontext, transformiert.
  3. Konsolidierung: Identische Modellelemente auf mehreren Diagrammen gleicher oder unterschiedlicher Notation weisen auf ein einziges Element im Modellkern.
  4. Vernetzung: Logische Beziehungen zwischen Modellelementen werden durch explizite Relationen hinterlegt, teilweise automatisch und teilweise manuell.
  5. Vokabular: Eine gemeinsame Begriffswelt (auch Glossar, Terminologie oder Ontologie genannt) erleichtert den Datenaustausch zwischen Systemen, indem Objekte und Attribute automatisch zugeordnet werden können. Es unterstützt auch das Verständnis zwischen Projektpartnern, indem Begriffe mit vereinbarter Bedeutung verwendet werden.

Schema

Für eine Darstellung von Systemmodellen gemäß SpecIF im JSON Format ist ein Schema verfügbar, das auf Github entwickelt und bereit gestellt wird. Weiterhin gibt es eine beispielhafte Implementierung einer Prüfung des Schema und der inhaltlichen Randbedingungen ("constraints").

CORS-enabled hosting:

Anregungen und konkrete Anwendung sind willkommen!

Beispiele

Zwei Beispiele aus den Domänen mechatronische Systeme und Unternehmens-IT sind in [11] Kapitel 5 beschrieben. Sie zeigen, wie Prozess-Modelle, Aufbau-Strukturen und Anforderung in Beziehung gesetzt werden und welche praktischen Fragen damit beantwortet werden können.

Diese Demonstrations-Beispiele auf dem aktuellen Stand von SpecIF werden hier vorgestellt. Es handelt sich um ZIP-Dateien mit der Modellinformation in JSON und den eingebetteten Bildern. Neben einer Dokumenten-Ansicht zum fortlaufenden Lesen sind die semantischen Beziehungen der Informationselemente verfolgbar. Alle Inhalte lassen sich nach Textstellen durchsuchen und anhand von Attributwerten filtern.

Anmerkung: Beide Beispiele sind nach der Methode 'Fundamental Modelling Concepts' (FMC) erstellt. Damit soll jedoch nicht der Eindruck erweckt werden, dass die Modellintegration mittels SpecIF nur mit FMC möglich ist. Im Gegenteil nehmen laufende Untersuchungen eine nützliche Transformation von SysML-Modelldiagrammen nach SpecIF vor. Wir suchen weitere praktische Beispiele, um das Vorgehen zu formalisieren.

Nun werden vergleichbare Darstellungen und Möglichkeiten bereits in verschiedenen Werkzeugen angeboten. Bei SpecIF geht es darum, Konventionen zu entwickeln, um Systemmodelle unabhängig von bestimmten Methoden oder Werk­zeugen nutzbar zu machen. Aus praktischen Gründen ist SpecIF heute zuerst in einer Abbildung auf ReqIF [5] realisiert; so sind die Modelle bereits heute in einer Vielzahl von Werkzeugen, die ReqIF unterstützen, nutzbar.

Erste Schritte

Sind Sie interessiert und möchten SpecIF näher untersuchen? Hier sind einige Verweise auf mögliche Einstiege ins Thema:

Bei Fragen sprechen Sie bitte mit Uwe Kaufmann, Oliver Alt oder Oskar v. Dungern über die unten angegebene Kontaktinformation. Vorschläge und Beiträge sind willkommen!

Kooperation

Die Ergebnisse werden detailliert und validiert:

Die SpecIF Initiative wird inhaltlich unterstützt von (in alphabetischer Reihenfolge):

Melden Sie sich bei uns, wenn Sie SpecIF unterstützen wollen durch aktive Mitarbeit an den Grundlagen, durch Anwendung in Ihren Projekten oder einfach durch Rückenstärkung („moral support“). Kontaktieren Sie uns unter: Oskar v. Dungern oder Uwe Kaufmann.

Träger

Die Initiative SpecIF wird getragen von der Gesellschaft für Systems Engineering e.V. (GfSE), German Chapter of INCOSE.

Literatur

[1] Wendt, S.: Ein grundlegender Begriffsrahmen für das Wissensmanagement im Software-Engineering. In Proceedings „Knowtech“ Dresden 2001
[2] Knöpfel, A.; Gröne, B.; Tabeling, P.: Fundamental Modelling Concepts – Effective Communication of IT Systems. ISBN-13: 978-0-470-02710-3. John Wiley&Sons, Chichester, 2005.
[3] Kaufmann, U., Pfenning, M.: 10 Theses about MBSE and PLM,
[4] Object Management Group: Systems Modeling Language (OMG SysML™), Version 1.3, June 2012
[5] Object Management Group: Requirements Interchange Format (ReqIF)
[6] Open Services for Lifecycle Collaboration (OSLC)
[7] Dungern, O.v.: Semantic Model-Integration for System Specification – Meaningful, Consistent and Viable, 7.Grazer Symposium Virtuelles Fahrzeug, Graz, Mai 2014.
[8] Dungern, O.v.: Übergreifende Konzeption von Geräten für die Gebäudeautomation – Methodik und Management. TdSE Tag des Systems Engineering der GfSE, Bremen, November 2014.
[9] Dungern, O.v.: Integration von Systemmodellen mit fünf fundamentalen Elementtypen. TdSE Tag des Systems Engineering der GfSE, Ulm, November 2015.
[10]  Dungern, O.v.: Von Anforderungslisten zu vernetzten Produktmodellen – am Beispiel der Gebäudeautomation. REConf, Unterschleißheim, März 2016.
[11]  Dungern, O.v.: Semantic Model Integration for System Specification - Creating a Common Context for Different Model Types. TdSE Tag des Systems Engineering der GfSE, Herzogenaurach, Oktober 2016.
[12]  Dungern, O.v.; Uphoff, F.: Der ‚Interaction Room‘ bahnt einen natürlichen Weg zu vernetzten Systemspezifikationen. REConf, München, März 2017 .
[13]  Dungern, O.v.: How to Automatically Understand and Integrate System-models … and how SpecIF can help. GfSE EMEA Workshop Mannheim, September 2017.
[14]  Mochine, Ph.; Sünnetcioglu, A.; Dungern, O.v.; Stark, R.: SysML-Modelle maschinell verstehen und verknüpfen. TdSE Tag des Systems Engineering der GfSE, Paderborn, November 2017.
[15]  Alt, O.: SpecIF - Die kommende vielschichtige Datenquelle für Spezifikationsdaten. Fachgruppentreffen GI-RE, Nürnberg, November 2018.
[16]  Dungern, O.v.: Model-Integration with SpecIF. ProSTEP ivip e.V. SysML-Workflow-Forum November 2019.
[17]  Dungern, O.v.; Alt, O.: Specification Integration Facility - Wozu braucht man SpecIF neben SysML?. TdSE Tag des Systems Engineering der GfSE, online, 18.-20.November 2020.
[18]  Dungern, O.v.: BPMN und Archimate Modelle mit SpecIF integrieren. TdSE Tag des Systems Engineering der GfSE, online, 10.-12..November 2021.
[19]  Dungern, O.v.: Kollaboration im Systems Engineering mit ReqIF. REConf, München, 25.-27. April 2022.
[20]  Alt, O.: SpecIF-Tutorial. TdSE Tag des Systems Engineering der GfSE, Paderborn, 16.-18. November 2022.
[21]  Dungern, O.v.: Anforderungen und Systemmodelle unter einem Hut. ModernRE Leipzig, 11.-12. Oktober 2023.

 

Nachrichten

SpecIF Editor/Viewer v1.1 available as 'alpha'-Version

TdSE 2021: SpecIF v1.1 released

TdSE 2021: Archimate and BPMN integrated using SpecIF

SpecIF Hackathon 2020

Archimate to SpecIF Transformation

TdSE 2017: SysML-Modelle maschinell verstehen und verknüpfen

SpecIF Vokabular überarbeitet

Der ‚Interaction Room‘ bahnt einen natürlichen Weg zu vernetzten Systemspezifikationen

SpecIF am TdSE 2016

SpecIF Nutzen im Interview

Initiative: Specification Integration Facility (SpecIF)

REConf 2016: Von Anforderungslisten zu Produktmodellen