Systemmodelle zusammen führen mit SpecIF

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

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, JSON-LD, 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 wird Teil dieser Arbeitsergebnisse sein.
  • 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 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 eine Anforderung 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.

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 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 Objekte und Relationen sowie ihre Attribute umfasst und dabei auf die Konventionen von OSLC, Dublin Core, IREB und andere offene Standards zurück greift.

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

Prinzipien der Modellintegration

Folgende vier 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.

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.

Kooperation

Die Ergebnisse werden in den Arbeitskreisen detailliert und validiert:

Ein Forschungsprojekt unter dem Namen „SEISMIK Service Entwicklung für die inter-disziplinäre System-Modellierung – eine Initiative von KMU“ befindet sich in der Antragsphase.

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

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, 27.-28.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, 1.-2.3.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.