Entwicklung einer Rich Client basierten GUI für Experten Systeme

Größe: px
Ab Seite anzeigen:

Download "Entwicklung einer Rich Client basierten GUI für Experten Systeme"

Transkript

1 Entwicklung einer Rich Client basierten GUI für Experten Systeme Abschlussarbeit zur Erlangung des akademischen Grades Bachelor of Science vorgelegt im Studiengang Angewandte Informatik des Fachbereiches Eletrotechnik und Informatik der Fachhochschule Münster von Dennis Huning Prüfer: Prof. Dr. rer. nat. Nikolaus Wulff Betreuer: Dipl. Physiker Tobias Henß Münster, 29. August 2008

2 Zusammenfassung Diese Arbeit behandelt das Thema der Programmierung einer grafischen Benutzeroberfläche für ein regelbasiertes Diagnosesystem das im wissenschaftlichen Umfeld eingesetzt wird. Basierend auf der JBoss Drools Regelmaschine wurde ein System geschaffen, das es erlaubt die wichtigen Informationen und das Wissen eines regelbasierten Diagnosesystems für Anwender abstrahiert und verständlich in einer grafischen Benutzeroberfläche zu präsentieren. Damit sich die Oberfläche möglichst optimal in diese Regelmaschine integriert, wurde untersucht wie Informationen und Wissen in der Maschine gespeichert werden und wie man an diese Informationen gelangt. Die Oberfläche des Diagnosesystems basiert auf der Eclipse Rich Client Plattform. Hierdurch war es möglich die Ergebnisse der Analyse in einzelne Anwendungsgebiete zu kapseln und diese als Plugins zu entwickeln. Die daraus resultierende Anwendung zeichnet sich durch ihre Modularität und Robustheit aus. i

3 ii

4 Danksagung Diese Zeilen möchte ich nutzen um mich bei allen, die mir bei dieser Arbeit geholfen haben, zu bedanken. Bei Prof. Dr. rer. nat. Nikolaus Wulff ohne seine Unterstützung wäre es mir nicht möglich gewesen dieses sehr interessante Projekt durchzuführen. Bei meinem Betreuer Dipl. Physiker Tobias Henß für seine hilfreichen konstruktiven Kommentare und die angenehme Arbeit. Bei meiner guten Freundin B.A. Yvonne Dönnebrink für das Korrekturlesen meiner Arbeit. Bei meinen Eltern und meiner Freundin für alles. Ihnen allen sei an dieser Stelle herzlich gedankt. iii

5 iv

6 Eidesstattliche Erklärung Hiermit versichere ich, dass ich die vorliegende Bachelor-Abschlussarbeit ohne Hilfe Dritter 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 ähnlicher Form keiner anderen Prüfungsbehörde vorgelegt und auch nicht veröffentlicht. Münster, 29. August 2008 Unterschrift v

7 vi

8 Inhaltsverzeichnis Zusammenfassung Danksagung Eidesstattliche Erklärung i iii v 1 Einleitung Motivation Zielsetzung Aufbau der Arbeit Einführung Expertensysteme Definition Expertensystemes/regelbasierte System Regelbasierte Systeme Die Eclipse Rich Client Plattform Warum ein Rich Client? Das Rich Client Plattform Konzept Eclipse Architektur Einführung in den Pixel Advisor Einführung in GridXP Einführung in UnifiedXP Entwicklung Allgemeines Auswahl der Regelmaschine Auswahlkriterien CLIPS JESS JBoss Drools Entscheidung Anforderungsanalyse der Benutzeroberfläche vii

9 Inhaltsverzeichnis Einleitung Anzeige von Fakten Anzeige von Lösungsstrategien Bewerten von Lösungsstrategien Änderung der Regelbasis Erstellen von Log-Dateien Unterschiedlich Sichten Ergebnis Interviewerkomponenten Funktionsweise des Pixel Advisors Funktionsweise GridXP Entwurf Architekturentwurf Entwurf der Faktenbasis Datenstruktur der Activations Entwurf Regeleditor Errechnung der Wahrscheinlichkeit Darstellung der Fakten in einer Baumstruktur Anzeigen von Lösungsstrategien Erstellen von Log-Dateien Implementierung Einleitung Implementierung des unifiedxpcore Plugins Implementierung des unifiedxpcore.utilities Plugins Implementierung des unifiedxpclient Plugin Implementierung des unifiedxpclient.network Plugin Implementierung des unifiedxpcore.ruleeditor Plugins Test JUnit Tests Simulator Ausblick 73 6 Literaturverzeichnis xv Glossar xvii viii

10 Abbildungsverzeichnis 2.1 Beispiel Entscheidungsbaum Komponenten eines XPS Schmema der Vorwärtsverkettung [IB] Eclipse Architektur SWT Event Modell [Dau05] SWT Widget Klasse [MS, Seite 30] JFace Event Model [Dau05] PVSS Datenpunkt Die vier Layer des Grids [CER] Abstrakte Architektur der UnifiedXP Software Vorgehensmodell CLIPS-Regel Drools Regel mit DRL-Syntax Drools Regel mit DSL Templates Beispiel: Erster Gemeinsamer Vorfahre - Algorithmus Klassendiagramm der Datenstruktur UnifedAgendaListener StrategyCertainCommonFact RuleBaseBuilder Schlüsselwörter eines Paketes [Ver08] Schlüsselwörter einer Regel [Ver08] DRL-Datei Builder Klassendiagramm ProbabilityStrategy Komponenten Diagramm der UnifiesXPClient Plugins Pakete des Kern Plugins Klassendiagramm des Utilities Plugins Klassendiagramm des UnifiedXPClient Plugins Aussehen der fertigen FaktView Klassendiagramm der FaktView Die verschiedenen Icons der TreeView Scheme des Selection Services ix

11 Abbildungsverzeichnis 3.22 Klassendiragramm des Network-Plugins Typischer Verbindungsaufbau Login Dialog Aussehen des fertigen Regeleditors Menü des Regellisten Fensters Klassendiagramms des Regeleditors Test der Wahrscheinlichkeit Bild Test der Wahrscheinlichkeit Bild x

12 1 Einleitung 1.1 Motivation Wissenschaftliche Experimente und Computersysteme werden in der heutigen Zeit immer komplexer. Für das betroffene Wartungspersonal ist es kaum noch möglich das ganze System zu überblicken. Kommt es dann zu einem Problem, ist die Suche nach einer Lösung meist ein nervenaufreibender und langwieriger Prozess. Häufig entstehen auch Situationen in der sich Fehler wiederholen, doch das Wartungspersonal, das die Lösung zu dem wiederholt auftauchendem Problem kennt, ist nicht verfügbar. So kommt es erneut zu der Suche nach einer Lösung für ein Problem, das als gelöst gilt. Beispiel eines solchen Systems ist der Large Hadron Collider (LHC), mit dessen Hilfe Physiker die Geheimnisse unseres Universum entdecken möchten. (Eine genauere Beschreibung folgt im anschließenden Kapitel.) An diesem Experiment arbeiten mehrere tausende Wissenschaftler und Ingenieure Hand in Hand. Kein einziger von diesen Wissenschaftlern und Ingenieuren ist in der Lage die Ausmaße des gesamten Systems zu überblicken. Trotz dieser Eigenschaft muss ein reibungsloser Ablauf garantiert werden. Aus diesem Grund soll ein Expertensystem (XPS) verwendet werden, das das Wartungspersonal bei ihrer Arbeit unterstützen soll. Dafür verfügt das XPS über eine Wissensbasis, die mit Expertenwissen gefüllt ist, und eine Faktenbasis mit Informationen über das System. Die Informationen werden von dem XPS mit Hilfe der Wissensbasis ausgewertet. Bei einem Problem kann das Expertensystem, falls Wissen über das Problem vorhanden ist, dieses Problem erkennen und eine Lösung anzeigen. Die Wissensbasis ist das Kapital eines XPS, denn nur ein XPS mit viel Wissen kann hilfreich sein. Daher liegt es auf der Hand, dass die richtige Präsentation der Informationen eines Systems und die Erhebung von neuem Wissen sehr wichtig ist. Deswegen gehört die Benutzeroberfläche zu einem der wichtigsten Komponenten eines XPS. 1.2 Zielsetzung Damit Lösungen zu Problemen angezeigt werden können, muss das XPS über eine Benutzeroberfläche verfügen. Die Entwicklung einer Benutzeroberfläche für ein XPS ist Ziel dieser 1

13 1 Einleitung Arbeit. Damit sich die Benutzeroberfläche in ein XPS integrieren kann, ist es wichtig ein solches System zu analysieren und die Vorgänge zu verstehen. Aus diesem Grund wurde viel Zeit mit der Analyse eines solchen Systems, verbracht. Aufgabe der Oberfläche soll es sein, dem Wartungspersonal einen schnellen Überblick über den Zustand des Systems zu geben. Zu diesem Überblick gehört die Anzeige von Fehlern, Fakten und des Wissens. Da ein XPS nur helfen kann, wenn die Wissensbasis über viel Wissen verfügt, muss die Oberfläche über eine Funktion zum Erheben des Wissens verfügen. Die Oberfläche soll möglichst modular aufgebaut sein. Einzelne Teile sollen ohne viel Aufwand ausgetauscht werden können. Aus diesem Grund wird als Unterbau der Oberfläche die Eclipse Rich Client Plattform eingesetzt werden. 1.3 Aufbau der Arbeit In dem ersten Kapitel Einführung werden die Begriffe und Systeme, die in dieser Arbeit benutzt werden, erklärt. Hierfür wird erläutert was ein Expertensystem ist, aus welchen Komponenten es besteht, warum eine Rich Client Plattform eingesetzt wird und die Besonderheit dieser Plattform. Zusätzlich wird eine Einführung in die Projekte Pixel Advisor, GridXP und UnifiedXP gegeben. Der ersten Teil des Kapitels Entwicklung geht auf die Analyse der Software ein. In diesen Abschnitten wird geklärt welche Anforderungen an die Benutzeroberfläche gestellt werden, um in den anschließenden Abschnitten den Entwurf des Datenmodells erläutern zu können. Abschließend wird auf die Implementierung der einzelnen Anforderungen als Rich Client Plugins eingegangen. Das Kapitel Test beschreibt wie vorgegangen wurde um die Funktion der Klassen und der gesamten Software zu testen. Im Kapitel Ausblick wird ein Überblick über interessante Features gegeben, die eine spätere Version dieser Software erweitern könnten. 2

14 2 Einführung 2.1 Expertensysteme Definition Expertensystemes/regelbasierte System Ein Expertensysteme (XPS) erlaubt es auf Grundlage einer Wissensbasis, Probleme eines Fachgebietes zu lösen und so Entscheidungen eines Experten zu simulieren [Jac]. Dabei wird das Expertenwissen über einen Wissens-Ingenieur (knowledge engineer) oder einer für Laien benutzbaren Schnittstelle in eine maschinell auswertbare Form transformiert. Das Expertenwissen wird vom Fachpersonal des Einsatzgebietes hinzugefügt. In der Regel ist das Expertenwissen nicht in Büchern oder Manuskripten vorhanden, sondern existiert nur in den Köpfen derjenigen, die jahrelange Erfahrungen über ein System gesammelt haben. Die Art, wie in Expertensysteme das Wissen dargestellt und wie eine Schlussfolgerung getroffen wird, kann durch unterschiedliche Modelle realisiert werden [Wik08][IB]: Fallbasierte Systeme (case-based reasoning ) Bei den fallbasierten Systemen wird versucht Problemstellungen durch Analogieschluss auf schon gelöste Probleme zurückzuführen. Beispiel: A hat Ähnlichkeit mit Problem B und A wurde durch C gelöst. Dann kann auch B durch C gelöst werden. Hauptbestandteil dieses Systems ist die Fallbasis, in der gelöste Probleme als Fälle vorhanden sind. Ein solcher Fall besteht mindestens aus einer Problembeschreibung und einer Problemlösung. Entscheidungsbäume Systeme die auf Entscheidungsbäumen basieren, versuchen eine passende Lösungsstrategie über das divide and conquer-prinzip zu finden, frei nach dem Motto: Ich weiß nicht wie ich das ganze Problem in eins löse, aber vielleicht kenne ich eine Strategie, Teilprobleme zu lösen. Es wird versucht ein Problem in viele kleiner Teilprobleme zu zerlegen. Diese Teilprobleme stellen die Knoten eines Baumes da. Die vom Knoten ausgehenden Kanten sind die Ausprägungen. Kann man nun die Knoten von der Wurzel bis zu einem Blatt verfolgen, wurde eine Lösung gefunden. Die Abbildung 2.1 soll dieses Modell verdeutlichen. Das Problem in diesem Beispiel ist die Frage, ob das Wetter es zulässt joggen zu gehen. Als Objekt liegt die Wettervorhersage, mit den Attributen Temperatur und Windstärke vor. Es wird nun versucht einen Pfad in dem Baum von der Wurzel bis zu einem Blatt zu finden. Entscheidungsbäume können auch zum Erheben 3

15 2 Einführung neuer Regel genutzt werden. Angenommen es ist sonniges Wetter und die Temperatur ist normal, dann würde daraus eine neue Regel entstehen, die lautet: Wenn Vorhersage gleich sonnig und Temperatur gleich normal ist, dann kann man joggen gehen. Abbildung 2.1: Beispiel Entscheidungsbaum Regelbasierte Systeme Sind die häufigste Realisierung von Expertensystemen. In regelbasierten Systemen liegt das Expertenwissen in Form von Regeln vor. Die Regeln werden von Experten direkt in das System eingegeben und sind nur für eine konkrete Situation gültig. Expertensysteme werden für die unterschiedlichsten Einsatzgebiete benutzt. Typische Aufgabenklassen für Expertensysteme sind (in Klammern sind die Namen einiger realisierter Expertensysteme zu sehen) [Wik08] [Fei92]: Dateninterpretation Analyse von Daten mit dem Ziel einer Zuordnung zu Objekten oder Erscheinungen, insbesondere Signalverstehen. Beispiele: Erkennung akustischer Sprache (HEARSAY), Identifizierung chemischer Strukturen anhand von Massenspektrometerdaten (DENDRAL), geologische Erkundung (PROSPECTOR), Proteinstrukturbestimmung aus Röntgendaten, Erdölbohrung, militärische Aufklärung, U-Boot-Ortung (SEPS, STAMMER). Überwachung Interpretation von Daten mit Aktionsauslösung in Abhängigkeit vom Ergebnis. Beispiele: Produktionssicherung, Überwachung von Patienten in der eisernen Lunge (VM), Überwachung eines Kernreaktors (REACTOR). Diagnose Interpretation von Daten mit starker Erklärungskomponente. Beispiele: vielfältig in der Medizin, zum Beispiel bei bakteriellen Infektionen (MYCIN), Rheumatologie, innere Medizin (INTERNIST), Pflanzenkrankheiten; außerdem zur Bestimmung und Lokalisation von Fehlern in technischen Systemen. 4

16 2.1 Expertensysteme Therapie Aktionen zur Korrektur fehlerhafter Systemzustände und Beseitigung der Ursachen (oftmals mit Diagnose gekoppelt). Beispiele: siehe Diagnose, Fehlerdiagnose im Autogetriebe (DEX), Fehlerortung und Wartung bei Telefonnetzen (ACE), automatische Entwöhnung von Beatmungspatienten in der Intensivmedizin (SmartCare/PS). Planung Erzeugen und Bewerten von Aktionsfolgen zur Erreichung von Zielzuständen: Beispiele: Versuchsplanung molekulargenetischer Experimente (MOLGEN), chemische Synthese (SECS), Finanzplanung (ROME), Produktionsplanung (ISIS), Steuerung des Flugbetriebs auf Flugzeugträgern (CAT), Handlungen autonomer Roboter (NOAH), beispielsweise Marsroboter. Entwurf Beschreibung von Strukturen, die vorgegebenen Anforderungen genügen. Beispiele: unter anderem für Schaltkreisentwurf (SYN, DAA), Computerkonfiguration (R1/XCON), chemische Verbindungen (SYNCHEM), Konfiguration von Betriebssystemen bei Siemensrechnern (SICONFEX). Prognose Vorhersage und Bewertung erreichbarer Zustände zeitvarianter Systeme. Beispiele: Beurteilung von Erdbebenauswirkungen (SPERIL), Erdbebenvorhersage, Hochwasservoraussage, Umweltentwicklung (ORBI) In dieser Arbeit wird ein regelbasierten System eingesetzt. Aus diesem Grund wird im nächsten Abschnitt auf die Besonderheit dieser Realisierungsart eingegangen Regelbasierte Systeme Definition einer Regel Eine Regel definiert eine Anweisung auf Basis von Aussagen und Logik [Wun]. Regeln werden meistens durch wenn - dann Sätze definiert. Wenn Temperatur der CPU wärmer als 50 Grad, dann schalte die Kühlung ein. Regeln bestehen aus dem eindeutigen Regelnamen, um eine Regel zu identifizieren. Bedingungsteil (wenn) wird auch als Left Hand Site (LHS) bezeichnet und kann aus einer oder mehreren Prämissen bestehen. Prämissen sind miteinander logisch verknüpft und führen über Konklusion zu einer oder mehreren Aktionen. Konsequenzteil (dann) einer Regel wird auch als Right Hand Site (RHS) bezeichnet und kann aus einer oder mehreren Aktionen bestehen. 5

17 2 Einführung Aufbau eines Regelbasierten Expertensystemes Abbildung 2.2: Komponenten eines XPS Die Abbildung 2.2 zeigt vereinfacht die einzelnen Komponenten und die Kommunikation zwischen den Komponenten eines regelbasierten Expertensystems[IB, Seite 6ff]. Die einzelnen Komponenten haben folgende Bedeutung: Regelmaschine (Inference Engine) Die Regelmaschine oder auch Inferenzmaschine leitet durch Schlussfolgerung (Inferenz) neue Aussagen (Konsequenz) aus der Wissensbasis ab. Die Regelmaschine ist der Motor eines Expertensystems. Wissensbasis (Knowledeg Base) Die Wissensbasis enthält das gesamte Wissen über einen speziellen Anwendungsbereich (Domain Specific Knowledge). Alle XPS verfügen über eine Wissensbasis. Doch nur wenn das Wissen in Form von Regeln abgebildet wird, spricht man von einem regelbasierten Expertensystem. Die Wissensbasis wird bei regelbasierten Systemen häufig in Faktenbasis und Regelbasis unterteilt. In der Faktenbasis oder auch Working Memory genannt, werden die Fakten hinterlegt, die zum Auswerten einer Regel führen. Fakten stellen die kleinste Einheit von Informationen da. Fakten können zur Faktenbasis hinzugefügt oder entfernt werden. Die Regelbasis enthält das Expertenwissen. 6

18 2.1 Expertensysteme Benutzeroberfläche (User Interface) Die Benutzeroberfläche kann in mehrere einzelne Komponenten aufgeteilt werden. Sie sollte aber mindestens über eine Erklärungskomponente verfügen, die die Vorgehensweisen des Expertensystems transparent darstellt. Die Erklärungs-Komponente gibt dem Benutzer die Möglichkeit getroffene Problemlösung zu hinterfragen oder Fehler in der Logik zu entdecken. Ein weiterer Bestandteil der Benutzeroberfläche ist die Wissenserwerbs-Komponente, die es Fachexperten ermöglicht neues Wissen für das XP-System zu definieren. Die Interviewer-Komponente Dient der Beschaffung von Informationen. Diese Informationen können direkt vom Benutzer kommen oder aber automatisch erhobene Messdaten sein. Falls die Daten durch einen Dialog mit dem Benutzer erhoben wurden, spricht man von einem interaktiven System. Werden die Daten automatisch durch eine an das System angeschlossene Datenbeschaffungs-Komponente erhoben spricht man von einem eingebetteten System. Aktivierungen und Feuern einer Regel Eine Regel wird als aktiviert bezeichnet, wenn alle die Prämissen des Bedingungsteils den Wahrheitswert true (wahr) ergeben. Um zu prüfen ob eine Prämisse den Wahrheitswert true erfüllt, bedarf es Informationen aus der Faktenbasis, die in Kombination mit der Regel von der Inferenzmaschine ausgewertet wird [Wun]. Fakt: CPU-Temperaturfühler misst 55 Grad Prämisse: Temperatur der CPU wärmer als 50 Grad ist erfüllt Konsequenz: schalte Kühlung ein ist auszuführen Im oberen Beispiel ist der Bedingungsteil der Regel durch das Faktum Temperaturfühler misst 55 Grad aktiviert worden. Der Konsquenzteil wird allerdings erst ausgeführt, wenn die Regel feuert. Das Ausführen des Konsequenzteils, wird als feuern bezeichnet. Bei dem Auswahlmechanismus, welche Regel als nächstes aktiviert wird, unterscheidet man zwischen datengetrieben (forward chaining) und zielgetrieben (backward chaining) [IB]. Bei der datengetriebene Auswahl oder Vorwärtsverkettung wird auf Grundlage von Fakten versucht eine Diagnose zu treffen. Um diesen Zweck zu erfüllen, wird eine Regel aus der Menge der aktiven Regeln ausgewählt und deren Aufführungsteil ausgeführt. Die Menge der aktiven Regeln wird als Konfliktmenge bezeichnet. Durch das Feuern der Regel kann die Datenbasis verändert werden, wodurch vorherige Aktivierungen verloren gehen können oder neue Aktivierungen hinzukommen. Dieser Vorgang wird solange wiederholt bis keine Aktivierung mehr vorliegt oder eine Diagnose getroffen wurde. Bei der zielgetriebenen Auswahl oder Rückwärtsverkettung versucht man eine vorliegende Hypothese bzw. Anfrage zu bestätigen. Wenn kein Faktum vorhanden ist um die 7

19 2 Einführung Hypothese zu beantworten, wird versucht eine Regel zu finden deren Konklusion die Hypothese darstellt. Ordnung (Salience) Wie bereits oben erwähnt, kann durch das Feuern einer Regel die Faktenbasis verändert werde. Die Änderung der Faktenbasis führt zwangsläufig zu einer neuen Auswertung der Regeln, wodurch aktivierte Regeln zurückgezogen werden können. Normalerweise wird die Regel, die als erstes aktiviert wurde, auch als erstes gefeuert. Um auf die Reihenfolge, in der Regeln gefeuert werden, Einfluss nehmen zu können, wird von den meisten Ruleengine die Option salience bereitgestellt. Der Wert der salience gibt die Reihenfolge des Feuerns an. Die Regel mit dem höchsten salience Wert wird als erstes gefeuert. Schleifen Bei der Vorwärtsverkettung läuft die Interpretation der Regeln in einer Schleife ab, siehe Abbildung 2.3. Dies kann zu Problemen führen, wenn das Faktum, das zum Feuern einer Regel geführt hat, nach dem Feuern immer noch vorhanden ist. Da es immer noch vorhanden ist, gehört auch die Regel, die vorher gefeuert hat, wieder zur Konfliktmenge. Wie man anhand der Abbildung 2.3 erkennt, würde diese Situation zu einer Schleife führen, Abbildung 2.3: Schmema der Vorwärtsverkettung [IB] da immer wieder die gleiche Regel ausgeführt wird. Verhindt werden soll das Entstehen von Schleifen durch das Refraktionsprinzip [IB]. Refraktionsprinzip heißt: Keine Regel darf zweimal 8

20 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 der Regel auf diesen Zustand. Die meisten regelbasierten XP-Systeme verfügen über ein Flag, das in der Regel gesetzt werden kann. Das Setzen dieses Flags veranlasst die Regelmaschine dazu diese Regel nicht auf den selben Zustand ein weiteres Mal anzuwenden. 2.2 Die Eclipse Rich Client Plattform Warum ein Rich Client? Die RCP ermöglicht es einem Entwickler sich auf seine Kernaufgabe zu konzentrieren, nämlich das Entwickeln einer Geschäfts- oder Anwendungslogik. Durch die Verwendung einer RCP ist man 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 Modulen, Features oder Plugins. Zwar bedarf es einer gewissen Einarbeitungszeit bis man sich an die Eigenschaften der jeweilige RCP gewöhnt hat, doch ist man erst einmal eingearbeitet, kann man mit Hilfe der RCP eine mächtige und modular aufgebaute Anwendung entwerfen Das Rich Client Plattform Konzept Um die Arbeit eines Entwicklers zu erleichtern, verfügt eine RCP über standardisierte Komponenten wie Hilfe System, Docking-System, vordefinierte Dialoge, Wizards und einen Update- Manager. Das Docking-System kümmert sich um das Layout der einzelnen Fenster der Applikation. Die einzelnen Fenster können dadurch beliebig in ihrer Größe verändert, verschoben, minimiert, maximiert und ineinander gestapelt werden. Modularität ist ein Kernkonzept jeder RCP. Jede RCP ist durch Module oder Plugins erweiterbar. Jedes Modul kapselt einen gewissen Aufgabenbereich in sich. Zwischen den Modulen existiert nur eine lose Kopplung. Sehr häufig wird die Verbindung zwischen Abhängigkeiten von Modulen dadurch hergestellt, dass ein Modul einen Service anfordert und ein anderes Modul einen Service anbietet. Die Zuordnung von Services übernimmt ein Plugin Manager. Der Ausdruck Rich Client soll den Unterschied zum Thin Client verdeutlichen, denn das Gegenteil eines Rich Clients ist ein Thin Client. Die Aufgabe eines Thin Clients ist die Einund Ausgabe von Daten. Die auszugebenden Daten werden meist komplett von einem Server 9

21 2 Einführung geliefert. Daher sind Thin Clients, nur verbunden mit einem Server, funktionsfähig. Im Gegensatz dazu verfügt der Rich Client über Intelligenz, die diesen auch offline betriebsfähig macht Eclipse Architektur Die Abbildung 2.4 gibt nur einen sehr abstrakten Überblick über die Eclipse Architektur. Allerdings ist der bausteinförmige Aufbau klar zu erkennen. Fast jeder der Blöcke stellt ein eigenständiges Plugin da. Die Plugin Architektur spielt bei Eclipse eine große Rolle, denn selbst die Eclipse Entwicklungsumgebung ist eine hoch funktionale Rich Client Anwendung und basiert auf einer Menge an Plugins [JM05]. Aufbauend auf die Plattform der Entwicklungs- Umgebung ist das Eclipse Software Development Kit (SDK) mit den Tools für die Java und Eclipse 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

22 2.2 Die Eclipse Rich Client Plattform OSGi-Standart entwickelt wurde. OSGi (früher Open Services Gateway initiative) ist eine Softwareplattform Spezifikation der OSGi-Alliance, die es erleichtert Anwendungen und ihre Dienste nach dem Komponentenmodell zu modularisieren und zu erweitern. Für das Komponentenmodell findet man folgende Beschreibung [VG00, Seite 293]: Ein Komponentenmodell legt einen Rahmen für die Entwicklung und Ausführung von Komponenten fest, der strukturelle Anforderungen hinsichtlich Verknüpfungsbzw. Kompositionsmöglichkeiten sowie verhaltensorientierte Anforderungen hinsichtlich Kollaborationsmöglichkeiten an die Komponenten stellt. Darüber hinaus wird durch ein Komponentenmodell eine Infrastruktur angeboten, die häufig benötigte Mechanismen wie Verteilung, Persistenz, Nachrichtenaustausch, Sicherheit und Versionierung implementieren kann. Das dynamische Modul-Konzept von OSGi mit dem flexiblen Versions- und Abhängigkeitsmanagement stellt wahrscheinlich das wichtigste Feature für den Rich-Client da. Jedes Eclipse Plugin ist ein Module und wird in OSGi als Bundle bezeichnet. Jedes Bundle kann von anderen Bundles abhängen. Die Abhängigkeit kann sehr genau versionsbedingt bestimmt werden. Es ist sogar möglich innerhalb einer Anwendung Abhängigkeiten zu verschiedenen Versionen eines anderen Bundles simultan zu benutzen. Das kleinste Ganze in einer Rich Client Anwendung ist ein Plugin. Jedes Plugin enthält die Datei META-INF/MANIFEST.MF und optional eine plugin.xml. Diese definieren das Verhalten zu anderen Plugins. Verfügt ein Plugin über aktives Verhalten, besitzt es zusätzlich zu den Konfigurationsdateien einen Activator. Diese Klasse dient als Ressourcen Speicher für das Plugin und kontrolliert den Lebenszyklus des Plugins. Bei der Aktivierung des Plugins wird die von AbstractUIPlugin geerbte Methode start() gerufen. Damit die Methode gerufen wird muss der Activtor in der MANIFEST.MF als Bundle-Activator eingetragen werden. Das Manifest spezifiziert das Startverhalten für das OSGi eines Plugins. Dies ermöglicht es die Plugin erst dann zu laden, wenn sie auch benötigt werden (Lazy Loading). Die Datei plugin.xml enthält alle Extensions und Extension-Points des Plugin. Die Extension-Points werden definiert, damit andere Plugins das gewünschte Verhalten des Extension Points ergänzen können. Ein Extension Point basiert zum Beispiel auf ein im Plugin enthaltendes, Interface oder einer Klasse. Extensions sind die Implementierungen gegen die Extension Points. Sie erweitern die Plattform um ein gewünschtes Verhalten, z.b. dient die Extension actionsets dazu die im Plugin enthaltenden Actions zu den Menüs und Toolbars hinzu zufügen. In Eclipse wird generell gegen Interfaces programmiert. Alle Interfaces fangen in Eclipse mit I an. Zum Bearbeiten der beiden Dateien MANIFEST.MF und plugin.xml enthält die Eclipse das Plugin Development Environment (PDE), einen speziellen Formular basierten Editor. Der Editor ermöglicht eine einfache Beschreibung der Funktionen, die das Plugin haben soll. Die Eclipse Plattform enthält eine Reihe weiterer Komponenten, siehe Abbildung 2.4, wie 11

23 2 Einführung ein Hilfesystem, einen Update Manager und dem International Component for Unicode (ICU). ICU ist ein sehr nützliches Tool um eine Anwendung zu lokalisieren bzw. zu internationalisieren. Es lässt sich auf eine Klasse anwenden und extrahiert vollautomatisch die in der Klasse definierten Texte in eine Text-Datei. In der Klasse werden die Strings durch eine Anfrage an ein 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 man nicht 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 sondern das eigens für die Eclipse Plattform entwickelte SWT (Standard Widget Toolkit) eingesetzt. SWT ist eine von IBM entwickelte Grafikbibliothek. Im Gegensatz zu Swing versucht SWT die nativen Betriebssystem GUI 1 -Komponenten zu benutzen, wodurch SWT basierte Anwendungen automatisch das bestmögliche Look & Feel erhalten. Zusätzlich ist es schneller und ressourcenschonender als Swing. Der Nachteil daran besteht darin, dass SWT nicht Plattformunabhängig ist. Für jedes Betriebssystem, auf dem eine SWT basierte Anwendung laufen soll, muss es eine SWT-Implementierung geben. Zurzeit sind auf der Website von Eclipse 2 13 Implementierungen für verschiedene Betriebssysteme vorhanden. Auch müssen die angeforderten Ressourcen in SWT selbst verwaltet werden. Sie werden nicht wie bei Java üblich von der Garbage Collection aufgeräumt. Deshalb verfügt jedes Widget über 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 repräsentiert den UI-Thread in der die SWT-Oberfläche läuft und verbindet die Java Anwendung mit dem BS. Sie delegiert jeden Benutzeraufruf aus dem BS zum angesprochenem Widget. Um von einem anderen Thread Veränderungen an der GUI durchzuführen, muss die Aktion in eine Runnable gekapselt werden. Die gekapselte Aktion wird dann an den UI-Thread übergeben. Den UI-Thread erhält man über die statische Funktion getcurrent() oder get- Default() an der Display Klasse. An die Methoden syncexec() und asyncexec() kann die Runnable übergeben werden. Sobald sich eine Möglichkeit ergibt, wird dann die run-methode des Runnables von dem UI-Thread ausgeführt. 1 Display. getcurrent (). asyncexec ( new Runnable () { 1 GUI = Graphical User Interface 2 12

24 2.2 Die Eclipse Rich Client Plattform 3 public void run () { 4 button. settext (" Hello World!") ; 5 } 6 }); Die Klasse Display hat im Gegensatz zur Klasse Shell keine visuelle Implementierung. Durch die Shell-Klasse werden in SWT Fenster repräsentiert. Die primäre Aufgabe der Shell ist die Bereitstellung eines allgemeinen Verbindungspunktes für die Container, Widgets und Events der Oberfläche. Daher dient die Shell als Vorfahre für alle Komponenten. SWT kennt zwei Arten von Shell: Top-Level Shell haben das Display als Vorfahre und werden gebraucht um das Hauptfenster der Anwendung zu entwerfen. Dialog-Shells haben keinen Verweis auf einen Vorfahren und sind der Top-Level Shell untergeordnet. Die Kommunikation mit den GUI-Komponenten wird über das SWT-Event-Model hergestellt, siehe Grafik 2.5. Die Methode readanddispatch() der Display-Klasse durchsucht die Nachrichtenwarteschlange des BS auf, für 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 für welches GUI- Widget die Nachricht bestimmt ist und leitet das Event an das Widget weiter. Das GUI-Widget informiert ihre Listener über das Event und ruft die Event-Handling-Methode des implementierten Interfaces auf. Für jede Art von Event gibt es ein anderes Interface, das von einem Listener implementiert werden muss. Das Interface beschreibt wie der Listener zu reagieren hat. Für jedes Interface gibt es einen Adapter. Der Adapter ist eine Klasse, die alle Methoden eines Interfaces implementiert, aber kein Verhalten hat. Ein Adapter erleichtert einem Programmierer die Arbeit, denn der Programmierer muss nur die Methode überschreiben an dessen Aufruf er interessiert ist. Alle Event Klassen verfügen über mehrere öffentliche (public) Member-Variablen, wie Quelle 13

25 2 Einführung und Type. Diese Variablen dienen dazu die Events zu beschreiben. SWT bietet wie jede Grafikbibliothek eine Vielzahl fertiger UI-Widgets. Die Abbildung 2.6 gibt einen Überblick über die verschiedenen Widgets. SWT bietet eine Menge an Vorzügen gegenüber Swing an. Doch Abbildung 2.6: SWT Widget Klasse [MS, Seite 30] besitzt es auch seine Schattenseiten. Gerade die Plattform Unabhängigkeit ist ein großer Vorteil von Swing. Damit SWT noch attraktiver wird, haben die Entwickler von SWT das JFace UI-Toolkit entwickelt. JFace JFace fügt dem SWT eine Reihe an UI-Entwicklungshilfsmittel hinzu. Dabei vereinen die JFace Komponenten die Struktur und die Präsentation eines UI-Widgets, um eine Menge an wiederverwendbaren Komponenten bereitzustellen, die die Entwicklung einer Java basierten Oberfläche erleichtern soll. Im JFace Toolkit sind Komponenten wie Image und Font Registrierung, Dialogen, Frameworks für Eingenschafts-Seiten, Wizards, Viewer, Actions und Fortschrittsanzeige für 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 möglich. Hierzu benutzt es die beiden Klassen ContentProvider und LabelProvider, die sich darum kümmern, welche Daten des Domain-Modells wie angezeigt werden. Der LabelProvider weiß wie (welcher Text und welches Image) ein Element des Modelles angezeigt werden muss. Der ContentProvider kennt das Modell und weiß, welches Element angezeigt werden muss. Zusätzlich implementiert es einen Lazy-Loading Mechanismus für nicht sichtbare Element. So werden Elemente, 14

26 2.2 Die Eclipse Rich Client Plattform die nicht sichtbar sind, erst erstellt, wenn diese angefordert werden. Im Gegensatz zum SWT Event-Modell, wo das Listener Verhalten immer für eine bestimmte Art von Komponente entworfen wird, (Zwar ist es möglich einen allgemeinen Listener zubenutzen, doch muss im Verhalten des allgemeinen Listener festgestellt werden, von welcher Komponente der Aufruf kam.) benutzt JFace, um eine höhere 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), der sich um die Repräsentation und um das Delegieren von Events im GUI Fenster sorgt und einem anderen Teil (Action), der sich um die Event-Verarbeitung kümmert. Die SWT-Events wurden durch Actions ersetzt. Actions können für jede Art von Komponente als Verhalten eingesetzt werden. Contribution kombinieren den Event-Listener und das GUI-Widget. Allerdings ist das JFace Event-Model nicht für alle Widget konzipiert, sondern nur für Buttons, Toolbar und Menus. Der Sinn hinter der JFace Event Verarbeitung ist es die am häufigsten auftretenden Events zu verallgemeinern und dadurch wiederverwendbarer zu machen. JFace vereinfacht durch seine UI-Komponenten eine Vielzahl von Vorgängen der Oberflachenprogrammierung. Die beiden Komponenten Viewer und Action sind die beiden, die in diesem Projekt die häufigste Anwendung finden. Alle Vorteile zu nennen würde den Rahmen dieser Arbeit sprengen, deswegen wird an dieser Stelle auf das JFace FAQ 3 verwiesen. Workbench Für den Benutzer ist die Workbench nur eine Ansammlung von Fenstern, die in einem Workbench Window angezeigt werden. Einzelne Fenster sind in Eclipse Views oder Editors. Der Unterschiede zwischen View und Editors sind: 3 Official Eclipse FAQs#JFace 15

27 2 Einführung In einem Workbench Window befindet sich i.d.r. nur eine Instanz derselben View, aber es können sich mehrere Instanzen desselben Editors befinden. Editors werden nur in der Editor-Area angezeigt und können nicht so wie Views an jedem Bereich des Workbench Windows geschoben werden. Editors implementieren das ISaveablePart Interface, das die Methoden-Signaturen für den integrierten Save-Mechanismus enthält. Bei Editoren deren Inhalt verändert wurde, wird das dirty-flag gesetzt. Hierdurch erkennt die Workbench, dass der Inhalt gespeichert werden muss bevor der Editor geschlossen wird. Beim Speichern wird durch die Implementierung des Interfaces von der Workbench automatisch die richtige Methode gerufen. Editors verfügen über keine eigene Toolbar sowie Views. Schaltflächen der Editors werden zur Workbench Window Toolbar hinzugefügt Editors sind nur für eine vordefinierte Eingabequelle gültig, z.b. Textdateien. Workbench Windows bestehen aus einer Titelleiste mit Schaltflächen für die Änderung der Größe und zum Schließen des Windows, der Menüleiste, der CoolBar (Toolbar), Fast-View (Short cut bar) Leisten und im unteren Bereich befindet sich die Statusleiste. Die CoolBar ist eine andere Bezeichnung für die Werkzeugleiste. In der Statusleiste befindet sich integriert eine Fortschrittsanzeige für langlaufende Prozesse. Die Statusleisten und Cool Bar können wahlweise deaktiviert werden. Der Hauptteil des Workbench Windows ist die Workbench Page die 0 oder mehr Views und/oder 0 oder mehr Editors enthalten kann. Das Layout verschiedener Views 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 Größe zu ändern, zu verschieben, zu gruppieren, aus diesen Fast-View zu erstellen und diese aus der Workbench heraus zu ziehen. Die Fast-View ist ein Fenster, das als Shortcut an die Seite geschoben wurde und wenn es ausgewählt wird, über den Zeitraum in der es den Fokus behält, angezeigt wird. Durch das Umschalten zwischen einer Perspective kann sich das ganze Verhalten einer Workbench ändern. Ein Beispiel wäre: In der einen Perspective hat man das Verhalten und Aussehen eines Java Editors und entwickelt Java Programme - in der anderen hat man eine PIM- Anwendung (Personal Information Manager) und kümmert sich um seine Geschäftskontakte. 2.3 Einführung in den Pixel Advisor Pixel Advisor ist ein XPS welches an der Universität Wuppertal in der Arbeitsgruppe Teilchenphysik von Prof. Mättig entwickelt wird. Geleitet wird das Projekt von dem Doktorand Tobias Henß. Ziel ist es, durch das Programm, eine Hilfestellung für Schichtarbeitern bei Fehlern im 16

28 2.3 Einführung in den Pixel Advisor Pixel Detektor zu bieten. Der Pixel Detektor ist ein Spurdetektor auf Basis von Halbleitern und dient unter anderem zur Impulsmessung von geladenen Teilchen. Eingesetzt wird der Pixel Detektor im inneren Detektor des ATLAS Experimentes am LHC (Large Hadron Collider). Der LHC ist ein Hadronen Speichering am Europäischen Labor für Elementarteilchenphysik CERN in Genf. Mit 27km Umfang ist der LHC die derzeit größte Maschine der Welt [CER08]. Im LHC werden zwei gegensätzliche Protonen-Beams (Strahlen) auf nahezu Lichtgeschwindigkeit beschleunigt. Ein Protonen-Beam besteht aus 2808 Bunches. Jeder Bunch ist ein Protonen-Paket, das aus ca Protonen besteht. Haben die Protonen-Beams ihre Endgeschwindigkeit erreicht, werden die Beams aufeinander gerichtet, wobei es zur Kollision einzelner Protonen kommt. Bei der Kollision entstehen neue Partikel, deren Zerfallsprodukte vom ATLAS-Detektor detektiert werden. Auf Basis der detektieren Zerfallsinformation können Energie und Masse eines Teilchen 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 Bahnradius die Impulse bestimmen zu können. Je nach Art des Partikels entstehen in den einzelnen Schichten des Experimentes unterschiedliche Signaturen. Aus diesen Signaturen können die Teilchenphysiker die Energie und Masse eines Teilchens berechnen. Ziel des ATLAS Teilchendetektor ist es unter anderem das Higgs-Bosson nachzuweisen. Physiker vermuten im Higgs-Teilchen die Erklärung der Masse der Elementarteilchen. 4 Trotz der hohen Menge an Bunches und der Protonen je Bunch wird es pro Kreuzung der Bunches nur in etwa 20 Kollisionen geben. Durch die hohe Geschwindigkeit des Beams werden sich allerdings die beiden Beams ca. 30 Millionen mal pro Sekunde kreuzen, wodurch es zu ca. 600 Millionen Kollisionen pro Sekunde kommt. Jede Kollision wird als Event bezeichnet. Würde man alle Daten eines Events speichern, entstünden pro Sekunde CD gefüllt mit Informationen. Da diese Menge von Informationen nicht speicherbar ist, gibt es das TDAQ (Trigger and Data Acquisition). Das TDAQ reduziert die Datenmenge pro Event um den Faktor auf 320 MB/s [ATL08]. Überwacht wird der gesamte Detektor durch das Detektorkontrollsystem. Dieses besteht aus einer Hardware- und einer Softwarekomponente. Die Softwarekomponente basiert auf PVSS (Prozess-Visualisierungs und -Steuerungs System). PVSS stellt sogenannte Datenpunkte zur 4 ID xml 17

29 2 Einführung Verfügung, siehe Abbildung 2.8. Datenpunkte können z.b. Temperatur Module oder Spannungsmesser sein. Ein solcher Punkt kann über 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 zum Teil von einer Finite state machine (FSM) 5 gesetzt. Die FSM sorgt dafür, dass Fehler erkannt werden. 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 wird in PVSS als Baum Struktur abgebildet. Sobald der LHC in den Betrieb geht, werden rund um die Uhr Wissenschaftler im Schichtbetrieb den Detektor überwachen. Kommt es während der Laufzeit zu einem Fehler, muss der Schichtarbeiter, um gewährleisten zu können, dass keine wichtigen Informationen verloren gehen, möglichst schnell eine Lösung finden. Der Schichtarbeiter ist in der Regel nur Experte für ein kleines Themengebiet. Am ATLAS-Detektor arbeiten 2200 Physiker, wovon keiner in der Lage ist, Experte auf allen Gebieten des Detektors zu sein. Aus diesem Grund entstand für den Pixel Detektor das Pilot-Projekt Pixel Advisor. Die Idee hinter dem Projekt ist, dass ein Experte sein Wissen in Form von Regeln in eine Software eingibt. Die Software soll diese Regeln einem Problem zuordnen können und die Lösungsstrategie des Experten anzeigen. 5 Eine FSM ist ein in sich geschlossenes System, das durch eine endliche Menge von Zuständen und deren Übergänge definiert wird 18

30 2.4 Einführung in GridXP 2.4 Einführung in GridXP Das Grid In der Einleitung zum Pixel Advisor wurde die immense Datenmenge von 320 MB/s, die der ATLAS Detektor im Betrieb produziert, erwähnt. Wenn der LHC 2008 in den Betrieb geht, werden ATLAS und die restlichen Experimente jährlich ein gesamt Datenvolumen von ca. 15PB produzieren. Damit dieses gewaltige Datenaufkommen gespeichert und verwaltet werden kann, wurde am CERN 2002 das LHC Computing Grid (LCG) gestartet. Es vereint Tausende von Computern weltweit zu einer Einheit und erlaubt es den Tausenden von Wissenschaftlern, die über den Globus verteilt sind, rund um die Uhr auf die produzierten Daten zu zugreifen und diese zu analysieren. Aufbau Die Generelle-Idee hinter dem Grid-Computing ist die Bereitstellung von Ressourcen, wie Speicherplatz und CPU-Zeit. So einfach, wie es möglich ist Strom aus der Steckdose zu bekommen, soll das Grid es ermöglichen auf Speicherplatz und CPU-Rechenzeit zu zugreifen. Realisiert wird dies durch eine Hard- und Softwareinfrastruktur, die die gemeinsame Nutzung und Zusammenfassung von Hochleistungsrechner-Kapazitäten 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 Ressourcen miteinander verknüpft. Danach folgt der Ressourcen-Layer, in dem Hochleistungsrechner, Datenbanken, Sensoren und Datenspeicher angesiedelt sind. Im Middleware-Layer sind die 19

31 2 Einführung Organisation-Organe enthalten. Die Middleware organisiert und integriert die Ressourcen im Grid. Der oberste Layer wird Applikation-Layer oder Serviceware-Layer genannt. Er stellt Anwendungen für Benutzerinteraktion zur Verfügung. Ausführen eines Jobs Um einen Job ausführen zu können, bedarf es mehrerer Schritte. Im ersten Schritt ist es notwendig Mitglied in einer Virtuelle Organisation (VO) zu werden. Im Grid ist die virtuelle Organisation eines der grundlegenden Konzepte. Durch virtuelle Organisationen werden Computer-Ressourcen, Daten und wissenschaftliche Instrumente einer Interessengruppe zusammengefasst. Eine Interessengruppe wäre zum Beispiel die Hochenergie Physik, die ihre Experimente und Messdaten in der virtuellen Organisation High Energy Physics zusammenfasst und in der sich die Personen und Institute, die sich mit der Hochenergie Physik beschäftigen, zusammenschließen. Jedem anderen Physiker der virtuellen Organisation High Energy Physics stehen automatisch alle Daten und Instrumente dieser Organisation zur Verfügung. Um im Grid identifiziert zu werden, benötigt man ein Zertifikat, das von einer Certification Authority (CA) ausgestellt wurde. Das ausgestellte Zertifikat muss in der Grid Benutzer Oberfläche installiert werden. Die Grid Benutzer Oberfläche ist der Rechner, der benutzt wird um auf die Grid Umgebung zu zugreifen. Da die Verbindung zum Gird generell über ein unsicheres Medium, z.b. dem Internet hergestellt wird, ist es notwendig mit seinem Zertifikat eine Proxy Credential oder auch Proxy Zertifikat genannt, zu erzeugen. Ein Zertifikat hat in der Regel eine Lebensdauer von einem Jahr. Bei Missbrauch muss es für ungültig erklärt (revoked) werden. Wird ein Zertifikat revoked, kann es nicht mehr benutzt werden. Durch die Proxy Credential, die eine kürzere Lebensdauer hat, soll gewährleistet werden, dass das original Zertifikat nicht geklaut werden kann. Um den Job im LCG laufen zu lassen, muss er in der Job Description Language (JDL) beschrieben werden. Mit der JDL kann beschrieben werden, was ausgeführt werden soll, welche Daten für die Ausführung benötigt werden, wohin die Ergebnisse geschrieben werden sollen und welche Ressourcen benötigt werden. Der so beschriebene Job wird mit der JDL-Datei an einen Ressource Broker gesendet. Der Ressource Broker ist ein Organisationseinheit der Middleware. Wenn ein Job an den Ressourcen Broker gesendet wird, sucht dieser nach der geeigneten Hardware. Gleichzeitig wird vom Logging and Book-keeping Service der Middleware ein Eintrag erstellt, dass der Job abgeschickt wurde. Um die geeignete Hardware für den Job zu finden, kontaktiert der Ressource Broker den Information Service und den Replica Catalog. Diese beiden Middleware Services kennen den aktuellen Zustand des Grid. Die Informationen des Information Service und des Replica Catalog werden vom Ressource Broker genutzt um die passende Hardware zu finden. Während der Ressource Broker nach der passenden Hardware sucht, ist der Job im Status waiting. Nachdem die passende Hardware gefunden wurde, übertragt der Ressource Broker 20

32 2.4 Einführung in GridXP den Job des Computing Element. Gleichzeitig wird der Ressourcen Broker über diese Entscheidung benachrichtigt, der den Job auf den Status ready setzt. Zusätzlich informiert der Broker das Computing Element über seine Entscheidung und teilt ihm mit, wo die Daten des Jobs zu finden sind. Während ein Job läuft, ist es möglich über die Benutzeroberfläche den Logging and Bookkeeping Service zu kontaktieren und den aktuellen Status des Jobs abzufragen. Wird der Job gerade vom Computing-Element bearbeitet, ist der Status auf running gesetzt. Sobald der Job ausgeführt wurde, sendet das Computing-Element die Ausgabe-Daten an den Ressource Broker zurück. Der Absender kann anschließend die Daten von diesem herunterladen. Die Informationen über die Verarbeitung des Jobs bleiben im Logging und Bookkeeping Service dauerhaft erhalten. Der Bearbeitungsstatus des Jobs kann am Logging and Book-keeping Service jederzeit erfragt werden. Es ist allerdings nur möglich Informationen über Jobs zu bekommen, deren Ersteller man ist. Daher kann der Logging and Book-Keeping Service nicht als Instrument der Überwachung dienen, denn der liefert nicht die nötige Transparenz um Probleme, die während der Ausführung eines Jobs entstehen können, zu analysieren. Um zutreffende Aussagen über den Jobverlauf und über den Zustand des Grids zu erstellen, wurde das Job Monitoring eingeführt. Der Job Execution Monitors (JEM) ist ein solches Monitoring Tool an dessen Entwicklung die Universität Wuppertal beteiligt ist. Monitoring von Jobs Der Job Execution Monitor (JEM) ist ein in Python geschriebener Wrapper, der um den original Job gepackt wird. JEM soll helfen die Job-Ausführung zu überwachen. Damit JEM Informationen über die Ausführung sammeln kann, wird der im JEM-Wrapper gepackte Job wie oben beschrieben, submitted. Auf der Worker Node 6 wird, anstelle des Jobs, zuerst der JEM-Wrapper gestartet. Während der Job ausgeführt wird, sammelt JEM Laufzeit Informationen. Zu diesen Laufzeit Informationen gehören geworfene sowie festgehaltene Exceptions, ausgeführte Kommandos, Systemressourcen der Workern Node und im Falle von Fehlern der Name des Skripts, Funktionsname, Zeilennummer und der Inhalt aller Variablen. Diese Laufzeit Informationen werden an R-GMA (Relational Grid Monitoring Architecture) gesendet. R-GMA ist ein Service für verteilte Computerumgebungen um Monitoring-, Logging- und User-Level-Informationen zu sammeln und bereitzustellen. Die Informationen werden wie bei einer Datenbank in Tabellen gespeichert. Informationen können über den SQL-Befehl select aus diesen Tabellen gelesen werden. 6 Worker Nodes und Computing Elemente dienen der Verarbeitung von Grid-Jobs 21

33 2 Einführung GridXP Das XP-System GridXP wurde entwickelt um die Daten, die von den Monitoring-Systemen in R-GMA gespeichert werden, regelbasiert zu analysieren und um Fehler auf einem System entdecken zu können. GridXP wird an der Universität Wuppertal entwickelt. Der Projektleiter ist der Doktorand Markus Mechtel. 2.5 Einführung in UnifiedXP UnifiedXP ist eine Code-Basis um die Benutzung eines Expertensystems für verschiedene Anwendungen zu erleichtern. Eine andere Anwendung wäre zum Beispiel ein anderer Detektor. Im Projekt sind eine Ruleengine und Container für Aktivierungen, Fakten und Regeln enthalten. UnifiedXP ist eine Client/Server Anwendung. Der Server enthält die Faktbasis, RegelBasis Abbildung 2.10: Abstrakte Architektur der UnifiedXP Software und die Inferenzemaschine. Der Client dient als Erklärungs und Wissenserwerbskomponente. Daher ist es die Aufgabe des Clients die Fakten, Aktivierungen und Regeln da zu stellen und es autorisierten Benutzern zu ermöglichen Regeln zu bearbeiten und die Regelbasis auszutauschen. Zum Anpassen des Servers an eine andere Anwendung genügt es die Interviewerkomponente, 22

34 2.5 Einführung in UnifiedXP die Regelbasis und die Konfigurationsdatei auszutauschen (Siehe Abbildung 2.10). Das Interviewerkomponente ist für jeden Anwendungsfall unterschiedlich. Die Aufgabe dieser Komponente ist es die Faktenbasis des Server mit Fakten zu füllen und diese aktuell zu halten. Die beiden Projekte Pixel Advisor und GridXP sind die ersten Expertensysteme die das UnifiedXP-Projekt als Kern benutzen. 23

35 2 Einführung 24

36 3 Entwicklung 3.1 Allgemeines Die Entwicklung der Software gliederte sich in die vier Phasen Analyse, Entwurf, Implementierung und Test. Nach jedem Test wurde die aktuelle Code-Version in ein zentrales Code- Repository committed. Bei der Entwicklung wurde nach dem Inkrementell-iteratives Vorgehensmodel vorgegangen. Daher bauten die Ergebnisse jeder Phase aufeinander auf, doch wiederholten sich die Phasen während der Entwicklung, siehe Abbildung 3.1. Zu Beginn der Entwicklung müsste erst einmal analysiert werden, welche Informationen die Abbildung 3.1: Vorgehensmodell GUI anzeigen soll. In Interviews mit den beiden Projektleitern Tobias Henss und Markus Mechtel wurden die Muss-Anforderungen an die Oberfläche geklärt. Aufbauend auf den Ergebnissen der Anforderungsanalyse folgte der Entwurf der einzelnen Anforderungen. Während des Entwurfes wurde die Architektur der Software erstellt.aufgabe des Entwurfes war es auch die richtige Regelmaschine auszuwählen. 25

37 3 Entwicklung Eine wichtige Muss-Anforderung von Markus Mechtel an das gesamte Projekt war es das Projekt als eine Server und Client Anwendung zu realisieren. Der Grund dieser Anforderung ist, dass die Server Komponente, die die Fakten und Regeln auswertet und für den Client bereithält, auf einer Workstation mit Grid Benutzeroberfläche laufen soll. Zu diesem Rechner sollen sich mehrere Clients verbinden können. Da der Rechner nicht zwangsläufig über ein Window-System verfügt, sollen sich die Clients über eine Netzwerkverbindung zu diesem Rechner verbinden können. Ein weiterer wichtiger allgemeiner Punkt ist der Datenschutz innerhalb der Software. Das Grid soll in Zukunft für kommerzielle Produkte attraktiver gemacht werden. Damit kommerzielle Produkte das Grid nutzen können, muss verhindert werden, dass die Daten an unbefugte Dritte gelangen. Um diese Anforderung zu realisieren, wird die Server/Client- Verbindung über SSL verschlüsselt. Zusätzlich sollen Benutzer nur auf die Daten Zugriff erhalten, über deren Rechte sie verfügen. Rechte über die Daten haben die Benutzer, wenn sie die Ersteller der Daten sind. Um diese Anforderung gewährleisten zu können, muss der Benutzer sich mit seinem SSL- Zertifikat am Server authentifizieren. Für die Authentifizierung können die gleichen Zertifikate genutzt werden, die auch zum Committen eines Jobs benötigt werden. Einzige Voraussetzung ist das die Zertifikate des Benutzers von einer dem Server bekannten CA signiert sind. Das Modul für die Server-Client-Kommunikation und der Authentifizierung eines Benutzers wurde von Frank Iker, der für seine Bachelor-Arbeit an der Vereinheitlichung von regelbasierten Expertensystem arbeitet, bereitgestellt. 3.2 Auswahl der Regelmaschine Auswahlkriterien Vor der Implementierung eines Expertensystems steht die Frage, für welche Regelmaschine man sich entscheidet, baut man auf eine Bestehende auf oder entwickelt man selber eine auf System-Anforderungen basierende, neue Regelmaschine. Auf dem Markt existieren mehrere fertige Regelmaschinen. Viele von ihnen sind unter einer Open-Source Licence veröffentlicht worden und können sogar in kommerzieller Software eingesetzt werden. Im UnifiedXP Projekt hat man sich für die Regelmaschine JBoss Drools, der Firma RedHat, entschieden. Ebenfalls wurde Drools in den vorher separat existierenden Projekten GridXP und Pixel Advisor eingesetzt. Bei der Wahl für eine der frei erhältlichen Regelmaschinen hat man folgende Entscheidungskriterien berücksichtigt: 26

38 3.2 Auswahl der Regelmaschine Benutzeroberfläche: Bietet die Regelmaschine Schnittstellen um eine eigene Plattform unabhängige Benutzeroberfläche anzubinden? Art der Faktenbasis: Wie gelangen die Fakten in die Regelmaschine? Sind Schnittstellen vorhanden um Fakten durch eine Softwarekomponente hinzufügen zu können? Ist es möglich JavaBeans in Regeln zu benutzen? Syntax der Regelsprache. Sind Programmierkenntnisse erforderlich um neue Regeln zu erstellen, oder können auch unerfahrene Benutzer neue Regeln erstellen? Art der Unterstützung. Existiert eine aktive und große Community? Sind aktuelle und verständlich Dokumentationen vorhanden? Lizenzart. Ist die Software als Open-Source lizenziert? Art der Einbindung in vorhandene Software. Erlaubt es die Architektur der Regelmaschine vorhandene Software weiterhin zu benutzen. Als Alternativen zu JBoss Drools wurden CLIPS und Jess getestet CLIPS CLIPS (C Language Integrated Production System) ist eine von der NASA entwickelte Programmiersprache um regelbasierte Expertensysteme zu entwickeln [db08]. Da CLIPS sehr schnell und kostenlos ist, ist es die am häufigsten verwendete Regelmaschine um Expertensysteme zu erstellen. Die Regeln werden in der LIPS (List Processing) ähnlichen CLIPS Syntax implementiert, siehe Abbildung 3.2. Um die Regeln auch in Java benutzen zu können, bietet CLIPS ein Java Native Interface Abbildung 3.2: CLIPS-Regel an. Über die Spracherweiterung COOL (Clips Object-Oriented Language) ist es zusätzlich möglich die Besonderheiten wie Vererbung und Polymorphismus von objektorientierten Sprachen in den Regeln abzufragen. Jedoch ist die Art, um auf Attribute einer Klasse zugreifen zu können, im Gegensatz zu dem was andere Regelmaschinen bieten sehr umständlich. Denn in CLIPS müssen Fakten als Atome (Skalarwerte, Einzelwerte) in die Faktbasis hinzugefügt werden. Das bedeutet, wenn eine Klasse zur Faktenbasis hinzugefügt wird, können Attribute is-a oder has-a abgefragt werden. Jedoch ist es nicht möglich auf Klassen Variablen zu zugreifen. 27

39 3 Entwicklung Das Zugreifen auf Klassen Variablen ist nur möglich wenn, diese als Atome zur Faktenbasis hinzugefügt werden JESS Jess (Jave Expert System Shell) ist als Clone von CLIPS in Java entstanden. Doch mittlerweile sind die beiden Sprachen nicht mehr kompatibel zueinander. Die Regeln werden in der aus CLIPS gewohnten Syntax eingeben. Dabei erweitert Jess diese Syntax, um die Fähigkeit JavaBeans in das Working Memory hinzuzufügen und dessen Member Variablen in Regeln zu benutzen. Zusätzlich bietet Jess die Möglichkeit Regeln in XML (JessML) zu definieren und die XML-Datei aus Java heraus zu parsen. Im Gegensatz zu CLIPS ist Jess keine Open Source Rule Engine und nur für den nicht kommerziellen Gebrauch kostenlos [db08] JBoss Drools JBoss Drools ist komplett in Java geschrieben und bietet eine 100% Java Unterstützung. Seit einigen Jahren gehört Drools zum Portfolio der Firma RedHat und wird von RedHat aktiv weiterentwickelt. Als Unterstützung für den Einstieg bietet RedHat eine Vielzahl von Dokumenten, Beispiel Implementationen, Foren und Wikis an. Es hat sich auch hinter der Software eine aktive Community gebildet, die auf Fragen schnell und adäquat antwortet. Regeln werden in Drools in drl-dateien geschrieben oder wahlweise in XML. Die Regel-Syntax ist bei Drools näher an einer natürlichen Sprache angelehnt, wie man anhand der Abbildung 3.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 natürlichen Sprache angelehnt. Wenn die Regeln noch lesbarer gemacht werden sollen, gibt es in Drool die Möglichkeit eine dsl-datei (Domain Specific Language) zu benutzten. Mit einer dsl-datei ist es möglich Templates zu definieren. Templates 28

40 3.2 Auswahl der Regelmaschine sind natürliche Sprach-Schnipsel, die als Stellvertreter für 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 verständlicher wird. JBoss liefert für die Eclipse IDE ein Plugin. Im Plugin sind ein Regeleditor mit Syntaxhervorhebung und Autovervollständigung, 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 Regeln ausgeführt werden, zu bestimmen. Ein weiterer Vorteil an Drools ist, dass es Open-Source ist. Drools bietet eine Vielzahl von Möglichkeiten aus Java heraus die Vorgänge in der Regelengine zu kontrollieren und zu loggen. Mit Vorgängen ist gemeint: Das Hinzufügen oder Entfernen von Fakten, die Aktivierung einer neuen Regel oder das Feuern einer Regel. Alle Ereignisse, die in der Regelmaschine auftreten, haben spezielle Event Interface implementiert. Mithilfe von dem zugehörigen Event-Listener ist es möglich sich an diesen Event zu registrieren. Ab dem Zeitpunkt der Registrierung wird man automatisch über ein neues Event informiert. Diese Schnittstellen werden genutzt um den UnifiedXP Client mit Informationen aus dem Server zu versorgen. Zusätzlich verfügt die Drools Regelsprache über eine Vielzahl von Optionen, die zur Steuerung der Ausführungsreihenfolge von Regeln ähnlich der Salience dienen. Es gibt zum Beispiel die Option Agenda-Groups, die es erlaubt Regeln in Agenda-Groups einzuteilen und einen Fokus auf eine bestimmte Agenda-Group zu setzten. Ist der Fokus auf eine bestimmte Gruppe gesetzt, werden die Regeln, die dieser Gruppe angehören, beim Auswählen einer zu feuernden Aktivierungen bevorzugt behandelt. Drools hat auch einen Algorithmus implementiert der Schleifen in der Ausführung von Regeln verhindern soll. Die Option, die das Refraktionsprinzip einschaltet, heißt no-loop und kann innerhalb der Regelbeschreibung gesetzt werden. 29

41 3 Entwicklung Entscheidung Einer der Hauptgründe gegen Jess und CLIPS ist ihre für Laien schwer verständliche Regel- Syntax. Gegen Jess sprach zusätzlich die inaktive Community, dass Jess kein Open-Source Projekt ist und das nur sehr wenige Programmierer an Jess entwickeln. CLIPS schied wegen der fehlenden JavaBeans Unterstützung und der Regel-Syntax aus. Im Gegensatz zu den beiden anderen bieten Drools eine offene und zu 100% freie Java-Architektur, die Möglichkeit natürliche Sprachkonstrukte in Regeln einzubetten und eine aktive Community. 3.3 Anforderungsanalyse der Benutzeroberfläche Einleitung Die Benutzeroberfläche des Expertensystems dient zur Darstellung der im Expertensystem ablaufenden Vorgänge. Sie soll einem Benutzer wie z.b. einem Schichtarbeiter einen schnellen Überblick über das zu beobachtende System ermöglichen. In den folgenden Abschnitten werden die einzelnen Anwendungsfälle der Oberfläche beschreiben Anzeige von Fakten Auf der grafischen Oberfläche soll der Benutzer einen Überblick über die vorhandenen Fakten bekommen. Die Fakten des Systems sollen als Knoten (n) in einem Baum (B) dargestellt werden. Mit der Maus oder der Tastatur soll der Benutzer durch diesen Baum navigieren können. Wählt der Benutzer ein Element des Baums aus, soll er die Details zu diesem Knoten angezeigt bekommen Anzeige von Lösungsstrategien Regeln die zum Lösen eines Problems dienen, sollen nicht gefeuert werden. Anstelle, dass diese Regeln feuern, soll die Aktivierung der Regel in der Benutzeroberfläche angezeigt werden. Das Feuern der Regel würde zum Verlust einer Aktivierung führen. Zwar ist es möglich sich die Aktivierungen zu merken, doch würde man hierdurch die Information verlieren ob ein Fehler noch vorhanden ist. Ist ein Faktum im Baum selektiert, werden nur die Aktivierungen der Nachfolger und die des selektierten Faktes angezeigt. 30

42 3.3 Anforderungsanalyse der Benutzeroberfläche Wenn mehrere Aktivierungen zu einem aus dem Faktenbaum ausgewählten Faktum existieren und dieser der erste gemeinsame Vorgänger der Fakten, die zur Aktivierung geführt haben ist, dann soll eine Wahrscheinlichkeit in Prozent angegeben werden. Der erste gemeinsame Vorfahre ist in der Theorie der Knoten, an dem es zu einem Fehler gekommen ist. Die Position dieses Vorgängers wird durch den folgenden Algorithmus bestimmt. Def.: Die Menge der Fakten, die zu einer Aktivierung geführt haben, heißt F A. F A = {f 1,..., f n } Die Menge aller Pfade (p) für die Fakten aus F A von dem Faktum zur Wurzel (W ) heißt P P = {pfad(f 1, W (B),..., pfad(f n, W (B)} Die Menge aller Längen der Pfade aus P heißt L L = {len(p 1 ),..., len(p n )} Die Funktion minlen gibt aus der Menge P den Pfad mit der kürzesten Länge zurück. p x = minlen(p ) Das Element x = n xi 1, für n xi n xi p x gilt für alle i = 0,..., min(l) ist der erst gemeinsame Vorfahre wenn gilt: k = len(p j ) min(l) + i für alle j = 0,..., n n xi 1 = n p1k = n p2k =... = n pnk Die Wahrscheinlichkeit soll dem Benutzer anzeigen, wie hoch die Chance ist, dass die angezeigte Lösungsstrategie zum Lösen des Problems führt. Der Algorithmus, der die Wahrscheinlichkeit für jede Aktivierung ausrechnet, soll austauschbar sein. Der Vorteil, der ein austauschbarer Algorithmus mit sich bringt, ist, dass es möglich ist selber zu bestimmen, wie die Wahrscheinlichkeit dargestellt wird. Denkbar wäre zum Beispiel, dass der Wert der Wahrscheinlichkeit nicht 100% erreicht, sondern nur 99%. Durch diese geringe Abweichung würde dem Benutzer signalisiert werden, dass eine mögliche Restungenauigkeit nicht ausgeschlossen ist. Beispiel: Es liegt für den Pixel Detektor folgende Situation vor: 31

43 3 Entwicklung Es existiert eine Regel, die aktiviert wird, wenn die Versorgungsspannung VDD und die Hochspannung HV einen bestimmten Wert überschreiten. Es liegen Fakten vor, die die Regel aktivieren (Fakten mit 45 Schraffur in Abbildung 3.5) In diesem Fall könnte der gemeinsame Vorfahre (Fakten mit Senkrechter Schraffur) Verursacher des Problems sein. Zusätzlich könne es eine Regel geben, die aktiviert wird, wenn es mehrere Module mit Fehlern gibt, was zu der Schlussfolgerung führt, dass Sector1 der Grund für die Fehler sein könnte. Abbildung 3.5: Beispiel: Erster Gemeinsamer Vorfahre - Algorithmus Bewerten von Lösungsstrategien Wenn eine Aktivierung mit einer hohen Wahrscheinlichkeit nicht zu einem Problem zutrifft, folglich dessen Lösungsstrategie nicht zum Lösen des Problems geführt hat, soll der Benutzer die Wahrscheinlichkeit einer Regel beeinflussen können. 32

44 3.3 Anforderungsanalyse der Benutzeroberfläche Änderung der Regelbasis Benutzer mit höheren Privilegien soll es gestattet sein die Regelbasis zu verändern. Veränderungen können sein: bearbeiten von Regeln hinzufügen von neuen Regeln löschen von Regeln Regelbasis des Servers auszutauschen und neu zu laden Außerdem soll es diesen Benutzer möglich sein den Server zu beenden Erstellen von Log-Dateien Für die spätere Analyse von Problemen wäre es wünschenswert, Log-Dateien speichern zu können. Anhand der Log-Datei soll man erkennen, warum eine Regel aktiviert wurde. Deswegen müssen diese Log-Dateien die Fakten enthalten, die zur Aktivierung geführt haben. Jedes Faktum sollte in diesem Log mit dem zugehörigen Werten aufgeführt sein. Das Erstellen einer Log-Datei soll aus einer Regel heraus durchführbar sein. Über einen in der Oberfläche integrierten Betrachter, soll es möglich sein, die Log-Dateien analysieren zu können Unterschiedlich Sichten Je nach Wissensstand der Benutzer soll eine andere Anordnung der Fenster angezeigt werden. Wird die Anwendung von einem Schichtarbeiter oder ähnlich qualifizierten Benutzer genutzt, soll die Oberfläche über nur wenige Aktionen verfügen und nur die wichtigsten Informationen enthalten Ergebnis Zusammengefasst ergeben sich für die Benutzeroberfläche folgende Muss-Anforderungen: 1. Darstellung der Fakten in einer Baumstruktur 2. Anzeige von Detail zu einem Knoten 3. Anzeigen von Lösungsstrategie 4. Bewerten von Lösungsstrategie 33

45 3 Entwicklung 5. Anordnen der Lösungsstrategie nach der Wahrscheinlichkeit 6. Algorithmus zum Berechnen der Wahrscheinlichkeit soll austauschbar sein 7. Spezielle Funktionen für privilegierte Benutzer: a) Austausch und neu laden der Regelbasis b) Herunterfahren des Servers c) Regeln bearbeiten, erstellen und löschen 8. Anzeigen der Regelmaschinen Log-Dateien 9. Unterschiedliche Perspektiven für unterschiedliche Aufgaben. Wie das Modell dieser Anforderungen aussieht, wird im Abschnitt Entwurf beschrieben. 3.4 Interviewerkomponenten Für die Entwicklung einer moderaten Datenstruktur ist es wichtig das Verhalten der Komponenten zu kennen, die auf diese zugreifen. Aus diesem Grund werden an dieser Stelle die Funktionweisen der beiden existierenden Module, des Pixel Advisors und des GridXP, gezeigt Funktionsweise des Pixel Advisors Pixel Advisor wird als Datenannahme Modul eingesetzt. Dieses Modul bekommt seine Daten über dem DIM (Distributed Information Management System) Mechanismus. DIM wurde am CERN für den Vorgänger Detektor, Delphi, entwickelt. DIM ist ein Kommunikationssystem für verteilte Umgebungen. Der DIM Server publiziert ein oder mehrere Services, die vom Client abonniert werden können. Services können über ihre Namen angesprochen werden und enthalten jegliche Art von Informationen. Abonniert der Client ein Service, wird der Client automatisch über Änderungen informiert. Der DIM-Server bekommt seine Informationen von PVSS. 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 veröffentlichen. Hierfür wird in dem Objekt der Name des Services gespeichert, der abonniert werden soll. Zusätzlich bewirkt das Einfügen eines Faktum in die Faktenbasis ein erneutes Auswerten der Regeln. 34

46 3.4 Interviewerkomponenten Durch das erneute Auswerten wird der Wert des eingefügten subscriptioncommandobject- Faktum auf den zu abonnierenden Service verändert. Jedes Faktum ist nach dem JavaBean Standard aufgebaut und implementiert die PropertyChange Unterstützung. Durch diese Unterstützung ist es möglich sich als Interessent über die Änderung des Zustandes eines Faktums informieren zu lassen. Getriggert durch die Änderungen des Zustandes des subscriptioncommandobject Faktums, fordert das Datenannahme Modul den DIM-Server auf, weitere Werte zu veröffentlichen. Anschließend wird ein Faktum, mit dem Namen des angeforderten Services, für die Antwort des DIM-Servers hinzugefügt. Für die Verbindung zwischen Dim-Server und Datannahme dient das XpsDimInfo Objekt. Kommt es auf PVSS-Seite zu einer Wertänderung im abonnierten Datenpunkt wird das XpsDimInfo Objekt aktualisiert und die infohandler-methode aufgerufen. Die infohandler-methode am XpsDimInfo-Objekt startet einen neuen Thread der den Wert des vorher angelegten Faktums aktualisiert. Jedes Faktum verfügt über eine Member-Variable name. Diese Variable enthält einen systemweit eindeutigen Schlüssel über das, das Faktum identifiziert werden kann. Als Schlüssel dient der Datenpunktname aus PVSS. Durch die Wertänderung des Faktums werden die Regeln erneut ausgewertet und der Vorgang beginnt von vorne. Über den beschriebenen Mechanismus wird die Faktenbasis mit Werten gefüllt. Wie bereits erwähnt, ist der Aufbau des Detektors in PVSS als Baum abgebildet. Ein Fehler auf den obersten Ebenen hat zur Folge, dass alle Datenpunkte mit dem Status Warning abonniert werden, bis die unterste Ebene erreicht ist. Die unterste Ebene des Baums enthält Temperatur oder Strommessungsmodule. Der Grund für dieses Vorgehen liegt darin, dass die Übertragungsrate an Wertänderungen pro Sekunde bei DIM auf 1000 begrenzt ist. Allerding sind alleine im Pixel-Detektor Wertänderungen pro Sekunde zu erwarten Funktionsweise GridXP Die Funktionsweise des GridXP basiert auf ein etwas einfacheres Prinzip, als der Pixel Advisor. Über R-GMA Java-API ist es möglich SQL-Befehl aus einem Java Programm an R-GMA zu senden. Da unter Umständen mehrere Minuten vergehen können bis auf einem SQL-Befehl geantwortet wird, hat jede Tabelle, die man auslesen möchte, einen eigenen Consumer. Die Consumer sind als Threads implementiert und werden beim Initialisieren der Anwendung gestartet. Um die Faktenbasis mit Informationen zu füllen, senden die einzelnen Consumer den SQL-Befehl 1 select \ textasteriskcentered from table an die zugehörige Tabelle. Aus den Antworten des R-GMA Services werden Java Objekte erzeugt, die der Consumer zur Faktenbasis hinzufügt. 35

47 3 Entwicklung 3.5 Entwurf Architekturentwurf Damit die Informationen der Regelmaschine durch den Client angezeigt werden können, ist es nötig eine geeignete Datenstruktur zu entwerfen. Die wichtigsten Informationen, die für den Benutzer aufbereitet und in dem GUI angezeigt werden, sind Fakten, Aktivierungen und Regeln. Diese Informationen werden als JavaBeans gespeichert. Für jeden dieser Informationen existiert ein Container der die Objekte organisiert, siehe Abbildung 3.6. Die Container sind nach dem Singleton Entwurfsmuster entworfen worden. Durch die Verwendung des Singleton- Musters [EG94], soll gewährleistet werden, dass keine zwei Instanzen eines Container existieren. Zusätzlich wird die Klasse der Container durch die Benutzung des Singleton-Muster global. Hierdurch wird es überflüssig an Klassen, die auf Fakten oder Ähnlichem zugreifen müssen, eine Referenz auf den entsprechenden Container beim Erzeugen zu übergeben. Die Beans werden vom Server als serialisierte Objekte geliefert. Aus diesem Grund implementieren alle Beans das Serializable Interface. Durch das Serializable Interface wird gezeigt, dass die Klassen serialisierbar sind und nur serialisierbare Member-Variablen enthalten. Drools verfügt zwar über die Objekte Rule, Package und Activation, doch verfügen diese Objekte teilweise über unnötige, über zu wenig Informationen oder über Informationen, die sich nicht mehr im Klartext lesen lassen. Als Konsequenz daraus wurden für alle diese Objekt neue Klassen erstellt. Diese Klassen bieten eine einfache Abstraktion der benötigten Informationen. In den nun folgenden Unterkapiteln wird beschrieben, wie der Entwurf für die Datenstruktur aussieht und wie die Container mit Daten angereichert werden. Die Datenstruktur ist so konzipiert, dass diese im Server und im Client einsetzbar ist. Da es auf Client Seite keine Regelmaschine gibt, wird der Teil, der mit der Regelmaschine kommuniziert, im Client deaktiviert Entwurf der Faktenbasis Damit die Fakten systemweit eindeutig sind, enthalten sie einen eindeutigen Schlüssel. Dieser Schlüssel soll gewährleisten, dass kein Faktum doppelt vorhanden ist. Fakten werden durch StoreableObjects repräsentiert. Organisiert werden diese Fakten im StoreableObjectsSet. Dieser Container enthält eine Menge von Funktionen, die zur Organisation der Fakten dienen. Zusätzlich kümmert sich der Container darum, dass Fakten nach Benutzern sortiert sind. Hierfür existiert im Faktum ein Member user, der den Namen des Benutzers enthält. Dieses Sortieren stellt sicher, dass ein Benutzer nur die Fakten zugeschickt bekommt, für die er auch die Rechte besitzt. Der Container bietet die einzige Schnittstelle zum WorkingMemory. 36

48 3.5 Entwurf Abbildung 3.6: Klassendiagramm der Datenstruktur 37

49 3 Entwicklung Objekte, die zum StoreableObjectsSet hinzugefügt werden, werden automatisch auch zum WorkingMemory hinzugefügt. Das Gleiche gilt für das Entfernen von Fakten. Beide Fälle führen zu einer erneuten Auswertung der Regelbasis. Damit der Container nach einer längeren Laufzeit nicht überläuft, wird eine maximale Kapazität angegeben. Wenn diese Kapazität überschritten wird, fängt der im Hintergrund laufende StoreOptimizer an das Faktum mit den ältesten Timestamps zu löschen. Der Optimierer löscht solange Fakten bis wieder genügend freie Kapazitäten vorhanden sind. Die Fakten verfügen über das Flag removeable. Falls das Flag gesetzt ist - z.b. aus einer Regel heraus - wird das Objekt nicht während der Optimierung gelöscht. So soll verhindert werden, dass der Optimierer ein wichtiges Objekt löscht Datenstruktur der Activations Die Informationen für eine SimpleActivationAbstraction kommen aus dem WorkingMemory. Das WorkingMemory verfügt über einer Agenda. Zur Agenda werden alle aktiven Regeln als Aktivierung hinzugefügt. Um über so ein Event benachrichtigt zu werden, genügt es das AgendaEventListener Interface zu implementieren und sich am WorkingMemory zu registrieren. Nachdem man sich an dem WorkingMemory registriert hat, wird man über folgende Events informiert: ActivationCreatedEvent wenn eine Aktivierung zur Agenda hinzugefügt wurde. BeforeActivationFiringEvent wenn mit der Ausführung des Konsequenzteils einer Regel begonnen wird. AfterActivationFiredEvent wenn der Konsequenzteil der Aktivierung ausgeführt wurde. ActivationCancelledEvent wenn mehrere Aktivierungen vorliegen und das Ausführen der einen Regel dazu führt, 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 DefaultAgendaEventListener an von dem man sich ableiten kann. Nicht überschriebene 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 überschreibt die Methoden activationcancelled activationcreated 38

50 3.5 Entwurf Abbildung 3.7: UnifedAgendaListener beforeactivationfired afteractivationfired Über das Event Objekt gelangt der Listener an die Drools Repräsentation einer Aktivierung. Die Aktivierung verfügt über die nötigen Informationen, um eine SimpleActivationAbstraction zu erzeugen. Die so erzeugte Abstraktion wird zum Container für Aktivierungen hinzugefügt. Beim Hinzufügen einer Aktivierung zum Container wird automatisch der erste gemeinsame Vorfahre gesucht und gesetzt. Damit der Algorithmus, der den gemeinsamen Vorfahren bestimmt, austauschbar ist, wurde an dieser Stelle das Strategy [EG94] Entwurfsmuster benutzt 3.8. Außerdem wird ein Counter mit dem Namen hasactivation in den Fakten einer Aktivierun- Abbildung 3.8: StrategyCertainCommonFact gen hochgezählt, sobald eine Aktivierung hinzugefügt wird. Dieser Counter zeigt an, ob und wie viele Aktivierungen es für ein Faktum gibt. Ein zweiter Counter hasactivationforchild wird hochgezählt, wenn für einen Nachfolger eine Aktivierung existiert. Wird eine Aktivierung gelöscht, werden die Counter heruntergezählt Entwurf Regeleditor Über die Benutzerschnittstelle soll der Benutzer Regeln verfassen, bearbeiten und löschen können. Als Quellen für die Regeln dienen die Drools drl-dateien. Beim Erstellen der Drools 39

51 3 Entwicklung RuleBase und des WorkingMemory werden die Regeln aus der drl-datei in Drools Rule Objekte übersetzt. Diese Objekte verfügen bis auf dem Namen über keine weiteren lesbaren Informationen aus der Quelle. Aus diesem Grund werden die Regeln für die Oberfläche separat als SimpleRuleAbstraction gespeichert. Für die Umwandlung von Text in ein SimpleRuleAbstraction Objekt wird eine Builder-Klasse benutzt. Die Builder-Klasse implementiert das Interface IRuleBaseBuilder 3.9. Das zusätzliche Interface erlaubt es späteren Entwicklern den einfachen Austausch des Builders. Durch den Austausch eines Builders wäre es möglich Regeln aus anderen Quelle einzulesen. Von Drools unterstützt 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 über Reguläre Ausdrücke mit den Schlüsselwörtern der Drools Regel-Syntax, siehe Abbildung Findet der Builder ein Schlüsselwort, das nicht function oder rule lautet, wird die eingelesene Zeile zu einer SimplePackageAbstraction-Instanz hinzugefügt. Ist das Schlüsselwort rule, liest der Builder eine Regel ein und fügt den eineindeutigen Namen der Regel zum Package hinzu. Das Erstellen einer Regel aus einen Text läuft wie in der Abbildung 3.11 gezeigt ab. Der Builder liest den Namen der Regel ein. Anschließend werden solange die Attribute oder 40

52 3.5 Entwurf Abbildung 3.10: Schlüsselwörter eines Paketes [Ver08] Abbildung 3.11: Schlüsselwörter einer Regel [Ver08] 41

53 3 Entwicklung Optionen eingelesen bis das Schlüsselwort when gefunden wird. Nach when wird wiederum solange ein LHS-Statement eingelesen bis die Zeile mit then beginnt. Das gleiche wird für die RHS-Statements durchgeführt. Beim Einlesen der RHS-Statements wird zusätzlich überprüft, ob das DSL-Template Solution: vorhanden ist. Der Text, der auf ein Solution-Tag folgt, wird in der Member-Variable solution gespeichert. Wird das Schlüsselwort end gefunden, ist die Regel eingelesen und der Builder erstellt aus den eingelesenen Informationen eine SimpleRuleAbstraction Instanz. Diese Instanz wird zum RulesSet hinzugefügt. Für das Schlüsselwort function wird die Anzahl der geöffneten geschweiften Klammern ermittelt. Für jede geschlossene geschweifte Klammer wird die Anzahl heruntergezählt. Eine Funktion ist erst dann vollständig eingelesen, wenn die Anzahl der offenen Klammer gleich Null ist. Die so eingelesene Funktion wird als String zu der SimplePackageAbstraction hinzugefügt. Ist das Ende der Datei erreicht, (EOF) kann die RuleBase zurückgegeben werden. Alle eingelesenen Regeln werden als SimpleRuleAbstraction zum Client gesendet. Im Client können der Wert der Salience, der Name und die einzelnen Statements bearbeitet werden. Jedoch ist es nur Benutzern mit administrativen Rechten erlaubt Regeln zu bestätigen. Benutzer ohne administrative Rechte können Regeln bearbeiten und neu erstellen. Allerdings wird bei diesen Benutzern das dirty-flag der Regel gesetzt. Regeln mit dirty-flag müssen von einem Admin bestätigt werden. Durch das Bestätigen wird eine eventuell vorhandene Regel ausgetauscht und das dirty-flag auf falsch gesetzt. Der Admin kann sich die Regeln mit gesetztem dirty-flag vom Server herunterladen und in dem Rule-Editor bearbeiten, löschen und bestätigen. Nur einem Admin ist es erlaubt die Regelbasis auszutauschen. Beim Austauschen der Regelbasis werden die lokalen Regeln des Admins zum Server übertragen. Am Server werden die Quellen neu geschrieben. Nachdem die Quellen neue geschrieben und erneut eingelesen sind, sendet der Client eine Reset Nachricht an alle Verbundenen Clients. Die Reset Nachricht führt im Client dazu, dass alle Container geleert und die Inhalte neu angefordert werden. Der RulesFileBuilder, der das IRulesSourceBuilder Interface implementiert, enthält die Methode die zum Neuschreiben der Regelbasis genutzt wird, siehe Abbildung Genauso wie beim RuleBaseBuilder wird hier auch auf die einfache Austauschbarkeit der Builder Klasse geachtet. Die writepackages()-methode erstellt zu Beginn ein Backup der Originaldatei. Das zusätzliche Backup erlaubt es bei einem Fehler die Originaldatei wiederherzustellen. Syntax Fehler führen dazu, dass beim Laden der Regel-Dateien ein Exception geworfen wird. Dies 42

54 3.5 Entwurf Abbildung 3.12: DRL-Datei Builder macht sich am Client dadurch bemerkbar, dass die Regeln nicht gesendet werden. Die einzelnen Pakete werden aus dem RulesSet Container geholt. Die writepackage()-methode ersetzt die original Pakete durch die neuen Pakete Errechnung der Wahrscheinlichkeit Der Algorithmus, der die Wahrscheinlichkeit ausrechnet, ist in eine eigenständige Klasse eingekapselt und implementiert das IProbabiltyCalculateStrategy Interface, siehe Abbildung Die Art des Aufbaues ist nach dem Strategy Entwurfsmuster entworfen. Durch die Anwendung des Strategy Musters werden alle Algorithmen, die das gleiche Ziel verfolgen, in eine Gruppe unterteilt. Zukünftigen Entwicklern wird es hierdurch erleichtert die voreingestellte Klasse durch eine andere auszutauschen. Andere Algorithmen könnten z.b., wie in den Anforderungen erwähnt 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

Überblick. Allgemeines, Geschichtliches. Architektur. Oberfläche. Plugins und deren Einsatz

Überblick. Allgemeines, Geschichtliches. Architektur. Oberfläche. Plugins und deren Einsatz Architektur Überblick Allgemeines, Geschichtliches Architektur Oberfläche Plugins und deren Einsatz Was ist Eclipse? Open-Source-Framework zur Entwicklung von Software nahezu aller Art. Bekannteste Verwendung:

Mehr

Inhaltsverzeichnis. TeiM. V E E.l E.2 E.3 E.4. Vorwort von Stefan Tilkov Einleitung Zielgruppe Über dieses Buch Konventionen Dank

Inhaltsverzeichnis. TeiM. V E E.l E.2 E.3 E.4. Vorwort von Stefan Tilkov Einleitung Zielgruppe Über dieses Buch Konventionen Dank V E E.l E.2 E.3 E.4 TeiM 1 1.1 1.2 1.3 1.4 1.5 2 2.1 2.2 2.3 2.4 2.5 2.6 3 3.1 3.2 3.3 3.4 3.5 Vorwort von Stefan Tilkov Einleitung Zielgruppe Über dieses Buch Konventionen Dank Überblick Die Entwicklungsumgebung

Mehr

Eine Einführung. Vortragende(r) FU Institut Berlin für Informatik 14.12.2005. Ingo Mohr

Eine Einführung. Vortragende(r) FU Institut Berlin für Informatik 14.12.2005. Ingo Mohr Rich Client Platform (RCP) Eine Einführung Vortragende(r) Institut für Informatik Ingo Mohr FU Institut Berlin für Informatik 14.12.2005 05. Juni 2008 Inhalt 1. Motivation 2. RCP Konzepte 3. RCP Applikations

Mehr

Projekt AGB-10 Fremdprojektanalyse

Projekt AGB-10 Fremdprojektanalyse Projekt AGB-10 Fremdprojektanalyse 17. Mai 2010 1 Inhaltsverzeichnis 1 Allgemeines 3 2 Produktübersicht 3 3 Grundsätzliche Struktur und Entwurfsprinzipien für das Gesamtsystem 3 3.1 Die Prefuse Library...............................

Mehr

eclipse - Entwicklungsumgebung und mehr ETIS SS05

eclipse - Entwicklungsumgebung und mehr ETIS SS05 eclipse - Entwicklungsumgebung und mehr ETIS SS05 Gliederung Motivation Geschichte Architektur Platform Runtime Eclipse Platform Java Development Tools (JDE) Plugin Development Environment (PDE) Zusammenfassung

Mehr

Das Interceptor Muster

Das Interceptor Muster Das Interceptor Muster Implementierung des Interceptor Musters basierend auf OSGi and Friends Benjamin Friedrich Hochschule für Technik und Wirtschaft des Saarlandes Praktische Informatik - Entwurfsmuster

Mehr

Dynamische Plug-ins mit Eclipse 3. Martin Lippert (martin.lippert@it-agile.de, www.it-agile.de) Tammo Freese (freese@acm.org)

Dynamische Plug-ins mit Eclipse 3. Martin Lippert (martin.lippert@it-agile.de, www.it-agile.de) Tammo Freese (freese@acm.org) Dynamische Plug-ins mit Eclipse 3 Martin Lippert (martin.lippert@it-agile.de, www.it-agile.de) Tammo Freese (freese@acm.org) Überblick Die Ausgangslage Dynamische Plug-ins Warum? Eclipse 3 Die OSGi-basierte

Mehr

Eignet sich Eclipse RCP als Enterprise Plattform? 2. Mai 2006 Lars Stucki & Edwin Steiner www.inventage.com

Eignet sich Eclipse RCP als Enterprise Plattform? 2. Mai 2006 Lars Stucki & Edwin Steiner www.inventage.com Eignet sich Eclipse RCP als Enterprise Plattform? 2. Mai 2006 Lars Stucki & Edwin Steiner www.inventage.com Eignet sich Eclipse RCP als Enterprise Plattform? Einführung Demos Corporate Governance Asset

Mehr

eclipse und Komponenten

eclipse und Komponenten Christian bossk Holle & Markus Breitländer Fh-Dortmund Fb Informatik SS04 Geschichte von eclipse April 1999 Eclipse wird von OTI und IBM entwickelt November 2001 Eclipse wird Open Source Lizensiert unter

Mehr

Open Source IDE - eclipse ETIS SS04

Open Source IDE - eclipse ETIS SS04 Open Source IDE - eclipse ETIS SS04 Gliederung Motivation Geschichte Architektur Platform Runtime Eclipse Platform Java Development Tools (JDE) Plugin Development Environment (PDE) Zusammenfassung 2 Motivation

Mehr

SWT. -The Standard Widget Toolkit- Inhaltsverzeichnis. Thomas Wilhelm SWT. 1. Was ist SWT?

SWT. -The Standard Widget Toolkit- Inhaltsverzeichnis. Thomas Wilhelm SWT. 1. Was ist SWT? Java -The Standard Widget Toolkit- Inhaltsverzeichnis 1. Was ist? - Vorteile von - Nachteile von 2. Vorbereitungen für 3. Das erste Programm in 4. Widgets und Styleparameter 5. - Layouts Was ist ein Widget?

Mehr

Spring Dynamic Modules for OSGi Service Platforms

Spring Dynamic Modules for OSGi Service Platforms Gerd Wütherich freiberuflicher Softwarearchitekt Spring Dynamic Modules for OSGi Service Platforms Server Anwendungen mit Spring und Eclipse Equinox Agenda OSGi Technologie: OSGi Technologie im Überblick

Mehr

Einführung in die OPC-Technik

Einführung in die OPC-Technik Einführung in die OPC-Technik Was ist OPC? OPC, als Standartschnittstelle der Zukunft, steht für OLE for Process Control,und basiert auf dem Komponentenmodel der Firma Microsoft,dem Hersteller des Betriebssystems

Mehr

Die Eclipse Rich Client Platform. Martin Lippert Consultant und Coach lippert@acm.org

Die Eclipse Rich Client Platform. Martin Lippert Consultant und Coach lippert@acm.org Die Eclipse Rich Client Platform Martin Lippert Consultant und Coach lippert@acm.org Historisches Eclipse is a universal platform for integrating development tools Plugin Development Environment PDE Java

Mehr

Grundlagen des Grid Computing

Grundlagen des Grid Computing Grundlagen des Grid Computing Grid Middleware Toolkits: glite ICA Joh.. Kepler Universität t Linz glite Grid Middleware für das LHC Grid Wurde im Rahmen des EGEE Projekts entwickelt Basiert auf dem Globus

Mehr

Die OSGi Service Plattform

Die OSGi Service Plattform Die OSGi Service Plattform Seminarvortrag Bernhard Cleven Gliederung 1 Einleitung 2 Das Framework 3 Bundles 4 Services 5 Beispiel 6 Fazit Seite 1/ 17 Einleitung Warum OSGi? Durch Modularisierung flexible

Mehr

Cloud-Computing Seminar - Vergleichende Technologien: Grid-Computing Hochschule Mannheim

Cloud-Computing Seminar - Vergleichende Technologien: Grid-Computing Hochschule Mannheim Sven Hartlieb Cloud-Computing Seminar Hochschule Mannheim WS0910 1/23 Cloud-Computing Seminar - Vergleichende Technologien: Grid-Computing Hochschule Mannheim Sven Hartlieb Fakultät für Informatik Hochschule

Mehr

Spring Dynamic Modules for OSGi Service Platforms

Spring Dynamic Modules for OSGi Service Platforms Gerd Wütherich freiberuflicher Softwarearchitekt Spring Dynamic Modules for OSGi Service Platforms Server Anwendungen mit Spring und Eclipse Equinox Agenda OSGi Technologie: OSGi Technologie im Überblick

Mehr

Eclipse User Interface Guidelines

Eclipse User Interface Guidelines SS 2009 Softwarequalität 06.05.2009 C. M. Bopda, S. Vaupel {kaymic/vaupel84}@mathematik.uni-marburg.de Motivation (Problem) Motivation (Problem) Eclipse is a universal tool platform - an open, extensible

Mehr

Grundsätzliche Struktur und Entwurfsprinzipien des Gesamtsystems. Grundsätzliche Struktur und Entwurfsprinzipien der einzelnen Pakete

Grundsätzliche Struktur und Entwurfsprinzipien des Gesamtsystems. Grundsätzliche Struktur und Entwurfsprinzipien der einzelnen Pakete Allgemeines 2 Produktübersicht 2 Grundsätzliche Struktur und Entwurfsprinzipien des Gesamtsystems 3 Grundsätzliche Struktur und Entwurfsprinzipien der einzelnen Pakete Account-Verwaltung 5 Freund-Funktionen

Mehr

Erweiterung für Premium Auszeichnung

Erweiterung für Premium Auszeichnung Anforderungen Beliebige Inhalte sollen im System als Premium Inhalt gekennzeichnet werden können Premium Inhalte sollen weiterhin für unberechtigte Benutzer sichtbar sein, allerdings nur ein bestimmter

Mehr

Autor: Michael Spahn Version: 1.0 1/10 Vertraulichkeit: öffentlich Status: Final Metaways Infosystems GmbH

Autor: Michael Spahn Version: 1.0 1/10 Vertraulichkeit: öffentlich Status: Final Metaways Infosystems GmbH Java Einleitung - Handout Kurzbeschreibung: Eine kleine Einführung in die Programmierung mit Java. Dokument: Autor: Michael Spahn Version 1.0 Status: Final Datum: 23.10.2012 Vertraulichkeit: öffentlich

Mehr

Grid-Systeme. Betrachtung verschiedener Softwareplattformen zur Realisierung von Grids und Vorstellung des Globus Toolkit. 07.06.2002 Grid Systeme 1

Grid-Systeme. Betrachtung verschiedener Softwareplattformen zur Realisierung von Grids und Vorstellung des Globus Toolkit. 07.06.2002 Grid Systeme 1 Grid-Systeme Betrachtung verschiedener Softwareplattformen zur Realisierung von Grids und Vorstellung des Globus Toolkit 07.06.2002 Grid Systeme 1 Gliederung Vorstellung verschiedener Plattformen Globus

Mehr

Technische Beschreibung: EPOD Server

Technische Beschreibung: EPOD Server EPOD Encrypted Private Online Disc Technische Beschreibung: EPOD Server Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee JKU Linz Institut für

Mehr

3.9 Grundelemente einer Benutzeroberfläche

3.9 Grundelemente einer Benutzeroberfläche 92 3 Grundlagen einer ios-anwendung 3.8.4 Target-Actions Einer der häufigsten Anwendungsfälle bei einer Oberfläche ist das Betätigen einer Schaltfläche durch einen Anwender, woraufhin eine bestimmte Aktion

Mehr

Fakultät Angewandte Informatik Programmierung verteilter Systeme 28.11.2011. Übungen zur Vorlesung Informatik II, Blatt 6

Fakultät Angewandte Informatik Programmierung verteilter Systeme 28.11.2011. Übungen zur Vorlesung Informatik II, Blatt 6 WS 2011/12 Fakultät Angewandte Informatik Programmierung verteilter Systeme 28.11.2011 Prof. Dr. Bernhard Bauer Übungen zur Vorlesung Informatik II, Blatt 6 Abgabe: Montag, 05.12.2011, 12.00 Uhr, Informatik

Mehr

Grundlagen Programmierung

Grundlagen Programmierung 13. Aufgabe (13 Punkte) Schreiben Sie eine neue Klasse Zahlenanalyse, mit der Integer-Objekte genauer betrachtet werden können. Bei den zu entwickelnden Methoden kann es immer sinnvoll sein, sich den Ablauf

Mehr

Dokumentation. MC Frog von André Klonz, Rico Andrich und Steve Schneider

Dokumentation. MC Frog von André Klonz, Rico Andrich und Steve Schneider Dokumentation MC Frog von André Klonz, Rico Andrich und Steve Schneider Aufgabenstellung: Die Aufgabe bestand darin, einen offline Editor für Multiple-Choice-Tests im QTI 2 Format zu schreiben, der Eigenschaften

Mehr

Rich Client Platform

Rich Client Platform Rich Client Platform SWT Praxis - Seminar Jan Marc Hoffmann Institut für Informatik Technische Universität zu Berlin 10. Juni 2008 1 / 46 1 2 3 4 5 6 2 / 46 Gegeben ist: java.awt.* Der Kunde wünscht sich:

Mehr

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Agenda Mobile Agenten allgemein JADE - Java Agent DEvelopment Framework Anwendungsfall

Mehr

Lastenheft. Auftraggeber IBR Abteilung ALG

Lastenheft. Auftraggeber IBR Abteilung ALG Lastenheft Auftraggeber IBR Abteilung ALG Versionsübersicht Version Datum Autor Status Kommentar 1.0 9. 2. 2011 Auftraggeber 1.1 1. 4. 2011 Auftraggeber Ergänzung Miniflur, Personenerkennung 1.1.1 6. 4.

Mehr

TERRA X5.Filialabgleich Client

TERRA X5.Filialabgleich Client TERRA X5.Filialabgleich Client Inhaltsverzeichnis TERRA X5.Filialabgleich Client...1 Installation...3 Mindestvoraussetzungen...3 Der erste Start / die Konfiguration...4 Das Hauptfenster...5 Installation

Mehr

Übungen zur Android Entwicklung

Übungen zur Android Entwicklung Übungen zur Android Entwicklung Aufgabe 1 Hello World Entwickeln Sie eine Hello World Android Applikation und laden diese auf den Emulator. Leiten Sie hierfür die Klasse android.app.activity ab und entwerfen

Mehr

Tutorial: Eigene Module und Extensions entwickeln. Version: 0.1 Autor: Anja Beuth

Tutorial: Eigene Module und Extensions entwickeln. Version: 0.1 Autor: Anja Beuth Tutorial: Eigene Module und Extensions entwickeln Version: 0.1 Autor: Anja Beuth Inhaltsverzeichnis 1 2 2.1 2.2 2.3 2.4 3 4 4.1 4.2 4.3 5 5.1 6 6.1 6.2 Notwendigkeit prüfen... Ein Projekt in Visual Studio

Mehr

CARM-Server. Users Guide. Version 4.65. APIS Informationstechnologien GmbH

CARM-Server. Users Guide. Version 4.65. APIS Informationstechnologien GmbH CARM-Server Version 4.65 Users Guide APIS Informationstechnologien GmbH Einleitung... 1 Zugriff mit APIS IQ-Software... 1 Zugang konfigurieren... 1 Das CARM-Server-Menü... 1 Administration... 1 Remote-Konfiguration...

Mehr

Enterprise Softwarearchitekturen in Java

Enterprise Softwarearchitekturen in Java Enterprise Softwarearchitekturen in Java Dauer: 5 Tage 1. Tag: Vorbereitungstag...2 Der erste Tag richtet sich an alle, die bislang wenig Praxiserfahrung mit der Programmiersprache Java haben. Die Teilnehmer

Mehr

Lenze OPC UA Kommunikation V1.0

Lenze OPC UA Kommunikation V1.0 Verwendete Komponenten: Lenze: 94xx: Highline FW 12 Easy Starter: 1.6 OPC UA Client: Softing OPC UA Client V1.2 Unified Automation UAexpert V1.2.2 175 Der Easy Starter verfügt ab der Version 1.6 über eine

Mehr

Sybase Central Dokumentation Aktivierung der Monitoringfunktion

Sybase Central Dokumentation Aktivierung der Monitoringfunktion Sybase Central Dokumentation Aktivierung der Monitoringfunktion Version 1.0 14. Dezember 2012 Inhaltsverzeichnis 1 EINLEITUNG... 3 2 ZIELSETZUNG... 3 3 VORGEHENSWEISE... 3 4 ANHANG... 7 4.1 DOKUMENTHISTORIE...

Mehr

4 Codierung nach Viginere (Lösung)

4 Codierung nach Viginere (Lösung) Kapitel 4 Codierung nach Viginere (Lösung) Seite 1/14 4 Codierung nach Viginere (Lösung) 4.1 Einführung Blaise de Vigenère lebte von 1523 bis 1596 in Frankreich und war nach dem Studium bei verschiedenen

Mehr

Java-Tutorium WS 09/10

Java-Tutorium WS 09/10 Tutorial: Eclipse Debugger Was ist der Eclipse Debugger? Die Eclipse Plattform stellt einige sehr hilfreiche Features zum Programmieren bereit. Eines dieser Features ist der Debugger. Mithilfe des Debuggers

Mehr

Multimedia Engineering II - Übung 2

Multimedia Engineering II - Übung 2 Multimedia Engineering II - Übung 2 Zielstellung der Übungsaufgabe Das Login-Panel der ersten Übung erhält nun die Funktion, auf eine zweite View zu wechseln. Auf dieser werden Sie nun das erste Mal einen

Mehr

Willkommen zur Vorlesung. Objektorientierte Programmierung Vertiefung - Java

Willkommen zur Vorlesung. Objektorientierte Programmierung Vertiefung - Java Willkommen zur Vorlesung Objektorientierte Programmierung Vertiefung - Java Zum Dozenten Mein Name: Andreas Berndt Diplom-Informatiker (TU Darmstadt) Derzeit Software-Entwickler für Web- Applikationen

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

7 Assemblies. Anwendungen (.exe) bzw. Anwendungskomponenten (.dll) für.net Portable Execution (PE) Files

7 Assemblies. Anwendungen (.exe) bzw. Anwendungskomponenten (.dll) für.net Portable Execution (PE) Files 7 Assemblies 8 Virtual Execution System VES Anwendungen (.exe) bzw. Anwendungskomponenten (.dll) für.net Portable Execution (PE) Files Teil der CLR Class Loader Metadaten (Manifest) zur Selbstbeschreibung

Mehr

Kundenanforderungen. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 24.05.2013

Kundenanforderungen. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 24.05.2013 Software Komponenten FS13 Gruppe 03 Horw, 24.05.2013 Bontekoe Christian Estermann Michael Moor Simon Rohrer Felix Autoren Bontekoe Christian Studiengang Informatiker (Berufsbegleitend) Adresse Telefon

Mehr

Kurzanleitung. Logstar_FTP. Version 1.1

Kurzanleitung. Logstar_FTP. Version 1.1 Kurzanleitung Logstar_FTP Version 1.1 Februar 2006 UP GmbH Anleitung_Logstar_FTP_1_24.doc Seite 1 von 8 LOGSTAR _FTP Inhaltsverzeichnis Einleitung...3 Registrierung...3 Das Logstar_FTP Hauptmenu...4 Server...4

Mehr

DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE

DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE DOKUMENTATION MAAS - MONITORING AS A SERVICE DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE Dokumentation MaaS - Monitoring as a Service Inhalt 1. MaaS - Monitoring as Service... 3 1.1 Einleitung...

Mehr

Konzepte zur Datenhaltung für Webseiten in einem Web-Content- Management-System

Konzepte zur Datenhaltung für Webseiten in einem Web-Content- Management-System Konzepte zur Datenhaltung für Webseiten in einem Web-Content- Management-System Web-Content-Management-Systeme () dienen dazu, komplexe Websites zu verwalten und den Autoren einzelner Webseiten möglichst

Mehr

VB.net Programmierung und Beispielprogramm für GSV

VB.net Programmierung und Beispielprogramm für GSV VB.net Programmierung und Beispielprogramm für GSV Dokumentation Stand vom 26.05.2011 Tel +49 (0)3302 78620 60, Fax +49 (0)3302 78620 69, info@me-systeme.de, www.me-systeme.de 1 Inhaltsverzeichnis Vorwort...2

Mehr

Ein Scan basierter Seitenangriff auf DES

Ein Scan basierter Seitenangriff auf DES Ein Scan basierter Seitenangriff auf DES Seminar Codes & Kryptographie SS04 Tobias Witteler 29.06.2004 Struktur des Vortrags 1. Einführung / Motivation 2. Struktur von DES 3. Die Attacke Begriffsklärung:

Mehr

Björn Heinemann Leiter Entwicklung Energiewirtschaft

Björn Heinemann Leiter Entwicklung Energiewirtschaft Björn Heinemann Leiter Entwicklung Energiewirtschaft Basis eclipse RCP eclipse platform project als Basis mit frameworks und services RCP Rich Client Platform zur Umsetzung einer Anwendung mit Benutzeroberfläche

Mehr

Bedienung von BlueJ. Klassenanzeige

Bedienung von BlueJ. Klassenanzeige Im Folgenden werden wichtige Funktionen für den Einsatz von BlueJ im Unterricht beschrieben. Hierbei wird auf den Umgang mit Projekten, Klassen und Objekten eingegangen. Abgeschlossen wird dieses Dokument

Mehr

Seminararbeit Ruby Uno Kartenspiel

Seminararbeit Ruby Uno Kartenspiel Seminararbeit Ruby Uno Kartenspiel Autor: Fabian Merki Fabian Merki 05.11.2006 1 von 10 Inhaltsverzeichnis Einleitung... 3 Die Idee... 4 Design und Implementierung in Ruby... 5 Testing... 7 Startbefehle...

Mehr

Template der gleichnamigen Action des geerbten Controllers, also AssetsController.

Template der gleichnamigen Action des geerbten Controllers, also AssetsController. 1.4 Aufbau des Buchs 7 Template der gleichnamigen Action des geerbten Controllers, also AssetsController. 1.4 Aufbau des Buchs Das Buch ist in sechs Kapitel unterteilt. Im ersten Kapitel Grundlagen findet

Mehr

Kapitel 6,»Objektorientierte Programmierung«, widmet sich der objektorientierten Programmierung mit Python.

Kapitel 6,»Objektorientierte Programmierung«, widmet sich der objektorientierten Programmierung mit Python. 1.3 Aufbau des Buchs lichkeiten offen. Auf die Unterschiede der beiden Versionen gehe ich besonders ein, sodass ein späterer Umstieg von der einen zur anderen Version leichtfällt. Erste Zusammenhänge werden

Mehr

MySQL Community Server 5.6 Installationsbeispiel (Ab 5.5.29)

MySQL Community Server 5.6 Installationsbeispiel (Ab 5.5.29) MySQL Community Server 5.6 Installationsbeispiel (Ab 5.5.29) Dieses Dokument beschreibt das Herunterladen der Serversoftware, die Installation und Konfiguration der Software. Bevor mit der Migration der

Mehr

GUI Programmierung in Java

GUI Programmierung in Java vs und niemals mischen! Daher muss man sich für eine Klasse entscheiden 1 (Abstract Window Toolkit) schwergewichtige Alle Elemente werden vom Betriebssytem gemalt sehen aus wie alle anderen Programme auf

Mehr

Drucken mit den ErgoSoft RIPs

Drucken mit den ErgoSoft RIPs Application Notes Drucken mit den ErgoSoft RIPs Inhalt Einleitung... 1 Grundsätzliches zum Drucken... 2 Direkt zum Anschluss drucken... 3 Mit dem Print Client drucken... 4 Kopien drucken... 5 Andere Druck

Mehr

Software Engineering II

Software Engineering II Software Engineering II Codegenerierung für den SmartIO Editor mit der Modeling Workflow Engine Wintersemester 10/111 Fachgebiet Software Engineering Albert Zündorf / Wiederholung Bisher im Laufe des Semesters

Mehr

PARAGON SYSTEM UPGRADE UTILITIES

PARAGON SYSTEM UPGRADE UTILITIES PARAGON SYSTEM UPGRADE UTILITIES VIRTUALISIERUNG EINES SYSTEMS AUS ZUVOR ERSTELLTER SICHERUNG 1. Virtualisierung eines Systems aus zuvor erstellter Sicherung... 2 2. Sicherung in eine virtuelle Festplatte

Mehr

Ersatzteile der Extraklasse Magento-Module der Shopwerft

Ersatzteile der Extraklasse Magento-Module der Shopwerft Ersatzteile der Extraklasse Magento-Module der Shopwerft MicroStudio - Fotolia.com Werden von Kunden oder Suchmaschinen Elemente des Shops aufgerufen, die nicht vorhanden sind, wird statt des gewünschten

Mehr

VBA-Programmierung: Zusammenfassung

VBA-Programmierung: Zusammenfassung VBA-Programmierung: Zusammenfassung Programmiersprachen (Definition, Einordnung VBA) Softwareentwicklung-Phasen: 1. Spezifikation 2. Entwurf 3. Implementierung Datentypen (einfach, zusammengesetzt) Programmablaufsteuerung

Mehr

Testen von grafischen Benutzeroberflächen

Testen von grafischen Benutzeroberflächen Seminarvortrag 10: Testen von grafischen Benutzeroberflächen 2004 / 06 / 28 Clemens Sommer, Gerald Peter Übersicht Motivation GUI Allgemein Fehlerquellen und deren Auswirkungen GUI Testwerkzeuge JUnit

Mehr

Control System Studio CSS

Control System Studio CSS Control System Studio CSS Überblick Was ist CSS? Motivation Design Applikationen Entwicklungsbeispiel Kollaboration/ Entwicklung Demo Was ist CSS? CSS ist: ein Framework für Plug-ins zur Entwicklung von

Mehr

Datenspooler Installationsanleitung Gültig ab Datenspooler-Version 2.2.20.X

Datenspooler Installationsanleitung Gültig ab Datenspooler-Version 2.2.20.X Datenspooler Installationsanleitung Gültig ab Datenspooler-Version 2.2.20.X Inhalt 1. Vorbedingungen... 4 2. Installation... 5 2.1. Umstellung von Datenspooler Version A.03.09 auf Datenspooler-Version

Mehr

Gefahren aus dem Internet 1 Grundwissen April 2010

Gefahren aus dem Internet 1 Grundwissen April 2010 1 Grundwissen Voraussetzungen Sie haben das Internet bereits zuhause oder an der Schule genutzt. Sie wissen, was ein Provider ist. Sie wissen, was eine URL ist. Lernziele Sie wissen, was es braucht, damit

Mehr

RULE-BASED LOCAL KNOWLEDGE NAVIGATION AND DECISION SUPPORT ON SMARTPHONES

RULE-BASED LOCAL KNOWLEDGE NAVIGATION AND DECISION SUPPORT ON SMARTPHONES 18. ITG Fachtagung Mobilkommunikation Osnabrück, 16. Mai 2013 Heinz-Josef Eikerling, Nazar Selo Gavan RULE-BASED LOCAL KNOWLEDGE NAVIGATION AND DECISION SUPPORT ON SMARTPHONES 1 Inhalt Einführung Motivation,

Mehr

Managed VPSv3 Was ist neu?

Managed VPSv3 Was ist neu? Managed VPSv3 Was ist neu? Copyright 2006 VERIO Europe Seite 1 1 EINFÜHRUNG 3 1.1 Inhalt 3 2 WAS IST NEU? 4 2.1 Speicherplatz 4 2.2 Betriebssystem 4 2.3 Dateisystem 4 2.4 Wichtige Services 5 2.5 Programme

Mehr

Inhaltsverzeichnis. 2.2 Grundlagen der UML... 41. 2.3 Zusammenfassung... 53

Inhaltsverzeichnis. 2.2 Grundlagen der UML... 41. 2.3 Zusammenfassung... 53 Vorwort......................................................... 13 1 Vorbereitungen.................................................. 17 1.1 JDK-Installation unter Windows................................

Mehr

Benutzerhandbuch. Neukirchen

Benutzerhandbuch. Neukirchen Benutzerhandbuch Neukirchen August 2015 Kontakt: Kai Hübl Lambertsberg 17 D-34626 Neukirchen kai.huebl@asneg.de Contents 1 Einleitung... 5 1.1 Inhalt... 5 1.2 OPC UA Client Stack... 5 1.3 OPC UA Server

Mehr

Vermittler (Mediator) Sabine Müller - Sven Richter - Jens Wagenbreth 03IN2-P-D

Vermittler (Mediator) Sabine Müller - Sven Richter - Jens Wagenbreth 03IN2-P-D Vermittler (Mediator) Sabine Müller - Sven Richter - Jens Wagenbreth 03IN2-P-D 1 1. EINLEITUNG... 3 2. ZWECK... 3 3. MOTIVATION... 3 4. ANWENDBARKEIT... 6 5. STRUKTUR... 6 6. TEILNEHMER... 7 7. INTERAKTION...

Mehr

Inhaltsverzeichnis. Apps für Android entwickeln

Inhaltsverzeichnis. Apps für Android entwickeln Inhaltsverzeichnis zu Apps für Android entwickeln von Jan Tittel und Jochen Baumann ISBN (Buch): 978-3-446-43191-1 ISBN (E-Book): 978-3-446-43315-1 Weitere Informationen und Bestellungen unter http://www.hanser-fachbuch.de/978-3-446-43191-1

Mehr

Projekt Xaml Konverter

Projekt Xaml Konverter Carsten Kuhn, Danny Kautzsch, Matthias Jauernig Leipzig, 01.02.2008 Lehrveranstaltung Compilerbau (Aufbaukurs) Prof. Waldmann, Fb IMN, HTWK Leipzig Projekt Xaml Konverter Aufgabenbeschreibung Mit Xaml

Mehr

Installation SQL- Server 2012 Single Node

Installation SQL- Server 2012 Single Node Installation SQL- Server 2012 Single Node Dies ist eine Installationsanleitung für den neuen SQL Server 2012. Es beschreibt eine Single Node Installation auf einem virtuellen Windows Server 2008 R2 mit

Mehr

Java Wireless Toolkit (JWT) Bei der Programmierung von Anwendungsprogrammen für mobile Endgeräte eignet sich die Verwendung des Java Wireless Toolkit.

Java Wireless Toolkit (JWT) Bei der Programmierung von Anwendungsprogrammen für mobile Endgeräte eignet sich die Verwendung des Java Wireless Toolkit. 1 Seminar zum Programmierprojekt Arbeitsbereich Technische Informatik Ausgabe: 30. April 2008 Anleitung B3 Einführung in die Entwicklungsumgebungen Allgemeines In dieser Aufgabe lernen wir die Entwicklungsumgebungen

Mehr

Einstieg in die Informatik mit Java

Einstieg in die Informatik mit Java 1 / 14 Einstieg in die Informatik mit Java Swing Gerd Bohlender Institut für Angewandte und Numerische Mathematik Gliederung 2 / 14 1 Einführendes Beispiel 2 Eigenschaften von Swing 3 Typisches Swing-Applet

Mehr

Integration Services - Dienstarchitektur

Integration Services - Dienstarchitektur Integration Services - Dienstarchitektur Integration Services - Dienstarchitektur Dieser Artikel solle dabei unterstützen, Integration Services in Microsoft SQL Server be sser zu verstehen und damit die

Mehr

Einführung in die Cross-Plattform Entwicklung Das Intel App Framework

Einführung in die Cross-Plattform Entwicklung Das Intel App Framework Einführung in die Cross-Plattform Entwicklung Das Intel App Framework Einführung Dieses Hands-on-Lab (HOL) macht den Leser mit dem Intel App Framework vom Intel XDK vertraut. Es wird Schritt für Schritt

Mehr

Schlussbewertung FB VI SOFTWAREPROJEKT II WS 09/10 TEAM. Alexander Kalden Dominik Eckelmann Marcel Pierry Julian Heise Besha Taher

Schlussbewertung FB VI SOFTWAREPROJEKT II WS 09/10 TEAM. Alexander Kalden Dominik Eckelmann Marcel Pierry Julian Heise Besha Taher Schlussbewertung FB VI SOFTWAREPROJEKT II WS 09/10 TEAM Alexander Kalden Dominik Eckelmann Marcel Pierry Julian Heise Besha Taher 729631 745097 736477 745011 741297 Inhalt Schlussbewertung... 3 Bewertung

Mehr

Eclipse Smart Client Beyond Eclipse RCP. Christian Campo, compeople, 24.April 2007

Eclipse Smart Client Beyond Eclipse RCP. Christian Campo, compeople, 24.April 2007 Eclipse Smart Client Beyond Eclipse RCP Christian Campo, compeople, 24.April 2007 1 Übersicht Definition / Architektur Smart Client Smart Client mit RCP Gesamtfazit 2 Fat - Thin - Smart Fat Client lokale

Mehr

estos XMPP Proxy 5.1.30.33611

estos XMPP Proxy 5.1.30.33611 estos XMPP Proxy 5.1.30.33611 1 Willkommen zum estos XMPP Proxy... 4 1.1 WAN Einstellungen... 4 1.2 LAN Einstellungen... 5 1.3 Konfiguration des Zertifikats... 6 1.4 Diagnose... 6 1.5 Proxy Dienst... 7

Mehr

GenLM: Lizenzmanagement im Grid- und Cloud-Computing

GenLM: Lizenzmanagement im Grid- und Cloud-Computing Flexibles Management von Softwarelizenzen in virtualisierten Umgebungen GenLM: Lizenzmanagement im Grid- und Cloud-Computing Mathias Dalheimer, dalheimer@itwm.fhg.de 20. Oktober 2008 Kaiserslautern Einleitung

Mehr

Matrikelnummer: 201671. east creative GbR. Dauer: 05.04. - 08.08.2004 (18 Wochen)

Matrikelnummer: 201671. east creative GbR. Dauer: 05.04. - 08.08.2004 (18 Wochen) PRAKTIKUMSBERICHT Praktikant: Michael Zornow Studiengang: Informationstechnik Matrikelnummer: 201671 Firma: east creative GbR Betreuer: Rainer Brym Dauer: 05.04. - 08.08.2004 (18 Wochen) 2 Inhaltsverzeichnis

Mehr

Zeiterfassung-Konnektor Handbuch

Zeiterfassung-Konnektor Handbuch Zeiterfassung-Konnektor Handbuch Inhalt In diesem Handbuch werden Sie den Konnektor kennen sowie verstehen lernen. Es wird beschrieben wie Sie den Konnektor einstellen und wie das System funktioniert,

Mehr

Zeiterfassungsanlage Handbuch

Zeiterfassungsanlage Handbuch Zeiterfassungsanlage Handbuch Inhalt In diesem Handbuch werden Sie die Zeiterfassungsanlage kennen sowie verstehen lernen. Es wird beschrieben wie Sie die Anlage einstellen können und wie das Überwachungsprogramm

Mehr

SmartExporter 2013 R1

SmartExporter 2013 R1 Die aktuelle Version wartet mit zahlreichen neuen Features und umfangreichen Erweiterungen auf. So können mit SmartExporter 2013 R1 nun auch archivierte Daten extrahiert und das Herunterladen der Daten

Mehr

OSGi. The Next Generation Java Service Platform. SOA - The Java Way or My classpath is killing me. Michael Greifeneder

OSGi. The Next Generation Java Service Platform. SOA - The Java Way or My classpath is killing me. Michael Greifeneder Michael Greifeneder OSGi The Next Generation Java Service Platform SOA - The Java Way or My classpath is killing me Bilder von Peter Kriens W-JAX Keynote 2007 und Neil Bartletts Getting Started with OSGi

Mehr

SmarTeam MS Outlook Integration Version 3.1 Beschreibung des Funktionsumfangs

SmarTeam MS Outlook Integration Version 3.1 Beschreibung des Funktionsumfangs SmarTeam MS Outlook Integration Version 3.1 Beschreibung des Funktionsumfangs Der Aufbau der MS Outlook Integration orientiert sich stark an den SmarTeam Integrationen zu den MS Office Produkten, wobei

Mehr

Tutorial. Tutorial. Microsoft Office 2010 Standard Edition verteilen. 2011 DeskCenter Solutions AG

Tutorial. Tutorial. Microsoft Office 2010 Standard Edition verteilen. 2011 DeskCenter Solutions AG Tutorial Microsoft Office 2010 Standard Edition verteilen 2011 DeskCenter Solutions AG Inhaltsverzeichnis 1. Einführung...3 2. Office 2010 Ressourcen bereitstellen...3 3. Anpassung der Office Installation...4

Mehr

VMware Schutz mit NovaBACKUP BE Virtual

VMware Schutz mit NovaBACKUP BE Virtual VMware Schutz mit NovaBACKUP BE Virtual Anforderungen, Konfiguration und Restore-Anleitung Ein Leitfaden (September 2011) Inhalt Inhalt... 1 Einleitung... 2 Zusammenfassung... 3 Konfiguration von NovaBACKUP...

Mehr

OpenCms jbpm Workflow Engine. OpenCms und jbpm Workflow Engine

OpenCms jbpm Workflow Engine. OpenCms und jbpm Workflow Engine OpenCms und jbpm Workflow Engine Geschäftliche Abläufe in einem Unternehmen folgen zu einem großen Prozentsatz beschreibbaren Prozessen, den so genannten Geschäftsprozessen. Diese Erkenntnis führte zum

Mehr

Beschreibung Programmierprojekt Lubica Mühlberger (0051755) 1578 - Anwendungspraktikum aus JAVA, Dr. Hahsler, WS 2005/2006.

Beschreibung Programmierprojekt Lubica Mühlberger (0051755) 1578 - Anwendungspraktikum aus JAVA, Dr. Hahsler, WS 2005/2006. Beschreibung Programmierprojekt Lubica Mühlberger (0051755) 1578 - Anwendungspraktikum aus JAVA, Dr. Hahsler, WS 2005/2006 CryptoManiac Inhaltsverzeichnis Problemstellung... 3 Analyse und Design... 4 Beschreibung

Mehr

w-lantv 50n Kurzanleitung Eine Schritt für Schritt Anleitung zum erfolgreichen, drahtlosen TV Erlebnis. Bitte zuerst lesen!

w-lantv 50n Kurzanleitung Eine Schritt für Schritt Anleitung zum erfolgreichen, drahtlosen TV Erlebnis. Bitte zuerst lesen! Eine Schritt für Schritt Anleitung zum erfolgreichen, drahtlosen TV Erlebnis. Bitte zuerst lesen! Änderungen von Design und /oder Technik vorbehalten. 2008-2009 PCTV Systems S.à r.l. 8420-20056-01 R1 Lieferumfang

Mehr

White Paper. Embedded Treiberframework. Einführung

White Paper. Embedded Treiberframework. Einführung Embedded Treiberframework Einführung White Paper Dieses White Paper beschreibt die Architektur einer Laufzeitumgebung für Gerätetreiber im embedded Umfeld. Dieses Treiberframework ist dabei auf jede embedded

Mehr

Session Storage im Zend Server Cluster Manager

Session Storage im Zend Server Cluster Manager Session Storage im Zend Server Cluster Manager Jan Burkl System Engineer, Zend Technologies Agenda Einführung in Zend Server und ZSCM Überblick über PHP Sessions Zend Session Clustering Session Hochverfügbarkeit

Mehr

Microsoft Office 2010

Microsoft Office 2010 Microsoft Office 2010 Office-Anpassungstool Author(s): Paolo Sferrazzo Version: 1.0 Erstellt am: 15.06.12 Letzte Änderung: - 1 / 12 Hinweis: Copyright 2006,. Alle Rechte vorbehalten. Der Inhalt dieses

Mehr

Multidisziplinäre und verteilte Simulationen in der Industrie

Multidisziplinäre und verteilte Simulationen in der Industrie Multidisziplinäre und verteilte Simulationen in der Industrie Marc Lob Forum»Virtualisierung und Grid Computing«Stuttgart, 27. Mai 2008 Inhalt Gekoppelte Multi-Physics-Simulation Reconfigurable Computing

Mehr

Autorisierung. Sicherheit und Zugriffskontrolle & Erstellen einer Berechtigungskomponente

Autorisierung. Sicherheit und Zugriffskontrolle & Erstellen einer Berechtigungskomponente Autorisierung Sicherheit und Zugriffskontrolle & Erstellen einer Berechtigungskomponente Dokumentation zum Referat von Matthias Warnicke und Joachim Schröder Modul: Komponenten basierte Softwareentwickelung

Mehr

Web 2.0 Software-Architekturen

Web 2.0 Software-Architekturen Web 2.0 Software-Architekturen Servlets als Controller einer MVC Web Architektur Prof. Dr. Nikolaus Wulff HTTP und HTML Das HyperText TransferProtokoll (HTTP) beschreibt eine einfache verbindungslose Kommunikation,

Mehr

Drei-Schichten-Architektur. Informatik B - Objektorientierte Programmierung in Java. Vorlesung 16: 3-Schichten-Architektur 1 Fachkonzept - GUI

Drei-Schichten-Architektur. Informatik B - Objektorientierte Programmierung in Java. Vorlesung 16: 3-Schichten-Architektur 1 Fachkonzept - GUI Universität Osnabrück Drei-Schichten-Architektur 3 - Objektorientierte Programmierung in Java Vorlesung 6: 3-Schichten-Architektur Fachkonzept - GUI SS 2005 Prof. Dr. F.M. Thiesing, FH Dortmund Ein großer

Mehr