SPES 2020 Deliverable Vector - Analyse und Konzeption f ur offene Fragestellungen in der Entwicklung von Automobilelektroniksystemen

 
WEITER LESEN
SPES 2020 Deliverable Vector - Analyse und Konzeption f ur offene Fragestellungen in der Entwicklung von Automobilelektroniksystemen
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
SPES 2020 Deliverable Vector - Analyse und Konzeption f ur offene Fragestellungen in der Entwicklung von Automobilelektroniksystemen
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.

                                            2
Contents

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

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

                                              4
Car

                                                     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.

                                                                                                5
Multimedia 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:

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

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

                                                    8
In 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

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

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

                                              11
Figure 4: Häufigkeit von Produkten im SuperSet

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

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

                                              14
F1                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

                                                     15
Komponente 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

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

                                              17
Sie können auch lesen