Entwicklung einer Rich Client basierten GUI f ur Experten ...Basierend auf der JBoss Drools Regelmaschine wurde ein System gescha en, das es erlaubt die wichtigen Informationen und

Entwicklung einer Rich Client basierten GUIfur Experten Systeme

Abschlussarbeit zur Erlangung des akademischen GradesBachelor of Science

vorgelegt imStudiengang Angewandte Informatik

des Fachbereiches Eletrotechnik und Informatikder Fachhochschule Munster

vonDennis Huning

Prufer: Prof. Dr. rer. nat. Nikolaus WulffBetreuer: Dipl. Physiker Tobias Henß

Munster, 29. August 2008

Zusammenfassung

Diese Arbeit behandelt das Thema der Programmierung einer grafischen Benutzerober-flache fur ein regelbasiertes Diagnosesystem das im wissenschaftlichen Umfeld eingesetztwird.Basierend auf der JBoss Drools Regelmaschine wurde ein System geschaffen, das eserlaubt die wichtigen Informationen und das Wissen eines regelbasierten Diagnosesys-tems fur Anwender abstrahiert und verstandlich in einer grafischen Benutzeroberflachezu prasentieren. Damit sich die Oberflache moglichst optimal in diese Regelmaschineintegriert, wurde untersucht wie Informationen und Wissen in der Maschine gespeichertwerden und wie man an diese Informationen gelangt.Die Oberflache des Diagnosesystems basiert auf der Eclipse Rich Client Plattform. Hier-durch war es moglich die Ergebnisse der Analyse in einzelne Anwendungsgebiete zu kap-seln und diese als Plugins zu entwickeln. Die daraus resultierende Anwendung zeichnetsich durch ihre Modularitat und Robustheit aus.

i

ii

Danksagung

Diese Zeilen mochte ich nutzen um mich bei allen, die mir bei dieser Arbeit geholfenhaben, zu bedanken.

Bei Prof. Dr. rer. nat. Nikolaus Wulff ohne seine Unterstutzung ware es mir nicht moglichgewesen dieses sehr interessante Projekt durchzufuhren.

Bei meinem Betreuer Dipl. Physiker Tobias Henß fur seine hilfreichen konstruktivenKommentare und die angenehme Arbeit.

Bei meiner guten Freundin B.A. Yvonne Donnebrink fur das Korrekturlesen meinerArbeit.

Bei meinen Eltern und meiner Freundin fur alles.

Ihnen allen sei an dieser Stelle herzlich gedankt.

iii

iv

Eidesstattliche Erklarung

Hiermit versichere ich, dass ich die vorliegende Bachelor-Abschlussarbeit ohne Hilfe Drit-ter und nur mit den angegebenen Quellen und Hilfsmitteln angefertigt habe. Alle Stellen,die aus den Quellen entnommen wurden, sind als solche kenntlich gemacht worden.

Die Arbeit wurde bisher in gleicher oder ahnlicher Form keiner anderen Prufungsbehordevorgelegt und auch nicht veroffentlicht.

Munster, 29. August 2008Unterschrift

v

vi

Inhaltsverzeichnis

Zusammenfassung i

Danksagung iii

Eidesstattliche Erklarung v

1 Einleitung 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Einfuhrung 32.1 Expertensysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 Definition Expertensystemes/regelbasierte System . . . . . . . . . . . . 32.1.2 Regelbasierte Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Die Eclipse Rich Client Plattform . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.1 Warum ein Rich Client? . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.2 Das Rich Client Plattform Konzept . . . . . . . . . . . . . . . . . . . . . 92.2.3 Eclipse Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 Einfuhrung in den Pixel Advisor . . . . . . . . . . . . . . . . . . . . . . . . . . 162.4 Einfuhrung in GridXP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.5 Einfuhrung in UnifiedXP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3 Entwicklung 253.1 Allgemeines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2 Auswahl der Regelmaschine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2.1 Auswahlkriterien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.2.2 CLIPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2.3 JESS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.2.4 JBoss Drools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.2.5 Entscheidung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.3 Anforderungsanalyse der Benutzeroberflache . . . . . . . . . . . . . . . . . . . . 30

vii

Inhaltsverzeichnis

3.3.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.3.2 Anzeige von Fakten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.3.3 Anzeige von Losungsstrategien . . . . . . . . . . . . . . . . . . . . . . . 303.3.4 Bewerten von Losungsstrategien . . . . . . . . . . . . . . . . . . . . . . 323.3.5 Anderung der Regelbasis . . . . . . . . . . . . . . . . . . . . . . . . . . 333.3.6 Erstellen von Log-Dateien . . . . . . . . . . . . . . . . . . . . . . . . . . 333.3.7 Unterschiedlich Sichten . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.3.8 Ergebnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.4 Interviewerkomponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.4.1 Funktionsweise des Pixel Advisors . . . . . . . . . . . . . . . . . . . . . 343.4.2 Funktionsweise GridXP . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.5 Entwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.5.1 Architekturentwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.5.2 Entwurf der Faktenbasis . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.5.3 Datenstruktur der Activations . . . . . . . . . . . . . . . . . . . . . . . 383.5.4 Entwurf Regeleditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.5.5 Errechnung der Wahrscheinlichkeit . . . . . . . . . . . . . . . . . . . . . 433.5.6 Darstellung der Fakten in einer Baumstruktur . . . . . . . . . . . . . . 443.5.7 Anzeigen von Losungsstrategien . . . . . . . . . . . . . . . . . . . . . . 443.5.8 Erstellen von Log-Dateien . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.6 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.6.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.6.2 Implementierung des unifiedxpcore Plugins . . . . . . . . . . . . . . . . 473.6.3 Implementierung des unifiedxpcore.utilities Plugins . . . . . . . . . . . . 483.6.4 Implementierung des unifiedxpclient Plugin . . . . . . . . . . . . . . . . 503.6.5 Implementierung des unifiedxpclient.network Plugin . . . . . . . . . . . 573.6.6 Implementierung des unifiedxpcore.ruleeditor Plugins . . . . . . . . . . 62

4 Test 694.1 JUnit Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.2 Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5 Ausblick 73

6 Literaturverzeichnis xv

Glossar xvii

viii

Abbildungsverzeichnis

2.1 Beispiel Entscheidungsbaum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Komponenten eines XPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Schmema der Vorwartsverkettung [IB] . . . . . . . . . . . . . . . . . . . . . . . 82.4 Eclipse Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.5 SWT Event Modell [Dau05] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.6 SWT Widget Klasse [MS, Seite 30] . . . . . . . . . . . . . . . . . . . . . . . . . 142.7 JFace Event Model [Dau05] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.8 PVSS Datenpunkt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.9 Die vier Layer des Grids [CER] . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.10 Abstrakte Architektur der UnifiedXP Software . . . . . . . . . . . . . . . . . . 22

3.1 Vorgehensmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2 CLIPS-Regel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.3 Drools Regel mit DRL-Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.4 Drools Regel mit DSL Templates . . . . . . . . . . . . . . . . . . . . . . . . . . 293.5 Beispiel: Erster Gemeinsamer Vorfahre - Algorithmus . . . . . . . . . . . . . . . 323.6 Klassendiagramm der Datenstruktur . . . . . . . . . . . . . . . . . . . . . . . . 373.7 UnifedAgendaListener . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.8 StrategyCertainCommonFact . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.9 RuleBaseBuilder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.10 Schlusselworter eines Paketes [Ver08] . . . . . . . . . . . . . . . . . . . . . . . . 413.11 Schlusselworter einer Regel [Ver08] . . . . . . . . . . . . . . . . . . . . . . . . . 413.12 DRL-Datei Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.13 Klassendiagramm ProbabilityStrategy . . . . . . . . . . . . . . . . . . . . . . . 433.14 Komponenten Diagramm der UnifiesXPClient Plugins . . . . . . . . . . . . . . 463.15 Pakete des Kern Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.16 Klassendiagramm des Utilities Plugins . . . . . . . . . . . . . . . . . . . . . . . 493.17 Klassendiagramm des UnifiedXPClient Plugins . . . . . . . . . . . . . . . . . . 513.18 Aussehen der fertigen FaktView . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.19 Klassendiagramm der FaktView . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.20 Die verschiedenen Icons der TreeView . . . . . . . . . . . . . . . . . . . . . . . 543.21 Scheme des Selection Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

ix

Abbildungsverzeichnis

3.22 Klassendiragramm des Network-Plugins . . . . . . . . . . . . . . . . . . . . . . 583.23 Typischer Verbindungsaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.24 Login Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613.25 Aussehen des fertigen Regeleditors . . . . . . . . . . . . . . . . . . . . . . . . . 623.26 Menu des Regellisten Fensters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633.27 Klassendiagramms des Regeleditors . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.1 Test der Wahrscheinlichkeit Bild1 . . . . . . . . . . . . . . . . . . . . . . . . . . 714.2 Test der Wahrscheinlichkeit Bild2 . . . . . . . . . . . . . . . . . . . . . . . . . . 71

x

1 Einleitung

1.1 Motivation

Wissenschaftliche Experimente und Computersysteme werden in der heutigen Zeit immer kom-plexer. Fur das betroffene Wartungspersonal ist es kaum noch moglich das ganze System zuuberblicken. Kommt es dann zu einem Problem, ist die Suche nach einer Losung meist ein ner-venaufreibender und langwieriger Prozess. Haufig entstehen auch Situationen in der sich Fehlerwiederholen, doch das Wartungspersonal, das die Losung zu dem wiederholt auftauchendemProblem kennt, ist nicht verfugbar. So kommt es erneut zu der Suche nach einer Losung furein Problem, das als gelost gilt.Beispiel eines solchen Systems ist der ”Large Hadron Collider“ (LHC), mit dessen Hilfe Physi-ker die Geheimnisse unseres Universum entdecken mochten. (Eine genauere Beschreibung folgtim anschließenden Kapitel.) An diesem Experiment arbeiten mehrere tausende Wissenschaftlerund Ingenieure Hand in Hand. Kein einziger von diesen Wissenschaftlern und Ingenieuren istin der Lage die Ausmaße des gesamten Systems zu uberblicken. Trotz dieser Eigenschaft mussein reibungsloser Ablauf garantiert werden. Aus diesem Grund soll ein Expertensystem (XPS)verwendet werden, das das Wartungspersonal bei ihrer Arbeit unterstutzen soll. Dafur verfugtdas XPS uber eine Wissensbasis, die mit Expertenwissen gefullt ist, und eine Faktenbasis mitInformationen uber das System. Die Informationen werden von dem XPS mit Hilfe der Wis-sensbasis ausgewertet. Bei einem Problem kann das Expertensystem, falls Wissen uber dasProblem vorhanden ist, dieses Problem erkennen und eine Losung anzeigen.Die Wissensbasis ist das Kapital eines XPS, denn nur ein XPS mit viel Wissen kann hilf-reich sein. Daher liegt es auf der Hand, dass die richtige Prasentation der Informationen einesSystems und die Erhebung von neuem Wissen sehr wichtig ist. Deswegen gehort die Benutze-roberflache zu einem der wichtigsten Komponenten eines XPS.

1.2 Zielsetzung

Damit Losungen zu Problemen angezeigt werden konnen, muss das XPS uber eine Benut-zeroberflache verfugen. Die Entwicklung einer Benutzeroberflache fur ein XPS ist Ziel dieser

1

1 Einleitung

Arbeit. Damit sich die Benutzeroberflache in ein XPS integrieren kann, ist es wichtig ein sol-ches System zu analysieren und die Vorgange zu verstehen. Aus diesem Grund wurde viel Zeitmit der Analyse eines solchen Systems, verbracht.

Aufgabe der Oberflache soll es sein, dem Wartungspersonal einen schnellen Uberblick uber denZustand des Systems zu geben. Zu diesem Uberblick gehort die Anzeige von Fehlern, Faktenund des Wissens. Da ein XPS nur helfen kann, wenn die Wissensbasis uber viel Wissen verfugt,muss die Oberflache uber eine Funktion zum Erheben des Wissens verfugen.Die Oberflache soll moglichst modular aufgebaut sein. Einzelne Teile sollen ohne viel Aufwandausgetauscht werden konnen. Aus diesem Grund wird als ”Unterbau“ der Oberflache die EclipseRich Client Plattform eingesetzt werden.

1.3 Aufbau der Arbeit

In dem ersten Kapitel ”Einfuhrung“ werden die Begriffe und Systeme, die in dieser Arbeitbenutzt werden, erklart. Hierfur wird erlautert was ein Expertensystem ist, aus welchen Kom-ponenten es besteht, warum eine Rich Client Plattform eingesetzt wird und die Besonderheitdieser Plattform. Zusatzlich wird eine Einfuhrung in die Projekte Pixel Advisor, GridXP undUnifiedXP gegeben.Der ersten Teil des Kapitels Entwicklung geht auf die Analyse der Software ein. In diesen Ab-schnitten wird geklart welche Anforderungen an die Benutzeroberflache gestellt werden, umin den anschließenden Abschnitten den Entwurf des Datenmodells erlautern zu konnen. Ab-schließend wird auf die Implementierung der einzelnen Anforderungen als Rich Client Pluginseingegangen.Das Kapitel Test beschreibt wie vorgegangen wurde um die Funktion der Klassen und dergesamten Software zu testen.Im Kapitel Ausblick wird ein Uberblick uber interessante Features gegeben, die eine spatereVersion dieser Software erweitern konnten.

2

2 Einfuhrung

2.1 Expertensysteme

2.1.1 Definition Expertensystemes/regelbasierte System

Ein Expertensysteme (XPS) erlaubt es auf Grundlage einer Wissensbasis, Probleme eines Fach-gebietes zu losen und so Entscheidungen eines Experten zu simulieren [Jac]. Dabei wird dasExpertenwissen uber einen Wissens-Ingenieur (knowledge engineer) oder einer fur Laien be-nutzbaren Schnittstelle in eine maschinell auswertbare Form transformiert. Das Expertenwissenwird vom Fachpersonal des Einsatzgebietes hinzugefugt. In der Regel ist das Expertenwissennicht in Buchern oder Manuskripten vorhanden, sondern existiert nur in den Kopfen derjeni-gen, die jahrelange Erfahrungen uber ein System gesammelt haben.Die Art, wie in Expertensysteme das Wissen dargestellt und wie eine Schlussfolgerung getroffenwird, kann durch unterschiedliche Modelle realisiert werden [Wik08][IB]:

Fallbasierte Systeme (case-based reasoning ) Bei den fallbasierten Systemen wird ver-sucht Problemstellungen durch Analogieschluss auf schon geloste Probleme zuruckzufuh-ren. Beispiel: A hat Ahnlichkeit mit Problem B und A wurde durch C gelost. Dann kannauch B durch C gelost werden. Hauptbestandteil dieses Systems ist die Fallbasis, in dergeloste Probleme als Falle vorhanden sind. Ein solcher Fall besteht mindestens aus einerProblembeschreibung und einer Problemlosung.

Entscheidungsbaume Systeme die auf Entscheidungsbaumen basieren, versuchen eine pas-sende Losungsstrategie uber das divide and conquer-Prinzip zu finden, frei nach demMotto: ” Ich weiß nicht wie ich das ganze Problem in eins lose, aber vielleicht kenne icheine Strategie, Teilprobleme zu losen“. Es wird versucht ein Problem in viele kleiner Teil-probleme zu zerlegen. Diese Teilprobleme stellen die Knoten eines Baumes da. Die vomKnoten ausgehenden Kanten sind die Auspragungen. Kann man nun die Knoten von derWurzel bis zu einem Blatt verfolgen, wurde eine Losung gefunden. Die Abbildung 2.1 solldieses Modell verdeutlichen. Das Problem in diesem Beispiel ist die Frage, ob das Wetteres zulasst joggen zu gehen. Als Objekt liegt die Wettervorhersage, mit den AttributenTemperatur und Windstarke vor. Es wird nun versucht einen Pfad in dem Baum von derWurzel bis zu einem Blatt zu finden. Entscheidungsbaume konnen auch zum Erheben

3

2 Einfuhrung

neuer Regel genutzt werden. Angenommen es ist sonniges Wetter und die Temperaturist normal, dann wurde daraus eine neue Regel entstehen, die lautet: Wenn Vorhersagegleich sonnig und Temperatur gleich normal ist, dann kann man joggen gehen.

Abbildung 2.1: Beispiel Entscheidungsbaum

Regelbasierte Systeme Sind die haufigste Realisierung von Expertensystemen. In regelba-sierten Systemen liegt das Expertenwissen in Form von Regeln vor. Die Regeln werdenvon Experten direkt in das System eingegeben und sind nur fur eine konkrete Situationgultig.

Expertensysteme werden fur die unterschiedlichsten Einsatzgebiete benutzt. Typische Aufga-benklassen fur Expertensysteme sind (in Klammern sind die Namen einiger realisierter Exper-tensysteme zu sehen) [Wik08] [Fei92]:

Dateninterpretation Analyse von Daten mit dem Ziel einer Zuordnung zu Objekten oderErscheinungen, insbesondere Signalverstehen. Beispiele: Erkennung akustischer Sprache(HEARSAY), Identifizierung chemischer Strukturen anhand von Massenspektrometer-daten (DENDRAL), geologische Erkundung (PROSPECTOR), Proteinstrukturbestim-mung aus Rontgendaten, Erdolbohrung, militarische Aufklarung, U-Boot-Ortung (SEPS,STAMMER).

Uberwachung Interpretation von Daten mit Aktionsauslosung in Abhangigkeit vom Ergeb-nis. Beispiele: Produktionssicherung, Uberwachung von Patienten in der ”eisernen Lun-ge” (VM), Uberwachung eines Kernreaktors (REACTOR).

Diagnose Interpretation von Daten mit starker Erklarungskomponente. Beispiele: vielfaltigin der Medizin, zum Beispiel bei bakteriellen Infektionen (MYCIN), Rheumatologie,innere Medizin (INTERNIST), Pflanzenkrankheiten; außerdem zur Bestimmung undLokalisation von Fehlern in technischen Systemen.

4

2.1 Expertensysteme

Therapie Aktionen zur Korrektur fehlerhafter Systemzustande und Beseitigung der Ursa-chen (oftmals mit Diagnose gekoppelt). Beispiele: siehe Diagnose, Fehlerdiagnose im Au-togetriebe (DEX), Fehlerortung und Wartung bei Telefonnetzen (ACE), automatischeEntwohnung von Beatmungspatienten in der Intensivmedizin (SmartCare/PS).

Planung Erzeugen und Bewerten von Aktionsfolgen zur Erreichung von Zielzustanden: Bei-spiele: Versuchsplanung molekulargenetischer Experimente (MOLGEN), chemische Syn-these (SECS), Finanzplanung (ROME), Produktionsplanung (ISIS), Steuerung des Flug-betriebs auf Flugzeugtragern (CAT), Handlungen autonomer Roboter (NOAH), bei-spielsweise Marsroboter.

Entwurf Beschreibung von Strukturen, die vorgegebenen Anforderungen genugen. Beispiele:unter anderem fur Schaltkreisentwurf (SYN, DAA), Computerkonfiguration (R1/XCON),chemische Verbindungen (SYNCHEM), Konfiguration von Betriebssystemen bei Sie-mensrechnern (SICONFEX).

Prognose Vorhersage und Bewertung erreichbarer Zustande zeitvarianter Systeme. Beispiele:Beurteilung von Erdbebenauswirkungen (SPERIL), Erdbebenvorhersage, Hochwasser-voraussage, Umweltentwicklung (ORBI)

In dieser Arbeit wird ein regelbasierten System eingesetzt. Aus diesem Grund wird im nachstenAbschnitt auf die Besonderheit dieser Realisierungsart eingegangen.

2.1.2 Regelbasierte Systeme

Definition einer Regel

Eine Regel definiert eine Anweisung auf Basis von Aussagen und Logik [Wun]. Regeln werdenmeistens durch ”wenn - dann“ Satze definiert.

Wenn Temperatur der CPU warmer als 50 Grad, dann schalte die Kuhlung ein.

Regeln bestehen aus dem

• eindeutigen Regelnamen, um eine Regel zu identifizieren.

• Bedingungsteil (wenn) wird auch als Left Hand Site (LHS) bezeichnet und kann auseiner oder mehreren Pramissen bestehen. Pramissen sind miteinander logisch verknupftund fuhren uber Konklusion zu einer oder mehreren Aktionen.

• Konsequenzteil (dann) einer Regel wird auch als Right Hand Site (RHS) bezeichnet undkann aus einer oder mehreren Aktionen bestehen.

5

2 Einfuhrung

Aufbau eines Regelbasierten Expertensystemes

Abbildung 2.2: Komponenten eines XPS

Die Abbildung 2.2 zeigt vereinfacht die einzelnen Komponenten und die Kommunikation zwi-schen den Komponenten eines regelbasierten Expertensystems[IB, Seite 6ff].Die einzelnen Komponenten haben folgende Bedeutung:

Regelmaschine (Inference Engine) Die Regelmaschine oder auch Inferenzmaschine leitetdurch Schlussfolgerung (Inferenz) neue Aussagen (Konsequenz) aus der Wissensbasis ab.Die Regelmaschine ist der ”Motor“ eines Expertensystems.

Wissensbasis (Knowledeg Base) Die Wissensbasis enthalt das gesamte Wissen uber einenspeziellen Anwendungsbereich (Domain Specific Knowledge). Alle XPS verfugen ubereine Wissensbasis. Doch nur wenn das Wissen in Form von Regeln abgebildet wird,spricht man von einem regelbasierten Expertensystem. Die Wissensbasis wird bei regel-basierten Systemen haufig in Faktenbasis und Regelbasis unterteilt. In der Faktenbasisoder auch Working Memory genannt, werden die Fakten hinterlegt, die zum Auswerteneiner Regel fuhren. Fakten stellen die kleinste Einheit von Informationen da. Faktenkonnen zur Faktenbasis hinzugefugt oder entfernt werden. Die Regelbasis enthalt dasExpertenwissen.

6

2.1 Expertensysteme

Benutzeroberflache (User Interface) Die Benutzeroberflache kann in mehrere einzelneKomponenten aufgeteilt werden. Sie sollte aber mindestens uber eine Erklarungskompo-nente verfugen, die die Vorgehensweisen des Expertensystems transparent darstellt. DieErklarungs-Komponente gibt dem Benutzer die Moglichkeit getroffene Problemlosung zuhinterfragen oder Fehler in der Logik zu entdecken. Ein weiterer Bestandteil der Benut-zeroberflache ist die Wissenserwerbs-Komponente, die es Fachexperten ermoglicht neuesWissen fur das XP-System zu definieren.

Die Interviewer-Komponente Dient der Beschaffung von Informationen. Diese Informatio-nen konnen direkt vom Benutzer kommen oder aber automatisch erhobene Messdatensein. Falls die Daten durch einen Dialog mit dem Benutzer erhoben wurden, sprichtman von einem interaktiven System. Werden die Daten automatisch durch eine an dasSystem angeschlossene Datenbeschaffungs-Komponente erhoben spricht man von einemeingebetteten System.

Aktivierungen und Feuern einer Regel

Eine Regel wird als aktiviert bezeichnet, wenn alle die Pramissen des Bedingungsteils denWahrheitswert true (wahr) ergeben. Um zu prufen ob eine Pramisse den Wahrheitswert trueerfullt, bedarf es Informationen aus der Faktenbasis, die in Kombination mit der Regel von derInferenzmaschine ausgewertet wird [Wun].

Fakt: CPU-Temperaturfuhler misst 55 GradPramisse: Temperatur der CPU warmer als 50 Grad ist erfulltKonsequenz: schalte Kuhlung ein ist auszufuhren

Im oberen Beispiel ist der Bedingungsteil der Regel durch das Faktum ”Temperaturfuhlermisst 55 Grad“ aktiviert worden. Der Konsquenzteil wird allerdings erst ausgefuhrt, wenndie Regel feuert. Das Ausfuhren des Konsequenzteils, wird als feuern bezeichnet. Bei demAuswahlmechanismus, welche Regel als nachstes aktiviert wird, unterscheidet man zwischendatengetrieben (forward chaining) und zielgetrieben (backward chaining) [IB].

• Bei der datengetriebene Auswahl oder Vorwartsverkettung wird auf Grundlage von Fak-ten versucht eine Diagnose zu treffen. Um diesen Zweck zu erfullen, wird eine Regel ausder Menge der aktiven Regeln ausgewahlt und deren Auffuhrungsteil ausgefuhrt. DieMenge der aktiven Regeln wird als Konfliktmenge bezeichnet. Durch das Feuern derRegel kann die Datenbasis verandert werden, wodurch vorherige Aktivierungen verlo-ren gehen konnen oder neue Aktivierungen hinzukommen. Dieser Vorgang wird solangewiederholt bis keine Aktivierung mehr vorliegt oder eine Diagnose getroffen wurde.

• Bei der zielgetriebenen Auswahl oder Ruckwartsverkettung versucht man eine vorlie-gende Hypothese bzw. Anfrage zu bestatigen. Wenn kein Faktum vorhanden ist um die

7

2 Einfuhrung

Hypothese zu beantworten, wird versucht eine Regel zu finden deren Konklusion dieHypothese darstellt.

Ordnung (Salience)

Wie bereits oben erwahnt, kann durch das Feuern einer Regel die Faktenbasis verandert werde.Die Anderung der Faktenbasis fuhrt zwangslaufig zu einer neuen Auswertung der Regeln,wodurch aktivierte Regeln zuruckgezogen werden konnen. Normalerweise wird die Regel, dieals erstes aktiviert wurde, auch als erstes gefeuert. Um auf die Reihenfolge, in der Regelngefeuert werden, Einfluss nehmen zu konnen, wird von den meisten Ruleengine die Optionsalience bereitgestellt. Der Wert der salience gibt die Reihenfolge des Feuerns an. Die Regelmit dem hochsten salience Wert wird als erstes gefeuert.

Schleifen

Bei der Vorwartsverkettung lauft die Interpretation der Regeln in einer Schleife ab, siehe Ab-bildung 2.3. Dies kann zu Problemen fuhren, wenn das Faktum, das zum Feuern einer Regelgefuhrt hat, nach dem Feuern immer noch vorhanden ist. Da es immer noch vorhanden ist,gehort auch die Regel, die vorher gefeuert hat, wieder zur Konfliktmenge.Wie man anhand der Abbildung 2.3 erkennt, wurde diese Situation zu einer Schleife fuhren,

Abbildung 2.3: Schmema der Vorwartsverkettung [IB]

da immer wieder die gleiche Regel ausgefuhrt wird. Verhindt werden soll das Entstehen vonSchleifen durch das Refraktionsprinzip [IB]. Refraktionsprinzip heißt: Keine Regel darf zweimal

8

2.2 Die Eclipse Rich Client Plattform

auf den gleichen Zustand angewandt werden. Implementierungen dieses Prinzips merken sich,welche Regel auf welchen Zustand angewandt wurde und verbieten ein erneutes Anwenden derRegel auf diesen Zustand. Die meisten regelbasierten XP-Systeme verfugen uber ein Flag, dasin der Regel gesetzt werden kann. Das Setzen dieses Flags veranlasst die Regelmaschine dazudiese Regel nicht auf den selben Zustand ein weiteres Mal anzuwenden.


2.2.1 Warum ein Rich Client?

Die RCP ermoglicht es einem Entwickler sich auf seine Kernaufgabe zu konzentrieren, namlichdas Entwickeln einer Geschafts- oder Anwendungslogik. Durch die Verwendung einer RCP istman in der Lage, schnell eine professionell aussehende und robuste Software zu entwickeln[JM05]. Eine RC-Anwendung ist jederzeit erweiterbar und besteht aus einer Vielzahl von Mo-dulen, Features oder Plugins. Zwar bedarf es einer gewissen Einarbeitungszeit bis man sich andie Eigenschaften der jeweilige RCP gewohnt hat, doch ist man erst einmal eingearbeitet, kannman mit Hilfe der RCP eine machtige und modular aufgebaute Anwendung entwerfen.

2.2.2 Das Rich Client Plattform Konzept

Um die Arbeit eines Entwicklers zu erleichtern, verfugt eine RCP uber standardisierte Kompo-nenten wie Hilfe System, Docking-System, vordefinierte Dialoge, Wizards und einen Update-Manager. Das Docking-System kummert sich um das Layout der einzelnen Fenster der Appli-kation. Die einzelnen Fenster konnen dadurch beliebig in ihrer Große verandert, verschoben,minimiert, maximiert und ineinander gestapelt werden.

Modularitat ist ein Kernkonzept jeder RCP. Jede RCP ist durch Module oder Plugins erweiter-bar. Jedes Modul kapselt einen gewissen Aufgabenbereich in sich. Zwischen den Modulen exis-tiert nur eine lose Kopplung. Sehr haufig wird die Verbindung zwischen Abhangigkeiten vonModulen dadurch hergestellt, dass ein Modul einen Service anfordert und ein anderes Moduleinen Service anbietet. Die Zuordnung von Services ubernimmt ein Plugin Manager.

Der Ausdruck ”Rich Client“ soll den Unterschied zum Thin Client verdeutlichen, denn dasGegenteil eines Rich Clients ist ein Thin Client. Die Aufgabe eines Thin Clients ist die Ein-und Ausgabe von Daten. Die auszugebenden Daten werden meist komplett von einem Server

9

2 Einfuhrung

geliefert. Daher sind Thin Clients, nur verbunden mit einem Server, funktionsfahig. Im Ge-gensatz dazu verfugt der Rich Client uber ”Intelligenz“, die diesen auch offline betriebsfahigmacht.

2.2.3 Eclipse Architektur

Die Abbildung 2.4 gibt nur einen sehr abstrakten Uberblick uber die Eclipse Architektur.Allerdings ist der bausteinformige Aufbau klar zu erkennen. Fast jeder der Blocke stellt eineigenstandiges Plugin da. Die Plugin Architektur spielt bei Eclipse eine große Rolle, dennselbst die Eclipse Entwicklungsumgebung ist eine hoch funktionale Rich Client Anwendungund basiert auf einer Menge an Plugins [JM05]. Aufbauend auf die Plattform der Entwicklungs-Umgebung ist das Eclipse Software Development Kit (SDK) mit den Tools fur die Java undEclipse Plugin Programmierung zu finden.Die Plattform Runtime von Eclipse basiert seit der Version 3.2 auf Equinox, die nach dem

Abbildung 2.4: Eclipse Architektur

10


OSGi-Standart entwickelt wurde. OSGi (fruher Open Services Gateway initiative) ist eineSoftwareplattform Spezifikation der OSGi-Alliance, die es erleichtert Anwendungen und ihreDienste nach dem Komponentenmodell zu modularisieren und zu erweitern. Fur das Kompo-nentenmodell findet man folgende Beschreibung [VG00, Seite 293]:

Ein Komponentenmodell legt einen Rahmen fur die Entwicklung und Ausfuhrungvon Komponenten fest, der strukturelle Anforderungen hinsichtlich Verknupfungs-bzw. Kompositionsmoglichkeiten sowie verhaltensorientierte Anforderungen hin-sichtlich Kollaborationsmoglichkeiten an die Komponenten stellt. Daruber hin-aus wird durch ein Komponentenmodell eine Infrastruktur angeboten, die haufigbenotigte Mechanismen wie Verteilung, Persistenz, Nachrichtenaustausch, Sicher-heit und Versionierung implementieren kann.

Das dynamische Modul-Konzept von OSGi mit dem flexiblen Versions- und Abhangigkeits-management stellt wahrscheinlich das wichtigste Feature fur den Rich-Client da. Jedes EclipsePlugin ist ein Module und wird in OSGi als ”Bundle“ bezeichnet. Jedes Bundle kann von ande-ren Bundles abhangen. Die Abhangigkeit kann sehr genau versionsbedingt bestimmt werden.Es ist sogar moglich innerhalb einer Anwendung Abhangigkeiten zu verschiedenen Versioneneines anderen Bundles simultan zu benutzen.

Das kleinste Ganze in einer Rich Client Anwendung ist ein Plugin. Jedes Plugin enthalt dieDatei META-INF/MANIFEST.MF und optional eine plugin.xml. Diese definieren das Verhal-ten zu anderen Plugins. Verfugt ein Plugin uber aktives Verhalten, besitzt es zusatzlich zuden Konfigurationsdateien einen Activator. Diese Klasse dient als Ressourcen Speicher fur dasPlugin und kontrolliert den Lebenszyklus des Plugins. Bei der Aktivierung des Plugins wird dievon AbstractUIPlugin geerbte Methode start() gerufen. Damit die Methode gerufen wird mussder Activtor in der MANIFEST.MF als Bundle-Activator eingetragen werden. Das Manifestspezifiziert das Startverhalten fur das OSGi eines Plugins. Dies ermoglicht es die Plugin erstdann zu laden, wenn sie auch benotigt werden (Lazy Loading). Die Datei plugin.xml enthaltalle Extensions und Extension-Points des Plugin. Die Extension-Points werden definiert, damitandere Plugins das gewunschte Verhalten des Extension Points erganzen konnen. Ein Exten-sion Point basiert zum Beispiel auf ein im Plugin enthaltendes, Interface oder einer Klasse.Extensions sind die Implementierungen gegen die Extension Points. Sie erweitern die Platt-form um ein gewunschtes Verhalten, z.B. dient die Extension ”actionSets“ dazu die im Pluginenthaltenden Actions zu den Menus und Toolbars hinzu zufugen. In Eclipse wird generell gegenInterfaces programmiert. Alle Interfaces fangen in Eclipse mit ”I“ an.Zum Bearbeiten der beiden Dateien MANIFEST.MF und plugin.xml enthalt die Eclipse dasPlugin Development Environment (PDE), einen speziellen Formular basierten Editor. Der Edi-tor ermoglicht eine einfache Beschreibung der Funktionen, die das Plugin haben soll.

Die Eclipse Plattform enthalt eine Reihe weiterer Komponenten, siehe Abbildung 2.4, wie

11

2 Einfuhrung

ein Hilfesystem, einen Update Manager und dem International Component for Unicode (ICU).ICU ist ein sehr nutzliches Tool um eine Anwendung zu lokalisieren bzw. zu internationalisie-ren. Es lasst sich auf eine Klasse anwenden und extrahiert vollautomatisch die in der Klassedefinierten Texte in eine Text-Datei. In der Klasse werden die Strings durch eine Anfrage anein ResourceBundle gestellt. ResourceBundle ist eine abstrakte Klasse aus dem java.util Paket,das Methoden bereitstellt um lokale Spezifikationen aus einer Text-Datei auszulesen.

Wenn man eine Eclipse Rich Client Anwendung oder ein Plugin schreiben will, kommt mannicht daran vorbei sich einmal die Grundfunktionen der Grafikbibliothek SWT und des UI-Toolkits JFace anzuschauen.

SWT

Als Grafikbibliothek wird, wie man aus der Abbildung 2.4 entnehmen kann, nicht Swing son-dern das eigens fur die Eclipse Plattform entwickelte SWT (Standard Widget Toolkit) einge-setzt. SWT ist eine von IBM entwickelte Grafikbibliothek. Im Gegensatz zu Swing versuchtSWT die nativen Betriebssystem GUI1-Komponenten zu benutzen, wodurch SWT basierte An-wendungen automatisch das bestmogliche ”Look & Feel“ erhalten. Zusatzlich ist es schnellerund ressourcenschonender als Swing. Der Nachteil daran besteht darin, dass SWT nicht Platt-formunabhangig ist. Fur jedes Betriebssystem, auf dem eine SWT basierte Anwendung laufensoll, muss es eine SWT-Implementierung geben. Zurzeit sind auf der Website von Eclipse 2 13Implementierungen fur verschiedene Betriebssysteme vorhanden. Auch mussen die angeforder-ten Ressourcen in SWT selbst verwaltet werden. Sie werden nicht wie bei Java ublich von derGarbage Collection aufgeraumt. Deshalb verfugt jedes Widget uber eine dispose() Methode,die die angeforderte Ressource freigibt.Jede SWT basierte GUI initiiert mindestens eine Instanz der Basis-Klassen Display und Shell.Die Display Klasse reprasentiert den UI-Thread in der die SWT-Oberflache lauft und verbin-det die Java Anwendung mit dem BS. Sie delegiert jeden Benutzeraufruf aus dem BS zumangesprochenem Widget.Um von einem anderen Thread Veranderungen an der GUI durchzufuhren, muss die Akti-on in eine Runnable gekapselt werden. Die gekapselte Aktion wird dann an den UI-Threadubergeben. Den UI-Thread erhalt man uber die statische Funktion getCurrent() oder get-Default() an der Display Klasse. An die Methoden syncExec() und asyncExec() kann die Run-nable ubergeben werden. Sobald sich eine Moglichkeit ergibt, wird dann die run-Methode desRunnables von dem UI-Thread ausgefuhrt.

1 Display.getCurrent ().asyncExec(new Runnable () {

1GUI = Graphical User Interface2http://download.eclipse.org/eclipse/downloads/drops/R-3.3.2-200802211800/index.php#swt

12


2 @Override3 public void run() {4 button.setText ("Hello World !");5 }6 });

Die Klasse Display hat im Gegensatz zur Klasse Shell keine visuelle Implementierung. Durchdie Shell -Klasse werden in SWT Fenster reprasentiert. Die primare Aufgabe der Shell ist dieBereitstellung eines allgemeinen Verbindungspunktes fur die Container, Widgets und Eventsder Oberflache. Daher dient die Shell als Vorfahre fur alle Komponenten. SWT kennt zweiArten von Shell :

• Top-Level Shell haben das Display als Vorfahre und werden gebraucht um das Haupt-fenster der Anwendung zu entwerfen.

• Dialog-Shells haben keinen Verweis auf einen Vorfahren und sind der Top-Level Shelluntergeordnet.

Die Kommunikation mit den GUI-Komponenten wird uber das SWT-Event-Model hergestellt,siehe Grafik 2.5. Die Methode readAndDispatch() der Display-Klasse durchsucht die Nach-richtenwarteschlange des BS auf, fur die GUI, relevante Events. Ist dies der Fall werden die

Abbildung 2.5: SWT Event Modell [Dau05]

Nachrichten an die Top-Level Shell geleitet. Die Top-Level Shell bestimmt fur welches GUI-Widget die Nachricht bestimmt ist und leitet das Event an das Widget weiter. Das GUI-Widgetinformiert ihre Listener uber das Event und ruft die Event-Handling-Methode des implemen-tierten Interfaces auf. Fur jede Art von Event gibt es ein anderes Interface, das von einemListener implementiert werden muss. Das Interface beschreibt wie der Listener zu reagierenhat.Fur jedes Interface gibt es einen Adapter. Der Adapter ist eine Klasse, die alle Methoden einesInterfaces implementiert, aber kein Verhalten hat. Ein Adapter erleichtert einem Programmie-rer die Arbeit, denn der Programmierer muss nur die Methode uberschreiben an dessen Aufrufer interessiert ist.Alle Event Klassen verfugen uber mehrere offentliche (public) Member-Variablen, wie Quelle

13

2 Einfuhrung

und Type. Diese Variablen dienen dazu die Events zu beschreiben. SWT bietet wie jede Gra-fikbibliothek eine Vielzahl fertiger UI-Widgets. Die Abbildung 2.6 gibt einen Uberblick uberdie verschiedenen Widgets. SWT bietet eine Menge an Vorzugen gegenuber Swing an. Doch

Abbildung 2.6: SWT Widget Klasse [MS, Seite 30]

besitzt es auch seine Schattenseiten. Gerade die Plattform Unabhangigkeit ist ein großer Vor-teil von Swing. Damit SWT noch attraktiver wird, haben die Entwickler von SWT das JFaceUI-Toolkit entwickelt.

JFace

JFace fugt dem SWT eine Reihe an UI-Entwicklungshilfsmittel hinzu. Dabei vereinen die JFaceKomponenten die Struktur und die Prasentation eines UI-Widgets, um eine Menge an wieder-verwendbaren Komponenten bereitzustellen, die die Entwicklung einer Java basierten Ober-flache erleichtern soll. Im JFace Toolkit sind Komponenten wie Image und Font Registrierung,Dialogen, Frameworks fur Eingenschafts-Seiten, Wizards, Viewer, Actions und Fortschritts-anzeige fur lang-laufende Operationen enthalten. JFace bildet das Fundament der Eclipse UI[JM05].Das JFace Viewer Framework erlaubt eine einfache Manipulation von Trees, Tables, Combos,StyledTexts und Lists. Das Framework ist eine Implementierung des Model-View-Controller(MVC) Entwurfsmuster und macht eine direkte Benutzung des Domain-Modells moglich. Hier-zu benutzt es die beiden Klassen ContentProvider und LabelProvider, die sich darum kummern,welche Daten des Domain-Modells wie angezeigt werden. Der LabelProvider weiß wie (welcherText und welches Image) ein Element des Modelles angezeigt werden muss. Der ContentProvi-der kennt das Modell und weiß, welches Element angezeigt werden muss. Zusatzlich implemen-tiert es einen Lazy-Loading Mechanismus fur nicht sichtbare Element. So werden Elemente,

14


die nicht sichtbar sind, erst erstellt, wenn diese angefordert werden.Im Gegensatz zum SWT Event-Modell, wo das Listener Verhalten immer fur eine bestimmteArt von Komponente entworfen wird, (Zwar ist es moglich einen allgemeinen Listener zubenut-zen, doch muss im Verhalten des allgemeinen Listener festgestellt werden, von welcher Kom-ponente der Aufruf kam.) benutzt JFace, um eine hohere wieder Verwendbarkeit des Event-Handling Verhaltens zu schaffen, eine eigene Event-Verarbeitung, siehe Abbildung 2.7.Beim JFace Event-Handling wurde das Event-Handling Verhalten von dem GUI-Widget ent-

Abbildung 2.7: JFace Event Model [Dau05]

koppelt. JFace separiert die Event Verarbeitung in zwei Teile: einen Teil (Contribution), dersich um die Reprasentation und um das Delegieren von Events im GUI Fenster sorgt und einemanderen Teil (Action), der sich um die Event-Verarbeitung kummert. Die SWT-Events wurdendurch Actions ersetzt. Actions konnen fur jede Art von Komponente als Verhalten eingesetztwerden. Contribution kombinieren den Event-Listener und das GUI-Widget. Allerdings ist dasJFace Event-Model nicht fur alle Widget konzipiert, sondern nur fur Buttons, Toolbar undMenus. Der Sinn hinter der JFace Event Verarbeitung ist es die am haufigsten auftretendenEvents zu verallgemeinern und dadurch wiederverwendbarer zu machen.JFace vereinfacht durch seine UI-Komponenten eine Vielzahl von Vorgangen der Oberflachen-programmierung. Die beiden Komponenten Viewer und Action sind die beiden, die in diesemProjekt die haufigste Anwendung finden. Alle Vorteile zu nennen wurde den Rahmen dieserArbeit sprengen, deswegen wird an dieser Stelle auf das JFace FAQ 3 verwiesen.

Workbench

Fur den Benutzer ist die Workbench nur eine Ansammlung von Fenstern, die in einem Work-bench Window angezeigt werden.Einzelne Fenster sind in Eclipse Views oder Editors. Der Unterschiede zwischen View undEditors sind:

3http://wiki.eclipse.org/The Official Eclipse FAQs#JFace

15

2 Einfuhrung

• In einem Workbench Window befindet sich i.d.R. nur eine Instanz derselben View, aberes konnen sich mehrere Instanzen desselben Editors befinden.

• Editors werden nur in der Editor-Area angezeigt und konnen nicht so wie Views an jedemBereich des Workbench Windows geschoben werden.

• Editors implementieren das ISaveablePart Interface, das die Methoden-Signaturen furden integrierten Save-Mechanismus enthalt. Bei Editoren deren Inhalt verandert wurde,wird das dirty-Flag gesetzt. Hierdurch erkennt die Workbench, dass der Inhalt gespei-chert werden muss bevor der Editor geschlossen wird. Beim Speichern wird durch dieImplementierung des Interfaces von der Workbench automatisch die richtige Methodegerufen.

• Editors verfugen uber keine eigene Toolbar sowie Views. Schaltflachen der Editors werdenzur Workbench Window Toolbar hinzugefugt

• Editors sind nur fur eine vordefinierte Eingabequelle gultig, z.B. Textdateien.

Workbench Windows bestehen aus einer Titelleiste mit Schaltflachen fur die Anderung derGroße und zum Schließen des Windows, der Menuleiste, der CoolBar (Toolbar), Fast-View(Short cut bar) Leisten und im unteren Bereich befindet sich die Statusleiste. Die CoolBar isteine andere Bezeichnung fur die Werkzeugleiste. In der Statusleiste befindet sich integriert eineFortschrittsanzeige fur langlaufende Prozesse. Die Statusleisten und Cool Bar konnen wahl-weise deaktiviert werden. Der Hauptteil des Workbench Windows ist die Workbench Page die0 oder mehr Views und/oder 0 oder mehr Editors enthalten kann. Das Layout verschiedenerViews und Editors in einem Workbench Window wird in einer Perspective definiert.Integriert in die Workbench ist ein Docking-System. Dieses erlaubt es, die Views oder Editors,zur Laufzeit in ihrer Große zu andern, zu verschieben, zu gruppieren, aus diesen Fast-View zuerstellen und diese aus der Workbench heraus zu ziehen. Die Fast-View ist ein Fenster, das alsShortcut an die Seite geschoben wurde und wenn es ausgewahlt wird, uber den Zeitraum inder es den Fokus behalt, angezeigt wird.Durch das Umschalten zwischen einer Perspective kann sich das ganze Verhalten einer Work-bench andern. Ein Beispiel ware: In der einen Perspective hat man das Verhalten und Ausse-hen eines Java Editors und entwickelt Java Programme - in der anderen hat man eine PIM-Anwendung (Personal Information Manager) und kummert sich um seine Geschaftskontakte.

2.3 Einfuhrung in den Pixel Advisor

Pixel Advisor ist ein XPS welches an der Universitat Wuppertal in der Arbeitsgruppe Teilchen-physik von Prof. Mattig entwickelt wird. Geleitet wird das Projekt von dem Doktorand TobiasHenß. Ziel ist es, durch das Programm, eine Hilfestellung fur Schichtarbeitern bei Fehlern im

16

2.3 Einfuhrung in den Pixel Advisor

Pixel Detektor zu bieten.Der Pixel Detektor ist ein Spurdetektor auf Basis von Halbleitern und dient unter anderemzur Impulsmessung von geladenen Teilchen. Eingesetzt wird der Pixel Detektor im innerenDetektor des ATLAS Experimentes am LHC (Large Hadron Collider). Der LHC ist ein Ha-dronen Speichering am Europaischen Labor fur Elementarteilchenphysik CERN in Genf. Mit27km Umfang ist der LHC die derzeit großte Maschine der Welt [CER08]. Im LHC werdenzwei gegensatzliche Protonen-Beams (Strahlen) auf nahezu Lichtgeschwindigkeit beschleunigt.Ein Protonen-Beam besteht aus 2808 Bunches. Jeder Bunch ist ein ”Protonen-Paket“, das ausca. 1011 Protonen besteht. Haben die Protonen-Beams ihre Endgeschwindigkeit erreicht, wer-den die Beams aufeinander gerichtet, wobei es zur Kollision einzelner Protonen kommt. Beider Kollision entstehen neue Partikel, deren Zerfallsprodukte vom ATLAS-Detektor detektiertwerden. Auf Basis der detektieren Zerfallsinformation konnen Energie und Masse eines Teil-chen errechnet werden.Das Atlas Experiment besteht aus den folgenden Komponenten:

• Inneren Detektor, der den Impuls jedes geladenen Partikels und dessen Ursprung misst.

• Kalorimeter, der die Energie des Partikels misst.

• Myon Spektrometer, der Myonen identifiziert und misst.

• Magnetsystem, das die geladenen Partikel auf Kreisbahnen zwingt, um aus dem Bahn-radius die Impulse bestimmen zu konnen.

Je nach Art des Partikels entstehen in den einzelnen Schichten des Experimentes unterschied-liche Signaturen. Aus diesen Signaturen konnen die Teilchenphysiker die Energie und Masseeines Teilchens berechnen.Ziel des ATLAS Teilchendetektor ist es unter anderem das Higgs-Bosson nachzuweisen. Phy-siker vermuten im Higgs-Teilchen die Erklarung der Masse der Elementarteilchen.4

Trotz der hohen Menge an Bunches und der Protonen je Bunch wird es pro Kreuzung der Bun-ches nur in etwa 20 Kollisionen geben. Durch die hohe Geschwindigkeit des Beams werden sichallerdings die beiden Beams ca. 30 Millionen mal pro Sekunde kreuzen, wodurch es zu ca. 600Millionen Kollisionen pro Sekunde kommt. Jede Kollision wird als Event bezeichnet. Wurdeman alle Daten eines Events speichern, entstunden pro Sekunde 100.000 CD gefullt mit Infor-mationen. Da diese Menge von Informationen nicht speicherbar ist, gibt es das TDAQ (Triggerand Data Acquisition). Das TDAQ reduziert die Datenmenge pro Event um den Faktor 200.000auf 320 MB/s [ATL08].

Uberwacht wird der gesamte Detektor durch das Detektorkontrollsystem. Dieses besteht auseiner Hardware- und einer Softwarekomponente. Die Softwarekomponente basiert auf PVSS(Prozess-Visualisierungs und -Steuerungs System). PVSS stellt sogenannte Datenpunkte zur

4http://www.br-online.de/br-alpha/alpha-centauri/alpha-centauri-higgs-teilchen-2005-ID1207916984891.xml

17

2 Einfuhrung

Verfugung, siehe Abbildung 2.8. Datenpunkte konnen z.B. Temperatur Module oder Span-nungsmesser sein. Ein solcher Punkt kann uber den Datenpunktnamen angesprochen werden.In diesen Punkten sind Attribute, wie der aktuelle Zustand und der aktuelle Wert, enthalten.Die Werte in den einzelnen Punkten werden zum Teil aus der Hardware ausgelesen und zumTeil von einer Finite state machine (FSM)5 gesetzt. Die FSM sorgt dafur, dass Fehler erkanntwerden.Der Pixel Detektor besteht auf jeder Seite aus drei Endkappen (Disks), dazwischen befinden

Abbildung 2.8: PVSS Datenpunkt

sich ineinander geschoben drei Zylinder (Barrels). Jeder Barrel besteht aus mehreren Leisten(Staves), auf denen die einzelnen Pixel Module montiert sind. Der Aufbau des Detektor wirdin PVSS als Baum Struktur abgebildet.

Sobald der LHC in den Betrieb geht, werden rund um die Uhr Wissenschaftler im Schichtbe-trieb den Detektor uberwachen. Kommt es wahrend der Laufzeit zu einem Fehler, muss derSchichtarbeiter, um gewahrleisten zu konnen, dass keine wichtigen Informationen verloren ge-hen, moglichst schnell eine Losung finden. Der Schichtarbeiter ist in der Regel nur Experte furein kleines Themengebiet. Am ATLAS-Detektor arbeiten 2200 Physiker, wovon keiner in derLage ist, Experte auf allen Gebieten des Detektors zu sein. Aus diesem Grund entstand furden Pixel Detektor das Pilot-Projekt Pixel Advisor.Die Idee hinter dem Projekt ist, dass ein Experte sein Wissen in Form von Regeln in eineSoftware eingibt. Die Software soll diese Regeln einem Problem zuordnen konnen und dieLosungsstrategie des Experten anzeigen.

5Eine FSM ist ein in sich geschlossenes System, das durch eine endliche Menge von Zustanden undderen Ubergange definiert wird

18

2.4 Einfuhrung in GridXP


Das Grid

In der Einleitung zum Pixel Advisor wurde die immense Datenmenge von 320 MB/s, die derATLAS Detektor im Betrieb produziert, erwahnt. Wenn der LHC 2008 in den Betrieb geht,werden ATLAS und die restlichen Experimente jahrlich ein gesamt Datenvolumen von ca.15PB produzieren. Damit dieses gewaltige Datenaufkommen gespeichert und verwaltet werdenkann, wurde am CERN 2002 das LHC Computing Grid (LCG) gestartet. Es vereint Tausendevon Computern weltweit zu einer Einheit und erlaubt es den Tausenden von Wissenschaftlern,die uber den Globus verteilt sind, rund um die Uhr auf die produzierten Daten zu zugreifenund diese zu analysieren.

Aufbau

Die Generelle-Idee hinter dem Grid-Computing ist die Bereitstellung von Ressourcen, wie Spei-cherplatz und CPU-Zeit. So einfach, wie es moglich ist Strom aus der Steckdose zu bekommen,soll das Grid es ermoglichen auf Speicherplatz und CPU-Rechenzeit zu zugreifen. Realisiertwird dies durch eine Hard- und Softwareinfrastruktur, die die gemeinsame Nutzung und Zu-sammenfassung von Hochleistungsrechner-Kapazitaten erlaubt. Die Architektur des Grids wird

Abbildung 2.9: Die vier Layer des Grids [CER]

in vier Layer aufgeteilt, siehe 2.9. Der unterste Layer ist der Netzwerk-Layer der die Ressour-cen miteinander verknupft. Danach folgt der Ressourcen-Layer, in dem Hochleistungsrechner,Datenbanken, Sensoren und Datenspeicher angesiedelt sind. Im Middleware-Layer sind die

19

2 Einfuhrung

Organisation-Organe enthalten. Die Middleware organisiert und integriert die Ressourcen imGrid. Der oberste Layer wird Applikation-Layer oder Serviceware-Layer genannt. Er stelltAnwendungen fur Benutzerinteraktion zur Verfugung.

Ausfuhren eines Jobs

Um einen Job ausfuhren zu konnen, bedarf es mehrerer Schritte. Im ersten Schritt ist esnotwendig Mitglied in einer Virtuelle Organisation (VO) zu werden. Im Grid ist die virtu-elle Organisation eines der grundlegenden Konzepte. Durch virtuelle Organisationen werdenComputer-Ressourcen, Daten und wissenschaftliche Instrumente einer Interessengruppe zu-sammengefasst. Eine Interessengruppe ware zum Beispiel die Hochenergie Physik, die ihre Ex-perimente und Messdaten in der virtuellen Organisation ”High Energy Physics“ zusammenfasstund in der sich die Personen und Institute, die sich mit der Hochenergie Physik beschaftigen,zusammenschließen. Jedem anderen Physiker der virtuellen Organisation ”High Energy Phy-sics“ stehen automatisch alle Daten und Instrumente dieser Organisation zur Verfugung.Um im Grid identifiziert zu werden, benotigt man ein Zertifikat, das von einer CertificationAuthority (CA) ausgestellt wurde. Das ausgestellte Zertifikat muss in der Grid Benutzer Ober-flache installiert werden. Die Grid Benutzer Oberflache ist der Rechner, der benutzt wird umauf die Grid Umgebung zu zugreifen. Da die Verbindung zum Gird generell uber ein unsicheresMedium, z.B. dem Internet hergestellt wird, ist es notwendig mit seinem Zertifikat eine ”ProxyCredential“ oder auch ”Proxy Zertifikat“ genannt, zu erzeugen. Ein Zertifikat hat in der Re-gel eine Lebensdauer von einem Jahr. Bei Missbrauch muss es fur ungultig erklart (revoked)werden. Wird ein Zertifikat revoked, kann es nicht mehr benutzt werden. Durch die ”ProxyCredential“, die eine kurzere Lebensdauer hat, soll gewahrleistet werden, dass das original Zer-tifikat nicht geklaut werden kann.Um den Job im LCG laufen zu lassen, muss er in der Job Description Language (JDL) be-schrieben werden. Mit der JDL kann beschrieben werden, was ausgefuhrt werden soll, welcheDaten fur die Ausfuhrung benotigt werden, wohin die Ergebnisse geschrieben werden sollenund welche Ressourcen benotigt werden. Der so beschriebene Job wird mit der JDL-Datei aneinen Ressource Broker gesendet.Der Ressource Broker ist ein Organisationseinheit der Middleware. Wenn ein Job an den Res-sourcen Broker gesendet wird, sucht dieser nach der geeigneten Hardware. Gleichzeitig wirdvom Logging and Book-keeping Service der Middleware ein Eintrag erstellt, dass der Job ab-geschickt wurde. Um die geeignete Hardware fur den Job zu finden, kontaktiert der RessourceBroker den Information Service und den Replica Catalog. Diese beiden Middleware Serviceskennen den aktuellen Zustand des Grid. Die Informationen des Information Service und desReplica Catalog werden vom Ressource Broker genutzt um die passende Hardware zu finden.Wahrend der Ressource Broker nach der passenden Hardware sucht, ist der Job im Status

”waiting“. Nachdem die passende Hardware gefunden wurde, ubertragt der Ressource Broker

20


den Job des Computing Element. Gleichzeitig wird der Ressourcen Broker uber diese Ent-scheidung benachrichtigt, der den Job auf den Status ”ready“ setzt. Zusatzlich informiert derBroker das Computing Element uber seine Entscheidung und teilt ihm mit, wo die Daten desJobs zu finden sind.Wahrend ein Job lauft, ist es moglich uber die Benutzeroberflache den Logging and Book-keeping Service zu kontaktieren und den aktuellen Status des Jobs abzufragen. Wird der Jobgerade vom Computing-Element bearbeitet, ist der Status auf ”running“ gesetzt.Sobald der Job ausgefuhrt wurde, sendet das Computing-Element die Ausgabe-Daten an denRessource Broker zuruck. Der Absender kann anschließend die Daten von diesem herunterla-den. Die Informationen uber die Verarbeitung des Jobs bleiben im Logging und BookkeepingService dauerhaft erhalten.Der Bearbeitungsstatus des Jobs kann am Logging and Book-keeping Service jederzeit er-fragt werden. Es ist allerdings nur moglich Informationen uber Jobs zu bekommen, derenErsteller man ist. Daher kann der Logging and Book-Keeping Service nicht als Instrument derUberwachung dienen, denn der liefert nicht die notige Transparenz um Probleme, die wahrendder Ausfuhrung eines Jobs entstehen konnen, zu analysieren.Um zutreffende Aussagen uber den Jobverlauf und uber den Zustand des Grids zu erstellen,wurde das Job Monitoring eingefuhrt. Der Job Execution Monitors (JEM) ist ein solches Mo-nitoring Tool an dessen Entwicklung die Universitat Wuppertal beteiligt ist.

Monitoring von Jobs

Der Job Execution Monitor (JEM) ist ein in Python geschriebener Wrapper, der um denoriginal Job gepackt wird. JEM soll helfen die Job-Ausfuhrung zu uberwachen. Damit JEMInformationen uber die Ausfuhrung sammeln kann, wird der im JEM-Wrapper gepackte Jobwie oben beschrieben, submitted. Auf der Worker Node6 wird, anstelle des Jobs, zuerst derJEM-Wrapper gestartet.Wahrend der Job ausgefuhrt wird, sammelt JEM Laufzeit Informationen. Zu diesen LaufzeitInformationen gehoren geworfene sowie festgehaltene Exceptions, ausgefuhrte Kommandos,Systemressourcen der Workern Node und im Falle von Fehlern der Name des Skripts, Funkti-onsname, Zeilennummer und der Inhalt aller Variablen. Diese Laufzeit Informationen werdenan R-GMA (Relational Grid Monitoring Architecture) gesendet. R-GMA ist ein Service furverteilte Computerumgebungen um Monitoring-, Logging- und User-Level-Informationen zusammeln und bereitzustellen. Die Informationen werden wie bei einer Datenbank in Tabellengespeichert. Informationen konnen uber den SQL-Befehl ”select“ aus diesen Tabellen gelesenwerden.

6Worker Nodes und Computing Elemente dienen der Verarbeitung von Grid-Jobs

21

2 Einfuhrung

GridXP

Das XP-System GridXP wurde entwickelt um die Daten, die von den Monitoring-Systemenin R-GMA gespeichert werden, regelbasiert zu analysieren und um Fehler auf einem Systementdecken zu konnen. GridXP wird an der Universitat Wuppertal entwickelt. Der Projektleiterist der Doktorand Markus Mechtel.

2.5 Einfuhrung in UnifiedXP

UnifiedXP ist eine Code-Basis um die Benutzung eines Expertensystems fur verschiedene An-wendungen zu erleichtern. Eine andere Anwendung ware zum Beispiel ein anderer Detektor. ImProjekt sind eine Ruleengine und Container fur Aktivierungen, Fakten und Regeln enthalten.UnifiedXP ist eine Client/Server Anwendung. Der Server enthalt die Faktbasis, RegelBasis

Abbildung 2.10: Abstrakte Architektur der UnifiedXP Software

und die Inferenzemaschine. Der Client dient als Erklarungs und Wissenserwerbskomponente.Daher ist es die Aufgabe des Clients die Fakten, Aktivierungen und Regeln da zu stellen undes autorisierten Benutzern zu ermoglichen Regeln zu bearbeiten und die Regelbasis auszutau-schen.Zum Anpassen des Servers an eine andere Anwendung genugt es die Interviewerkomponente,

22

2.5 Einfuhrung in UnifiedXP

die Regelbasis und die Konfigurationsdatei auszutauschen (Siehe Abbildung 2.10). Das Inter-viewerkomponente ist fur jeden Anwendungsfall unterschiedlich. Die Aufgabe dieser Kompo-nente ist es die Faktenbasis des Server mit Fakten zu fullen und diese aktuell zu halten.Die beiden Projekte Pixel Advisor und GridXP sind die ersten Expertensysteme die dasUnifiedXP-Projekt als Kern benutzen.

23

2 Einfuhrung

24

3 Entwicklung

3.1 Allgemeines

Die Entwicklung der Software gliederte sich in die vier Phasen Analyse, Entwurf, Implemen-tierung und Test. Nach jedem Test wurde die aktuelle Code-Version in ein zentrales Code-Repository committed. Bei der Entwicklung wurde nach dem Inkrementell-iteratives Vorge-hensmodel vorgegangen. Daher bauten die Ergebnisse jeder Phase aufeinander auf, doch wie-derholten sich die Phasen wahrend der Entwicklung, siehe Abbildung 3.1.Zu Beginn der Entwicklung musste erst einmal analysiert werden, welche Informationen die

Abbildung 3.1: Vorgehensmodell

GUI anzeigen soll. In Interviews mit den beiden Projektleitern Tobias Henss und Markus Mech-tel wurden die Muss-Anforderungen an die Oberflache geklart.Aufbauend auf den Ergebnissen der Anforderungsanalyse folgte der Entwurf der einzelnen An-forderungen. Wahrend des Entwurfes wurde die Architektur der Software erstellt.Aufgabe desEntwurfes war es auch die richtige Regelmaschine auszuwahlen.

25

3 Entwicklung

Eine wichtige Muss-Anforderung von Markus Mechtel an das gesamte Projekt war es dasProjekt als eine Server und Client Anwendung zu realisieren. Der Grund dieser Anforderungist, dass die Server Komponente, die die Fakten und Regeln auswertet und fur den Clientbereithalt, auf einer Workstation mit Grid Benutzeroberflache laufen soll. Zu diesem Rech-ner sollen sich mehrere Clients verbinden konnen. Da der Rechner nicht zwangslaufig uberein Window-System verfugt, sollen sich die Clients uber eine Netzwerkverbindung zu diesemRechner verbinden konnen.

Ein weiterer wichtiger allgemeiner Punkt ist der Datenschutz innerhalb der Software. Das Gridsoll in Zukunft fur kommerzielle Produkte attraktiver gemacht werden. Damit kommerzielleProdukte das Grid nutzen konnen, muss verhindert werden, dass die Daten an unbefugte Drittegelangen. Um diese Anforderung zu realisieren, wird die Server/Client- Verbindung uber SSLverschlusselt. Zusatzlich sollen Benutzer nur auf die Daten Zugriff erhalten, uber deren Rech-te sie verfugen. Rechte uber die Daten haben die Benutzer, wenn sie die Ersteller der Datensind. Um diese Anforderung gewahrleisten zu konnen, muss der Benutzer sich mit seinem SSL-Zertifikat am Server authentifizieren. Fur die Authentifizierung konnen die gleichen Zertifikategenutzt werden, die auch zum Committen eines Jobs benotigt werden. Einzige Voraussetzungist das die Zertifikate des Benutzers von einer dem Server bekannten CA signiert sind.

Das Modul fur die Server-Client-Kommunikation und der Authentifizierung eines Benutzerswurde von Frank Iker, der fur seine Bachelor-Arbeit an der Vereinheitlichung von regelbasiertenExpertensystem arbeitet, bereitgestellt.

3.2 Auswahl der Regelmaschine

3.2.1 Auswahlkriterien

Vor der Implementierung eines Expertensystems steht die Frage, fur welche Regelmaschineman sich entscheidet, baut man auf eine Bestehende auf oder entwickelt man selber eine aufSystem-Anforderungen basierende, neue Regelmaschine. Auf dem Markt existieren mehrerefertige Regelmaschinen. Viele von ihnen sind unter einer Open-Source Licence veroffentlichtworden und konnen sogar in kommerzieller Software eingesetzt werden.Im UnifiedXP Projekt hat man sich fur die Regelmaschine JBoss Drools, der Firma RedHat,entschieden. Ebenfalls wurde Drools in den vorher separat existierenden Projekten GridXPund Pixel Advisor eingesetzt. Bei der Wahl fur eine der frei erhaltlichen Regelmaschinen hatman folgende Entscheidungskriterien berucksichtigt:

26


• Benutzeroberflache: Bietet die Regelmaschine Schnittstellen um eine eigene Plattformunabhangige Benutzeroberflache anzubinden?

• Art der Faktenbasis: Wie gelangen die Fakten in die Regelmaschine? Sind Schnittstellenvorhanden um Fakten durch eine Softwarekomponente hinzufugen zu konnen? Ist esmoglich JavaBeans in Regeln zu benutzen?

• Syntax der Regelsprache. Sind Programmierkenntnisse erforderlich um neue Regeln zuerstellen, oder konnen auch unerfahrene Benutzer neue Regeln erstellen?

• Art der Unterstutzung. Existiert eine aktive und große Community? Sind aktuelle undverstandlich Dokumentationen vorhanden?

• Lizenzart. Ist die Software als Open-Source lizenziert?

• Art der Einbindung in vorhandene Software. Erlaubt es die Architektur der Regelma-schine vorhandene Software weiterhin zu benutzen.

Als Alternativen zu JBoss Drools wurden CLIPS und Jess getestet.

3.2.2 CLIPS

CLIPS (C Language Integrated Production System) ist eine von der NASA entwickelte Pro-grammiersprache um regelbasierte Expertensysteme zu entwickeln [dB08]. Da CLIPS sehrschnell und kostenlos ist, ist es die am haufigsten verwendete Regelmaschine um Expertensys-teme zu erstellen. Die Regeln werden in der LIPS (List Processing) ahnlichen CLIPS Syntaximplementiert, siehe Abbildung 3.2.Um die Regeln auch in Java benutzen zu konnen, bietet CLIPS ein Java Native Interface

Abbildung 3.2: CLIPS-Regel

an. Uber die Spracherweiterung COOL (Clips Object-Oriented Language) ist es zusatzlichmoglich die Besonderheiten wie Vererbung und Polymorphismus von objektorientierten Spra-chen in den Regeln abzufragen. Jedoch ist die Art, um auf Attribute einer Klasse zugreifen zukonnen, im Gegensatz zu dem was andere Regelmaschinen bieten sehr umstandlich. Denn inCLIPS mussen Fakten als Atome (Skalarwerte, Einzelwerte) in die Faktbasis hinzugefugt wer-den. Das bedeutet, wenn eine Klasse zur Faktenbasis hinzugefugt wird, konnen Attribute ’is-a’oder ’has-a’ abgefragt werden. Jedoch ist es nicht moglich auf Klassen Variablen zu zugreifen.

27

3 Entwicklung

Das Zugreifen auf Klassen Variablen ist nur moglich wenn, diese als Atome zur Faktenbasishinzugefugt werden.

3.2.3 JESS

Jess (Jave Expert System Shell) ist als Clone von CLIPS in Java entstanden. Doch mittler-weile sind die beiden Sprachen nicht mehr kompatibel zueinander. Die Regeln werden in deraus CLIPS gewohnten Syntax eingeben. Dabei erweitert Jess diese Syntax, um die FahigkeitJavaBeans in das Working Memory hinzuzufugen und dessen Member Variablen in Regeln zubenutzen. Zusatzlich bietet Jess die Moglichkeit Regeln in XML (JessML) zu definieren unddie XML-Datei aus Java heraus zu parsen. Im Gegensatz zu CLIPS ist Jess keine Open SourceRule Engine und nur fur den nicht kommerziellen Gebrauch kostenlos [dB08].

3.2.4 JBoss Drools

JBoss Drools ist komplett in Java geschrieben und bietet eine 100% Java Unterstutzung. Seiteinigen Jahren gehort Drools zum Portfolio der Firma RedHat und wird von RedHat aktivweiterentwickelt. Als Unterstutzung fur den Einstieg bietet RedHat eine Vielzahl von Doku-menten, Beispiel Implementationen, Foren und Wikis an. Es hat sich auch hinter der Softwareeine aktive Community gebildet, die auf Fragen schnell und adaquat antwortet.Regeln werden in Drools in drl-Dateien geschrieben oder wahlweise in XML. Die Regel-Syntaxist bei Drools naher an einer naturlichen Sprache angelehnt, wie man anhand der Abbildung3.3 erkennen kann.Vergleicht man die Regel 3.3 mit der CLIPS-Regel 3.2, die genau dasselbe verhalten hat, sieht

Abbildung 3.3: Drools Regel mit DRL-Syntax

man, was damit gemeint ist ”einer naturlichen Sprache angelehnt“. Wenn die Regeln noch les-barer gemacht werden sollen, gibt es in Drool die Moglichkeit eine dsl-Datei (Domain SpecificLanguage) zu benutzten. Mit einer dsl-Datei ist es moglich Templates zu definieren. Templates

28


sind naturliche Sprach-Schnipsel, die als Stellvertreter fur die Drool Rules Language (DRL)dienen.In der Abbildung 3.4 wurde die DRL und Java Syntax durch dsl-Templates ausgetauscht,

Abbildung 3.4: Drools Regel mit DSL Templates

wodurch die Regel um ein vielfaches lesbarer und verstandlicher wird. JBoss liefert fur dieEclipse IDE ein Plugin. Im Plugin sind ein Regeleditor mit Syntaxhervorhebung und Autover-vollstandigung, ein Fenster um dsl-Dateien zu erstellen, eine Rule-Flow GUI und ein Regel-Debugger enthalten. Die Rule-Flow GUI erlaubt es grafisch die Reihenfolge, in der Regelnausgefuhrt werden, zu bestimmen. Ein weiterer Vorteil an Drools ist, dass es Open-Source ist.

Drools bietet eine Vielzahl von Moglichkeiten aus Java heraus die Vorgange in der Regelenginezu kontrollieren und zu loggen. Mit Vorgangen ist gemeint: Das Hinzufugen oder Entfernenvon Fakten, die Aktivierung einer neuen Regel oder das Feuern einer Regel. Alle Ereignisse,die in der Regelmaschine auftreten, haben spezielle Event Interface implementiert. Mithilfevon dem zugehorigen Event-Listener ist es moglich sich an diesen Event zu registrieren. Abdem Zeitpunkt der Registrierung wird man automatisch uber ein neues Event informiert. DieseSchnittstellen werden genutzt um den UnifiedXP Client mit Informationen aus dem Server zuversorgen.

Zusatzlich verfugt die Drools Regelsprache uber eine Vielzahl von Optionen, die zur Steue-rung der Ausfuhrungsreihenfolge von Regeln ahnlich der Salience dienen. Es gibt zum Beispieldie Option Agenda-Groups, die es erlaubt Regeln in Agenda-Groups einzuteilen und einen Fo-kus auf eine bestimmte Agenda-Group zu setzten. Ist der Fokus auf eine bestimmte Gruppegesetzt, werden die Regeln, die dieser Gruppe angehoren, beim Auswahlen einer zu feuern-den Aktivierungen bevorzugt behandelt. Drools hat auch einen Algorithmus implementiert derSchleifen in der Ausfuhrung von Regeln verhindern soll. Die Option, die das Refraktionsprinzipeinschaltet, heißt ”no-loop“ und kann innerhalb der Regelbeschreibung gesetzt werden.

29

3 Entwicklung

3.2.5 Entscheidung

Einer der Hauptgrunde gegen Jess und CLIPS ist ihre fur Laien schwer verstandliche Regel-Syntax. Gegen Jess sprach zusatzlich die inaktive Community, dass Jess kein Open-SourceProjekt ist und das nur sehr wenige Programmierer an Jess entwickeln. CLIPS schied wegender fehlenden JavaBeans Unterstutzung und der Regel-Syntax aus. Im Gegensatz zu den bei-den anderen bieten Drools eine offene und zu 100% freie Java-Architektur, die Moglichkeitnaturliche Sprachkonstrukte in Regeln einzubetten und eine aktive Community.

3.3 Anforderungsanalyse der Benutzeroberflache

3.3.1 Einleitung

Die Benutzeroberflache des Expertensystems dient zur Darstellung der im Expertensystemablaufenden Vorgange. Sie soll einem Benutzer wie z.B. einem Schichtarbeiter einen schnellenUberblick uber das zu beobachtende System ermoglichen. In den folgenden Abschnitten werdendie einzelnen Anwendungsfalle der Oberflache beschreiben.

3.3.2 Anzeige von Fakten

Auf der grafischen Oberflache soll der Benutzer einen Uberblick uber die vorhandenen Faktenbekommen. Die Fakten des Systems sollen als Knoten (n) in einem Baum (B) dargestellt wer-den. Mit der Maus oder der Tastatur soll der Benutzer durch diesen Baum navigieren konnen.Wahlt der Benutzer ein Element des Baums aus, soll er die Details zu diesem Knoten angezeigtbekommen.

3.3.3 Anzeige von Losungsstrategien

Regeln die zum Losen eines Problems dienen, sollen nicht gefeuert werden. Anstelle, dass dieseRegeln feuern, soll die Aktivierung der Regel in der Benutzeroberflache angezeigt werden. DasFeuern der Regel wurde zum Verlust einer Aktivierung fuhren. Zwar ist es moglich sich dieAktivierungen zu merken, doch wurde man hierdurch die Information verlieren ob ein Fehlernoch vorhanden ist. Ist ein Faktum im Baum selektiert, werden nur die Aktivierungen derNachfolger und die des selektierten Faktes angezeigt.

30


Wenn mehrere Aktivierungen zu einem aus dem Faktenbaum ausgewahlten Faktum existierenund dieser der erste gemeinsame Vorganger der Fakten, die zur Aktivierung gefuhrt haben ist,dann soll eine Wahrscheinlichkeit in Prozent angegeben werden. Der erste gemeinsame Vorfah-re ist in der Theorie der Knoten, an dem es zu einem Fehler gekommen ist. Die Position diesesVorgangers wird durch den folgenden Algorithmus bestimmt.

Def.:Die Menge der Fakten, die zu einer Aktivierung gefuhrt haben, heißt FA.

FA = {f1, ..., fn}

Die Menge aller Pfade (p) fur die Fakten aus FA von dem Faktum zur Wurzel (W )heißt P

P = {pfad(f1, W (B), ...., pfad(fn, W (B)}Die Menge aller Langen der Pfade aus P heißt L

L = {len(p1), ..., len(pn)}

Die Funktion minLen gibt aus der Menge P den Pfad mit der kurzesten Langezuruck.

px = minLen(P )

Das Element x = nxi−1 , fur nxi gilt

nxi ∈ px fur alle i = 0, ...,min(L)

ist der erst gemeinsame Vorfahre wenn gilt:

k = len(pj)−min(L) + i fur alle j = 0, ..., n

nxi−1 = np1k= np2k

= ... = npnk

Die Wahrscheinlichkeit soll dem Benutzer anzeigen, wie hoch die Chance ist, dass die angezeigteLosungsstrategie zum Losen des Problems fuhrt. Der Algorithmus, der die Wahrscheinlichkeitfur jede Aktivierung ausrechnet, soll austauschbar sein. Der Vorteil, der ein austauschbarerAlgorithmus mit sich bringt, ist, dass es moglich ist selber zu bestimmen, wie die Wahrschein-lichkeit dargestellt wird. Denkbar ware zum Beispiel, dass der Wert der Wahrscheinlichkeitnicht 100% erreicht, sondern nur 99%. Durch diese geringe Abweichung wurde dem Benutzersignalisiert werden, dass eine mogliche Restungenauigkeit nicht ausgeschlossen ist.Beispiel:Es liegt fur den Pixel Detektor folgende Situation vor:

31

3 Entwicklung

• Es existiert eine Regel, die aktiviert wird, wenn die Versorgungsspannung VDD und dieHochspannung HV einen bestimmten Wert uberschreiten.

• Es liegen Fakten vor, die die Regel aktivieren (Fakten mit 45◦ Schraffur in Abbildung3.5)

In diesem Fall konnte der gemeinsame Vorfahre (Fakten mit Senkrechter Schraffur) Verursacherdes Problems sein. Zusatzlich konne es eine Regel geben, die aktiviert wird, wenn es mehrereModule mit Fehlern gibt, was zu der Schlussfolgerung fuhrt, dass Sector1 der Grund fur dieFehler sein konnte.

Abbildung 3.5: Beispiel: Erster Gemeinsamer Vorfahre - Algorithmus

3.3.4 Bewerten von Losungsstrategien

Wenn eine Aktivierung mit einer hohen Wahrscheinlichkeit nicht zu einem Problem zutrifft,folglich dessen Losungsstrategie nicht zum Losen des Problems gefuhrt hat, soll der Benutzerdie Wahrscheinlichkeit einer Regel beeinflussen konnen.

32


3.3.5 Anderung der Regelbasis

Benutzer mit hoheren Privilegien soll es gestattet sein die Regelbasis zu verandern. Veranderungenkonnen sein:

• bearbeiten von Regeln

• hinzufugen von neuen Regeln

• loschen von Regeln

• Regelbasis des Servers auszutauschen und neu zu laden

Außerdem soll es diesen Benutzer moglich sein den Server zu beenden.

3.3.6 Erstellen von Log-Dateien

Fur die spatere Analyse von Problemen ware es wunschenswert, Log-Dateien speichern zukonnen. Anhand der Log-Datei soll man erkennen, warum eine Regel aktiviert wurde. Des-wegen mussen diese Log-Dateien die Fakten enthalten, die zur Aktivierung gefuhrt haben.Jedes Faktum sollte in diesem Log mit dem zugehorigen Werten aufgefuhrt sein. Das Erstelleneiner Log-Datei soll aus einer Regel heraus durchfuhrbar sein. Uber einen in der Oberflacheintegrierten Betrachter, soll es moglich sein, die Log-Dateien analysieren zu konnen.

3.3.7 Unterschiedlich Sichten

Je nach Wissensstand der Benutzer soll eine andere Anordnung der Fenster angezeigt werden.Wird die Anwendung von einem Schichtarbeiter oder ahnlich qualifizierten Benutzer genutzt,soll die Oberflache uber nur wenige Aktionen verfugen und nur die wichtigsten Informationenenthalten.

3.3.8 Ergebnis

Zusammengefasst ergeben sich fur die Benutzeroberflache folgende Muss-Anforderungen:

1. Darstellung der Fakten in einer Baumstruktur

2. Anzeige von Detail zu einem Knoten

3. Anzeigen von Losungsstrategie

4. Bewerten von Losungsstrategie

33

3 Entwicklung

5. Anordnen der Losungsstrategie nach der Wahrscheinlichkeit

6. Algorithmus zum Berechnen der Wahrscheinlichkeit soll austauschbar sein

7. Spezielle Funktionen fur privilegierte Benutzer:

a) Austausch und neu laden der Regelbasisb) Herunterfahren des Serversc) Regeln bearbeiten, erstellen und loschen

8. Anzeigen der Regelmaschinen Log-Dateien

9. Unterschiedliche Perspektiven fur unterschiedliche Aufgaben.

Wie das Modell dieser Anforderungen aussieht, wird im Abschnitt Entwurf beschrieben.

3.4 Interviewerkomponenten

Fur die Entwicklung einer moderaten Datenstruktur ist es wichtig das Verhalten der Kom-ponenten zu kennen, die auf diese zugreifen. Aus diesem Grund werden an dieser Stelle dieFunktionweisen der beiden existierenden Module, des Pixel Advisors und des GridXP, ge-zeigt.

3.4.1 Funktionsweise des Pixel Advisors

Pixel Advisor wird als Datenannahme Modul eingesetzt. Dieses Modul bekommt seine Datenuber dem DIM (Distributed Information Management System) Mechanismus. DIM wurde amCERN fur den Vorganger Detektor, Delphi, entwickelt. DIM ist ein Kommunikationssystemfur verteilte Umgebungen. Der DIM Server publiziert ein oder mehrere Services, die vom Cli-ent abonniert werden konnen. Services konnen uber ihre Namen angesprochen werden undenthalten jegliche Art von Informationen. Abonniert der Client ein Service, wird der Clientautomatisch uber Anderungen informiert. Der DIM-Server bekommt seine Informationen vonPVSS.

In der ersten Phase der Beschaffung neuer Fakten – das Abonnieren eines Datenpunktes –wird ein subscriptionCommandObject-Objekt in die Faktenbasis angelegt. Das subscription-CommandObject dient dazu den Dim-Server aufzufordern neue Datenpunkte zu veroffentlichen.Hierfur wird in dem Objekt der Name des Services gespeichert, der abonniert werden soll.Zusatzlich bewirkt das Einfugen eines Faktum in die Faktenbasis ein erneutes Auswerten derRegeln.

34

3.4 Interviewerkomponenten

Durch das erneute Auswerten wird der Wert des eingefugten subscriptionCommandObject-Faktum auf den zu abonnierenden Service verandert. Jedes Faktum ist nach dem JavaBeanStandard aufgebaut und implementiert die PropertyChange Unterstutzung. Durch diese Un-terstutzung ist es moglich sich als Interessent uber die Anderung des Zustandes eines Faktumsinformieren zu lassen.Getriggert durch die Anderungen des Zustandes des subscriptionCommandObject Faktums,fordert das Datenannahme Modul den DIM-Server auf, weitere Werte zu veroffentlichen. An-schließend wird ein Faktum, mit dem Namen des angeforderten Services, fur die Antwort desDIM-Servers hinzugefugt.Fur die Verbindung zwischen Dim-Server und Datannahme dient das XpsDimInfo Objekt.Kommt es auf PVSS-Seite zu einer Wertanderung im abonnierten Datenpunkt wird das XpsDi-mInfo Objekt aktualisiert und die infoHandler -Methode aufgerufen. Die infoHandler -Methodeam XpsDimInfo-Objekt startet einen neuen Thread der den Wert des vorher angelegten Fak-tums aktualisiert.Jedes Faktum verfugt uber eine Member-Variable name. Diese Variable enthalt einen system-weit eindeutigen Schlussel uber das, das Faktum identifiziert werden kann. Als Schlussel dientder Datenpunktname aus PVSS. Durch die Wertanderung des Faktums werden die Regelnerneut ausgewertet und der Vorgang beginnt von vorne.Uber den beschriebenen Mechanismus wird die Faktenbasis mit Werten gefullt. Wie bereitserwahnt, ist der Aufbau des Detektors in PVSS als Baum abgebildet. Ein Fehler auf denobersten Ebenen hat zur Folge, dass alle Datenpunkte mit dem Status Warning abonniert wer-den, bis die unterste Ebene erreicht ist. Die unterste Ebene des Baums enthalt Temperatur oderStrommessungsmodule. Der Grund fur dieses Vorgehen liegt darin, dass die Ubertragungsratean Wertanderungen pro Sekunde bei DIM auf 1000 begrenzt ist. Allerding sind alleine imPixel-Detektor 10.000 Wertanderungen pro Sekunde zu erwarten.

3.4.2 Funktionsweise GridXP

Die Funktionsweise des GridXP basiert auf ein etwas einfacheres Prinzip, als der Pixel Advisor.Uber R-GMA Java-API ist es moglich SQL-Befehl aus einem Java Programm an R-GMA zusenden. Da unter Umstanden mehrere Minuten vergehen konnen bis auf einem SQL-Befehlgeantwortet wird, hat jede Tabelle, die man auslesen mochte, einen eigenen Consumer. DieConsumer sind als Threads implementiert und werden beim Initialisieren der Anwendung ge-startet. Um die Faktenbasis mit Informationen zu fullen, senden die einzelnen Consumer denSQL-Befehl

1 select \textasteriskcentered from table

an die zugehorige Tabelle. Aus den Antworten des R-GMA Services werden Java Objekteerzeugt, die der Consumer zur Faktenbasis hinzufugt.

35

3 Entwicklung

3.5 Entwurf

3.5.1 Architekturentwurf

Damit die Informationen der Regelmaschine durch den Client angezeigt werden konnen, ist esnotig eine geeignete Datenstruktur zu entwerfen. Die wichtigsten Informationen, die fur denBenutzer aufbereitet und in dem GUI angezeigt werden, sind Fakten, Aktivierungen und Re-geln. Diese Informationen werden als JavaBeans gespeichert. Fur jeden dieser Informationenexistiert ein Container der die Objekte organisiert, siehe Abbildung 3.6. Die Container sindnach dem Singleton Entwurfsmuster entworfen worden. Durch die Verwendung des Singleton-Musters [EG94], soll gewahrleistet werden, dass keine zwei Instanzen eines Container existieren.Zusatzlich wird die Klasse der Container durch die Benutzung des Singleton-Muster global.Hierdurch wird es uberflussig an Klassen, die auf Fakten oder Ahnlichem zugreifen mussen,eine Referenz auf den entsprechenden Container beim Erzeugen zu ubergeben.Die Beans werden vom Server als serialisierte Objekte geliefert. Aus diesem Grund imple-

mentieren alle Beans das Serializable Interface. Durch das Serializable Interface wird gezeigt,dass die Klassen serialisierbar sind und nur serialisierbare Member-Variablen enthalten.Drools verfugt zwar uber die Objekte Rule, Package und Activation, doch verfugen diese Ob-jekte teilweise uber unnotige, uber zu wenig Informationen oder uber Informationen, die sichnicht mehr im Klartext lesen lassen. Als Konsequenz daraus wurden fur alle diese Objekt neueKlassen erstellt. Diese Klassen bieten eine einfache Abstraktion der benotigten Informationen.

In den nun folgenden Unterkapiteln wird beschrieben, wie der Entwurf fur die Datenstruk-tur aussieht und wie die Container mit Daten angereichert werden. Die Datenstruktur ist sokonzipiert, dass diese im Server und im Client einsetzbar ist. Da es auf Client Seite keineRegelmaschine gibt, wird der Teil, der mit der Regelmaschine kommuniziert, im Client deak-tiviert.

3.5.2 Entwurf der Faktenbasis

Damit die Fakten systemweit eindeutig sind, enthalten sie einen eindeutigen Schlussel. DieserSchlussel soll gewahrleisten, dass kein Faktum doppelt vorhanden ist. Fakten werden durchStoreableObjects reprasentiert. Organisiert werden diese Fakten im StoreableObjectsSet. Die-ser Container enthalt eine Menge von Funktionen, die zur Organisation der Fakten dienen.Zusatzlich kummert sich der Container darum, dass Fakten nach Benutzern sortiert sind.Hierfur existiert im Faktum ein Member user, der den Namen des Benutzers enthalt. Die-ses Sortieren stellt sicher, dass ein Benutzer nur die Fakten zugeschickt bekommt, fur die erauch die Rechte besitzt. Der Container bietet die einzige Schnittstelle zum WorkingMemory.

36

3.5 Entwurf

Abbildung 3.6: Klassendiagramm der Datenstruktur

37

3 Entwicklung

Objekte, die zum StoreableObjectsSet hinzugefugt werden, werden automatisch auch zum Wor-kingMemory hinzugefugt. Das Gleiche gilt fur das Entfernen von Fakten. Beide Falle fuhrenzu einer erneuten Auswertung der Regelbasis.Damit der Container nach einer langeren Laufzeit nicht uberlauft, wird eine maximale Kapa-zitat angegeben. Wenn diese Kapazitat uberschritten wird, fangt der im Hintergrund laufendeStoreOptimizer an das Faktum mit den altesten Timestamps zu loschen. Der Optimierer loschtsolange Fakten bis wieder genugend freie Kapazitaten vorhanden sind. Die Fakten verfugenuber das Flag removeable. Falls das Flag gesetzt ist - z.B. aus einer Regel heraus - wird dasObjekt nicht wahrend der Optimierung geloscht. So soll verhindert werden, dass der Optimiererein wichtiges Objekt loscht.

3.5.3 Datenstruktur der Activations

Die Informationen fur eine SimpleActivationAbstraction kommen aus dem WorkingMemory.Das WorkingMemory verfugt uber einer Agenda. Zur Agenda werden alle aktiven Regeln alsAktivierung hinzugefugt. Um uber so ein Event benachrichtigt zu werden, genugt es das Agen-daEventListener Interface zu implementieren und sich am WorkingMemory zu registrieren.Nachdem man sich an dem WorkingMemory registriert hat, wird man uber folgende Eventsinformiert:

ActivationCreatedEvent wenn eine Aktivierung zur Agenda hinzugefugt wurde.

BeforeActivationFiringEvent wenn mit der Ausfuhrung des Konsequenzteils einer Regelbegonnen wird.

AfterActivationFiredEvent wenn der Konsequenzteil der Aktivierung ausgefuhrt wurde.

ActivationCancelledEvent wenn mehrere Aktivierungen vorliegen und das Ausfuhren dereinen Regel dazu fuhrt, dass der Bedingungsteil einer anderen Regel nicht mehr zutrifft,dann wird die Aktivierung der nicht mehr zutreffenden Regel abgebrochen.

AgendaGroupPoppedEvent wenn der Fokus auf eine Agenda Gruppe gesetzt wurde.

AgendaGroupPushedEvent wenn der Fokus auf eine Agenda Gruppe aufgehoben wurde.

Damit man nicht gezwungen ist jede Methode auszuimplementieren, bietet Drools den Defaul-tAgendaEventListener an von dem man sich ableiten kann. Nicht uberschriebene Methoden,die die unterschiedlichen Events abarbeiten, werden durch ein dummy-Verhalten ersetzt.Die Klasse UnifiedAgendaListener 3.7 leitet sich von der Klasse DefaultAgendaEventListener

ab und uberschreibt die Methoden

• activationCancelled

• activationCreated

38

3.5 Entwurf

Abbildung 3.7: UnifedAgendaListener

• beforeActivationFired

• afterActivationFired

Uber das Event Objekt gelangt der Listener an die Drools Reprasentation einer Aktivierung.Die Aktivierung verfugt uber die notigen Informationen, um eine SimpleActivationAbstractionzu erzeugen. Die so erzeugte Abstraktion wird zum Container fur Aktivierungen hinzugefugt.Beim Hinzufugen einer Aktivierung zum Container wird automatisch der erste gemeinsameVorfahre gesucht und gesetzt. Damit der Algorithmus, der den gemeinsamen Vorfahren be-stimmt, austauschbar ist, wurde an dieser Stelle das Strategy [EG94] Entwurfsmuster benutzt3.8.Außerdem wird ein Counter mit dem Namen hasActivation in den Fakten einer Aktivierun-

Abbildung 3.8: StrategyCertainCommonFact

gen hochgezahlt, sobald eine Aktivierung hinzugefugt wird. Dieser Counter zeigt an, ob undwie viele Aktivierungen es fur ein Faktum gibt. Ein zweiter Counter hasActivationForChildwird hochgezahlt, wenn fur einen Nachfolger eine Aktivierung existiert. Wird eine Aktivierunggeloscht, werden die Counter heruntergezahlt.

3.5.4 Entwurf Regeleditor

Uber die Benutzerschnittstelle soll der Benutzer Regeln verfassen, bearbeiten und loschenkonnen. Als Quellen fur die Regeln dienen die Drools drl-Dateien. Beim Erstellen der Drools

39

3 Entwicklung

RuleBase und des WorkingMemory werden die Regeln aus der drl-Datei in Drools Rule Objekteubersetzt. Diese Objekte verfugen bis auf dem Namen uber keine weiteren lesbaren Informa-tionen aus der Quelle. Aus diesem Grund werden die Regeln fur die Oberflache separat alsSimpleRuleAbstraction gespeichert.Fur die Umwandlung von Text in ein SimpleRuleAbstraction Objekt wird eine Builder-Klassebenutzt. Die Builder-Klasse implementiert das Interface IRuleBaseBuilder 3.9. Das zusatzlicheInterface erlaubt es spateren Entwicklern den einfachen Austausch des Builders. Durch denAustausch eines Builders ware es moglich Regeln aus anderen Quelle einzulesen. Von Droolsunterstutzt werden XML-Dateien und Datenbanken.Die Builder Klasse bekommt als Argumente den Pfad zu den drl-Dateien und optional zu den

Abbildung 3.9: RuleBaseBuilder

dsl-Dateien. Die drl-Datei wird von dem RulesSetBuilder analysiert. Der Builder liest die Text-Datei zeilenweise ein und vergleicht die Zeile uber Regulare Ausdrucke mit den Schlusselworternder Drools Regel-Syntax, siehe Abbildung 3.10.Findet der Builder ein Schlusselwort, das nicht ”function“ oder ”rule“ lautet, wird die eingele-

sene Zeile zu einer SimplePackageAbstraction-Instanz hinzugefugt. Ist das Schlusselwort ”rule“,liest der Builder eine Regel ein und fugt den eineindeutigen Namen der Regel zum Packagehinzu. Das Erstellen einer Regel aus einen Text lauft wie in der Abbildung 3.11 gezeigt ab.Der Builder liest den Namen der Regel ein. Anschließend werden solange die Attribute oder

40

3.5 Entwurf

Abbildung 3.10: Schlusselworter eines Paketes [Ver08]

Abbildung 3.11: Schlusselworter einer Regel [Ver08]

41

3 Entwicklung

Optionen eingelesen bis das Schlusselwort ”when“ gefunden wird. Nach ”when“ wird wiederumsolange ein LHS-Statement eingelesen bis die Zeile mit ”then“ beginnt. Das gleiche wird fur dieRHS-Statements durchgefuhrt. Beim Einlesen der RHS-Statements wird zusatzlich uberpruft,ob das DSL-Template ”Solution:“ vorhanden ist. Der Text, der auf ein Solution-Tag folgt, wirdin der Member-Variable solution gespeichert. Wird das Schlusselwort ”end“ gefunden, ist dieRegel eingelesen und der Builder erstellt aus den eingelesenen Informationen eine SimpleRu-leAbstraction Instanz. Diese Instanz wird zum RulesSet hinzugefugt.

Fur das Schlusselwort ”function“ wird die Anzahl der geoffneten geschweiften Klammern er-mittelt. Fur jede geschlossene geschweifte Klammer wird die Anzahl heruntergezahlt. EineFunktion ist erst dann vollstandig eingelesen, wenn die Anzahl der offenen Klammer gleichNull ist. Die so eingelesene Funktion wird als String zu der SimplePackageAbstraction hinzu-gefugt. Ist das Ende der Datei erreicht, (EOF) kann die RuleBase zuruckgegeben werden.

Alle eingelesenen Regeln werden als SimpleRuleAbstraction zum Client gesendet. Im Clientkonnen der Wert der Salience, der Name und die einzelnen Statements bearbeitet werden. Je-doch ist es nur Benutzern mit administrativen Rechten erlaubt Regeln zu bestatigen.

Benutzer ohne administrative Rechte konnen Regeln bearbeiten und neu erstellen. Allerdingswird bei diesen Benutzern das dirty-Flag der Regel gesetzt. Regeln mit dirty-Flag mussen voneinem Admin bestatigt werden. Durch das Bestatigen wird eine eventuell vorhandene Regelausgetauscht und das dirty-Flag auf ”falsch“ gesetzt. Der Admin kann sich die Regeln mitgesetztem dirty-Flag vom Server herunterladen und in dem Rule-Editor bearbeiten, loschenund bestatigen. Nur einem Admin ist es erlaubt die Regelbasis auszutauschen.

Beim Austauschen der Regelbasis werden die lokalen Regeln des Admins zum Server ubertragen.Am Server werden die Quellen neu geschrieben. Nachdem die Quellen neue geschrieben underneut eingelesen sind, sendet der Client eine Reset Nachricht an alle Verbundenen Clients.Die Reset Nachricht fuhrt im Client dazu, dass alle Container geleert und die Inhalte neu an-gefordert werden.

Der RulesFileBuilder, der das IRulesSourceBuilder Interface implementiert, enthalt die Me-thode die zum Neuschreiben der Regelbasis genutzt wird, siehe Abbildung 3.12. Genauso wiebeim RuleBaseBuilder wird hier auch auf die einfache Austauschbarkeit der Builder Klassegeachtet. Die writePackages()-Methode erstellt zu Beginn ein Backup der Originaldatei. Daszusatzliche Backup erlaubt es bei einem Fehler die Originaldatei wiederherzustellen. SyntaxFehler fuhren dazu, dass beim Laden der Regel-Dateien ein Exception geworfen wird. Dies

42

3.5 Entwurf

Abbildung 3.12: DRL-Datei Builder

macht sich am Client dadurch bemerkbar, dass die Regeln nicht gesendet werden. Die einzel-nen Pakete werden aus dem RulesSet Container geholt. Die writePackage()-Methode ersetztdie original Pakete durch die neuen Pakete.

3.5.5 Errechnung der Wahrscheinlichkeit

Der Algorithmus, der die Wahrscheinlichkeit ausrechnet, ist in eine eigenstandige Klasse ein-gekapselt und implementiert das IProbabiltyCalculateStrategy Interface, siehe Abbildung 3.13.Die Art des Aufbaues ist nach dem Strategy Entwurfsmuster entworfen. Durch die Anwen-dung des Strategy Musters werden alle Algorithmen, die das gleiche Ziel verfolgen, in eineGruppe unterteilt. Zukunftigen Entwicklern wird es hierdurch erleichtert die voreingestellteKlasse durch eine andere auszutauschen. Andere Algorithmen konnten z.B., wie in den Anfor-derungen erwahnt so entwickelt sein, dass eine Aktivierung niemals 100% erreicht. Der in der

Abbildung 3.13: Klassendiagramm ProbabilityStrategy

DefaultCalculateStrategy enthaltende Algorithmus zeigt die Wahrscheinlichkeit in Prozent an.Die Wahrscheinlichkeit einer Aktivierung errechnet sich durch:

43

3 Entwicklung

1 Wahrscheinlichkeit = Salience Wert der Aktivierung / Summe allerSaliences * 100.

Um den Grundwert ausrechnen zu konnen wird an der Klasse ActivationsSet die MethodegetActivationsForFact() gerufen. Diese Methode gibt eine Liste mit Aktivierungen zuruck. Inder Liste sind alle Aktivierungen enthalten, die durch einen Nachfolge Faktum entstandensind. Zum Grundwert addiert werden jedoch nur die Fakten, deren activationsCommonFactgleich dem ubergebenen commonFact ist. Bei den Aktivierungen, wo diese Voraussetzung nichtzutrifft, wird die Wahrscheinlichkeit auf 0 gesetzt. Ist der Grundwert aufsummiert, wird dieWahrscheinlichkeit nach der oben gezeigten Formel ausgerechnet.

3.5.6 Darstellung der Fakten in einer Baumstruktur

Da die Fakten hierarchisch in einem Baum angezeigt werden, verfugen diese uber zusatzlicheMember-Variablen. Die Member-Variable parent enthalt den Key des Vorgangerfaktum. Inder Liste children werden die Keys der Nachfolger gespeichert. Da nur die Keys der Fakten,die in Beziehung zu einem Faktum stehen, gespeichert werden, verfugt ein Faktum uber keinedirekte Referenz zu einem anderen. Durch dieses Vorgehen soll verhindert werden, dass Objekteserialisiert werden, die nicht serialisiert werden durfen, denn es durfen nur die Fakten zumClient gesendet werden, die auch in der Faktenbasis (dem StoreableObjectsSet) vorhandensind. Eine weitere Voraussetzung ist, dass die Fakten vom Typ StoreableObject sind, dennder Client kennt nur Fakten diesem Typ. Aus diesem Grund wird vor dem Senden eine neueInstanz vom Typ StoreableObjects erstellt. Die Daten des zu sendenden Faktums werden indiese neue Instanz kopiert. So wird sichergestellt, dass das gesendete Objekt eine Instanz derKlasse StoreableObject ist und nicht die einer Klasse, die die Klasse StoreableObject erweitert.

3.5.7 Anzeigen von Losungsstrategien

Damit eine Losungsstrategie fur eine aktivierte Regel angezeigt wird, muss im Ausfuhrungsteilder Regel das DSL-Template ”Solution:“ enthalten sein. Ist das Template vorhanden, wirdder Text des Solution-Template in der Member-Variable solution, einer Regel, gespeichert.Auf der UI werden alle Aktivierungen zu einem markierten Faktum und dessen Nachfolgerangezeigt. Die angezeigten Aktivierungen werden nach ihrer Wahrscheinlichkeit sortiert. Wahltman eine Aktivierung aus, so erscheinen die Fakten die zur Aktivierung gefuhrt haben und einLosungsvorschlag, der zum Losen des Problems fuhren kann.

44

3.6 Implementierung

3.5.8 Erstellen von Log-Dateien

Zur spateren Analyse wird eine Log-Datei erstellt. Die Log-Datei enthalt alle Events, die inder Agenda aufgetreten sind. Uber die Methode writeToDisk an der Klasse JBossRules ist esmoglich die Log-Datei auf die Festplatte zu schreiben. Drools bietet zum Erstellen von Log-Dateien den WorkingMemoryFileLogger an. Dieser Logger wird als Listener zum Working-Memory hinzugefugt. Ab diesen Zeitpunkt logt dieser jedes Event, das am WorkingMemoryauftritt. Dazu gehoren:

• Erstellen, loschen und ausfuhren von Aktivierungen

• Hinzufugen, aktualisieren und loschen von Fakten

• Ruleflow gestartet und beendet

• Ruleflow-group aktiviert und deaktiviert

• Regel Paket hinzugefugt und geloscht

• Regel geloscht und hinzugefugt

Die Log-Datei wird im XML-Format gespeichert. Die in dem Plugin fur die Eclipse IDE ent-haltende Audit-View ist ein spezieller Betrachter fur die Log-Dateien. Die Audit-View stelltdie Events grafisch aufbereitet als Event-Baum da. Durch die Benutzung der Eclise RCP istes moglich diese View in die spatere Anwendung einzubauen um es Benutzer zu ermoglichendie Log-Datei komfortabel aufbereitet lesen zu konnen.

3.6 Implementierung

3.6.1 Einleitung

In dem nun folgenden Kapitel sollen die Implementierung und die Funktionsweisen der Ober-flache-Komponenten gezeigt werde. Allerdings werden nur die interessanten Code-Fragmenteund Klassen beschrieben. Bei weniger interessanten Fragmenten wird kurz deren Funktion an-gesprochen. Klassen, deren Implementierung eine Eins-zu-eins-Umsetzung des Entwurfes, sindwerden ganz ausgelassen.Fur die Implementierung wurden die Ergebnisse der Anforderungsanalyse und des Entwur-fes in kleinen Aufgaben aufgeteilt. Kleine Aufgaben haben den Vorteil, dass der Aufwanduberschaubar bleibt. Damit auch die Informationen, die zu einer Aufgabe gehoren uberschaubarsind, wurden diese Aufgaben als Task in Mylyn eingegeben. Mylyn ist eine Erweiterung furEclipse, die eine aufgabenfokussierte Benutzeroberflache (task-focused UI) anbietet. Durch die-ses Plugin ist es moglich alle Informationen, die eine Aufgabe betreffen, zu sammeln und zu

45

3 Entwicklung

fokussieren. Wenn ein Aufgabe/Task in Mylyn fokussiert ist, werden nur noch die Informa-tionen angezeigt, die einer Aufgabe zugeordnet sind. Die fokussierten Informationen konnenKlassen, Methoden oder Dateien sein.Die einzelnen Aufgaben wurden nach Art der Anwendung gruppiert und als Plugin entwickelt.Durch die verschiedenen Plugins wird die Anwendung sehr modular. Das komplette ProduktUnifiedXPClient besteht aus 6 Plugins, siehe Abbildung 3.14.Die Abbildung 3.14 gezeigte Produktkonfiguration unifiedxpclient.product ist eine xml-Datei,

Abbildung 3.14: Komponenten Diagramm der UnifiesXPClient Plugins

in der beschrieben steht, wie die Anwendung exportiert werden soll. Die Datei wurde so konfi-guriert, dass die oben angezeigten Plugins mitexportiert werden und die unifiedxpclient RichClient Anwendung ausgefuhrt wird, wenn das Produkt gestartet wird. Des Weiteren benotigtdas unifiedxpcore-Plugin eine Eigenschaft mit der Bezeichnung ”ConfigFilePath“. Diese Eigen-schaft muss der Java Virtual Machine beim Starten der Anwendung, mit der Erweiterung ”-D“,ubergeben werden. Die Eigenschaft enthalt den Pfad zu einer XML-Konfigurationsdatei. DieseDatei wird fur den UnifiedXP-Kern benotigt. In der Datei sind die Standard Pfade zu den Zer-tifikaten, die Adresse des Servers und der Port des Servers enthalten. Der Ubergabeparameterwird in der Produkt Konfigurationdatei gesetzt, wodurch beim Export des Projektes eineini-Datei erzeugt wird. Diese ini-Datei enthalt den Ubergabeparameter. Zusatzlich wurde einBranding der Anwendung eingestellt, das den Starter der Anwendung in UXPClient umbenenntund den Splash Screen der Anwendung um eine Fortschrittsanzeige erganzt.

46

3.6 Implementierung

3.6.2 Implementierung des unifiedxpcore Plugins

Aufgabe und Aufbau

Dieses Plugin enthalt das Modell der GUI. Das in Abbildung 3.15 gezeigte Diagramm enthaltdie Pakete und die Klassen die von der GUI benutzt werden.

Abbildung 3.15: Pakete des Kern Plugins

Wahrend der Programmierung erwies sich das Managen von Abhangigkeiten immer wieder alsProblem. Des Haufigeren kam es nach Programmerganzungen zu Fehlern in den Abhangigkeiten.Eclipse bietet an vielen Stellen die Moglichkeit, diese automatisch setzen zu lassen. Allerdingskann dieser Mechanismus keine Plugins hinzufugen, die nur ”locker“ an einem anderen ge-bunden sind. Problematisch wird es, wenn die Run-Konfiguration in der Eclipse lauft, dochdie exportierte Anwendung wegen fehlenden Abhangigkeiten beim Starten abbricht. In diesenFallen kann es hilfreich sein die Anwendung einmal uber die Console mit dem Parametern ausdem nachsten Listing zu starten.

1 ./ Starter -consolelog -noExit -console

47

3 Entwicklung

Die Erganzung ”-noExit“ bewirkt, dass die Anwendung bei einem Fehler nicht geschlossenwird. Dadurch bekommt man Zugriff auf die OSGi -API und kann mit dem Kommando ”ss“den Status der geladenen Plugins abfragen. Die Plugins lassen sich in diesem ”Modus“ einzelnper Kommando ”start xx“ (xx steht fur die angezeigte Nummer des jeweiligen Plugins) aufru-fen. Durch dieses Vorgehen kann herausgefunden werden, warum welches Plugin nicht gestartetwerden kann, denn das Ubergabeparameter ”-consolelog“ gibt an, alle Fehler auf die Konsoleauszugeben. Hat man den Fehler lokalisieren konnen, kann mit ”exit“ die OSGi Prompt be-endet werden. Wahrend der Entwicklung lagen die Fehler haufig an fehlerhaften Ant-BuildSkripten. Diese werden automatisch aus den Vorgaben erstellt, die man in der build.propertiestrifft.Damit die Fehlersuche bei diesem Problem vereinfacht wird, wurden alle Abhangigkeit in denPlugin unifiedxpcore zusammengefasst. Damit andere Plugins auf die eingebundenen Biblio-theken zugreifen konnen, mussen die Pakete der Bibliotheken, in der Datei MANIFEST.MF,als Export-Packages definiert werden.

Implementierung der Container Klasse

Bei der Implementierung der Container-Klassen ActivtionsSet und StoreableObjectsSet war eswichtig, dass die Klassen Thread-Safe sind, da die Fakten, wie zu Pixel Advisor und GridXPbereits erwahnt, aus nebenlaufigen Threads in die Container Klasse hinzugefugt werden. Ausdiesem Grund sind die benutzen Collections vom Typ SynchronizedMap und wichtige Methodensynchronized. Diese Einstellungen bewirken, dass sich zur gleichen Zeit nur ein Thread in einerMethode aufhalten und auf die Collection zugreifen darf.Zum Inhalt gehort auch die Klasse Client, die sich um den Aufbau der SSL-Verbindung zumServer kummert. Da die Sourcen fur die Klasse zu Verfugung gestellt wurden, soll auf dieImplementierung an dieser Stelle nicht weiter eingegangen werden.

3.6.3 Implementierung des unifiedxpcore.utilities Plugins

Die in Abbildung 3.16 gezeigten Klassen des Utilities Plugins enthalten nutzliche Funktionenund Konstanten, die von anderen Plugins benutzt werden. Die Implementierung der meistenMethoden ist sehr trivial. Aus diesem Grund wird an dieser Stelle nur auf eine kleine Auswahlder Funktionweisen diese Plugins eingegangen.Wie z.B. auf den Eclipse Logging Service, der von der Klasse LogUtil benutzt wird. Uberdie statischen Methoden der Klasse LogUtil lassen sich logging Informationen in die Eclipselog-Datei schreiben. Dazu wird der folgende Aufruf genutzt:

1 Platform.getLog(Platform.getBundle(bundleID)).log(2 new Status(serverity , bundleID , code , message , t));

48

3.6 Implementierung

Abbildung 3.16: Klassendiagramm des Utilities Plugins

Der Aufruf bewirkt, dass die Log-Datei ”.log“ im Verzeichnis workspace/.metadata des RichClient Programm Ordners um einen Eintrag erweitert wird. Das Interessante an dieser Log-Datei ist, dass diese mit der Eclipse LogView graphisch aufbereitet angezeigt werden kann.Damit die LogView im UnifiedXPClient genutzt werden kann, muss zunachst die plugin.xmlum den folgenden Eintrag erweitert werden.

1 <menuContribution2 locationURI ="menu:org.eclipse.ui.main.menu">3 <menu4 id=" window"5 label=" window">6 <command7 commandId ="org.eclipse.ui.views.showView"8 label ="Show Error View"9 style ="push">

10 <parameter11 name="org.eclipse.ui.views.showView.viewId"12 value="org.eclipse.pde.runtime.LogView">13 </parameter >14 </command >15 </menu >16 </menuContribution >

Diese Erganzung bewirkt, dass Eclipse, beim Erstellen des Workbench Window Inhaltes, einenContribution (siehe JFace Kapitel) zum Fenstermenu hinzufugt. Der Contribution Eintrag ruft

49

3 Entwicklung

das showView-Command mit dem angebenden Parameter auf. Im zweiten Schritt ist es wich-tig das Plugin org.eclipse.ui.views.log zu den Abhangigkeiten hinzuzufugen. Dafur reicht esden Eintrag org.eclipse.ui.views.log;bundle-version=”1.0.0” unter Require-Bundle in der MA-NIFEST.MF hinzuzufugen.Diese beiden Einstellungen bewirken, dass beim nachsten Start der Anwendung im Menu Win-dow ein Eintrag vorzufinden ist, der ”Show Error View“ heißt und dieser die Error View offnet.

Aufgaben, deren Abarbeitung eine langere Zeit in Anspruch nehmen, blockieren die GUI.Damit die GUI benutzbar beleibt, werden solche Aufgaben in einem extra Thread ausgelagert.Zu Problemen kann dies fuhren, wenn die ausgelagerte Aufgabe Anderungen an der GUI vor-nehmen muss. Denn, wie bereits im Abschnitt uber SWT erwahnt, kann aus diesen Threadsdie Oberflache nur manipuliert werden, wenn die Manipulation uber die Methoden syncExec()oder asyncExec() der Display Klasse ausgefuhrt wird.Da dies an mehreren Stellen passieren muss, wurde fur die Utilities Klasse eine Methodegeschrieben, die das Wrappen in ein Runnable und ubergeben an die syncExec() Methodeubernehmt. Die Methode uiMethodCall() benotigt dafur das Quellobjekt und den Namen derFunktion, die ausgefuhrt werden soll.

1 private static void uiMethodCall(final Object source , final String2 methodname , boolean sync , final Object ... args)

Zusatzlich kann angegeben werden, ob die Methode synchron oder asynchron zum UI-Threadausgefuhrt werden soll. Optional konnen Argumente vom Typ Object mit ubergeben werden.Die Methode holt sich anhand des Namens per Java-Reflection die zu ubergebene Funktion. DasAufrufen der geholten Funktion wird in einem Runnable gepackt und entweder an syncExec()oder an asyncExec() ubergeben, je nachdem ob sync gleich true ist oder false ist.

3.6.4 Implementierung des unifiedxpclient Plugin

Aufgabe und Struktur

Das unifiedxpclient Plugin ist als RCP-Projekt angelegt worden. Eclipse erstellt bei dieser Artvon Projekt automatisch die Infrastruktur, die benotigt wird um das Plugin als Rich ClientAnwendung laufen zu lassen. Zur benotigten Infrastruktur gehoren die oben erwahnten Datei-en plugin.xml und MANIFEST.MF, wie auch die Klassen aus der Abbildung 3.17.Zu dem Funktionsumfang der Rich Client Anwendung gehoren die Methoden und Views zur

Visualisierung von Fakten und Aktivierungen. Daher sind in diesem Plugin alle Mechanismenvorhanden um Fakten in einer Baumstruktur zu prasentieren, Aktivierungen anzuzeigen undderen Salience Wert zu manipulieren. Die Abbildung 3.18 zeigt die fertige Anwendung. DasModell des Plugins wird uber eine Datenquelle (z.B. das Internet) mit Informationen gefullt.

50

3.6 Implementierung

Abbildung 3.17: Klassendiagramm des UnifiedXPClient Plugins

Damit die Datenquelle nur ”locker“ an die Anwendung angebunden ist, wird ein ExtensionPoint datasource veroffentlicht. Plugins die als Quelle dienen, mussen den Extension Pointdatatsource erweitern und das IDataSource-Interface implementieren.IDataSource verfugt uber eine Methode initDataSource(). Diese Methode wird aufgerufen bevordas Workbench-Window initialisiert ist und dient dazu Netzwerkverbindungen oder ahnlichesbeim Starten zu konfigurieren. Damit die Anzeigen des Fensters auf eine hergestellte Verbin-dung zugreifen konnen, wurde der Methodenaufruf in die postWindowOpen() Methode desApplicationWorkbenchWindowAdvisor eingefugt. Der Methodenaufruf wird vor dem Erzeugender Workbench-Page aufgerufen und dient normalerweise zum Konfigurieren des Workbench-Window Aussehen.

FaktTreeView

Die Klasse FactTreeView erweitert, wie man aus dem Diagramm 3.19 entnehmen kann, dieabstrakte Klasse TreeView. TreeView enthalt eine Referenz auf die Klasse TreeViewer, diezur Darstellung der Fakten in einer Baumstruktur dient. Der TreeViewer bekommt bei derInitialisieren der FactTreeView die beiden Klassen FactTreeContentProvider und FactTreeLa-belProvider ubergeben.Beim Initialisieren und beim Aktualisieren des TreeViewers ist es notig zu wissen welche Ele-mente als Wurzel-Elemente angezeigt werden mussen. Aus diesem Grund verfugt der FactTree-

51

3 Entwicklung

Abbildung 3.18: Aussehen der fertigen FaktView

ContentProvider uber die Klasse TreeModel, an der er sich als Listener registriert. Die KlasseTreeModel registriert sich am StoreableObjectsSet als Listener. Sobald ein neues Faktum zumStoreableObjectsSet hinzugefugt wird, informiert dieser seine Listener. Hierdurch wird die Me-thode propertyChange() an der Klasse TreeModel gerufen. Die Klasse TreeModel kontrolliert,ob es sich um ein Wurzel-Objekt handelt, ist das der Fall, wird das neue Faktum zur Liste derWurzel-Elemente hinzugefugt. Nachdem die Uberprufung abgeschlossen ist, benachrichtigt dasTreeModel den FactTreeContentProvider, der daraufhin den TreeViewer aktualisiert.FactTreeLabelProvider implementiert das Interface ITreeContentProvider. Die implementier-ten Methoden kummern sich um die Ruckgabe und Auswahl des richtigen Elementes in derBaumstruktur. Die Methode getElements() gibt ein Array mit Objekten, die keinen Vorgangerhaben, zuruck. Dazu gibt diese den Ruckgabewert der TreeModel Methode getRootObjects()zuruck. Die Implementierung der Methode getParent(), ist im folgendem Listening gezeigt.Zu Beginn der Methode wird uberpruft, ob es sich bei dem Element um ein StoreableObject

52

3.6 Implementierung

Abbildung 3.19: Klassendiagramm der FaktView

handelt. Die Uberprufung ist eigentlich uberflussig, da an keiner Stelle Objekte, die nicht vonTyp StoreableObject sind, in das StoreableObjectsSet gelangen konnen. Der einzige Fall derabgefangen werden muss ist, dass ein anderer Thread in der zwischen Zeit den Vorganger imStoreableObjectsSet geloscht hat und daher die Methode getStoreble() null zuruck gibt.

1 public Object getParent(Object element) {2 StoreableObject retVal = null;3 if (element instanceof StoreableObject) {4 StoreableObject object = (StoreableObject) element;5 retVal = StoreableObjectsSet.getInstance ().getStoreable(6 object.getParent ());7 }8 // If element not of type StoreableObject or if the parent9 //isn ’t longer available return a dummy -Object

10 if (retVal == null) {11 dummy.setLabel (" Parent isn ’t longer available ");12 retVal = dummy;13 }14 return dummy;15 }

53

3 Entwicklung

Im Unterschied zur Implementierung der getParent() Methode, gibt die getChildren() Methodeein Array von Nachfolgern zuruck. Die Implementierung dieser Methode ist der getParent()sehr ahnlich. Anstelle einer Objektreferenz mussen die Referenzen aller Nachfolger nacheinan-der geholt und zu einem Array hinzugefugt werden.Die hasChildren() Methode dient dem TreeViewer dazu zu entscheiden, ob ein Element entfalltbar ist, folglich Nachfolger besitzt oder ein Blattelement ist. Gibt hasChildren() true zuruck,erscheint vor dem Element ein Symbol zum Aufklappen. Wie ein Element im Baum dargestelltwerden muss, weiß die Klasse FactTreeLabelProvider. Diese leitet sich von der Klasse LabelPro-vider ab. Die uberladene Methode getImage() gibt vier Arten (zu sehen in Abbildung 3.20)von Icons zuruck:

Abbildung 3.20: Die verschiedenen Icons der TreeView

1. Wenn die beiden Zahler hasActivation- und hasChildActivation-Zahler gleich null sind.

2. Wenn der hasActivation-Zahler großer als null und der hasChildActivation-Zahler gleichnull ist.

3. Wenn der hasActivation-Zahler gleich null ist und der hasChildActivation-Zahler großernull ist.

4. Wenn die beiden Zahler hasActivation und hasChildActivation großer als null sind. (Trittauf wenn Element der erste gemeinsame Vorfahre ist.)

Als Text wird beim Aufruf der Methode getText() entweder der Inhalte der StoreableObjects-Variable label zuruckgegeben oder, wenn label keine Zeichen enthalt, der Inhalte der Variablekey. Ein in der Klasse TreeView enthaltenes Kontextmenu erlaubte es (In der Klammer stehendie Namen der Aktion):

• Den Inhalt des TreeModel und des TreeViewer zu leeren (Clear Tree)

• In einem Dialog alle Informationen uber ein selektiertes Objekt anzuschauen (ShowSelected)

• Den TreeViewer zu aktualisieren (Refresh tree)

• Den Baum zu entfalten oder zusammen zu klappen. (Expand all/Collapse all)

Der Benutzer kann mit der Maus oder der Tastatur in dem Baum navigieren und einzelneObjekte selektieren. Damit andere Views oder Editoren uber eine Selektion benachrichtigtwerden, wird der TreeViewer als SectionProvider am Selection Service gesetzt. Dieser Servicewird von der Eclipse Workbench angeboten. Sobald der TreeViewer als Selection Provider

54

3.6 Implementierung

gesetzt ist, werden alle Views und/oder Editors die sich als Listener am Selection Serviceregistriert haben uber eine Selektion informiert, siehe Abbildung 3.21.

Abbildung 3.21: Scheme des Selection Services

DetailView

Die DetailView ist ein solcher Selection Listener. Sie dient der Anzeige von Details zu einemFaktum. Die DetailView wird aktualisiert, sobald ein Faktum im TreeView selektiert ist. Dafurmuss diese das ISelectionListener Interface implementieren. Die implementierte Methode se-lectionChanged() bekommt als Parameter ein Objekt vom Typ ISelection ubergeben. Uberdieses Objekt gelangt man an das selektierte Objekt, das zum Aktualisieren der View dient.Zusatzlich zum ISelectionListener implementiert die View das PropertyChangeListener Inter-face und registriert sich als solcher am StoreableObjectsSet. Jedes Mal, wenn ein neues Faktumzum Set hinzugefugt wird, vergleicht die View, ob es sich um ein Werte-Update des angezeigtenFaktums handelt. Trifft das zu, werden die angezeigten Werte aktualisiert.

ActivationView

Die Aktivations View ist auch an der Selektion eines Objektes im Baum interessiert. Dochanders als die DetailView, wird in dieser die Selektion benutzt um herauszufinden, welche

55

3 Entwicklung

Aktivierungen angezeigt werden mussen. Um das herauszufinden, wird die Methode getActiva-tionsWithProbabilityForFact() aufgerufen. Diese stammt aus dem IProbabiltyCalculateStrategyInterface. Das Interface wird von der Klasse DefaultCalculateStrategy implementiert.Da es sich bei der Methode um eine zeitaufwendigere Aufgabe handelt, wurde der Metho-denaufruf in ein Runnable gekapselt und in einem extra Thread ausgelagert. Der Aufruf derMethode hat, wie im Entwurf beschrieben, zur Folge, dass eine Liste am ActivationsSet ange-fordert wird, die alle Aktivierungen fur die Nachfolger enthalt. Fur das Erstellen dieser Listemussen die Keys der Nachfolger gesammelt werden. Das Sammeln der Keys ubernimmt dieMethode buildRelationshipListForStoreableObject(). Diese ruft rekursiv die Methode getChild-rens() am ubergebenen StoreableObject, solange auf, bis das Objekt keine Nachfolger mehrbesitzt. Die Schlussel der Nachfolger werden in einer Liste gespeichert. Der Inhalt der Listewird anschließend mit den Fakten jeder Aktivierung verglichen. Besitzt eine Aktivierung einenSchlussel eines Nachfolgers, wird diese zur Ruckgabeliste hinzugefugt. Diese Methode ist etwaslangwierig, da die Fakten keine Referenz auf eine durch Sie ausgeloste Aktivierung besitzen.Wurden die Aktivierungen zusammen getragen, wird der Grundwert aufsummiert und Cloneder Aktivierungen erstellt. Die Clone werden erstellt, da der Wahrscheinlichkeitswert in derVariable salience gespeichert wird. Die in Bild 3.18 gezeigte Tabelle fur die Aktivierungenkennt keine Wahrscheinlichkeit. In der Spalte mit dem Titel Probability wird immer der Wertder Salience angezeigt. Nachdem die Liste zuruckgegeben wurde, wird der Inhalt der Tabellefur die Aktivierung geloscht. Danach werden die Elemente aus der Ruckgabelist, zu der Tabellefur die Aktivierungen hinzugefugt.

Um die Tabelle der Aktivierungen zu sortieren, wurde eine SortingListener erstellt. DieserListener wird als SelectionListener zu den Titeln der Tabelle hinzugefugt. Sobald ein Titelangeklickt wird, wird dieser Sortierer aktiv und sortiert den Inhalt der Tabelle auf- oder ab-steigend, je nachdem was fur ein Zustand vorlag. Die Elemente werden mit dem BubbleSortAlgorithmus sortiert 1. Damit die Tabelle automatisch absteigend nach der Wahrscheinlichkeitsortiert wird, sendet der Thread, der die Aktivierungen zu der Tabelle hinzugefugt hat, ab-schließend einen ”vorgetauschten“ Selection-Aufruf an den Sortierer.

Die beiden Schalter ”Helpfully“ und ”Discrad“ dienen dem Benutzer als Ruckmeldung uberdie angezeigte Aktivierung. Der Button ”Helpfully“ inkrementiert den Salience-Wert der aus-gewahlten Aktivierung und ruft an der DataSource die Methode manipulateSalience() auf. DieMethode erwartet als Argumente den Namen der Regel und den neuen Wert der Salience. ImUnterschied zum ”Helpfully-Schalter“ dekrementiert der ”Discard-Schalter“ den Salience-Wert.

Hinter den beiden Gluhlampen wurde eine Funktion implementiert, die die Activations Viewals Listener zum ActivationsSet hinzufugt. Diese Funktion zeigt automatisch alle Aktivierun-

1Fur Interessierte: http://de.wikipedia.org/wiki/BubbleSort

56

http://de.wikipedia.org/wiki/BubbleSort

3.6 Implementierung

gen des AktivationsSet an. Sobald eine neue Aktivierung hinzugefugt wird, aktualisiert sich dieView in diesem Modus. Die Gluhlampe mit dem roten Kreuz deaktiviert diesen Modus.

3.6.5 Implementierung des unifiedxpclient.network Plugin

Aufgabe und Management der Verbindung

Die Funktion dieses Plugins ist es die Verbindung zum Server herzustellen, den Datenflusszu regeln und die Verbindung zu managen. Hierzu wurde die Klasse ConnectionHandler ge-schrieben, die sich von Thread ableitet und die Interfaces IDataSource und ClientListenerimplementiert, siehe Abbildung 3.22. Damit die Verbindung, wenn die Anwendung geschlossenwird, getrennt wird, implementiert diese Klasse zusatzlich das DisposeListener Interface undregistriert sich als solcher an der aktiven Shell. Wenn die Methode widgetDisposed() gerufenwird, sendet der ConnectionHandler ein Nachricht zum Server, dass die Verbindung beendetwird. Gesendet werden Nachrichten uber die sendMessage() Methode an der Client Klasse.Gesendet werden immer Klassen des Types Message. Eine Message besteht aus einem Textund einem Kommando. Alle existierenden Kommandos sind als Enumeration in der KlasseMessage gespeichert. Wird zum Beispiel eine Disconnect Nachricht gesendet, wird eine Mes-sage mit dem Kommando CLIENT DISCONNECT erstellt und an den Server gesendet.Empfangende Nachrichten werden vom Client an die Listeners uber die Methode handleServer-Message() weitergereicht. Der ConnectionHandler wahlt in einer switch-case-Abfrage anhanddes Nachrichtenkommandos einen geeigneten Message-Handler aus. Zusatzlich mussen je nachKommando weitere Anweisungen ausgefuhrt werden. Diese Anweisungen kummern sich dar-um, dass neue Nachrichten gesendet werden. Die Handler sind alle vom Typ Runnable undwerden nach dem Abarbeiten der Anweisungen in der switch-case-Abfrage gestartet.Die Abbildung 3.23 zeigt einen typischen Verbindungsaufbau als Administrator. Zuerst wird

immer die Methode connectToServer() aufgerufen. Der Server antwortet mit einer Nachrichtund informiert den Client, ob er User oder Admin ist. Danach fordert der Client am Serveralle, fur den Benutzer bestimmten Fakten an. Der Server antwortet mit einer UPDATE ALLMessage. Diese Nachricht wird vom UpdateMessageHandler abgearbeitet. Zusatzlich sendet derClient bei dieser Nachricht die Kommandos GET ACTIVATIONS und GET RULE BASE. DieAntworten vom Server werden jeweils vom ActivationsHandler oder RuleBaseUpdateHandlerabgearbeitet. Der UpdateMessageHandler sendet, wenn er die empfangenden Fakten zum Sethinzugefugt hat, eine GET UPDATE Nachricht. Die Antwort UPDATE wird wieder vom Up-dateMessageHandler abgearbeitet. Der Server sendet nur Fakten an den Client, wenn zuvoreine GET UPDATE Message angekommen ist. Dieses Vorgehen soll verhindern, dass der Cli-ent und der Server durch Update Nachrichten, die durch ein Faktum verursacht werden, an

57

3 Entwicklung

Abbildung 3.22: Klassendiragramm des Network-Plugins

58

3.6 Implementierung

Abbildung 3.23: Typischer Verbindungsaufbau

dem sich standig der Wert andert, blockiert werden.

Sendet der Client zum Abschluss eine SHUTDOWN SERVER Message, antwortet der Servermit einer SERVER DISCONNECT Nachricht. Diese Nachricht wird dem Benutzer durch eineMessageBox-Dialog angezeigt. Das Dialog weißt den Benutzer darauf hin, dass der Server her-untergefahren wird und die Verbindung abgebaut wurde.

Fur die Nachrichten, die Daten mit senden, gibt es die in Abbildung 3.15 gezeigten NachrichtenTypen. Diese Nachrichten leiten sich alle von der Nachricht Message ab und werden in dementsprechenden Handler in den richtigen Typ umgewandelt.

Alle Klassen, die am Verbindungsstatus interessiert sind, konnen das IConnectionListener im-plementieren und sich als ConnectionListener am ConnectionHandler registrieren. Andert sichder Status der Verbindung ruft der ConnectionHandler die updateConnectionState() Methode.Der aktuelle Status wird als boolesche Variable isConnected ubergeben.

59

3 Entwicklung

Zusatzlich ist in diesem Plugin ein ActionSet implementiert, das zur Steuerung der Netzwerk-verbindung dient. Im ActionSet enthalten sind die Actions:

• Connect: Ruft am Client die connectToServer() Methode auf.

• Shutdown: Sendet eine Nachricht mit dem Kommando SHUTDOWN SERVER.

• Disconnect: Sendet eine Nachricht mit dem Kommando CLIENT DISCONNECT undweißt den Client an die Verbindung abzubauen.

Das ActionSet wird beim Laden des Plugins automatisch in die Menuleiste des Fensters inte-griert. Die Actions werden dort dem Menu ”Network“ hinzugefugt. Damit das Ausfuhren derActions verbindungsabhangig erlaubt und nicht erlaubt ist, implementieren diese das IConnec-tionListener Interface. Das heißt, falls die Verbindung aufgebaut ist und der Benutzer einAdministrator ist, ist ”Disconnect“ und ”Shutdown“ aktiv und ”Connect“ ausgegraut. Ist derBenutzer kein Administrator, wird ”Shutdown“ ebenso ausgegraut. Ist die Verbindung abge-baut, ist nur ”Connection“ Aktiv.Ob eine Verbindung mit dem Server aufgebaut ist, wird im Client unten links in der ServerOb-serverView angezeigt. Um uber den Verbindungsstatus Auskunft zu geben implementiert dieView den IConnectionListener Interface und registriert sich als Listener am ConnectionHand-ler

Implementierungen des datasource Interfaces

AddEditedRulesDer Aufruf dieser Methode hat zur Folge, dass eine Nachricht vom Typ EditedRulesMessagean den Server gesendet wird. In die Nachricht wird die editierte Regel gepackt. Der Server fugtdie Regel zu der Liste der editierten Regeln des RulesSet hinzu.

ExchangeRuleBaseEntschließt sich ein Administrator die Server Regelbasis durch seine lokale Regelbasis auszutau-schen, wird die Methode exchangeRuleBase() aufgerufen. Diese Methode sendet eine Nachrichtvom Typ EditedRuleBaseMessage mit der neuen Regelbasis zum Server. Im Server wird dieRegelbasis an die Methode exchangeRuleBase() am RulesSet ubergeben. Diese loscht die Re-gelbasis des Servers und fugt die Regeln der neuen Regelbasis hinzu. Wurden die neuen Regelnhinzugefugt schreibt der Server die drl-Dateien neu und resetet die Drools-RuleBase. Hierdurchwerden die Regeln neu eingelesen. Abschließend sendet der Server an alle Clients eine Nachrichtmit dem Kommando RESET. Das Reset bewirkt, dass alle Container Klassen im Client denInhalt loschen. Danach wird der Inhalt neu angefordert (Abbildung 3.23 Nachrichtenfluss absendGetUpdateAll()).

60

3.6 Implementierung

GetAllEditedRulesDie Methode getAllEditedRules() sendet eine Nachricht mit dem Kommando GET EDITED RULESan den Server. Der Server Antwortet mit einer EditedRulesMessage. Diese wird vom EditedRu-lesMessageHandler abgearbeitet. Dieser fugt den Inhalt zu der Liste der editierten Regelnhinzu. Hierdurch werden alle PropertyChangeListener informiert die sich am RulesSet regis-triert haben.

ManipulateSalienceAusgelost durch ein User Feedback in der ActivationsView sendet diese Methode eine Nach-richt vom Typ SalienceMessage an den Server. Die SalienceMessage erwartet als Argumentden Regelname und den neuen Wert der Salience. Der Server holt sich darauf hin am RulesSetdie Instanze zu dem Regelnamen, erstellt eine Kopie dieser Regel und setzt den Wert der Sali-ence. Die Kopie wird mit einem gesetzten dirty-Flag zur List der editierten Regeln hinzugefugt.

InitDataSourceBeim Initialisieren der DataSource ruft der ClientHandler das LoginDialog auf. In dem Login-

Abbildung 3.24: Login Dialog

Dialog (Abbildung 3.24) kann man uber die Schaltflache ”Set“ den Pfad zu seinem Zertifikatsetzten. Der Besitzer muss sich mit seinem Zertifikats-Password authentifizieren. Konnte derBenutzer sich erfolgreich authentifizieren, wird versucht eine Verbindung zum Server aufzu-bauen. Die Adresse und der Port des Servers sind in der XML-Konfigurationsdatei im Instal-lationsverzeichnis des Clients definiert.

getUsernameDer Aufruf der getUsername() Methode bewirkt, dass der ConnectionHandler den Distin-guished Name des Benutzers zuruckgibt. Der Distinguished Name wird vom Client aus demZertifikat ausgelesen.

isAllowedDie Methode isAllowed() erwartet ein String Argument. Anhand dieses String Argumentes,

61

3 Entwicklung

das ein Name einer Funktion sein konnte, soll die DataSource entscheiden, ob der angemeldeteBenutzer uber die erforderlichen Rechte verfugt diese Anforderung auszufuhren.

3.6.6 Implementierung des unifiedxpcore.ruleeditor Plugins

Abbildung 3.25: Aussehen des fertigen Regeleditors

Allgemeines

Dieses Plugin stellt eine View zum Anzeigen von Regeln und einen Editor zum Bearbeiten derRegeln zu Verfugung. Der fertige Editor kann durch umschalten der Perspektive auf ”Rule Edi-tor Perspective“ geoffnet werden. Wahlweise konnen die einzelnen Views uber den Menueintrag

”Add View“ hinzugefugt werden. Die Abbildung 3.25 zeigt den fertigen Regeleditor.

62

3.6 Implementierung

Rules List View

AufgabeDie RulesListView dient zum Darstellen der editierten und nicht editierten Regeln aus dem

RulesSet. Editierte Regeln sind in der Liste dadurch zu erkennen, dass diese das Symbol

haben. Nicht editierte Regeln haben das Symbol . Zum Anzeigen der Regeln wird einTableViewer mit nur einer Spalte benutzt. Es wird hier kein ListViewer eingesetzt, da derListViewer keine Images vor den Eintragen anzeigen kann. Als Modell dient dem TableViewerdie RulesSet Klasse aus dem unifiedXPcore Plugin. An dieser Klasse tragt sich der RulesList-ContentProvider als Listener ein (gleicher Mechanismus wie bei der FaktTreeView). Zusatzlichwird der TableViewer als SelectionProvider am SelectionService eingesetzt gesetzt.

Dynamische FilterUber das View Menu gelangt man an eine Liste von Filtern, die in Abbildung 3.26 gezeigt

Abbildung 3.26: Menu des Regellisten Fensters

werden. Bis auf ”Show only edited rules“ und ”Reset all filters“ werden diese dynamisch erzeugt.Dazu wird der Teil des Regelnamens extrahiert der vor dem ”:“ steht. Aus dem extrahiertenTeil wird das Objekt auf das Gefiltert werden soll, und der Name des Filters erzeugt. Ist einFilter aktiviert werden nur die Elemente in der Liste angezeigt, deren Name den extrahiertenTeil des Regelnamens enthalten.Die Filter sind alle vom Typ RuleBaseFilter. Dieser erweitert die Klasse ViewerFilter. DerRuleBaseFilter ist so konstruiert, dass Boolesche- und Stringvariablen gefiltert werden konnen.Als Paramter braucht der Filter das Objekt auf, dass gefiltert werden soll (zum Beispiel derBooleschewert true) und der Name der Methode, die am zu filterndem Objekt gerufen werdensoll. Der Aufruf der Methode liefert das Objekt, dass die Bedingungen des Filters erfullen muss.Um zu filtern wird die geerbte Methode select() uberschrieben. Das folgende Listing zeigt dieImplementierung der Methode.

63

3 Entwicklung

1 public boolean select(Viewer viewer , Object parentElement , Objectelement) {

2 object = element.getClass ().getMethod(method).invoke(element);3 //catch some Exceptions4 if (object instanceof String) {5 String string = (String) object;6 if (string.contains (( String)filter))7 return true;8 }else if (object instanceof Boolean) {9 boolean bool = (Boolean) object;

10 if (bool == (Boolean)filter)11 return true;12 }13 return false;14 }

Als erstes holte die Methode per Java-Reflection den Ruckgabewert(2) der Methode, die beimErzeugen des Filter angeben wurde. Anschließend findet ein Typ Umwandlung(4-5∨8-9) statt.Das so umgewandelte Objekt wird mit dem Filterobjekt verglichen (6∨10). Stimmt der Ver-gleich, wird true zuruckgegeben, ansonsten false. Wenn die select() Methode false liefert, wirddas Objekt in der Liste nicht angezeigt.

Toolbar SchaltflachenDie im Fenster gezeigten Buttons in der TitelLeiste des Views sind nur aktiv, wenn der Benutzerals Administrator angemeldet ist. Die Schaltflachen aus der Toolbar haben folgende Funktion(Abbildung 3.26 von links nach rechts):

• Loscht die ausgewahlte Regel aus der lokalen Regelbasis.

• Fordert alle editierten Regeln vom der DataSource an. Dazu wird an der DataSourcedie Methode getAllEditedRules() aufgerufen. Der Aufruf der Methode bewirkt, dass diein der DataSource vorhandenen Regeln mit gesetzten dirty-Flag zur lokalen Liste dereditierten Regeln hinzugefugt werden.

• Ruft an der DataSource die Methode exchangeRuleBase() auf. Als Argument wird dieserMethode die lokale Regelbasis des Clients ubergeben. Dieser Aufruf hat zur Folge, dassam Server die Regelbasis durch die Client Regelbasis ausgetauscht wird.

RuleEditor

Die Editor-View ist aus mehreren Teilen aufgebaut. Die Abbildung 3.27 zeigt die einzelnenTeile aus die der Editor aufgebaut ist.

64

3.6 Implementierung

Um Programmierarbeit zu sparen wurde die Anzeige der Left-Hand-Site und der Right-Hand-Site in die Klasse RuleStatementGroup extrahiert. Die Groups werden in der RuleEditorViewdurch einen Rahmen markiert. Groups konnen wie ein einzelnes Wideget uber die MethodesetEnabled() deaktiviert oder aktiviert werden. In der Group werden die einzelnen Zeilen derLeft oder Right Hand Site (Statements) einer Regel in einer Liste angezeigt. Die ComboBox derGroup wird beim Erstellen der View mit den jeweiligen Statements gefullt. Das heißt, aus derCombo fur die Left-Hand-Site konnen alle benutzten Aussagen ausgewahlt werden. (Aussagenwie DSL-Templates.) Die Combo der Right-Hand-Site Group verfugt uber alle Aktionen, diein den Regeln der Regelbasis verwendet wurden. Zusatzlich kann die Combo auch als Textfeldbenutzt werden um einen neuen Eintrag zu definieren. Hat man einen Eintrag ausgewahlt oderneu definiert, kann dieser uber die Schaltflache ”Add Statement“ zu der Liste hinzugefugtwerden. Das Hinzufugen ubernimmt der RuleStatementGroupController. Dieser kummert sichum das Verhalten der Group.Die Liste der Statements verfugt uber ein Kontextmenu mit den beiden Funktionen ”EditSelected“ und ”Delete Selected“. Wird ”Edit Selected“ ausgewahlt, wird der selektierte Eintragin der Combo angezeigt und der Fokus auf die Combo gesetzt. Sobald die Combo den Fokusverliert, wird die Anderung an den Listeneintrag ubertragen. Der Aufruf von ”Delete Selected“bewirkt, dass der selektierte Eintrag der Liste geloscht wird.Der Regeleditor registriert sich als SelectionListener am Selction Service. Wird in der Rules

List eine Regel ausgewahlt, werden die Inhalte des Regeleditors mit dem Inhalt der selektiertenRegel gefullt. Die View ist State getrieben, wodurch verhindert werden soll, dass durch einefalsche Bedienung der Buttons aus der Buttonsbar inkonsistente Daten entstehen. Andertman den View-State, wirkt sich dieses nur auf die Schaltflachen der View aus, nicht auf dasDatenmodell.Editiert werden konnen die Regeln erst dann, wenn der Schaltflache ”Edit“ gedruckt wird. DasDrucken des Schalters hat zur Folge, dass der RuleEditorController der View, diese auf denState EDIT setzt. In diesem State werden die Schaltflache, die nicht betatigt werden durfen,deaktiviert und die Eingabefelder aktiviert. Zusatzlich wird der SelectionListener ausgetragen,sodass ein Selektieren einer anderen Regel die View nicht mehr beeinflusst, siehe nachfolgendesListing.

1 butConfirmRule.setEnabled(true);2 butEdit.setEnabled(false);3 butNew.setEnabled(false);4 butSave.setEnabled(true);5 txtRulename.setEditable(true);6 txtSalience.setEditable(true);7 butAbort.setEnabled(true);8 lhs.setEnabled(true);9 rhs.setEnabled(true);

10 getSite ().getWorkbenchWindow ().getSelectionService ()11 .removeSelectionListener(listener);

65

3 Entwicklung

EDIT und NEW haben das gleiche Verhalten. Der State EDIT kann nur verlassen werden,wenn einer der aktiven Schalter gedruckt oder die View geschlossen wird.Druckt man den ”Abort“-Schalter, wurden die Anderungen an der Regel verworfen werden undder View-State auf ABORT gesetzt. Die View-States ABORT und SAVE haben das gleicheVerhalten. Beide deaktivieren die von EDIT oder NEW aktivierten Schaltflachen.Beim Auswahlen von ”New“ wird der Inhalt der editierbaren Felder geloscht und es kann eineneue Regel erstellt werden. Das Drucken von ”Save“ speichert die Regel als editierte Regel inder Regelbasis. Zusatzlich erscheint ein Dialog. Das Dialog will bestatigt bekommen, ob dieeditierte Regel zur DataSource gesendet werden soll. Wird das Dialog mit OK beantwortet,wird die Regel an die Methode addEditedRules() der DataSource ubergeben.Editierte Regeln konnen nur von einem Administrator in eine nicht editierte Regel uberfuhrtwerden. Nur als Administrator ist der Schalter ”Confirm rule“ sichtbar. Aktiviert werden kanndieser, wenn eine Regel ausgewahlt wird und auf ”Edit“ geklickt wird. Das Betatigen des

”Confirm rule“ Schalters bewirkt, dass der Controller die Kopien der Regel aus der Liste dereditierten Regeln loscht und die Regel zur Liste der nicht editierten Regeln hinzugefugt. Danachwird die View in den State SAVE gesetzt.

66

3.6 Implementierung

Abbildung 3.27: Klassendiagramms des Regeleditors

67

3 Entwicklung

68

4 Test

4.1 JUnit Tests

Fur die wichtigen Klassen des Unified-Projektes wurden sogenannte Unit-Test erstellt. JUnitbietet eine API zum Testen von Java-Programmen. Die Tests werden direkt in Java geschriebenund sind wiederholbar. Fur die Eclipse IDE existiert ein Plugin, das die Ausfuhrung der Testin die IDE integriert. Ob ein Test erfolgreich ausgefuhrt wurde, wird visuell durch einen grunenHacken fur in Ordnung und einen roten Hacken fur fehlgeschlagen oder Fehler angezeigt.In diesem Projekt wurde JUnit eingesetzt um die Methoden der essentiellen Klassen zu uber-prufen. Bei den Methoden wurden das Verhalten und die Ruckgabe getestet. Auf den Codeder einzelnen Tests wird an dieser Stelle verzichtet. Stattdessen wird kurz erklart, welche derKlassen warum und worauf getestet wurden.Alle Container Klassen des Projektes wurden getestet. Die meisten Tests der Container sindziemlich simpel aufgebaut, da getestet wird, ob eine Menge an Informationen, die zum Con-tainer hinzugefugt wurden, auch wieder gleich herauskommen.Der Test der Klasse StoreableObjectsSet, die als Container fur die Fakten dient, war besonderswichtig. Wichtig beim Testen war es sicherzustellen, dass die Klasse thread-safe ist, da ne-benlaufig, von mehreren Threads Zugriffe stattfinden konnen. Um dies sicherzustellen, wurdenmehrere Threads gestartet, die nebenlaufig lesend und schreibend auf den Container zugreifen.Der Test schlagt fehl, wenn eine ConcurrentModification-Exception geworfen wird. Diese Ex-ception wird geworfen, wenn z.B. uber eine Collection iteriert wird und gleichzeitig ein Elementaus der Collection hinzugefugt oder entfernt wird.Die Builder Klassen wurden ebenfalls ausgiebig getestet, denn ein Fehler in diesen Klassenwurde bedeuten, dass entweder die Regel-Dateien falsch gelesen werden oder beim SchreibenFehler in den Dateien entstunden. Im ersten Fall ist es problematisch, dass ein Fehler un-ter Umstanden nicht direkt gesehen wird und erst beim Neuschreiben der Regelbasis auffallt.Durch Fehler beim Neuschreiben und Schreiben der Regelbasis ware der Server nicht mehreinsatzfahig. Der entstandene Fehler musste manuell auf dem Server durch Reparieren derRegelquelle behoben werden. Aus diesem Grund wurde die Klasse genauestens getestet undzusatzlich eine Backup Methode implementiert. Die Backup-Methode erstellt vor jedem Neu-schreiben eine Kopie der vorhandenen Regelquelle.

69

4 Test

4.2 Simulator

Um die Funktionsweise der Oberflache zu testen wurde ein Simulator geschrieben. Der Si-mulator dient dazu, die Interviewerkomponente des Servers zu simulieren. Deshalb benutztder Simulator die originalen Klassen des UnifiedXP-Kern und erganzt diese um eine ”fake“RuleBase. Durch den Simulator wird eine vollstandige Serverumgebung simulieren. Mit demSimulator kann das Verhalten auf beliebige Fakten getestet oder auch wahlweise ein Stresstestdurchgefuhrt werden.Der Simulator verfugt uber eine graphische Benutzeroberflache. Die Oberflache erlaubt es,die Member-Variablen eines Faktums beliebige Werte zu ubergeben, und dass so eingestellteFaktum zur Faktenbasis hinzuzufugen. Mit Hilfe dieser Funktion kann getestet werden, waspassiert, wenn Werte falsch gesetzt werden. Ein Beispiel ware, dass einzelne Wert eines Fak-tum gleich ”null“ sind. Zusatzlich ermoglicht diese Funktion einzelne Regeln zu testen, wodurchkontrolliert werden kann, ob ein gewunschtes Verhalten der Regeln ausgelost wird, sobald einFaktum hinzugefugt wird.Im Stresstest-Modus fugt ein Thread hochfrequent Fakten zur Faktenbasis hinzu und erzeugtdadurch Aktivierungen mit einer Abhangigkeit von einem oder mehreren Fakten. Ein ande-rer Thread loscht einzelne Fakten. Durch diesen Test soll das Verhalten bei großen Lastenuberpruft werden.Der Simulator wurde auch eingesetzt um die Anzeige der Wahrscheinlichkeit zu uberprufen.Dafur wurde ein Abbild eines Faktenbaumes erzeugt, wie es im Pixel Detektor vorkommt.Die Regelbasis wurde fur diesen Test um mehrere Testregeln erganzt. Die Regeln sind voneinem Temperatur-Modul und von einen Hochspannung Modul oder einem Optischen Modulabhangig sind. Die Abbildung 4.1 zeigt das Resultat des Testes. Im Resultat sieht man, dassdie beiden Testregeln die von den Fakten TModule und VMeas und von den Fakten TModu-le und TOpto abhangen die gleiche Wahrscheinlichkeit haben und den gleichen gemeinsamenVorhanger L2 B99 S1 C7.Status. Die andere Testregel ist nur von TModule abhangig. Daherwird wenn der Vorfahre L2 B99 S1 C7 M4C.Status ausgewahlt wird eine 100% Wahrschein-lichkeit fur die ”Temperature Rule“ angezeigt, siehe Abbildung 4.2.

70

4.2 Simulator

Abbildung 4.1: Test der Wahrscheinlichkeit Bild1

Abbildung 4.2: Test der Wahrscheinlichkeit Bild2

71

4 Test

72

5 Ausblick

Als Resultat dieser Bachelorarbeit steht eine robuste und modulare Software. Diese Softwareerfullt alle Anforderungen, die zu Beginn der Analyse gestellt wurden. Doch gibt es in jedenProjekt Ideen durch die eine Software noch funktionaller und bedienfreundlicher wird.Die nun folgende Zeilen beschreiben ein paar solcher Funktionen, die in einem spateren Ent-wicklungsstadium in den UnifiedXPClient eingebaut werden konnten.

Benutzerverwaltung In der momentanen Fassung des Programms gibt es zwei Arten vonBenutzern. Einen Administrator, der alles darf und einen normalen User, der nur einge-schrankt Feedback an den Server senden darf. Als eine Erweiterung ware es denkbar denClient mit einem Plugin auszustatten um neue Benutzer anzulegen und diesen Benutzernunterschiedlich viele Rechte zu zuweisen.

Erweiterter Regeleditor Mit dem enthaltenden Regeleditor ist es moglich, einfach neueRegeln anhand der vorhandenen Sprachschnipsel zu erstellen. In einer spateren Versionware es denkbar diesen durch einen gefuhrten Regeleditor auszutauschen. Mit diesemware es moglich eigene Sprachschnipsel zu erstellen ohne die Regelsyntax kennen zumussen. Der Editor fuhrt dafur den Benutzer durch ein Wizard und erstellt anhand derAuswahl ein DSL-Template, das danach von anderen Benutzern genutzt werden kann.

Frei definierbare Tags Wunschenswert ware es, in den Regeln frei definierbare Tags ein-setzten zu konnen: Tags, wie den Solution-Tag. Denkbar ware es diese Tags so zu de-finieren, dass diese mit einer Darstellung in der GUI verknupft werden. Man definiertbeispielsweise einen Tag Picture. Dieser wird so definiert, dass er einen Link zu einemBild ubergeben bekommt. Auf der GUI wird, wenn die Aktivierung angezeigt wird, diediesen Tag enthalt, das Bild erscheinen.

Austauschen einzelner Regeln In der jetzigen Version gibt es keine Moglichkeit einzelneRegeln wahrend der Laufzeit auszutauschen. Theoretisch wurde Drools diese Funkti-on ebenfalls unterstutzten. Deshalb ware es eine wunschenswerte Erweiterung, in einerspateren Version, das Austauschen und Neuladen einzelner Regeln zu implementieren.

Verifizieren von Regeln Eine interessante Vorstellung ware es den im Kapitel Test beschrie-benen Simulator als Plugin in eine Testumgebung einzupacken. Mit dieser Testumgebungkonnten Administratoren neue Regeln verifizieren.

73

6 Literaturverzeichnis

[ATL08] ATLAS: ATLAS Fact Sheet, 2008. Dokumentname: atlas factsheet 4.pdf.

[CER] CERN: GirdCafe. [Online; Stand 27. August 2008].

[CER08] CERN: LHC the guide, 2008.

[Dau05] Daum, Berthold: Professional Eclipse 3 for JavaTMDevelopers. John Wiley & SonsLtd, 2005.

[dB08] Buhr, Prof. Edzard de: Expertensysteme, mit Einfuhrung in Jess, 2008. Fach-hochschule Oldenburg/Ostfriesland/Wilhelmshaven.

[EG94] Erich Gamma, Richard Helm, Ralph Johnson John Vlissides: Design Pat-terns - Elements of Reusable Object-Oriented Software. Addison Wesley, 1994.

[Fei92] Feigenbaum, Edward Albert: Expert Systems: Principles and Practice, 1992.Dokumentname: KSL-91-79.ps.gz.

[IB] I. Boersch, J. Heinsohn, R. Socher: Wissensverarbeitung. Spektrum Akademi-scher Verlag, 2 Auflage.

[Jac] Jackson, Peter: Introduction to Expert Systems. Addison-Wesley Verlag.

[JM05] Jeff McAffer, Jean-Michel Lemieux: Eclipse Rich Client Platform: Designing,Coding, and Packaging JavaTMApplications. Addison Wesley Professional, 2005.

[MS] MATTHEW SCARPINO, STEPHEN HOLDER, STANFORD NG LAU-RENT MIHALKOVIC: SWT/JFace in Action. Manning Publications.

[Ver08] Verlaenen, Mark Proctor Michael Neale Michael Frandsen Sam Grif-fith Jr. Edson Tirelli Fernando Meyer Kris: Drools Documentation, 2008.[Online; Stand 27. August 2008].

[VG00] Volker Gruhn, Andreas Thiel: Komponentenmodelle. Addison Wesley, 2000.

[Wik08] Wikipedia: Expertensystem — Wikipedia, Die freie Enzyklopadie, 2008. [Online;Stand 27. August 2008].

[Wun] Wunderlich, Lars: Java Rules Engines. entwickler press.

xv

6 Literaturverzeichnis

xvi

Glossar

Analogieschluss Schlussfolgerung aufgrund einer Ahnlichkeit zwischenzwei Objekten

Distinguished Name Der Distinguished Name eines Zertifikats soll weltweiteindeutig sein. Er soll sicherstellen, dass es weltweit keinezwei Zertifikate gibt, die auf den gleichen Namen ausge-stellt sind.

Flag Binare Variable, welche als Hilfsmittel zur Kennzeich-nung bestimmter Zustande dient.

Framework Ein Programmiergerust

GUI (Graphical User Interface ) Grafische Benutzeroberflache einer Anwendung, manch-mal auch grafische Benutzerschnittstelle genannt.

Hadronen Teilchen das einer starkern Wechselwirkung untergebenist.

IDE Integrated Development Environment, ist ein Anwen-dungsprogramm spezialisiert auf die Entwicklung vonSoftware.

JavaBeans Eine spezielle Konvention um Datencontainer in Java zuerstellen.

Konklusion Schlussfolgerung

LCG LHC Computing GridLHC Large Hadron Collider

xvii

Glossar

LISP LISP ist eine funktionale Programmiersprache. Program-me bestehen in einer funktionalen Programmierspracheaus einer Menge von Funktionen.

Look & Feel Bezeichnet die von einem Hersteller oder Konsortiumstandardisierte Design-Aspekte

Member Variablen Attribute einer Klassen

Prompt EingabeaufforderungPramisse Bedingung, Aussage

RCP Rich Client Platform

SWT Standard Widget Toolkit

Wizards Wizard sind eine Serie von Formularen, die den Benutzerdurch eine komplexe Aufgabe fuhren.

XPS Expertensystem

xviii

Documents

Entwicklung einer Rich Client basierten GUI f ur Experten ...Basierend auf der JBoss Drools Regelmaschine wurde ein System gescha en, das es erlaubt die wichtigen Informationen und