Systemmodellierung Software-Variantenmanagement mit SysML

Autor / Redakteur: Frank Lippert * / Franz Graser

Variantenmodellierung hilft dabei, die Entwicklung von Produktlinien zu vereinfachen und konsistent zu halten. Die Methode Orthogonal Variability Modeling (OVM) zeigt in der Praxis zunehmend ihre Stärken.

Firmen zum Thema

Schemazeichnung einer Standheizung für das Auto. Der Beitrag erläutert das Vorgehen bei der Systemmodellierung anhand dieses Beispiels
Schemazeichnung einer Standheizung für das Auto. Der Beitrag erläutert das Vorgehen bei der Systemmodellierung anhand dieses Beispiels
(Bild: Standheizung Fluessigkeit Aufgeschnitten.jpg / Cschirp, Wikimedia Commons / BY-SA 3.0)

Firmen stellen Konsumgüter oft in Form von Produktlinien und –familien her, also als eine Palette von Produkten, die gemeinsame Merkmale haben können. Im Fall mechatronischer Systeme spielen dabei auch immer technische Abhängigkeiten eine Rolle. Oft beginnt die Produktentwicklung jedes Mal von vorne, unabhängig von den Wiederverwendungspotenzialen, die eine gemeinsame Plattform bieten würde. Egal ob eine Produktlinie von Grund auf oder eine Plattform durch Analyse bestehender Produkte aufgebaut wird: Der Entwicklungsaufwand reduziert sich durch Wiederverwendung von Komponenten und durch Einsparung von Zeit und Geld bei Design und Test.

Immer häufiger kommen deswegen bereits in der Frühphase der Entwicklung, wie bei Anforderungserhebung und Systemarchitektur, insbesondere aber beim Design und der Implementierung, Modellierungen mit formalen Notationen und Simulation zum Einsatz. Als eine explizit für das Systems Engineering entwickelte Notation bietet sich hier die Systems Modeling Language SysML an, die von der Object Management Group standardisiert ist [1].

Bildergalerie

Die SysML ist ein Profil – eine fachspezifische Anpassung – und eine Weiterentwicklung der Unified Modeling Language UML für das Systems Engineering (was sich im Namensbestandteil „Sys-“ widerspiegelt) und enthält die meisten in der UML vorhandenen Diagrammtypen. Sowohl Struktur als auch dynamisches Verhalten eines Systems können modelliert werden. Anders als die UML ist die SysML aber nicht an Software gebunden. Praktisch alle physikalischen Beziehungen, Randbedingungen, Stoff- und Energietransporte können ausgedrückt werden. Darin besteht der Vorteil von SysML.

Das Basiselement der SysML ist nicht die „Klasse“, sondern der „Block“. Ein Block kann fast alles darstellen: System, Komponente, Funktion, Feature, Aktivität etc. Wie in der UML kann man benutzersichtbare Features als Use Cases modellieren und in Szenarien wie dem Aktivitäts- und Zustandsdiagramm darstellen. Statische Beziehungen zwischen Systemen, Subsystemen und Komponenten drückt man in Blockdiagrammen oder internen Blockdiagrammen aus. Es können zudem Anforderungen und mathematische Randbedingungen in eigenen Diagrammen modelliert werden.

Wichtig ist auch die Zuordnung oder Abbildung von konzeptuell verschiedenen Diagrammen und Artefakten, die man mit der allocate-Beziehung zwischen praktisch allen Modellelementen herstellen kann. Dies kann die UML mit der dependency-Beziehung oder der Generalisierung nur unvollkommen ausdrücken. Bild 1 (siehe Bildergalerie) zeigt ein Kfz als Komposition von Features in SysML-Notation. Ohne den Gedanken an Plattform- oder Variantenmodellierung kommt es trotz Einsatz fortschrittlicher Mittel zu einer Explosion der zu beachtenden Varianten-Anzahl innerhalb einer Produktfamilie.

Ein Hindernis bei der Einführung von Variantenmodellierung dürfte neben den unvermeidbaren Kosten der Tool-Einführung und der nötigen Schulungen die generell geringere Verbreitung von Modellierungsmethoden mit formalen Notationen im Systems Engineering sein (im Gegensatz etwa zu Simulationen) [2]. Auch ist Variantenmodellierung selbst nicht international so standardisiert wie die UML oder SysML. Dies hat höhere Einführungskosten zur Folge.

Der Austausch von Variantenmodellen mit Kunden oder Zulieferern ist eventuell nicht ohne Weiteres möglich, so dass sich der Einsatz dieser Modellierungsform auf die interne Entwicklung beschränken kann. Jedoch zeigt unsere Erfahrung, dass diese anfänglichen Investitionen durch wesentliche Aufwand- und Kostenreduzierungen sowie deutlich verbesserte Entwicklungs- und Testprozesse in (relativ nach Komplexität des Produkts) in kurzer Zeit wieder hereingeholt werden.

Entwicklung in Domänen und Applikationen

Zu Beginn einer Systementwicklung werden Produkte oft als Baum von Features dargestellt. Dabei stellt man sich ein Feature als Subsystem oder Komponente mit eigenständiger Funktionalität vor, die man etwa auch separat verkaufen kann. Bei der Produktlinienentwicklung basierend auf einer Plattform werden Möglichkeiten betrachtet, Features zu identifizieren, die allen Produkten gemeinsam sind, um sie für alle Produkte gemeinsam zu entwickeln und zu testen.

In der Produktlinienentwicklung bezeichnet man dieses Herausfaktorisieren von Features als Scoping. Dies führt zu einer Aufspaltung in eine Domänen- und eine Applikationsentwicklung. Dabei kommt es darauf an, nur die Features der Plattform hinzuzufügen, die tatsächlich mehr als einem Produkt zur Verfügung stehen. Domäne bezeichnet also die wiederverwendbare Plattform, entweder aus Core-Elementen, die es immer geben muss und/oder als Ansammlung von Komponenten, die es bei mehr als einem Produkt gibt und deshalb auch zur Plattform gezählt werden. Die Applikation ist das konkrete, einzelne Produkt oder System.

Einzelne Systeme innerhalb einer Familie von Produkten können als Varianten einer Produktplattform angesehen werden. Die Varianten unterscheiden sich in bestimmten variablen Merkmalen. Diese Variabilität lässt sich ebenso modellieren wie das gesamte System. Grundsätzlich zu unterscheiden ist die Variabilität in der Produktentwicklung einerseits von den Konfigurationsmöglichkeiten von Features während der Laufzeit eines Produkts andererseits.

Eine effektive Variantenmodellierung von Produktlinien muss diesen Unterschied sichtbar machen. Tool-Unterstützung sorgt dafür, dass Inklusions-, Exklusions- und Abhängigkeitsbedingungen für die Kombination von Features formuliert werden können und am Ende nur erlaubte Kombinationen von Features ein Produkt definieren können.

Die Methoden FODA und OVM im Überblick

Bereits Anfang der 90er machten sich Kang, Cohen und andere am Carnegie Mellon Software Engineering Institute (SEI) Gedanken über Software-Wiederverwendung im Rahmen von Domänenmodellen und konzipierten dafür die Feature Oriented Domain Analysis (FODA) [3].

In ihrem Variantenmodell können optionale, verpflichtende und sich gegenseitig ausschließende Varianten dargestellt werden. Allerdings ist die Aussage, was genau sich in den Varianten ändert, nur implizit dargestellt. Es gibt keine Symbole in der Notation dafür, die als Diskriminatoren dienen könnten. Auch kann nicht gut zwischen Variabilität zur Entwicklungszeit und Laufzeit (z. B. Konfigurierbarkeit des Produkts) unterschieden werden.

Eine neuere Methode zur Modellierung von Variabilität ist Orthogonal Variability Modeling (OVM) [2]. In dieser Notation wird die Variabilität eines Features als eigenständiges und darstellbares Modellierungselement behandelt. Darin besteht ein wesentlicher Fortschritt gegenüber FODA.

Beim OVM wird die Variabilität zweier Hauptelemente betrachtet:

  • Variability Point: „Was variiert?“
  • Variante: „Wie variiert es?“

Durch diesen Ansatz kann OVM die Variabilität in allen Phasen der Systementwicklung konsistent und völlig unabhängig von der sonstigen Systemmodellierung darstellen.

Als Beispiel einer Produktfamilie betrachten wir eine KFZ-Standheizung. Ein Basis-Feature, das allen Heizungen einer Produktlinie gemeinsam ist, ist die Temperatursteuerung. Jedoch ergeben sich bei grundlegender Überlegung Varianten: Standheizungen können mit Strom oder mit (fossilem) Kraftstoff betrieben werden. In letzterem Fall könnte die Standheizung einen eigenen kleinen Tank besitzen oder den Kraftstoff des KFZ nutzen, wobei zwischen Benzin- und Dieselvarianten unterschieden werden muss.

Eine weitere Variante betrifft das Einschalten. Im Basisfall, den jedes Gerät beherrschen muss, wird die Standheizung von Hand auf eine bestimmte Temperatur eingestellt und die Heizung unmittelbar gestartet oder über eine Uhr von Hand auf eine bestimmte Startzeit eingestellt. Die Luxus-Variante sollte mindestens eine und höchstens zwei der folgenden weiteren Möglichkeiten beherrschen: Einschalten über eine eigene Fernbedienung mit Funksteuerung oder Bedienung über eine Handy-App.

Zur Vorbereitung werden das System analysiert und die technischen Elemente und Zusammenhänge (Kontexte) in einem Kontextdiagramm dargestellt (Bild 2). Kontextdiagramme sind eigentlich Bestandteil der Modellierungsmethode Structured Analysis/Structured Design. Diagramme des hier gezeigten Typs Top-Level-Datenflussdiagramm haben sich als so nützlich erwiesen, dass man sie auch in der SysML verwendet.

Bildergalerie

OVM am Beispiel einer Kfz-Standheizung

Wie sehen nun Domänen- und Applikationsentwicklung für eine Standheizung aus, die mit Benzin betrieben wird und über eine manuelle bzw. handybasierte Zeiteinstellung verfügt? Stellen wir dieses System mit der SysML unter Verwendung von OVM dar.

Zunächst gibt es Basis-Features, die allen Systemen gemein sind. Die Anforderungen, das Design und die Implementierung für die Temperatursteuerung sind für alle Standheizungen gemeinsam zu entwickeln. Separat als Komponente oder Subsystem sind hingegen die verschiedenen Start- und Zeiteinstellungsvarianten zu entwickeln und zu testen. Die Basis-Features und die potenziellen Variantenkomponenten stellen also unsere Domänenentwicklung dar (Bild 3).

Die Applikationsentwicklung besteht aus der Erzeugung einer (erlaubten) konkreten Variante und andererseits aus der Integration der Basis- und Variantenkomponenten zu einem Endprodukt. In OVM können Varianten in allen Phasen der Entwicklung konsistent dargestellt werden.

Tools unterstützen die Erstellung einer konkreten Systemvariante aus dem Variabilitätsmodell. Sie erstellen aus allen Variabilitätspunkten und den Beziehungen zwischen den Varianten eine erlaubte Konfiguration. Sie stellen auch sicher, dass zu einer konkreten Variante nur die relevanten Anforderungen, Modelle und Tests übernommen werden.

Das hier gezeigte Beispiel ist bewusst einfach gewählt. Es dürfte jedoch einsichtig sein, dass bei komplizierten Produkten mit einer Vielzahl von Varianten, Lizenzierungsmodellen und Ähnlichem das Tool-gestützte Variantenmanagement mit SysML seine Vorteile schnell zur Geltung bringt.

Literaturhinweise:

[1] OMG SysML Version 1.3. (Juni 2012). http://www.omg.org/spec/SysML/1.3/

[2] Pohl, K., Böckle, G., & van der Linden, F. (2005): Software Product Line Engineering. Berlin, Heidelberg: Springer.

[3] Kang, K., Cohen, S., Hess, J., Nowak, W., & Peterson, S. (1990).: Feature-Oriented Domain Analysis (FODA) Feasibility Study. CMU/SEI.

* Frank Lippert ist Softwarearchitekt bei Mixed Mode. Er befasst sich mit der Modellierung von Software und Systemarchitekturen mit UML und SysML.

(ID:43962689)