Please note: This page is currently being translated to English ... it is voluntary work and will not last too long, hopefully.

Merging system models with SpecIF

Content: Motivation, Goals, Use Cases, Method, Examples, Cooperation, Literature

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.

Goals

SpecIF contributes to the following objectives:

  • Lifecycle-Management from the Beginning: Structures and content from the early phases of system conception are seamlessly made available for development.
  • Embracing disciplines: SpecIF creates a common context for models from disciplines such as Mechanics, Electronics, Software, Safety and others.
  • Embracing methods: Texte, dynamische und statische Modelle bekannter Methoden, darunter BPMN, SysML und FMC werden in einem gemeinsamen Kontext dargestellt.
  • Technology-neutral: SpecIF Daten lassen sich verlustlos für verschiedene „technische Träger“ transformieren: beispielsweise relationale Datenbanken, ReqIF, OSLC, XMI, JSON-LD, Graphen-Datenbanken oder linked-data im Web (RDF).
  • Vendor-neutral and independent: 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-compliant: 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-compliant: SpecIF draws on existing standards, most importantly from W3C, OMG and OASIS.
  • Open and cooperative: All results are published with Creative Commons 4.0 CC BY-SA license; allowing commercial use. The results can be further developed, but the origin must be stated and they must be published under similar terms; please consult the referenced license text. We encourage everyone interested to join our GfSE working group and to directly contribute to the results.

Use Cases

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“).

Method

Levels of Information Representation

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.

Fundamental Information Element Types

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 Objekt, z.B. eine Aktivität, ein Prozess-Schritt, eine Funktion, eine System­kompo­nente oder eine Rolle.
  • Ein ● Zustand repräsentiert ein passives Objekt, 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 Typen für die zu verwendenden Modellelemente definiert, nämlich

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

Alle diese Typen können Attribut-Typen definieren, die ihrerseits einen Daten-Typ mit Wertebereich aufweisen. So wird festgelegt, dass ein 'Requirement' z.B. die Attribute 'Title', 'Description' und 'Priority' besitzen soll.

Die Objekte, Relationen und Hierarchien mit ihren Attributen, also die Daten des Systemmodells, sind Instanzen der jeweiligen Typen.

Semantics

Vocabulary

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 selber: 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 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.

Logical Statements

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 Objekten, den Modellelementen, und ebenfalls attributierten Relationen, 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.

Principles of Model-Integration

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 Diagrammen gleichen oder unterschiedlichen Typs 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 die Kommunikation 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 Schema-Prüfung und einer Einhaltung der inhaltlichen Randbedingungen ("constraints").

Anregungen und konkrete Anwendung sind willkommen!

Examples

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.

Cooperation

The results are continuously detailed and validated by:

A research project named „SEISMIK Service Entwicklung für die inter-disziplinäre System-Modellierung – eine Initiative von KMU“ has been submitted for funding.

The SpecIF Initiative is being supported by (in alphabetical sequence):

Interested to support the SpecIF Initiative with active collaboration on theoretic fundementals or on practical application or simply with „moral support“? Please contact us: Oskar v. Dungern or Uwe Kaufmann.

Institution

The SpecIF initiative is hosted by the Gesellschaft für Systems Engineering e.V. (GfSE), German Chapter of INCOSE.

Literature

[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, März 2016 Unterschleißheim.
[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ärz 2017 München.
[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.