SPES 2020 Deliverable Vector - Analyse und Konzeption f ur offene Fragestellungen in der Entwicklung von Automobilelektroniksystemen
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
TECHNISCHE UNIVERSITÄT MÜNCHEN
FAKULTÄT FÜR INFORMATIK
Software & Systems Engineering
Prof. Dr. Dr. h.c. Manfred Broy
SPES 2020 Deliverable Vector
Analyse und Konzeption für offene
Fragestellungen in der Entwicklung von
Automobilelektroniksystemen:
Fallstudie
Author: Thomas Kofler
Version: 1.0
Date: February 6, 2012
Status:
Technische Universität München - Fakultät für Informatik - Boltzmannstr. 3 - 85748 Garching
Kurzfassung
Dieses Dokument dient zur Vorstellung der erarbeitenden Ergebnisse anhand einer Fallstudie,
die im Rahmen des SPES-2020-Projektes Seitens TU München und der Vector Informatik
GmbH ausgearbeitet wurden.
2Contents
1 Einleitung 4
1.1 Kundenfunktionsmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 SuperSet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Reduziertes SuperSet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Logische Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 Analyse der Kundenfunktionsmodelle 9
2.1 Erfüllbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Produktsuche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Alle Produkte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4 Anzahl von Produkten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5 Variabilität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6 Gemeinsamkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.7 Reduktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.8 Entscheidungspropagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.9 Entdecken von unbenutzbaren Funktionen . . . . . . . . . . . . . . . . . . . . . 14
2.10 Relationen zwischen SuperSet und Variante . . . . . . . . . . . . . . . . . . . . 14
3 Analyse der logischen Architektur 14
3.1 Betrachung logische Architektur der Fallstudie . . . . . . . . . . . . . . . . . . 15
3.2 Erkennen von Widersprüchen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4 Abschließende Anmerkungen 16
References 17
31 Einleitung
Die in diesem Dokument vorgestellte Fallstudie, wird anhand der Methoden, die im Rahmen
von SPES erarbeitet und in [KH11] dokumentiert wurden, bearbeitet.
1.1 Kundenfunktionsmodell
Abbildung 1 zeigt das vollständige Kundenfunktionsmodell der hier vorgestellten Fallstudie.
Ein vollständiges Kundenfunktionsmodell – daher ein Kundenfunktionsmodell das alle möglichen,
wie auch unmöglichen Funktionen eines zu erstellenden Systems beinhaltet – wird auch Super-
Set genannt. Kundenfunktionen sind hierarchisch angeordnete Funktionen, aus Sicht des Kun-
den, die ein zu erstellendes System beinhalten kann. Ein Kundenfunktionsmodell beschreibt
eine Menge von Produkten (daher Ausprägungen einer Konfigurationen eins Kundenfunktion-
smodells).
Eine bestimmte Konfiguration eines Kundenfunktionsmodells (daher das Vorwegnehmen der
Selektion von Kundenfunktionen) kann wieder eine Menge von Produkten beschreiben. Dieser
Schritt kann so oft wiederholt werden, bis keine weitere Konfiguration mehr möglich ist, in
diesem Fall spricht man von einem konkreten Produkt.
Kundenfunktionen können sich gegenseitig beeinflussen. Z.B. ist es möglich festzulegen, dass
wenn eine bestimmte Kundenfunktion vorhanden ist eine andere Kundenfunktion nicht vorhan-
den sein darf. Kundenfunktionen können innerhalb einer Hierarchieebene Gruppen bilden, z.B.
eine alternative Auswahl von Kundenfunktionen.
Die hier vorgestellten Kundenfunktionsmodelle basieren auf den Konzepten, bekannt aus FODA
[KCH+ 90].
1.2 SuperSet
Abbildung 1 zeigt das in der Fallstudie zu analysierende SuperSet. Das SuperSet enthält
folgende Kundenfunktionen und Relationen zu anderen Kundenfunktionen:
Car : Ein Auto (Car ) besteht aus vier verpflichtenden Kundenfunktionen (Powertrain
Features, Body Features, Chassis Features, Multimedia Features).
Powertrain Features: Besteht aus zwei verpflichtenden Kundenfunktionen (Engine Fea-
tures und Transmission Features). Verpflichtend bedeutet, dass beide Kundenfunktionen
in jedem Produkt vorhanden sein müssen (da auch die übergeordnete Kundenfunktion –
Powertrain Features – verpflichtend ist).
Engine Features: Besteht aus vier alternativen Kundenfunktionen (Diesel Engine 2l,
Gasoline Engine 2l, Electric Engine, Diesel Engine 3l ). Eine alternative Auswahl be-
deutet, dass aus in einem konkreten Produkt genau eines aus den vier Kundenfunktionen
vorhanden sein muss.
4Car
Powertrain
Body Features
Features
Engine Transmission Comfort
Body Variants
Features Features Features
Diesel Engine Gasoline Diesel Engine Automatic Manual Climate
Electric Engine Sedan Convertible Coupe Seat Memory
2l Engine 2l 3l Transmission Transmission Control
Chassis
Features
Steering Brake and Stability Multimedia
Drive Features
Features Control Features Features
Electric Hydraulic
4 Wheel Drive 2 Wheel Drive ASR ABS ESP Phone Tuner Navigation
Steering Steering
needs (ABS or ESP)
Figure 1: Kundenfunktionsmodell (SuperSet) der Fallstudie
Transmission Features: Besteht aus zwei alternativen Kundenfunktionen (Automatic Trans-
mission und Manual Transmission). Von diesen Kundenfunktionen muss genau eine in
einem gültigen Produkt vorhanden sein.
Body Features: Besteht aus einer verpflichtenden Kundenfunktion Body Variants und
einer optionalen Kundenfunktion Comfort Features.
Body Variants: Besteht aus drei alternativen Kundenfunktionen (Sedan, Convertible und
Coupe).
Comfort Features: Ist eine optionale Funktion, die aus zwei weiteren optionalen Kun-
denfunktionen besteht (Climate Control und Seat Memory). Optionale Kundenfunktio-
nen müssen in einem Produkt nicht vorhanden sein. Eine Ausnahme ist dann gegeben,
wenn eine optionale Kundenfunktion von einer anderen nicht optionalen Kundenfunktion
benötigt wird.
Chassis Features: Besteht aus drei verpflichtenden Kundenfunktionen (Steering Features,
Drive Features und Brake and Stability Control Features). Alle diese Kundenfunktionen
müssen in jedem Produkt vorhanden sein.
Steering Features: Besteht aus zwei alternativen Kundenfunktionen (Electric Steering und
Hydraulic Steering).
Drive Features: Besteht aus zwei alternativen Kundenfunktionen (4 Wheel Drive und 2
Wheel Drive).
Brake and Stability Control Features: Besteht aus einer optionalen Kundenfunktion (ASR)
und aus zwei alternativen Kundenfunktionen (ABS und ESP ). Zusätzlich wird ausgedrückt,
dass ASR entweder ABS oder ESP benötigt, wenn es gewählt wurde. Dies bedeutet, ist
die Kundenfunktion ASR in einem Produkt vorhanden, so muss entweder ABS oder ESP
im gleichen Produkt auch vorhanden sein.
5Multimedia Features: Besteht aus einer notwendigen Kundenfunktion (Tuner ) und aus
zwei optionalen Kundenfunktionen (Phone und Navigation).
Die Abbildung 1 beschreibt eine Menge von Produkten. Man spricht daher auch von einer
Produktfamilie. Ein konkretes Produkt ist dann gültig, wenn es keine Widersprüche zwischen
Kundenfunktionen gibt, die sich benötigen oder ausschließen. Ein SuperSet ist gültig, wenn
sie zumindest ein gültiges Produkt hat.
1.3 Reduziertes SuperSet
Das Kundenfunktionsmodell in Abbildung 2 repräsentiert eine Vorkonfiguration des Kunden-
funktionsmodells aus Abbildung 1. Ein konfiguriertes Kundenfunktionsmodell, oder auch
Variante eines SuperSets ist eine Vorauswahl/Konfiguration eines SuperSets oder einer an-
deren Variante. Sie schränkt daher die Anzahl von möglichen Produkten ein. Eine Variante
beschreibt ebenfalls eine Menge von Produkten und ist dann gültig, wenn es keine Wider-
sprüche zwischen Kundenfunktionen gibt, die sich benötigen oder ausschließen. Eine Variante
ist dann gültig, wenn sie zumindest ein gültiges Produkt hat.
Car
Powertrain
Body Features
Features
Engine Transmission Comfort
Body Variants
Features Features Features
Gasoline Diesel Engine Automatic Manual Climate
Convertible Coupe Seat Memory
Engine 2l 3l Transmission Transmission Control
Chassis
Features
Steering Brake and Stability Multimedia
Drive Features
Features Control Features Features
Hydraulic
2 Wheel Drive ASR ESP Phone Tuner Navigation
Steering
needs
Figure 2: Reduziertes Kundenfunktionsmodell von Abbildung 1
Das reduzierte Kundenfunktionsmodell in Abbildung 2 ist eine Variante des SuperSets in Ab-
bildung 1.
Folgende Vorkonfigurationen wurden in dieser Variante vorgenommen:
6Engine Features: Enthält nur mehr eine Auswahl von zwei Kundenfunktionen (Gasoline
Engine 2l und Diesel Engine 3l ). Jedes gültige Produkt dieser Variante hat daher entweder
die Kundenfunktion Gasoline Engine 2l oder Diesel Engine 3l.
Body Variants: Die mögliche Auswahl wurde reduziert auf zwei Kundenfunktionen, Con-
vertible und Coupe.
Steering Features: Wurde reduziert auf eine Alternative Hydraulic Steering. Eine einzelne
Alternative ist gleichbedeutend mit einer notwendigen Kundenfunktion. Ist nur mehr
eine Auswahl zur Verfügung in einer Variante, muss diese in jedem Produkt (sofern die
übergeordnete Kundenfunktion vorhanden sein muss) vorhanden sein.
Drive Features: Hier gilt analog zur Kundenfunktion Steering Features, dass nur mehr eine
Auswahl vorhanden ist und daher die Kundenfunktion 2 Wheel Drive notwendigerweise in
allen Produkten der Variante vorhanden sein muss, da auch die Kundenfunktion Chassis
Feature eine notwendige Kundenfunktion ist.
Brake and Stability Control Features: Hier wurde ABS von den alternativen Kundenfunk-
tionen entfernt. Daher wurde auch die Relation zwischen ASR und ESP angepasst. Wird
die optionale Kundenfunktion ASR gewählt, muss auch die Kundenfunktion ESP vorhan-
den sein. In diesem Fall ist erkennbar, dass die Relation nicht notwendig ist, da ESP in
jedem Produkt vorkommen muss und daher die Relation needs niemals einen Widerspruch
verursachen könnte. Wenn ASR nicht vorhanden ist, ist die Kundenfunktion ESP nicht
zwingend erforderlich, ist ASR vorhanden, ist ESP erforderlich. Da ESP aber immer
vorhanden sein muss, kann die Relation needs keinen Widerspruch verursachen.
In Abschnitt 2 werden die hier vorgestellten Kundenfunktionsmodelle nach den erarbeitenden
Methoden in [KH11] analysiert.
Interne Repräsentation. In Abschnitt 2.8 wird der Begriff Entscheidungspropagation definiert.
Die interne Repräsentation eines reduzierten SuperSets oder auch Variante ist eine Menge
von Kundenfunktionen ohne Beziehung. Die Beziehungen zwischen Kundenfunktionen werden
duch das SuperSet an alle Varianten weiter propagiert. Jede Variante erbt daher die Beziehun-
gen zwischen vorhandenen Kundenfunktionen des SuperSets. Einerseits bedeutet dies, dass
nur mehr an einer Stelle eine Beziehung definiert werden muss. Andererseits ergibt sich
auch ein Nachteil, nämlich, dass auch die Gültigkeit einer Variante überprüft werden muss
(dieser Nachteil ist aber auch ohne Propagation vorhanden). Z.B. Eine Funktion F1 benötigt
eine Funktion F2, in einer Variante ist nur mehr Funktion F1 vorhanden, daher wird diese
Beziehung auch nicht propagiert. In diesem Fall ist es möglich, dass die Anzahl der gültigen
Produkte der Variante größer ist, wie die Anzahl der gültigen Produkte des SuperSets. Um
dieses Problem zu begegnen, bietet das erstellte Framework eine Überprüfung an und weist
darauf hin, dass z.B. eine bestimmte Beziehung fehlt aber notwendig wäre. Explizit definierte
Beziehungen in einer Variante bleiben erhalten.
1.4 Logische Architektur
Kundenfunktionen werden durch logische Komponenten realisiert. Abbildung 3 zeigt die Kom-
ponentenübersicht der Fallstudie.
7Climate Control
Sedan Convertible Coupe
require
ABS
ASR 2 Wheel Drive 4 Wheel Drive
ESP
Electric Steering Hydraulic Steering Seat Memory
XOR
Tuner Phone Navigation
Diesel 2l Gasoline 2l Electric Diesel 3l
XOR
Automatic Manual
XOR
Figure 3: Logische Komponenten der Fallstudie
8In dem hier präsentierten Beispiel ist jede logische Komponente 1:1 mit mit einer Kunden-
funktion verbunden. Zusätzlich werden in der logischen Architektur Informationen zu den
Varianten mitgeführt (z.B. Convertible requires Sedan).
In dieser Fallstudie soll gezeigt werden, dass sich Widersprüche aus den Informationen zu Vari-
anten in der logischen Architektur, wie auch aus den Informationen im Kundenfunktionsmodell
zu den Varianten ergeben. Wie Kommunikation zwischen logischen Komponenten in dem erar-
beiteten Ansatz funktioniert und welchen Mehrwert durch die erarbeitete Modellierung ensteht,
wird in [Kof12] gezeigt.
Siehe Abschnitt 3 für mehr Details.
2 Analyse der Kundenfunktionsmodelle
Wie in [KH11] theoretisch erarbeitet, werden die Methoden am vorgestellten Fallbeispiel angewen-
det.
2.1 Erfüllbarkeit
Ein Kundenfunktionsmodell ist erfüllbar, wenn es zumindest ein gültiges Produkt repräsentiert.
Konkret bedeutet dies, dass es keine Widersprüche zwischen Kundenfunktionen gibt, die sich
benötigen oder ausschließen.
Das in dieser Fallstudie zu analysierende SuperSet (siehe Abbildung 1) repräsentiert 7680
gültige Produkte. Das reduzierte Kundenfunktionsmodell (Variante – siehe Abbildung 2)
repräsentiert 320 gültige Produkte.
Die Anzahl der gültigen Produkte kann mit Hilfe des Deminer-Tools berechnet werden, es
stehen dazu zwei Umsetzungen zur Verfügung. (a) die Deminer-interne Berechnung oder (b)
die Möglichkeit sich von Deminer das Kundenfunktionsmodell in einen aussagenlogischen Aus-
druck transformieren zu lassen und mittels des SMT1 -Solvers Z3 [dMB08] die möglichen Pro-
dukte berechnen zu lassen. Z3 ist ein SMT-Solver, bietet aber auch spezielle Konstrukte für
aussagenlogische Berechnungen (auch SAT-Solver genannt – Boolean satisfiability problem).
2.2 Produktsuche
Produkte in Deminer können über logische Ausdrücke gesucht werden, hierbei wird angegeben,
welche Kundenfunktionen in einem Produkt vorkommen müssen und welche nicht vorkommen
dürfen. Deminer berechnet die möglichen Produkte wie in 2.1 angeführt. Die Produktsuche
kann besonders dann interessant werden, wenn überprüft werden soll, ob es Produkte gibt, die
bestimmte Eigenschaften erfüllen oder eben nicht erfüllen. Diese High-Level-Suchmöglichkeit
kann auch als Filter verstanden werden. Nach der Berechnung der gültigen Produkte wird
anhand der Sucheingabe gefiltert.
1
SMT – Satisfiability Modulo Theories
9In der aktuellen Version von Deminer verwendet zur Suche die Ergebnisse der in Abschnitt 2.1
durchgeführten Kalkulation der gültigen Produkte. Hier ist vorstellbar, dass zur Suche exklusiv
ein SAT-Solver verwendet wird, das hätte den Vorteil, dass nur mehr Produkte kalkuliert
werden, die die Anforderungen durch den logischen Ausdruck erfüllen. Dies Änderung stellt
nur mehr einen geringfügigen Programmieraufwand in Deminer dar.
2.3 Alle Produkte
Wie in 2.1 angeführt, wird zur Feststellung der Erfüllbarkeit alle möglichen Produkte berech-
net. Daher kann der hier vorgestellte Ansatz auch alle Produkte (a) berechnen und (b) visu-
alisieren.
Dieser Schritt ist besonders dann im Hintergrund durchzuführen, wenn es sehr viele gültiger
Produkte gibt, speziell Relationen im Kundenfunktionsmodell der Art ”‘optional”’ treiben die
Anzahl von gültigen Produkten in die Höhe. Während des Modellierungsvorganges des Kun-
denfunktionsmodelles sollte sich daher der Modellierer bewusst sein, wie Relationen zwischen
Kundenfunktionen verwendet werden. Vieles lässt sich in FODA-Modellen auf verschiedene
Art- und Weise modellieren. Speziell sind folgende Regeln beim Arbeiten mit Kundenfunk-
tionsmodellen und Berechnungen aufgetreten:
Mandatory sollte so häufig wie möglich verwendet werden. Mandatory-Relation im Kun-
denfunktionsmodell (Baum) die näher an der Wurzel sind, reduzieren die mögliche Anzahl
von gültigen Produkten.
Alternative sollte vorzugsweise gegenüber exkludes verwendet werden. Viele Relationen
zwischen Kundenfunktionen lassen sich in eine ”‘Alternative”’-Relation umformulieren
und sorgen daher dafür, dass die Berechnung der gültigen Produkte schneller möglich ist.
Optional sollte möglichst so verwendet werden, dass die übergeordnete Kundenfunktion,
wenn diese nur ein übergeordneter Sammelknoten der untergeordneten optionalen Kun-
denfunktionen ist, die selber mit keiner weiteren logischen Komponente in Relation steht,
mandatory ist. Diese Kundenfunktion stellt kein weiteres gültiges Produkt dar, sondern
wird nur durch der Existenz der Kundenfunktion als eigenständiges Produkt identifiziert,
wobei die gleiche Aussage gegeben ist, wenn keine untergeordnete optionale Kundenfunk-
tion gewählt wird.
...
Diese Auflistung ist nicht vollständig. Sie soll dazu dienen, festzuhalten, dass ein Kundenfunk-
tionsmodell vor der Berechnung der gültigen Produkte eventuell nochmals reduziert werden
sollte und auf genau der vorher beschriebenen Aussagen hin untersucht werden kann.
Es kann zu Fällen kommen, in denen zwei oder mehr gültige Produkte, die aber unterschiedliche
Kundenfunktionen repräsentieren, semantisch gleichbedeutend sind. Das Kundenfunktions-
modell sollte daher, wie beschrieben, vorher nochmals überprüft werden. Eine Normalisierung
des Kundenfunktionsmodelles würde hier helfen. Zu Normalisierung von Kundenfunktions-
modelle gibt es bereits wissenschaftliche Arbeiten, auf diese wird in [KH11] verwiesen.
102.4 Anzahl von Produkten
Die Anzahl der Produkte einer Produktlinie ergibt sich in dem hier vorgestellten Ansatz durch
die Berechnung aller Produkte, siehe 2.3. Die Anzahl der Produkte in der hier vorgestellten
Fallstudie sind in 2.1 angeführt.
2.5 Variabilität
Dabei wird ein Wert geliefert, der angibt, wie angibt, wie flexibel eine Produktlinie ist, z.B.
würde ein hoher Faktor angeben, dass die Produktlinie sehr flexibel ist. Dieser Faktor gibt
Aufschluss über die Komplexität einer Produktlinie.
In dieser Fallstudie wird dieser Faktor nicht berechnet, da der Faktor ein subjektives Merkmal
ist. Man nehme ein generisches SuperSet, dass als Ausgangsbasis für alle weiteren Varianten
verwendet wird. Das SuperSet wird in diesem Fall einen hohen Faktor aufweisen, da es sehr
flexibel ist und die Anzahl der Produkte sehr hoch sein wird. Da das SuperSet aber als
Basis für die Definition von Relationen zwischen Kundenfunktionen verwendet werden kann,
damit die Entscheidungspropagation gefördert wird, soll dieser Faktor nicht dazu dienen, die
Entscheidungspropagationsmöglichkeiten einzuschränken. Die Berechnung des Faktors in Vari-
anten kann aber durchaus Sinn machen. In der hier vorgestellten Fallstudie existiert nur eine
Variante, die Berechnung des Faktors ist daher nicht sinnvoll, speziell weil es keine Vergle-
ichsmöglichkeiten zu anderen Varianten gibt, die auf dem selben SuperSet aufbauen.
2.6 Gemeinsamkeiten
Deminer bietet für die Berechnung der Gemeinsamkeiten eine Statistik an, die anzeigt, welche
Produkte in welcher Häufigkeit in einer Variante oder im SuperSet vorkommen. Die Abbildung
4 zeigt die in Deminer integrierte Möglichkeit zur Berechnung und Anzeige.
Das in Abbildung 4 dargestellte Histogramm, dessen Klassen die Kundenfunktionen darstellen,
zeigt die Häufigkeit von Kundenfunktionen im SuperSet. Aus dem Histogramm lassen sich
interessante Erkenntnisse gewinnen.
Bedeutung von ”‘inneren”’ Kundenfunktionen: Innere Kundenfunktionen sind Kunden-
funktionen, die im Graph kein Blatt darstellen (auch innere Knoten). Ein Kundenfunk-
tionsmodell ist eine hierarchische Anordnung von Begriffen, welche die Anforderungen
an eine Familie von Produkten beschreibt. Die inneren Kundenfunktionen eines Kunden-
funktionsmodells sind teilweise reine Klassifizierungs-Kundenfunktionen, die keine weitere
Bedeutung haben. Speziell, wenn diese, wie nachfolgend definiert sind:
Notwendige innere Kundenfunktionen: Alle notwendigen Kundenfunktionen(Mandatory)
die direkt mit dem Wurzelelement oder transitiv über weitere notwendige Kundenfunk-
tionen mit dem Wurzelelement in Relation stehen, kommen in jedem Produkt vor. Diese
Kundenfunktionen haben eine reine Klassifizierungsbedeutung, sofern sie nicht mit lo-
gischen Komponenten in Relation stehen. Hier gilt es zu überlegen, ob die Größe von
Kundenfunktionsmodellen in Zukunft nicht reduziert werden kann, indem für diese Klas-
sifizierung eine andere Möglichkeit gefunden wird.
11Figure 4: Häufigkeit von Produkten im SuperSet
122.7 Reduktion
Die Reduktion von möglichen Produkten einer Produktlinie ist eine Kundenfunktionsmodell
übergreifende Analyse und wird auch ”‘Staged Configuration”’ genannt. Der Ansatz der in
dieser Fallstudie verfolgt wird, ist genau ein solcher Ansatz. Eine Variante ist Teilmenge des
SuperSets und reduziert daher die Anzahl von möglichen Produkten durch eine Vorkonfigura-
tion.
2.8 Entscheidungspropagation
Unter Entscheidungspropagation verstehen wir in dieser Fallstudie die implizite Beziehung
zwischen SuperSet und den Varianten, die eine Teilmenge an Kundenfunktionen des SuperSets
enthalten. Entscheidungspropagation soll dabei helfen, den Wartungsaufwand von Produktlin-
ien zu reduzieren.
Folgende Probleme werden damit begegnet:
Redundante Definition von Beziehungen zwischen Kundenfunktionsmodellen: Ein Super-
Set enthält Beziehungen zwischen Kundenfunktionen. Diese Beziehungen gelten auch für
jede Variante des SuperSets. Die Definition von Beziehungen zwischen Kundenfunktionen
in den Varianten ist redundant, da diese Beziehungen bereits im SuperSet vorhanden sind.
Zusätzliche Beziehungen in einer Variante können definiert werden.
Redundante Definition von Beziehungen zwischen Kundenfunktionsmodellen und der ver-
knüpften logischen Komponenten: Kundenfunktionen können in logischen Komponen-
ten realisiert sein. Kundenfunktionen aus dem SuperSet sind mit einem expliziten Link
zu logischen Komponenten verknüpft. Kundenfunktionen von Varianten werden eben-
falls mit diesen logischen Komponenten verknüpft. Diese Verknüpfung ist redundant und
nicht notwendig, die Beziehungen zu logischen Komponenten einer Variante vom SuperSet
abgeleitet werden können.
Zusätzlich ist es möglich Variabilitätsinformationen zwischen logischen Komponenten zu
definieren. Diese Informationen sind nur dann notwendig, wenn sich die Beziehung nicht
bereits aus dem verknüpften Kundenfunktionsmodell ergibt. In der uns zur Verfügung
gestellten Fallstudie sind alle Beziehungen in der logischen Architektur redundant, weil
sie sich bereits aus dem Kundenfunktionsmodell ergeben. Beispiel: Electric Steering XOR
Hydraulic Steering, wie in Abbildung 3 ersichtlich. Diese Beziehung ergibt sich aus der
Kundenfunktionsdefinition, in Abbildung 1 ist zu sehen, dass die Kundenfunktionen Elec-
tric Steering und Hydraulic Steering alternative Kundenfunktionen sind. Sie können da-
her in keinem gültigen Produkt gleichzeitig vorhanden sein. Die Relation XOR in der
logischen Architektur ist daher nicht notwendig und redundant.
Um Entscheidungspropagation in unserer Fallstudie anzuwenden, werden alle Beziehungen des
reduzierten SuperSets (der Variante) entfernt. In unserer Fallstudie sind die Kundenfunk-
tionen der Variante nicht mit logischen Komponenten der logischen Architektur verknüpft,
diese Beziehungen müsse daher nicht entfernt werden. Konkret bedeutet dies, dass die Vari-
ante, siehe Abbildung 2, nur eine Menge von Kundenfunktionen ohne Beziehungen ist. Diese
13Menge beinhaltet die Kundenfunktionen: {Car, Powertrain Features, Engine Features, Gaso-
line Engine 2l, Diesel Engine 3l, Transmission Features, Automatic Transmission, Manual
Transmission, Body Features, Body Variants, Convertible, Coupe, Comfort Features, Climate
Control, Seat Memory, Chassis Features, Steering Features, Hydraulic Steering, Drive Fea-
tures, 2 Wheel Drive, Break and Stability Control Features, ASR, ESP, Multimedia Features,
Phone, Tuner, Navigation}.
2.9 Entdecken von unbenutzbaren Funktionen
Die Analyse der Kundenfunktionsmodelle (SuperSet und Variante) hat keine unbenutzen Funk-
tionen zu Tage gefördert. Alle Kundenfunktionen kommen in zumindest einem Produkt vor.
Unnutzbare Kundenfunktionen treten dann auf, wenn exkludes-Beziehungen existieren, die,
egal welche Konfiguration im Kundenfunktionsmodell gewählt wurde, immer ausgeschlossen
sind.
2.10 Relationen zwischen SuperSet und Variante
Die in Deminer implementierten Möglichkeiten gehen über die Fallstudie hinaus. Z.B. sind
Analysen zwischen Kundenfunktionsmodellen möglich. Beispiel: Eine Kundenfunktion F1
benötigt die Kundenfunktion F2. Kurz F1 needs F2. Wir nehmen an, dass diese zwei Kun-
denfunktionen im SuperSet definiert sind. In einer Variante fehlt die Kundenfunktion F2, auf-
grund von der hier eingeführten Entscheidungspropagation wird nun die needs-Relation nicht
übernommen in die Variante, da die Kundenfunktion F2 nicht vorhanden ist. Dies würde
aber bedeutet, dass in der Variante Produkte gültig wären, die grundsätzlich, aufgrund der
Einschränkungen im SuperSet, nicht gültig sind. Dieser Fall muss von einer Implementierung
der hier vorgestellten Ansätze unbedingt untersucht werden. In Deminer wird in diesem Fall
eine Warnung angezeigt.
3 Analyse der logischen Architektur
Die im Rahmen von SPES erarbeitete Methode zur Analyse von Kundenfunktionsmodellen,
die mit einer logischen Architektur verknüpft sind, analysiert eine abstrakte Kommunikation
zwischen Komponenten und der Kundenfunktionsmodelle.
Wir sprechen daher davon, dass es eine Kommunikation zwischen logischen Komponenten gibt.
Wir treffen keine Aussage darüber, welche Daten wann kommuniziert werden.
Wir unterscheiden zwischen einer optionalen Kommunikation und einer notwendigen Kommu-
nikation. Diese Kommunikation zwischen den Komponenten wird über Ports durchgeführt.
Ports können dabei optional oder notwendig sein. Z.B. kommuniziert eine Komponente über
einen notwendigen Port zu einem optionalen Port einer anderen Komponente, kann eine Aus-
sage darüber getroffen werden, ob diese Konstellation grundsätzlich möglich ist, oder nicht.
In [Kof12] wird im Detail auf die Beziehung zwischen Kundenfunktionen und logischer Ar-
chitektur eingegangen.
14F1 F2 F1 needs F2 F1 needs F2
L1 L2 L1 L2 L1 L2
Figure 5: Mögliche Fälle von Inkosistenzen zwischen Kundenfunktionsmodell und logischer
Architektur
3.1 Betrachung logische Architektur der Fallstudie
In der Fallstudie ist die logische Architektur hierarchisch flach organisiert. Kommunikation
findet statt, z.B. zwischen Sedan und Convertible, siehe Abbildung 3. Zusätzlich kommt in der
Fallstudie etwas hinzu, was in der Ausarbeitung nicht berücksichtigt wurde, nämlich der Fall,
dass eine logische Architektur ebenfalls Produktlinieninformationen beinhaltet.
Im Abschlussdokument wurde davon ausgegangen, dass die logische Architektur jene ist, welche
sich nicht ändern, sondern aus dem Kundenfunktionsmodell ”‘ergeben”’ muss. In [Kof12]2
wird ein Ansatz vorgestellt, um eine mit einem SuperSet verbundene logische Architektur,
mit einer beliebigen Anzahl von Hierarchien, auf die logischen Komponenten einer Variante
so zu schließen, um die minimal benötigten logischen Komponenten zu identifizieren, um eine
Variante realisieren zu können. Der in [Kof12] vorgestellte Ansatz lässt sich analog, ohne
Änderung, auch auf ein konkretes Produkt anwenden, z.B. es wird ein konkretes Produkt
gewählt und gesucht sind jene logischen Komponenten, die minimal notwendig sind, um die
das Produkt zu realisieren.
3.2 Erkennen von Widersprüchen
Hier wird beschrieben, wie mit den erarbeiteten Ansätzen Widersprüche zwischen logischer
Architektur und Kundenfunktionsmodell definiert und gefunden werden können.
In dem hier präsentierten Ansatz werden alle Komponenten oder Kundenfunktionen als Knoten
in einem Graph, sowie alle Relationen zwischen Komponenten und Komponenten, Kundenfunk-
tionen und Kundenfunktionen und Komponenten und Kundenfunktionen als Kanten dargestellt.
Den Kanten und Knoten wird eine Semantik zugewiesen.
Dies ermöglicht es, im Graph nach Kanten zu suchen, die bestimmte Eigenschaften erfüllen.
Z.B. Kundenfunktionen, die durch eine logische Komponente realisiert werden. Für die Suche
nach Kundenfuntionen mit bestimmten Eigenschaften, wird von Deminer eine Graph-Such-
Sprache zur Verfügung gestellt, die nach bestimmten Mustern suchen kann.
Wir nehmen an, wir suchen nach einer Konstellation, wie sie in Abbildung 5 in Fall 1 zu sehen
ist. In Worten: Alle Teilgraphen, die eine Kundenfunktion (f 1) aufweisen, die in einer logischen
2
Dieses Dokument ist ebenfalls aus der Zusammenarbeit mit der Fa. Vector entstanden
15Komponente realisiert werden, die mit einer andere logische Komponente kommuniziert und
deren Funktion in einer Kundenfunktion (f 2) beschrieben ist, wobei f 1 6= f 2 gilt und, es
existiert keine Relation zwischen f 1 und f 2 vom Typ needs, oder es existiert keine Relation
zwischen f 2 und f 1 vom Typ needs.
Transitive Hülle. Mit dieser einfachen Abfrage, ist es möglich, genau diesen Fall zu finden.
In den seltensten Fällen wird es aber so sein, dass eine flache Hierarchie von logischen Kom-
ponenten gegeben ist. Dies bedeutet, dass die berechnung der transitiven Hülle notwendig ist,
bevor diese Suche gestartet wird. Deminer kann dazu verwendet werden, die transitive Hülle
abzuleiten und ins Modell einzuzeichnen. Dann ist die direkte Suche nach diesen Inkosistenzen
über Such-Graphen möglich. Analog gilt dies auch für Hierarchien im Kundenfunktionsmod-
ell.
Um z.B. den Widerspruch zu finden, dass Convertible Sedan benötigt in der logischen Ar-
chitektur, aber im Kundenfunktionsmodell definiert ist, dass es sich dabei um alternative
Kundenfunktionden handelt und daher, durch die 1:1 Relation zwischen Kundenfunktionen
und logischen Komponenten, ein Widerspruch gegeben ist, kann dafür ebenfalls ein Such-
muster definiert werden. Speziell bei diesen Mustern ist die transitive Hülle besonders wichtig,
es müssen z.B. auch Teilkomponentenbeziehungen berücksichtigt werden.
4 Abschließende Anmerkungen
In [KH11] werden die Lösungsansätze betrachtet, die teilweise in dieser Fallstudie evaluiert
wurden. In den Lösungsansätzen wurden eine Vielzahl weiterer Ansätze betrachtet, die nicht
auf die Fallstudie angewendet wurden. Teilweise war die Fallstudie dafür nicht geeignet und
teilweise sind nur minimale Änderungen an der Methode erforderlich, um sie anzusetzen.
Abschließend lassen die erarbeitenden Methoden und die hier vorgestellten Ergebnisse, die
Schlussfolgerung zu, dass der erarbeitete Ansatz sich sehr gut für die Probleme der Fa. Vector
anwenden lässt.
Die prototypische Umsetzung kann verwendet werden, um Detailfragen zur Implementierung
zu klären. Generell gehen wir davon aus, dass sich der Prototyp nicht ohne Weiteres in die
bestehenden Lösungen bei der Vector Informatik GmbH integrieren lassen, (a) wegen der
Technologiebarriere und (b) wegen des prototypischen Charakters der Umsetzung. Für die
Zielplattform Java finden sich eine Vielzahl bereits verfügbarer Implementierungen der hier
vorgestellten Ideen, die für den Bedarf verwendet werden können. Hier sei noch angemerkt,
dass es nicht Ziel der protoypischen Implementierung war, dass sie sich einfach in bestehende
Lösungen integrieren soll, sondern, die prototypische Implementierung sollte zeigen, dass die
Ansätze praxisrelevant sind und angewendet werden können. Da der Autor seinen Proto-
typen selber implementiert hat, kann von einem Aufwand der reinen Implementierung von
ca. 2-3 Personenmonate ausgegangen werden. Dieser Aufwand ist exklusive des Aufbaus des
notwendigen Hintergrundwissens geschätzt.
Ein weiterer Weg diese Ansätze in die Praxis zu überführen sieht wie folgt aus: Grundsätzlich
ist es nicht notwendig, die Funktionalität des Prototypen nachzubauen, da die Darstellung
(interne Repräsentation) des Gesamtgraphen der Kundenfunktionsmodelle sowie der logischen
16Architekturen für die hier durchgeführten Operationen nicht von Bedeutung ist. Der Graph
kann grundsätzlich aus jeder Repräsention heraus, auch AdHoc erstellt und dann überprüft
werden. Für den Prototypen hat sich eine interne Repräsentation als Graph angeboten, da das
Problem einen Graph-Charakter hat.
Eine weitere Überlegung ist, die hier vorgestellten Überprüfungen dynamisch während der
Erfassung der Modelle durch den Benutzer durchzuführen. Dies würde bei größeren Mod-
ellen die Wartezeit reduzieren. Die Konsistenzprüfung, sowie die Berechnung der Produkte
könnte so während der Eingabe zu Warnungen oder Hinweisen führen, die der Benutzer zu
berücksichtigen hat. Werden die Produkte im Hintergrund berechnet, könnte jede weitere
Einschränkung den Lösungsraum verkleinern und die Menge von Produkten reduzieren und
jede weitere z.B. optionale Relation dafür sorgen, dass sich der Lösungsraum vergrößert. Auch
hier ist vorstellbar, dass ein SAT-Solver in PREEVision integriert wird. Eine dynamische
Durchführung der hier vorgestellten Ansätze würde sich für eine weitere Untersuchung anbi-
eten.
Des Weiteren hat sich herausgestellt, dass sich für die Berechnung der möglichen Produkte vor
allem ein SAT-Solver eignet, da sich Funktionsmodelle, sowie die damit verknüpften logischen
Komponenten auf der in diesem Dokument vorgestellten Abstraktionsebene einfach in einen
logischen Ausdruck transformieren lassen. Deswegen ist die Verwendung des Prototypes nicht
notwendig, viel mehr muss Seitens der Fa. Vector sichergestellt werden, dass die von den
Kunden modellierten Kundenfunktionsmodelle semantisch ein Kundenfunktionsmodell nach
FODA darstellen. Dies wäre z.B. möglich, durch stärkere semantische Einschränkungen bei
der Modellierung der Kundenfunktionsmodelle. Ist dieser Schritt durchgeführt, können die
Ansätze die im Rahmen von SPES erarbeitet wurden in die Praxis überführt werden.
References
[dMB08] Leonardo Mendonça de Moura and Nikolaj Bjørner. Z3: An efficient smt solver.
In C. R. Ramakrishnan and Jakob Rehof, editors, TACAS, volume 4963 of Lecture
Notes in Computer Science, pages 337–340. Springer, 2008.
[KCH+ 90] K. Kang, S. Cohen, J. Hess, W. Novak, and A. Peterson. Feature-oriented domain
analysis (FODA) feasibility study. Technical report, SEI, CMU, Pittsburgh, 1990.
[KH11] Thomas Kofler and Alexander Harhurin. SPES 2020 Deliverable Vector: Analyse
und Konzeption für offene Fragestellungen in der Entwicklung von Automobilelek-
troniksystemen: Lösungsansätze und prototypische Umsetzung. Technical report,
2011.
[Kof12] Thomas Kofler. Reducing Maintenance Efforts in Software Product Line Develop-
ment by Feature Relation Propagation and Tracing of Components, 2012.
17Sie können auch lesen
