Praktikumsbericht Datum: Firma: Praktikumsmitglieder:

Transkript

1 Praktikumsbericht Datum: 09. April 2008 Firma: PRO-DIRECT-FINANCE Praktikumsmitglieder: David Backstein Dirk Neumann Katleen Thiele Sebastian Müller

2 Inhaltsverzeichnis Einleitung 4 Gruppenvorstellung 4 Firmenvorstellung 4 Projektvorstellung 5 Organisation 5 Aufgabenbereiche 5 Projektplanung und -management 6 Kommunikation 7 Recherche der Softwareprozesse 7 Extreme Programming (XP) 7 Test-Driven Development (TDD) 7 Verwendete Technologien 8 Werkzeuge 8 Hilfesystem: Prototyp CMS und Core 8 Datenhaltung 8 Web-Interface 8 Neuronale Netze 9 Einleitung 9 Theoretische Grundlagen 9 Einführung in das Prinzip von neuronalen Strukturen 9 Konzeption des Hilfesystems 10 Selbstorganisierende Karten 10 Hierarchische selbstorganisierende Karten 10 Anlernen von selbstorganisierenden Karten 11 Simplifizierte Prinzipserklärung einer selbstorganisierenden Karte 11 Begriffserklärungen 11 Erstellen einer HSOM Struktur aus Textdaten 12 Arbeitsweise des Hilfesystems, schematischer Überblick 17 Administration der HSOM Struktur 17 Anfrage stellen, Antwort holen 19 Smalltalk Modul 20 Designkonzept 21 Bedienbarkeit 21 2

3 Veränderbarkeit 22 Avatar 22 Form 22 Farbe 22 Sprechblase 22 Inhaltsfokussierung 23 Animation 23 Gesicht 23 CMS 24 Avatarverwaltung / Layoutverwaltung 25 Datenhaushalt / Offene Fragen 26 Blacklist / Wordbook 27 Technische Einstellungen / Usereinstellungen 28 Datenanpassung 29 Fazit aller Gruppenmitglieder 29 David Backstein 29 Dirk Neumann 30 Katleen Thiele 30 Sebastian Müller 31 Glossar 32 3

4 Einleitung Die Komplexität von Software und deren Funktionsumfang ist seit den 90 er Jahren beträchtlich gestiegen. Hohe Einarbeitungszeiten sind die Folge. Produktives Arbeiten wird vor allem in der Anfangszeit der Benutzung durch Funktionssuche und schlechte Hilfesysteme verhindert. Um die Akzeptanz der Software zu erhöhen und die Einarbeitung in diese zu erleichtern, erhalten Hilfesysteme einen immer wichtigeren Stellenwert. Der Anspruch an ein solches Hilfesystems ist dabei das Verstehen können verschiedener Problemstellungen eines Benutzers sowie das Heraussuchen und Anbieten der gesuchten Informationen. Dies setzt eine so genannte schwache KI voraus, eine Simulation intelligenten Verhaltens mit Mitteln der Mathematik und der Informatik, die sehr gut geeignet ist, konkrete Anwendungsprobleme und Fragestellungen zu analysieren und zu lösen. Solche Hilfesysteme werden intelligente oder kooperative Hilfesysteme genannt. Die Herausforderung große Informationsmengen zu bewältigen, ohne den Benutzer zu überfordern, hat uns dazu motiviert, das Thema intelligente Hilfesysteme zu behandeln. Gruppenvorstellung Seit 2005 studieren Katleen Thiele, David Backstein, Dirk Neumann und Sebastian Müller an der TFH Berlin Medieninformatik. Alle arbeiteten schon vor Praktikumsbeginn seit über einem Jahr bei der PRO-DIRECT- FINANCE. Aufgrund positiver Erfahrungen in der Firma und gemeinsamer Zusammenarbeit entstand der Entschluss zusammen bei der PRO-DIRECT-FINANCE unser Praktikum zu absolvieren. Firmenvorstellung Die PRO-DIRECT-FINANCE ist ein Softwareunternehmungen, das webbasierende Kernbankensoftware für namhafte Kreditinstitute, Versicherungen und Bausparkassen entwickelt und implementiert. Die Firma wurde 2005 gegründet, hat ihren Sitz in Berlin Treptower Park, und beschäftiginzwischen 60 Mitarbeiter aus den Bereichen Bankwesen und Informatik. Der Umgang der Mitarbeiter und der Führungskräfte untereinander ist bemerkenswert offen, und bietet somit für ein Praktikum sehr gute Bedingungen. Pro-Direct-Finance als ein junges Startup Unternehmen bot somit eine interessante und wirklichkeitsnahe Möglichkeit die Entwicklung und Realisierung eines Softwareprojektes zu bewältigen. 4

5 Projektvorstellung Ziel des Projektes CoBra war sowohl eine Machbarkeitsstudie, als auch die Realisierung eines Prototypen für ein anpassbares, intelligentes Hilfesystem für Softwarelösungen der PRO-DIRECT-FINANCE. Sie sollen dabei helfen den nötigen Einarbeitungsaufwand der Kunden in die Plattformen zu reduzieren, Begriffserklärungen und Hilfe bei häufig gestellten Fragen bieten, sowie ein interaktives Plattformhandbuch darstellen. Über ein seperates CMS können zusätzlich bisher nicht berücksichtigte Benutzerfragen beantwortet werden. Die Kompetenz des Hilfesystems wächst dadurch mit der Zeit, da durch die ansteigende Informationsdichte differenziertere Antworten gegeben werden können. Damit das Hilfesystem an Akzeptanz gewinnt, ist es nicht nur möglich Fachfragen zu stellen, sondern mit dem Avatar zu reden. Dadurch soll der Avatar den Eindruck erwecken als verstünde er den Nutzer. Diese Eigenschaft soll dabei helfen, das Hilfesystem zur ersten Anlaufstelle bei Fragen werden zu lassen. Organisation Aufgabenbereiche Unter Berücksichtigung der jeweiligen Vorlieben und Fähigkeiten wurden Kernkompetenzen erkannt, dementsprechend Aufgabenbereiche auf die einzelnen Mitlgieder verteilt und im Folgenden aufgeschlüsselt. Die Bereiche definieren vorwiegend die Verantwortlichkeit. Bei der Realisierung des Projektes war allzu oft bereichsübergreifende Arbeit notwendig, als dass die Bereiche strikt voneinander getrennt zu betrachten wären. David Backstein Projektleiter Implementierung der neuronalen Struktur (Backend) Dirk Neumann Moderator Implementierung des CMS (Frontend) Katleen Thiele Protokollführer Design des Avatars und der Benutzeroberflächen Implementierung des Webinterface (Frontend) Sebastian Müller Qualitätsmanager Implementierung der neuronalen Struktur (Backend) Datenbankimplementierung (Backend) 5

6 Projektplanung und -management Das im Studium kurz eingeführte MS-Project wurde am Anfang auch für das Praktikum zur Projektplanung und -verfolgung eingesetzt. In der Praxis stellte sich aber leider heraus, dass sich nicht die Arbeit nach dem Plan richtete, sondern der Plan nach der getanen Arbeit. Dadurch wurde der Plan wirkungslos und seine einziger Nutzen war, dass die aufgeschriebenen Aufgaben nicht vergessen wurden. Zum großen Teil wurde allerdings die Planung übergangen und nach eigenem Ermessen gearbeitet. MS-Project ist für mittlere bis größere Projekte sinnvoll. Für kleinere Projekte ist es schlichtweg zu klobig und in der Handhabe. Es musste schnell eine andere Projektplanungstechnik her, die für unerfahrene Teams und kleine Zeitperioden geeignet ist. Nach Gesprächen innerhalb des Teams und unserer Praktikumsbetreuerin, wählten wir bei der Planung Wochenweise vorzugehen. So war eine Woche eine Iteration im Projektprozess, nach der möglichst die ausgewählten ToDo s abgearbeitet sind und ein konsistenter Softwarestand hergestellt ist. Die Produktivität der Arbeit wurde durch den simplen Trick gesteigert, die komplette Wochenplanung für alle Teammitglieder gut sichtbar auf unsere Tafel zu schreiben. Dort sind Personen den Aufgaben zuzuweisen, den Aufwand festzulegen und letztlich die ToDo s abzuhaken. Die Planung und Aufgabenverfolgung war nun allgegenwärtig und einfach nachzuvollziehen. Dadurch wurde erreicht, dass die Arbeiten sich nun nach den definierten Aufgaben richteten und nicht andersherum. Hätten wir diese Technik ab der Hälfte des Praktikums nicht angewendet, wäre das Projekt möglicherweise sogar gescheitert, weil keine so zielgerichtete und zweckmäßige Entwicklung möglich gewesen wäre, wie es mit dieser Technik der Fall war. Abb 1) Tafel mit ToDo s in unserem Arbeitszimmer 6

7 Kommunikation Das Team verwaltete sich komplett selbst. So wurden Meetings mit Mitgliedern abgehalten, um fachliche Fragen zu klären, Fehlentscheidungen zu minimieren oder Wissenstransfer zu ermöglichen, ganz speziell bei der Schnittstelle zwischen Frontend und Backend. Jedes Mitglied konnte Meetings einberufen und war in seiner Mitsprache gleichberechtigt. Neben den internen Meetings wurde ein jour fix vereinbart, bei dem wöchentlich jeden Freitag ein Statusmeeting mit unserem Praktikumsbetreuer abgehalten wurde und der Stand und die Richtung, in die das Projekt läuft, beurteilt. Selbstverständlich wurde auch viel mit den regulären Mitarbeitern kommuniziert, um anwendbare Techniken zu ermitteln oder Fachwissen zu erlernen und auszutauschen. Recherche der Softwareprozesse Extreme Programming (XP) Agiles Projektmanagement wie das Extreme Programming, ist grundsätzlich positiv zu bewerten. Das Projekt ist nicht statisch, sondern entwickelt sich in einzelnen Iterationsschritten weiter. Nach jedem Iterationsschritt kann man schauen wo man steht und wo das Projekt hinführen soll. Dadurch entwickelt man nicht vom Ziel weg und kann Fehlentwicklungen zeitnah korrigieren. XP hat aber noch weitere Merkmale. Das Wissen über die einzelnen Projektbestandteile liegt optimalerweise bei allen Teammitgliedern. Es gibt also kein Expertentum und Wissensmonopol. Dies konnten wir so nicht umsetzen. Die Zeit, die verbraucht wird, damit jeder im Team die Details eines neuronalen Netzes versteht, ist für diese kurze Projektdauer einfach zu viel. Letztendlich haben wir ein weiches XP als Vorgehensweise genommen. Wir haben teilweise Pair-Programming durchgeführt, bei dem zwei Leute vor einem Rechner sitzen und programmieren. Wir haben in wöchentlichen Iterationen gearbeitet und spontane Meetings einberufen, um Dinge abzustimmen, zu bewerten und Wissenstransfer zu ermöglichen. Jeder sollte Einblick in die Arbeitsweise der anderen Gebiete erhalten. Dies ist uns in einem begrenzten Maße auch gelungen. Leider lässt es sich hierbei nicht vermeiden, dass Kernkompetenzen entstehen. Test-Driven Development (TDD) Ursprünglich wollten wir TDD als Vorgehensweise bei der Softwareentwicklung benutzen, da gerade ein neuronales Netz vieler Tests bedarf, um die korrekte Arbeitsweise sicherzustellen. Es stellten sich jedoch zwei entscheidende Faktoren dagegen: Test Driven Development ist eine komplett andere Entwicklungsweise als das im Studium erlernte Vorgehen. Die Planung in UML wird bei TDD vernachlässigt, da die Architektur des Programmes mit den Anforderungen-also den definierten Tests- wächst und daraus entsteht. Dieses Umdenken erfordert sehr viel Zeit. Ein Faktor, den wir im Praktikum nicht im Überfluss hatten. Deswegen blieben wir bei der klassischen Planungsart. 7

8 Verwendete Technologien Nach ausgibiger Technologierecherche in den ersten beiden Projektwochen, Besprechungen in Meetings und Berücksichtigung der Richtinien Seitens der PRO-DIRECT-FINANCE wurde sich für die folgenden Technologien entschieden: Werkzeuge Eclipse 3.3 IDE Netbeans 6 IDE CVS zur Versionierung des Projektes MS Project zur Planerstellung ANT zur Projektautomatisierung Tomcat 6 Webserver DIA UML Editor Hilfesystem: Prototyp CMS und Core Java Swing / AWT JDBC Datenhaltung MySQL Datenbank Web-Interface Java Script HTML CSS JSP 8

9 Neuronale Netze Einleitung Im folgenden Abschnitt über neuronale Netze werden die Grundlagen und Prinzipien einer neuronalen Datenstruktur dargelegen um die Arbeitsweise des Hilfesystem-Prototypen unserer Gruppe Grundlegend verstehen zu können. Da die Ausarbeitung einen Überblick über über die genutzen Prinzipien geben soll, beschränkt se sich auf die Erklärung der Vorgänge, ohne auf die mathematischen Details einzugehen. Es soll ein leicht verständlicher und schneller Einblick gegeben werden wie die Anwendung funktioniert. Durch dieses Verständnis wird ein effektiver Umgang mit dem Prototypen möglich und der Grundstein für eine intensivere Auseinandersetzung mit dem Quellcode der Anwendung gelegt. Es folgen einige theoretische Grundlagen zu neuronalen Strukturen, darin werden einige Begriffe und Prinzipen aus dem Umfeld von neuonalen Strukturen erklärt. Nachfolgend werden die im Prototypen verwendeten Algorithmen der selbstorganisierenden Karten und die Abfrage von Informationen in einer simplifizierten grafischen Form dargelegt. Theoretische Grundlagen Einführung in das Prinzip von neuronalen Strukturen Neuronale Strukturen bezeichnet zunächst die Struktur und Informationsarchitektur von Gehirn und Nervensystem bei Tieren und Menschen. Informationsträger ist in einer neuronalen Struktur das Neuron, die Struktur bildet sich dann durch Verknüpfungen dieser Neuronen. Zwischen den Neuronen finden auf chemischen und elektrischen Weg ein Informationsaustausch statt. Dieses biologische Prinzip der Informationshaltung hat einen sehr interessante Eigenschaft. Verschiedene semantisch gleichartige Reize der Sinnesorgane stimulieren im Gehirn örtlich nahe beieinanderliegene Neuronen. Es werden also multidimensionale Reize von Augen, Gehör etc. auf einer dreidimensionalen Gehirnstruktur so abgebildet, das ähnliche Informationen im Gehirn an der gleichen Stelle landen. Kurz gesagt: semantisch ähnliche Informationen werden räumlich nahe beieinander abgelegt. Dieses Verhalten nennt man inhaltsgebundene Datenhaltung. 9

10 Diese Eigenschaft ermöglicht es, dass Menschen und Tiere auf Situationen reagieren können, auch wenn ihnen diese unbekannt sind. Ein Sinneseindruck (Reiz) stimuliert eine semantisch ähnliche Region des Gehirns, somit findet sich fast immer eine Idee, an die Situation heranzugehen. Computer sind wiederum nur in der Lage, auf Problemstellungen zu reagieren, auf die sie schon vorher eine Lösung kennen. In der Informatik ist das Prinzip der neuronalen Informationsarchitekur deswegen sehr interessant, da eine gewisse Ungenauigkeit in der Problemstellung trotzdem zu einem sinnvollen Ergebnis gebracht werden kann. Hier liegen auch die Gründe für die Entscheidung, neuronale Strukturen als Datenstruktur des Hilfesystems zu erproben. Ein anderer Nutzen ist die selbstständige semantische Strukturierung der Informationen, was das Einpflegen neuer Informationen in das System sehr einfach macht. Konzeption des Hilfesystems Zwei grundlegende Anforderungen waren Grundlage der Konzeption des Hilfesystems für Web-Anwendungen: Zum einen das Finden von semantisch naheliegenden Informationen auf eine Frage eines Benutzers, wozu selbstorganisierende Karten benutzt wurden, zum anderen muss es eine unkomplizierte Möglichkeit geben, das System zu administrieren. Nach einiger Zeit der Recherche von tauglichen Technologien und Herangehensweisen haben wir uns entschlossen, eine neuronale Struktur zu verwenden. Selbstorganisierende Karten Die zu verarbeitenden Informationen sind eine Anzahl von kleineren Texten. Diese werden auf die Neuronen von sogenannten selbstorganisierende Karten oder Kohonenkarten (engl. SOM, Self-Organizing Map) abgebildet, die diese Texte inhaltsgebunden auf einer 2D-Karte semantisch verteilt anbieten. Durch einen Algorithmus wird für jeden Text eine Signatur erstellt. Diese Signatur repräsentiert eine Ortsangabe in einem vieldimensionalem Raum. Die Daten liegen nun schon inhaltsgebunden in diesem vieldimensionalem Raum nach semantischer Bedeutung zusammen sortiert. Wird nun eine Anfrage in Form eines formulierten Satzes gestellt, wird dieser ebenfalls in eine multidimensionale Ortsangabe übersetzt. Eine Anfrage nennen wir nun Reiz, dieser Reiz enthält wie ein Neuron auch eine Signatur. Durch eine Abstandsfunktion kann nun nach den örtlich naheliegenden Neuronen des Reizes gesucht werden. Das Ergebnis ist eine nach semantischer Relevanz geordnete Liste von möglichen Antworten. Diese semantische Relevanz eines Neurons zu einem Reiz liegt praktisch als eine Fließkommazahl zwischen 0 und 1 vor, wobei 1 semantisch übereinstimmend bedeuten würde. Somit ist es nicht nur möglich eine oder mehrere gute Antwort auf eine Frage zu finden, sondern es steht auch eine Information über die semantische Relevanz einer Antwort zur Verfügung. Hierarchische selbstorganisierende Karten Das Benutzen einer selbstorganisierenden Karte allein löst zwar das Problem eine passende Antwort auf eine Frage zu finden, macht aber das Pflegen der Daten sehr unübersichtlich. Alle Neuronen liegen momentan noch als eine Liste vor, was das Administrieren des Datenbestandes mit steigender Anzahl der Daten sehr schwer macht. Einen visuellen Eindruck über die inhaltsgebundene Strukturierung erhält man erst durch das Erstellen einer hierarchischen selbstorganisierenden Karte (engl. HSOM, Hierarchical Self-Organizing Map). Die Informationen werden in einer Baumstruktur von Neuronen-Layern sortiert. Mit einer solchen Struktur wird es möglich, einen Überblick über die semantische Sortierung der Daten zu gewinnen und diese dann auch administrieren zu können. 10

11 Anlernen von selbstorganisierenden Karten Die Qualität einer selbstorganisierenden Karte hängt in der praktischen Anwendung vom Algorithmus, der sie angelernt hat, ab. Damit ist gemeint, das die Datenstruktur einer selbstorganisierenden Karte nur dann einen Vorteil bringt, wenn die Daten auch wirklich semantisch zusammengehörend an örtlich gleichen Plätzen liegen. Das bedeutet also, das multidimensionale Reize auf eine zweidimensionale Karte abgebildet werden, und zwar so, das diese auch auf der 2D Karte inhaltsgebunden zusammen liegen. Die Qualität des Anlernens entscheidet letztendlich auch über die Qualität und den Nutzen, die eine selbstorganisierende Karte in der praktischen Anwendung bietet. Da wir nicht nur eine zweidimensionale SOM benutzen, sondern einer HSOM-Struktur mit mehreren SOM-Layern, die in einer Baumstruktur zueinander stehen, wird der Vorgang des Anlernens mehrmals ausgeführt. Da die HSOM eine Baumstruktur von SOMs ist, wird jede SOM der Baumstruktur mit dem gleichen Prinzip angelernt. Nach jedem Anlernen einer SOM wird nach Orten gesucht, an denen zu viele Neuronen an einem Ort gesammelt sind. Diese werden dann auf einem neuen Neuronen-Layer (einer SOM) gebracht und angelernt, und im alten Neuronen-Layer von einem virtuellen Neuron repräsentiert. Das Prinzip des Anlernens wir im folgenden Abschnitt ausführlicher beschrieben, für den Moment soll es genügen, die Wichtigkeit des Anlernvorganges zu verstehen. Simplifizierte Prinzipserklärung einer selbstorganisierenden Karte Begriffserklärungen Um die nachfolgenden Prinzipserklärungen verstehen zu können sind zuerst einige Begriffe zu klären. Dass ein Neuron die kleinste Einheit einer selbstorganisierenden Karte (auch SOM oder Neuron-Layer genannt) ist, wurde ja schon erwähnt. Was noch nicht erwähnt wurde, ist die Tatsache, das es verschiedene Neuronenarten gibt. Kartenneuron Ein Kartenneuron repäsentiert einen Platz auf einer SOM. Ein Kartenneuron selbst enthält noch keine Informationen und ist für die Erstellung und die Strukturierung der Daten in einer HSOM Struktur wichtig. 11

12 Ein Reizneuron ist eine Anfrage, die in ein Neuron mit Signatur verwandelt wurde. Ein Reiz ist also ein Neuron mit Ortsangabe. Reizneuronen / Reiz Kartenneuron mit Reizen Im Laufe des Anlernvorgangs werden Kartenneuronen mit Reizen (oder Reizneuronen) besetzt. Liegt mehr als ein Reiz auf einem Kartenneuron, wird aus dem Kartenneuron eine neue SOM generiert. Liegt auf einer SOM ein Kartenneuron mit genau einem Reiz, wird dieses Neuron zu einem finalen Neuron umgewandelt. Dieser Typ repräsentiert eine Information mit Ortsangabe, an den wir Anfragen richten können, und der seine feste Position in der HSOM gefunden hat. Finale Neuronen Erstellen einer HSOM Struktur aus Textdaten Im folgenden Fall sollen exemplarisch acht Textinformationen in eine HSOM Struktur gebracht werden. In der Ausgangssituation werden alle Informationen, die gespeichert werden sollen, in Reize verwandelt, und auf ein Kartenneuron gelegt. Der Algorithmus erkennt eine zu große Verdichtung von Informationen an einem Ort, und erstellt eine neue SubSOM. Kartenneuron mit 8 Reizen 12

13 Je nach Konfigurationseinstellungen wird nun eine neue SOM erstellt. In unserem Fall gehen wir davon aus, das eine neue SubSOM mit den Dimensionen 2x2 Neuronen erstellt wird. Es werden per Zufall Kartenneuronen erstellt und auf die Karte gelegt, so dass jeder Knotenpunkt ein Kartenneuron enthält. Eine Sub Som wird erstellt Das Anlernen startet. Praktisch bedeutet das, die Reize werden je nach semantischer Zusammengehörigkeit auf die Kartenneuronen der ersten SubSOM gelegt. Dabei entstehen zum Teil auch wieder Verdichtungen, da zwei Kartenneuronen noch mehr als einen Reiz enthalten. Reize werden auf neuer Sub Som angelernt Nach Beendigung des Anlernens dieser SubSOM werden alle Kartenneuronen mit genau einem Reiz zu finalen Neuronen umgewandelt. In diesem Schritt erhält das Kartenneuron eine feste Signatur, die Information dies es tragen soll, und seine feste Position in der HSOM-Struktur. Finale Neuronen erzeugen 13

14 Die beiden Verdichtungen werden wieder durch das Erstellen weiterer SubSOMs gelöst. Es entstehen also aus den beiden überladenen Kartenneuronen zwei neue SOMs mit jeweils drei Reizen. Neue Sub SOM s erstellen Die beiden neuen SubSOMs werden mit den drei Reizen angelernt und finden so ihre Position auf der jeweiligen SOM. Reize auf Sub SOM s verteilen Nach diesem Schritt existiert kein Kartenneuron mit mehr als einem Reiz. Alle mit einem Reiz belegten Kartenneuronen werden zu finalen Neuronen. Kartenneuronen ohne Reiz bleiben als eine Art blinde Strukturneuronen in der HSOM-Struktur zurück. Das Erstellen der HSOM-Struktur aus acht Textinformationen ist nun fertig, wir haben einen Baum mir der Tiefe 2 als Ergebnis. Finale Neuronen erzeugen 14

15 Eine Abfrage liegt im Hilfesystem in Form eines Satzes vor. Hier soll nun gezeigt werden, wie eine Abfrage mit einem solchen Satz zu einer möglichst passenden Antwort kommt. Anfrage Zuerst wird die Eingabe durch einen Algorithmus in eine Signatur, also einer Ortsangabe im multidimensionalen Raum, umgewandelt. Signatur der Anfrage berechnen Es entsteht ein Reizneuron, das wir nun in unsere SOM geben können. Als Beispiel nehmen wir nun eine fertig angelernte SOM Struktur aus 9 finalen Neuronen. Wird der Reiz auf die SOM Struktur angewendet, wird die Anfrage zu einer Ortsangabe auf der SOM. Reiz an SOM geben Diese Ortsanganbe auf der SOM sei nun durch die Linie nach unten dargestellt. Wir haben nun eine Position auf dem Layer, und vier umliegende mögliche Kandidaten für eine Anwort. Über Winkelfunktionen wird das nächste Neuron ermittelt. Örtlich näheste Neuronen finden 15

16 Durch dieses Vorgehen gibt es immer ein Gewinnerneuron, das die vermeintlich beste Anwort auf die Frage darstellt. Um die positiven Eigenschaften der SOM Struktur zu nutzen suchen wir aber auch noch nach möglichst guten alternativen Antworten, die dem User angeboten werden sollen. Gewinnerneuron bestimmen Vom Gewinnerneuron aus ist es nicht schwer, die nächsten umliegenden Informationen zu identifizieren, und diese dann ebenfalls dem User zur Verfügung zu stellen. In diesem Beispiel haben wir eine Antwort, und suchen nun noch drei alternative Anworten. Die Abfrage ist damit erledigt, als Ergebnis haben wir vier finale Neuronen, und für jedes Neuron einen Wert 0 bis 1, der die semantische Relevanz der Antwort zu der Frage ausdrückt. Alternative Antworten suchen Unbekannte Information gesucht Ein weiterer Fall, der auftreten kann, ist, wenn eine Anfrage ohne semantischen Zusammenhang zu den Daten, die in der Struktur gehalten werden, gestellt wird. Wenn also die Frage mit den Antworten überhaupt nichts zu tun hat. Auch in diesem Fall werden wir eine beste Antwort erhalten. Aber durch die semantische Relevanz sind wir in der Lage zu erkennen, das es eine sehr schlechte Antwort auf die gestellte Frage ist. In diesem Fall schalten wir die Abfrage an die HSOM aus, und schalten einen A.L.I.C.E-Chatbot ein, weil davon auszugehen ist, das der Benutzer keine ernste Frage stellt. Solche Fragen werden für spätere Beantwortung gesammelt. 16

17 Arbeitsweise des Hilfesystems, schematischer Überblick Nach der Erklärung der Prinzipien beim Erstellen der Struktur und dem Abfragen der HSOM erklärt dieser Abschnitt die Aufgabentrennung der Softwar- Module des Hilfesystems. Grundlegend gibt es vier Module, die in Zusammenarbeit das Hilfesystem darstellen. Die Anwendung ist geteilt in ein CMS (Content Managment System) zum Administrieren des Hilfesystems und der HSOM-Erstellung, ein Webinterface das die Abfragen an das System entgegennimmt, einem Core-Modul, das für alle Berechnungen und Abfragen zuständig ist und einer Datenhaltung in einer Datenbank, die alle Informationen des Hilfesystems hält. Im folgenden Abschnitt wird erklärt, welche Module an den beiden Arbeitsschritten (die Administration und das Stellen von Abfragen an die HSOM Struktur) beteiligt sind. Administration der HSOM Struktur An der Administration der HSOM-Struktur sind die Module CMS, Core und Datenbank beteiligt. Zuerst werden wird per CMS die Rohdaten der Datenbank aktualisiert. Administration der Rohdaten Beim Starten des CMS-Moduls werden die vorhanden Rohdaten aus der Datenbank geholt. Nun verwaltet der Administrator die Inhalte und Einstellungen des Systems. Das meint zum Beispiel das Erstellen neuer Neuronen und somit das Eingeben neuer Daten in das System. Alle gemachten Einstellungen und die Informationen in Form von Neuronen werden beim Speichern wieder in die Rohdaten der Datenbank abgelegt. 17

18 Wenn die Rohdaten wie gewünscht verändert wurden, muss die HSOM-Struktur komplett neu berechnet werden. Wegen dieses Umstandes werden die im CMS gemachten Änderungen zwar beim Editieren gleich in der Rohdatenbank gespeichert, aber erst nachdem alle Arbeiten erledigt sind werden die Informationen neu berechnet. Das Neuberechnen der Struktur wird durch den Änderungen übernehmen - Button angestoßen. Nach dem Klicken des Änderungen übernehmen Buttons wird folgender Ablauf angestoßen: Neuberechnung der HSOM Struktur Durch Klicken des Änderungen übernehmen -Buttons gibt das CMS dem Core-Modul die Anweisung, die Struktur neu aufzubauen. Der Core liest die Rohdaten aus der Datenbank. Die HSOM-Struktur wird neu erstellt und angelernt. Dieser Prozess kann sehr zeitintensiv werden. Einfluss auf die Dauer hat man durch das Ändern der Anzahl der Lernschritte im CMS. Nach dem Berechnen der HSOM-Struktur wird diese für die Datenbank zum Speichern aufbereitet, und in der Tabelle hsomdata gespeichert (fertige HSOM). Nach diesen Schritten liegt ein hierarchisch strukturierter Datensatz vor, der im CMS als Baum angesehen oder per Web-Interface abgefr agt werden kann. Somit ist es möglich Datensätze auf einem lokalen PC zu Administrieren und zu berechnen. Auf dem Server, der die Anwendung hostet und die Möglichkeit bietet Abfragen zu stellen, wird dann ein SQL Dump dieser berechneten Daten eingespielt. 18

19 Durch dieses Vorgehen wird der Abfragebetrieb auf dem Server nicht gestört, und somit auch ein wartungsbedingter Funktionsausfall der Anwendung vermieden. Anfrage stellen, Antwort holen Um eine Anfrage an das System zu stellen sind die Module der Datenbank, der Core und das Webinterface notwendig. Der Server, auf dem die Anwendung im Abfragebetrieb läuft, benötigt nur den Teil der fertigen HSOM-Datenbank, um arbeiten zu können. Im Detail ist das die Tabelle hsomdata der Datenbanktabellen. Die Rohdaten sind nicht notwendig. Anfrage wird gestellt Der Benutzer gibt eine Frage über das Webinterface ein. Das Webinterface richtet eine Anfrage an das Core-Modul, und wartet auf die Antwort. Das Core-Modul generiert nun aus der Anfrage einen Reiz, der zur Abfrage an die SOM Struktur geschickt wird. Ein Reiz enthält, wie auch Neuronen, eine Signatur, die einer Ortsangabe im multidimensionalen Raum einer SOM Karte entspricht. Es werden dann, der inhaltsgebundenen Datenstruktur entsprechend, die örtlich nähesten Neuronen zu diesem Reiz gesucht. Die nächste Grafik zeigt die interaktion unter den Modulen bei einer Abfrage an das System. 19

20 Antwort suchen und ausgeben Das Core-Modul holt sich die HSOM-Struktur von der Datenbank und rekonstruiert sie. Es wird ein Reiz aus der Frage erstellt, und damit eine Abfrage an die HSOM-Struktur gestellt. Die Antwort und maximal drei alternative Antworten werden zusammengestellt. Das Core-Modul gibt die Anfrage beantwortet an das Webinterface zurück. Das Webinterface präsentiert dem Benutzer die Antwort und ist für die nächste Anfrage bereit. Smalltalk Modul Das Hilfesystem ist nur so leistungsstark und präzise wie es Anzahl an Daten enthält. Wenn wenige Neuronen- also Frage-Antwort Paare- gespeichert sind, so kann das neuronale Netz nur unzureichend relevante Antworten auf Benutzerfragen liefern. Aber auch bei einem riesigen Datenbestand kann dies passieren, wenn die eingegebene Frage eine komplett themenfremde, eine Dialogfrage an den Avatar oder einfach nur eine Bemerkung ist. Damit in dieser Situation das System nicht seine Begrenztheit preisgibt und dem Benutzer bei Fragen zum Avatar wie z.b. Wie geht es dir? etwas zu antworten weiß, haben wir ein AIML Modul eingegliedert, dass in solchen Fällen antwortet. AIML ist eine Beschreibungssprache auf XML Basis, die natürliche Sprachdialoge in Softwaresystemen definiert. Das Resultat sind Chatbots, die je nach Programmierung auf bestimmte Fragen Antworten geben können, dem Benutzer Fragen stellen und sogar einen Dialog mehrere Sätze aufbauen können. Der von uns verwendete Chatbot ist der preisgekrönte A.L.I.C.E. (Artificial Linguistic Internet Computer Entity). Fällt die Relevanz der gefundenen Antwort aus dem neuronalen Netz unter einen definierten Grenzwert, wird die Benutzerfrage an den Chatbot weitergeleitet und dessen Antwort ausgegeben. 20

21 Designkonzept Ziel des Designkonzeptes war es eine Oberfläche zu bieten, die leicht zu bedienen und anpassbar ist. Dabei sollte den Richtlinien der Banken entsprechend das Hilfesystem nicht vom wesentlichen Inhalt des jeweiligen Banken-Systems ablenken. Dem jeweiligen Kunden sollte ausserdem die Möglichkeit zur Verfügung stehen, das System leicht in vorhandene Anwendungen und Designkonzepte zu integrieren. Bedienbarkeit Vom Entwurf zur Umsetzung Das System soll ohne spezielle Kenntnisse nutzbar sein. Das Webinterface ist aus diesem Grund sehr einfach und minimalistisch gestaltet, um den Nutzer schnell und einfach zu einer passenden Antwort zu führen. Benötigt der Benutzer in einer Plattformanwendung Hilfe, öffnet er das Hilfesystem durch das Anklicken des Avatarsymbols. Dabei wird das Hilfesystem gestartet und das Web-Interface steht als PopUp Fenster für Abfragen zur Verfügung. Avatarsymbol PopUp Fenster mit Avatar und Sprechblase 21

22 Über das Eingabefeld werden Anfragen an das System eingegeben. Gibt es für eine Anfrage mehrere gute Antworten, werden diese dem Benutzer als Links zum Anklicken, als Alternativen zur normalen Antwort angeboten. Veränderbarkeit Avatar Die Oberfläche des Hilfesystems ist in Avatar- und Sprechblase geteilt. Über das CMS hat der Benutzer die Möglichkeit die Farbe und das Aussehen des Avatars zu verändern, sowie die Farben der Sprechblase und des Fensters einzustellen. Das CMS bietet die Möglichkeit einen individuellen Avatar aus einigen Vorlagen zu erstellen und diese farblich anzupassen. Veränderungen sind im Haar-, Körper- und Dressbereich möglich, jeweils sowohl in der Form des Avatars als auch in der Farbgestaltung. Verschiedene Avatarvorlagen, die zur Auswahl stehen Form Farbe Der Avatar besteht aus den folgenden dre Ebenen: Body-, Hair- und Dressebene. Für jede der drei Ebenen stehen einige Vorlagen zur Auswahl, die der Kunden nach den eigenen Bedürfnissen zusammenstellen kann. Es stehen sowohl weibliche, als auch männliche Vorlagen zur Verfügung und es können eigene Vorlagen erstellt und eingebunden werden. Eigene Avatarvorlagen können bequem über das CMS eingebunden werden. Jede Ebene kann farblich frei verändert werden. Dabei stehen ein Farbwähler zur Verfügung, der eine Anzahl von Farben zu Auswahl bietet und die Eingabe eigener Farbwerte im Hex Format ermöglicht. Sprechblase Die Sprechblase als Ausgabefenster für Antworttexte ist ebenfalls über das CMS farblich frei gestaltbar. Es können die Sprechblase, ihr Rahmen und der Text farblich angepasst werden. 22

23 PopUp Fenster mit Avatar und Sprechblase im Userdialog Inhaltsfokussierung Bei der Gestaltung des Hilfesystems stand der zu transportierende Inhalt im Mittelpunkt. Den Anforderung einer Bank entsprechend wurde bewusst auf ein zu aufdringliches Design verzichtet. Animation Gesicht Informationen sollen schnell und effektiv von Benutzer abgreifbar sein. Dabei stellte sich uns die Frage nach einer animierten Avatar-Figur für das Hilfesystem. In den Richtlinen für Bankanwendungen ist weder JavaScript noch Flash erlaubt, was wichtige Technologien für Animation im Webbereich sind. Den Konventionen einer Bankanwendung entsprechend wurde deshalb bewusst auf eine animierte Figur verzichtet, und eine statische Variante erstellt. Die Züge des Gesichtes wurden aus zwei Gründen weg gelassen. Zum einen weil sich viele Menschen von Augen beobachtet fühlen und selbst immer wieder das Objekt der Beobachtung aufsuchen. Zum anderen weil Gesichtszüge bei diesen kleinen Ausmaßen des Avatars überladen wirken würden. 23

24 CMS Um alle Daten des Hilfesystems einfach und unproblematisch verwalten zu können, wurde ein eigenes Content-Management-System (CMS) entwickelt. Mit diesem haben auch Nicht-IT-Spezialisten die Möglichkeit, alle Inhalte des Hilfesystems zu verwalten und an neue Gegebenheiten anzupassen. Bei der Realisierung wurde besonderer Wert auf eine einfache und intuitive Benutzerführung gelegt. Folgende Bereiche lassen sich mit dem CMS verwalten: Avatar Layout Datenhaushalt Offene Fragen Blacklist / Wordbook Technische Einstellungen Usereinstellungen Die einzelnen Aufgaben des CMS werden in den nachfolgenden Abschnitten nun genauer erklärt. 24

25 Avatarverwaltung / Layoutverwaltung Im Tab Avatar / Layout hat der Nutzer die Möglichkeit Farb- und Layoutanpassungen für verschiedene Plattformen vorzunehmen und individuell zu speichern. Folgende Einstellungen kann der Nutzer vornehmen: Avatar: Tab: Avatareinstellungen Farbe: Body, Hair, Dress Design: Body, Hair, Dress Eigene Benutzerfarbe Individuelles Speichern und Laden eines Avatars Layout Farbe: Hintergund, Sprechblase, Schriftfarbe Design: Menüicons Individuelles Speichern und Laden von Layouts 25

26 Datenhaushalt / Offene Fragen Im Tab Datenhaushalt / Offene Fragen hat der Nutzer die Möglichkeit die Kernfunktionalität des Hilfesystems zu verwalten. Dies bedeutet konkret, das der Nutzer hie sämtliche Fragen des Systems (mit Ausnahme der Fragen für den A.L.I.C.E. - Chatbot) individuell anpassen kann. Des Weiteren hat der Nutzer die Einsicht auf Fragen, die gestellt wurden, abe noch nicht beantwortet werden konnten, das heißt die gefundenen Antworten unter der definierten Mindestrelevanz liegen. Auch diese Fragen können einfach verwaltet werden. Folgende Einstellungen kann der Nutzer vornehmen: Datenhaushalt: Tab: Datenhaushalt Darstellung: Baumstruktur / Liste Frage / Antwort / Schlagwörter: Suchen, Hinzufügen, Editieren, Löschen Offene Fragen: Offene Frage: Beantworten, Löschen 26

27 Blacklist / Wordbook Tab: Blacklist / Wordbook Im Tab Blacklist / Wordbook hat der Nutzer die Möglichkeit so genannte Blackwörter zu verwalten. Solche Blackwörter sind Wörter, die bei einer Frageeingabe automatisch rausgefiltert, also vom System ignoriert werden sollen. Zudem kann der Nutzer sich eine Tabellarische Übersicht über alle aus den eingegebenen Fragen resultierten Wörtern anschauen, die für eine Antwortfindung relevant sind. Es gilt die Regel, je kleiner das Wörterbuch, desto schneller der Lernprozes. Deshalb werden Wörter ohne inhaltliche Bedeutung in die Blacklist eingetragen, damit sie aus dem Wörterbuch gekürzt werden. Das betrifft vor allem Artikel und Pronomen. Werden allerdings Wörter mit inhaltlicher Bedeutung in die Blacklist eingefügt- beispielsweise das Wort Flugzeug - so kann das System eine Frage nach mit diesem Wort nicht mehr ordnungsgemäß beantworten- obwohl es möglicherweise eine passende Antwort hätte. Es kann nur Wörter, die im Wörterbuch stehen, verarbeiten. Folgende Einstellungen kann der Nutzer vornehmen: Blacklist: Blackwort: Suchen / Hinzufügen / Löschen Limit: Upper / Lowerlimit ( ) 27

28 Technische Einstellungen / Usereinstellungen Tab: Usereinstellungen Im Tab Technische Einstellungen / Usereinstellungen hat der Nutzer die Möglichkeit sämtliche Parameter für die Berechnung der Neuronalen Struktur zu verändern. Des Weiteren kann der Nutzer Änderungen an der Datenbank vornehmen und Ordner für externe Avatarvorlagen auswählen. Folgende Einstellungen kann der Nutzer vornehmen: Technische Einstellungen: Dies sind Parameter, die die Generierung der HSOM steuern. So kann das Verhältnis zwischen Breitenund Tiefenwachstum eingestellt werden, die Anzahl der Lernschritte definiert werden und der Lernradius eines Neurons sowie dessen Vermögen über die Zeit zu lernen festgelegt werden. Usereinstellungen Datenbank: Leeren / Testdatensatz erzeugen Ordner (Vorlagen): Body, Hair, Dress Ordner (Vorschau): Body, Hair, Dress Ordner: Avatarbilder 28