Thesis - AIDA - Universität des Saarlandes

Transcription

2009
Konzeption und
Implementierung eines
generischen
Produktkonfigurators
Diplomarbeit
Universität des Saarlandes – Fachrichtung Informatik
Lehrstuhl für Künstliche Intelligenz
Erstprüfer: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
Zweitprüfer: Prof. Dr. grad. Ing. Jörg Siekmann
Betreut von: Dipl.-Inform. Michael Schmitz
Volker Kudelko
30.11.2009
<Inhaltsverzeichnis
2
ERKLÄRUNG DER SELBSTSTÄNDIGKEIT
Hiermit versichere ich, die vorliegende Arbeit selbstständig verfasst und keine
anderen als die angegebenen Quellen und Hilfsmittel benutzt sowie die Zitate deutlich
kenntlich gemacht zu haben.
Diese Arbeit wurde bisher in gleicher oder ähnlicher Form keiner anderen
Prüfungsbehörde vorgelegt und auch nicht veröffentlicht.
Die vorliegende Arbeit entstand im Rahmen einer praktischen Studienphase bei der
ORBIS AG in Saarbrücken.
Saarbrücken, den 30. November 2009
________________________________
Unterschrift
30. November 2009
Konzeption und Implementierung eines generischen Produktkonfigurators
DANKSAGUNG
Ich bedanke mich bei Prof. Dr. Dr. Wolfgang Wahlster und Herrn Michael Schmitz
für das interessante Thema und die eingehende Betreuung während der Durchführung
meiner Arbeit. Ebenso geht mein Dank an Herrn Prof. Dr. Jörg H. Siekmann, der die
Zweitkorrektur übernahm.
Desweiteren bedanke ich mich bei der ORBIS AG für die sehr gute Zusammenarbeit,
insbesondere bei Herrn Michael Hach für seine große Hilfe im Bereich der
Variantenkonfiguration und der Java Programmierung.
Außerdem danke ich meinen Eltern für die Unterstützung während meiner
gesamten Studienzeit.
30. November 2009
3
<Inhaltsverzeichnis
4
Inhaltsverzeichnis
Inhaltsverzeichnis ......................................................................................................... 4
1.
2.
Einleitung ............................................................................................................ 8
1.1.
Definitionen ........................................................................................... 9
1.2.
Zielsetzung ........................................................................................... 10
1.3.
Motivation............................................................................................ 11
1.4.
Aufgabenstellung ................................................................................. 13
1.5.
Aufbau der Arbeit................................................................................. 14
Grundlagen ....................................................................................................... 16
2.1.
3.
Grafische Konfiguratoren ...................................................................... 16
2.1.1.
Anforderungen an Konfiguratoren ................................................. 16
2.1.2.
Einsatzgebiete ............................................................................... 19
2.2.
Technische Einteilung von Produktkonfiguratoren .................................. 20
2.3.
Generische Konfiguratoren ................................................................... 21
2.4.
Constraint-Programmierung .................................................................. 22
2.5.
Benutzerschnittstellen allgemein ........................................................... 24
2.6.
Bewertung ........................................................................................... 27
Verwandte Arbeiten ........................................................................................... 28
3.1.
Vergleich .............................................................................................. 30
30. November 2009
4.
Implementierung................................................................................................ 32
4.1.
Konzeption........................................................................................... 32
4.2.
Umsetzung ........................................................................................... 33
4.2.1.
Wahl der Programmiersprache ....................................................... 33
4.2.2.
Wahl der Entwicklungsumgebung .................................................. 35
4.3.
Designpattern ....................................................................................... 36
4.3.1.
Singleton ....................................................................................... 36
4.3.2.
Builder .......................................................................................... 37
4.3.3.
Model View Controller ................................................................... 38
4.4.
Laufzeit und Effizienzoptimierung ......................................................... 40
4.4.1.
Hash Tabelle .................................................................................. 40
4.4.2.
Queues ......................................................................................... 41
4.4.3.
Konsistenzprüfungen ..................................................................... 42
4.4.4.
Variablen ....................................................................................... 43
4.4.5.
Constraints - Requires Relationen ................................................... 44
4.4.6.
Constraints – Junction Relationen................................................... 44
4.5.
Datenverarbeitung ................................................................................ 45
4.5.1.
Zeichenobjekte (DrawingObject)..................................................... 45
4.5.2.
Tree .............................................................................................. 46
4.6.
Klassendesign ....................................................................................... 49
4.6.1.
Übersicht ....................................................................................... 49
4.6.2.
Drawing Manager.......................................................................... 50
4.6.3.
Drawing Panel ............................................................................... 50
4.6.4.
Data Handler ................................................................................. 50
4.6.5.
Logic Container ............................................................................. 51
4.6.6.
UI Changer .................................................................................... 51
30. November 2009
5
<Inhaltsverzeichnis
5.
4.7.
Ablauf einer Variablenänderung in der ORBIS Configuration Suite .......... 51
4.8.
Hardwareanforderungen....................................................................... 52
Generischer Aufbau ........................................................................................... 53
5.1.
Einsatzbereich ...................................................................................... 53
5.2.
Aufbau ................................................................................................. 54
5.2.1.
Regeleditor .................................................................................... 55
5.2.2.
Objekteditor .................................................................................. 59
5.2.3.
GUI Designer ................................................................................. 59
5.2.4.
Struktureditor ................................................................................ 60
5.3.
6.
7.
6
Dateiformat zur Speicherung von Konfigurationen................................. 60
Zusammenfassung und Ausblick ......................................................................... 62
6.1.
Zusammenfassung der Arbeit ................................................................ 62
6.2.
Ausblick auf mögliche Erweiterungen .................................................... 63
Anhang ............................................................................................................. 64
7.1.
Ausgewählte Quelltexte ........................................................................ 64
7.2.
Screenshots .......................................................................................... 66
8.
Abbildungsverzeichnis ........................................................................................ 69
9.
Literaturverzeichnis............................................................................................. 71
30. November 2009
„Nichts ist schwier iger als das Vereinfachen. Nichts ist einfacher
als das Kompliz ieren. “
Georges Elgozy
„Fortschritt ist die Fähigkeit des Menschen, einfache Dinge zu
kompliz ieren.“
Thor Heyerdahl
30. November 2009
7
Einleitung
8
1. Einleitung
Der Bedarf nach Individualisierung von Produkten erfordert von Unternehmen die
Realisierung individueller, maßgeschneiderter Kundenwünsche. Die Auseinandersetzung
mit dieser Aufgabe ist für viele Unternehmen überlebenswichtig, insbesondere, um
Marktposition, Alleinstellungsmerkmale und nicht zuletzt ihr Preisniveau im
internationalen Wettbewerb behaupten zu können. Die Beherrschung der
Produktkomplexität und Variantenvielfalt sowohl während der Auftragsgewinnung, als
auch in der Auftragserfassung sind dabei von entscheidender Bedeutung. Hierbei eine
machbare Auswahl aus einer Vielzahl von Produktkombinationen zu treffen, kann
aufgrund einer hohen Komponentenvielfalt unmöglich sein. Unternehmen sind bemüht
dem Kunden eine maximale Komponentenvielfalt anzubieten um eine möglichst große
Anzahl von Kundenwünschen zu bedienen, bei gleichzeitiger Minimierung der
innerbetrieblichen Varianz. Der Einsatz eines Produktkonfigurators ist somit
unausweichlich, um aus dieser Komponentenvielfalt das gewünschte Produkt zu
erhalten.
Wird ein solcher Konfigurator verwendet, spielen intuitive Bedienbarkeit und die
Möglichkeit einer grafischen Vorschau des Produktes eine wichtige Rolle, vorallem wenn
Endkunden als Anwender in Frage kommen. Ein Endkunde möchte möglichst schnell
und ohne große Einarbeitung sein Produkt konfigurieren und im Anschluss bestellen
können.
Hier setzen grafische Konfiguratoren an. Sie ermöglichen dem Benutzer anhand
grafischer Elemente ein Produkt per Drag and Drop zusammenzustellen. Hierbei sind
Restriktionen zu beachteten, so dass als Ergebnis ein technisch korrektes Produkt - u.a.
30. November 2009
mit richtigem Preis - entsteht. Zur Einhaltung dieser Restriktionen werden beispielsweise
Elemente dynamisch ausgeblendet oder bestimmte Aktionen je nach Kontext
unterbunden.
Die vorliegende Arbeit beschreibt den Aufbau und die Konzeption eines grafischen
Konfigurators und dessen Integration in eine bestehende Applikation. Die Erfahrungen,
die während dieser Implementierung gewonnen wurden, dienen dabei als Grundlage für
die Konzeption eines generischen, grafischen Konfigurators, dessen Aufbau im
Anschluss beschrieben wird.
1.1. Definitionen
In diesem Abschnitt werden die in dieser Arbeit häufig verwandten Begriffe erklärt
um später darauf zurückgreifen zu können.
•
Unter einer manuellen Konfiguration (Merkmalbewertung) wird im
Folgenden die nicht grafisch-gestützte Bewertung von Merkmalen
verstanden, die z.B. einzeln eingegeben oder durch Frage-Antwort Dialoge
erfasst werden.
•
Im Gegensatz dazu bietet die grafische Konfiguration eine Möglichkeit,
durch Interaktionen (z.B. Drag & Drop) mit der grafischen Darstellung des
Produktes dieses zu verändern. Durch diese Interaktionen werden
automatisch Merkmalbewertungen ausgeführt; sie sind also Folgeereignisse
der grafischen Konfiguration. Der Benutzer kann somit durch Interaktionen
ein Produkt erstellen ohne explizit Merkmale manuell bewerten zu müssen.
•
Ein konfigurierbares Material (KMat) ist ein Material, welches die
Möglichkeit bietet, Varianten zu bilden. Das konfigurierbare Material wirkt
somit wie eine Schablone für ein Endprodukt. Eine Instanz dieser Schablone
wird Variante genannt, wobei die Attribute (=Merkmale) der Instanz die
Ausprägungen der Eigenschaften des konfigurierbaren Materials darstellen.
Zu jedem konfigurierbaren Material wird eine Stückliste erstellt, die die
maximale Anzahl an Elementen enthält, sowie ein zugehöriger Arbeitsplan
angelegt, der die maximal nötigen Arbeitsschritte enthält (1).
30. November 2009
9
Einleitung
10
1.2. Zielsetzung
Ziel dieser Arbeit ist die Erstellung eines grafischen Konfigurators für
Industriesektionaltore und dessen Integration in die ORBIS Configuration Suite1. Diese ist
über eine bidirektionale Schnittstelle an ein SAP2 System angebunden, so dass während
einer Kundenauftragserfassung in SAP eine grafische Konfiguration möglich ist.
Die Kurzbeschreibung des Konfigurationsprozesses lautet:
Wird in einem SAP Kundenauftrag eine neue Auftragsposition angelegt, so wird
die ORBIS Configuration Suite gestartet und das SAP System bleibt in einer
Wartestellung. Der eigentliche Konfigurationsprozess wird somit in eine externe
Applikation ausgelagert, um die Einschränkungen seitens SAP – wie beispielsweise
das Einbinden eines grafischen Konfigurators – zu umgehen. Die Konfiguration des
Produktes in der ORBIS Configuration Suite kann hierbei manuell oder grafisch
erfolgen. Nach erfolgter Konfiguration wird die ORBIS Configuration Suite beendet
und es erfolgt ein Rücksprung in das SAP System, wobei alle notwendigen
Parameter des konfigurierten Objektes (im vorliegenden Fall ein
Industriesektionaltor) in den Kundenauftrag übernommen werden.
Die grafische Implementierung soll zum einen dazu dienen, dass Personen ohne
spezifische Produktkenntnisse den Konfigurator bedienen können und zum anderen, um
in jedem Arbeitsschritt eine Vorschau des Produktes zu erhalten.
Des Weiteren werden zu jedem Implementierungsdetail Empfehlungen zum Aufbau
eines generischen Konfigurators hinzugefügt. Diese Empfehlungen sind durch ein “G“
links neben dem zugehörigen Text markiert.
1
2
Softwareprodukt der Orbis AG, http://www.orbis.de
http://www.sap.de
30. November 2009
Abbildung 1) Screenshot des grafischen Konfigurators
1.3. Motivation
Die SAP-Variantenkonfiguration3 bietet weder einen integrierten grafischen
Konfigurator, noch ist es ohne erheblichen Aufwand möglich, durch Programmierung
einen derartigen mit gleichem Komfort und gleichen Möglichkeiten wie eine externe
Applikation zu erstellen. Aus diesem Grund wurde der Fokus auf externe Konfiguratoren
mit Schnittstellen zu einem SAP System gerichtet.
Aktuell gibt es zahlreiche Produktkonfiguratoren4 mit Schnittstellen zu
verschiedensten Softwaresystemen wie z.B. SAP, infor5, abas6, AutoCAD7 und Excel.
3
http://help.sap.com/saphelp_470/helpdata/de/92/58d455417011d189ec0000e81ddfac/frameset
.htm
4
Ein Werkzeug, das hilft ein Produkt so zu bestimmen, dass es vorgegebenen
Anforderungen genügt.
5
http://www.infor.de/ - Anbieter von Unternehmenssoftware
6
http://www.abas.de/ - ERP -und eBusiness-Software Anbieter für den Mittelstand
7
http://www.autodesk.de - Applikation von zum Erstellen von 2D- und 3D-Zeichnungen mit
einem PC
30. November 2009
11
Einleitung
12
Dr. Axel Brinkop stellt achtzehn Produktkonfiguratoren in seinem Bericht (2) gegenüber
und vergleicht diese anhand ihres Funktionsumfangs. Keines der vorgestellten
Softwaresysteme bietet eine vollständige Integration in einen SAP Prozess, sondern sie
kommunizieren lediglich mittels remoteaufrufbarer Funktionsbausteine mit einem SAP
System. Die Bedeutung dieser Unterschiede verdeutliche ich anhand eines
Kundenauftrags:
Mit einigen vorgestellten Produkten lässt sich nach erfolgter Konfiguration ein
Kundenauftrag im SAP System erstellen. Dadurch werden ein neuer Materialstamm und
eine neue Materialstückliste erzeugt und die Auftragsposition innerhalb des
Kundenauftrags erhält das neu angelegte Material. Möchte man nachträglich
Änderungen vornehmen, muss der Kundenauftrag im SAP System geöffnet und
bearbeitet werden. Da für jede Konfiguration ein neues Material angelegt wird, steigt
mit jedem neuen Kundenauftrag die Anzahl der gespeicherten Materialen, wodurch ein
erhöhter Pflegeaufwand für das SAP System entsteht.
Andere Produkte, die zwar das SAP Beziehungswissen verwenden um die oben
vorgestellten Probleme zu vermeiden, setzen aber ein eigenes – zusätzliches Beziehungswissen ein. Falls keine Schnittstelle zur Abgleichung des Beziehungswissens
zwischen beiden Systemen existiert, ergibt sich somit ein doppelter Pflegeaufwand bei
Änderungen, da beide Systeme angepasst werden müssen. In diesem Fall ist es auch
notwendig, dass bei Änderungen im SAP System diese im eingesetzten Konfigurator
vorgenommen werden.
Im Gegensatz dazu kann beim Einsatz der ORBIS CS der Benutzer einen
Kundenauftrag im SAP selbst anlegen. Beim Hinzufügen eines konfigurierbaren
Materials in eine Position des Kundenauftrags, erfolgt ein Absprung in die ORBIS CS,
wobei das SAP System in einer Warteposition bleibt. Beim Rücksprung wird SAP von der
ORBIS CS mit allen notwendigen Daten versorgt, so dass der in SAP gestartete Prozess
der Kundenauftragserfassung fortgesetzt werden kann. Es wird hierbei auch kein neues
Material angelegt, sondern das konfigurierbare Material bleibt in der Auftragsposition
erhalten. Zudem kann die Orbis CS das SAP Beziehungswissen migrieren, verändern und
diese Änderungen zurück in das SAP System übertragen. Die Pflege kann somit
vollständig ausgelagert werden und zentral an einer Stelle erfolgen.
30. November 2009
Aufgrund der fehlenden vollständigen Integration und der beschriebenen Nachteile
der aktuell erhältlichen Produktkonfiguratoren, entschloss sich die ORBIS AG eine eigene
Anwendung zu entwickeln, die genau diese Integration bietet.
Diese vollständige Integration eines Konfigurators in eine Unternehmenssoftware
(z.B. ein SAP System) ist laut D. Jannach et al. (3) von großer Relevanz, wobei bereits ein
Trend zu erkennen ist, dass Unternehmen darauf zielen bei der Herstellung und
Bereitstellung ihrer konfigurierbaren Produkte in Supply-Chain Netzwerken
zusammenzuarbeiten. Auch betonen diese die Bedeutsamkeit von web-basierten
Konfiguratoren, die besonders für den Einsatz in heterogenen IT-Landschaften geeignet
sind.
Die vorliegende Arbeit implementiert einen grafischen Konfigurator in die ORBIS CS,
so dass eine grafische Produktkonfiguration vollständig in einen SAP Prozess integriert
werden kann.
1.4. Aufgabenstellung
Zur Implementierung des grafischen Konfigurators in die ORBIS CS ist es erforderlich
eine Schnittstelle zu definieren und diese zu implementieren. Dies bedeutet Methoden
zu definieren, wie Grafikänderungen des Benutzers an die ORBIS CS übermittelt und wie
manuelle Änderungen in der ORBIS CS in die Grafik übernommen werden. Die
Kommunikation muss hierbei effizient sein, damit nicht bei jeder Änderung Daten
übertragen und nicht jedes Mal Konsistenzprüfungen angestoßen werden.
Ebenso muss eine anpassbare Logik hinterlegbar sein. Nach dieser Logik soll sich das
User Interface dynamisch anpassen (z.B. wenn in ein Torglied bereits Fenster gesetzt
wurden, muss die Fenster-Auswahlliste ergrauen, so dass in dieses Torglied keine
weiteren Fenster platziert werden können). Zudem sollten für den User jederzeit grafisch
dessen Interaktionsmöglichkeiten ersichtlich sein.
Das fertig konfigurierte Produkt muss auf Widerspruchsfreiheit prüfbar sein. Hierzu
benötigt man sowohl Klassen zum Hinterlegen von Bedingungen und Beziehungen als
auch eine Prüflogik, die alle Bedingungen auf Korrektheit analysieren kann und bei
Inkonsistenzen sinnvolle Fehlermeldungen liefert.
30. November 2009
13
Einleitung
14
Daraus resultieren folgende Anforderungen:
•
Plattformunabhängigkeit um die Anwendung in möglich vielen Umgebungen
einsetzen zu können
•
effiziente Kommunikation der Grafik mit der ORBIS CS, damit nicht bei jeder
Änderung der Grafik Konsistenzprüfungen durchgeführt werden müssen
•
intuitiv zu bedienende Benutzerschnittstellen
•
effiziente Speicherung einer großen Anzahl von Merkmalen - bestehend aus
Variablenname und Wert
•
effiziente Berechnung der Konsistenzprüfungen mit schlüssigen
Fehlermeldungen
•
Implementierung von Klassen zum Hinterlegen von Konsistenzprüfungen
•
Implementierung von Klassen zum Hinterlegen von Logik, nach welcher sich
die Benutzerschnittstelle anpasst
1.5. Aufbau der Arbeit
Das folgende Kapitel „Grundlagen“ beschreibt grafische Konfiguratoren und leitet
zu generischen Konfiguratoren über. Im Anschluss erläutere ich die Verwendung von
Constraints im Kontext der Variantenkonfiguration und zeige die Bedeutung von
intuitiven Benutzerschnittstellen.
Im Kapitel verwandte Arbeiten, erkläre ich kurz deren Funktionsweise und grenze
sie anhand ausgewählter Eigenschaften von der vorliegenden Arbeit ab.
Das dritte Kapitel „Implementierung“ behandelt zunächst die Wahl einer
geeigneten Programmiersprache und die Verwendung in diesem Kontext. Ebenso
werden an dieser Stelle die verwandten Designpattern aufgeführt und deren Vorteile
erläutert. Zudem werden die zur Laufzeitoptimierung eingesetzten Datenstrukturen
behandelt. Zuletzt wird die genaue Implementierung des Projektes anhand des
Klassendesigns beschrieben.
Das vorletzte Kapitel „generischer Aufbau“ erläutert die Konzeption eines
generischen grafischen Konfigurators bestehend aus vier Hauptkomponenten. Des
30. November 2009
Weiteren beschreibe ich dessen Einsatzdomäne und gehe näher auf die zugrunde
liegende Wissensbasis ein.
Die Arbeit schließt mit einer Zusammenfassung ab. Darin schildere ich zum einen
meine Empfehlungen zum Aufbau eines Produktkonfigurators hinsichtlich dessen
Generik und zum anderen gebe ich einen Ausblick auf mögliche Erweiterungen.
30. November 2009
15
Grundlagen
16
2. Grundlagen
In diesem Kapitel erläutere ich zunächst grafische Produktkonfiguratoren und weise
auf deren Bedeutung im Vergleich zu nicht grafischen Konfiguratoren hin. Anhand eines
Beispiels zeige ich deren Vorteile beim Einsatz im Endkundenbereich, deren Grenzen und
verdeutliche die Vorteile der ORBIS Configuration Suite. Im Anschluss gehe ich näher auf
das Thema der Constraint Programmierung ein und erkläre deren Ziele und
Anwendungsgebiete, die in der vorliegenden Arbeit betrachtet werden.
Um genauere Informationen zu intuitiven Benutzerschnittstellen zu erhalten, gehe
ich auf die allgemeinen Anforderungen an eine solche Benutzerschnittstelle ein und
erläutere deren charakteristische Hauptmerkmale und wie diese in der vorliegenden
Arbeit realisiert wurden.
2.1. Grafische Konfiguratoren
Grafische Produktkonfiguratoren sind Computerprogramme, mit denen die
Produktspezifikationen kundenindividuell für Angebote oder Aufträge (Konsumgüter
oder Investitionsgüter) erzeugt werden können, wobei eine grafische Darstellung des
anzupassenden Produktes enthalten ist. Grafische Vorschauelemente, die beispielsweise
per Drag & Drop eingefügt werden können, unterstützen den Benutzer beim Aufbau
seines Produktes.
2.1.1. Anforderungen an Konfiguratoren
Die hohe Relevanz intuitiver und ergonomischer Schnittstellen in der
Softwareentwicklung spiegelt sich im Bereich der Produktkonfiguratoren wider. So
30. November 2009
erläutern Dan Heiderscheit und Hans Jorgen Skovgaard in Ihrem Bericht (4), dass
Produktkonfiguratoren eine ansprechende und einfach zu bedienende
Benutzerschnittstelle benötigen, mit der ein komplexes Konfigurationsproblem
vereinfacht werden kann.
Die beste Benutzerschnittstelle, insbesondere bei komplexen Aufgabenstellungen,
besteht aus der Visualisierung des Produktes. Lässt sich ein Produkt nicht rein grafisch
konfigurieren, so ist eine Kombination aus grafischer und manueller Konfiguration die
beste Wahl. Dies bedeutet, man hat eine Kombination aus grafischer Darstellung des
Produktes und verschiedene Eingabemasken, zum Hinterlegen von Details, die nicht
durch die grafische Konfiguration abgedeckt werden können. Ebenso ist es wichtig, dass
Benutzer mit unterschiedlichem Wissensstand mit der Applikation effizient arbeiten
können. Erfahrene Benutzer mit spezifischem Produktwissen bevorzugen eine detaillierte
Sicht auf das Konfigurationsproblem, wobei oft eine Gesamtübersicht in Form einer
grafischen Darstellung gewünscht ist. Hingegen bevorzugen weniger erfahrene Benutzer
nur die grafische Sicht mit dem Ziel schnell das gewünschte Produkt zu erhalten.
Eine grafische Darstellung der Konfiguration erleichtert die Auswahl der
Konfigurationsmöglichkeiten und der Endanwender kann Restriktionen besser
verstehen. Wurde in ein Torglied eine Fensterreihe gesetzt, so können keine weiteren
Elemente eingesetzt werden. Hier erkennt der Anwender sowohl an der Grafik, dass das
Einfügen von weiteren Elementen in dieses Torglied keinen Sinn ergibt, als auch an der
ergrauten Combobox zur Auswahl von weiteren Fenstern.
Ferner beschreiben Dan Heiderscheit und Hans Jorgen Skovgaard, dass bei
Konfigurationsproblemen, bei denen der Zusammenbau und die Platzierung von
Objekten im Vordergrund stehen, grafische Vorschauelemente die Interaktion sehr
erleichtern können, insbesondere wenn diese Elemente per Drag & Drop platziert
werden können. Ein Beispiel für diese Art von Konfiguratoren ist der Ikea Home
Planner8. Hier geht es primär darum, Möbelstücke in einem vorgegebenen Raum nach
eigenen Wünschen zu platzieren und das Ergebnis in einer Maßzeichnung oder 3D
Ansicht zu betrachten. Dadurch kann der Kunde nicht nur im Warenhaus selbst, sondern
zu Hause – abseits von regulären Öffnungszeiten – seine Möbelstücke am PC auswählen
8
http://www.ikea.de
30. November 2009
17
Grundlagen
18
und platzieren. Der Entwurf lässt sich ausdrucken, so dass er zum nächsten Einkauf
mitgenommen werden kann. Dies stellt beispielsweise bei der Einrichtung einer Küche
einen Zeitgewinn für das Warenhaus dar, da der Mitarbeiter nur den Ausdruck
Au
überprüft
und eventuell Verbesserungsvorschläge dem Kunden unterbreitet. Außerdem liefert der
Ikea Home Planner als Ergebnis eine Materialstückliste mit den Preisen des aktuellen
Katalogs.
In diesem Fall dient der Konfigurator lediglich als Auswahlhilfe
ilfe und zur räumlichen
Darstellung der Möbelstücke. Es lässt sich aber weder eine Bestellung direkt aus der
Anwendung heraus generieren, noch wird ein Prozess zur Auftragsabwicklung gestartet.
Auch gibt das System keine Details über die Verfügbarkeit der ausgewählten Produkte
preis. Hier setzt die ORBIS CS mit ihrem integrierten grafischen Konfigurator an, der
genau diese Prozessintegration bietet und nach erfolgter Konfiguration
Konfiguration einen Auftrag
initiiert.
Die folgende Abbildung zeigt einen Screenshot des Ikea Home Planners.
Planner Unten
rechts sind Miniaturansichten von verschiedenen Kleiderschränken zu sehen, die per
Drag & Drop in das Vorschaubild eingefügt werden können. Die Kleiderschränke
iderschränke können
hierbei angepasst werden.
Abbildung 2) Ikea Home Planner
30. November 2009
Eine weitere wichtige Eigenschaft eines grafischen Konfigurators besteht darin, dass
die Regeln zur Platzierung von Objekten, Prüflogiken und Konsistenzbedingungen in
einer eigenen Klasse oder sogar in einer eigenen Anwendung ausgelagert sind, um die
Komplexität zu verringern und Wartungsaufwände zu verringern. (Trennung von
Konfigurator und Modellierungsanwendung).
2.1.2. Einsatzgebiete
Das Haupteinsatzgebiet eines Produktkonfigurator ist die kundenindividuelle
Serienfertigung. Diese stellt für jeden Kunden genau das Produkt bereit, das er wünscht
– und zwar zu einem Preis ähnlich dem eines Standardproduktes. Unter dem Begriff
versteht man ferner, möglichst viele denkbare Kundenwünsche zu bedienen, ohne die
innerbetriebliche Varianz ausufern zu lassen (5).
Die Produktkonfiguration, also die Erzeugung eines Produktes aus mehreren
Bauteilen oder Baugruppen nach den Wünschen des Kunden in einem klassischen
Baukastensystem, fällt demnach unter kundenindividuelle Serienfertigung. Dieses
Verfahren darf nicht mit der Variantenfertigung verwechselt werden, durch die ein
Kunde aus vorhandenen ähnlichen Produkten eine fertiggestellte Variante auswählen
kann (6).
Der Einsatz eines Produktkonfigurators in der kundenindividuellen Serienfertigung
setzt folgendes voraus:
a) Anpassung der Produktstruktur nach Markt- und
Produktionsgesichtspunkten (7).
b) Eine angemessene Fertigungstiefe und die Konzentration auf
Kernkompetenzen (8).
Grundsätzlich lassen sich Produktkonfiguratoren in drei Anwendungsbereiche
gliedern, die jeweils separate Anforderungen stellen:
1) Platzierung von Objekten: z.B. Küchenplaner
2) Klassische Konfiguration: z.B. vorliegende Arbeit
3) Konstruktion
In dieser Arbeit geht es um die Klassische Konfiguration. Falls der Bereich in die
30. November 2009
19
Grundlagen
20
Platzierung von Objekten geändert werden soll, müssten beispielsweise Ankerpunkte
und eine erweiterte Logik zum Platzieren der Objekte dem Modell hinzugefügt werden.
Der Bereich der Konstruktion stellt besondere Anforderungen, so dass der hier
vorgestellte Konfigurator dafür nicht geeignet ist.
2.2. Technische Einteilung von Produktkonfiguratoren
Laut Dr.-Ing. Josef Wüpping (5) können Produktkonfiguratoren technisch in drei
Klassen unterteilt werden.
1) Wissensbasierte Systeme: In einem Expertensystem wird die Künstliche
Intelligenz für die produktspezifischen Abhängigkeiten angewendet. Als
Problemlösungstechniken werden meistens IF-THEN-ELSE Regeln, Constraints
(siehe 2.4), Entscheidungsbäume zur Eingrenzung der Lösungsräume und
Zustandstabellen möglicher, nicht möglicher und abhängiger Kombinationen
verwandt.
2) Regelbasierte Systeme: Programmalgorithmen prüfen produktspezifische
Abhängigkeiten in einem Constraint Löser. Für einfache Anwendungen ist
der Aufwand zur Erstellung eines Regelwerkes vertretbar. Bei komplexen
Systemen macht dies jedoch nur begrenzt Sinn, da die Pflege und
Erweiterung dieses Beziehungswissens sehr aufwändig ist.
3) Entscheidungstabellenbasierte Systeme: Produktabhängigkeiten werden
über verknüpfte Entscheidungstabellen abgebildet. Diese Technik eignet sich
für einfache Konfigurationen, lässt sich jedoch für sehr komplexe Produkte
nur schwer handhaben und pflegen.
Der hier vorgestellte Konfigurator gehört zu den regelbasierten Systemen. Sämtliche
Produktlogik wurde nur in Constraints hinterlegt, da das zugrundeliegende
Konfigurationsproblem eine mittlere Komplexität aufwies.
G
Um auf alle Konfigurationsprobleme eingehen zu können, empfiehlt sich daher die
Verwendung eines wissensbasierten Systems, da dieses auch für komplexe Probleme
geeignet ist.
30. November 2009
2.3. Generische Konfiguratoren
Um nicht für jedes Konfigurationsproblem eine eigene Anwendung zu entwickeln,
dienen generische Konfiguratoren. Ein Konfigurator ist demnach generisch, wenn er sich
an die Bedürfnisse eines Unternehmens anpassen lässt. Diese Anpassungen erfolgen
über einen Customizing Bereich der Anwendung. Idealerweise sollten diese Änderungen
ohne Programmierkenntnisse vorgenommen werden können, damit prinzipiell jeder
Mitarbeiter mit entsprechendem Produktwissen damit zurechtkommt. Diese Möglichkeit
der Anpassung ist von sehr großer Bedeutung, da sonst Änderungen nur im Quelltext
von Spezialisten mit Programmierkenntnissen vorgenommen werden können. Diese
nachträglichen Änderungen sind als schwierig und aufwändig einzustufen, da die
Konfigurationsbasis bei jeder Änderung wächst und somit deren Komplexität zunimmt.
Falls kein Mitarbeiter mit entsprechenden Programmierkenntnissen vorhanden ist,
kommen externe Dienstleister ins Spiel, die diese Änderungen vornehmen. Hier kann
leicht eine Art von Abhängigkeit entstehen, da nur diese Dienstleister mit der
technischen Umsetzung vertraut sind. Allerdings sind Unternehmen oft zurückhaltend,
wenn es darum geht ihr Produktwissen externen Firmen preiszugegeben. Genau vor
diesen Problemen stand die Firma VHV Anlagenbau GmbH, die sich daher für den
Einsatz eines generischen Produktkonfigurators entschied (9).
Ebenso entstanden durch den Einsatz eines Produktkonfigurators erhebliche
Zeiteinsparungen:
„Die Einführung des Produktkonfigurators brachte zusätzlich einen enormen
Zeitgewinn bei der Konfiguration eines Gurtförderers. Ein versierter Konstrukteur,
der bereits mehrfach solche Anlagen konfiguriert hat, benötigte bisher für die
Erstellung einer kompletten Anlage im 3D-CAD-System mindestens zwei Stunden.
Nach der Einführung der KoViP-Software reduzierte sich die Zeit für die
Konfiguration der Anlage und die Erstellung der kompletten Anlage im 3D CADSystem bis auf weniger als fünf Minuten“ (9).
Oft existieren Produzent-Produzent Beziehungen zwischen Unternehmen, so dass
ein Unternehmen Produkte herstellt und das andere diese Produkte kauft, in irgendeiner
Form verändert, erweitert und selbst verkauft. Hier ist es von Vorteil, wenn das kaufende
Unternehmen die Konfigurationsbasis des ersten importieren und somit selbst
30. November 2009
21
Grundlagen
22
verarbeiten kann, damit nicht eine spezielle Schnittstelle entwickelt (programmiert)
werden muss. Dies kann mit anpassbaren generischen Konfiguratoren erreicht werden,
so dass auch bei Änderungen der Konfigurationsbasis des ersten Unternehmens das
zweite zeitnah und - vor allem selbst – diese Änderungen in ihrem eigenen System
umsetzen kann.
Das G-SCOP Laboratory des Grenoble Institute of Technology untersuchte den
grundsätzlichen Aufbau von generischen Produktkonfiguratoren (10) und betonte dabei
die Vorteile des Einsatzes einer Objekt-orientierten Programmiersprache (wie z.B. Java,
C++ oder C#), da diese Sprachen über das Konzept der Vererbung verfügen. Dies ist bei
der Erstellung von Objektstrukturen (Objekthierarchien) sehr hilfreich, da mittels
Vererbung sich Eigenschaften und Methoden in „Kind-Klassen“ wiederverwenden
lassen, ohne sie neu implementieren zu müssen.
2.4. Constraint-Programmierung
Um Konsistenzbedingungen oder Logik zu hinterlegen werden in der vorliegenden
Arbeit Constraints verwendet. Im Folgenden gehe ich näher auf diese ein und erkläre
deren Bedeutung im verwendeten Kontext.
Constraints9 eignen sich zur Darstellung von unvollständiger Information zur
Beschreibung der Eigenschaften und Beziehungen von teilweise unbekannten Objekten.
Als sehr allgemeiner und abstrakter Begriff haben Constraints die verschiedensten
Ausprägungen und Arten.
Als Constraint kann man beispielsweise eine mathematische Gleichung oder ein
logisches Prädikat verstehen, zum Beispiel 5 oder „x ist ungerade“. Die beiden
erwähnten Constraints enthalten zwar Informationen über die Werte der Variablen x
und y, allerdings in schlecht verwertbarer Form. Ziel der Constraint-Programmierung ist
es, eine Menge derartiger Informationen auf Widerspruchsfreiheit zu prüfen und
gegebenenfalls zu vereinfachen. So kann beispielsweise aus den Informationen
2 und 1
2 y 1
die Lösung 7 und 5 gefolgert werden.
Hat man ein Modell, bestehend aus mehreren Constraints, mit dem Ziel eine gültige
9
Engl. Für (Rand-, Neben-, Wert) Bedingungen, Einschränkungen
30. November 2009
Lösung zu erhalten, so steht man vor dem Constraint Satisfaction Problem (CSP). Ziel ist
es, einen Zustand (d. h. Belegungen von Variablen) zu finden, der alle aufgestellten
Bedingungen (Constraints) erfüllt. Ein solches Problem besteht aus einer Menge von
Variablen, ihren Wertebereichen und den Bedingungen, die Verknüpfungen zwischen
den Variablen herstellen und dadurch festlegen, welche Kombinationen von Werten der
Variablen zulässig sind.
Ein CSP kann mittels einer inkrementellen Formulierung folgendermaßen als
Standardsuchproblem angesehen werden:
•
Startzustand: Leere Zuweisung {}, in der keiner Variablen ein Wert
zugeordnet ist.
•
Nachfolgerfunktion: Ein Wert kann einer beliebigen und nicht belegten
Variablen zugewiesen werden ohne im Konflikt mit einer vorher belegten
Variablen zu stehen.
•
Ziel: Die Aktuelle Zuweisung ist vollständig, d.h. jeder Variablen wurde ein
Wert zugeordnet.
•
Pfadkosten: Konstante Kosten (z.B. 1) für jeden Schritt.
Jede Lösung besteht aus einer Zuweisung aller Variablen mit Werten. Daher findet
sich diese Lösung im Suchbaum bei Tiefe n, wenn n Variablen belegt werden müssen.
Der Suchbaum dehnt sich nur bis zur Tiefe n aus, weshalb depthfirst10 Suchalgorithmen
häufig eingesetzt werden.
Sobald für die Variable x1 ein gültiger Wert gefunden wurde, wird dieser Wert
beibehalten und ein gültiger Wert für die Variable x 2 ermittelt, ohne im Konflikt mit x1
zu stehen. Dies wird solange fortgeführt, bis zu jeder Variablen ein zulässiger Wert
ermittelt wurde.
Sobald eine gültige Variablenbelegung gefunden wurde, wird dieser Pfad
fortgeführt, ohne weitere mögliche Belegungen zu testen. Wird ein ungültiger Wert
gefunden, so wird solange nach einem Wert gesucht, bis ein gültiger gefunden wurde.
10
Tiefensuche
30. November 2009
23
Grundlagen
24
Die folgende Abbildung illustriert diese Vorgehensweise anhand eines Suchbaumes.
Modell
Start
Variable x1
false
Variable x2
Variable x3
true
true
true
Abbildung 3) Depth-First Suchbaum
Constraints finden zudem nicht nur in Programmiersprachen verstärkt Anwendung
sondern auch in Datenbanken. Hier ermöglichen Constraints eine Zusammenfassung
vieler Datenbankeinträge (u. U. unendlich viele) zu einem Eintrag. Dies ist vor allem bei
der Speicherung von zeitlicher und räumlicher Information von Nutzen.
In dieser Arbeit wird nur der Teilbereich der Constraint Programmierung behandelt,
der sich mit dem Prüfen auf Widerspruchsfreiheit beschäftigt. Das heißt, es geht nicht
darum eine optimale Lösung auf ein Problem bzw. ein Optimierungsproblem zu finden,
sondern eine gegebene Lösung auf Zulässigkeit zu prüfen. Constraints geben hierbei
Bedingungen der Variablenbelegungen an, wie z.B. Variable im Intervall [1,5] oder
Variable < 8000. Bei der Überprüfung auf Widerspruchsfreiheit liegt die Laufzeit in O(n),
wobei n die Anzahl der Constraints und Variablen ist. Im Gegensatz dazu beträgt die
Laufzeit zur Berechnung eines CSP Problem O(n2).
2.5. Benutzerschnittstellen allgemein
Intuitive und ergonomische Benutzerschnittstellen spielen in der
Softwareentwicklung eine zentrale Rolle, da sie maßgeblich zur Benutzerakzeptanz und
Effizienz beitragen. Demnach ist besonders wichtig, dass auch Produktkonfiguratoren
über eine Benutzerschnittstelle mit diesen Eigenschaften verfügen.
Aufgrund des hohen Stellenwertes des Benutzerschnittstellendesigns gibt es
30. November 2009
zahlreiche Richtlinien11, welche konkrete Anforderungen an diese aufzeigen und
Regelwerke zur Dialoggestaltung (11) beinhalten.
Im Folgenden wird kurz auf die VDI-Richtlinie 5005 „Software-Ergonomie in der
Büro-Kommunikation“ (12) eingegangen. Sie beschreibt im Wesentlichen drei wichtige
Anforderungen an Software-Systeme:
1) Kompetenzförderlichkeit: Das Software-System soll konsistent und
handlungsunterstützend gestaltet sein und so das Wissen des Benutzers über
das Software-System steigern.
2) Handlungsflexibilität: Das System muss alternative Lösungswege und
Aufgabenstellungen unterstützen.
3) Aufgabenangemessenheit: Das System muss erlauben, die Aufgabe gut und
effizient zu erledigen.
Ausgehend von diesen drei Grundanforderungen, ergeben sich zahlreiche weitere
Anforderungen. Auf den grafischen Konfigurator und die ORBIS Configuration Suite
bezogen, erläutere ich anhand ausgewählter Anforderungen, wie diese umgesetzt
wurden.
Der erste Punkt wird u.a. dadurch erreicht, dass
•
nur im Kontext anwendbare Aktionen ermöglich werden; sinnlose
Funktionen werden blockiert (z.B. wenn eine Tür in das Tor platziert wurde,
wird diese Auswahlliste grau darstellt und zu verhindern, dass eine weitere
Tür hinzugefügt wird).
•
Sicherheitsabfragen bei Operationen mit schwerwiegenden Folgen: Beim
Beenden der ORBIS Configuration Suite muss ein weiteres Dialogfenster
bestätigt werden, in welchem ein Hinweis auf möglichen Datenverlust
gegeben wird.
Der zweiten Anforderung wird Rechnung getragen dadurch, dass
•
der Benutzer mit einer geänderten Aufgabenstellung (die Torhöhe ändert
11
VDI-Richtlinie 5005 „Software-Ergonomie in der Büro-Kommunikation, Motif (OSF/Motif Style
Guide), MacOS X (Aqua Human Interface Guidelines)
30. November 2009
25
Grundlagen
26
sich und somit beginnt die Konfiguration erneut mit einem leeren Tor) seine
Arbeit noch effizient mit demselben System erledigen kann, ohne das System
bzw. den Prozess neuzustarten.
•
unterschiedliche Benutzer mit unterschiedlichem Erfahrungshintergrund ihre
Aufgaben auf alternativen Wegen erledigen können. So kann zwischen einer
grafischen und einer manuellen Konfiguration jederzeit hin und her
gewechselt werden.
Die letzte Anforderung der VDI Richtlinie an ein Software System wurde erfüllt,
indem
•
der Benutzer die Zielsetzung seiner Aufgabe mit dem System erreichen kann,
ohne zusätzlich andere Systeme oder Medien einsetzen zu müssen (z.B.
Speicherung von Zwischenergebnissen auf Papier).
•
versucht wurde den Arbeitsaufwand zu reduzieren durch syntaktisch
einfache Aufgaben (hinzufügen von Komponenten durch Drag & Drop) und
Reduktion vieler Einzelschritte (eine Reihe von Torfenstern kann durch eine
Aktion zum Tor hinzugefügt werden, ohne jedes Fenster einzeln einfügen zu
müssen).
Besonders anwenderfreundliche Benutzerschnittstellen und durchdachte
Dialogtechniken wurden im Nielsen Norman Group Report ausgezeichnet (13).
Eine der prämierten Dialogtechniken ist beispielsweise die weit verbreitete JavaScript
Bibliothek Lightbox12.
“Lightbox is a simple, unobtrusive script used to overlay images on the current
page. It's a snap to setup and works on all modern browsers (14).”
Diese Bibliothek wird u.a. verwendet um Bilder mittels modalen Dialogen
anzuzeigen. Ein Link im Quellfenster öffnet durch Klicken ein weiteres Fenster, wobei
das Quellfenster stark abgedunkelt wird, so dass der Fokus des Betrachters auf das neu
geöffnete Fenster gerichtet wird.
12
http://www.lokeshdhakar.com/projects/lightbox2/
30. November 2009
2.6. Bewertung
Bei der Konzeption eines Konfigurators ist grundsätzlich die Einsatzdomäne zu
beachten. Diese lässt sich - wie in 2.1.2 erwähnt - in die Bereiche Platzierung von
Objekten, klassische Konfiguration und Konstruktion einteilen, welche jeweils
unterschiedliche Anforderungen stellen. Für die vorliegende Arbeit spielt nur der Bereich
der klassischen Konfiguration eine Rolle, so dass Anforderungen aus den beiden
anderen Domänen – wie Ankerpunkte beim Platzieren von Objekten oder
Konstruktionslogiken – entfallen. Weiterhin die Ausrichtung auf den 2D-Modus
empfehlenswert um dem Benutzer die Interaktion zu erleichtern und die komplexen
Berechnungen im 3D Modus zu umgehen.
Zur Modellierung von Konsistenzprüfungen eignen sich Constraints, die entweder
selbst entwickelt werden müssen oder durch Einbinden externer Bibliotheken verwendet
werden können. Letzteres hat den Vorteil, dass diese meist einen großen
Funktionsumfang aufweisen und Funktionalitäten wie Zusammenfassung oder
Vereinfachung von Constraints bieten. Der Einsatz von Constraints kann auf einen
Teilbereich – nämlich die Überprüfung auf Widerspruchsfreiheit – reduziert werden. Dies
bedeutet, dass die Ausführung rechenintensiver Constraintlöser vermieden werden
kann, da nur eine gegebene Lösung auf Gültigkeit überprüft und keine optimale Lösung
gefunden werden muss.
Bei der Gestaltung der Benutzerschnittstelle sollte die leichte Bedienung im
Vordergrund stehen um auch eine hohe Endkundenakzeptanz zu erreichen. Daher ist es
sinnvoll alle Oberflächen möglichst minimalistisch zu gestalten und beim Einsatz von
Drag & Drop Elementen diese mit Vorschaubildern auszustatten.
30. November 2009
27
Verwandte Arbeiten
28
3. Verwandte Arbeiten
In diesem Kapitel werden Arbeiten rund um das Thema grafischer bzw. generischer
Produktkonfigurator vorgestellt und im Anschluss die Unterschiede zum vorgestellten
Konzept verdeutlicht.
Wie in 2.3 erwähnt, befasst sich das KoVip Projekt mit der Entwicklung eines
generischen Konfigurators für die Firma VHV Anlagenbau GmbH (9), der über
Schnittstellen zu CAD und ERP Systemen verfügt um einen gewissen Grad der
Integration in eine bestehende Systemlandschaft zu bieten. Eines der Hauptziele war die
Unabhängigkeit von externen Dienstleistern zu schaffen, so dass eigene Mitarbeiter den
Konfigurator an die Bedürfnisse des Unternehmens anpassen können und die
Vereinfachung der Wartung der zugrunde liegenden Wissensbasis.
Die Folgende Abbildung zeigt zwei Screenshots dieser Applikation, wobei die linke
die Produktstruktur und deren Aufbau und die rechte die CAD Applikation mit dem
erstellten Produkt darstellt.
Abbildung 4) Produktstruktur und parametrisiertes 3D-Modell
30. November 2009
Unter dem Aspekt des Product Lifecycle Managements befasste sich das G-SCOP
Laboratory des Grenoble Institute of Technology mit der generischen
Produktkonfiguration (10) und erforschte in diesem Zusammenhang die Bedeutung von
allgemeinen Business Objekten und deren sinnvoller Aufbau. Sie betonten die in 2.1.1
erwähnten Vorteile des Einsatzes einer Objekt-orientierten Programmiersprache.
Wie in 2.1.2 beschrieben, entwickelte Ikea einen grafischen Konfigurator zur
Platzierung von Möbelstücken, der nach erfolgter Konfiguration eine Materialstückliste
alle verwandten Elemente mit zugehörigem Preis liefert.
Die Firma Autodesk hat mit dem Projekt Dragonfly13 einen kostenlosen
Wohnungsplaner vorgestellt, der als Webapplikation in einem Browser mit installiertem
Adobe Flash lauffähig ist und mittels Adobe Flex14 realisiert wurde. Dadurch trägt
Autodesk der wachsenden Bedeutung von Internet-fähigen Konfiguratoren Rechnung
und ebnet den Einsatz in heterogenen Systemlandschaften. Mit zahlreichen
Einrichtungsgegenständen und Architekturelementen kann damit die eigene Wohnung
am Rechner geplant werden. Die Bedienung der Software ist möglichst einfach
gehalten, so dass keine lange Einarbeitungszeit nötig ist.
Die Konfiguration kann bei Dragonfly im zwei- und dreidimensionalen Raum
erfolgen. Zu Beginn wird der Grundriss gezeichnet. Wenn dieser grob steht, werden die
Räume durch Innenwände, Fenster und Mauervorsprünge ergänzt und individualisiert,
bis die Wohnung abgebildet ist. Dazu steht eine große Auswahl an Bodenbelägen,
Einrichtungsgegenständen, Wandverkleidungen und Dekorationen zur Verfügung, die
als Miniaturansicht dargestellt werden und mittels Drag & Drop eingefügt werden
können.
Zwischen der zwei- und dreidimensionalen Ansicht kann jederzeit umgeschaltet
werden. Dadurch können die Elemente präzise im Raum platziert werden. Die meisten
Einrichtungsgegenstände lassen nicht aber nur im 2D Modus platzieren um dem
Benutzer die oft schwierige Handhabung im dreidimensionalen Raum zu erleichtern.
Prinzipiell lässt sich auch der gesamte Konfigurationsprozess im 2D-Modus durchführen,
so dass der 3D-Modus nur als Ergebnisansicht bzw. Vorschau dient.
13
14
http://dragonfly.autodesk.com
http://www.adobe.com/de/products/flex/
30. November 2009
29
Verwandte Arbeiten
30
Die nachstehende Abbildung zeigt einen Screenshot vom Projekt Dragonfly im 3DModus während einer Wohnungskonfiguration. Rechts sind Miniaturansichten von
Objekten zu sehen, die per Drag & Drop platziert werden können.
Abbildung 5) Autodesk Projekt Dragonfly
3.1. Vergleich
Der Bereich der Variantenkonfiguration liegt in einem eher kommerziellem Umfeld,
so dass es zwar eine Vielzahl von Produkten (1.3) am Markt gibt, jedoch ohne eine
detaillierte Beschreibung des Aufbaus oder Preisgabe des Quelltextes. Bei der Recherche
fanden sich sowohl Arbeiten über grafische als auch über generische
Produktkonfiguratoren, jedoch lies sich kein Dokument mit tiefergehenden
Informationen über die Verbindung der beiden Domänen – nämlich ein generischer und
grafischer Produktkonfigurator – finden. Entweder hatten die vorgestellten Lösungen
einen generischen Aufbau oder sie besaßen eine Möglichkeit zur interaktiven-grafischen
Konfiguration. Im Folgenden werden diese Unterschiede nochmals verdeutlich:
Das KoViP Projekte entwickelte zwar einen generischen Produktkonfigurator, aber
hier fehlt es an der Möglichkeit der interaktiven Konfiguration. Die Merkmale des
30. November 2009
31
Produktes können nur manuell eingegeben werden und erst im Anschluss ist es möglich,
das fertige Produkt mittels eines CAD Programms zu visualisieren. Ebenso fehlen
Plattformunabhängigkeit und Internetfähigkeit.
Diese letzten beiden Mankos existieren beim Projekt Dragonfly nicht. Es benötigt
lediglich die Installation von Adobe Flash, was für Windows, Linux, MacOS
M
und Solaris
verfügbar ist, und einen
inen Internetbrowser.
Internetbrowser Zudem gelang es durch den Einsatz der Adobe
Flex Technologie eine optisch ansprechende Oberfläche zu gestalten.
Der Ikea Home Planner
lanner bietet im Vergleich zu den übrigen lediglich die Möglichkeit
der interaktiven Konfiguration und der Ausgabe einer Materialstückliste.
Die folgende Abbildung stellt einige Eigenschaften der verwandten Arbeiten und
des eigenen Konzeptes gegenüber.
KoViP
Ikea HP
Dragonfly
Konzept
interaktive Konfiguration
figuration
Miniaturansicht d. Elemente
Schnittstellen zu ext. Systemen
generischer Aufbau
Import von ext. Bez.-wissen
wissen
internetfähig
plattformunabhängig
15
Ergebnis als Materialstückliste
Abbildung 6)) Vergleich der verwandten Arbeiten mit dem entwickelten Konzept
Wie aus der Abbildung 6 zu erkennen ist, erfüllt keine der verwandten Arbeiten alle
aufgeführten Eigenschaften. Aus diesem Grund wird in der vorliegenden Arbeit in
Kapitel 5 ein Konzept vorgestellt, mit dem Ziel alle oben genannten Punkte zu erfüllen.
15
Sofern Adobe Flash für die verwendete Plattform verfügbar ist – aktuell: Windows, Linux,
MacOS und Solaris
30. November 2009
Implementierung
32
4. Implementierung
Die Umsetzung des Projektes stellte besondere Anforderungen an die
Programmiersprache. Diese sollte plattformunabhängig eingesetzt werden können und
über Bibliotheken zur grafischen Darstellung von Objekten verfügen. Ebenso werden die
verwandten Designpattern im Einzelnen erklärt und näher auf deren Einsatzgebiete im
Bereich der Produktkonfiguratoren mit deren Vorteilen eingegangen.
Des Weiteren werden die eingesetzten Datenstrukturen hinsichtlich ihrer
Funktionalität und Effizienz erläutert. Eine Besonderheit ist hierbei die Klasse Tree. Diese
ist eine spezielle Baumstruktur zum Ablegen von Objekten, die im Anschluss ausführlich
erklärt wird. Zuletzt wird anhand des Quellcodes ausgesuchter Methoden die
Funktionsweise des Konfigurators gezeigt.
4.1. Konzeption
Zur Darstellung der grafischen Elemente wurde die sehr umfangreiche Java 2D
Bibliothek verwendet. Sie bietet alle notwendigen Methoden zum Zeichnen der
geometrischen Figuren bis hin zur Kantenglättung von Schriften und Objekten.
Außerdem verringert sich der Aufwand beim Implementieren einer PDF ExportFunktionalität, da mittels der frei erhältlichen iText16 Bibliothek PDF Dateien direkt aus
Java 2D Methoden heraus erzeugt werden können.
16
http://www.lowagie.com/iText/
30. November 2009
4.2. Umsetzung
4.2.1. Wahl der Programmiersprache
Bei der Wahl der Programmiersprache war es wichtig, dass die resultierende
Software plattformunabhängig einsetzbar ist. Sie sollte nicht nur unter Windows
Betriebssystemen (wie Windows 2000, XP, Vista), sondern beispielsweise auch auf Linux
Systemen lauffähig sein. Ein Grund für diese Anforderung ist die wachsende Bedeutung
von nicht-Windows Systemen im professionellen Einsatzbereich. Dies belegt eine im
Februar 2009 durchgeführte IDC Studie (15), wonach 53 Prozent der Befragten - u.a. als
Reaktion auf die Wirtschaftskrise - den Einsatz von Linux auf Servern ausweiten wollen.
Bereits jetzt haben 39 Prozent der befragten Unternehmen Unix im Einsatz und 55
Prozent arbeiten mit mindestens einem Linux Server.
"Schwierige wirtschaftliche Rahmenbedingungen unterstützen aufstrebende
Technologien und die Einführung kosteneffizienter Lösungen. Im Gegenzug bestrafe
die Rezession nicht konkurrenzfähige Angebote“. Al Gillen, Studienautor und
Software-Analyst bei IDC.
Wegfallende Lizenzkosten, eine bessere Herstellerunabhängigkeit und eine erhöhte
Flexibilität aufgrund der Quelltextoffenheit, sind dabei die Hauptgründe für den Einsatz
von Linux.
Nicht nur im Server- sondern auch im Desktopbereich nimmt die Bedeutung von
Linux zu. Als Beispiel dafür ist die Stadt München zu nennen. So wurde im Rahmen des
LiMux Projektes (16) die Stadtverwaltung von Windows NT auf Linux umgestellt.
Insgesamt waren dabei ca. 14.000 PC Systeme und etwa 400 Notebooks betroffen.
Folgende Ziele wurden mit dieser Migration verfolgt (17):
•
größere Unabhängigkeit von Softwareherstellern, Beratern, Plattformen und
externen Zeitvorgaben
•
Erhöhung der Chancengleichheit zum Markteintritt für den Mittelstand,
dadurch mehr Wettbewerb im Softwaremarkt
•
mittelfristig erhöhte Kostenkontrolle (angestrebte Reduzierung)
Die Client Studie der Landeshauptstadt München, welche den Nutzen und die
30. November 2009
33
Implementierung
34
Kosten der Migration analysierte, kam zu folgendem Ergebnis:
„Liegen die Präferenzen des Stadtrates der LHM eher auf der monetär
wirtschaftlichen Seite, dann ist die Ausstattungsalterative Windows XP / Office XP
für die Landeshauptstadt München vorteilhafter.
Orientiert sich der Stadtrat eher in Richtung auf qualitativ-strategische Aspekte
der Entscheidung, dann ist die Variante Linux / Open Office / VM Ware die optimale
Lösung.“ (18)
Desweiteren sind neben Linux, auch häufig OS/40017 Systeme von IBM als
Serverbetriebssysteme im Einsatz, auf denen die Software lauffähig sein soll.
Um die wachsende Bedeutung von Web-basierten Konfiguratoren zu beachten,
sollte das Programm auch internetfähig sein.
Aufgrund dieser Anforderungen kamen Java und die Microsoft .net Familie in die
engere Auswahl, wobei letztlich die Entscheidung für Java gefallen ist.
Einer der Gründe hierfür war, dass die angestrebte Plattformunabhängigkeit unter
.net grundsätzlich möglich ist, aber die beiden am weitesten entwickelten Projekte
Mono18 und dotGNU19 mit ihren Implementierungen noch nicht auf dem
Entwicklungsstand des heutigen .net sind. Desweiteren bietet Java Connector „JCo“ zur
Kommunikation der Anwendung mit einem SAP System mehr Vorteile gegenüber dem
.net Connector.
“The SAP Java Connector (SAP JCo) is a toolkit that allows a Java application to
communicate with any SAP System. It combines an easy to use API with
unprecedented flexibility and performance. The package supports both, Java to SAP
System as well as SAP System to Java calls. The SAP JCo is the best choice for
building SAP-enabled Java applications because of the following features:
•
High performance JNI-based RFC middleware.
17
http://www.ibm.com/iseries
http://www.novell.com/linux/ximian.html
19
http://www.gnu.org/software/dotgnu
18
30. November 2009
•
Supports R/3 3.1I and higher (and other SAP Components that have BAPIs or
RFMs).
•
Supports inbound (Java client calls BAPI or RFM) and outbound (ABAP calls
Java server) calls.
•
Supports synchronous, transactional (important for IDocs), and queued RFC.
•
Supports client pooling (good for web servers)
•
Multi-platform
•
Complete and correct code-page handling (incl. multi-byte languages)
•
Easy to install and deploy”
•
(19)
Zudem ist es durch die Java Applet Technologie ohne großen Aufwand möglich, die
Anwendung in eine Internetseite zu integrieren, so dass eine Konfiguration auch im
Internet erfolgen kann. Dies ist besonders für Endkunden interessant, die sich somit
selbst und jederzeit über das Internet ihr gewünschtes Produkt konfigurieren können
und als Ergebnis ein Vorschaubild und den Endpreis erhalten.
Zur Integration der Grafik hätte man auch JavaFX20 einsetzen können. Diese von Sun
entwickelte Produktfamilie zielt auf die Erstellung von grafisch ansprechenden und
interaktiven Applikationen mit dem Anspruch, die zukünftige Präsentationsschicht für
plattformübergreifende Java-Anwendungen zu werden. Jedoch hat JavaFX erst im
Dezember 2008 das Betastadium verlassen und durch die Übernahme von Sun durch
Oracle ist die weitere Entwicklung von JavaFX ungewiss (20).
4.2.2. Wahl der Entwicklungsumgebung
Als Entwicklungsumgebung wurde das quelloffene Programmierwerkzeug Eclipse21
eingesetzt, da es eine Vielzahl von sehr hilfreichen Erweiterungen - sowohl quelloffen als
auch von kommerziellen Anbietern - gibt. Des Weiteren bietet Eclipse eine AutoKorrektur sowie zahlreiche weitere nützliche Funktionen wie z.B.
20
21
http://www.javafx.com/
http://www.eclipse.org/
30. November 2009
35
Implementierung
36
•
Auslagern von Strings zur Unterstützung von Mehrsprachigkeit
•
konfigurierbares Formatieren
•
umfangreiche Debugging Möglichkeiten
•
zahlreiche Refactoring22 Möglichkeiten
•
viele verfügbare open source Erweiterungen
4.3. Designpattern
Um bestimmte Probleme bei der Implementierung geschickt zu lösen, wurden
geeignete Designpattern gesucht. Sie sind bewährte Lösungsvorschläge für
wiederkehrende Entwurfsprobleme in der Softwarearchitektur und
Softwareentwicklung. Sie stellen damit eine wiederverwendbare Vorlage zur
Problemlösung dar, die in einem bestimmten Zusammenhang einsetzbar ist. Im
Folgenden werden die Funktionsweise und der Verwendungsgrund der genutzten
Designpattern erläutert.
4.3.1. Singleton
Ein bekanntes Problem in der Programmiersprache Java besteht aus dem Fehlen von
globalen Variablen, wie man sie beispielsweise von C++ kennt. Abhilfe schafft hier das
Singleton Designpattern. Es ist ein in der Softwareentwicklung eingesetztes
Entwurfsmuster und gehört zur Kategorie der Erzeugungsmuster. Es besteht aus einer
eigenen Klasse mit privatem Konstruktor und einer öffentlichen, statischen Methode
(getInstance()), welche die Instanz der Klasse zurückliefert.
Singleton
-instance : Singleton
-Singleton()
+getInstance() : Singleton
Abbildung 7) Singleton Konstruktor
Quelltext der Methode getInstance():
22
Refactoring bezeichnet in der Software-Entwicklung die manuelle oder automatisierte
Strukturverbesserung von Programm-Quelltexten unter Beibehaltung des Programm-Verhaltens.
30. November 2009
public static Singleton getInstance() {
if (instance == null)
instance = new Singleton();
return instance;
}
Abbildung 8) UML Diagramm der Klasse Singleton
Durch diesen Aufbau ist es möglich auf die Instanz der Klasse Singleton global
zuzugreifen (Singleton.getInstance()). Der private Konstruktor verhindert
außerdem, dass Instanzen direkt erzeugt werden können; nur mittels der Methode
getInstance() kann eine einzelne Instanz erzeugt werden.
4.3.2. Builder
Sind zum Erzeugen eines Objektes bestimmte Parameter notwendig und andere nur
optional, so lässt sich dies mittels unterschiedlichen Konstruktoren realisieren, die sich
alle anhand ihrer Signatur unterscheiden. Diese hat jedoch als Nachteil, dass die
Lesbarkeit abnimmt und viele Konstruktoren geschrieben werden müssen.
Eine Alternative hierzu bietet das Builder Pattern aus dem Bereich der
Softwareentwicklung. Es gehört zur Kategorie der Erzeugungsmuster (Creational
Patterns). Es trennt die Konstruktion komplexer Objekte von deren Repräsentationen,
wodurch dieselben Konstruktionsprozesse wiederverwendet werden können.
Im Wesentlichen besteht das Builder Pattern aus einer Objektklasse, einer inneren
statischen Builder Klasse, welche für jeden optionalen Parameter eine eigene Methode
enthält, und aus einer build Methode zum Erzeugen des Objektes.
Um ein Objekt zu erzeugen wird der Konstruktor der inneren Builder Klasse nur mit
den erforderlichen Parametern aufgerufen, wodurch der Konstruktor schlank und somit
lesbar bleibt. Um weitere optionale Parameter anzugeben, werden die in der inneren
Klasse definierten Methoden an den Konstruktor angehängt. Der folgende Quelltext
illustriert dies:
new Constraint.Builder(
new StringVariable("SI_STUERT","J"),
new StringVariable("SI_STAUSF",["SH, SL"]))
.requires().build());
Abbildung 9) Beispiel eines Constraints
30. November 2009
37
Implementierung
38
Die Methode requires() ist hierbei in optionaler Parameter, der zwischen dem
Konstruktor(StringVariable) und der build() Methode steht und angibt, dass wenn die
Variable „SI_STUERT“ den Wert „J“ hat, muss die Variable „SI_STAUSF“ den Wert „SH“
oder „SL“ haben.
4.3.3. Model View Controller
Zur Trennung von Darstellung und Logik, setzt die Orbis CS setzt das Model View
Controller Pattern ein. Es lassen sich dadurch mehrere unterschiedliche Sichten (Views)
für ein Konfigurationsproblem erstellen. Dies ist sinnvoll, da beispielsweise Endkunden
und unternehmensinterne Mitarbeiter andere Sichten mit unterschiedlichem
Detaillierungsgrad oder auch anderen Userinterfaceelementen bevorzugen.
Das Model-View-Controller-Konzept beinhaltet die genaue Aufgabenverteilung
innerhalb einer Anwendung. So versteht man unter dem Model die Datenquelle, die
Daten unabhängig vom Erscheinungsbild liefert (z.B. aus einer Datenbank oder externen
Quelle). Die View zeigt diese Daten in passender Form an (z.B. grafische Vorschau des
Produktes), wobei die Art und Weise wie diese View die Daten anzeigt nicht vom Model
beeinflusst wird.
Der Controller steuert die Interaktion mit dem Benutzer (das Verhalten der
Komponente). Wird beispielsweise in der angezeigten Merkmaltabelle ein Wert
geändert, so teilt der Controller dies dem Model mit, welches wiederum die View
darüber informiert, dass eine Änderung erfolgte und eine Aktualisierung der Grafik
notwendig ist.
Der Vorteil dieser Aufgabenverteilung ist zum einen die Möglichkeit der Aufteilung
in logische, unabhängige Klassen, wie auch die Möglichkeit, jede der drei Komponenten
jederzeit auszutauschen. Hierdurch ist bei der Java Bibliothek Swing der Austausch des
Look-and-Feels23 zur Laufzeit möglich.
Die nachstehende Abbildung soll diesen Zusammenhang verdeutlichen:
23
Eine Liste verfügbarer Look-and-Feels findet sich unter http://www.javootoo.com
30. November 2009
Abbildung 10) Model View Controller Pattern (31)
G
Alle vorgestellten Designpattern eignen sich zur Erstellung eines generischen
Produktkonfigurators, da sie allgemeine und in diesem Bereich immer auftretende
Probleme wie
•
das Fehlen von globalen Variablen in Java,
•
die schlechte Lesbarkeit von Konstruktoren mit vielen Parametern und
•
die Notwendigkeit von verschiedenen Darstellungsmöglichkeiten zu ein und
demselben Modell aufgrund unterschiedlichem Hintergrundwissen
(Endkunde und Vertriebsmitarbeiter)
elegant lösen. Besonders die letzte Anforderung spielt im Zusammenhang der
Produktkonfiguration eine entscheidende Rolle, da verstärkt der Endkunde die
Konfiguration eines Produktes selbst übernehmen soll. Dieser Endkunde verfügt in den
meisten Fällen über wenig oder kein Produktwissen, so dass er eine vereinfachte und
stärker System-geführte Konfiguration – also eine andere Sicht auf das Problem wie
beispielsweise ein Vertriebsmitarbeiter – bevorzugt.
30. November 2009
39
Implementierung
40
4.4. Laufzeit und Effizienzoptimierung
4.4.1. Hash Tabelle
Zur Verwaltung und Speicherung der Merkmale, wurde eine Datenstruktur gesucht,
die folgende Operationen besonders effizient implementiert:
•
Abspeicherung und von Merkmalen (Wertepaar bestehend aus Name und
Wert) in die Datenstruktur
•
Prüfung ob ein Merkmal bereits in der Datenstruktur vorhanden ist
•
Unterbindung von Mehrfachspeicherungen ohne explizite Prüfungen zu
erstellen
Die effiziente Implementierung obiger Methoden ist besonders wichtig, da die
Datenstruktur – selbst bei weniger komplexen Konfigurationen – sehr schnell über
tausend Einträge aufweisen kann.
Eine weitere Anforderung besteht darin, dass jedes Merkmal nur einmal in der
Datenstruktur vorkommen kann, d.h. beim erneuten Speichern eines Merkmals, soll der
vorherige Wert überschrieben werden.
Aufgrund dieser Überlegungen wurde zum Speichern der Merkmale eine Linked
Hashmap gewählt, da sie für die beschriebenen Aktionen lediglich konstante Laufzeiten
benötigt und somit die Größe (d.h. die Anzahl der gespeicherten Elemente) keine Rolle
spielt.
Die Klasse Linked HashMap ist eine Unterklasse von HashMap, die alle ihre
Eigenschaften erbt und zusätzlich eine Reihenfolge bietet in der ein Iterator Elemente
zurückliefert. Im Gegensatz zu LinkedHashSet bietet LinkedHashMap eine Wahl der
Reihenfolge, in welcher der Iterator die Hash Tabelle durchlaufen soll. Elemente können
in der Reihenfolge ausgegeben werden, in der sie hinzufügt wurden oder in der sie
bearbeitet wurden.
Die Folgende Tabelle zeigt sieben Map Implementierungen von Java und
verdeutlicht die Laufzeitunterschiede anhand dreier Methoden. Die Variable h
bezeichnet hierbei die Kapazität der Tabelle.
•
get(key): Liefert den Wert dem der angegebene Schlüssel zugeordnet ist.
30. November 2009
41
•
containsKey(name): Liefert true zurück, falls dem angegebenen Schlüssel ein
Wert zugeordnet ist.
•
next(): Liefert das folgende Element innerhalb der Hash Tabelle zurück.
get()
containsKey()
next()
HashMap
O(1)
O(1)
O(h/n)
LinkedHashMap
O(1)
O(1)
O(1)
IdentityHashMap
O(1)
O(1)
O(h/n)
EnumMap
O(1)
O(1)
O(1)
O(log n)
O(log n)
O(log n)
O(1)
O(1)
O(h/n)
O(log n)
O(log n)
O(1)
TreeMap
ConcurrentHashMap
ConcurrentSkipListMap
Abbildung 11) Vergleich von Map Implementierungen anhand ihrer Laufzeiten
4.4.2. Queues
Bei Änderungen in der Grafik, die mehrere Merkmale betreffen, sollte nicht jedes
Merkmal einzeln übertragen und auf Konsistenz geprüft werden, sondern alle
Änderungen sollten in einem Durchgang an die ORBIS CS gesendet und erst dann
verarbeitet werden.
Um dies zu realisieren eignet sich die Datenstruktur Queue. Diese kann eine
beliebige Anzahl von Objekten aufnehmen und diese in der Reihenfolge ihres Einfügens
wieder zurückliefern. Dazu werden folgende Operationen zur Verfügung gestellt:
•
enqueue: zum Hinzufügen eines Objekt und
•
dequeue: zum Zurückholen und Entfernen eines Objektes
Dabei wird nach dem First In – First Out-Prinzip gearbeitet, das heißt, es wird von
dequeue immer das Objekt aus der Warteschlange zurückgegeben, welches als erstes
mit enqueue eingefügt wurde. Diese – recht simplen – Operationen sind in der Queue
Datenstruktur besonders effizient implementiert, so dass, falls die oben genannten
Methoden ausreichen, die Verwendung dieser Datenstruktur empfehlenswert ist. Die
30. November 2009
Implementierung
42
beiden oben genannten Methoden haben konstante Laufzeit, so dass die Länge der
Queue keine Rolle spielt.
Werden umgekehrt Änderungen in der ORBIS CS getätigt, so ist die
Vorgehensweise analog zu oben. Der Konfigurator stellt ebenfalls eine Queue zum
Sammeln von Merkmalen zur Verfügung, die in einem Schritt verarbeitet werden
können. Dadurch wird nicht bei jeder Markmaländerung geprüft, ob sich Änderungen in
der Grafik ergeben.
4.4.3. Konsistenzprüfungen
Zum Hinterlegen von Bedingungen und zur Überprüfung des Modells auf
Widerspruchsfreiheit, wurde ein eigenes Package bestehend aus den Klassen
DependenceModel, Constraint, Variable, IntVariable und StringVariable erstellt. Der
Fokus bei der Erstellung dieser Klassen lag dabei auf der Lesbarkeit des Quellcodes und
der effizienten Implementierung der Prüfroutinen. Ersteres ist von Bedeutung, da in
einem regelbasierten System die Komplexität der Wissensbasis mit jeder Änderung oder
Erweiterung schnell wächst (9) und somit eine gute Lesbarkeit des Quelltextes wichtig
ist. Um dies zu erreichen wurde u.a. das in 4.3.2 vorgestellte Design Pattern verwandt,
welches Klassenkonstruktoren schlank hält und trotzdem weitere Parameter ermöglicht,
ohne dass die Lesbarkeit darunter leidet. Um die Prüfroutinen nicht unnötig oft
aufzurufen werden diese nur bei tatsächlichen Änderungen aktiv, was einen
Performancegewinn darstellt. Ebenso wurde es durch den Einsatz einer Queue
ermöglicht, eine Reihe von Änderungen vorzunehmen wobei erst nach deren
vollständiger Abarbeitung die Konsistenzprüfungen starten.
Die Klasse DependenceModel ist hierbei der Ausgangspunkt, welcher Variablen und
Constraints (Beziehungen zwischen zwei oder mehreren Variablen) zugeordnet werden
können. Außerdem enthält sie eine Methode zur Überprüfung des gesamten Modells
auf Widerspruchsfreiheit. Zur Verwaltung von Variablen dient die abstrakte Klasse
Variable, welche die Klassen IntVariable und StringVariable als untergeordnete Klassen
mit jeweils eigenen Prüfmethoden besitzt. Sie dienen dazu konkrete
Variablenbelegungen zu speichern. Bei Inkonsistenzen färbt sich eine Statusleuchte rot
und ein Button zum Anzeigen der Fehlerdetails erscheint. Durch Drücken auf diesen
Button erscheint ein Popup Fenster mit Fehlermeldungen, die zuvor in einen StringBuffer
30. November 2009
geschrieben wurden.
Ein StringBuffer ist ein Container,, in dem eine Zeichenkette abgelegt wird, die über
bestimmte Methoden modifiziert werden kann. Der wesentliche Unterschied zur Klasse
String besteht darin, dass der
de StringBuffer veränderbar ist, d.h. während
ährend die
Manipulations-Methoden
Methoden der
de String Klasse immer neue String-Objekte
Objekte erzeugen,
erzeu
arbeiten die Methoden auf ein und demselben Objekt,, woraus sich ein
Performancevorteil im Vergleich zu String ergibt.
Die folgende Abbildung verdeutlicht den Aufbau des Constraint Packages:
Abbildung 12) UML Klassendiagramm des Packages Constraint
4.4.4. Variablen
Variablen können mittels der Klasse IntVariable (Speicherung von ganzzahligen
Werten) und StringVariable (Speicherung von Zeichenketten) in das Model eingebunden
werden.
Bei IntVariable kann festgelegt werden, ob eine Variable
•
gesetzt sein muss.
•
einen bestimmten Wert haben muss.
•
in einem Intervall liegen muss.
30. November 2009
43
Implementierung
•
44
in einem Intervall mit bestimmten Schrittweiten liegen muss.
Die Klasse StringVariable ist ähnlich aufgebaut. Hier kann bestimmt werden ob, eine
Variable
•
gesetzt ein muss.
•
einen bestimmten Wert haben muss.
•
einen bestimmten Wert aus einer Liste haben muss.
Bei Verletzung einer Bedingung wird eine entsprechende Text Meldung generiert.
4.4.5. Constraints - Requires Relationen
Um Anzugeben, dass eine Variable erforderlich ist, wenn eine andere nicht leer oder
einen bestimmten Wert hat, wird die requires Relation verwandt. Im Folgenden Beispiel
muss die Variable „SI_VGLANORD“ einen Wert erhalten, sobald der Variable
„SI_VGLTYP_OTG“ ein Wert zugewiesen wird. Man beachte den Aufruf der build()
Methode, die das Objekt erzeugt nachdem alle Parameter angegeben wurden.
new StringVariable("SI_VGLTYP_OTG"),
new StringVariable("SI_VGLANORD"))
.requires().build());
Abbildung 13) Quelltext Beispiel einer require Relation
4.4.6. Constraints – Junction Relationen
Um logische Relationen zwischen Variablen zu definieren dient die junction Relation.
Hier können die logischen Verknüpfungen AND, XOR und NAND hinterlegt werden. Das
folgende Beispiel illustriert die Verwendung einer NAND Relation: Wenn die Variable
„SI_VGLTYP_UTG“ den Wert „A“, „D“ oder „E“ hat, darf die Variable
„SI_TGTYP_UTG“ nicht den Wert „AL“ haben. Umgekehrt gilt dies genauso.
new StringVariable("SI_VGLTYP_UTG", new String[]
{"A","D","E"}),
new StringVariable("SI_TGTYP_UTG", "AL"))
.junction(Junction.NAND).build());
Abbildung 14) Quelltext Beispiel einer Junction.NAND Relation
Der Verwendung von AND und XOR Relationen ist analog zu obigen Beispiel.
30. November 2009
Junction.NAND ist hierbei durch Junction.XOR bzw. Junction.AND zu ersetzen.
G
Die hier vorgestellten Datenstrukturen empfehlen sich alle zur Erstellung eines
generischen Produktkonfigurators, da immer
•
Variablen verwaltet werden müssen und
•
die Möglichkeit bestehen muss, dass diese in Paketen (Queues) verarbeitet
werden können
Es hängt nur davon ab, welche Programmiersprache verwendet wird, da es hier
unterschiedliche Map Implementierung gibt, die sich im Detail in ihrer Laufzeit
unterscheiden können.
Bei reinen regelbasierten Systemen kann es sinnvoll sein, externe Bibliotheken zur
Erstellung von Konsistenzprüfungen zu verwenden, da in diesem Bereich der Fokus auf
ihnen liegt und eine große Funktionalität wünschenswert ist. In den beiden anderen
Bereichen (wissensbasierte und Entscheidungstabellen-basierte Systeme) werden
Constraints nicht eingesetzt oder sie haben keine zentrale Bedeutung. Hier kann es
durchaus sinnvoll sein, die benötigten Klassen mit den notwendigen Funktionalitäten
selbst zu erstellen. Generell sollte aber der Einsatz eines regelbasierten Systems kritisch
betrachtet werden, da hier die Pflege und die Verwaltung der Constraints mit der Zeit
immer komplexer und somit auch aufwendiger wird. Nur bei weniger komplexen
Konfigurationsproblemen ist deren Einsatz empfehlenswert.
4.5. Datenverarbeitung
4.5.1. Zeichenobjekte (DrawingObject)
Um Objekte darzustellen wurde für jedes eine eigene Klasse entwickelt, die alle der
abstrakten Klasse DrawingObject untergeordnet sind.
Die folgende Grafik beschreibt den Aufbau der Zeichenobjekte.
30. November 2009
45
Implementierung
46
DrawingObject
MainGate
Elmement
MainGate
Sandwich
Window
Door
AluFrame
Window
Abbildung 15)
15 Die abstrakte Klasse DrawingObject mit ihren Unterklassen
Die in der Hierarchie oberste abstrakte Klasse ist DrawingObject.. Sie enthält dabei
alle Methoden und Felder, die in allen untergeordneten Klassen benötigt werden,
werden wie
z.B.: X/Y Koordinate und Höhe/Breite
Höhe/
des Objektes. Alle untergeordneten Klassen erben
diese Methoden und Attribute, so dass diese nicht wieder implementiert werden
müssen.
4.5.2. Tree
Zur hierarchischen und strukturierten Speicherung aller grafischen Objekte wurde
eine eigene Baumstruktur erstellt. Ein Baumobjekt besteht hierbei aus einem
eine
Zeichenobjekt (DrawingObject
DrawingObject) und enthält dabei Referenzen auf den
d
übergeordneten Baum (parent: Tree) und auf eine Liste mit untergeordneten
Bäumen (children:
children: ArrayList<Tree>).
Betrachten wir als Beispiel ein Tor,
Tor welches aus drei Torgliedern besteht und eine
Tür besitzt. Außerdem sind in den Torgliedern mit Nummer zwei und drei Fenster
eingebaut. Die Baumdarstellung dieses Tores lautet:
MainGate
MainGate
Element 1
MainGate
Element 2
MainGate
Element 3
Sandwich
Window
Sandwich
Window
Door
Abbildung 16)) beispielhafte Baumdarstellung eines Tores
30. November 2009
Der Baumknoten besteht aus dem Haupttor, welcher die Grunddaten (X/Y Position
und Höhe/Breite) beherbergt. Alle übrigen Elemente sind untergeordnete Objekte, da sie
sich innerhalb des Tores befinden. Auf der nächsten Stufe befinden sich die einzelnen
Torgliedelemente und die Tür. Auf der dritten Stufe sind die Fenster und Alurahmen zu
finden, da sie immer in ein bestehendes Torgliedelement eingesetzt werden. Durch diese
Anordnung wird das Tor mit jeder weiteren Stufe in immer kleinere Bereiche unterteilt.
Beim Einfügen neuer Objekte spielt immer nur das übergeordnete Objekt eine Rolle
anhand dessen die Positionierung berechnet wird.
Beim Einfügen eines Zeichenobjektes kann das übergeordnete Objekte für die
Position ausschlaggebend sein aber auch das Objekt selbst. Letzteres ist beispielsweise
bei der Tür der Fall, diese wird immer in die erste Hierarchieebene eingefügt. In diesem
Fall muss der Konstruktor dementsprechend angepasst werden, damit beim Erzeugen
und Einfügen des Objektes der korrekte Platz im Baum eingenommen wird.
G
Diese Art der Verwaltung eignet sich auch für einen generischen Konfigurator. Die
Standardmethoden, die für jeden Konfigurator empfehlenswert sind, bestehen hierbei
aus:
•
get/setChildren()
•
get/setParent()
•
getNumberOfChildren()
•
addChild(Tree)
•
removeChild(Tree), removeChildAt(int)
•
get/setData()
•
isMarked(): überprüft ob ein Baumobjekt markiert / ausgewählt ist.
•
pre/post/inOrder(): Überführung des Baumes in eine Liste mit allen
Blattknoten in einer bestimmten Reihenfolge.
•
hasChildWithTypeOf(String)
Besondere Bedeutung haben hier bei die Baum-Traversierungsmethoden
preOrder() und postOrder(). Diese Methoden liefern eine geordnete Liste aller
Zeichenobjekte, wobei das Durchlaufen bei preOrder() nach der depth-first und bei
30. November 2009
47
Implementierung
48
24
postOrder() nach der breadth-first
breadth
Methode abläuft. Die folgenden Grafiken
verdeutlichen die Unterschiede zwischen beiden Methoden und zeigen die
Darstellungen des Tores aus 4.5.2.
MgElem 1
MgElem 2
MgElem 3
Door
S.Window
S.Window
Abbildung 18) Pre-Order Darstellung
MgElem I
S.Window
MgElem 2
S.Window
MgElem 3
Door
Abbildung 17) Post-Order Darstellung
Anhand der preOrder() Reihenfolge, werden die die Objekte gezeichnet. Die
postOrder() Reihenfolge bestimmt welches Objekt markiert
markiert wird, falls Objekte
übereinanderliegen und eine
ein Objektanwahl stattfindet. Es werden somit unterliegende
Objekte als erstes selektiert. (z.B. ein Alu Fenster liegt in einem Torgliedelement, beim
Selektieren soll aber nur das Alu Fenster gewählt werden können).
Die gewünschte Hierarchie wird dadurch eingehalten,
eingehalten indem
dem Objekte nur
hinzugefügt werden können, wenn das gewünschte übergeordnete Objekt markiert ist.
Das neue Objekt wird in diesem Fall als Unterbaum eingefügt. Lediglich die Tür, welche
nur dem Tor selbst ungeordnet ist, wird immer in die zweite Hierarchiestufe eingefügt.
Vor
or dem Einfügen muss daher nicht das Tor markiert werden.
24
Breitensuche
30. November 2009
4.6. Klassendesign
4.6.1. Übersicht
Abbildung 19)) Klassendiagramm des grafischen Konfigurators
30. November 2009
49
Implementierung
50
4.6.2. Drawing Manager
Diese Klasse dient als Schnittstelle zur ORBIS CS. Sie enthält alle notwendigen
Methoden, damit die ORBIS CS Werteänderung an die Grafikkomponente senden kann,
worauf Änderungen in der Grafik erfolgen können. Die Methoden selbst, sind in der
Klasse Data Handler ausgelagert und werden lediglich von Drawing Manager
aufgerufen. Umgekehrt erhält sie von der ORBIS CS eine Instanz dessen
InstanceManagers, damit Änderungen des Benutzers in der Grafik an die ORBIS CS
übertragen werden können.
Außerdem instanziiert sie ein Drawing Panel und erstellt eine Instanz des Data
Handlers, welcher bei Wertänderungen durch Die ORBIS CS die Grafik anpasst, bereit.
Die Art und Weise dieser Änderungen wird durch die Klasse LogicContainer spezifiziert.
4.6.3. Drawing Panel
Ein zentrales Element des grafischen Konfigurators stellt die Klasse „DrawingPanel“
dar. Sie implementiert Mouse- und Mouse Motion Listener zur Steuerung von Benutzer
Interaktionen (z.B. Hinzufügen einer Tür) und gibt diese Änderungen weiter an die
Klasse Data Handler. Umgekehrt werden auch Änderungen von der ORBIS CS an Data
Handler übergeben und dort weiterverarbeitet. Des Weiteren instanziiert sie alle UI
Elemente sowie den Zeichenbereich (DrawingArea).
4.6.4. Data Handler
Diese Klasse steuert zentral die Änderungen der Grafik, wenn Änderungen von der
ORBIS CS ausgehen und wenn Änderungen über die Benutzerschnittstelle erfolgen. Für
Ersteres stellt Data Handler Methoden wie beispielsweise setValue und deleteValue zur
Verfügung. Um nicht bei jeder Änderung überprüfen zu müssen, ob eine Aktualisierung
der Grafik notwendig ist, stellt sie außerdem die Methoden setValueToInputQueue und
processInputQueue zur Verfügung. Erstere dient dazu, Werte in eine Warteschlange
(Queue) zu setzen, die mit der Methode processInputQueue verarbeitet werden können.
Durch die Verwendung einer Queue können somit mehrere Variablen gesetzt werden,
ohne bei jeder Wertsetzung zu prüfen, ob sich Änderungen in der Grafik ergeben.
Dieser Einsatz der Queue bietet somit einem Performancevorteil.
30. November 2009
4.6.5. Logic Container
Mit der Klasse Logic Container ist es möglich, einem Objekt mehrere Variablen
zuzuordnen und zu bestimmen, welche dieser Variablen gesetzt sein müssen, damit das
jeweilige Objekt gezeichnet werden kann. Neben den Variablen lassen sich noch
Funktionen zuordnen, die bei Ausführung „true“ zurückliefern müssen, damit das
betreffende Objekt gezeichnet wird. Sie beinhaltet somit alle notwendigen
Variablenbelegungen und Nebenbedingungen eines Objektes.
G
Diese Klasse ist bereits generisch implementiert, so dass sie für alle Arten von
Objekten eingesetzt werden kann.
4.6.6. UI Changer
Die Klasse UI Handler dient zur Steuerung der Userinterface-Elemente (z.B.
Auswahllisten) und ermöglicht das Verändern des Erscheinungsbildes (ergrauen und
ausblenden). Durch die Zuordnung eines Zeichenobjektes (DrawingObject) zu einem
oder mehreren UI Elementen können Methoden hinterlegt werden, die bei der Auswahl
eines Objektes ausgeführt werden und die Darstellung ändern.
G
Diese generische Art der Userinterface-Steuerung eignet sich prinzipiell für alle
Arten von Konfiguratoren.
4.7. Ablauf einer Variablenänderung in der ORBIS
Configuration Suite
Wird eine Variable in der Orbis CS geändert oder gesetzt, so wird die setValue()
Methode des grafischen Konfigurators aufgerufen. Diese Methode ist Bestandteil der
Klasse DrawingManager und sie reicht die getätigte Änderung weiter an die Klasse
DataHandler. Diese überprüft, ob sich durch die Wertsetzung eine Änderung in der
Grafik ergeben hat, aktualisiert diese dementsprechend und legt die Variable in der Hash
Tabelle, die alle Variablen verwaltet, ab. Außerdem wird bei einer Änderung, diese auch
an die Klasse UIChanger weitergeleitet, die für die Aktualisierung der
Benutzerschnittstelle verantwortlich ist. Je nachdem welche Art von Änderung
stattgefunden hat, werden UI Elemente ausgeblendet, ergraut oder beinhalten andere
Werte.
30. November 2009
51
Implementierung
52
Die Folgende Abbildung illustriert diesen Ablauf in vereinfachter Form:
Abbildung 20) Sequenzdiagramm einer Variablenänderung
Nachdem dieser Prozess abgeschlossen ist, startet die Konsistenzprüfung, die das
Ergebnis visuell anzeigt.
4.8. Hardwareanforderungen
Insgesamt betrachtet stellt das Programm keine hohen Anforderungen an einen
Rechner. Ein Pentium 425 oder ein AMD Athlon XP26 Prozessor genügt, um ein flüssiges
Arbeiten zu ermöglichen. Der Einsatz eines Zwei – oder Vierkernprozessors bringt keine
Vorteile, da die Anwendung nicht auf den Mehrkern-Betrieb optimiert wurde. Ebenso
genügt eine onboard Grafikkarte, da weder Schattierungen noch Lichtreflektionen
verwendet werden. An rechenintensiven Operationen wird nur Antialiasing27 bei der
Kantenglättung von Text eingesetzt. Da dies nur ein kleiner Teil der Grafik ist, fallen
diese Berechnungen nicht ins Gewicht.
Beim Einsatz von Windows XP sind 512 MB oder mehr und bei Windows Vista bzw.
Windows 7 1024 MB Arbeitsspeicher oder mehr empfohlen.
25
http://www.intel.com/products/processor/pentium4/index.htm
http://www.amd.com/athlonxp
27
Bezeichnet eine Technik zur Verminderung von unerwünschten Effekten, die durch ein
begrenzt aufgelöstes Pixelraster verursacht werden. Ein sehr häufig auftretender Effekt ist der
Treppeneffekt, der bei der Erzeugung einer Computergrafik entstehen kann.
26
30. November 2009
5. Generischer Aufbau
Dieser Abschnitt behandelt den Aufbau eines generischen grafischen Konfigurators
anhand ausgewählter Literatur und wird durch persönliche Empfehlungen und
Erfahrungen, die während der Konzeption und Implementierung des in dieser Arbeit
beschriebenen grafischen Konfigurators gewonnen wurden, ergänzt.
5.1. Einsatzbereich
Grundsätzlich stellt sich die Frage ob die grafische Konfiguration im 2D oder 3D
Modus erfolgen soll. Beide Modi haben jeweils ihre Vor- und Nachteile, wobei der 2D
Modus im Allgemeinen die bessere Wahl ist. Dies liegt daran, dass Benutzer mit einer 2D
Ansicht leichter zurechtkommen, da hier kein räumliches Denken notwendig ist, welches
laut Thurstone (21) eines von sieben Primärfaktoren der intellektuellen Kapazität
darstellt. Um Benutzer ohne diese Fähigkeit nicht auszuschließen, ist eine Interaktion im
2D Modus die beste Wahl. Außerdem sind hier Überdeckungen einzelner Objekte
leichter zu erkennen als im 3D Modus. Durch den Einsatz des 2D Modus ergibt sich
sowohl eine Reduzierung der Komplexität in der Bedienung als auch in der Entwicklung,
da beispielsweise komplexe Kollisionsprüfungen (Ineinanderstellen von Objekten)
entfallen. Um einen Vorteil der 3D Ansicht – nämlich die Nähe zur Realität – nutzen zu
können, sollte das fertig konfigurierte Produkt in einer 3D-Ansicht visualisiert werden
können. Dies kann beispielsweise durch eine Anbindung an ein CAD Programm erfolgen
oder durch den Export des Produktes als PDF 3D28 Datei. Letzteres bietet den Vorteil,
28
http://www.acrobat3d.de/
30. November 2009
53
Generischer Aufbau
54
dass auch Endkunden ihr Produkt von allen Seiten betrachten können, da der benötigte
Adobe Acrobat Reader kostenlos verfügbar ist29.
Der Einsatz zielt auf die Produktionsgüterindustrie für Objekte wie beispielsweise
Fenster, Türen und Tore, die aus einfachen geometrischen Figuren wie Quadrat,
Rechteck, Dreieck, Kreis oder Ellipse bestehen, wobei es erlaubt ist, Objekte
übereinander zu positionieren.
5.2. Aufbau
Für den Aufbau der Applikation empfiehlt sich die Einteilung in folgende vier
Komponenten:
•
GUI Designer zur Anpassung und Erstellung der Benutzerschnittstelle und
zum Hinterlegen von „UI-Effekten“ wie ein/ausblenden und ergrauen von UIElementen
•
Objekteditor zur Erstellung der grafischen Darstellung der einzelnen
Objekte bzw. Bauteile
•
Regeleditor um Beziehungen zwischen den Objekten / Bauteilen
herzustellen und entsprechende Konsistenzbedingungen zu hinterlegen
•
Struktureditor um den grundsätzlichen Aufbau eines Produktes zu
beschreiben mit all seinen möglichen Ausprägungen ohne weitere Logik zu
beinhalten
Abramovici et Al. verfolgten in ihrem KoViP Projekt (9) die gleiche Strategie und
nahmen ebenfalls eine Unterteilung in diese vier Elemente vor. Sie empfahlen weiterhin
alle Daten in einer Konfigurationsdatenbank zu speichern, damit alle Komponenten
zugreifen können. Dies ist nötig, da einige Objekte von mehreren Komponenten
bearbeitet werden. Zur Anbindung von externen Systemen wie einer CAD Anwendung
entwickelten sie eine weitere Komponente, die eng mit dem Objekt- und dem
Struktureditor verbunden ist.
29
http://get.adobe.com/de/reader
30. November 2009
55
Die nachstehende Grafik veranschaulicht die Zusammenhänge zwischen den vier
Komponenten und zeigt Beziehungen zu weiteren Objekten auf:
1
*
GUI Editor
Struktureditor
*
1
*
*
*
Einzelteil
Konfigurierbares Material
Gui Element
* *
*
*
*
1
*
*
*
Zeichenobjekt
Objekteditor
*
*
Variable
1
*
1
1
*
*
Constraint
Regeleditor
*
*
Abbildung 21) Übersicht generischer grafischer Konfigurator
Im Folgenden gehe ich näher auf die einzelnen Komponenten ein und erläutere
ihren Aufbau und deren Funktionsweise.
5.2.1. Regeleditor
Der Regeleditor dient zum Hinterlegen der Produktlogik und Konsistenzprüfungen
und somit zum Erstellen des gesamten Beziehungswissens. Die Produktlogik kann z.B.
mit Entscheidungsbäumen realisiert werden(22), wobei zwischen UND- bzw. ODERBäumen zu unterscheiden ist (23). Letztere bestehen aus Knoten, die jeweils eine ODERVerknüpfung der folgenden d.h. ungeordneten Knoten beinhalten. Es kann also nur ein
Knoten gewählt werden.
Ein Ast eines ODER-Entscheidungsbaumes könnte hierbei bedeuten:
•
wenn „Tür“ gewählt wird, dann ist keine weitere Tür wählbar, oder
•
wenn „Breite größer als 6000 mm“ gewählt wird, dann sind nur noch
Torhöhen kleiner als 6000 mm wählbar.
Die Definition von UND-Bäumen ist analog zu ODER-Bäumen, wobei Knoten in
gleicher Hierarchiestufe bedeuten, dass alle Knotenmerkmale erforderlich sind. Es
müssen also alle Knoten gewählt werden.
30. November 2009
Generischer Aufbau
56
Zusammenfassend lässt sich sagen, dass UND/ODER-Bäume bei der Konfiguration
von besonderem Interesse sind (24). Sie eignen sich zur Repräsentation von
Konfigurierungsproblemen. In UND-Knoten kann festgehalten werden, welche Arten
von Bausteinen zur Realisierung eines Produktes notwendig sind, und in ODER-Knoten,
welche Alternativen für die Bausteine zur Verfügung stehen.
Die folgende Abbildung veranschaulicht den Einsatz von UND/ODER Knoten in einer
Baumdarstellung. In erster Stufe befinden sich zwei UND-Knoten, die beide erforderlich
für das Produkt sind. Die dritte Stufe besteht hingegen aus ODER-Knoten, aus denen
jeweils eine Auswahl getroffen werden muss.
Tor
UND
ODER
Torgliedelement
AluRahmen
Sandwichfenster
Oberflächendesign
Stucco
Micrograin
Abbildung 22) UND/ODER Baum
Prinzipiell stellt sich die Frage nach einem wissensbasierten, regelbasierten oder
Entscheidungstabellenbasierten System wie sie in 2.2 beschrieben wurden. Um den
Einsatzbereich eines Konfigurators zu maximieren, empfiehlt sich daher für einen
generischen Konfigurator ein wissensbasiertes System, da hier verschiedene Techniken
zur Regelhinterlegung verwendet werden und ein wissensbasiertes System auch bei
komplexen Anforderungen geeignet ist. Im Gegensatz dazu bestehen
•
entscheidungstabellenbasierte Systeme nur aus verknüpften Tabellen, mit
denen nur einfache Regeln hinterlegt werden können.
•
regelbasierte Systeme nur aus Constraints, deren Pflege und Erweiterung bei
komplexen Anforderungen sehr aufwändig ist.
Die zweite Hauptkomponente des Regeleditors besteht aus Konsistenzprüfungen,
die sich mittels Constraints realisieren lassen wie sie in 2.4 beschrieben wurden. Des
Weiteren sollte eine Benutzeroberfläche erstellt werden, mit der ohne
30. November 2009
Programmieraufwand Constraints hinterlegt werden können. Zur technischen
Umsetzung eignen sich funktionale Programmiersprachen, die Merkmale wie Pattern
Matching30 und Funktionen höherer Ordnung31 bieten. Das KoViP Projekt verwandte zur
Umsetzung hierzu die logische Programmiersprache Prolog. Ein Prolog-Programm
besteht aus einer Datenbasis, deren Einträge als Fakten und Regeln bezeichnet werden.
Der Benutzer kann Anfragen an diese Datenbasis stellen, woraufhin der PrologInterpreter die Fakten und Regeln benutzt, um systematisch eine Antwort zu finden.
Näheres zu Prolog incl. Tutorial ist in (25) zu finden.
Eine weitere wichtige Eigenschaft des Regeleditors besteht darin, das formulierte
Beziehungswissen als XML-Datei zu imund zu exportieren. Dadurch können technisch
versierte Benutzer auch Änderungen direkt in der XML-Datei vornehmen und diese im
Anschluss importieren. Dies ist z.B. sinnvoll um Bedingungen zu hinterlegen, dich nicht
über die Standard-Benutzerschnittstelle eingegeben werden können. Auch kann die Imund Exportfunktion dahingehend eingesetzt werden, um Beziehungswissen zu verteilen
(24) oder - wie in 2.3 erwähnt - die Produktlogik eines Dritten einzubinden. Um
Letzteres zu realisieren, muss eine geeignete Oberfläche erstellt werden, mit welcher der
zu importierende Inhalt der XML-Datei auf das unternehmensinterne Produktwissen
abgebildet wird.
Aufbau der Wissensbasis
Beim Aufbau der Wissensbasis ist es laut R. Rumage (26) empfehlenswert, zunächst
das Produkt genau zu definieren um im Anschluss die Hauptkomponenten zu
bestimmen. Die erste Phase besteht somit aus einer physikalischen und funktionellen
Analyse und der detaillierten Beschreibung des Produktes. In der zweiten Phase wird das
Endprodukt in Hauptkomponenten unterteilt und diese jeweils separat – auch oft von
verschiedenen Personen – möglichst vollständig beschrieben.
Essentielle Bestandteile der ersten Phasen sind die Produktlogik und die
Konsistenzbedingungen (Constraints). Sie bilden den Kern der Wissensbasis, welche sich
in eine dreigliedrige Hierarchie, bestehend aus Basiswissen, Benutzerwissen und
Produktwissen, einteilen lässt (9).
30
31
Musterabgleich
Funktionen, die als Ergebnis wieder eine Funktion zurückliefern.
30. November 2009
57
Generischer Aufbau
58
Auf der untersten Stufe dieser Wissenspyramide befindet sich das Basiswissen.
Dieses kann beispielsweise die Arithmetik zum Umrechnen zwischen Einheiten oder
länderspezifische Normen wie die verwendete elektrische Spannung liefern.
liefern
Auf der nächsten Stufe liegt das Produktwissen, welches alle notwendigen Regeln
und Konsistenzprüfungen zur Erstellung des jeweiligen Produktes enthält wie z.B.
„wenn Torbreite zwischen 3500mm und 4500mm, dann sind die gültigen
gültige Türpositionen
= 2,3,4“.
Die dritte und oberste Stufe besteht aus dem Projektwissen. Es beinhaltet das
Projekt-spezifische
spezifische Wissen, welches
welche nur in diesem Projekt relevant ist. Dies können
Sonderfälle oder zusätzliche Konfigurationsmöglichkeiten sein, wie z.B.
z.B. das Hinzufügen
eines weiteren Oberflächendesigns. Auch kann es verwandt werden um das Wissen
einer nur zeitweise verfügbaren
verfügbare Sonderedition eines Produktes zu hinterlegen. Wird ein
neues Projekt angelegt, wird somit immer auf das gleiche BasisBasis und Produktwissen
Prod
zurückgegriffen.
Projektwissen
Produktwissen
Basiswissen
Abbildung 23) Wissenspyramide
Das Produktwissen beinhaltet oft Regeln in der Art, dass „wenn Komponente A
ausgewählt wird, muss auch Komponente B ausgewählt werden“. Diese zusätzlich
erforderliche Auswahl sollte automatisch durch den Produktkonfigurator übernommen
werden, um dadurch die Benutzerinteraktivität zu verbessern.
verbessern Nach
ach Goetz Botterweck et
Al. (27) ist es wichtig,, eine solche automatische
a
Auswahl bzw. Abwahl dem Benutzer
sowohl grafisch (durch entsprechende Symbole und eine farbliche Hervorhebung der
betreffenden Komponenten)
Komponenten) als auch textuell mitzuteilen, damit dieser den Grund der
automatischen Aktion erkennt und somit das Produkt besser versteht.
30. November 2009
5.2.2. Objekteditor
Der Objekteditor dient als Modellierer für alle benötigten grafische Primitive. Hier
wird das Erscheinungsbild der Objekte festgelegt. Im Anschluss an die Modellierung wird
jedem Zeichenobjekt ein Einzelteil, welches im Struktureditor erstellt wurde, zugeordnet
um eine logische Verbindung zwischen grafischer Darstellung in internem Produktwissen
herzustellen.
Zur grafischen Modellierung empfiehlt sich der Einsatz eines vektorbasierten Editors,
der aus den Benutzereingaben Quellcode (in vorliegender Implementierung Java2D
Code) erzeugt. Optional können die Objekte mit Texturen versehen werden. Da dies
jedoch eine höhere Rechenzeit benötigt, sollte der Einsatz nur bei ausreichender
Rechenleistung in Erwägung gezogen werden. Der Vorteil des Einsatzes von Texturen,
wäre eine detailliertere Darstellung des Produktes, was dem Endkunden
entgegenkommt.
Des Weiteren ist sinnvoll, eine Importmöglichkeit für CAD-Zeichnungen zu schaffen,
da diese Zeichnungen in Unternehmen weit verbreitet sind und somit eine erneute
Modellierung im Objekteditor hinfällig ist.
Die Verwendung einer objektorientierten Programmiersprache eignet sich an dieser
Stelle aufgrund auftretender Vererbungshierarchien (10), welche in einer derartigen
Sprache leicht umzusetzen sind und sich der Programmieraufwand für untergeordnete
Klassen verringert.
5.2.3. GUI Designer
Alle benötigten Benutzerschnittstellen werden mit Hilfe des GUI Designers erstellt.
Er soll eine Auswahl aus allen gängigen UI Elementen wie Buttons, Tabellen,
Textbereichen, Auswahlboxen und Listenfelder bieten, die frei angeordnet werden
können. Um eine möglichst große Flexibilität und damit auch eine hohe Generik zu
erreichen, sollten alle UI-Elemente, die die verwendete Programmiersprache bietet, zur
Auswahl stehen.
Nachdem die Auswahl und Platzierung abgeschlossen ist, erfolgt die Zuordnung von UI
Elementen zu grafischen Objekten, die zuvor mittels des Objekteditors erstellt wurden.
Dies ist notwendig um bei Interaktionen mit den Zeichenobjekten, die
Benutzeroberfläche dynamisch anzupassen.
30. November 2009
59
Generischer Aufbau
60
5.2.4. Struktureditor
Der Struktureditor dient sowohl zum Anlegen aller Einzelteile eines konfigurierbaren
Materials als auch zur Beschreibung all seiner möglichen Ausprägungen ohne eine
bestimmte Produktlogik zu enthalten.
enthalten Nur der strukturierte und hierarchische Aufbau
des Produktes ist hier von Bedeutung.
Bedeutung Dies kann elegant mittels verknüpfter
Materialtabellen
abellen erreicht werden, wie es in wissensbasierten Systemen eingesetzt wird
(5).
Industrietor
Torgliedelement
•Torgliedelement
•Tür
•Sandwichfenster Typ A
•Sandwichfenster Typ D
•Sandwichfenster Typ E
•Alurahmen
Sandwichfenster Typ D
•Breite:
Breite: 400 - 450 mm
•Höhe:
Höhe: 250mm
Abbildung 24) Verknüpfte Materialtabellen
Falls Stammdaten in anderen Systemen (z.B. SAP) gepflegt werden, so sollen die
Materialien mittels einer Schnittstelle ausgewählt
a
werden können, ohne sie im
Struktureditor neu anlegen zu müssen.
müssen Diese Zeitersparnis durch Importieren
vorhandener Materialien spiegelt den hohen Stellenwert und einen Vorteil einer vollintegrierten Lösung wider.
5.3. Dateiformat zur Speicherung von Konfigurationen
Neben der Speicherung des fertig konfigurierten Produktes als PDF Dokument sollte
auch der Export als Grafikdatei möglich sein. Hier eignen sich am besten vektorbasierte
Dateiformate um beispielsweise in einer vergrößerten Detailansicht eine Pixelbildung zu
vermeiden. Zudem ist es von Nutzen noch weitere Informationen zu dem Objekt in diese
Bilddatei zu integrieren. Diese
D
beiden Anforderungen erfüllt das quelloffene SVG
Format32. Es dient der Speicherung
S
von zweidimensionalen Vektorgrafiken mittels einer
XML Datei,, die um weitere Attribute – wie Merkmalname und –wert
wert – ergänzt werden
kann.
Selbst bei einfachen Grafiken kann eine
ei SVG-Datei
Datei schnell mehrere hundert Zeilen
32
http://www.svg.org
30. November 2009
aufweisen. Um daher die Dateigröße nicht ausufern zu lassen, bietet sich eine
standardmäßige Komprimierung33 an. Die Kompressionsrate bei Textdateien ist im
Allgemeinen recht hoch, so dass die Dateigröße bei einer Kompression wesentlich
abnimmt. Als Komprimierungsmethode bietet sich das zip-Format an. Es bietet zwar im
Vergleich zu anderen Formaten wie rar oder 7zip eine schlechtere Komprimierungsrate
aber die größte Kompatibilität und es ist kostenfrei. Alle notwendigen Bibliotheken sind
für alle gängigen Programmiersprachen verfügbar, so dass deren Implementierung kein
Problem darstellt.
Bei SVG ist es außerdem möglich eigene Document Type Definitions34 anzulegen
und zu integrieren. Diese bestehen aus einem Satz von Regeln, um Dokumente eines
bestimmten Typs zu definieren. Eine Dokumenttypdefinition besteht dabei aus
Elementtypen, Attributen von Elementen, Entitäten und Notationen. Dies bedeutet, dass
in einer DTD die Reihenfolge, die Verschachtelung der Elemente und die Art des Inhalts
von Attributen festgelegt werden. Die Erstellung einer solchen DTD bietet sich im
vorliegenden Fall an, um Merkmale mit ihren Werten oder sogar Beziehungswissen zu
hinterlegen.
Zur Umsetzung hierzu kann beispielsweise das Batik Toolkit35 eingesetzt werden.
Dabei handelt sich es um eine frei verfügbare Java Bibliothek, die u.a. aus Java 2D
Funktionsaufrufen SVG Dokumente erzeugen kann.
,
33
http://www.uni-koeln.de/rrzk/software/archkomp/
http://www.w3.org/TR/SVG11/svgdtd.html
35
http://xmlgraphics.apache.org/batik/
34
30. November 2009
61
Zusammenfassung und Ausblick
62
6. Zusammenfassung und Ausblick
6.1. Zusammenfassung der Arbeit
Die Entwicklung eines zu hundert Prozent generischen grafischen Konfigurators
halte ich für weniger sinnvoll, da dies meines Erachtens mit einem erheblichen Aufwand
verbunden ist. Schon bei einer geringen Reduzierung der Generik sinkt der
Entwicklungsaufwand deutlich. Um dennoch eine größtmögliche Flexibilität zu
erreichen, sollten in jeder, der in 5.2 beschriebenen Hauptkomponenten, eine
Möglichkeit bestehen, eigenen Quellcode zu hinterlegen. Eine weitere Möglichkeit eine
hohe Flexibilität zu erreichen, besteht aus dem Gebrauch von Im- und Export von
Konfigurationsdateien wie es in 5.2.1 erläutert wurde. Auf diese Weise kann eine
exportierte Datei manuell verändert und diese im Anschluss importiert werden. Dies
ermöglicht beispielsweise das Hinterlegen von Funktionen, die nicht über die
Standardbenutzeroberfläche umgesetzt werden können aber sehr wohl vom
Konfigurationssystem verarbeitet werden können.
Im Gegensatz dazu halte ich es wichtig für Unternehmen, dass beim Einsatz eines
nicht grafischen Konfigurators dieser eine hundert prozentige Generik anstrebt um die
bereits erwähnten Nachteile wie
•
Abhängigkeit von externen Dienstleitern
•
Steigerung der Komplexität mit jeder Änderung des Beziehungswissens im
Quelltext
•
Preisgabe des Produktwissens an Dritte
zu umgehen.
30. November 2009
Aufgrund der fehlenden Literatur zu generischen grafischen Konfiguratoren wurden die
beiden verbreiterten Bereiche generischer bzw. grafischer Konfigurator zunächst separat
betrachtet um dadurch im Anschluss ein Konzept zur Verbindung der beiden Welten zu
entwickeln.
6.2. Ausblick auf mögliche Erweiterungen
Die ORBIS CS verfügt über eine Benutzeroberflächenmodellierung mit der UIElemente eingefügt und platziert werden können. Somit hätte die eigens erstellte GUI
mit dieser modelliert und eingebunden werden können.
Constraints wurden in dieser Implementierung mittels Java Klassen realisiert. Anstatt
diese selbst zu implementieren, hätte auch die frei erhältliche Java Bibliothek JaCoP36
eingesetzt werden können. Sie bietet neben der Überprüfung eines Modells auf
Widerspruchsfreiheit auch die Möglichkeit ein klassisches Suchproblem zu lösen.
Liegt die Präferenz auf dem Einsatz keiner Fremdbibliothek, so eignet sich zum
Aufbau einer Logik die Programmiersprache Prolog, welche mittels der JPL37 Bibliothek in
ein Java Projekt eingebunden werden kann.
Soll die Anwendung als Browser Applikation mit Fokus auf einer grafischansprechenden Benutzeroberfläche eingesetzt werden, könnte die Umsetzung mittels
des Adobe Flex38 Frameworks erfolgen. Es dient zum Erstellen von Rich Internet
Applications39 und besteht aus unterschiedlichen Komponenten wie dem Software
Development Kit, dem Flex Builder, dem LiveCycle Data Service und Flex Charting.
Adobe zielt darauf ab, mit Flex eine Plattform zu etablieren, die auch Softwareentwickler
und nicht nur Designer – wie es wie Adobe Flash der Fall war - anspricht. Bibliotheken
wie Degrafa40 für den 2D bzw. Away3d41 für den 3D Bereich bieten eine brauchbare
Grundlage zum Erstellen von grafischen Elementen.
36
http://jacop.osolpro.com/
http://www.swi-prolog.org/packages/jpl/java_api/index.html
38
http://www.adobe.com/de/products/flex/
39
Rich Internet Applications (RIAs) bieten eine funktionsreiche und ansprechende
Benutzerschnittstelle mit dem Ziel zu Kundenzufriedenheit und Produktivität zu erhöhen, wobei
die gesamte Anwendung in einem Web-Browser lauffähig ist.
40
http://www.degrafa.org/
41
http://away3d.com/
37
30. November 2009
63
Anhang
64
7. Anhang
7.1. Ausgewählte Quelltexte
Die Überprüfung, ob zu einem Zeichenobjekt alle notwendigen Werte zugeordnet
wurden, übernimmt die Methode performVariables(). Wenn erforderliche Werte nicht
gesetzt wurden, wird das jeweilige Objekt nicht dargestellt. Eine Besonderheit ist hier
das Haupttor selbst – erst wenn alle benötigten Werte dafür gesetzt wurden, können
alle übrigen Objekte gezeichnet werden.
private void performVariables() {
_instance.getDrawingArea().cleer();
if (_objList.get(0).allRequirementsAreSet(this)) {
updateDrawing(_objList.get(0).getObjNames().get(0));
for (int i = 1; i < _objList.size(); i++) {
LogicContainer lc = this._objList.get(i);
if(lc.allRequirementsAreSet(this))
updateDrawing(_objList.get(i).getObjNames().get(0));
}
}
}
Die Methode hasChildWithTypeOf überprüft ob der aktuelle (Teil-)Baum
Unterbäume mit Objekten des Typs type hat. Sie ist auch für generische Anwendungen
verwendbar, da der gewünschte Typ nur als String übergeben werden muss.
public boolean hasChildWithTypeOf(String type) {
if (this.hasChildren()) {
for (Tree tree : this.getChildren()) {
if (tree.getData().getClass().getName().endsWith(type))
return true;
}
} return false;
}
30. November 2009
Um ein Torgliedelement einzufügen wird der Konstruktor der Klasse
MainGateElement aufgerufen, der das gerade erstellte Objekt an die entsprechende
Position im Baum eingefügt. Jedes Zeichenobjekt muss somit einen Konstruktor mit
entsprechenden Anweisungen zur Platzierung des Objektes im Baum enthalten.
public MainGateElement(float xPos, float yPos, float
elem_height, String elemType) {
addObjectChangeListener(this);
setParent(Singleton.getInstance().getTree());
setXPos(xPos);
setYPos(yPos);
setXSize(getParent().getData().getXSize());
setYSize(elem_height);
setElemType(elemType);
setSurfaceType(getParent().getData().getSurfaceType());
getParent().addChild(new Tree(getParent(), this));
}
Zur Verwaltung von Variablen empfiehlt sich zunächst eine abstrakte Klasse zu
erstellen, die als Oberklasse zu allen Variablentypen fungiert und als Feld lediglich den
Variablennamen beinhaltet, der mit der Methode setVariable() gesetzt werden kann.
Sinnvoll ist es auch eine Methode zum Ermitteln des Typs zu implementieren, da
beispielsweise bei arithmetischen Operationen der Variablentyp bekannt sein muss.
public abstract class VariableContainer {
private String variable;
public
public
public
public
void setVariable(String var) {this.variable = var;}
String getVariable() {return variable;}
abstract Object getValue();
abstract Class<?> getType();
}
30. November 2009
65
Anhang
66
7.2. Screenshots
Die untenstehende Abbildung zeigt die ORBIS CS mit integriertem grafischen
Konfigurator während der Konfiguration eines Industriesektionaltores. Links oben sind
die Grunddaten des Tores zu finden, welche erst mit Werten versorgt werden müssen,
damit die grafische Konfiguration erfolgen kann. Unterhalb dessen befindet sich die
Baumdarstellung alle verwandten Komponenten mit den jeweiligen Preisen. Rechts des
Tores sind die Userinterfaceelemente zur Objektauswahl mit ihren Vorschaugrafiken
angeordnet.
Um ein Element in das Tor einzufügen, muss bei Fenstern zunächst das Zieltorglied
gewählt werden. In Anschluss muss in der jeweiligen Combo Box das passende Fenster
selektiert werden, woraufhin eine Vorschaugrafik des Fenster anzeigt wird. Durch Drag
& Drop der Vorschaugrafik wird das Fenster in das zuvor selektierte Torgliedelement
gesetzt.
Abbildung 25) Grafische Konfiguration eines Tores
Das Einfügen einer Tür verläuft analog zum Einfügen eines Fensters mit dem
Unterschied, dass kein Torgliedelement zuvor selektiert werden muss. Nach dem
Einfügen nimmt die Tür nur gültige Positionen, die abhängig von der Torbreite sein, ein.
Das Verschieben der Tür ist ebenfalls möglich.
30. November 2009
Während der Konfiguration laufen nach jeder Merkmaländerung, des Tores
Konsistenzprüfungen ab. Das Ergebnis dieser wird durch einen farbigen (rot/grün) Status
Button visualisiert um dem Benutzer jederzeit über die Gültigkeit seiner Aktionen zu
informieren.
Die Konfiguration kann hierbei nicht nur grafisch, sondern auch manuell erfolgen,
indem Merkmale einzeln bewertet werden. Dazu sind alle Merkmale des Tores
aufgeführt, deren Änderung sich unmittelbar auf die Grafik auswirkt.
Abbildung 26) Manuelle Konfiguration
Wird nun durch die manuelle Konfiguration ein ungültiger Wert für ein Merkmal
(z.B. eine Türbreite von 400mm) eingegeben,
Abbildung 27) Manuelle Fehlkonfiguration
30. November 2009
67
Anhang
68
so färbt sich die Statusleuchte rot und ein Button mit Fehlerdetails erscheint.
Abbildung 28) Visualisierung der Fehlkonfiguration
Beim Klicken auf den Button „Fehlerdetails“ öffnet sich ein Fenster mit den
genauen Informationen über den Fehler.
Abbildung 29) Fehlerdetails einer Konfiguration
30. November 2009
8. Abbildungsverzeichnis
Abbildung 1) Screenshot des grafischen Konfigurators ............................................... 11
Abbildung 2) Ikea Home Planner ............................................................................... 18
Abbildung 3) Depth-First Suchbaum .......................................................................... 24
Abbildung 4) Produktstruktur und parametrisiertes 3D-Modell ................................... 28
Abbildung 5) Autodesk Projekt Dragonfly .................................................................. 30
Abbildung 6) Vergleich der verwandten Arbeiten mit dem entwickelten Konzept ........ 31
Abbildung 7) Singleton Konstruktor........................................................................... 36
Abbildung 9) Beispiel eines Constraints...................................................................... 37
Abbildung 8) UML Diagramm der Klasse Singleton..................................................... 37
Abbildung 10) Model View Controller Pattern (31) ..................................................... 39
Abbildung 11) Vergleich von Map Implementierungen anhand ihrer Laufzeiten .......... 41
Abbildung 12) UML Klassendiagramm des Packages Constraint.................................. 43
Abbildung 13) Quelltext Beispiel einer require Relation ............................................... 44
Abbildung 14) Quelltext Beispiel einer Junction.NAND Relation .................................. 44
Abbildung 15) Die abstrakte Klasse DrawingObject mit ihren Unterklassen ................. 46
Abbildung 16) beispielhafte Baumdarstellung eines Tores........................................... 46
Abbildung 17) Post-Order Darstellung ....................................................................... 48
Abbildung 18) Pre-Order Darstellung ......................................................................... 48
30. November 2009
69
Abbildungsverzeichnis
70
Abbildung 19) Klassendiagramm des grafischen Konfigurators ................................... 49
Abbildung 20) Sequenzdiagramm einer Variablenänderung ....................................... 52
Abbildung 21) Übersicht generischer grafischer Konfigurator ..................................... 55
Abbildung 22) UND/ODER Baum ............................................................................... 56
Abbildung 23) Wissenspyramide................................................................................ 58
Abbildung 24) Verknüpfte Materialtabellen ............................................................... 60
Abbildung 25) Grafische Konfiguration eines Tores .................................................... 66
Abbildung 26) Manuelle Konfiguration ...................................................................... 67
Abbildung 27) Manuelle Fehlkonfiguration ................................................................ 67
Abbildung 28) Visualisierung der Fehlkonfiguration.................................................... 68
Abbildung 29) Fehlerdetails einer Konfiguration ......................................................... 68
30. November 2009
9. Literaturverzeichnis
1. Meier, Andreas V. und Cojocaru, Natalia. Konfigurierbare Materialien. Technische
Universität München : s.n., 2004.
2. Brinkop, Dr. Axel. Marktführer Produktkonfiguration. Oberschlettenbach : s.n.,
2009.
3. Research Issues in Knowledge-Based Configuration. Jannach, Dietmar, et al.
Hershey - New York : Information Science Reference, 2007. Mass Customization
Information Systems in Business. S. 221-236.
4. Visualization of Configurations: Simplifying Configuration User Interfaces. Dan
Heiderscheidt, Hans Jorgen Skovgaard. 1999. AAAI Technical Report WS-99-05. S.
114-118.
5. Wüpping, Dr.2Ing. Josef. Konfigurationstechnik für die individuelle Serienfertigung.
IT Management. 2000, April.
6. Piller, F. Kundenindividuelle Massenproduktion. München/Wien : Hanser Verlag,
1998.
7. Wüpping, Dr.2Ing. Josef. Logistikgerechte Produktstrukturen bei marktorientierter
Variantenvielfalt. io Management. 1998, 1/2.
8. Maßberg, W. Beherrschung der Komplexität in der Produktion. wt Werkstattechnik.
S. 349-354 : Springer-VDI-Verlag, 1997.
30. November 2009
71
<Literaturverzeichnis
72
9. Abramovici, Michael, et al. KoViP - Konfigurationssoftware und Dienstleistungen
für virtuelle Produkte. CAD-CAM-Report. 2006, 09.
10. The mechanisms of construction of generic product configuration with the help of
business object and delay differentiation. Izadpanah, S2H, Gzara, L und Tollenaere,
M. 3, Cranfield : Royaume-Uni, 2009, Bde. CIRP-Design.
11. Microsoft Corporation. The Windows Interface Guidelines for Software Design: An
Application Design Guide. s.l. : Microsoft Press, 1995.
12. VDI2Gesellschaft Entwicklung Konstruktion Vertrieb. Bürokommunikation;
Software-Ergonomie in der Bürokommunikation. 1990.
13. Nielsen Norman Group Report. Application Design Showcase: 10 Best App UIs.
s.l. : eSellerate, 2008.
14. Dhakar, Lokesh. Lightbox 2. [Online] September 2009.
http://www.huddletogether.com/projects/lightbox2/.
15. IDC Central Europe GmbH. Der IT Markt in Deutschland, 2008-2013 – Update 1.
Quartal 2009. Frankfurt : IDC Central Europe GmbH, 2009.
16. Landeshauptstadt München. LiMux Projekt. [Online] 2009.
http://www.muenchen.de/limux.
17. Schießl, Florian. LiMux und WollMux: Zwei Jahre freie Software in München.
München : s.n., 2008.
18. UNILOG Integrata. Client Studie der Landeshauptstadt München, Kurzfassung des
Abschlussberichtes. München : s.n., 2003.
19. SAP AG, Integration and Certification Centers. Integration Guide - Technologies.
s.l. : SAP Press, 2003.
20. Java World. Does JavaFX have a future at Oracle? [Online] 4. April 2009.
http://www.javaworld.com/community/node/2859.
30. November 2009
21. Thurstone, L.L. Fundamental Equations - Multiple-Factor Analysis. Chicago : The
University of Chicago Press, 1947.
22. Heiob, W. Einsatz dialogorientierter Entscheidungstabellentechnik in der Angebotsund Auftragsbearbeitung in Unternehmen mit auftragsgebundener Produktion.
Karlsruhe : Dissertation, TU Karlsruhe, 1982.
23. Die Konfigurations- & Verträglichkeitsmatrix als Beitrag zum Management von
Konfigurationswissen in KMU. Puls, Christoph. Karlsruhe : Dissertation an der ETH
Zürich, 2002.
24. National Instruments. Generic Configuration Editor (xCE) Reference Example.
Example Program. 2009.
25. Fuchs, Norbert E. Prolog Tutorial. Zürich : Institut für Informatik - Universität Zürich,
2003.
26. Rumage, Richard L. Generic Configuration Management - Explained. 2005.
27. Interactive Techniques to Support the Configuration of Complex Feature Models.
Goetz, Botterweck, Schneeweiss, Denny und Pleuss, Andreas. Ireland : Lero,
University of Limerick, 2009.
28. Günter, Andreas, Kreuz, Ingo und Kühn, Christian. Kommerzielle SoftwareWerkzeuge für die Konfigurierung von technischen Systemen. [Hrsg.] arenDTaP Verlag.
Künstliche Intelligenz,. 1999, 3, S. 61-65.
29. Abramovici, Michael, Ghoffrani, Mehdi und Neubach, Manuel.
Produktkonfiguratoren für die mittelständische Industrie. CAD-CAM Report. 2005, 4.
30. Abramovici, Michael, et al. A Generic Knowledge Base Pruduct Configuration
Software And Servies For Virtual Products. Bochum : Ruhr-Universität Bochum, 2006.
31. Sun Microsystems, Inc. Java BluePrints - Model-View-Controller. [Online] 2002.
http://java.sun.com/blueprints/patterns/MVC-detailed.html.
30. November 2009
73

Thesis - AIDA - Universität des Saarlandes

Transcription

Similar documents

Rechnerverbund NRW

windows 95 - Detlev Dalitz

Handbuch zur Dashboard- und Widget-Erstellung

Zahlungssysteme

Garagen-Sectionaltore

Seminarprogramm

HERMES

as a PDF

Falten im Leichtbau

digsi 5 - Siemens

Extbase extension programming

DSML`08 Domain-Specific Modeling Languages - CEUR