Integration von Optimierungsalgorithmen in den Grid Resource Broker GORBA

Größe: px
Ab Seite anzeigen:

Download "Integration von Optimierungsalgorithmen in den Grid Resource Broker GORBA"

Transkript

1 Integration von Optimierungsalgorithmen in den Grid Resource Broker GORBA Bachelorarbeit für die Prüfung zum Bachelor of Science des Studienganges Angewandte Informatik an der Dualen Hochschule Baden-Württemberg Karlsruhe von Florian Möser Bearbeitungszeitraum 12 Wochen Matrikelnummer Kurs TAI06 Ausbildungsfirma Forschungszentrum Karlsruhe GmbH Hermann-von-Helmholtz-Platz Eggenstein-Leopoldshafen Betreuer (betrieblich) Dr. Karl-Uwe Stucky Gutachter (DHBW) Gerhard Wolf

2 Erklärung gemäß 16 (3) der Studien- und Prüfungsordnung für den Studienbereich Technik vom Ich habe die vorliegende Bachelorarbeit selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet. Ort Datum Unterschrift ii

3 Kurzfassung Der Ressourcenbroker GORBA wird für die Planung beim Grid Scheduling verwendet. Zum Erstellen von Schedules stehen GORBA bereits mehrere Heuristiken zur Verfügung. Diese Auswahl an Algorithmen soll erweitert werden. In dieser Arbeit werden dazu verschiedene Algorithmen einer umfassenden Recherche unterzogen und so auf ihre Eignung als Heuristik für GORBA hin untersucht. Anschließend werden die am vielversprechendsten eingeschätzten Verfahren implementiert und anhand von mehreren Tests erprobt. Zu diesen Tests gehören die konventionellen Planungen von GORBA, bei welchen von Heuristiken Schedules erzeugt und von einer Bewertungskomponente bewertet werden, und die GLEAM-Optimierungsläufe. GLEAM ist ein Evolutionärer Algorithmus, welcher verwendet werden kann, um Schedules zu verbessern. Getestet werden die neu implementierten Heuristiken, indem sie als Ausgangspopulation für GLEAM verwendet werden. Anhand der Ergebnisse der GLEAM-Planungen wird diskutiert, ob sich die Heuristiken für dieses Anwendungsgebiet eignen. iii

4 Danksagung Mein Dank gilt meinem Betreuer Dr. Karl-Uwe Stucky, Dr. Wilfried Jakob, Dr. Wolfgang Süß und Dr. Alexander Quinte vom Institut für angewandte Informatik für die ständige Unterstützung bei meinem Studium sowie der Erstellung dieser Bachelorarbeit. iv

5 Inhaltsverzeichnis Abbildungsverzeichnis... viii Tabellenverzeichnis... ix Abkürzungsverzeichnis... x Kapitel 1 Einleitung Aufgabenstellung Gliederung der Arbeit... 3 Kapitel 2 Aktueller Stand der Technik/Grundlagen Grid-Computing Scheduling-Theorie Scheduling-Probleme Job-Daten Klassifizierung von Scheduling-Problemen Job-Shop-Scheduling-Problem (JSSP) GORBA-Problem Ressource Applicationjob Gridjob Klassifizierung Komplexität GORBA GLEAM Heuristik Metaheuristik Risiken Kapitel 3 Recherche Methodik Allgemeine Zusammenfassung der Ergebnisse Heuristiken und Algorithmen * Giffler-Thompson-Algorithmus (GTA) v

6 3.3.2 * Shifting Bottleneck-Heuristik * List-Scheduling-Heuristiken * Decomposition Approach * Greedy Randomized Adaptive Search Procedure (GRASP) * Tabu-Suche (Tabu Search) * Branch-and-Bound * Approximierende Algorithmen * Lagrange-Relaxation mit neuronalen Netzen Simulierte Abkühlung (Simulated Annealing) Schwellenakzeptanz (Threshold Accepting) Vergleich der Algorithmen Auswahl Kapitel 4 Implementierung Entwicklungsumgebung Programmiersprache Integration in GORBA Code-Konventionen Klassenübersicht Änderungen an vorhandenen Klassen gorba.optimization gorba.optimization.exceptions gorba.optimization.rulesgj gorba.optimization.rulesres: gorba.optimization.listscheduling gorba.optimization.shiftingbottleneck gorba.optimization.tabusearch gorba.optimization.grasp Softwaretests Komponententest Unit Tests Integrationstests vi

7 4.3.3 Abnahmetest Black-Box-Tests Tests zur Parameterfindung Kapitel 5 Benchmark-Tests Parametrisierung der Algorithmen Ergebnisse der konventionellen Planung Benchmark-Umgebung für die GLEAM-Läufe Ergebnisse der GLEAM-Läufe Kapitel 6 Zusammenfassung Kapitel 7 Fazit/Ausblick Literaturverzeichnis... ix Anhang A Anhang B Ergebnisse von GORBA-Planungen (a)... xii Ergebnisse von GORBA-Planungen (b)... xiii vii

8 Abbildungsverzeichnis Abbildung 1: Maschinenorientiertes Gantt-Diagramm... 5 Abbildung 2: Joborientiertes Gantt-Diagramm... 5 Abbildung 3: Gantt-Diagramm in GORBA zur Darstellung von Schedules Abbildung 4: GORBAs Optionsdialog Abbildung 5: Zeiteinheiten von Ressourcen Abbildung 6: Beispiel zur Pfaderstellung für List Scheduling Abbildung 7: Erstellung der Liste für das List Scheduling Abbildung 8: Problem bei Shifting Bottleneck Abbildung 9: GLEAM-Ergebnisse für die alten Heuristiken Abbildung 10: GLEAM-Ergebnisse für List Scheduling Abbildung 11: GLEAM-Ergebnisse für Shifting Bottleneck Abbildung 12: GLEAM-Ergebnisse für Tabu Search Abbildung 13: GLEAM-Ergebnisse für GRASP viii

9 Tabellenverzeichnis Tabelle 1: Mögliche Werte für α 1 bei der Maschinenumgebung... 6 Tabelle 2: Mögliche Werte für α 2 bei der Maschinenumgebung... 7 Tabelle 3: Mögliche Werte von β 1 bis β 6 bei den Job-Charakteristiken... 7 Tabelle 4: Klassifikation vom GORBA-Problem Tabelle 5: Kriterien zum Vergleichen von Verfahren Tabelle 6: Gegenüberstellung und Bewertung der Verfahren Tabelle 7: Präfixe für Variablen einfachen Datentyps Tabelle 8: Präfixe für Instanzen von Klassen Tabelle 9: Präfixe für Methoden Tabelle 10: Vorhandene Klassen, welche abgeändert wurden Tabelle 11: Klassen im Package gorba.optimization Tabelle 12: Klassen im Package gorba.optimization.exceptions Tabelle 13: Klassen im Package gorba.optimization.rulesgj Tabelle 14: Klassen im Package gorba.optimization.rulesres Tabelle 15: Klassen im Package gorba.optimization.listscheduling Tabelle 16: Klassen im Package gorba.optimization.shiftingbottleneck Tabelle 17: Klassen im Package gorba.optimization.tabusearch Tabelle 18: Parameter für die Tabu-Suche Tabelle 19: Klassen im Package gorba.optimization.grasp Tabelle 20: Parameter für GRASP Tabelle 21: Ergebnisse aus 100 GORBA-Planungen (GRASP) Tabelle 22: Ergebnisse aus 100 GORBA-Planungen (Tabu-Suche) Tabelle 23: Endergebnisse aus den konventionellen Planungen ix

10 Abkürzungsverzeichnis DAG Directed Acyclic Graph (gerichteter azyklischer Graph) EA Evolutionärer Algorithmus FZK Forschungszentrum Karlsruhe GADL Grid Application Definition Language GLEAM General Learning Evolutionary Algorithm and Method GORBA Global Optimising Resource Broker and Allocator GRASP Greedy Randomized Adaptive Search Procedure GRDL Grid Resource Description Language GTA Giffler-Thompson-Algorithmus HW Hardware HWC Hardware Class (Hardware-Klasse) IAI Institut für Angewandte Informatik JSSP Job-Shop-Scheduling-Problem PI-CPLP Pure Integer Capacitated Plant Location Problems RCL Restricted Candidates List SVN Subversion SW Software SWC Software Class (Software-Klasse) ZE Zeiteinheit x

11 Kapitel 1 Einleitung Zeit ist Geld dieser im Jahre 1748 von Benjamin Franklin (Franklin [1]) geprägte Ausspruch ist heute wichtiger denn je: Verschwendung von Zeit bedeutet häufig Ineffizienz und Verzögerungen in Produktions- oder Bearbeitungsprozessen und somit den Verlust von Geld. Entscheidungen dürfen nicht lange dauern und müssen trotzdem korrekt sein. Dies gilt in den meisten Bereichen des täglichen Lebens genauso wie in den komplexen Bereichen der Wissenschaft. Wer Geld verdienen will, muss in der heutigen Welt schnell und effizient sein oder auf schnelle und effiziente Systeme zurückgreifen können. Doch was bedeutet Effizienz eigentlich? Effizienz bedeutet im Allgemeinen, mit wenig Aufwand viel erreichen. Häufig kann die Effizienz von Prozessen durch eine gute und schnelle Planung erhöht werden. Eine solche Planung ist auch im Grid, einer Computerumgebung lose gekoppelter und weltweit verteilter Rechenressourcen, notwendig. Benutzer können Aufträge, sogenannte Jobs, in das Grid einspeisen. Da die Ressourcen im Grid aus wirtschaftlichen Gründen meist nicht kostenlos und nicht zu jeder Zeit zur Verfügung gestellt werden können, ist es für die Benutzer essentiell, dass ihre Jobs schnell, günstig und in einem vorgegebenen zeitlichen Rahmen bearbeitet werden. Deswegen müssen Jobs auf geeignete Weise den vorhandenen Rechenressourcen zugewiesen werden. Der Benutzer möchte nicht lange warten, bevor mit der Bearbeitung der Jobs begonnen werden kann. Weiterhin möchte er nicht viel Geld für die Bearbeitung aufwenden. Aus diesem Grund wurde und wird von Wissenschaftlern und Entwicklern auf der ganzen Welt nach Verfahren zur Erstellung von optimalen Ablaufplänen, nicht nur im Grid, gesucht. Auch im Institut für Angewandte Informatik (IAI) im Forschungszentrum Karlsruhe (FZK) beschäftigten sich Wissenschaftler mit diesen Problemen. Hierzu wurde der Grid Resource Broker GORBA (Global Optimising Resource Broker and Allocator) entwickelt, ein Programm, welches vor allem für die Planung in der Grid-Umgebung und Allokation von Jobs zu Ressourcen benutzt wird. Für diese Aufgabe werden in GORBA integrierte Heuristiken, sowie der extern durch GORBA aufgerufene Evolutionäre Algorithmus (EA) mit dem Namen GLEAM (General Learning Evolutionary Algorithm and Method) (Blume [2]) im FZK verwendet. Diese Verfahren erstellen Belegungsplanungen, auch Schedules genannt, für Ressourcen und ermöglichen eine Bewertung dieser anhand verschiedener Kriterien. Ziel dabei ist, einen möglichst optimalen Schedule in möglichst kurzer Zeit zu erstellen (auch hier liegt der Fokus auf der Effizienz!). In dieser Arbeit werden die zur Erstellung der Schedules entwickelten Methoden verbessert, bzw. durch neue Verfahren erweitert. 1

12 1.1 Aufgabenstellung GORBA (Global Optimising Resource Broker and Allocator) dient in einer Grid- Umgebung der Planung von Jobs, deren Reihenfolge durch Workflows beschrieben wird. Für einen Job steht dabei eine nichtleere Menge an Ressourcen mit normiertem Leistungsfaktor und normierten Kosten pro Zeiteinheit zur Verfügung. Das Ziel sind Belegungsplanungen, die nach anwenderspezifischen Randbedingungen durchgeführt werden und die Ressourcen möglichst gut auslasten. Die Zuweisung von Jobs auf Ressourcen und somit die Erstellung eines Ablaufplanes wird als Scheduling bezeichnet. Aus den Job-Daten werden nach einfachen Heuristiken Reihenfolgen für die Abarbeitung erzeugt, die dann nach weiteren Heuristiken den Ressourcen zugeordnet werden. Die Ergebnisse dieser heuristischen Planung werden mit Hilfe des Evolutionären Algorithmus (EA) GLEAM (Blume [2]) weiter optimiert. Ein neues Vorhaben soll GORBA zu einem adaptiven, lernfähigen System ausbauen, das auf der Basis eines Algorithmen-Pools abhängig vom aktuellen Zustand des Grids durch Auswahl, Parametrisierung und Kombination von Algorithmen angepasste Verfahren für das Scheduling einsetzt. Bislang wurden die bereits implementierten Algorithmen soweit möglich adaptiert. Außerdem wurde der Giffler-Thompson-Algorithmus (GTA) erprobt, welcher sich nicht als sehr hilfreich erwiesen hat. Aufgabe der Bachelorarbeit soll nun sein: Auf der Grundlage von Vorarbeiten (Projektarbeit III, Möser [3]) und weiterer Recherchen neue potentielle Kandidaten für Optimierungsalgorithmen und Heuristiken für das Grid Scheduling finden Algorithmen/Heuristiken beschreiben und implementieren Falls nötig einen weiteren Satz von Benchmarks für vergleichende Studien erstellen Bisherige und neue Algorithmen anhand der Benchmarks in konventionellen Planungen und zusammen mit GLEAM testen und die Ergebnisse auswerten Die Vorhandene Software muss in geringem Umfang modifiziert werden. Erwartetes Ergebnis Das erwartete Ergebnis setzt sich aus den folgenden Aspekten zusammen: 1. Lauffähige Software (mindestens ein weiterer Algorithmus) inklusive vollständiger Dokumentation (Konstruktiver Aspekt) 2. Beschreibung der Algorithmen/Heuristiken (Theoretischer Aspekt) 2

13 3. Durchführung von Testläufen und Benchmarks, sowie die Diskussion der Ergebnisse (Experimenteller Aspekt) Schwerpunkte Es folgen die Schwerpunkte dieser Arbeit: Optimierungsalgorithmen (Recherche, Implementierung, Test) Scheduling Software-Entwicklung Entwicklung von Komponenten Verteiltes Rechnen Arbeitsumgebung Gearbeitet wird während dieser Bachelorarbeit hauptsächlich unter folgenden Rahmenbedingungen: Suse Linux für Software Entwicklung in Java, C und C++ GORBA- und GLEAM-Werkzeuge (Bewertungskomponente, Benchmark- Generator) für Benchmark-Tests unter Suse Linux Windows XP für Office-Arbeiten mit MS Office 1.2 Gliederung der Arbeit In Kapitel 1 wird die Aufgabenstellung erläutert und ein kurzer Einblick in die Thematik gegeben. In Kapitel 2 werden Grundlagen von der Scheduling Theorie sowie GORBA beschrieben und auf die genaue Problematik beim Scheduling im Grid eingegangen. Die Dokumentation der Recherche von Optimierungsalgorithmen folgt in Kapitel 3. Betrachtete Algorithmen werden gegenübergestellt und Ergebnisse der Gegenüberstellung aufgezeigt. Weiterhin wird die Entscheidung für die zur Implementierung gewählten Verfahren erläutert und begründet. Kapitel 4 beschäftigt sich mit der Implementierung der verschiedenen Verfahren und zeigt auf, wie diese in der jeweiligen Programmiersprache umgesetzt wurden. Dazu gehört auch eine Beschreibung der Entwicklungsumgebung und der Integration in GORBA. Im Anschluss daran werden in Kapitel 5 die Erwartungen an die Benchmark-Tests sowie die Benchmark-Tests selbst zur Bewertung der implementierten Verfahren beschrieben und Ergebnisse dieser zusammengestellt, analysiert und Erkenntnisse dargelegt. In 0 folgt eine Zusammenfassung der gesamten Arbeit. Abschließend soll in Kapitel 7 noch ein Ausblick auf die zukünftige Entwicklung gegeben und ein Fazit gezogen werden. 3

14 Kapitel 2 Aktueller Stand der Technik/Grundlagen In diesem Kapitel wird der aktuelle Stand der Technik erklärt, sowie Grundlagen zum Verständnis der Problematik übermittelt. 2.1 Grid-Computing Das Grid-Computing ist eine Art des verteilten Rechnens. Das Grid besteht aus einem Verbund (cluster) von Rechnern, die lose gekoppelt sind und auf der ganzen Welt verteilt sein können. Es wird vor allem in der Forschung eingesetzt, da dort keine Geheimhaltung der Daten notwendig bzw. erwünscht ist, wie beispielsweise in der Industrie. Zusätzlich können die Rechenkapazitäten sehr gut ausgelastet werden. Ian Foster und Carl Kesselman gaben die erste Definition für ein rechenbetontes Grid (computational grid, nachfolgend nur Grid genannt). Sie vergleichen das Grid aufgrund seiner netzartigen Struktur und der Art der (gewünscht einfachen) Zugänglichkeit mit dem elektrischen Stromnetz (electric power grid). Das Grid ist nach Foster [4] eine Hard- und Software-Infrastruktur, welche zuverlässigen, konsistenten, überall vorhandenen und preisgünstigen Zugang zu sehr leistungsstarken Rechenressourcen bietet. Zu der Zeit, als diese Definition gegeben wurde, gab es das Grid allerdings noch nicht. Die Definition wurde später verfeinert, indem der Fokus auf den direkten Zugang zu Ressourcen beliebiger Art (wie z.b. Computer, Software und Daten) statt nur auf das Berechnen von Daten im Grid gelegt wurde. Diese Zugriffe müssen genau definiert sein und die Einhaltung muss sorgfältig überprüft werden. Die zugreifenden Individuen oder Gruppen werden dabei als Virtuelle Organisationen (virtual organization) bezeichnet, bzw. als solche zusammengefasst. Ein Grid hat laut Foster [5] folgende drei Eigenschaften und Aufgaben: Koordination von Ressourcen verschiedener Instanzen Verwendung offener und standardisierter Protokolle Anpassung an komplexe Benutzererwartungen Die Benutzer des Grids können verschiedene Aufgaben an dieses abschicken. Durch die Grid-Infrastruktur müssen dann die erforderlichen Ressourcen alloziert werden und Ablaufpläne erstellt werden. Anschließend sollen die Aufgaben durch das Grid abgearbeitet werden. Dieser Vorgang soll automatisch geschehen, so dass der Benutzer das Grid über standardisierte Schnittstellen verwenden kann und nicht mit den Einzelheiten vertraut sein muss. Die Schnittstellen werden über eine Software, der sogenannten Middleware, zur Verfügung gestellt. 4

15 2.2 Scheduling-Theorie In diesem Abschnitt werden Begriffe aus der Scheduling-Theorie eingeführt. Die Ausführungen lehnen sich an Brucker [6] an. In der Scheduling-Theorie wird meist von Maschinen und Jobs, welche auf den Maschinen ausgeführt werden müssen, gesprochen. Ein Belegungsplan wird in diesem Zusammenhang als Schedule bezeichnet. Ein solcher beinhaltet alle Jobs mit zeitlicher Zuordnung zu den für sie relevanten Maschinen. Durch einen Schedule wird der Ablauf der Jobs eindeutig festgelegt Scheduling-Probleme Es gebe m Maschinen M j (j = 1,, m), welche n Jobs J i (i = 1,, n) bearbeiten müssen. Ein Schedule ist eine Allokation von einem oder mehreren Zeitintervallen auf einer Maschine zu jedem Job. Gantt-Diagramme ermöglichen eine übersichtliche Darstellung dieser Schedules. Es ist möglich, maschinenorientierte (Abbildung 1) oder joborientierte (Abbildung 2) Diagramme zu verwenden. Abbildung 1: Maschinenorientiertes Gantt-Diagramm Abbildung 2: Joborientiertes Gantt-Diagramm Job-Daten Ein Job J i besteht aus n i Operationen O i1,, O i,ni. Operation O i1 ist die erste Operation von Job J i. Jeder Operation O ij ist eine Bearbeitungszeit p ij zugeordnet und jeder Job J i besitzt eine Freigabezeit r i. Sie gibt die Zeit an, zu welcher mit der Bearbeitung von Operation O i1 begonnen werden kann. Zudem gibt es für die Jobs noch ein Fälligkeitsdatum d j. Diese Daten können in der Zielfunktion f i (t) benutzt werden. Die Funktion berechnet die Kosten, die für die Fertigstellung von J i zum Zeitpunkt t entstehen. Weiterhin kann f i mittels w i gewichtet werden, um einem Job mehr oder weniger Bedeutung in der endgültigen Bewertung zuzumessen. Jeder Operation O ij ist eine Menge von Maschinen μ ij {M 1,, M m } zugeordnet, wobei die Operation auf jeder dieser Maschinen bearbeitet werden kann. 5

16 2.2.3 Klassifizierung von Scheduling-Problemen Um eine Klassifizierung von Scheduling-Problemen zu ermöglichen, wurden Kriterien für Jobs, Maschinenumgebungen und Optimierungsmöglichkeiten/Zielfunktion eingeführt (Graham et al. [7]). Diese werden üblicherweise als 3-Feld-Klassifikation α β γ dargestellt. Jedes der Felder ist für ein Kriterium verantwortlich; α für die Maschinenumgebung, β für die Jobeigenschaften und γ für die Zielfunktion. Folgend wird ein Überblick der Mittel zur Klassifizierung gegeben Maschinenumgebung (α) Um die Maschinenumgebung zu beschreiben, wird α weiter aufgeteilt in α 1 und α 2 (α=α 1 α 2 ). Für α 1 sind nach Brucker [6]die folgenden Werte möglich:, P, Q, R, PMPM, QMPM, G, X, O, J, F Die Bedeutungen sind in Tabelle 1 aufgelistet: Tabelle 1: Mögliche Werte für α 1 bei der Maschinenumgebung Wert P Q R PMPM QMPM G J Bedeutung Jeder Job besitzt nur eine Operation. Für jeden Job gibt es eine dedizierte Maschine (einzige Maschine, auf der der Job abgearbeitet werden kann). Jeder Job besitzt nur eine Operation. Identische parallele Maschinen, auf welchen jeder der Jobs ausgeführt werden kann. Ein Job läuft auf jeder Maschine gleichschnell. Jeder Job besitzt nur eine Operation. Gleichartige parallele Maschinen, auf welchen jeder der Jobs ausgeführt werden kann. Ein Job läuft auf jeder Maschine unterschiedlich schnell, abhängig von ihrer Geschwindigkeit. Jeder Job besitzt nur eine Operation. Nicht gleichartige parallele Maschinen, auf welchen jeder der Jobs ausgeführt werden kann. Ein Job läuft auf jeder Maschine unterschiedlich schnell. Jede Maschine kann unterschiedliche Geschwindigkeiten für unterschiedliche Jobs besitzen. (Ein Job kann langsam bearbeitet werden, ein anderer schnell, obwohl die gleiche Maschine benutzt wird.) Jeder Job besitzt nur eine Operation. Identische Mehrzweckmaschinen (Maschinen, die mit speziellen Werkzeugen/spezieller Software ausgestattet sind, um verschiedenartige Jobs bearbeiten zu können). Jeder Job besitzt nur eine Operation. Gleichartige Mehrzweckmaschinen. Jeder Job kann aus mehreren Operationen bestehen. Für jede Operation gibt es eine dedizierte Maschine (einzige Maschine, auf der die Operation abgearbeitet werden kann). Es gibt Rangordnungen zwischen beliebigen Operationen. General Shop Siehe G, aber Rangordnungen sind nicht beliebig, sondern in der Form: O i1 O i2 O i3... O i,ni für i = 1,, n Zudem wird im Allgemeinen angenommen, dass zwei aufeinanderfolgende Operationen nicht auf der gleichen Maschine 6

17 F O X bearbeitet werden. Job Shop Siehe J, wobei jeder Job genauso viele Operationen besitzt, wie Maschinen existieren und jede Operation auf jeder der Maschinen ausgeführt werden kann. Flow Shop Siehe F, aber ohne Rangordnungen bei den Operationen. Kombination aus J und O. Mixed Shop Für α 2 sind die Werte x N, k, möglich. Beschrieben werden diese in Tabelle 2. Tabelle 2: Mögliche Werte für α 2 bei der Maschinenumgebung Wert x N k Bedeutung x N steht hierbei für einen Platzhalter, welcher durch eine positive ganze Zahl ersetzt wird. Diese gibt die Anzahl der Maschinen an. Die Anzahl der Maschinen ist beliebig, aber vorgegeben. Die Anzahl der Maschinen ist nicht vorgegeben Job-Charakteristiken (β) Die durch β beschriebenen Job-Charakteristiken lassen sich weiter in β 1 bis β 6 aufteilen, sodass gilt: β = β 1 β 2 β 3 β 4 β 5 β 6. Dabei macht β 1 Aussagen dazu, ob Jobs/Operationen unterbrochen werden dürfen. β 2 behandelt die Rangordnungen zwischen einzelnen Jobs und β 3 die Freigabezeiten der Jobs. β 4 wird für die Bearbeitungszeiten von Jobs benutzt und β 5 für Bearbeitungsfristen. β 6 gibt schließlich an, ob es sich bei dem Problem um ein Batch-Problem handelt (wobei mehrere Jobs zu einem Stapel (batch) zusammengefasst werden müssen). Einzelne Komponenten können aus β weggelassen werden, falls keiner der für sie möglichen Werte zutrifft. Die laut Brucker [6] möglichen Werte für die einzelnen Komponenten von β werden in Tabelle 3 erläutert. Tabelle 3: Mögliche Werte von β 1 bis β 6 bei den Job-Charakteristiken mögliche Werte Bedeutung β 1 pmtn Gibt an, dass das Unterbrechen und die spätere Wiederaufnahme von Jobs oder Operationen möglich sind. β 2 prec Die Prioritätsbedingungen der Jobs können als azyklischer gerichteter Graph dargestellt werden. intree Die Prioritätsbedingungen der Jobs können als Intree dargestellt werden. (Intree = gerichteter Graph mit einer Wurzel, welche von jedem anderen Knoten im Graph durch genau einen gerichteten Pfad erreichbar ist.) outtree Die Prioritätsbedingungen der Jobs können als Outtree dargestellt werden. (Outtree = gerichteter Graph mit einer Wurzel, von welcher jeder andere Knoten im Graph durch genau einen gerichteten Pfad erreichbar ist.) tree Die Prioritätsbedingungen der Jobs können als In- oder Outtree 7

18 dargestellt werden. cains Die Prioritätsbedingungen der Jobs können als In- oder Outtree mit einem Indegree und Outdegree von jeweils 1 dargestellt werden (von jedem Knoten im Graph gibt es nur maximal eine ausgehende und eine eingehende Kante). sp grap Die Prioritätsbedingungen der Jobs können als Series-parallel graph dargestellt werden. Ein SP-Graph ist ein Graph, welcher genau einen Startknoten (source) und genau einen Endknoten (sink) hat. β 3 r i Für jeden Job kann eine Freigabezeit angegeben werden. β 4 p i Für jeden Job kann eine Bearbeitungszeit angegeben werden. β 5 d i Für jeden Job gibt es eine maximale Fertigstellungszeit, die für jeden Job angegeben werden muss. β 6 p batc Die Jobs können zu einem zusammenhängenden Stapel zusammengefasst werden. Die Länge des Stapels ist gleich dem Maximum der Bearbeitungszeiten seiner Jobs. s batc Die Jobs können zu einem zusammenhängenden Stapel zusammengefasst werden. Die Länge des Stapels ist gleich der Summe aller Bearbeitungszeiten seiner Jobs Zielfunktion (γ) Die Zielfunktion gibt an, nach welchen Gesichtspunkten der Schedule optimiert werden soll. Dabei gibt es zwei Standardfunktionen; das Flaschenhalsziel (bottleneck objective) und das Summenziel (sum objective). Es sei C i die Fertigstellungszeit von Job J i. f i (C i ) seien die Kosten, die Fertigstellungszeit zu erreichen. Dabei ist f max (C) n max f i C i i = 1,, n ein Flaschenhalsziel und f i (C) i=1 f i (C i ) ein Summenziel. Demnach kann γ die Werte f max oder f i annehmen. Aber es können auch genauere Ziele für f i in γ angegeben werden. Mögliche Ziele sind zum Beispiel: Minimierung der maximalen Bearbeitungsdauer (makespan) Minimierung der gesamten Flusszeit (total flow time) Minimierung der gewichteten gesamten Flusszeit (weighted total flow time) Minimierung der Verspätung von Jobs (lateness) Maximierung der Frühzeitigkeit von Jobs (earliness) Minimierung der Unpünktlichkeit von Jobs (tardiness) Minimierung der absoluten Abweichung der Jobs von ihren Fertigstellungsterminen (absolute deviation) Minimierung der Abweichung von Jobs von ihren Fertigstellungsterminen (squared deviation) 8

19 2.3 Job-Shop-Scheduling-Problem (JSSP) Das JSSP wird häufig als Vergleich mit anderen Problemen oder als Grundlage für Algorithmen herangezogen. Deshalb soll es auch hier kurz aufgeführt werden. Es gibt beim JSSP m Maschinen M 1,, M m und n Jobs i = 1,, n. Die Jobs bestehen aus n i Operationen O i1, O i2,, O ini. Bei den Operationen gibt es Vorgänger -und Nachfolgerbeziehungen ( O ij O ij +1 ; j = 1,, n i 1 ), da sie in genau dieser Reihenfolge abgearbeitet werden müssen. Im zugehörigen Schedule ist jeder Operation O ij eine Maschine μ ij und eine Bearbeitungszeit p ij zugeordnet, wobei eine Operation aus allen Maschinen wählen kann. Dabei wird angenommen, dass aufeinanderfolgende Operationen auf jeweils unterschiedlichen Maschinen bearbeitet werden. Eine Operation hat immer nur einen direkten Vorgänger bzw. Nachfolger. Weiterhin ist die Bearbeitungszeit fest der jeweiligen Operation zugeordnet und nicht zusätzlich von einer Maschine abhängig. Maschinen besitzen auch keine Verfügbarkeitszeiten, sondern stehen jederzeit zur Verwendung bereit. Das Optimierungsproblem des klassischen JSSP mit J C max ist bekanntermaßen NPhart (siehe z.b. Lenstra [8] oder Schuster [9]). 2.4 GORBA-Problem Das GORBA-Problem ist aufgrund mehrerer Randbedingungen komplexer als das ohnehin schon NP-harte JSSP. Wie beim JSSP ist auch hier das Ziel, optimale oder möglichst optimale Schedules in einer sehr kurzen Zeit zu erzeugen. In den folgenden Abschnitten soll auf diese Problematik genauer eingegangen werden. Die Begriffe sind im Gegensatz zum JSSP bei GORBA und der Grid-Umgebung im FZK anders definiert. Eine Übersicht wird in diesem Abschnitt gegeben. Für sehr detaillierte Ausführungen dazu sei auf Jakob et al. [10] und [11] verwiesen Ressource Die Ressource entspricht im JSSP der Maschine. Bei GORBA kann eine Ressource nochmals unterteilt werden in Hardwareressource (z.b. ein Rechner), Softwareressource (z.b. ein Bildbearbeitungsprogramm) und Datenressource (z.b. das Ergebnis einer Berechnung). Verschiedene Ressourcen können in Klassen zusammengefasst werden, welche dann jeweils als Hardwareklasse, Softwareklasse oder Datenklasse bezeichnet werden. Die Ressourcen einer Klasse besitzen insofern gleiche Eigenschaften, als dass sie alternativ einsetzbar sind. Sie können z.b. unterschiedlich schnell oder zu unterschiedlichen Zeiten verfügbar sein. Bei der Planung können zunächst die Klassen an sich durchsucht werden können. Die Ressourcen werden mithilfe der GRDL (Grid Resource Definition Language), einer auf 9

20 der GADL (Grid Application Definition Language) aufbauenden und für die Verwendung mit GORBA angepassten Beschreibungssprache, beschrieben. Verschiedene Ressourcen/-Klassen können andere Ressourcen/-Klassen bereitstellen oder von ihnen abhängig sein. HWC bedeutet Hardware-Klasse, SWC bedeutet Software-Klasse. HW und SW geben wiederum Hardware- und Software-Instanzen an. Datenressourcen spielen zurzeit bei GORBA noch keine Rolle. Stellt eine Ressource eine andere bereit, so wird dies mit dem Stichwort provides angezeigt. Ist eine Ressource von einer anderen abhängig, so wird dies mit depends deutlich gemacht. Gridjobs können verschiedene Ressourcenklassen als Voraussetzungen besitzen. In diesen Klassen muss dann für eine Zuordnung nach einer Instanz der Ressource gesucht werden. Sind keine Instanzen dieser Ressourcen (zum gewünschten Zeitpunkt) vorhanden, so kann der Gridjob nicht ausgeführt werden Applicationjob Der Applicationjob entspricht dem Job im JSSP. Er besteht aus einem oder mehreren Gridjobs. Alle Applicationjobs sind parallel und besitzen zueinander keine Vorgängeroder Nachfolgerbedingungen. Als Graph betrachtet besitzt jeder Applicationjob jeweils einen (Pseudo-)Gridjob als Start und einen weiteren als Ziel. Diese besitzen außer der Kennzeichnung von Start und Ziel keine Funktion. Unmittelbar nach dem Start-Gridjob folgen in dem Graph alle Gridjobs, welche keinen Vorgänger-Gridjob besitzen. Umgekehrt befinden sich alle Gridjobs ohne Nachfolger-Gridjob unmittelbar vor dem Ziel-Gridjob. Der Graph ist gerichtet und azyklisch, so dass es auf keinen Fall zu Endlosschleifen bei der Bearbeitung kommen kann. Im Gegensatz zum JSSP sind mehrere Nachfolger für Gridjobs, also Verzweigungen innerhalb des Applicationjobs, möglich Gridjob Der Gridjob ist die kleinste verplanbare Einheit bei GORBA und entspricht somit einer Operation im JSSP. Gridjobs können parallel ablaufen. Zudem kann ein Gridjob mehrere Vorgänger und Nachfolger besitzen. Gibt es für einen Gridjob einen oder mehrere Vorgänger, so müssen diese zuerst fertig abgearbeitet werden, damit der Gridjob gestartet werden kann. Im Falle von Vorgänger- und Nachfolgerbeziehungen ist eine Kommunikationszeit vorgesehen, welche aber aktuell von GORBA nicht in Betracht gezogen wird. Ein Gridjob besitzt Anforderungen an Ressourcen. Bei der Planung des Gridjobs wird eine passende Ressource aus einem Ressourcenpool ausgewählt und der Gridjob wird auf dieser eingeplant. 10

21 2.4.4 Klassifizierung Ausgehend von den in Abschnitt gegebenen Klassifizierungsmöglichkeiten für Scheduling-Probleme soll nun eine Einordnung des GORBA-Problems erfolgen. Eine Klassifizierung nach Brucker [6] ist schwer möglich, da sich die Umgebung und die Anforderungen für GORBA nicht ohne Weiteres in die gegebenen Szenarien einordnen lassen. In Tabelle 4 werden die Werte für die vorgestellten Parameter für das GORBA- Problem festgelegt. Tabelle 4: Klassifikation vom GORBA-Problem α 1 GMPM Es handelt sich beim GORBA-Problem nicht mehr um ein Shop-Scheduling- Problem nach Brucker [6], da keine der vorgeschlagenen Maschinenumgebungen zutrifft. Deshalb wird die Maschinenumgebung auf den Wert GMPM (Gorba Multi Purpose Mashines) gesetzt. α 2 Ø Die Anzahl der Ressourcen ist nicht festgelegt. β 1 Ø Das Unterbrechen der Abarbeitung von Applicationjobs und Gridjobs ist nicht möglich. β 2 prec Es existieren Vorgänger- und Nachfolgerbeziehungen und die Applicationjobs können als direkte azyklische Graphen dargestellt werden. β 3 r i Applicationjobs besitzen eine früheste Startzeit, welche vom Benutzer angegeben werden kann. Ist keine Zeit vom Benutzer angegeben, so wird der Wert 0 verwendet. β 4 t(i, μ i ) Laufzeiten von Gridjobs (und somit auch Applicationjobs) sind abhängig von den Ressourcen, auf welchen die Gridjobs laufen, und von den Gridjobs selbst (μ i gibt die Ressource an, zu welcher Gridjob i zugeordnet ist). β 5 d i Für jeden Applicationjob kann ein maximaler Endzeitpunkt vom Benutzer festgelegt werden. β 6 Ø Applicationjobs werden nicht zu Batches zusammengefasst. γ Fitness Als Optimalitätskriterium wird eine Bewertungsfunktion herangezogen, welche die Fitness eines Schedules berechnet. Die Fitness-Funktion verwendet die Kriterien Makespan, Auslastung, Makespan der einzelnen Applicationjobs und die Kosten der Applicationjobs. Zusammengefasst kann das GORBA-Problem mit GPMP prec, r i, t i, μ i, d i Fitness beschrieben werden. In Hahnenkamp [12] gibt es eine alternative Einordnung für das GORBA-Problem, welche Kosten von Applicationjobs einbezieht und ebenfalls an die Notation in Brucker [6] angelehnt ist. Dort wird allerdings angegeben, dass Applicationjobs keine früheste Startzeit besitzen. Nach aktuellem Stand besitzen Applicationjobs einen solchen aber. 11

22 2.4.5 Komplexität Da das GORBA-Problem in keinem Punkt das JSSP vereinfacht, sondern im Gegenteil komplexer ist, ist auch das GORBA-Problem NP-hart. In Hahnenkamp [12] wird eine Beweisskizze gegeben, welche das GORBA-Problem als Ausgangspunkt verwendet. Durch Vereinfachungen des Problems geht schließlich das generelle JSSP hervor. 2.5 GORBA GORBA (Global Optimising Resource Broker and Allocator) ist eine in Java entwickelte Middleware für das Grid, die für die Erstellung von Schedules. Zudem lässt es den Benutzer den Ablauf des Schedules verfolgen. Beispielsweise kann beobachtet werden, welcher Gridjob bereits bearbeitet wurde oder welche Gridjobs noch auf die Bearbeitung warten. Zu GORBA gehören verschiedene Werkzeuge, wie ein Applikationsdesigner, ein Benchmark-Generator und eine externe Komponente zur Bewertung von Schedules. Zurzeit werden alle Daten, mit denen GORBA arbeitet, in XML nach vorgegebenen XML-Schemata gespeichert. Zu diesen Daten gehören Ressourcenbeschreibungen, Applicationjobs, Schedules und Listen von Schedules. Die Software soll dem Benutzer die Aufgaben des Ressourcenmanagements abnehmen, indem sie automatisch die Allokation und Planung der Ressourcen durchführt. Die dabei entstehenden Schedules sollen eigentlich optimal sein. Da dies aufgrund der Komplexität des GORBA-Problems sowie der kurzen verfügbaren Planungszeit nicht oder nur sehr unwahrscheinlich zu erreichen ist, wird ein möglichst optimaler Schedule als Ziel angesehen. In der Praxis bedeutet das, dass ein optimierter Schedule besser als das beste heuristische Ergebnis sein soll. Dabei muss bedacht werden, dass Benutzer verschiedene Anforderungen an Optimierungsziele stellen können. Wichtige Ziele sind hier die Termintreue, die Gesamtbearbeitungszeit und die Gesamtkosten des Schedules. Weiterhin ist es möglich, dass Benutzer für eine schnelle Bearbeitung bereit sind, mehr zu zahlen, und umgekehrt Verzögerungen im Gegenzug zu einer Kostenverminderung hinnehmen. Allerdings müssen auch für die Ressourcenanbieter relevante Ziele, wie z.b. eine gute allgemeine Auslastung der Ressourcen und ein guter Durchsatz an Applicationjobs, beachtet werden. Dies soll sicherstellen, dass andere Benutzer stets genügend freie Rechenressourcen vorfinden, auf denen ihre Applicationjobs laufen können und somit mehr Benutzer durch die gleiche Menge an Ressourcen bedient werden können. GORBA plant die Ressourcenverteilung in einem gering ausgelasteten Grid konventionell, wofür die bereits vorhandenen und implementierten Heuristiken benutzt werden. Gibt es allerdings Konflikte oder längere Wartezeiten bei der Planung, so wird GLEAM für die Planung verwendet. Die Planung in einem nicht stark beanspruchten Grid ist nicht so aufwendig, denn da mehr Ressourcen für einen 12

23 Schedule verfügbar sind, kommt es seltener zu Konflikten. Probleme treten meist bei der Planung in einem stärker ausgelasteten Grid auf. Gridjobs können aufgrund von möglicherweise bereits vorhandenen Belegungen oder aufgrund von grundsätzlichen Verfügbarkeitszeiten von Ressourcen zu einem beliebigen Zeitpunkt auf dieser Ressource eingeplant werden. Somit kann es sehr schwierig werden, Schedules zu erstellen. Es entstehen zwangsweise Wartezeiten. Zusätzlich kann es Benutzer mit unterschiedlichen Anforderungen geben, so dass die Planung nochmals komplexer wird, da die Anforderungen aller Nutzer beachtet werden sollen. GLEAM kann dort ansetzen und die Planung für alle Benutzer möglichst optimal und somit zu deren Zufriedenheit erstellen. Zur Darstellung eines Schedules benutzt GORBA maschinenorientierte Gantt-Diagramme (siehe Abbildung 3). In diesen werden nicht verfügbare Zeitschlitze durch einen schwarzen Balken dargestellt. Abbildung 3: Gantt-Diagramm in GORBA zur Darstellung von Schedules Schedules werden durch die GORBA-Bewertungskomponente anhand von vier Kriterien bewertet. Diese Kriterien sind: Gesamte Makespan (möglichst minimale Bearbeitungsdauer) Makespan von Applicationjobs (möglichst minimale Bearbeitungsdauer) Kosten von Applicationjobs (möglichst geringe Kosten) Auslastung von Ressourcen (möglichst hohe Auslastung) Bei Überschreitungen bestimmter Werte, welche von Fall zu Fall unterschiedlich sein können, da sie vom Benutzer vorgegeben werden können, treten bei der Bewertung Straffunktionen ein, welche ein Ergebnis deutlich verschlechtern können. 13

24 2.6 GLEAM GLEAM (General Evolutionary Algorithm and Method) ist ein EA (Evolutionärer Algorithmus) und kann für die Optimierung von Schedules beim Grid-Scheduling im FZK verwendet werden. Der EA wird in (Blume [2]) beschrieben. Einfache Heuristiken können Schedules erzeugen, welche dann von GLEAM optimiert werden. Dieser Schritt ist aber nicht zwingend erforderlich, es reichen auch einfache Job-Sequenzen. Ziel dabei ist es, einen Schedule innerhalb von 3 Minuten möglichst zu optimieren. Die Zeit wurde bei früheren Benchmarks auf 3 Minuten gesetzt (und wurde auch noch nicht herabgesetzt), weil es als realistisch erachtet wurde, in dieser Zeit die Startpopulation genügend verbessern zu können. 2.7 Heuristik Eine Heuristik ist ein Algorithmus, welcher mit geringem Rechenaufwand unter Verwendung von einfachen Faustregeln innerhalb kurzer Zeit eine gute Lösung für ein bestimmtes Problem finden soll (Gumm [13]). Ziel ist nicht die exakte Lösung des Problems. Dabei ist nicht garantiert, dass der Algorithmus für jedes der Probleme schnell ist und gute Lösungen bietet. Diese sind zwar meist nicht das Optimum, aber gemessen am Rechenaufwand der Suche nach dem Optimum bezüglich einer Kosten- Nutzen-Betrachtung oft deutlich überlegen. Die Güte ist allerdings nicht allgemein nachweisbar. 2.8 Metaheuristik In der Mathematik und Informatik sind Metaheuristiken Heuristiken, die approximierte Lösungen für Optimierungsprobleme finden, wobei jedoch keine Faustregeln, sondern abstrakte Schritte definiert werden. Die Metaheuristiken können somit auf eine Vielzahl von Problemen angewendet werden, müssen aufgrund dessen aber auch auf diese Probleme hin angepasst werden. Häufig werden sie verwendet, wenn kein effizienter Lösungsalgorithmus bekannt ist. Eine besondere Güte von Ergebnissen kann nicht garantiert werden. Metaheuristiken benötigen Hilfsprozeduren, welche für die eigentlichen Entscheidungen zuständig ist. 2.9 Risiken Für die Implementierung und die Ergebnisse ist es wichtig, mit den möglichen Problemen und Risiken vertraut zu sein, welche bei dem GORBA-Problem auftreten könnten, um Fehler zu vermeiden. Das erste Problem ist, dass bei der Auswahl der Algorithmen nur auf Ergebnisse mit dem JSSP oder anderen (z.b. spezialisierten) Scheduling-Problemen zurückgegriffen werden kann. Da jeder Algorithmus angepasst werden muss, ist es nicht möglich, genaue Aussagen bezüglich der Eignung für das GORBA-Problem zu machen. Aussagen 14

25 über den Erfolg können erst nach der Implementierung gemacht werden. Das kann zur Folge haben, dass in Wirklichkeit ungeeignete Algorithmen gewählt werden. Da es zeitlich nicht möglich ist, alle Algorithmen im Verlauf dieser Arbeit zu implementieren, müssen einige der zur Auswahl stehenden Verfahren ausgewählt werden. Durch eine umfangreiche und genaue Analyse ist dieser Effekt abzuschwächen. Die abschließenden Benchmark-Tests und deren Auswertung dauern erfahrungsgemäß sehr lange. Für jeden implementierten Algorithmus wird dazu die gleiche Zeit veranschlagt. Die Benchmarks für verschiedene Algorithmen können aufgrund gegebener Strukturen nicht gleichzeitig ausgeführt werden. Die Benchmark-Umgebung ist vorgegeben und wird in Kapitel 5 näher betrachtet. Eine Absicherung ist durch einen rechtzeitigen Beginn der Benchmarks möglich. Dies wurde bei der Projektplanung einberechnet. Für die Benchmarks sollen zum Vergleich alte Werte herangezogen werden. Wichtig ist hier, dass diese Werte von Benchmarks auf den gleichen Rechenressourcen zustande gekommen sind. Ansonsten müssen diese bereits vorhandenen Benchmarks nochmals auf den bereitstehenden Rechnern durchgeführt werden. Ist dies der Fall, so könnte es passieren, dass die bereits vorhandenen Heuristiken aufgrund der höheren Rechenleistung so gute Ergebnisse liefern, dass ein Vergleich mit neu implementierten Verfahren aufgrund von zu kleinen Unterschieden nicht mehr sinnvoll ist. 15

26 Kapitel 3 Recherche Um verschiedene Verfahren betrachten und vergleichen zu können, musste eine umfassende Literaturrecherche erfolgen. Dieses Kapitel beschreibt, wie diese Recherche durchgeführt wurde, welche Ergebnisse dabei herauskamen und wie diese einzuschätzen und zu verwerten sind. 3.1 Methodik Als Quelle für die Recherche wurden hauptsächlich das Internet und grundlegende Bücher zur Scheduling-Theorie benutzt. Im Internet wurden für die Suche folgende Seiten verwendet: (Google) (CiteSeerX) (Scirus) (ScienceDirect) Außerdem wurden die aus der Vorrecherche hervorgegangenen Dokumente benutzt. Diese wurden zur besseren Nachvollziehbarkeit soweit möglich auf den IAI-internen Server abgelegt. 3.2 Allgemeine Zusammenfassung der Ergebnisse Zunächst wurden die bereits bekannten Ergebnisse und Erkenntnisse zum Scheduling im Grid zusammengefasst. Es ist wichtig, diese Erkenntnisse bei der Recherche nach neuen Verfahren mit einzubeziehen. Dadurch wird es möglich, sowohl Risiken als auch mögliches Potential besser abzuwägen. In Sonnleithner [14] wird beschrieben, wie der Giffler-Thompson-Algorithmus (GTA) in GORBA integriert wurde. Die Integration brachte nach Ergebnissen aus zahlreichen Benchmark-Läufen keine Verbesserungen für den Evolutionären Algorithmus GLEAM (Jakob et al. [15]). Daraufhin wurde in einer vorangegangenen Projektarbeit eine Internetrecherche zu Alternativen für den GTA bzw. für die weiteren existierenden Heuristiken durchgeführt. Dafür wurden in der Vorarbeit zunächst der GTA und anschließend weitere Algorithmen untersucht. Auch in dieser Arbeit werden noch weitere Verfahren untersucht. Es stellte sich heraus, dass es viele alternative, aussichtsreiche Verfahren gibt. Diese Einschätzungen konnten bisher nur aufgrund von Literaturangaben getätigt werden. Für eine Vergleichsgrundlage wurden verschiedene Anforderungen an die Algorithmen für die Verwendung in GORBA gestellt. Diese Punkte wurden in der 16

27 Projektarbeit ungewichtet bewertet. Welche Punkte die Algorithmen bewältigen müssen, wird in Abschnitt 3.4 beschrieben. Oftmals konnte keine konkrete Aussage getroffen werden, da die Literatur viele der Punkte nicht genau benennt. Für einen genauen Vergleich müssen die Verfahren implementiert und ihre Verwendbarkeit über Benchmarks ausgewertet werden. Die als am vielversprechendsten eingeschätzten Verfahren werden in dieser Arbeit genauer untersucht. Eine erneute Bewertung mit Betrachtung weiterer Algorithmen und weiterer Bewertungspunkte findet in Abschnitt 3.4 statt. 3.3 Heuristiken und Algorithmen Die untersuchten Heuristiken und Algorithmen werden in diesem Abschnitt kurz vorgestellt und zusammengefasst. Auf die zur Bearbeitung gewählten Verfahren wird im nachfolgenden Abschnitt 3.4 sowie bei den Ausführungen zur Implementierung in Kapitel 4 noch genauer eingegangen. Bereits im Vorfeld zu dieser Arbeit betrachtete Verfahren werden durch ein vorangestelltes Sternchensymbol (*) gekennzeichnet. Diese sind hier nur kurz beschrieben, um einen Überblick zu gewährleisten. Ausführlicher sind sie in den jeweiligen Quellen und auch in der Vorarbeit (Möser [3]) abgehandelt. Allerdings wurden einige Aussagen überarbeitet. Die tatsächlich implementierten Algorithmen werden in Kapitel 4 bei der Implementierung ausführlicher und mit Beschreibungen der notwendigen Modifikationen beschrieben * Giffler-Thompson-Algorithmus (GTA) Einordnung: Heuristik Ziel: Erstellen von aktiven Schedules Der GTA ist eine Heuristik, welche bereits in GORBA integriert wurde. Der Angepaste GTA wird sehr ausführlich in Sonnleithner [14] beschrieben. Im Allgemeinen wird so vorgegangen, dass aus einer Menge von Ressourcen(-gruppen) eine als nächstes zu belegende gewählt wird. Für diese Ressource(-ngruppe) wird dann der nächste Gridjob, der verplant werden soll, anhand einer Prioritätsregel aus einem Gridjob-Pool ausgewählt. Dies wird gemacht, bis alle Gridjobs verplant sind. Vorgänger- und Nachfolgerbedingungen, ressourcenbedingte Bearbeitungszeiten der einzelnen Gridjobs sowie die Ressourcenabhängigkeiten der Gridjobs waren Teil der Anpassung an das GORBA-Problem * Shifting Bottleneck-Heuristik Einordnung: Heuristik Ziel: Minimierung der Makespan beim JSSP Shifting Bottleneck ist eine Heuristik, welche das JSSP in kleinere Probleme zerlegt, indem versucht wird, nacheinander die Flaschenhälse, im Idealfall 1-Maschinen- 17

28 Probleme, zu optimieren. Für jede Maschine wird dafür ein Schedule unter Verwendung der Earliest-Due-Date-Regel erstellt. Dann wird für jede Maschine die maximale Verspätung berechnet und danach alle Maschinen nach dieser Verspätung absteigend angeordnet. Ist eine Maschine rechtzeitig, so ist die Verspätung 0, bei einer frühzeitigen Maschine gar negativ. Auch diese Maschinen können somit eingeordnet werden. Die Maschinen werden danach dieser Ordnung entsprechend in den gesamten Schedule eingeplant. Das bedeutet, dass zunächst die Jobs der Maschine mit der maximalen Verspätung verplant werden, danach die der zweithöchsten Verspätung, und so weiter. Dabei werden keine Vorgänger- und Nachfolgerbeziehungen beachtet. Weiterhin müsste jeder Gridjob hierbei direkt eine Maschine benötigen, auf der er geplant werden kann. Varianten der Shifting Bottleneck-Heuristik werden in Adams et al. [16] und Dauzere-Peres [17] vorgestellt. In Chen et al. [18] wird eine Variante mit parallelen Maschinen betrachtet. Einige Ansätze aus dieser Arbeit können für die GORBA-Umgebung verwendet werden * List-Scheduling-Heuristiken Einordnung: Heuristik Ziel: Erstellen eines gültigen Schedules anhand von Prioritäten Die List-Scheduling-Heuristiken werden in der Literatur als sehr leicht zu implementieren beschrieben Schuster[9]. Sie ordnen die Operationen nach bestimmten Kriterien in eine Liste und erstellen daraus einen Schedule. Laut Hurink [19] gibt es zwei Herangehensweisen, List-Scheduling-Heuristiken anzuwenden, wobei es bei beiden sehr unwahrscheinlich ist, optimale Schedules zu erzeugen. Die erste Herangehensweise ist, zunächst die Zuordnung der Jobs zu Maschinen, und anschließend die Reihenfolge zu bearbeiten. Die Bearbeitung der Reihenfolge ist dabei ein NP -hartes Teilproblem, so dass dieser Ansatz verworfen wird. Die zweite Möglichkeit ist, zuerst die Reihenfolge und danach die Zuordnung zu Maschinen zu bearbeiten. Diese Methode kann für Probleme mit Vor- und Nachfolgebeziehungen allerdings nicht immer gute Lösungen bieten, wie in Hurink [19] gezeigt wird. In Tchimou N'Takpé [20] wird ein Critical-Path Ansatz beschrieben, welcher sich für die Erstellung der Liste anbietet. Eine solche Lösung könnte für GORBA verwendet werden, sollte diese Heuristik zur Bearbeitung gewählt werden * Decomposition Approach Einordnung: Heuristik Ziel: Erstellen eines Schedules durch Zerlegung des Problems in Teilprobleme Beim Decomposition Approach wird versucht, durch Zerlegung des JSSP in 1- Maschinen-Probleme einen Schedule zu erstellen. Der Ansatz ähnelt dem Shifting Bottleneck, bis auf die Ausnahme, dass hier keine Einschränkung gemacht wird, in 18

29 welcher Reihenfolge die Maschinen optimiert werden müssen. Beschrieben wird eine mögliche Variante in Raman [21] * Greedy Randomized Adaptive Search Procedure (GRASP) Einordnung: Metaheuristik Ziel: Näherungslösung Dieses Verfahren besteht aus vielen unabhängigen GRASP-Schritten. In jedem dieser GRASP-Schritte wird eine zufällige Lösung mithilfe einer als eingeschränkte Liste von Kandidaten (RCL, restricted candidates list) bezeichneten Liste erzeugt. Diese Liste dient zum Finden eines Gridjobs, welcher als nächstes zur Planung verwendet werden soll. In der Liste befinden sich die Kandidaten, also die Gridjobs. Diese werden nach bestimmten Kriterien geordnet. Einer der besten k Kandidaten oder der besten α% Kandidaten dieser Liste wird zufällig für den nächsten Lösungsschritt gewählt. Ist die zufällige Lösung erstellt, wird sie mithilfe einer lokalen Suche optimiert. Eine Orientierung in Richtung Greedy, Zufall oder zwischen den beiden kann durch eine Anpassung von k bzw. α geschehen. Je größer k bzw. α, desto zufälliger wird die Lösung. GRASP-Ansätze zum Lösen des JSSP sind in Sheibani [22], Pitsoulis [23] und in Binato et al. [24] zu finden * Tabu-Suche (Tabu Search) Einordnung: Metaheuristik Ziel: Näherungslösung Die Tabu-Suche ist eine Methode zur heuristischen Optimierung und wird erstmals in Glover [25] und [26] vorgestellt. Zunächst wird eine (zufällige) Lösung erstellt. Danach wird ein Suchraum gültiger Lösungen schrittweise erkundet. Ein Schritt ist die Veränderung des Ergebnisses, wobei nicht festgelegt ist, in welcher Form diese Veränderung stattfinden muss. Anhand dieser Veränderungen werden neue Lösungen erschaffen, wovon ein Teil anhand von (nicht durch den Algorithmus festgelegten) Regeln als Tabu deklariert und in eine Tabu-Liste eingetragen wird. Die Tabu-Liste hat dabei normalerweise eine feste, begrenzte Länge. Die Elemente, die zuerst in die Tabu-Liste eingetragen werden, werden auch zuerst wieder herausgenommen, falls sie voll ist und ein neues Element eingetragen werden soll. Für den Fall, dass keine Verschlechterungen zugelassen werden, ist es wahrscheinlich, dass kein globales Optimum gefunden wird, sondern nur ein lokales. Allerdings ist auch beim Zulassen von Verschlechterungen der Erfolg von vielen Faktoren wie der Ergebnisdarstellung, der Definition eines Schrittes, der Tabu-Deklaration und der Länge der Tabu-Liste ab. In Pitsoulis [23] wird angegeben, dass die Tabu-Suche bei Tests mit dem PI-CPLP (Pure Integer Capacitated Plant Location Problem) schneller als GRASP arbeite und bessere 19

30 Ergebnisse als Simuliertes Abkühlen sowie GRASP brachte. Ein Algorithmus mit mehreren Optimierungszielen wird in Baykasoglu [27] beschrieben * Branch-and-Bound Einordnung: Meta-Heuristik Ziel: Finden von optimalen Lösungen in ganzzahligen Optimierungsproblemen Dieses Verfahren wird erstmals in Land [28] erwähnt. Mit Branch-and-Bound werden Algorithmen bezeichnet, welche systematisch alle Kandidatenlösungen absuchen. Dabei werden ausgehend von einer gültigen Ausgangslösung weitere gültige Lösungen (branch) generiert. Aus einem Branch werden weitere Branches erstellt, es gibt keine Rückwärtsschritte. Es werden nur solche Branches weiter verfolgt, die gewissen vordefinierten Schranken (bound) entsprechen. Diese müssen so gewählt sein, dass nicht versehentlich solche Branches eliminiert werden, welche zum Optimum führen würden. Dabei werden alle zulässigen Lösungen, welche beispielsweise durch eine andere Heuristik erstellt werden, als obere Schranken benutzt. Daraus werden dann die unteren Schranken, zum Beispiel mittels Relaxation, erstellt. Ist eine Lösung obere Schranke, so wird durch diese Lösung eine bestimmte Güte vorgelegt, welche garantiert besser ist, als andere Lösungen. Untere Schranken hingegen sagen aus, dass es keine schlechteren Lösungen geben kann. Es werden die unteren Schranken benutzt, um Branches zu eliminieren. Wenn eine untere Schranke bekannt ist, welche niedriger ist, als eine für einen Branch berechnete, so muss dieser Branch nicht weiter bearbeitet werden (Dakin [29]). Es gibt für das JSSP nach aktuellem Stand keine ausreichend guten (unteren) Schranken (Schuster [9]). Ein effizientes Bearbeiten großer Probleme mit Branch-and-Bound ist daher aus Sicht einiger Entwickler nicht möglich (Vaessens et al. [30] und Blazewicz et al. [31]) * Approximierende Algorithmen Einordnung: Algorithmus (allgemein) Ziel: Näherungslösung Die approximierenden Algorithmen sind im Allgemeinen solche, die irgendein Optimierungsproblem annähernd lösen. In Shmoys et al. [32] werden solche Algorithmen für das JSSP vorgestellt. Ein weiterer, darauf aufbauender, Algorithmus wird in Jansen et al. [33] vorgestellt. Diese versuchen jeweils, die Makespan zu optimieren. Approximationsalgorithmus ist nicht näher durch die Literatur spezifiziert und wird lediglich als ein allgemeiner Begriff verwendet. 20

31 3.3.9 * Lagrange-Relaxation mit neuronalen Netzen Einordnung: Mathematischer Optimierungsalgorithmus mit künstlicher Intelligenz Ziel: Näherungslösung Wie in Luh et al. [34] sehr detailliert und anhand eines Job-Shop-Beispiels beschrieben, soll dieser Ansatz mithilfe von KI (Künstliche Intelligenz) in neuronalen Netzen (Kriesel [35]) und mit der Lagrange-Relaxation JSSP lösen. Dafür bedarf es einer Funktion, welche das neuronale Netz darstellt, und einer Funktion, welche Lösungen bewertet. Das gesamte Problem wird in Teilprobleme zerlegt und jedes dieser Teilprobleme mit Lagrange schen Faktoren belegt. Jedes Teilproblem wird von einem Neuronalen Netz bearbeitet, welches die Lagrange schen Faktoren anpasst Simulierte Abkühlung (Simulated Annealing) Einordnung: Heuristik Ziel: Näherungslösung Eine allgemeine Beschreibung der Simulierten Abkühlung findet sich beispielsweise in Brucker [6]. Eine mögliche Implementierung für das JSSP wird in Yamada [36] erläutert; zwei weitere Heuristiken, die auf Simulierter Abkühlung beruhen, werden in Steinhöfel [37] beschrieben. Das Verfahren arbeitet wie folgt: Seien alle gültigen Lösungen für ein Problem in der Menge S, so arbeitet dieses Verfahren ausgehend von einer Lösung s S. Die Kosten der Lösung s werden mit der Kostenfunktion c(s) berechnet. Die Nachbarschaft von s, also die Lösungen, die aus s durch einen einzigen Schritt hervorgehen können, werden mit N(s) bezeichnet. Ein Schritt ist nicht genau definiert, beschreibt aber eine Veränderungen einer Lösung anhand von Regeln. Aus dieser Nachbarschaft wird bei der Simulierten Abkühlung eine Lösung s zufällig gewählt. Diese Lösung s wird immer als neue Lösung akzeptiert, falls sie besser als die bisherige ist, also c(s ) c(s). Außerdem wird s mit einer gewissen Wahrscheinlichkeit als neue Lösung akzeptiert, falls c(s ) > c(s). Diese Wahrscheinlichkeit nimmt pro Schritt ab (Abkühlung), so dass die Wahrscheinlichkeit mit der Dauer des Verfahrens gegen 0 geht. Das bedeutet, dass ein lokales Minimum anfangs leicht überwunden werden kann, aber dass es später schwieriger wird. Die Probleme sind bei diesem Verfahren vor allem, dass die Lösungen um ein Minimum oszillieren und somit viel Rechenzeit verschwendet wird, wenn eine bestimmte Anzahl von Iterationen oder eine bestimmte Laufzeit als Abbruchkriterium gewählt wird. Abhilfe kann gegebenenfalls durch eine Tabu-Liste geschaffen werden, die allerdings sehr lang werden kann. Das Problem bei der Simulierten Abkühlung ist, dass eine geeignete Verteilung der Abkühlung für verschiedene Arten von Problemen gefunden werden muss, damit dieses Verfahren gut arbeiten kann. 21

32 Schwellenakzeptanz (Threshold Accepting) Einordnung: Heuristik Ziel: Annäherung von Optimierungsproblemen Threshold Accepting ist eine Art der Simulierten Abkühlung (Aarts [38]). Der Unterschied liegt hierbei im Akzeptanzkriterium. Bei der Schwellenakzeptanz wird eine Lösung s als neue Lösung akzeptiert, wenn die Differenz zwischen c(s ) c(s) kleiner als ein positiver Schwellenwert t ist. Dieser Schwellenwert wird nach und nach verringert. Die Probleme und Möglichkeiten zur Abhilfe sind die gleichen, wie bei Simulierter Abkühlung. 3.4 Vergleich der Algorithmen Der Vergleich der verschiedenen Verfahren v i aus der Menge aller hier vorgestellten Verfahren V erfolgt auf Basis gewichteter Kriterien k j aus K und Abdeckung dieser Kriterien durch das Verfahren. Für die Erfüllung eines Kriteriums k j werden Bewertungspunkte von 1-10 vergeben. Diese Punkte wurden folgendermaßen aufgeteilt: Kriterien, die als leicht erfüllbar eingeschätzt wurden, bekamen nur wenige Bewertungspunkte zugeteilt, ebenso wie solche, die meist als Standard gegeben sind. Unbedingt für das Problem zu erfüllende Kriterien, die schwer erfüllbar sind, bekamen hingegen mehr Bewertungspunkte zugeteilt. Die Abdeckung a ij eines Kriteriums k j durch das Verfahren v i wird mittels einer fünfstufigen Skala eingeordnet: Erfüllt ein Verfahren das Kriterium komplett, so werden die Bewertungspunkte mit einer Erfüllungsquote von 100% der Bewertungspunkte in das Endergebnis aufgenommen, erfüllt es die Anforderung nicht, so werden 0% in das Endergebnis aufgenommen. Häufig kam bei der Recherche jedoch vor, dass eine Beschreibung in der Literatur nicht aussagekräftig genug war. Dort wurden Vermutungen angestellt. Die Vermutungen besitzen alle ähnliche Aussagekraft hinsichtlich der Bewertung und können von verschiedener Qualität sein: unwahrscheinlich (40% der Bewertungspunkte), keine Aussage möglich (50% der Bewertungspunkte) und wahrscheinlich (60% der Bewertungspunkte) sind die möglichen Werte. Die voraussichtliche Güte eines Verfahrens v i berechnet sich also aus der Summe aller mit der Abdeckung a ij gewichteten n Kriterien k j : n f v i = a ij k j j =1 (1) 22

33 Die verschiedenen Kriterien und ihre Werte sind in Tabelle 5 beschrieben. Tabelle 5: Kriterien zum Vergleichen von Verfahren Kriterium Wert Beschreibung Nichtpräventives Scheduling 1 Operationen und Jobs können nicht unterbrochen werden Statisches Scheduling 1 Vor der Planung stehen alle Daten für die Planung bereit und ändern sich während der Planung nicht Gerichtete azyklische Graphen maschinenabhängige Joblaufzeiten Verursachung von Kosten durch Maschinen Verfügbarkeitszeiten von Maschinen Berücksichtigung mehrerer Optimierungsfaktoren 3 Der Ablauf der Jobs lässt sich durch einen gerichteten azyklischen Graphen (DAG) darstellen. (Das ist ein Graph, bei dem Kanten durch Pfeile dargestellt sind, welche von einem zu einem anderen Knoten zeigen. Außerdem gibt es keine Zyklen in diesem Graph.) 5 Maschinen besitzen verschiedene Geschwindigkeiten, sodass die Ausführungszeit mit der Geschwindigkeit der Maschine gewichtet werden muss, um die wirkliche Ausführungszeit des Jobs zu berechnen 5 Maschinen müssen für ihre Benutzung bezahlt werden 8 Maschinen sind nicht zu jeder Zeit verfügbar, sondern besitzen Zeitfenster 8 Der zu erstellende Schedule muss hinsichtlich verschiedener, vom Benutzer einstellbarer Optimierungsfaktoren optimal sein (Pareto-optimal) 5 Verschiedene Jobs und Operationen besitzen verschiedene Laufzeiten Jobs/Operationen mit unterschiedlicher Laufzeit Parallele Operationen 8 Verschiedene Operationen eines Jobs können parallel/gleichzeitig ablaufen Jobs, welche mehrmals auf die selbe Maschine zugreifen Jobs mit Anforderungen an Maschinen Operationen mit mehreren direkten Vorgängern Operationen mit mehreren direkten Nachfolgern Kommunikationszeiten zwischen Operationen 3 Verschiedene Operationen eines Jobs können auf der selben Maschine bearbeitet werden, so dass es weniger Maschinen geben kann, als die maximale Anzahl an Operationen jedes Jobs 9 Anforderungen gelten nicht für eine bestimmte Maschine, sondern für eine Gruppe von Maschinen 9 Bevor eine Operation ausgeführt werden kann, müssen alle direkten Vorgänger fertig bearbeitet worden sein 7 nachdem eine Operation ausgeführt wurde, werden alle direkt nachfolgenden Operationen zur Bearbeitung freigegeben 5 Zeit, die benötigt wird, um nach einer Operation frühestens die nächstfolgende Operation starten zu können 23

34 Weiterhin gibt es noch folgende Bewertungskriterien, welche durch Implementierung und Benchmarks getestet werden müssen, und nicht vorher abgeprüft werden können: Geschwindigkeit und Güte der Ergebnisse: Wie schnell findet der Algorithmus eine sehr gute Lösung? Sind die Ergebnisse im Allgemeinen gut? Dieser Punkt wird gemeinsam betrachtet, da ein gutes Ergebnis, welches sehr lange braucht, um gefunden zu werden, ebenso unnütz ist, wie ein sehr schlechtes Ergebnis, welches nur sehr wenig Zeit benötigt. Zuverlässigkeit: Hier kommt vor allem die Frage auf, ob der Algorithmus bei jeder Konstellation von Maschinen, Jobs und Operationen eine gute Lösung findet. Möglicherweise gibt es Ausnahmen, bei denen der Algorithmus schlecht arbeitet. Möglichkeit der Integration in GORBA: Da ohne eine Integration in GORBA die Algorithmen nicht in ihrer späteren Umgebung getestet werden können, ist es wichtig, dass sie überhaupt integriert werden können. Dabei sollte der Aufwand den Nutzen möglichst nicht übersteigen. Die Frage muss also lauten: Alles ist möglich Aber mit wie viel Aufwand ist die Implementierung verbunden? Dies kann bei der Planung der Implementierung, sowie durch Betrachtungen in der Literatur kenntlich werden. Einige Verfahren sind von Natur aus komplexer als andere. Einfache Heuristiken sind sicherlich einfacher integrierbar, als komplette Systeme zur Findung eines Optimums, versprechen aber vielleicht nicht den Erfolg eines umfassenderen Verfahrens. Letztere verwenden häufig mehrere einfachere Verfahren zum Lösen von Teilproblemen. Nutzen für GORBA und als Startpopulation für GLEAM: Die wichtigste Frage ist, ob die Verwendung einer der Verfahren eine signifikante Verbesserung für eines der Einsatzgebiete (konventionelle Planung, Startpopulation für GLEAM) mit sich bringt. Der Nutzen kann sehr schwer abgeschätzt werden. Selbst bei einem Verfahren wie dem GTA wurden keine Verbesserungen erreicht. Allerdings gibt es, wie sich bei der bisherigen Recherche herausstellte, viele Alternativen, die zum Teil sogar größeres Potenzial besitzen, als der GTA. 24

35 Wert Appr. Algorithmus 1 Appr. Algorithmus 2 Branch&Bound Decomp. Approach GRASP GTA Lagr.Rel&neur. Netze List Scheduling Shifting Bottleneck Simulated Annealing Tabu Search Threshold Accepting Tabelle 6: Gegenüberstellung und Bewertung der Verfahren Nichtpräventives Scheduling 1 Statisches Scheduling 1 Gerichtete azyklische Graphen 3 Maschinen können Laufzeit von Jobs beeinflussen 5 Maschinen verursachen Kosten 5 Maschinen haben Verfügbarkeitszeiten 8 Berücksichtigung mehrerer Optimierungsfaktoren 8 Jobs/Operationen mit unterschiedlicher Laufzeit 5 Parallele Operationen 8 Jobs, welche mehrmals auf die selbe Maschine zugreifen 3 Jobs mit Anforderungen an Maschinen 9 Operationen mit mehreren direkten Vorgängern 9 Operationen mit mehreren direkten Nachfolgern 7 Kommunikationszeiten zwischen Operationen 5 Punktzahl Ranking Legende: = Bedingung erfüllt (100%) = Bedingung wahrscheinlich erfüllt (60%) = keine Aussage möglich (50%) = Bedingung wahrscheinlich nicht erfüllt (40%) = Bedingung nicht erfüllt (0%) 3.5 Auswahl Das Ergebnis der Bewertung zeigt Tabelle 6. Nach dem Bewertungsschema erreichte die Tabu-Suche den besten Wert. Danach folgen Lagrange-Relaxation, Shifting Bottleneck, GRASP und List Scheduling. Da auch die Anpassbarkeit an GORBA, was die Implementierung sowie die Kombination mit GLEAM beinhaltet, wichtig ist, wurden Shifting Bottleneck, List Scheduling, GRASP und Tabu-Suche für die weitere 25

36 Bearbeitung ausgewählt. Auch die Lagrange-Relaxation in Verbindung mit neuronalen Netzen erreicht eine sehr hohe Gesamtpunktzahl. Dieses Verfahren wird allerdings als sehr komplex und als nicht für eine gemeinsame Verwendung mit GLEAM passend eingeschätzt (als selbständiges Verfahren sind dieses und andere Verfahren trotzdem sehr interessant). Aus diesem Grund erfolgt in dieser Arbeit keine Umsetzung. Insgesamt kann die Tabelle nur ungefähre Werte liefern, da in der Literatur für die bestimmten Fragestellungen und Anforderungen meist keine eindeutige Antwort gegeben ist. So ist es möglich, dass Verfahren in dieser Arbeit nicht weiter betrachtet werden, die bei einer Implementierung gute Ergebnisse liefern würden. Die gewählten Verfahren besitzen jedoch nach aktuellen Einschätzungen die besten Erfolgschancen. Meist kann ein Verfahren in Verbindung mit anderen verwendet werden. In dieser Hinsicht gibt es keine Einschränkungen für die Implementierung. 26

37 Kapitel 4 Implementierung Dieses Kapitel beschäftigt sich mit der Implementierung der Verfahren sowie deren Einbettung in GORBA. 4.1 Entwicklungsumgebung Entwickelt wird in der Eclipse Platform für die Java-Entwicklung auf Suse Linux 11. Gearbeitet wird in einem eigens für diese Arbeit erstellten Zweig im GORBA- Repositorium mittels Subversion (SVN) Client. Java wird in der Version verwendet. Die Quelldateien können somit auf einfache Art und Weise verwaltet werden, ohne dass andere Arbeiten an GORBA dadurch gestört werden. Alle GORBA-Entwickler haben auf das Repositorium Zugriff und können stets den aktuellen Stand der Bearbeitung verfolgen Programmiersprache Die Programmiersprache ist bei der Implementierung vorgegeben. Dabei ist es wichtig, für welches Einsatzgebiet programmiert werden soll. Eine Integration von Heuristiken muss in Java erfolgen, da diese direkt in GORBA integriert werden sollen und GORBA selbst auch in Java geschrieben ist. Wird allerdings eine Verwendung in Verbindung mit GLEAM angestrebt, so ist C/C++ als Programmiersprache zu wählen, da der Evolutionäre Algorithmus in diesen Sprachen entwickelt wurde. Dies ist in dieser Arbeit jedoch nicht gegeben Integration in GORBA Sämtliche Algorithmen sind zunächst direkt in GORBA integriert. Dafür wurde der Paketstruktur (package structure) von GORBA ein weiteres Paket hinzugefügt. Diese Paketstruktur entspricht im Verzeichnisbaum einer Ordnerstruktur. Das neue Paket heißt optimization. Dort befinden sich die neu erstellten Klassen für die neuen Heuristiken. Einige dieser Klassen sind sogenannte Wrapper-Klassen. Diese kapseln von GORBA erzeugte Objekte und verwenden sie weiter. Die Originale der Objekte werden dabei nicht verändert, sondern nur ausgelesen und wenn notwendig durch eigene Klassen um Attribute erweitert. Um eine möglichst hohe Modulisierung der neu erstellten Heuristiken zu ermöglichen, wird darauf geachtet, die Abhängigkeiten auf Seiten von GORBA zu den neuen Klassen gering zu halten. Einige Abhängigkeiten sind ohne ein automatisches System, welches beispielsweise über externe Metadaten die aktuell verwendbaren Klassen einlesen könnte, nicht vermeidbar, denn in GORBA sollen die neuen Heuristiken natürlich auch aufrufbar sein. Jeder der Algorithmen besitzt eine Methode, die den jeweils erstellten Schedule in einen von GORBA verwertbaren Schedule umwandelt. Diese Methoden werden jeweils automatisch von den Algorithmen selber nach Erstellung des Schedules aufgerufen. Der Schedule wird dann der ApplicationJobList von GORBA hinzugefügt, um eine Bewertung und 27

38 Weitergabe an GLEAM zu ermöglichen. Genauere Erläuterungen zum Code gibt es in Abschnitt Code-Konventionen Um die Lesbarkeit und das leichtere Verständnis des Codes zu fördern, werden folgende Konventionen bei der Programmierung beachtet: Bezeichner Alle Bezeichner erhalten möglichst sprechende Namen, aus denen deren Funktion oder Bedeutung ablesbar ist. Diese Namen werden in lowercamelcase geschrieben. Das bedeutet, dass das erste Wort klein und alle darauffolgenden Wörter mit Großbuchstaben beginnen. Zusätzlich zum eigentlichen Namen bekommen bestimmte Bezeichner noch Präfixe zugewiesen. Präfixe Die Präfixe dienen zur Erkennung des Datentyps von Variablen. Die folgenden Tabellen zeigen die vorgegebenen Präfixe für einfache Datentypen (Tabelle 7), Instanzen von Klassen (Tabelle 8) und von Methoden (Tabelle 9). Arrays werden zusätzlich zum Präfix mit dem Infix Arr gekennzeichnet (z.b. intarrbeispiel). Zusätzlich dazu erhalten Klassenattribute noch das Präfix m_, um auszudrücken, dass die Variable Attribut einer Klasse ist (z.b. m_intgroesse). Tabelle 7: Präfixe für Variablen einfachen Datentyps Typ short int long float double char boolean byte Präfix short int long flt dbl chr bool byte Tabelle 8: Präfixe für Instanzen von Klassen Klasse Short Integer Long Float Double Präfix cshort cint clong cflt cdbl 28

39 Char Boolean Byte String Vector, ArrayList, LinkedHashMap cchr cbool cbyte str vec Tabelle 9: Präfixe für Methoden Aufgabe Rückgabe einer Klassenvariable Rückgabe eines Boolean Setzen einer Klassenvariable Hinzufügen eines Elements zu einem Container Entfernen eines Elementes von einem Container Prüfen auf Zugehörigkeit eines Elements zu einem Container Präfix get is set add remove contains Aufruf von Variablen und Funktionen Innerhalb von Klassen werden Klassenvariablen und Methoden immer mit this.<name> aufgerufen. Statische Variablen werden mit <Klassenname>.<name> aufgerufen. Konstanten werden mit final deklariert und komplett groß geschrieben. Einzelne Wörter werden hier mit Unterstrich getrennt. Klassenvariablen sind immer als private oder, wenn durch Vererbung benötigt, als protected deklariert und werden außerhalb der Klasse per get- und set-methoden aufgerufen, bzw. verändert. Kommentare Für jede Klasse und jede Methode gibt es einen Kommentar im Javadoc-Stil, welcher die Funktion der Klasse oder Methode beschreibt. Parameter, Rückgabewerte und mögliche Ausnahmen (Exceptions) müssen genannt und möglichst erklärt werden. 4.2 Klassenübersicht In diesem Abschnitt werden die neu angelegten Klassen aufgelistet und ihre Funktionen beschrieben. Zusätzlich werden die bereits in GORBA verwendeten Klassen, welche verändert wurden, aufgeführt und die Änderungen erläutert. Außerdem wird erläutert, wie die Algorithmen implementiert wurden. Für die Arbeit wurden dem GORBA-Code neun Packages hinzugefügt. Diese fassen jeweils zusammenhängende Klassen zusammen. Im Folgenden werden zunächst die Packages genannt. In den 29

40 Tabellen werden die Klassen für das jeweilige Package, ohne nochmaliges Nennen des Packages aufgezeigt (mit Ausnahme der bereits vorhandenen Klassen). Trotzdem befinden sich die Klassen natürlich in dem Package Änderungen an vorhandenen Klassen Hier werden die Änderungen zusammengefasst, welche an bereits vorhandenen GORBA-Klassen durchgeführt wurden. Tabelle 10: Vorhandene Klassen, welche abgeändert wurden Klassenname gorba.init.initgorba gorba.init.gorbasettings gorba.gui.dialog_option gorba.applicationjob.app licationjoblist Kurzbeschreibung Klasse zum Verwalten von Systemparametern von GORBA Klasse zum Verwalten von Betriebsparametern von GORBA Dialogfenster zum Ändern von Parametern und Optionen in GORBA Liste zum Verwalten von mehreren Objekten der Klasse ApplicationJob Um eine Integration zu ermöglichen, werden in GORBA zunächst die Klassen InitGorba und GorbaSettings angepasst. In GorbaSettings werden Schlüssel- Wert-Paare hinterlegt, die später von weiteren Klassen GORBAs verwendet werden können. Diese und weitere Schlüssel-Wert-Paare dienen generell zur Verwaltung von Anwendereinstellungen in GORBA. Verwendet werden die neuen Paare in den Klassen Dialog_Option sowie ApplicationJobList, weshalb auch diese angepasst werden. Durch die Erweiterung von Dialog_Option ist es möglich, die neuen Algorithmen im Optionsfenster von GORBA zur Bearbeitung zu selektieren (siehe Abbildung 4). ApplicationJobList wird dahingehend erweitert, dass die Optionen abgefragt werden und entsprechend ihrer Werte die zugehörigen Algorithmen aufgerufen werden. 30

41 Abbildung 4: GORBAs Optionsdialog gorba.optimization Dies ist das Haupt-Package. Es enthält allgemeine Klassen, die von mehreren entwickelten Algorithmen verwendet werden. Tabelle 11: Klassen im Package gorba.optimization Klassenname OptGraph OptGraphArc OptGraphDisjunctiveArc OptGraphNode OptGraphPath OptGridjob OptResource OptStep OptTimeLine OptTimeSlot Kurzbeschreibung Graph, welcher zur möglichen Nachoptimierung bei GRASP und Shifting Bottleneck verwendet wird. Eine Kante im Graph. Eine disjunktive Kante im Graph. Ein Knoten im Graph (kapselt einen Gridjob). Ein Pfad im Graph. Wrapper für ein Objekt der Klasse Gridjob. Wrapper für ein Objekt der Klasse Resource. Schritt zum Verändern eines Regelsatzes (für GRASP und Tabu-Suche). Zeitlinie für eine Ressource zur Darstellung der verfügbaren Zeiten. Ein Zeitschlitz, welcher einen verfügbaren Zeitraum einer Ressource darstellt. Um eine Grundlage zu haben, die von allen zu implementierenden Algorithmen verwendet werden kann, wurden zwei Wrapper-Klassen (von Englisch: to wrap = einpacken/umhüllen) erstellt. Dies sind im Einzelnen OptGridjob und OptResource. OptGridjob wrappt einen Gridjob aus GORBA und OptResource eine Resource. Weiterhin wurden zwei Klassen erstellt, welche zwei vorhandenen Klassen in GORBA ähnlich sind. Dabei handelt es sich um OptTimeSlot 31

42 und OptTimeLine. OptTimeSlot (ähnelt TimeSlot) und OptTimeLine (ähnelt TimeSlotList) dienen zur Zuordnung von freien Zeitschlitzen auf Ressourcen (OptResource besitzt außer der gewrappten Resource nur eine OptTimeLine). Ein Zeitschlitz wird dabei als OptTimeSlot dargestellt, eine gesamte Zeitlinie als OptTimeLine. Auch die Gridjobs verwenden Zeitschlitze, allerdings um anzuzeigen, wann sie ablaufen. Ein Zeitschlitz ist nicht direkt an eine Ressource gebunden, sondern kann gesondert existieren. Ein OptGridjob besitzt außer einem gewrappten Gridjob-Objekt einige weitere Attribute. Es werden der zugehörige ApplicationJob, die direkten Vorgänger, die direkten Nachfolger sowie die benutzbaren Ressourcen gespeichert. Desweiteren wird im Konstruktor des Gridjobs sein Fälligkeitsdatum (DueDate) berechnet und gespeichert. Der Gridjob besitzt auch eine Referenz auf eine Ressource und einen Zeitschlitz, welche bei der Verplanung des Gridjobs durch einen Algorithmus entsprechend aktualisiert werden. Zusätzlich zu Get- und Set-Methoden enthält OptGridjob noch eine Methode zum Umwandeln in einen für GORBA verwertbaren GorbaScheduleJob. Zu diesem Zweck gibt es noch ein Attribut, welches angibt, ob der Gridjob bereits transformiert ist. In allen vier implementierten Algorithmen werden OptGridjob und OptResource, bzw. davon abgeleiteten Klassen, verwendet. Für GRASP und Shifting Bottleneck gibt es noch die Anforderung, eine Nachoptimierung durchzuführen. In Binato et al. [24] wird dafür eine Nachoptimierung anhand eines disjunktiven Graphen durchgeführt. Dies ist ein Graph, welcher gerichtete und ungerichtete, sogenannte disjunktive Kanten besitzt. Aus diesem Grund wurde ein solcher Graph mit OptGraph implementiert. Ein Knoten in dem Graph wird mit OptGraphNode, welches einen Gridjob kapselt, dargestellt. Für jeden Knoten werden eingehende und ausgehende Kanten, sowie der Gridjob gespeichert. OptGraphArc entspricht einer Kante in dem Graph. Es werden pro Kante zwei Knoten gespeichert, ein Start- und ein Zielknoten. OptGraphDisjunctiveArc erweitert OptGraphArc und entspricht einer disjunktiven Kante. Hier werden beide Knoten gleichwertig behandelt, da es keine Richtung bei der disjunktiven Kante gibt. Weiterhin gibt es noch OptGraphPath, welches einen Pfad im Graph darstellt. Die Klasse besitzt eine Methode zur Berechnung der aktuellen Länge des Pfades. Dies wird anhand der Länge der enthaltenen Knoten berechnet. Die wichtigsten Methoden vom Graph selber sind die die Erstellung des längsten Pfades zu einem bestimmten Knoten, die Erstellung des kritischen Pfades und das Austauschen zweier Knoten: 32

43 Ablauf der Optimierung mit dem disjunktiven Graph: Das Modell des disjunktiven Graphen wird in Roy [39] erstmalig vorgestellt. Dafür sei ein Graph G = (V, A, E) gegeben, der durch Knoten V (=Gridjobs), Pfeile A (=Vorgängerund Nachfolgerbedingungen) und disjunktive Pfeile E (=Verbindungen zwischen Gridjobs, die auf der gleichen Ressource ausgeführt werden) definiert ist. Die disjunktiven Pfeile sind zunächst nicht gerichtet, bekommen aber durch eine Lösung eine Richtung zugewiesen. Die Richtung sagt aus, in welcher Reihenfolge die Operationen auf einer Ressource ausgeführt werden. Da alle Gridjobs, welche auf der gleichen Ressource ausgeführt werden, durch disjunktive Pfeile verbunden sind, muss die Lösung alle disjunktiven Pfeile so umgewandelt haben, dass diese nun gerichtet sind. Davon ausgenommen ist jeweils ein disjunktiver Pfeil pro Maschine, wenn eine Ressource drei oder mehr Applicationjobs zu bearbeiten hat. Wäre diese Ausnahme nicht gegeben, gäbe es einen Zyklus. In diesem Graph wird ein kritischer Pfad bezüglich der Dauer der einzelnen Gridjobs berechnet. Im kritischen Pfad werden danach Gridjobs ausgetauscht, die auf den gleichen Ressourcen ausgeführt werden, wenn dies die Vorgänger- und Nachfolgebeziehungen nicht verletzt. Nach dem Austauschen wird wieder der kritische Pfad berechnet. Ist er kürzer geworden, so wird die Änderung übernommen und mit der Änderung erneut die Güte des Schedules berechnet, ansonsten wird die Änderung rückgängig gemacht. Gibt es bei einem Durchlaufen des kritischen Pfades keine Änderungen mehr, so ist ein lokales Optimum erreicht gorba.optimization.exceptions Dieses Package beinhaltet die Exceptions, welche für die Behandlung von Ausnahmefällen benötigt werden. Jeder Algorithmus kann diese Exceptions verwenden. Tabelle 12: Klassen im Package gorba.optimization.exceptions Klassenname NoResForJobException NotImplementedException Kurzbeschreibung Exception, die geworfen werden kann, wenn für einen Job keine Ressource gefunden wurde. Exception, die geworfen wird, wenn eine Funktion oder Klasse noch nicht oder noch nicht fertig implementiert wurde. 33

44 4.2.4 gorba.optimization.rulesgj Dieses Package beinhaltet Regeln zum Finden eines am besten geeigneten Gridjobs. Tabelle 13: Klassen im Package gorba.optimization.rulesgj Klassenname GJRule GJRuleAJFewestTimeLeft GJRuleEarliestStartFirst GJRuleEDD GJRuleLongestJobFirst GJRuleMostSuccFirst GJRuleShortestJobFirst Kurzbeschreibung Repräsentiert eine Prioritätsregel für Gridjobs. Prioritätsregel Am wenigsten Bearbeitungszeit im ApplicationJob übrig Prioritätsregel Gridjob mit frühester Startmöglichkeit Prioritätsregel Gridjob mit frühester Fälligkeitszeit Prioritätsregel Längster Gridjob Prioritätsregel Gridjob mit den meisten Nachfolgern Prioritätsregel Kürzester Gridjob Für die Gridjob-Wahl gibt es eine abstrakte Klasse (GJRule), welche als Oberklasse für alle anderen Regeln implementiert wurde. Auch diese gibt eine Methode vor, welche von allen Unterklassen implementiert werden muss. Diese Methode erwartet als Parameter ein Array von Gridjobs und einen Wert α, welcher aber null sein darf. Eine Regel wählt einen Gridjob aus dem übergebenen Array aus und gibt diesen zurück. Ist kein α angegeben, so ist die Auswahl deterministisch, ansonsten werden die besten α Prozent der Gridjobs in ein neues Array gelesen und daraus ein zufälliges Element zurück gegeben. Die Variante mit α wird von GRASP und Tabu-Suche verwendet. Bei den folgenden Beschreibungen wird die α-variante nicht nochmals beschrieben, da sie für jede Regel auf gleiche Weise angewendet wird. Folgende Regeln wurden implementiert: ApplicationJobFewestTimeLeft Dargestellt durch die Klasse: GJRuleAJFewestTimeLeft Jeder Gridjob J i besitzt einen frühestmöglichen Startzeitpunkt J i start, welcher abhängig von seinen Vorgängern, bzw. bei Gridjobs ohne Vorgänger abhängig vom frühestmöglichen Startzeitpunkt des Applicationjob ist. Der Applicationjob besitzt eine maximale Fertigstellungszeit, welche vom Benutzer bei seiner Erstellung angegeben wird. Diese sollte bei der Generierung eines Schedules möglichst nicht überschritten werden. Diese Fertigstellungszeit sei J i. Die Regel wählt nun den Gridjob aus, app _end für den J i app _end J i minimal ist. Durch die Einführung dieser Regel in GRASP und start Tabu-Suche wurden die Ergebnisse nach GLEAM-Bewertung deutlich verbessert, da Zeitüberschreitungen stark reduziert werden konnten. 34

45 EarliestStartFirst Dargestellt durch die Klasse: GJEarliestStartFirst Diese Regel wählt den Gridjob aus, welcher theoretisch die frühestmögliche Startzeit besitzt. Diese wird von seinen Vorgängern, bzw. falls keine Vorgänger existieren vom Applicationjob bestimmt. EarliestDueDate Dargestellt durch die Klasse: GJRuleEDD Durch diese Regel wird der Gridjob mit dem frühesten Fälligkeitszeitpunkt gewählt. Der Fälligkeitszeitpunkt wird bei Initialisierung eines OptGridJob berechnet. LongestJobFirst Dargestellt durch die Klasse: GJLongestJobFirst Diese Regel wählt aus einer Liste von Gridjobs den längsten Gridjob aus. Dafür wird die voraussichtliche Länge auf einer Standard-CPU verwendet. MostSuccessorsFirst Dargestellt durch die Klasse: GJRuleMostSuccFirst Diese Regel wählt von allen Gridjobs in der übergebenen Liste den Gridjob aus, welcher die meisten Nachfolge-Gridjobs hat. ShortestJobFirst Dargestellt durch die Klasse: GJRuleShortestJobFirst Bei dieser Regel wird der kürzeste Gridjob ausgewählt. Die Länge wird anhand Berechnungen auf einer Standard-CPU erfasst. Diese ist in allen Gridjobs gespeichert und bezeichnet eine voraussichtliche Dauer. 35

46 4.2.5 gorba.optimization.rulesres: Dieses Package beinhaltet Regeln zum Finden einer am besten geeigneten Ressource. Tabelle 14: Klassen im Package gorba.optimization.rulesres Klassenname ResRule ResRuleCheapest ResRuleEarliestCheapest ResRuleEarliestEnd ResRuleEarliestOrCheapest ResRuleEarliestStart ResRuleFastest ResRuleMostTimeLeft Kurzbeschreibung Repräsentiert eine Prioritätsregel für Ressourcen. Prioritätsregel Billigste Ressource Prioritätsregel Billigste Ressource unter den Ressourcen, die ein frühestmögliches Bearbeitungsende ermöglichen Prioritätsregel Ressource, die ein frühestmögliches Bearbeitungsende ermöglicht Prioritätsregel Billigste aus den frühestmöglichen Ressourcen oder frühestmögliche aus den billigsten Ressourcen Prioritätsregel Ressource, die einen frühestmöglichen Bearbeitungsbeginn ermöglicht Prioritätsregel Schnellste Ressource Prioritätsregel Ressource mit der meisten verfügbaren freien Bearbeitungszeit Für die Ressourcenwahl wurde eine Oberklasse ResRule als abstrakte Klasse erstellt. Diese Klasse gibt eine Methode vor, die anhand eines Gridjobs eine Ressource wählt, auf welcher der Gridjob verplant werden soll. Da die verwendbaren Ressourcen bereits dem Gridjob bekannt sind, müssen diese nicht der Funktion übergeben werden. Alle Unterklassen von ResRule lesen in der oben genannten Methode die benutzbaren Ressourcen aus dem übergebenen Gridjob und untersuchen entsprechend der Regel, wann der Gridjob auf dieser Ressource ausgeführt werden kann, bzw. welche Ressource entsprechend der Regel die bestgeeignetste ist. Alle neu implementierten Algorithmen verwenden diese Regeln zur Auswahl von passenden Ressourcen. Es gibt hier folgende Regeln: Cheapest Dargestellt durch die Klasse: ResRuleCheapest Anmerkung: Diese Regel wird aktuell nur in Verbindung mit anderen Regeln eingesetzt. Diese Regel sucht aus einer Liste von Ressourcen billigste aus. Die Kosten einer Ressource können zu verschiedenen Zeiträumen variabel sein, so dass zunächst für jede zu untersuchende Ressource der früheste Startzeitpunkt und die Dauer des aktuellen Gridjobs berechnet werden muss. Aus diesen Werten können die Kosten für 36

47 die Ressource berechnet werden. Von allen Ressourcen, die für einen Gridjob zur Auswahl stehen, wird so die billigste ausgewählt. Bei mehreren gleichbilligen Ressourcen wird die erste Ressource der Liste gewählt. EarliestCheapest Dargestellt durch die Klasse: ResRuleEarliestCheapest Diese Regel findet unter einer Liste von Ressourcen die Ressource, auf der der aktuelle Gridjob am frühesten beendet werden kann. Gibt es mehrere Ressourcen, auf welchen der Gridjob gleichermaßen schnell beendet werden kann, so wird aus diesen Ressourcen die billigste (siehe Regel Cheapest) ausgewählt. EarliestEnd Dargestellt durch die Klasse: ResRuleEarliestEnd Diese Regel wählt aus einer Liste von Ressourcen die Ressource aus, auf welcher der aktuelle Gridjob als erstes beendet werden kann. Gibt es bei mehreren Ressourcen Gleichstand, so wird die erste passende Ressource gewählt. EarliestOrCheapest Dargestellt durch die Klasse: ResRuleEarliestOrCheapest Bei dieser Regel gibt es zwei mögliche Szenarien, die eintreten können. Dafür wird zunächst die CostWeight, also die vom Benutzer für einen Applicationjob angegebene Gewichtung zwischen Kosten und Geschwindigkeit, aus dem zum aktuellen Gridjob gehörenden Applicationjob ausgelesen. Ist dieser Wert größer oder gleich 0.5, so werden zuerst die billigsten Ressourcen gesucht (siehe Regel Cheapest) und aus dem Resultat die Ressource gewählt, auf welcher der Gridjob am frühesten beendet werden kann. Ist der Wert allerdings kleiner als 0.5, so wird zuerst nach den Ressourcen gesucht, auf denen der Gridjob als erstes beendet werden kann. Aus diesen wird dann die billigste gewählt. EarliestStart Dargestellt durch die Klasse: ResRuleEarliestStart Diese Regel sucht die Ressource, auf der der aktuelle Gridjob am frühesten gestartet werden kann. Gibt es mehrere Ressourcen, auf die das zutrifft, so wird die erste passende ausgewählt. 37

48 Fastest Dargestellt durch die Klasse: ResRuleFastest Durch diese Regel wird die Ressource aus der Liste der benutzbaren Ressourcen eines Gridjobs gewählt, welche den Gridjob am schnellsten bearbeiten kann. Gibt es mehrere Ressourcen mit dem gleichen maximalen Wert, so wird die erstmögliche dieser Ressource verwendet. MostTimeLeft Dargestellt durch die Klasse: ResRuleMostTimeLeft Diese Regel wählt aus einer Liste von Ressourcen eines Gridjobs die Ressource aus, auf der die noch verfügbare Gesamtzeit am höchsten ist. Dies führt dazu, dass Ressourcen mit einer kleinen Verfügbarkeitszeit fast nie verwendet werden. Die verfügbare Gesamtzeit berechnet sich aus der Summe der freien ZE (Zeiteinheiten) einer Ressource über ein bestimmtes Intervall. Dieses Intervall ist aber für alle Ressourcen gleich, so dass es zu den eben beschriebenen Problemen kommt. Dies kann an Abbildung 5 nachvollzogen werden. In dem Beispiel wurde die maximale Gesamtlänge des Schedules mit 17 ZE berechnet. Bei Res1 sind in diesen 17 ZE nur 5 ZE verfügbar, für Res2 6ZE und für Res3 13ZE. In der Praxis werden die Gridjobs aber schon im vorderen Teil eingeplant, so dass die maximale Anzahl an ZE nie erreicht wird. Das bedeutet in diesem Fall, Res2 erst dann gewählt werden kann, wenn mindestens 7 ZE von Res3 belegt sind. Res1 kann sogar erst bei 8 belegten ZE auf Res3 und 1 belegten ZE auf Res2 gewählt werden. Abhilfe könnte eine Variierung der Intervalllänge jeder Ressource schaffen. Dabei müsste die Länge anhand der freien Zeitschlitze berechnet werden, die auf einer Ressource bei Initialisierung des jeweiligen Algorithmus zur Verfügung stehen. Abbildung 5: Zeiteinheiten von Ressourcen 38

49 4.2.6 gorba.optimization.listscheduling In diesem Package befinden sich die Klassen für List Scheduling. Sie werden nur vom List Scheduling Algorithmus verwendet. Tabelle 15: Klassen im Package gorba.optimization.listscheduling Klassenname LSMain LSPath Kurzbeschreibung Hauptklasse für List Scheduling. Repräsentiert einen Pfad von Gridjobs, welcher benutzt wird, um die Liste für List Scheduling zu erstellen. Diese Heuristik geht (nach der Initialisierung) in grob zwei Schritten vor. Im ersten Schritt wird eine Liste von Jobs erzeugt, im zweiten Schritt wird diese abgearbeitet, indem sie auf Ressourcen verteilt werden. Die Reihenfolge der Planung ist durch die Liste vorgegeben. Skizze des Verfahrens: 1. Initialisierung der für die Heuristik erforderlichen Daten 2. Erstellen einer Liste von Jobs für das Scheduling 3. Einplanen aller Jobs der Liste a. Für alle Jobs in der Liste: Plane den Job auf einer Ressource ein 1 Initialisierung Der Einstiegspunkt des Algorithmus ist die Klasse LSMain. Diese wird mittels Konstruktor zunächst initialisiert; gleichzeitig wird eine Referenz auf das Programm GORBA übergeben. Aus dieser Referenz werden später die Ressourcenbschreibungen und Applicationjobs ausgelesen. Über den Aufruf einer main-methode wird der Algorithmus gestartet. Der main-methode werden der früheste Startzeitpunkt, sowie eine Prioritätsregel für die Ressourcenwahl zur Erstellung des Schedules übergeben: Aus der Gorba-Referenz wird dann die theoretisch maximale Fertigstellungszeit gelesen (diese ist nicht gleichzusetzen mit den vom Benutzer vorgegebenen gewünschten Fertigstellungszeiten für die Applicationjobs). Dieser Schritt wird benötigt, um später die Zeitschlitze der Ressourcen ordnungsgemäß berechnen zu können. Darauf folgt das Einlesen der Ressourcen in der Methode createresources. Hier werden alle Ressourcen aus allen vorliegenden Applicationjobs gelesen und danach 39

50 entsprechende OptResource-Objekte initialisiert, welche als Wrapper für Ressourcen dienen. Als Container für diese wird eine LinkedHashMap verwendet: Nachdem die Ressourcen geladen wurden, wird die Liste der zu planenden Gridjobs erstellt. Dies geschieht in der Methode creategridjobstoschedule. Gleichzeitig werden die für den Gridjob benutzbaren Ressourcen zugewiesen. Dafür werden alle Applicationjobs durchlaufen und ihre ersten Gridjobs (Gridjobs ohne Vorgänger) als OptGridjob einer Liste hinzugefügt. Die ersten Gridjobs werden gewählt, da aus ihnen anhand von Nachfolgebeziehungen alle anderen Gridjobs gelesen werden können: Die Vorgänger- und Nachfolgerbeziehungen können nicht direkt aus den originalen Gridjobs übernommen werden. Dies hängt mit der Struktur der Daten zusammen, wie sie von GORBA geliefert werden. Würden diese Daten direkt verwendet werden, wäre eine Kapselung nicht mehr möglich. Es würden durch den Algorithmus die Objekte von GORBA direkt verändert werden. Dies würde eine Bearbeitung derselben Daten durch einen weiteren Algorithmus verhindern. Deshalb werden diese neu generiert, was nach dem Einlesen aller ersten Gridjobs geschieht. 40

51 2 Erstellen der Liste Abbildung 6: Beispiel zur Pfaderstellung für List Scheduling Wie die Liste erstellt wird, ist durch den ursprünglichen Algorithmus nicht vorgeschrieben. Deswegen wurde eine eigene Lösung entwickelt: Nachdem alle Vorgänger- und Nachfolgerbeziehungen erstellt worden sind, muss die Liste erstellt werden, welche die Reihenfolge der Planung der Gridjobs angibt. Dafür werden alle möglichen Pfade von allen ersten Gridjobs (Gridjobs ohne Vorgänger) zu allen letzten Gridjobs (Gridjobs ohne Nachfolger) erstellt und gespeichert. Dies geschieht in der rekursiven Funktion createallpaths. Diese Pfade sind Ketten von Gridjobs mit je einem oder keinem Nachfolger/Vorgänger. Die Erstellung der Pfade wird an einem Beispiel in Abbildung 6 dargestellt. Der Applicationjob in dieser Darstellung besitzt fünf Gridjobs. Der erste Gridjob ist Gridjob1, der letzte Gridjob ist Gridjob5. Ausgehend von Gridjob1 wird nun jeder Pfad zu Gridjob5 abgesucht. Da Gridjob1 bereits zwei Nachfolger hat, müssen mindestens zwei Pfade entstehen. Es gibt keine weiteren Verzweigungen in dem Graph, so dass es bei den zwei dargestellten Pfaden bleibt. Die maximale Länge jeden Pfades wird dann auf die Anzahl der zu diesem Zeitpunkt enthaltenen Gridjobs gesetzt. Dieser Wert wird folgend auch als ursprüngliche Länge bezeichnet. 41

52 Abbildung 7: Erstellung der Liste für das List Scheduling Aus den Pfaden wird dann die Liste für das Scheduling erstellt. Dies geschieht in der Methode createlslist. L now sei die aktuelle Länge (Anzahl Gridjobs) von Pfad p und L orig sei die ursprüngliche Länge von p. Es wird nach und nach aus einem Pfad, für den L now /L orig größer als bei allen anderen Pfaden ist, der erste Gridjob entfernt und der Liste hinzugefügt (bei mehreren gleichen Werten wird einer der Pfade zufällig gewählt). Der entfernte Gridjob wird auch aus allen anderen Pfaden, in denen er enthalten ist, entfernt. Besitzt ein Pfad danach keine Gridjobs mehr, so wird er aus der Liste der Pfade entfernt. Würde der Gridjob nur nach L now gewählt werden, könnte es vorkommen, dass Gridjobs mit ihrer Planung auf sehr lange Pfade warten müssen. Die Jobs in der Liste werden in ihrer Reihenfolge später nicht mehr verändert, daher muss sichergestellt werden, dass die frühesten Startzeiten aller Gridjobs bereits feststehen. Dies ist durch die beschriebene Methode zur Erstellung der Pfade und der Liste 42

53 gewährleistet. In Abbildung 7 kann die Erstellung der Liste am Beispiel aus Abbildung 6 nachvollzogen werden. 3 Einplanen der Gridjobs Nach der Erstellung der Liste wird über diese iteriert und somit jeder enthaltene Gridjob abgearbeitet. Für jeden Job wird eine Ressource aus den vorhandenen Ressourcen nach der in der main-methode übergebenen Ressourcenregel ausgewählt. Hier zeigt sich der Vorteil der Prioritätsregeln, weil durch ihre Verwendung eine Erweiterung oder Abänderung leicht möglich. Ist der Algorithmus am Ende der Liste angelangt, so ist ein Schedule erstellt worden. Anschließend wird der Schedule in einen GorbaSchedule (Schedule, welcher in der Form vorliegt, dass er von GORBA direkt verwendet werden kann) umgewandelt und an die Gorba-Instanz zurückgegeben, wo dieser weiter verwendet werden kann (zum Beispiel um von der externen Bewertungskomponente bewertet zu werden). Besonderheiten Das Problem, welches bei der Planung dieses Algorithmus auftrat, ist die Parallelität von Applicationjobs selbst, sowie deren Gridjobs. Durch die Parallelität ist es schwer, eine Liste zu erstellen, welche Vorgänger- und Nachfolgerbeziehungen wahrt. Zudem wird eine gute Verteilung der einzelnen Applicationjobs angestrebt. Der Grund dafür ist der, dass bei Zwar kann es vorkommen, dass gewisse Applicationjobs viel früher fertig sein müssen als andere, aber davon soll hier bei der Erstellung der Liste nicht ausgegangen werden. Es wird stattdessen eine möglichst gute Verteilung der Gridjobs angestrebt. Der erste Ansatz zur Erstellung der Liste war, alle Gridjobs einem Pool hinzuzufügen und dann nach und nach aus diesem Pool den Gridjob herauszunehmen, welcher theoretisch als erstes starten könnte. Dies wurde verworfen, weil dafür für jeden Gridjob und jeden seiner Vorgänger die Startzeiten, sowie Bearbeitungsdauern auf allen möglichen Ressourcen, auf denen diese Gridjobs theoretisch bearbeitet werden könnten, zu berechnen sind. Die gewählte Lösung pfadbasierte Lösung bietet den Vorteil, dass die Gridjobs in den Applicationjobs sehr gut verteilt werden. Der Nachteil ist, dass die gleichmäßige Verteilung auch Applicationjobs selber betrifft. Dies könnte möglicherweise gute Ergebnisse bei Tests verhindern, da somit beispielsweise alle letzten Gridjobs (Gridjobs ohne Nachfolger) zeitnah dem Ende des längsten Applicationjobs geplant werden, sogar wenn die Applicationjobs sehr unterschiedliche Vorgaben hinsichtlich des vom Benutzer vorgegebenen Fertigstellungszeitpunkts besitzen. 43

54 Ein weiteres Problem waren die verschiedenen Kriterien, anhand welcher ein GORBA- Schedule bewertet wird. Die Heuristik arbeitet nur mit jeweils einer Ressourcenregel, so dass verschiedene Optimalitätskriterien nicht beachtet werden gorba.optimization.shiftingbottleneck In diesem Package befinden sich die Klassen für Shifting Bottleneck. Sie werden nur vom Shifting Bottleneck Algorithmus verwendet. Tabelle 16: Klassen im Package gorba.optimization.shiftingbottleneck Klassenname SBMain SBGridjob SBResourceGroup Kurzbeschreibung Hauptklasse für Shifting Bottleneck. Wrappt einen Gridjob, spezialisiert für Shifting Bottleneck. Eine Gruppe von Ressourcen, welche gleichzeitig als Flaschenhals dient. Beim Shifting Bottleneck wird versucht, ein JSSP in mehrere 1-Maschinen-Probleme zu zerlegen, diese zu lösen, und am Ende zusammenzufügen. Skizze des Verfahrens: 1. Initialisierung der erforderlichen Daten 2. Lösen eines 1-Ressourcengruppe-Sequenzierungs-Problems der Gridjobs für jede Ressource 3. Ordnen der Ressourcen nach einem Flaschenhalskriterium 4. Einfügen der sequenzierten Gridjobs jeder Ressource in den Hauptschedule. 5. Nachoptimierung 1 Initialisierung: Um den Algorithmus zu starten, muss dieser vorher durch die Klasse SBMain durch einen Konstrutkor initialisiert werden. Diesem Konstruktor wird eine Gorba-Instanz übergeben, welche intern gespeichert wird. Diese Instanz stellt das Programm GORBA dar und beinhaltet alle eingelesenen Daten, wie Ressourcenbeschreibungen und Applicationjobs. Um den Algorithmus zu starten, muss eine main-methode aufgerufen werden, welcher eine frühestmögliche Startzeit und eine Prioritätsregel für die Wahl von Ressourcen übergeben werden muss: Bis hierhin unterscheidet sich die Implementierung nicht von der des List Scheduling. 44

55 Allerdings werden beim Shifting Bottleneck Ressourcengruppen benötigt, womit sich die Initialisierungsphasen in den folgenden Schritten unterscheiden. Zuerst werden alle Applicationjobs aus der Gorba-Instanz ausgelesen und somit die Liste der zu planenden Gridjobs erstellt. Allerdings gibt es keine Zuweisung von benutzbaren Ressourcen zu den Gridjobs! Zudem werden nicht nur die ersten Gridjobs ausgelesen, sondern alle zu planenden. Das Einlesen der Gridjobs geschieht in der Methode creategridjobstoschedule: Sind alle Gridjobs eingelesen, werden aus den Gridjobs die Ressourcen erstellt. Dabei wird so vorgegangen, dass die benutzbaren Ressourcen (diese sind in den Gridjobs bereits als Liste vorhanden) aus den Gridjobs gelesen werden und daraus Ressourcengruppen aufgebaut werden: 45

56 Zunächst wird eine leere Liste von Ressourcen initialisiert. Es wird also die Liste der benutzbaren Ressourcen jedes Gridjobs durchlaufen. Für jede der Ressourcen wird zunächst die Zeitlinie (TimeSlotList) ausgelesen und die Bearbeitungsdauer des Gridjobs auf der Ressource berechnet. Danach wird anhand der Zeitlinie abgefragt, ob der Gridjob theoretisch auf der Ressource geplant werden kann. Ist dies der Fall, so wird die Ressource der Liste der passenden Ressourcen (reslist2) für diesen Gridjob hinzugefügt. Zusätzlich wird noch für jeden Gridjob und somit für jede Ressourcengruppe eine gesamte Verfügbarkeitszeit (longtimeslottime) berechnet. Diese setzt sich zusammen aus der Summe der Länge aller Zeitschlitze aller Ressourcen in der Ressourcengruppe und wird später beim Eliminieren von Ressourcen aus Ressourcengruppen verwendet. Anmerkung: reslist2 ist nicht die entstandene Ressourcengruppe, beinhaltet aber die gleichen Ressourcen. Zu der Ressourcengruppe gehören weitere Attribute, wie zum Beispiel gesamte Verfügbarkeitszeit und die enthaltenen Gridjobs. Wird so eine Ressourcenliste generiert, die exakt die gleichen Ressourcen beinhaltet, wie eine vorher generierte Ressourcengruppe, so wird die Liste nicht als eigenständige Ressourcengruppe gespeichert, sondern es wird einfach der Gridjob der bereits 46

57 bestehenden Ressourcengruppe hinzugefügt. Wenn keine solche Ressourcengruppe besteht, wird eine neue Ressourcengruppe aus der Ressourcenliste erstellt und der Gridjob hinzugefügt. Wird ein Gridjob zu einer Ressourcengruppe hinzugefügt, so wird gleichzeitig in dem Gridjob eine Referenz auf diese Ressourcengruppe gespeichert. Wurden auf diese Weise alle Ressourcengruppen erstellt, werden aus ihnen die Ressourcen, welche gleich sind, eliminiert. Dafür wird für jede Ressourcengruppe die Methode makedisjunct mit jeder anderen Ressourcengruppe als Parameter aufgerufen. In dieser Methode werden zunächst die Ressourcen gezählt, die bei beiden Ressourcengruppen gleich sind, und in einer Liste gespeichert. Solange noch gleiche Ressourcen in den Gruppen existieren, muss aus einer der beiden Gruppen eine Ressource entfernt werden. Es gibt verschiedene Fälle, die dabei auftreten können: Fall 1: Der erste Fall ist der, dass beide Ressourcengruppen nur jeweils eine Ressource besitzen. Dieser Fall kann nicht von vornherein auftreten, da gleiche 47

58 Ressourcengruppen bei der Erstellung ausgeschlossen werden (siehe oben). Allerdings kann Eliminieren von Ressourcen aus Ressourcengruppen zu exakt diesem Zustand führen. Deshalb muss auch dieser Fall überprüft werden. Tritt dieser Fall also ein, werden alle Gridjobs der zweiten Ressourcengruppe der ersten hinzugefügt und in den Gridjobs die Referenzen auf die Ressourcengruppe dementsprechend aktualisiert. Schließlich wird aus der zweiten Ressourcengruppe die Ressource entfernt. (Leere Ressourcengruppen werden aus der Liste der Ressourcengruppen später entfernt.) Fall 2: Der zweite Fall ist der, dass in einer der Ressourcengruppe nur eine Ressource vorhanden ist, in der anderen Gruppe aber mindestens zwei Ressourcen. In diesem Fall wird die gleiche Ressource aus der Gruppe mit mehreren Ressourcen entfernt. Fall 3: Gibt es in beiden Ressourcengruppen mehr als eine Ressource, so wird anhand zweier berechneter Werte ermittelt, aus welcher Ressourcengruppe die Ressource entfernt werden soll. Der Wert wird mithilfe der maximalen Bearbeitungszeit aller Gridjobs der Gruppe und mit deren gesamten Verfügbarkeitszeit berechnet. Aus der Gruppe mit dem kleineren Ergebnis wird die Ressource entfernt. (Denkbar wäre auch die Verwendung der gesamten summierten Gridjob-Bearbeitungszeiten.) Wurden aus allen Ressourcengruppen die identischen Ressourcen eliminiert, kann es vorkommen, dass bestimmte Ressourcengruppen keine Ressourcen mehr enthalten. Diese werden aus der Liste der Ressourcengruppen entfernt. 2 Lösung der 1-Ressourcen-Sequenzierungs-Probleme Im Anschluss daran werden alle verbliebenen Ressourcengruppen verplant. Dafür werden alle der Gruppe zugewiesenen Gridjobs mit der Prioritäts-Regel auf die Ressourcen der Ressourcengruppe verplant. Bevor die Planung allerdings stattfinden kann, müssen den Gridjobs die benutzbaren Ressourcen zugewiesen werden, da dies aufgrund von möglichen Änderungen bezüglich der Ressourcengruppe zu einem früheren Zeitpunkt noch nicht möglich war. Nach der Planung aller Gridjobs einer Gruppe wird deren Verspätung (lateness) berechnet sowie die Gridjobs nach ihren Fertigstellungszeiten absteigend geordnet. 3 Ordnen nach Flaschenhalskriterium Sind alle Ressourcengruppen komplett verplant, so werden sie jetzt nach ihrer Verspätung absteigend geordnet. Die Ressourcengruppe mit der größten Verspätung steht nun also an erster Stelle. 48

59 4 Einordnung in den Hauptschedule Aus diesen geordneten Ressourcengruppen wird nun eine neue Ressourcengruppe erstellt, welche alle Ressourcen der einzelnen Gruppen sowie alle Gridjobs der einzelnen Gruppen enthält, so wie sie angeordnet wurden. Die Planungsergebnisse, bis auf die Sequenzierung der Gridjobs werden nun verworfen und die Gridjobs erneut geplant, aber in der aus den Einzelplanungen hervorgegangenen Reihenfolge. Die Reihenfolge wird allerdings nicht beachtet, falls ein Gridjob noch nicht bearbeitete Vorgänger besitzt. Diese werden stets zuerst bearbeitet. 5 Nachoptimierung Anschließend erfolgt eine Nachoptimierung über das in Abschnitt beschriebene Verfahren. Schließlich wird der erstellte Schedule in einen vom GORBA-Programm verwertbaren Schedule umgewandelt und an GORBA zurückgegeben. Besonderheiten: Das Verwenden der Verspätung als Flaschenhalskriterium ist für das GORBA-Problem nicht die einzige Möglichkeit. Das Kriterium ist relativ einfach mit einem anderen austauschbar. Auch nach mehreren Kriterien kann theoretisch geordnet werden. Hierfür kann eine Fitnessfunktion eingesetzt werden. In GORBA wird das Problem von einem 1-Maschinen-Problem (bzw. 1-Ressourcen- Problem) zum 1-Ressourcengruppen-Problem. Ressourcengruppen gibt es allerdings in GORBA nicht. Deshalb müssen aus den Anforderungen der Gridjobs bestimmte Ressourcengruppen erstellt werden. Diese werden aber durch das Eliminieren von identischen Ressourcen oft wieder zu wenigen Ressourcengruppen zusammengefasst. Der ursprüngliche Algorithmus geht von genau einer passenden Maschine für jede Operation aus. Dies ermöglicht das schnelle Lösen der Sequenzierungsprobleme, da nur jeweils eine Maschine betrachtet werden muss. Um dies auch beim GORBA- Problem weitestgehend zu ermöglichen, kann auf das Eliminieren von identischen Ressourcen nicht verzichtet werden. Das Problem, welches hier in Erscheinung tritt, ist, dass es bei GORBA viele gleichartige Hardware-Ressourcen geben kann, welche durch Werkzeuge wie zum Beispiel installierte Programme weitere Funktionen bekommen können. Zudem kann es auch vorkommen, dass Ressourcen zwar gleiche Funktionen bewältigen können, aber unterschiedlich schnell sind oder zu unterschiedlichen Zeitschlitzen zur Verfügung stehen. Weitere Ressourcen decken umfangreiche Funktionen ab, bieten aber gleichzeitig grundlegende Aufgaben. Es ist daher äußerst schwierig, gut geeignete Ressourcengruppen zu finden. Gibt es beispielsweise nur große Ressourcengruppen (solche die aufgrund von Zusammenfassungen viele 49

60 Gridjobs bearbeiten müssen) wirkt sich auch auf die Performance negativ aus. Je mehr Ressourcen die Gridjobs zur Auswahl haben, desto mehr Ressourcen müssen je Gridjob überprüft werden. Einer Ressourcengruppe sind die Gridjobs zugeordnet, die auf einer der enthaltenen Ressourcen ausgeführt werden müssen. Die Gridjobs besitzen allerdings noch Vorgänger- und Nachfolgebeziehungen, welche möglicherweise nicht der gleichen Ressourcengruppe zugeordnet sind. Das heißt, wenn die Planung der Ressourcengruppen abgeschlossen ist, sind die Gridjobs zwar sequenziert, aber nur pro Ressourcengruppe. Besitzen die Gridjobs außerhalb der Ressourcengruppe noch Abhängigkeiten, so müssen diese erneut bearbeitet werden. Das Problem soll an einem einfachen Beispiel verdeutlicht werden: Abbildung 8: Problem bei Shifting Bottleneck Gegeben sei die Umgebung aus Abbildung 8. Gridjob1 ist Vorgänger von Gridjob2, welcher wiederum Vorgänger von Gridjob3 ist. Res1 ist Ressourengruppe1 und Res2 die Ressourcengruppe2. Auf beiden Ressourcengruppen werden nun die zugehörigen Gridjobs verplant und somit sequenziert. Sei Ressourcengruppe1 die mit der höheren Verspätung, dann wird bei Zusammenlegung der Ressourcengruppen und erneuter Planung nun laut Reihenfolge der Gridjobs zuerst Gridjob1, dann Gridjob3 und dann Gridjob2 verplant. Da allerdings Gridjob2 Vorgänger von Gridjob3 ist, muss dieser vor Gridjob3 verplant werden, was das ganze Shifting Bottleneck in diesem einfachen Fall ignorieren würde. Bei größeren Problemen können die Auswirkungen noch viel drastischer werden. Der ursprüngliche Algorithmus sieht ein nochmaliges Sequenzieren nach dem Hinzufügen einer Bottleneck-Maschine vor, dies kann bei GORBA aber sehr komplex werden, vor allem da es bei den Maschinen unterschiedliche Geschwindigkeiten und Zeitslots gibt. Eine Umsortierung würde oft eine komplette Neuerstellung des Schedules bedeuten. 50

61 4.2.8 gorba.optimization.tabusearch In diesem Package befinden sich die Klassen für die Tabu-Suche. Sie werden nur von der Tabu-Suche verwendet. Tabelle 17: Klassen im Package gorba.optimization.tabusearch Klassenname TSMain TSScheduler TSSolution Kurzbeschreibung Hauptklasse für die Tabu-Suche. Klasse, mit der eine TSSolution geplant werden kann. Ein Schedule, der mit der Tabu-Suche erstellt wurde oder werden soll. Tabu-Suche ist eine Metaheuristik. Das Verfahren geht im allgemeinsten Fall folgendermaßen vor: Zuerst wird eine zufällige Lösung erstellt und ausgehend davon wird in einer bestimmten Anzahl von Iterationen je eine Nachbarschaft generiert. Die Nachbarschaft wird durch Änderungen an der ersten Lösung erzeugt. Die Lösungen in der Nachbarschaft werden dann durchsucht und bestimmte Lösungen werden anhand von Tabukriterien, welche nicht genau vorgegeben sind, als Tabu gekennzeichnet. Alle Tabus werden weiterhin auf ihre Eignung als Aspirant überprüft. Das bedeutet, eine Tabu-Lösung kann trotzdem weiter verwendet werden, wenn sie gleichzeitig Aspirant ist. Lösungsdarstellung: Wesentlich ist, dass die Darstellung für die Änderung und somit für die Erzeugung der Nachbarschaft geeignet ist; ein Schedule selbst als Darstellung wäre sonst okay. Mögliche Darstellungsformen sind beispielsweise Reihenfolgen von Gridjobs oder eine Menge von unterschiedlichen Prioritätsregeln zur Generierung eines Schedules. In Anlehnung an Baykasoglu [27] wurde letztere Darstellungsform für das GORBA- Problem gewählt. Dort wird eine Methode beschrieben, wie aus einzelnen Regeln einen Schedule aufgebaut werden kann, und wie diese Regeln den entstehenden Schedule beeinflussen können. Regeln, die vorgestellt werden, sind: SPT (Shortest Process Time) EDD (Earliest Due Date) LPT (Longest Process Time) MWR (Most Work Remaining Time) LWR (Least Work Remaining Time) PDR (Process/Remaining Time) ERD (Earliest Release Date) MS (Minimum Slack) 51

62 LNS (Largest Number of Successors) WSPT (Weighted Shortest Process Tme) Eine Lösung besteht nun aus einer Reihe von Regeln, die an bestimmten Positionen (Nummer des aktuellen Durchlaufs bei der Schedule-Erstellung) benutzt werden, zum Beispiel: Position Regel EDD LNS LWR PDR ERD EDD ERD WSPT LPT EDD Für das Erstellen eines Schedules aus dieser Lösungsdarstellung wird in der Literatur eine Implementierung des Giffler-Thompson-Algorithmus verwendet, welcher vor der Selektion eines jeden Jobs die aktuelle Regel zur Wahl des Jobs benutzt, und keine universelle Regel für alle Schritte gleichzeitig, wie beim eigentlichen GTA vorgesehen. Ein Ändern einzelner Regeln in eine andere kann den entstehenden Schedule beeinflussen, indem an einer bestimmten Position ein anderer Gridjob gewählt wird, als durch die ursprüngliche Regel. Der Vorteil dieser Methode ist, dass sehr verschiedene Lösungen erstellt werden und somit ein großer Kreis von möglichen Lösungen abgedeckt wird. Der zweite Vorteil ist, dass jede Lösung automatisch zulässig ist. Bei der implementierten Version des Algorithmus wird kein GTA verwendet. Außerdem werden nur einige der oben genannten Regeln verwendet. Dafür gibt es weitere Regeln. Diese werden bereits in Abschnitt 0 und vorgestellt. Skizze des Verfahrens: 1. Initialisierung 2. Erstellen einer ersten Lösung s start a. s best = s start 3. Iteration bis ein Abbruchkriterium erfüllt ist: a. Erstellung einer Nachbarschaft N(s start ) b. Erstellung/Aktualisieren der Tabu-Liste T(N) c. Erstellung der Aspiranten-Liste A(T) d. Bestimmung einer neuen Lösung s* aus (N\T) A und s start = s* e. Wenn s* besser als s best ist: s best = s* 1 Initialisierung Der Einstiegspunkt zur Tabu-Suche befindet sich in der Klasse TSMain. Dort wird der Algorithmus über einen Konstruktor zunächst initialisiert. Er erhält dabei eine Referenz 52

63 auf eine GORBA-Instanz, welche das Programm GORBA darstellt. Über eine main- Methode wird der Algorithmus gestartet. Diese Methode ist parametrisierbar: Die Bedeutung der Parameter wird in Tabelle 18 gezeigt. Im Laufe der Erläuterung wird näher auf die Parameter eingegangen. Tabelle 18: Parameter für die Tabu-Suche starttime tabulistsize nochangelimit individuals minchange Frühestmögliche Startzeit für den zu erstellenden Schedule. Größe der Tabu-Liste. Anzahl der Durchgänge, die maximal durchlaufen werden können, ohne dass eine Verbesserung des Schedules erreicht wurde. Anzahl der Individuen, die pro Durchgang erstellt werden. Minimale Chance der Änderung einer Regel im Gridjob-Regelsatz In dieser main-methode wird zunächst ein TSSolution-Objekt (Lösung) mit der GORBA-Referenz und der frühestmöglichen Startzeit starttime initialisiert: 2 Erstellen einer ersten Lösung Im Konstruktor dieser Lösung wird dann die theoretisch maximale Länge des resultierenden Schedules anhand der GORBA-Referenz berechnet. Anschließend werden die Ressourcen aus den Applicationjobs gelesen, welche von der GORBA- Referenz zur Verfügung gestellt werden. Dabei wird für jede Ressource ein OptResource-Objekt erzeugt. Für dieses Objekt wird dann über die frühestmögliche Startzeit sowie die maximale Länge des Schedules eine Zeitlinie (OptTimeLine) erzeugt, welche die verfügbaren Zeitschlitze der Ressource darstellt. Anschließend werden die ersten Gridjobs (Gridjobs ohne Vorgänger) aus den Applicationjobs gelesen, welche von der GORBA-Instanz zur Verfügung gestellt werden. Es werden nur die ersten Gridjobs gelesen, da aus diesen alle anderen Gridjobs aus den Nachfolgerbeziehungen gelesen werden können. Die gelesenen Gridjobs werden in OptGridJob-Objekte verpackt; anschließend werden Vorgänger- und Nachfolgerbeziehungen für diese neuen Objekte neu erzeugt. Dieses erhält bereits bei 53

64 Initialisierung die schon eingelesenen Ressourcen als Parameter und berechnet daraus sofort die benutzbaren Ressourcen zur späteren Verwendung: Dieser Schritt ist notwendig, da sonst die originalen Objekte im Verlauf des Gridjobs verändert werden müssten. Dies hätte zur Folge, dass bereits nach der ersten TS- Iteration nicht mehr mit den von GORBA bereitgestellten Daten gearbeitet werden kann. Nachdem die Gridjobs eingelesen und umgewandelt wurden, wird nun die Zufallskomponente initialisiert. Diese besteht aus zwei zufälligen Prioritätsregelsätzen. Ein Regelsatz ist für die Gridjob-Prioritätsregeln zuständig, der andere für die Ressourcen-Prioritätsregeln. Für die zufällige Wahl von Regeln stellt die Klasse TSSolution zwei statische Arrays mit Regeln zur Verfügung. Jeder Regelsatz besteht aus X Regeln, wobei X die Anzahl der zu planenden Gridjobs ist. Jede der Regeln wird aus dem entsprechenden statischen Array zufällig ausgewählt: Nach dem Initialisieren der Lösung kann aus dieser nun ein Schedule erzeugt werden. Dies wird aus der main-methode von TSMain heraus getan, indem die schedule- Methode von TSSolution aufgerufen wird. In dieser Methode wird ein neues TSScheduler-Objekt erzeugt. Diesem werden die relevanten Daten (erste Gridjobs, Startzeit, Gridjob-Regeln, Ressourcen-Regeln) übergeben: 54

65 Der Scheduler verändert die ihm übergebenen Gridjobs, sowie die Ressourcen, auf denen die Gridjobs verplant werden. Zunächst wird für jeden der übergebenen Gridjobs die frühestmögliche Startzeit festgelegt. Diese berechnet sich aus der übergebenen Startzeit + die vorgegebene Startzeit des zum Gridjob gehörenden Applicationjobs. Außerdem wird eine Referenz auf jeden der Gridjobs in eine Liste eingetragen (m_vecfirstgridjobs - auch die Klasse TSScheduler besitzt eine solche Liste als Attribut). Zusätzlich wird ein Zähler mit dem Wert 0 dekliniert. Er wird benutzt, um bei jedem Durchlauf die aktuelle Ressourcen-Regel und Gridjob-Regel auszuwählen. Dieser Gridjob wird dann auf der entsprechenden Ressource eingeplant. Anschließend wird der Gridjob aus der Liste entfernt. Die frühestmöglichen Startzeiten seiner Nachfolger werden danach aktualisiert. Schließlich werden die Nachfolger der Liste hinzugefügt, falls sie nicht noch weitere Vorgänger besitzen. Wenn es keine Gridjobs mehr in der Liste gibt, ist der erste Schedule erstellt: Im Anschluss daran wird die Fitness des Schedules berechnet und gespeichert. Bei der Berechnung der Fitness werden die Bearbeitungszeit der einzelnen Applicationjobs, die Kosten der einzelnen Applicationjobs, und die Verspätung der Jobs hinsichtlich ihrer Fälligkeitszeit beachtet. 55

66 3 Iterationen zur Erstellung neuer Schedules Anschließend werden solange neue Schedules erzeugt, bis sich über eine gewisse Anzahl von Iterationen der beste Schedule nicht geändert hat. Die maximale Anzahl an Iterationen ohne Verbesserungen, also erfolglose Durchläufe, wird durch den Parameter nochangelimit bestimmt. 3.a - Die Nachbarschaft: Zunächst muss in jedem Durchlauf eine Nachbarschaft zu einem Ausgangs- Schedule generiert werden. Um einen Nachbar zu generieren, werden die Regelsätze, mit denen der ursprüngliche Schedule generiert wurde, verändert. Mit diesen neuen Regeln wird dann ein neuer Schedule nach oben beschriebener Vorgehensweise erstellt. Dieser Schedule ist Nachbar der ursprünglichen Lösung. Die Nachbarschaft besteht aus einer Menge von Schedules. Die Anzahl der Schedules in der Nachbarschaft ist durch den Parameter individuals vorgegeben. Je mehr erfolglose Durchläufe aufeinander folgen, umso mehr werden die Regelsätze verändert. Die Regelsätze für Ressourcen-Regeln werden erst ab intnochangelimit/3 erfolglosen Durchläufen geändert, um zunächst in einer näheren (weniger Änderungen unterliegenden) Nachbarschaft suchen zu können. Sind die Regeln für Gridjobs und Ressourcen die gleichen wie die, die zu einem vorherigen besten Schedule führten, so wird der Schedule nicht neu erzeugt. Ansonsten wird er erzeugt und der Nachbarschaft hinzugefügt. Zunächst gab es nur für die Gridjob-Bestimmung Regeln, die Regeln zur Bestimmung der nächsten Ressourcen waren konstant und für jeden Bearbeitungsschritt gleich. Dies wurde im Laufe der Entwicklung geändert, um eine größere Lösungsvielfalt erzeugen zu können. Für diese Änderungen wurden verschiedene Parameter eingeführt. Diese Parameter sind: K GJ = Parameter, welcher die Anzahl der zu ändernden Gridjob-Regeln bestimmt K RES = Parameter, welcher die Anzahl der zu ändernden Ressourcen- Regeln bestimmt Die eigentlichen Regeländerungen werden nun über sogenannter Schritte (Objekte der Klasse TSStep) bestimmt. Hier wird angegeben, wie ein Regelsatz verändert werden soll. Die Möglichkeiten sind dabei prozentual oder total. Diese Information wird im ersten Parameter von einem Schritt angegeben. Im zweiten Parameter liegt dann der Prozentwert (0..100) bzw. ein konkreter Wert. Wird prozentual angegeben, so werden X Prozent Regeln mit 56

67 anderen zufälligen Regeln ersetzt. Wird total angegeben, so werden X Regeln mit anderen zufälligen Regeln ersetzt. In der aktuellen Implementierung bleiben diese Schritte über den gesamten Verlauf der Schedule-Erstellung gleich, das heißt in jedem Durchlauf werden X Prozent oder X Regeln durch neue ersetzt. Für diese Ersetzung wird an einer zufälligen Stelle eine Regel genommen und mit einer neuen ersetzt. Dabei kann es vorkommen, dass zweimal an der gleichen Stelle getauscht wird, denn eine Überprüfung, ob an der betroffenen Stelle in diesem Durchgang schon eine Ersetzung geschah, findet nicht statt. Anfangs waren diese Ersetzungen mit gleicher Erfolgswahrscheinlichkeit von 100% durchgeführt worden. Das bedeutet, jede Ersetzung wurde auch immer durchgeführt. Im Verlauf der Entwicklung wurde hier aber eine Verfeinerung eingeführt, die zu frühe zu große Änderungen eines Schedules verhindern soll. Dafür wurde ein weiterer Parameter eingeführt: K GJ MIN (in der Implementierung m_dblminchange) ist der Parameter zur Bestimmung der minimalen Änderungschance. Dieser Parameter gibt an, mit wie viel % Chance eine Änderung einer Regel übernommen werden muss. Dies ist jeweils abhängig von der Anzahl der Gridjobs n die geplant werden müssen (=Anzahl der Durchläufe, die der Algorithmus für die Erstellung eines Schedules benötigt). Ist K GJ MIN beispielsweise 80%, so hat eine Änderung der Regel an der ersten Stelle eine 80%ige Chance, übernommen zu werden. Die Änderung der Regel an der letzten Stelle wird immer mit 100% übernommen. Die Chance C i der Regel an Stelle i, übernommen zu werden, ist: C i = K GJ MIN + i 100 K GJ MIN n (2) Da es möglich ist, dass sich über mehrere Durchläufe keine Verbesserungen einstellen (der Durchlauf also erfolglos war), wurde allerdings eine weitere Methode zur generellen Erhöhung der Änderungschance eingebaut um Verbesserungen, bzw. Veränderungen, des Schedules zu begünstigen. Zu Beginn des Algorithmus wird eine Variable initialisiert, welche angibt, wie viele Stellen in einem Regel-Set pro Durchlauf geändert werden sollen (entweder prozentual oder total). Mit jedem Durchlauf, der keine Verbesserung des Schedules brachte, wird folgende Formel angewandt, wobei D cnt für die aktuelle Anzahl der erfolglosen Durchläufe steht: K GJ = K GJ + K GJ D cnt 10 (3) 57

68 Wenn zum Beispiel K GJ = 50 ist, können pro Durchlauf theoretisch 50% der Gridjob-Regeln geändert werden. Dieser Wert erhöht sich dann mit jedem Durchlauf, bei dem keine Verbesserung stattfand. Jeder Wert über 100% wird wie 100% behandelt. Wird eine Verbesserung des Schedules festgestellt, so wird K GJ auf seinen ursprünglichen Wert zurückgesetzt. 3.b - Die Tabu-Liste: Die Tabu-Liste wird mit jedem Durchlauf erweitert, bzw. aktualisiert. Alle Lösungen, die gleiche Regelsätze besitzen, wie ein vorher generierter bester Schedule, werden automatisch entfernt, bevor es zum Erstellen eines Schedules kommt. Zusätzlich sind alle Nachbarn eines Schedules ein Tabu, welche eine schlechtere Fitness als der Eltern-Schedule besitzen, allerdings nur maximal so viele, bis die Tabu-Liste voll ist. Falls ein Schedule an eine volle Tabu-Liste angefügt werden soll, wird der als erstes angefügte Schedule aus der Tabu-Liste entfernt und der neue Schedule wird angefügt. Die Größe der Tabu-Liste wird durch den Parameter tabulistsize begrenzt. 3.c - Die Aspiranten-Liste: Zum Erstellen der Aspiranten-Liste wird zunächst aus der Nachbarschaft eine Liste von Pareto-Nachbarn erstellt. Diese Schedules sind so definiert, dass sie in mindestens einem Kriterium besser sein müssen, als jeder andere Schedule der Nachbarschaft. Die Kriterien, nach welchen kontrolliert wird, sind Kosten und Geschwindigkeit. Für diese Kriterien wird bei der Erstellung eines Schedules ein entsprechender Wert berechnet. Aspiranten sind nun solche Lösungen, die sowohl Tabu als auch Pareto-Nachbar sind. 3.d und e Neue Lösung und Aktualisieren der Ausgangslösung: Nun wird überprüft, ob es Schedules in der Nachbarschaft gibt, welche nicht in der Tabu-Liste enthalten sind. Ist dies der Fall, so wird der beste dieser Schedules als aktueller Ausgangs-Schedule gespeichert. Außerdem wird er mit dem aktuell besten Schedule verglichen. Ist die Fitness des neuen Schedules besser, so wird er als der aktuell beste Schedule gespeichert. Befinden sich jedoch alle Nachbarn in der Tabu-Liste, so wird der beste Aspirant als neuer Ausgangs-Schedule gespeichert. Der Vergleich mehrerer Schedules erfolgt anhand einer Fitness-Funktion, welche in der Klasse TSSolution implementiert ist. 58

69 Nach einer Anzahl von nochangelimit erfolglosen Iterationen ist der Algorithmus fertig. Der aktuell beste Schedule wird in einen vom GORBA-Programm verwendbaren Schedule transformiert und an die GORBA-Instanz zurückgegeben gorba.optimization.grasp In diesem Package befinden sich die Klassen für GRASP. Sie werden nur vom GRASP Algorithmus verwendet. Tabelle 19: Klassen im Package gorba.optimization.grasp Klassenname GRASPMain GRASPScheduler GRASPSolution Kurzbeschreibung Hauptklasse für GRASP. Klasse, mit der eine GRASPSolution geplant werden kann. Ein Schedule, der mit GRASP erstellt wurde oder werden soll. GRASP ist eine weitere Metaheuristik. Der Erfolg von GRASP hängt von der Lösungsdarstellung, der Lösungskonstruktion, der lokalen Suche und der Aktualisierung der Lösung ab. GRASP ist eine Multistart-Heuristik, das heißt, dass viele parallele GRASP-Iterationen gleichzeitig gestartet werden können, ohne wichtige Informationen für das Ergebnis zu verlieren. Als Ausgangspunkt zur Implementierung wird der Algorithmus aus Binato et al. [24] verwendet. GRASP ist ein iterativer Prozess, wobei jede Iteration aus drei Schritten besteht. Diese Schritte sind das Erstellen einer zulässigen Lösung, die Lokale Suche und das Aktualisieren der aktuell besten Lösung. Die beste Lösung wird am Ende der Bearbeitung zurückgegeben. Zur Erstellen einer zulässigen Lösung wird jeweils von einer zufälligen Lösung ausgegangen. Diese Lösung wird erstellt, indem solange Gridjobs in den Schedule eingeordnet werden, bis keine Gridjobs mehr übrig sind. Dabei können natürlich nur solche Gridjobs als nächstes verplant werden, wenn alle ihre Vorgänger bereits verplant sind. All diese möglichen Gridjobs werden als beschränkte Kandidatenliste (Restricted Candidates List, RCL) zusammengefasst. Aus dieser Liste wird von den besten (nach einem Kriterium) k oder den besten α Prozent ein Gridjob zufällig gewählt, welche als nächstes verplant wird (in dieser Arbeit ist nur die Version mit α implementiert worden, sodass auf k nicht weiter eingegangen wird). Zur Bewertung der Güte wird im ursprünglichen Algorithmus nur die Makespan verwendet. Dies ist für GORBA nicht ausreichend, um gute Schedules zu erzeugen. Deshalb wird eine Fitnessfunktion verwendet, welche die Bearbeitungszeiten der Applicationjobs, die Kosten der Applicationjobs und die Verspätung der Gridjobs hinsichtlich ihrer Fälligkeiten zur Berechnung verwendet. 59

70 Es ist möglich, dass der erzeugte Schedule kein lokales Optimum darstellt. Deshalb wird nach der Erstellung einer Lösung noch mit der in vorgestellten Methode nachoptimiert. Das erreichte Ergebnis kann nun mit dem bisher besten Ergebnis verglichen und, wenn es besser ist, ausgetauscht werden. Es werden so viele Iterationen ausgeführt, bis eine Abbruchbedingung erfüllt ist. Skizze des Verfahrens: 1. Initialisierung 2. Iterationen (auch parallel möglich) bis eine Abbruchbedingung erfüllt ist: a. Erstellen einer Greedy-Randomized Lösung s i mithilfe der RCL b. Nachoptimierung ausgehend von s i mit lokaler Suche c. Aktualisieren der besten Lösung, falls s i besser als diese ist 1 Initialisierung GRASP wird über den Konstruktor der Klasse GRASPMain initialisiert, wo es eine Referenz auf das Programm GORBA bekommt. Dies macht es dem Algorithmus möglich, auf die von GORBA generierten Objekte zuzugreifen. Nach der Initialisierung kann GRASP über eine main-methode gestartet werden. Dieser Methode können Parameter übergeben werden, welche das Scheduling-Verhalten von GRASP beeinflussen: Die einzelnen Parameter werden in Tabelle 20 vorgestellt und im Verlauf dieses Kapitels näher erläutert. Tabelle 20: Parameter für GRASP starttime listsize maxiter maxtimeseconds alpha Frühestmögliche Startzeit für den zu erzeugenden Schedule Größe der Restricted Candidates List maximale Anzahl an Iterationen Zeit in Sekunden, welche GRASP verwenden soll α-wert für die RCL In dieser Methode erfolgen Parameterzuweisungen und Initialisierungen. Wichtig ist dabei eine Variable, welche die erfolglosen Iterationen zählt (der Grund dafür folgt später in diesem Kapitel). Erfolglose Iterationen sind Iterationen, die keinen besseren Schedule hervorbrachte, als den aktuell besten Schedule. 60

71 Außerdem werden in dieser Methode die GRASP Iterationen gestartet. Bevor mit den Iterationen begonnen werden kann, wird überprüft, ob eine bestimmte Anzahl Iterationen durchgeführt werden soll, oder ob der Algorithmus eine bestimmte Zeit lang laufen soll. Fall 1 maxtimeseconds 0: Hat maxtimeseconds einen Wert 0, so wird dieser Parameter ignoriert und maxiter Iterationen werden durchgeführt. Dabei gibt es noch eine Einschränkung: Waren die letzten maxiter/4 Iterationen erfolglos, wird der Algorithmus ebenfalls abgebrochen. Dieser Wert bietet dem Algorithmus genug Iterationen, die aktuell beste Lösung zu verbessern. Je mehr erfolglose Iterationen aufeinander folgen, desto unwahrscheinlicher wird eine Verbesserung. Diese Abbruchbedingung soll Zeit sparen, wenn ersichtlich ist, dass sich sowieso nichts mehr an der endgültigen Lösung ändern wird. Fall 2 maxtimeseconds 1: Ist maxtimeseconds jedoch 1, so werden so lange Iterationen durchgeführt, bis GRASP maxtimeseconds Sekunden gelaufen ist (die zu diesem Zeitpunkt laufenden Iterationen werden noch beendet). 2 GRASP Iterationen Nach der Entscheidung zu einem Abbruchkriterium können GRASP Iterationen gestartet werden, bis das entsprechende Kriterium erfüllt ist. Jede Iteration besteht aus verschiedenen Einzelschritten. Zunächst muss eine zufällige Lösung generiert werden. 2.a Erstellen einer Greedy-Randomized Lösung: Eine Lösung wird durch ein Objekt der Klasse GRASPSolution dargestellt. Dem Konstruktor dieser Klasse werden die GORBA-Instanz, die frühestmögliche Startzeit, sowie die Größe der RCL (listsize) übergeben. Im Konstruktor wird zuerst die maximale Bearbeitungszeit des Schedules aus der GORBA-Instanz gelesen und die Liste von verwendbaren Ressourcen und deren Verfügbarkeitszeiten generiert. Anschließend werden die ersten Gridjobs aus und die Prioritätsregeln erzeugt. Dieser Schritt läuft genauso ab, wie bei der Tabu-Suche (siehe Abschnitt 4.2.8). Nach dem Initialisieren kann ein Schedule erstellt werden, indem die Methode schedule von GRASPSolution aufgerufen wird. In dieser Methode wird ein Objekt der Klasse GRASPScheduler erstellt, welches dann automatisch den Schedule anlegt. Der Konstruktor von GRASPScheduler benötigt die folgenden Parameter: die Liste der ersten Gridjobs, den frühesten Startzeitpunkt, 61

72 die Gridjob-Regeln, die Ressourcen-Regeln, ein α für die RCL und die Größe der RCL (listsize). Es wird nun ein Zähler initialisiert, welcher die Zahl der aktuellen Durchläufe zählt. Dieser Zähler wird für die Wahl von Prioritätsregeln benötigt. Die RCL wird erzeugt, indem eine Menge von listsize Gridjobs aus den ersten Gridjobs in die RCL eingetragen wird. Gibt es nicht so viele Gridjobs zur Auswahl, so ist die RCL einfach nicht bis zu ihrer maximalen Anzahl Gridjobs gefüllt, aber trotzdem gültig. Aus der RCL wird anschließend einer der besten α% Gridjobs anhand der aktuellen Prioritätsregel für Gridjobs gewählt und mit der aktuellen Prioritätsregel für Ressourcen auf einer passenden Ressource eingeplant. Anschließend wird der Gridjob aus der Liste der ersten Gridjobs entfernt. Schließlich werden die Nachfolger des so eingeplanten Gridjobs aktualisiert, indem letzterer aus der Vorgängerliste aller Nachfolger entfernt wird. Außerdem wird der frühestmögliche Startzeitpunkt der Nachfolger auf das geplante Ende des eingeplanten Gridjobs gesetzt, falls dieses später ist, als der aktuell frühestmögliche Startzeitpunkt des jeweiligen Nachfolgers. Besitzen die Nachfolger nach Entfernen des eingeplanten Gridjobs aus ihrer Vorgängerliste keine weiteren Vorgänger, so werden sie in die Liste der ersten Gridjobs übernommen. Beim Aktualisieren der Nachfolger ähnelt GRASP der Tabu-Suche: 62

73 2.b Nachoptimierung: Nachdem der Schedule erzeugt worden ist, wird versucht, diesen nochmals zu verbessern. Dies wird mit der in Abschnitt beschriebenen Methode getan. 2.c Aktualisieren der besten Lösung: Anschließend wird der Schedule als bester Schedule gespeichert, falls er besser als der bisherige beste Schedule ist. Für die Einschätzung der Güte wird eine Fitness-Funktion verwendet. GRASP kann weitestgehend so implementiert werden, wie es der Pseudocode vorgibt. In allen Bereichen müssen Anpassungen gemacht werden, dies ist aber für eine Metaheuristik üblich. Für GORBA wurde die Generierung einer zufälligen Lösung direkt übernommen. Hierfür werden alle ApplicationJobs, Ressourcen und Gridjobs von 63

74 GORBA verwendet. Alle ersten Gridjobs, also die ohne Vorgängerjob, werden betrachtet und nach einem Kriterium sortiert, welches zufällig gewählt wird. Es gibt verschiedene Kriterien, nach denen gewählt werden kann. Die implementierten Kriterien wurden als Klassen erstellt und sind somit sehr leicht austausch- und erweiterbar. Die bisher erstellten Kriterien sind: EDD (EarliestDueDate) SJF (ShortestJobFirst) LJF (LongestJobFirst) FTL (FewestTimeLeft in ApplicationJob) ESF (EarliestStartFirst) MSF (MostSuccessorsFirst) (Von GRASP werden SJF, MSF, ESF und mit dreifacher Gewichtung FTL verwendet. Diese Konstellation ergab bei heuristischen Planungen gute bis sehr gute Ergebnisse.) Besonderheiten: Das α wird in dieser Implementierung fest durch einen Parameter übergeben und ändert sich danach für diesen GRASP-Lauf nicht mehr. Möglicherweise kann eine dynamische Anpassung des Wertes während der Durchführung der GRASP-Iterationen eine Verbesserung der Ergebnisse liefern. Es ist wahrscheinlich, dass ein bestimmter α- Wert für bestimmte Probleme besser als für andere Probleme arbeitet. Eigentlich bauen die verschiedenen Iterationen nicht auf einander auf, so dass diese parallel auf mehreren Prozessoren gestartet werden können. Da nur der Vergleich mit der aktuell besten Lösung synchronisiert werden muss, können die aufwendigeren Schritte (Schritt 2.a und 2.b) komplett auf dem jeweiligen Prozessor berechnet werden. In Binato et al. [24] wurde bereits ein linearer Geschwindigkeitszuwachs mit jedem weiteren Prozessor nachgewiesen. Zum Bewerten der Güte einer Lösung kommt eine Fitnessfunktion zum Einsatz. Diese Fitnessfunktion erlaubt eine Einschätzung zum Gesamtbild der Lösung, das heißt, es werden mehrere Ziele in dieser Funktion betrachtet. In der aktuellen Implementierung werden die Kosten, die Fertigstellungszeiten und die Verspätungen der Jobs für die Bewertung herangezogen. Zudem wird anhand von dem vom Benutzer vorgegebenen Verhältnis zwischen Kosten und Preis der jeweilige Wert skaliert, um dem Benutzerwunsch möglichst nachkommen zu können. Die Fitness wird nicht weiterverwendet und ist daher nur ein internes Mittel zur Einschätzung einer Lösung. Für jeden ApplicationJob, der geplant wurde, wird die Berechnung separat durchgeführt und am Ende alle Werte addiert. Um eine Addition der Werte zu 64

75 ermöglichen, werden alle Bewertungsmaßstäbe skaliert, so dass beispielsweise ein umfangreicherer ApplicationJob nicht mehr Wichtigkeit zugeschrieben bekommt, als ein weniger umfangreicher. Generell sind für GRASP verschiedene Algorithmen für die lokale Suche möglich. Für die Implementierung wurde die bereits erwähnte Methode mit den disjunktiven Graphen gewählt. Diese musste für GORBA abgeändert werden, so dass nicht nur der kritische Pfad, sondern die Fitness einer veränderten Lösung zum Vergleich mit der ursprünglichen Lösung herangezogen wird. Weiterhin kann ein Austausch zweier aufeinanderfolgender, sich nicht gegenseitig benötigender Gridjobs nicht ohne die Überprüfung der Zeitfenster auf der entsprechenden Ressource geschehen. Aus diesem Grund musste dementsprechend eine weitere Überprüfung stattfinden. Änderungen werden nur übernommen, wenn dies von der Ressource her ohne weitere Umplanungen möglich ist. Das Parallelisieren des Algorithmus ist in dieser Version der Implementierung noch nicht gegeben. Alle GRASP-Iterationen werden sequenziell abgearbeitet. Erste Überlegungen zur Parallelisierbarkeit beinhalteten sowohl das komplette Parallelisieren der einzelnen GRASP-Iterationen als auch das Parallelisieren von kleineren Teilen, wie beispielsweise Teilen der Bewertungsfunktion. Für parallele Abläufe können in Java Threads verwendet werden. Dabei ist zu beachten, dass die Synchronisation dieser Threads auch Rechenzeit verbraucht. Soll zudem eine Art Gedächtnis implementiert werden, ist die Synchronisation besonders wichtig, da auf vorher erstellte Lösungen oder andere Informationen zurückgegriffen werden müsste. Zudem kam die Frage auf, wie viele Threads pro wie vielen CPUs verwendet werden sollten. Theoretisch wäre ein Thread je Prozessor naheliegend, dies muss aber nicht zwangsläufig gute Ergebnisse liefern, wenn die Threads so synchronisiert sind, dass nach der Bearbeitung einer GRASP-Iteration auf die anderen Threads gewartet werden muss (zum Beispiel zum Abgleich der Ergebnisse). Schneller als eine nicht parallelisierte Lösung sollte es sein, wenn wirklich nur die GRASP-Iterationen gemacht werden und keine weiteren Überprüfungen gemacht werden müssen. Generell wird in jeder Iteration erst mal eine komplett neue Lösung erstellt, bisherige Ergebnisse werden dabei nicht mit einbezogen. Allerdings gibt es Bestrebungen, vorangegangene Ergebnisse in neuen Iterationen zu benutzen. Dies kann beispielsweise mit einem veränderbaren (Pitsoulis [23]) oder selbstanpassendem (Prais [40]) α-wert gesehen. Zudem ist die Idee entstanden, die Initiallösungen in einer Hash- Tabelle zu speichern, um so doppelte Lösungen ausschließen zu können. 65

76 4.3 Softwaretests Dieser Abschnitt zeigt, welche Tests zur Sicherstellung der Fehlerfreiheit durchgeführt worden. Zunächst sei hier erwähnt, dass kein Test eine 100%ige Fehlerfreiheit gewährleisten kann. Trotzdem soll versucht werden, möglichst fehlerfreie Komponenten für GORBA zu entwickeln. Um dies zu ermöglichen, sind verschiedene Tests mit möglichst hoher Testabdeckung notwendig. Dies soll durch das Durchlaufen mehrerer Teststufen sichergestellt werden. Diese Stufen werden in den folgenden Abschnitten erläutert Komponententest Unit Tests Die erste Stufe der Tests sind die vom Entwickler geschriebenen Komponententests. Sie werden geschrieben, um einzelne Teile der Software auf ihre korrekte Funktionsweise hin zu überprüfen. Diese Tests können vor oder nach der Implementierung des eigentlichen Programmcodes geschrieben werden. Sie eignen sich sehr gut zum Testen von Grenzfällen oder Grenzüberschreitungen, die beispielsweise bei Benutzereingaben auftreten, aber auch für Anwendungsfälle, wo eine Variable den Wert null annimmt. Für Java liegen die Unit Tests als JUnit (http://www.junit.org) vor. Das Prinzip ist, dass ein vorher bekanntes oder gewünschtes Ergebnis in einem dafür parametrisiertem Testlauf erreicht werden soll. Solange das gewünschte Ergebnis nicht eintritt, ist etwas an der Software fehlerhaft. Tests, die hier durchgeführt wurden, sind zum Beispiel solche, die das Verändern oder Erstellen von Objekten von Klassen betreffen. Dafür wurden Klassen zum Beispiel mit üblichen Werten, aber auch mit Grenzwerten initialisiert. Dies soll sicherstellen, dass, egal welche Eingabe ein Benutzer oder ein Programm macht, sinnvolle Werte erstellt werden, oder gegebenenfalls ein aussagekräftiger Hinweis ausgegeben werden kann. Zum Verändern von Objekten gehören auch Berechnungen, welch an den Objekten durchgeführt werden müssen. Die JUnit-Tests gehören hier zu den sogenannten White-Box-Tests, da Kenntnis über den Quellcode vorhanden ist. Diese Tests bildeten den Großteil der Softwaretests. Sie wurden stets zeitnah zur eigentlichen Programmierung durchgeführt Integrationstests Dies sind Tests, welche das Zusammenspiel der Komponenten untereinander, aber auch mit GORBA untersuchen sollen. Da die Algorithmen möglichst stark gekapselt wurden, beläuft sich die Zusammenarbeit mit GORBA auf das Starten des Algorithmus durch die GORBA-Oberfläche, die Übergabe der GORBA-Parameter an den Algorithmus, und das Zurückschreiben der Planungsergebnisse vom Algorithmus in GORBA. Diese Zusammenarbeit wurde getestet, indem möglichst viele verschiedene Kombinationen aus Ressourcen und Applicationjobs mit den Algorithmen geplant wurden und im 66

77 laufenden GORBA überprüft wurde, ob es dabei zu Fehlermeldungen kommt. Die Kommunikation innerhalb der Heuristik-Komponenten wurde bereits teilweise durch die UnitTests abgedeckt. Die Integrationstests ähneln dem Abnahmetest im nächsten Abschnitt, sind allerdings bezüglich der Heuristik-Komponenten White-Box-Tests, da sie vom Programmierer selber durchgeführt wurden Abnahmetest Black-Box-Tests Die Black-Box-Tests bezeichnen den Test von Software ohne Kenntnisse des Programmcodes. Hier wird das Verhalten der Software getestet, wenn der Benutzer beliebige Eingaben machen kann. Das System muss eine ausreichende Fehlerakzeptanz besitzen und falsche Benutzereingaben abfangen können. Um dies zu gewährleisten, müssen diese Tests von Benutzern durchgeführt werden, welche nicht an der Programmierung beteiligt waren. Hierbei ist wichtig zu bemerken, dass durch die Integration in ein weiteres System (GORBA) auch durchaus Fehler auftreten können, die nichts mit dem jeweiligen Algorithmus zu tun haben. Beispielsweise kann es vorkommen, dass Dateien nicht geladen werden können, wenn GORBA nicht auf Linux, sondern auf Windows ausgeführt wird. Dies wurde beispielsweise getestet, wobei der Test aber fehlschlug, da GORBA Linux-Kommandozeilentools aufruft, welche auf Windows nicht vorhanden sind. Da eine Verwendung auf Windows-Systemen zumindest in Zukunft nicht vorgesehen ist, ist diese Erkenntnis nicht ausschlaggebend und an GORBA musste nicht zwingend etwas geändert werden. Es wurde allerdings eine Abfrage in GORBA eingebaut, so dass GORBA erkennt, ob es auf Windows oder einem sonstigen Betriebssystem ausgeführt wird, so dass der Dateiseparator (auf Windows \ und auf Unix-Systemen / ) entsprechend angepasst wird. Weitere Fehler, die nicht durch die Heuristiken bedingt sind, sind zum Beispiel Netzwerkausfälle beim Laden von Dateien. Da die Implementierung von GORBA nicht vom Programmierer selbst vorgenommen wurde, sondern an dieser nur Änderungen möglich waren, konnten Teile dieser Tests vom Programmierer selber durchgeführt werden, da keine direkte Kenntnis über die Implementierung jeder GORBA-Klasse vorhanden war Tests zur Parameterfindung Zusätzlich zu den Tests zur Sicherung der Qualität mussten geeignete Parameter (für GRASP und Tabu-Suche) für die konventionelle Planung gefunden werden. Dafür wurden mit der GORBA-internen Funktion zum Speichern von Macros kleinere Benchmark-Szenarien mit bis zu ca. 30 Gridjobs aufgebaut. Diese Szenarien wurden dann von GRASP und Tabu-Suche unter Verwendung verschiedener Parameter bearbeitet. Die Ergebnisse konnten mithilfe der GLEAM-Bewertungskomponente eingeschätzt werden. Die im Durschnitt jeweils beste Parameterkonstellation wurde für die anschließenden Benchmarks als Ausgangsparametrisierung verwendet. Dabei gilt zu beachten, dass es nicht möglich war, jede mögliche Konstellation zu testen. Es 67

78 konnten aber anhand von Tendenzen gute Parameter gewählt werden. Die Parameter werden in Abschnitt 5.1 beschrieben. 68

79 Kapitel 5 Benchmark-Tests Hier werden die Benchmark-Tests und deren Ergebnisse vorgestellt, die zur Bewertung der neu implementierten Algorithmen/Heuristiken dienen sollen. Dafür wird nach einer Beschreibung der GORBA-Bewertung auf die Parametrisierung der Algorithmen eingegangen. Danach folgt eine Vorabeinschätzung aufgrund der reinen GORBA- Ergebnisse. Diese Ergebnisse wurden noch nicht mit GLEAM optimiert und lassen daher wahrscheinlich keine 100%igen Schlüsse hinsichtlich der Verwendung als Ausgangspopulation für GLEAM zu, sind aber sicherlich hilfreich für eine erste Einschätzung sowie für eine Bewertung hinsichtlich der Verwendung für die konventionelle Planung von GORBA. Danach wird die Testumgebung vorgestellt und die Einstellungen und Kommandos gezeigt, mit denen die Testläufe durchgeführt werden. Dies soll nachfolgenden Arbeiten eine bessere Möglichkeit geben, die Vorgänge nachzuvollziehen. Schließlich folgt eine Auswertung anhand der ermittelten GLEAM-Ergebnisdaten. 5.1 Parametrisierung der Algorithmen Es ist möglich (und notwendig), die Algorithmen zu parametrisieren, da auch davon deren Erfolg abhängt. Die Parameter wurden in Tests parallel zur Implementierung durchgeführt. Dabei ist zu beachten, dass nicht jede mögliche Konfiguration getestet werden konnte. Die besten getesteten Parameter wurden anhand mehrerer Testläufe gewählt und sollen nun vorgestellt werden: GRASP: Größe der RCL: 10 Alpha: 0.4 (40%) Maximale Anzahl an Iterationen: 500 Zeitbegrenzung: keine* Regeln zur Wahl der Gridjobs aus der RCL**: o 1x SJF (ShortestJobFirst) o 1x MSF (MostSuccessorsFirst) o 1x ESF (EarliestStartFirst) o 3x FTL (FewestTimeLeft) Regel zur Wahl der Ressourcen: o EarliestCheapest * Eine zeitliche Begrenzung bot sich nicht an, da die konventionellen Planungen auf dem Entwicklungsrechner ausgeführt wurden und dort starke Schwankungen bezüglich der Ausführungszeit vorkamen (es stand nicht für jede Planung ein eigener Prozessor zur Verfügung). 69

80 ** Eine dieser Regeln wird zufällig bei jedem Schritt der Abarbeitung der RCL gewählt. Tabu-Suche: Größe der Tabu-Liste: 20 Durchläufe ohne Verbesserungen: 15 Individuen je Durchlauf: 10 Minimale Chance auf Übernahme von Änderungen: 80% Maximal zu ändernde Gridjob-Regeln je Schritt: 65%* Maximal zu ändernde Ressourcen-Regeln je Schritt: 30%* Regeln zur Wahl der Gridjobs aus der RCL: o 1x SJF (ShortestJobFirst) o 1x MSF (MostSuccessorsFirst) o 1x ESF (EarliestStartFirst) o 3x FTL (FewestTimeLeft) Regel zur Wahl der Ressourcen: o EarliestStart o EarliestEnd o MostTimeLeft o EarliestCheapest * Diese Werte scheinen auf den ersten Blick sehr hoch, werden jedoch dadurch relativiert, dass Regeländerungen oft (durch wenige Ressourcen- bzw. Gridjob- Alternativen) keine oder nur sehr geringe Auswirkung auf die Fitness einer Lösung haben. Weiterhin werden diese Änderungen nicht mit 100%iger Wahrscheinlichkeit übernommen. List-Scheduling: List-Scheduling kann nur hinsichtlich der Prioritätsregel parametrisiert werden, mit der Ressourcen ausgewählt werden. Ansonsten gibt es keine Möglichkeiten der Parametrisierung. Es wurden folgende Prioritätsregeln angewendet: EarliestEnd EarliestStart EarliestCheapest MostTimeLeft EarliestCheapest OR CheapestEarliest 70

81 Shifting Bottleneck: Wie beim List-Scheduling gibt es keine Parametrisierungsmöglichkeiten, abgesehen von den Prioritätsregeln. Folgende Regeln wurden benutzt: EarliestEnd EarliestStart EarliestCheapest MostTimeLeft EarliestCheapest OR CheapestEarliest 5.2 Ergebnisse der konventionellen Planung Die vier implementierten Algorithmen besitzen nach ersten Einschätzungen unterschiedliches Potential. Diese Einschätzungen weichen zum Teil stark von denen aus der Recherche ab. Die Ursache dafür liegt beim GORBA-Problem. Durch dessen Komplexität ist eine 1-zu-1 Umsetzung der Algorithmen nicht möglich. Auf der anderen Seite wird von manchen Algorithmen für deren Erfolg eine gewisse Art des JSSP vorausgesetzt. Bei komplexeren Aufgaben arbeiten sie nicht mehr gut genug, um sinnvoll für eine konventionelle Planung eingesetzt zu werden (die Ergebnisse aus dieser waren laut Bewertung zu schlecht). Dies macht spezielle Algorithmen für spezielle Aufgaben vorteilhaft, für andere Aufgaben jedoch schlecht verwendbar. Das Problem ist, dass die Algorithmen meist auf eine spezielle oder signifikant einfachere Aufgabenstellung zugeschnitten sind, aber bei schwierigeren Aufgaben eben diesen Vorteil des genauen Zuschnitts verlieren. Die größten Hoffnungen wurden trotz relativ hoher Schwankungen bei der Bewertung auf die Tabu-Suche gesetzt. Die konventionelle Planung der Tabu-Suche dauert zwar im Durchschnitt am längsten (dies ist variabel, da das Abbruchkriterium nicht fest gesetzt ist), bietet aber zusammen mit GRASP unter den neuen Algorithmen die besten Ergebnisse der konventionellen Planung, auch wenn GRASP hinter den ersten Erwartungen zurückbleibt. Dies kann an einer falschen Parametrisierung liegen, allerdings wurden die nach mehreren Testläufen während der Implementierung als am Besten befundenen Parameter verwendet. Eine noch frühere Version der Tabu-Suche, welche allerdings sehr langsam war, konnte bei bestimmten Benchmark-Größen stets das beste Ergebnis aller bestehenden einfachen Heuristiken liefern. Durch die Langsamkeit war diese Version allerdings nicht konkurrenzfähig und wurde zugunsten einer schnelleren Lösung verworfen. Auch GRASP gelingt das beste Ergebnis bei ausreichend vielen Durchgängen. Da dies aber im Verhältnis zu den bereits vorhandenen Heuristiken zu viel Zeit in Anspruch nimmt, wird dies nicht weiter betrachtet. Bei Tests während der Implementierung wurde erkannt, dass GRASP vor 71

82 allem bei kleinen Problemen mit wenigen (~30) Gridjobs sehr gute Ergebnisse liefert, welche ca Punkte unter den jeweiligen Ergebnissen von GLEAM liegen. Um diese Aussage zu bestätigen, wurden verschiedene kleine Benchmarks als Macro anhand vorhandener Ressourcenbeschreibungen und vorhandener Applicationjobs erstellt, mehrfach ausgeführt und die Ergebnisse der konventionellen Planung anschließend mit der GORBA-internen GLEAM-Planung verbessert. Durch Hinzufügen weiterer Prioritätsregeln für Gridjobs (beschrieben in Abschnitt 0) konnten bei GRASP und der Tabu-Suche die Ergebnisse deutlich verbessert werden. Dies wurde anhand kleinerer Benchmark-Szenarien erprobt. Für diese Test-Szenarien ergeben sich sehr häufig ebenbürtige oder bessere Ergebnisse wie mit bisherigen Heuristiken. Die Vorplanungen werden in GORBA mit Benchmark-Dateien durchgeführt, welche sich in folgende Klassen unterteilen lassen: Große Ressourcenwahl, große Abhängigkeiten (gg) Große Ressourcenwahl, kleine Abhängigkeiten (gk) Kleine Ressourcenwahl, große Abhängigkeiten (gg) Kleine Ressourcenwahl, kleine Abhängigkeiten (kk) Eine weitere Unterteilung beschreibt die Anzahl der Gridjobs. Das heißt, es gibt beispielsweise gg100, was für 100 Gridjobs steht bei entsprechender Benchmark- Klasse steht. Die alten Heuristiken, List Scheduling und Shifting Bottleneck sind deterministisch. Für beide gibt es verschiedene Selektierungsregeln für Gridjobs, sogenannte Prioritätsregeln. Mit jeder dieser Regeln wurde eine Planung durchgeführt und das jeweils beste Ergebnis in die Tabelle übernommen. Bei den herkömmlichen Heuristiken wurde ebenso vorgegangen. Die Ergebnisse von GRASP und Tabu-Suche unterliegen jedoch aufgrund von Zufallskomponeten Schwankungen (siehe Abschnitt und 4.2.9für Details). Deshalb wurden bei diesen Heuristiken jeweils 100 konventionelle Planungen durchgeführt und daraus der Mittelwert, die Standard-Abweichung und die Konfidenzintervalle für 95% und 99% berechnet. Der als Ausgang für die GLEAM-Läufe verwendete Schedule wurde so gewählt, dass er mit seiner Bewertung im Bereich x ± KI95 liegt (wobei KI95 = Konfidenzintervall 95% ist). Die zusammengefassten Ergebnisse aus diesen Planungen sind in Tabelle 21 und Tabelle 22 sichtbar. Es werden außerdem minimale und maximale Werte mit angegeben. 72

83 Tabelle 21: Ergebnisse aus 100 GORBA-Planungen (GRASP) Mittelwert Std.-Abw. Konf.-Int (95) Konf.-Int (99) Min Max gg ,69 508,47 99,66 130,97 729, ,60 gg ,37 102,97 20,18 26,52 311,00 783,20 gg200d 2.923,50 854,54 167,49 220, , ,90 gk ,01 229,16 44,91 59,03 311, ,30 gk ,73 47,71 9,35 12,29 56,00 330,80 gk200d 608,42 135,00 26,46 34,77 377, ,30 kg , ,65 636,53 836, , ,20 kg ,08 511,72 100,29 131, , ,40 kg200d , ,98 564,66 742, , ,70 kk ,27 452,01 88,59 116,43 497, ,50 kk ,09 107,70 21,11 27,74 81,60 671,90 kk200d 1.226,85 303,65 59,51 78,21 653, ,70 Tabelle 22: Ergebnisse aus 100 GORBA-Planungen (Tabu-Suche) Mittelwert Std.-Abw. Konf.-Int (95) Konf.-Int (99) Min Max gg ,96 941,00 184,43 242, , ,20 gg ,39 872,97 171,10 224, , ,10 gg200d 5.500, ,59 378,58 497, , ,90 gk , ,71 542,85 713, , ,50 gk , ,64 210,23 276, , ,00 gk200d 5.915, ,72 261,41 343, , ,50 kg , , , , , ,50 kg , ,33 340,71 447, , ,00 kg200d , ,84 513,67 675, , ,20 kk , ,39 661,17 868, , ,60 kk , ,42 204,90 269, , ,00 kk200d 7.433, ,63 280,40 368, , ,10 Es folgt eine Übersicht in Tabelle 23, welche die Endergebnisse aus den konventionellen Planungen (nach Bewertung durch die Bewertungskomponente) zeigt. Rote Zahlen stellen jeweils den besten Wert dar. Aus dieser Tabelle lassen sich Vermutungen anstellen, welcher Algorithmus sich am besten für das jeweilige Benchmark-Scenario eignet. 73

84 Tabelle 23: Endergebnisse aus den konventionellen Planungen Beste alte Heuristik GRASP (x ± KI95) Tabu-Suche (x ± KI95) Bestes List Scheduling Bestes Shifting Bottleneck gg , , ,4 57,1 153,6 gg ,0 528, ,4 15,7 86,5 gg200d , , ,5 234,6 832,4 gk ,3 656, ,6 62,6 121,2 gk ,7 150, ,0 4,4 24,0 gk200d ,8 618, ,9 76,6 179,4 kg , , ,7 286,1 664,9 kg , , ,2 62,1 580,1 kg200d , , ,6 557, ,5 kk , , ,7 110,0 182,6 kk ,3 303, ,1 22,4 52,8 kk200d , , ,5 249,4 326,8 Bei den meisten Problemklassen liegen die neuen Algorithmen hinter der besten bisherigen Heuristiken zurück. Von letzteren ist allerdings nur die Heuristik shortestduetime mit allen drei Ressourcenallokationsstrategien (siehe Jakob et al. [15]) stets erfolgreich. Die Details dazu sind in Anhang A zu finden. Von den neuen Algorithmen zeigen vor allem List Scheduling und Shifting Bottlneck sehr niedrige Werte. Diese sind vergleichbar mit den schlechteren bereits vorhandenen. Weiterhin ist zu bemerken, dass die Tabu-Suche im Mittel immer bessere Ergebnisse liefert, als GRASP. Trotzdem bleiben beide Algorithmen meist hinter der Heuristik sortestduetime zurück. Für diese Einschätzungen wurden Bewertungen herangezogen, die durch die Bewertungskomponente von GLEAM geliefert wurden. Es wurde auch zu Testzwecken mit kleineren Benchmark-Szenarien gearbeitet, bei denen GRASP und die Tabu-Suche sehr häufig ebenbürtige oder bessere Ergebnisse brachten, wie die bisherigen Heuristiken. Der Umfang und die Komplexität der GLEAM- Benchmarks sind anscheinend zu hoch für die neuen Algorithmen. Die Ergebnisse, die bei der heuristischen Planung entstehen, werden in einer jeweils 3- minütigen Optimierungsphase von GLEAM verbessert. Wegen der begrenzten Zeit ist es wahrscheinlich, dass höherwertige Startlösungen auch für GLEAM vorteilhaft sind. Dabei ist anzumerken, dass bereits durch kleinere Änderungen einer Lösung (zum Beispiel Austauschen von zwei Gridjobs) eine höherwertige Lösung entstehen kann (höherwertig bezüglich der Bewertung der GLEAM-Bewertungskomponente). Durch vorangegangene Studien wurde bereits festgestellt, dass die GLEAM-Optimierung äußerst stark ist und es wurde die Vermutung angestellt, dass somit die Ausgangslösung nur geringen Einfluss auf das Endergebnis hat. 74

85 Um dies letztendlich nachzuweisen, wird eine Testumgebung aufgebaut, in der die GLEAM-Läufe durchgeführt und deren Ergebnisse analysiert werden können. 5.3 Benchmark-Umgebung für die GLEAM-Läufe Im Ordner /projects/grid/gorba/optplanwork/bm_heuri wurde die Benchmark- Umgebung eingerichtet. Im Unterordner BM1 befinden sich weitere Ordner, welche für verschiedene Benchmark-Szenarien stehen. Es gibt folgende Ordner, welche den Benchmark-Klassen entsprechen: gr_ga (große Ressourcenwahl, große Abhängigkeiten) gr_ka (große Ressourcenwahl, kleine Abhängigkeiten) kr_ga (kleine Ressourcenwahl, große Abhängigkeiten) kr_ka (kleine Ressourcenwahl, kleine Abhängigkeiten) Jeder dieser Ordner unterteilt sich weiter in die Benchmark-Szenarien für jeweils 50, 100 und 200 Gridjobs. Ein weiteres Benchmark-Szenario ist 200d, welches 200 Gridjobs und doppelte Ressourcen bedeutet. Diese Ordner enthalten die Job-Daten, die in GORBA eingelesen und mit der konventionellen Planung vorgeplant werden sollen. Sobald eine konventionelle Planung in GORBA durchgeführt wird, werden Dateien erzeugt, welche die Ergebnisse und Bewertungen dieser Planung enthalten. Zunächst müssen Ergebnisse mit den vorhandenen Heuristiken erstellt werden, damit die neuen Heuristiken mit diesen verglichen werden können. Zwar existieren alte Ergebnisse mit den gleichen Benchmarks, diese wurden allerdings auf Rechnern erstellt, welche nicht mehr zur Verfügung stehen, bzw. nicht für die aktuellen Benchmark-Läufe verwendet werden sollen. Die aktuellen Rechner sind schneller, so dass Ergebnisse der alten Benchmarks zumindest teilweise neu erstellt werden müssen, um am Ende die Werte brauchbar vergleichen zu können. Die für die GLEAM-Läufe zur Verfügung stehenden Rechner sind iai-grid1 bis iai-grid4. Sie besitzen jeweils 8 CPUs. Da GLEAM nicht deterministisch ist, müssen mehrere Läufe durchgeführt werden, um statistisch sicherstellen zu können, dass es sich um ein korrektes Ergebnis handelt. Es wurden jeweils 100 Läufe durchgeführt. Die GLEAM-Läufe werden folgendermaßen durchgeführt: 1. Erstellen der Ergebnisse der konventionellen Planung mit GORBA a. Laden der Benchmark-Makrodatei (enthält Ressourcen und ApplicationJobs) b. Aktivieren der gewünschten Planungsheuristiken c. Durchführen der Planung (Funktion K-Plan Jobs in GORBA) 75

86 2. Erstellte Ergebnisse in den jeweiligen Ordner verschieben (der Ordner, aus dem die Benchmark-Makrodatei kommt) gorba_kp.log joblist_gorba_gkomb2.mod joblist_gorba_g.mod joblist_gorba.xml 3. Einloggen auf einem der Rechner iai-grid1 bis iai-grid4 per ssh: a. $> ssh p24 iai-grid1 4. In den Ordner mit den erstellten Ergebnissen navigieren, zum Beispiel: a. $> cd /projects/grid/gorba/optplanwork/bm_heuri/ BM1/gR_gA/BM1_gR_gA_ GLEAM-Läufe starten, wenn noch CPUs frei sind, wobei eine CPU für Systemaufgaben reserviert ist, es sollte also eine der 8 CPUs frei bleiben a. Nachsehen, ob CPUs frei sind, mit Linux-Befehl top b. $> source../../../job_ii.scr 46 PRÄFIX POP LÄUFE PRÄFIX ist der Präfix für die zu erstellende Logdatei POP ist die Populationsgröße LÄUFE ist die Anzahl der GLEAM-Läufe mit dieser Parametrisierung 6. Wenn die GLEAM-Läufe fertig sind, Auswertungsmaster aufrufen, muss als Ergebnis normal beendet liefern: a. $> ausw_master_allg LOGFILENAME BEST G+ D+ RECHNERNAME LOGFILENAME ist der Logfile-Name bis inklusive p BEST ist die beste Endnote, welche in gorba_kp.log zu finden ist G+ D+ sagt an, dass Gorba für die Planung verwendet wurde und dass zusätzlich zu erg-dateien auch noch dat-dateien erzeugt werden sollen, welche beispielsweise t-tests ermöglichen. RECHNERNAME ist rein informativ, um nach der Auswertung mögliche Fehler eines Rechners feststellen zu können 7. Wichtige Zeilen aus den Ergebnissen zusammenfassen in einer neuen Datei: a. $> cat LOGFILENAME*.erg tee NEUE_DATEI fgrep nisz LOGFILENAME ist der Logfile-Name bis inklusive p, das die Populationsgröße einleitet NEUE_DATEI ist ein beliebiger neuer Dateiname 8. Die Ausgabe sowie den Inhalt der neuen Datei in einer zusammenfassenden Datei speichern, damit ein Überblick möglich ist 76

87 a. Aus dem Überblick Ergebnisse ablesen und Diagramme erstellen b. Falls ersichtlich ist, dass weitere GLEAM-Läufe notwendig sind (zum Beispiel weil ein Ergebnis noch nicht eindeutig ist), diese Läufe durchführen. Für die neu entwickelten Heuristiken GRASP und Tabu-Suche müssen bereits im ersten Schritt mehrere Läufe durchgeführt werden, da durch die Zufallskomponenten jeder Lauf andere Ergebnisse erzeugen kann. 5.4 Ergebnisse der GLEAM-Läufe In diesem Abschnitt werden Ergebnisse der Benchmark-Läufe anhand von Diagrammen dargestellt. Für jedes Szenario wurden mit jedem Algorithmus 100 Läufe für verschiedene Populationsgrößen durchgeführt. Die Besonderheit bei den Benchmarks war, dass die Ergebnisse der neuen Heuristiken nicht einzeln, sondern jeweils in Verbindung mit den alten Heuristiken in die GLEAM-Optimierung gegeben worden. Der Grund dafür ist, dass bei älterer Hardware die alten Heuristiken keine 100%ige Erfolgsrate hatten. Die Hoffnung war, dass sich die Erfolgsraten durch Hinzunehmen jeweils einer neuen Heuristik verbessern. Allerdings wurden die Benchmarks auf neuer Hardware durchgeführt, so dass Verbesserungen nicht sehr gut ersichtlich werden. Wie zu erkennen ist, gibt es zwischen den verschiedenen Verfahren nur geringe Unterschiede. Fast in jedem Szenario erreicht jeder Algorithmus die vollständige Erfolgsrate, welche jeweils durch die Skala auf der linken Seite angezeigt wird. 100 entspricht einer Erfolgsrate bei der GLEAM-Optimierung von 100%. Jeder der 100 Läufe war dann erfolgreich optimiert worden. Werden die 100% nicht erreicht, so steht der erreichte Wert über der jeweiligen Säule. Weiße Säulen mit rotem Rand zeigen einen unsicheren Wert (die Benchmarks wurden mit verschiedenen Populationsgrößen durchgeführt, aber nur bei einer dieser Populationsgrößen konnten 100% erreicht werden). 77

88 All gg gk kg kk kg kk d gg gk Abbildung 9: GLEAM-Ergebnisse für die alten Heuristiken List Scheduling gg gk kg kk kg kk d gg gk Abbildung 10: GLEAM-Ergebnisse für List Scheduling 78

Approximationsalgorithmen

Approximationsalgorithmen Ausarbeitung zum Thema Approximationsalgorithmen im Rahmen des Fachseminars 24. Juli 2009 Robert Bahmann robert.bahmann@gmail.com FH Wiesbaden Erstellt von: Robert Bahmann Zuletzt berarbeitet von: Robert

Mehr

Heuristiken im Kontext von Scheduling

Heuristiken im Kontext von Scheduling Heuristiken im Kontext von Scheduling Expertenvortrag CoMa SS 09 CoMa SS 09 1/35 Übersicht Motivation Makespan Scheduling Lokale Suche Weitere Metaheuristiken Zusammenfassung Literatur CoMa SS 09 2/35

Mehr

Seminar zur BWL im Wintersemester 2015 / 2016. Maschinenbelegungsplanung in der betrieblichen Fertigung

Seminar zur BWL im Wintersemester 2015 / 2016. Maschinenbelegungsplanung in der betrieblichen Fertigung Institut für Wirtschaftswissenschaft Abteilung für BWL und Unternehmensforschung Prof. Dr. Jürgen Zimmermann (juergen.zimmermann@tu-clausthal.de) Stefan Kreter, M. Sc. (stefan.kreter@tu-clausthal.de) Julius-Albert-Str.

Mehr

Echtzeitfähige Ereignisgetriebene Scheduling-Strategien

Echtzeitfähige Ereignisgetriebene Scheduling-Strategien Friedrich-Alexander-Universität Erlangen-Nürnberg Ausgewählte Kapitel eingebetteter Systeme Echtzeitfähige Ereignisgetriebene Scheduling-Strategien Sven Kerschbaum 1. Einführung Bei einem eingebetteten

Mehr

Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests. Masterarbeit

Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests. Masterarbeit Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests Masterarbeit zur Erlangung des akademischen Grades Master of Science (M.Sc.) im Masterstudiengang Wirtschaftswissenschaft

Mehr

Approximationsalgorithmen: Klassiker I. Kombinatorische Optimierung Absolute Gütegarantie Graph-Coloring Clique Relative Gütegarantie Scheduling

Approximationsalgorithmen: Klassiker I. Kombinatorische Optimierung Absolute Gütegarantie Graph-Coloring Clique Relative Gütegarantie Scheduling Approximationsalgorithmen: Klassiker I Kombinatorische Optimierung Absolute Gütegarantie Graph-Coloring Clique Relative Gütegarantie Scheduling VO Approximationsalgorithmen WiSe 2011/12 Markus Chimani

Mehr

Studienarbeit. Integration eines Giffler-Thompson-Schedulers in GORBA

Studienarbeit. Integration eines Giffler-Thompson-Schedulers in GORBA Studienarbeit Integration eines Giffler-Thompson-Schedulers in GORBA Daniel Sonnleithner Projektleiter: Dr. Karl-Uwe Stucky Studienarbeit Aufgabenstellung für Herrn cand.mech. Daniel Sonnleithner Matrikel-Nr.:

Mehr

No-wait Job-Shop-Scheduling:

No-wait Job-Shop-Scheduling: No-wait Job-Shop-Scheduling: Komplexität und Local Search Der Fakultät für Naturwissenschaften der Universität Duisburg-Essen (Standort Duisburg) zur Erlangung des akademischen Grades eines Doktors der

Mehr

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 374

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 374 DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN Nr. 374 Eignung von Verfahren der Mustererkennung im Process Mining Sabrina Kohne

Mehr

4 Greedy-Algorithmen (gierige Algorithmen)

4 Greedy-Algorithmen (gierige Algorithmen) Greedy-Algorithmen (gierige Algorithmen) Greedy-Algorithmen werden oft für die exakte oder approximative Lösung von Optimierungsproblemen verwendet. Typischerweise konstruiert ein Greedy-Algorithmus eine

Mehr

Das Lastverteilungsproblem

Das Lastverteilungsproblem Das Lastverteilungsproblem Approximationsalgorithmen Referent Franz Brauße Veranstaltung Proseminar Theoretische Informatik Universität Trier, FB IV Dozent Prof. Dr. Henning Fernau 23.02.2012 Übersicht

Mehr

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit IT-basierte Erstellung von Nachhaltigkeitsberichten Diplomarbeit zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen Fakultät der Leibniz Universität Hannover vorgelegt von

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

Grid Computing. Einführung. Marc Lechtenfeld. Seminar Grid Computing Sommersemester 2004 Universität Duisburg-Essen

Grid Computing. Einführung. Marc Lechtenfeld. Seminar Grid Computing Sommersemester 2004 Universität Duisburg-Essen * Grid Computing Einführung Marc Lechtenfeld Seminar Grid Computing Sommersemester 2004 Universität Duisburg-Essen Übersicht 1 Problematik 2 Systemanforderungen 3 Architektur 4 Implementation 5 Projekte

Mehr

Prozesse und Scheduling

Prozesse und Scheduling Betriebssysteme für Wirtschaftsinformatiker SS04 KLAUSUR Vorbereitung mit Lösungen / Blatt 1 Prozesse und Scheduling Aufgabe 1 : Scheduling Gegeben seien die folgenden Prozesse und die Längen des jeweiligen

Mehr

Befragung und empirische Einschätzung der Praxisrelevanz

Befragung und empirische Einschätzung der Praxisrelevanz Befragung und empirische Einschätzung der Praxisrelevanz eines Vorgehensmodells zur Auswahl von CRM-Systemen D I P L O M A R B E I T zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

Hochflexibles Workforce Management: Herausforderungen und Lösungsverfahren

Hochflexibles Workforce Management: Herausforderungen und Lösungsverfahren Hochflexibles Workforce Management: Herausforderungen und Lösungsverfahren Dissertation zur Erlangung des akademischen Gerades eines Doktors der Wirtschaftswissenschaften ( Doctor rerum politicarum") an

Mehr

3. Entscheidungsbäume. Verfahren zum Begriffslernen (Klassifikation) Beispiel: weiteres Beispiel: (aus Böhm 2003) (aus Morik 2002)

3. Entscheidungsbäume. Verfahren zum Begriffslernen (Klassifikation) Beispiel: weiteres Beispiel: (aus Böhm 2003) (aus Morik 2002) 3. Entscheidungsbäume Verfahren zum Begriffslernen (Klassifikation) Beispiel: weiteres Beispiel: (aus Böhm 2003) (aus Morik 2002) (aus Wilhelm 2001) Beispiel: (aus Böhm 2003) Wann sind Entscheidungsbäume

Mehr

Schnelles Rescheduling von Gridjobs mit Heuristiken und dem Evolutionären Algorithmus GLEAM

Schnelles Rescheduling von Gridjobs mit Heuristiken und dem Evolutionären Algorithmus GLEAM Schnelles Rescheduling von Gridjobs mit Heuristiken und dem Evolutionären Algorithmus GLEAM Wilfried Jakob, Alexander Quinte, Karl-Uwe Stucky, Wolfgang Süß Forschungszentrum Karlsruhe GmbH Institut für

Mehr

OPERATIONS-RESEARCH (OR)

OPERATIONS-RESEARCH (OR) OPERATIONS-RESEARCH (OR) Man versteht darunter die Anwendung mathematischer Methoden und Modelle zur Vorbereitung optimaler Entscheidungen bei einem Unternehmen. Andere deutsche und englische Bezeichnungen:

Mehr

Approximation in Batch and Multiprocessor Scheduling

Approximation in Batch and Multiprocessor Scheduling Approximation in Batch and Multiprocessor Scheduling Tim Nonner IBM Research Albert-Ludwigs-Universität Freiburg 3. Dezember 2010 Scheduling Zeit als Ressource und Beschränkung Formaler Gegeben sind Jobs

Mehr

Antwortzeitverhalten von Online Storage Services im Vergleich

Antwortzeitverhalten von Online Storage Services im Vergleich EPOD Encrypted Private Online Disc Antwortzeitverhalten von Online Storage Services im Vergleich Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee

Mehr

Workflow Systeme mit der Windows Workflow Foundation

Workflow Systeme mit der Windows Workflow Foundation Studiengang Electronic Business (EB) Diplomarbeit (280000) Workflow Systeme mit der Windows Workflow Foundation externe Betreuung durch Christoph Müller vorgelegt bei Prof. Dr. Michael Gröschel von Hans-Martin

Mehr

Systeme 1. Kapitel 5. Scheduling

Systeme 1. Kapitel 5. Scheduling Systeme 1 Kapitel 5 Scheduling Scheduling Verteilung und Zuweisung von begrenzten Ressourcen an konkurrierende Prozesse Beispiel: -> Zeitablaufsteuerung Zwei Prozesse zur gleichen Zeit rechenbereit auf

Mehr

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching 1.1 Caching von Webanwendungen In den vergangenen Jahren hat sich das Webumfeld sehr verändert. Nicht nur eine zunehmend größere Zahl an Benutzern sondern auch die Anforderungen in Bezug auf dynamischere

Mehr

Perzentile mit Hadoop ermitteln

Perzentile mit Hadoop ermitteln Perzentile mit Hadoop ermitteln Ausgangspunkt Ziel dieses Projektes war, einen Hadoop Job zu entwickeln, der mit Hilfe gegebener Parameter Simulationen durchführt und aus den Ergebnissen die Perzentile

Mehr

Einführung in die Informatik I

Einführung in die Informatik I Einführung in die Informatik I Algorithmen und deren Programmierung Prof. Dr. Nikolaus Wulff Definition Algorithmus Ein Algorithmus ist eine präzise formulierte Handlungsanweisung zur Lösung einer gleichartigen

Mehr

Kürzeste Wege in Graphen. Maurice Duvigneau Otto-von-Guericke Universität Fakultät für Informatik

Kürzeste Wege in Graphen. Maurice Duvigneau Otto-von-Guericke Universität Fakultät für Informatik Kürzeste Wege in Graphen Maurice Duvigneau Otto-von-Guericke Universität Fakultät für Informatik Gliederung Einleitung Definitionen Algorithmus von Dijkstra Bellmann-Ford Algorithmus Floyd-Warshall Algorithmus

Mehr

Parallele und funktionale Programmierung Wintersemester 2013/14. 8. Übung Abgabe bis 20.12.2013, 16:00 Uhr

Parallele und funktionale Programmierung Wintersemester 2013/14. 8. Übung Abgabe bis 20.12.2013, 16:00 Uhr 8. Übung Abgabe bis 20.12.2013, 16:00 Uhr Aufgabe 8.1: Zeigerverdopplung Ermitteln Sie an folgendem Beispiel den Rang für jedes Listenelement sequentiell und mit dem in der Vorlesung vorgestellten parallelen

Mehr

Diskussion eines IT-Outsourcing unter Berücksichtigung von Compliance Anforderungen. Bachelorarbeit

Diskussion eines IT-Outsourcing unter Berücksichtigung von Compliance Anforderungen. Bachelorarbeit Diskussion eines IT-Outsourcing unter Berücksichtigung von Compliance Anforderungen Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftswissenschaft

Mehr

Teststrategie festlegen und Teststufen aufeinander abstimmen

Teststrategie festlegen und Teststufen aufeinander abstimmen Testen Teststrategie festlegen und Teststufen aufeinander abstimmen Bereich Projektplanung und -steuerung Aktivität Projekt planen Ziele Effiziente Testausführung Vermeidung von doppelter Arbeit schnell

Mehr

Instant Grid Stand August 2006

Instant Grid Stand August 2006 Instant Grid Stand August 2006 Instant Grid Stand August 2006 Projekttreffen 22/23.08.2006 Göttingen Andreas Hoheisel (andreas.hoheisel@first.fraunhofer.de) Helge Rosé (helge.rose@first.fraunhofer.de)

Mehr

Mustererkennung mit Baumautomaten

Mustererkennung mit Baumautomaten Mustererkennung mit Baumautomaten Eine Ausarbeitung von Gisse Alvarado für das Seminar Mustererkennung mit syntaktischen und graphbasierten Methoden bei Prof. Dr. W. Kurth/ Th. Mangoldt Cottbus 2006 Inhalt

Mehr

Binäre lineare Optimierung mit K*BMDs p.1/42

Binäre lineare Optimierung mit K*BMDs p.1/42 Binäre lineare Optimierung mit K*BMDs Ralf Wimmer wimmer@informatik.uni-freiburg.de Institut für Informatik Albert-Ludwigs-Universität Freiburg Binäre lineare Optimierung mit K*BMDs p.1/42 Grundlagen Binäre

Mehr

Schnelles Resource Constrained Project Scheduling mit dem Evolutionären Algorithmus GLEAM

Schnelles Resource Constrained Project Scheduling mit dem Evolutionären Algorithmus GLEAM Schnelles Resource Constrained Project Scheduling mit dem Evolutionären Algorithmus GLEAM Wilfried Jakob 1, Alexander Quinte 1, Karl-Uwe Stucky 1, Wolfgang Süß 1, Christian Blume 2 1 Forschungszentrum

Mehr

Begriff: Scheduling Planung, Schedule Plan. Verplanung der CPU-Zeit an die Threads (bzw. Prozesse)

Begriff: Scheduling Planung, Schedule Plan. Verplanung der CPU-Zeit an die Threads (bzw. Prozesse) 5 CPU-Scheduling Im folgenden wird von Threads gesprochen. Bei Systemen, die keine Threads unterstützen, ist der einzige "Thread" eines Prozesses gemeint. Früher wurde dieser Thread synonym mit dem Begriff

Mehr

Redwood Cronacle und REALTECH theguard! Integration

Redwood Cronacle und REALTECH theguard! Integration Redwood Cronacle und REALTECH theguard! Integration Einleitung Redwood Software und REALTECH haben gemeinsam eine Lösung entwickelt, die die Systemverfügbarkeit von SAP und mysap Systemen signifikant erhöht.

Mehr

DIPLOMARBEIT. Integration anwendungsneutraler lokaler Suchverfahren. in den adaptiven memetischen Algorithmus HyGLEAM

DIPLOMARBEIT. Integration anwendungsneutraler lokaler Suchverfahren. in den adaptiven memetischen Algorithmus HyGLEAM DIPLOMARBEIT Integration anwendungsneutraler lokaler Suchverfahren in den adaptiven memetischen Algorithmus HyGLEAM für die komplexe Reihenfolgeoptimierung von Björn Hahnenkamp Referent: Prof. Dr. Hartmut

Mehr

Bachelorarbeit. Brennpunkt Gemeinsame Agrarpolitik. Die GAP der EU im Spannungsfeld zwischen ökonomischer Ineffizienz und Interessen der Agrarlobby?

Bachelorarbeit. Brennpunkt Gemeinsame Agrarpolitik. Die GAP der EU im Spannungsfeld zwischen ökonomischer Ineffizienz und Interessen der Agrarlobby? Bachelorarbeit Ben Witthaus Brennpunkt Gemeinsame Agrarpolitik Die GAP der EU im Spannungsfeld zwischen ökonomischer Ineffizienz und Interessen der Agrarlobby? Bachelor + Master Publishing Ben Witthaus

Mehr

SAP als effiziente IT-Application für den deutschen Mittelstand? mit Schwerpunkt Internationales Management

SAP als effiziente IT-Application für den deutschen Mittelstand? mit Schwerpunkt Internationales Management Wirtschaftswissenschaftliche Fakultät Universität Passau Bachelorarbeit SAP als effiziente IT-Application für den deutschen Mittelstand? Eingereicht bei Prof. Dr. Carola Jungwirth Lehrstuhl für Betriebswirtschaftslehre

Mehr

Fraunhofer Resource Grid

Fraunhofer Resource Grid Fraunhofer Resource Grid Fraunhofer Resource Grid Andreas Hoheisel (andreas.hoheisel@first.fraunhofer.de) Uwe Der (uwe.der@first.fraunhofer.de) Computing Grids Computing Grids Das Netz ist der Computer

Mehr

Eine Baumstruktur sei folgendermaßen definiert. Eine Baumstruktur mit Grundtyp Element ist entweder

Eine Baumstruktur sei folgendermaßen definiert. Eine Baumstruktur mit Grundtyp Element ist entweder Programmieren in PASCAL Bäume 1 1. Baumstrukturen Eine Baumstruktur sei folgendermaßen definiert. Eine Baumstruktur mit Grundtyp Element ist entweder 1. die leere Struktur oder 2. ein Knoten vom Typ Element

Mehr

Numerisches Programmieren

Numerisches Programmieren Technische Universität München SS 2012 Institut für Informatik Prof Dr Thomas Huckle Dipl-Inf Christoph Riesinger Dipl-Math Alexander Breuer Dipl-Math Dipl-Inf Jürgen Bräckle Dr-Ing Markus Kowarschik Numerisches

Mehr

Analyse kritischer Erfolgsfaktoren für Enterprise Social Networking Anwendungen. Bachelorarbeit

Analyse kritischer Erfolgsfaktoren für Enterprise Social Networking Anwendungen. Bachelorarbeit Analyse kritischer Erfolgsfaktoren für Enterprise Social Networking Anwendungen Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftswissenschaften

Mehr

Scheinaufgabe im Fach Web Engineering

Scheinaufgabe im Fach Web Engineering Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik Institut für Verteilte Systeme Scheinaufgabe im Fach Web Engineering Thomas Thüm 07. August 2006 Matrikel: 171046 Lehrveranstaltung: Web

Mehr

Zeichnen von Graphen. graph drawing

Zeichnen von Graphen. graph drawing Zeichnen von Graphen graph drawing WS 2006 / 2007 Gruppe: D_rot_Ala0607 Christian Becker 11042315 Eugen Plischke 11042351 Vadim Filippov 11042026 Gegeben sei ein Graph G = (V; E) Problemstellung V E =

Mehr

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector 7.4 Analyse anhand der SQL-Trace 337 7.3.5 Vorabanalyse mit dem Code Inspector Der Code Inspector (SCI) wurde in den vorangegangenen Kapiteln immer wieder erwähnt. Er stellt ein paar nützliche Prüfungen

Mehr

Steinerbäume. Seminarausarbeitung Hochschule Aalen Fakultät für Elektronik und Informatik Studiengang Informatik Schwerpunkt Software Engineering

Steinerbäume. Seminarausarbeitung Hochschule Aalen Fakultät für Elektronik und Informatik Studiengang Informatik Schwerpunkt Software Engineering Steinerbäume Seminarausarbeitung Hochschule Aalen Fakultät für Elektronik und Informatik Studiengang Informatik Schwerpunkt Software Engineering Verfasser Flamur Kastrati Betreuer Prof. Dr. habil. Thomas

Mehr

Seminar künstliche Intelligenz

Seminar künstliche Intelligenz Seminar künstliche Intelligenz Das Kürzeste-Wege-Problem in öffentlichen Verkehrsnetzen Stefan Görlich mi5517 25.05.2005 Inhalt 1. Einleitung 1.1 Problemstellung 3 1.2 Zielsetzung 3 1.3 Die Suche in öffentlichen

Mehr

Proseminar Technische Informatik A survey of virtualization technologies

Proseminar Technische Informatik A survey of virtualization technologies Proseminar Technische Informatik A survey of virtualization technologies Referent: Martin Weigelt Proseminar Technische Informatik - A survey of virtualization technologies 1 Übersicht 1. Definition 2.

Mehr

Praktische Job-Shop Scheduling-Probleme. Dissertation

Praktische Job-Shop Scheduling-Probleme. Dissertation Praktische Job-Shop Scheduling-Probleme Dissertation zur Erlangung des akademischen Grades doctor rerum naturalium (Dr. rer. nat.) vorgelegt dem Rat der Fakultät für Mathematik und Informatik der Friedrich-Schiller-Universität

Mehr

Grundlagen verteilter Systeme

Grundlagen verteilter Systeme Universität Augsburg Insitut für Informatik Prof. Dr. Bernhard Bauer Wolf Fischer Christian Saad Wintersemester 08/09 Übungsblatt 5 26.11.08 Grundlagen verteilter Systeme Lösungsvorschlag Aufgabe 1: Erläutern

Mehr

Universität Passau. Prof. Dr. Carola Jungwirth. Bachelorarbeit

Universität Passau. Prof. Dr. Carola Jungwirth. Bachelorarbeit Universität Passau Lehrstuhl für Betriebswirtschaftslehre mit Schwerpunkt Internationales Management Prof. Dr. Carola Jungwirth Bachelorarbeit Der Einsatz moderner Medien und Kommunikationsmöglichkeiten

Mehr

Cloud Computing in Industrie 4.0 Anwendungen: Potentiale und Herausforderungen

Cloud Computing in Industrie 4.0 Anwendungen: Potentiale und Herausforderungen Cloud Computing in Industrie 4.0 Anwendungen: Potentiale und Herausforderungen Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftsingenieur der Fakultät

Mehr

Studien- und Prüfungsordnung für den Bachelorstudiengang Wirtschaftsinformatik (Information Systems and Management) an der

Studien- und Prüfungsordnung für den Bachelorstudiengang Wirtschaftsinformatik (Information Systems and Management) an der Studien- und Prüfungsordnung für den Bachelorstudiengang Wirtschaftsinformatik (Information Systems and Management) an der Hochschule für angewandte Wissenschaften Fachhochschule München vom 23.08.2010

Mehr

Grundlagen und Basisalgorithmus

Grundlagen und Basisalgorithmus Grundlagen und Basisalgorithmus Proseminar -Genetische Programmierung- Dezember 2001 David König Quelle: Kinnebrock W.: Optimierung mit genetischen und selektiven Algorithmen. München, Wien: Oldenbourg

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

High Performance Computing Cluster-Lösung mit MOSIX im Einsatz bei VA-TECH HYDRO

High Performance Computing Cluster-Lösung mit MOSIX im Einsatz bei VA-TECH HYDRO High Performance Computing Cluster-Lösung mit MOSIX im Einsatz bei VA-TECH HYDRO Anastasios Stomas SFI Technology Services AG 12. März 2003 anastasios.stomas@sfi.ch Seite 1 Hintergrund INHALT Cluster-

Mehr

Ohne Mathematik undenkbar!

Ohne Mathematik undenkbar! Die tägliche - Suche: Ohne Mathematik undenkbar! Dipl.-Wirt.Math. Jan Maruhn FB IV - Mathematik Universität Trier 29. März 2006 29. März 2006 Seite 1 Gliederung Einleitung und Motivation Das Internet als

Mehr

Herausforderungen des Continuous Auditing im Big Data Umfeld

Herausforderungen des Continuous Auditing im Big Data Umfeld Herausforderungen des Continuous Auditing im Big Data Umfeld Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftswissenschaft der Wirtschaftswissenschaftlichen

Mehr

Codierungstheorie Rudolf Scharlau, SoSe 2006 9

Codierungstheorie Rudolf Scharlau, SoSe 2006 9 Codierungstheorie Rudolf Scharlau, SoSe 2006 9 2 Optimale Codes Optimalität bezieht sich auf eine gegebene Quelle, d.h. eine Wahrscheinlichkeitsverteilung auf den Symbolen s 1,..., s q des Quellalphabets

Mehr

Neuerungen Analysis Services

Neuerungen Analysis Services Neuerungen Analysis Services Neuerungen Analysis Services Analysis Services ermöglicht Ihnen das Entwerfen, Erstellen und Visualisieren von Data Mining-Modellen. Diese Mining-Modelle können aus anderen

Mehr

Binäre Bäume Darstellung und Traversierung

Binäre Bäume Darstellung und Traversierung Binäre Bäume Darstellung und Traversierung Name Frank Bollwig Matrikel-Nr. 2770085 E-Mail fb641378@inf.tu-dresden.de Datum 15. November 2001 0. Vorbemerkungen... 3 1. Terminologie binärer Bäume... 4 2.

Mehr

2. DFG- Workshop 3.1. Erfassung/Bewertung/Transfer. Beitrag von Peter Küsters. Spiegelung. Archiv. Bild 1: Unterschied zwischen FTP und Spiegelung

2. DFG- Workshop 3.1. Erfassung/Bewertung/Transfer. Beitrag von Peter Küsters. Spiegelung. Archiv. Bild 1: Unterschied zwischen FTP und Spiegelung 2. DFG- Workshop 3.1. Erfassung/Bewertung/Transfer Beitrag von Peter Küsters Formen des Datentransfers bei der Erfassung von Websites Im folgenden werden Methoden und Software zur Erfassung vorgestellt.

Mehr

Seminar im WS 2011/12: Technische Aspekte des Cloud- Computings. Prof. Sergei Gorlatch, Dominik Meiländer, Michel Steuwer

Seminar im WS 2011/12: Technische Aspekte des Cloud- Computings. Prof. Sergei Gorlatch, Dominik Meiländer, Michel Steuwer Seminar im WS 2011/12: Technische Aspekte des Cloud- Computings Prof. Sergei Gorlatch, Dominik Meiländer, Michel Steuwer Fachbereich Mathematik und Informatik Arbeitsgruppe Parallele und Verteilte Systeme

Mehr

Vergleich verschiedener Optimierungsansätze

Vergleich verschiedener Optimierungsansätze Vergleich verschiedener Optimierungsansätze Inhaltsverzeichnis 1 Einleitung... 2 2 Welchen Nutzen schafft munio?... 3 3 Analysen... 3 3.1 Schritt 1: Optimierung anhand von Indizes... 3 3.2 Schritt 2: Manuell

Mehr

Hauptdiplomklausur Informatik März 2002: Internet Protokolle

Hauptdiplomklausur Informatik März 2002: Internet Protokolle Universität Mannheim Fakultät für Mathematik und Informatik Lehrstuhl für Praktische Informatik IV Professor Dr. W. Effelsberg Hauptdiplomklausur Informatik März 2002: Internet Protokolle Name:... Vorname:...

Mehr

TESTPLAN

TESTPLAN <Projektname> Firma TESTPLAN ID Version Ersteller: ------------------- Vorgesetzter des Erstellers:

Mehr

Branch-and-Bound. Wir betrachten allgemein Probleme, deren Suchraum durch Bäume dargestellt werden kann. Innerhalb des Suchraums suchen wir

Branch-and-Bound. Wir betrachten allgemein Probleme, deren Suchraum durch Bäume dargestellt werden kann. Innerhalb des Suchraums suchen wir Effiziente Algorithmen Lösen NP-vollständiger Probleme 289 Branch-and-Bound Wir betrachten allgemein Probleme, deren Suchraum durch Bäume dargestellt werden kann. Innerhalb des Suchraums suchen wir 1.

Mehr

Formaler Entwurf mit Event-B Die Eventbank

Formaler Entwurf mit Event-B Die Eventbank Institut für Theoretische Informatik Anwendungsorientierte Formale Verifikation Vorlesung Anwendung Formaler Verifikation SS 2015, 9.6.15 Dr. V. Klebanov, Dr. M. Ulbrich Formaler Entwurf mit Event-B Die

Mehr

1 Einleitung. 1.1 Unser Ziel

1 Einleitung. 1.1 Unser Ziel 1 Dieses Buch wendet sich an alle, die sich für agile Softwareentwicklung interessieren. Einleitend möchten wir unser mit diesem Buch verbundenes Ziel, unseren Erfahrungshintergrund, das dem Buch zugrunde

Mehr

Kapiteltests zum Leitprogramm Binäre Suchbäume

Kapiteltests zum Leitprogramm Binäre Suchbäume Kapiteltests zum Leitprogramm Binäre Suchbäume Björn Steffen Timur Erdag überarbeitet von Christina Class Binäre Suchbäume Kapiteltests für das ETH-Leitprogramm Adressaten und Institutionen Das Leitprogramm

Mehr

Ausarbeitung zum Vortrag Java Web Start von Adrian Fülöp Fach: Komponentenbasierte Softwareentwicklung WS 06/07 Fachhochschule Osnabrück

Ausarbeitung zum Vortrag Java Web Start von Adrian Fülöp Fach: Komponentenbasierte Softwareentwicklung WS 06/07 Fachhochschule Osnabrück Ausarbeitung zum Vortrag Java Web Start von Adrian Fülöp Fach: Komponentenbasierte Softwareentwicklung WS 06/07 Fachhochschule Osnabrück Adrian Fülöp (297545) - 1 - Inhaltsverzeichnis: 1. Einführung 2.

Mehr

Kodierungsalgorithmen

Kodierungsalgorithmen Kodierungsalgorithmen Komprimierung Verschlüsselung Komprimierung Zielsetzung: Reduktion der Speicherkapazität Schnellere Übertragung Prinzipien: Wiederholungen in den Eingabedaten kompakter speichern

Mehr

IT-Sicherheit mobiler Applikationen zur Unterstützung von Geschäftsprozessen. Bachelorarbeit

IT-Sicherheit mobiler Applikationen zur Unterstützung von Geschäftsprozessen. Bachelorarbeit IT-Sicherheit mobiler Applikationen zur Unterstützung von Geschäftsprozessen Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftswissenschaft der

Mehr

Use-Cases. Bruno Blumenthal und Roger Meyer. 17. Juli 2003. Zusammenfassung

Use-Cases. Bruno Blumenthal und Roger Meyer. 17. Juli 2003. Zusammenfassung Use-Cases Bruno Blumenthal und Roger Meyer 17. Juli 2003 Zusammenfassung Dieses Dokument beschreibt Netzwerk-Szenarios für den Einsatz von NetWACS. Es soll als Grundlage bei der Definition des NetWACS

Mehr

Swp08-6 Verantwortliche: Yundensuren, Baigalmaa. Testkonzept

Swp08-6 Verantwortliche: Yundensuren, Baigalmaa. Testkonzept Testkonzept 1.Einführung Um die Zuverläsigkeit und die Qualität der Software und des gesamten Systems zu verbessern, sind Tests durchzuführen. Die Testreihe läst sich in drei Stufen einteilen, nülich Komponententest,

Mehr

visionapp Server Management 2008 R2 Service Pack 1 (SP1)

visionapp Server Management 2008 R2 Service Pack 1 (SP1) visionapp Server Management 2008 R2 Service Pack 1 (SP1) Die Neuerungen im Überblick Produktinformation Kontakt: www.visionapp.de www.visionapp.de visionapp Server Management 2008 R2 SP1: Neue Funktionen

Mehr

(Titel des Berichts)

(Titel des Berichts) (Titel des Berichts) Praxissemesterbericht von (Vorname Name) aus (Geburtsort) Matrikelnummer Anschrift Telefon HTW Aalen Hochschule für Technik und Wirtschaft Betreuender Professor Abgabetermin Angaben

Mehr

4 Planung von Anwendungsund

4 Planung von Anwendungsund Einführung 4 Planung von Anwendungsund Datenbereitstellung Prüfungsanforderungen von Microsoft: Planning Application and Data Provisioning o Provision applications o Provision data Lernziele: Anwendungen

Mehr

Grundlagen der Informatik

Grundlagen der Informatik Grundlagen der Informatik Prof. Dr. Bernhard Schiefer bernhard.schiefer@fh-kl.de http://www.fh-kl.de/~schiefer Wesentliche Inhalte Einführung Rechnergrundlagen Grundlagen der Programmierung Kern imperativer

Mehr

Effiziente Java Programmierung

Effiziente Java Programmierung Effiziente Java Programmierung Seminar Implementierung moderner virtueller Maschinen am Beispiel von Java SS 2009 von Reinhard Klaus Losse 20. Mai 2009 Gliederung Definition Effizienz Werkzeuge zum Messen

Mehr

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit 1 Hochverfügbarkeit Lernziele: Network Load Balancing (NLB) Failover-Servercluster Verwalten der Failover Cluster Rolle Arbeiten mit virtuellen Maschinen Prüfungsanforderungen von Microsoft: Configure

Mehr

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Andreas Armbrecht Siemens AG Darmstadt, 01. 02. Dezember 2009 Business Unit Rail Automation Systeme der Eisenbahnautomatisierung

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

VLADISLAVA ARABADZHIEVA

VLADISLAVA ARABADZHIEVA VLADISLAVA ARABADZHIEVA Bachelor of Science Informatik Geburtsjahr 1987 Profil-Stand August 2015 Triona Information und Technologie GmbH Wilhelm-Theodor-Römheld-Str. 14 55130 Mainz Fon +49 (0) 61 31 9

Mehr

Datenstrukturen & Algorithmen

Datenstrukturen & Algorithmen Datenstrukturen & Algorithmen Matthias Zwicker Universität Bern Frühling 2010 Übersicht Binäre Suchbäume Einführung und Begriffe Binäre Suchbäume 2 Binäre Suchbäume Datenstruktur für dynamische Mengen

Mehr

Drei Strategien, die First-Call-Resolution zu verbessern

Drei Strategien, die First-Call-Resolution zu verbessern Drei Strategien, die First-Call-Resolution zu verbessern Das Messen von Kennzahlen ist allen Managern im Kunden-Service- Bereich ein Begriff. Die meisten von ihnen messen weit mehr als die branchenüblichen

Mehr

Betriebssysteme (BTS)

Betriebssysteme (BTS) 9.Vorlesung Betriebssysteme (BTS) Christian Baun cray@unix-ag.uni-kl.de Hochschule Mannheim Fakultät für Informatik Institut für Betriebssysteme 10.5.2007 Exkursion Die Exkursion wird am Freitag, den 18.5.2007

Mehr

Effizientes Änderungsmanagement in Outsourcing- Projekten

Effizientes Änderungsmanagement in Outsourcing- Projekten Effizientes Änderungsmanagement in Outsourcing- Projekten Dr. Henning Sternkicker Rational Software IBM Deutschland GmbH Sittarder Straße 31 52078 Aachen henning.sternkicker@de.ibm.com Abstract: Es werden

Mehr

DATA BECKERs Praxishandbuch zu SUSE Linux 10

DATA BECKERs Praxishandbuch zu SUSE Linux 10 DATA BECKERs Praxishandbuch zu SUSE Linux 10 Daniel Koch DATA BECKER Hardware vor dem Kauf prüfen 4. So läuft jede Hardware Längst wird Linux von vielen Hardwareherstellern unterstützt. Ganz reibungslos

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

Algorithmische Methoden für schwere Optimierungsprobleme

Algorithmische Methoden für schwere Optimierungsprobleme Algorithmische Methoden für schwere Optimierungsprobleme Juniorprof. Dr. Henning Meyerhenke Institut für Theoretische Informatik 1 KIT Henning Universität desmeyerhenke, Landes Baden-Württemberg Institutund

Mehr

Formulierungshilfen für das wissenschaftliche Schreiben

Formulierungshilfen für das wissenschaftliche Schreiben Formulierungshilfen für das wissenschaftliche Schreiben 1. Einleitendes Kapitel 1.1.1 Einen Text einleiten und zum Thema hinführen In der vorliegenden Arbeit geht es um... Schwerpunkt dieser Arbeit ist...

Mehr

A-Plan 12.0. Zeiterfassung 2.0. Ausgabe 1.1. Copyright. Warenzeichenhinweise

A-Plan 12.0. Zeiterfassung 2.0. Ausgabe 1.1. Copyright. Warenzeichenhinweise A-Plan 12.0 Zeiterfassung 2.0 Ausgabe 1.1 Copyright Copyright 1996-2014 braintool software gmbh Kein Teil dieses Handbuches darf ohne ausdrückliche Genehmigung von braintool software gmbh auf mechanischem

Mehr

Das Studiengangsinformationssystem (SGIS)

Das Studiengangsinformationssystem (SGIS) Das Studiengangsinformationssystem (SGIS) Manual für Typo3-Redakteure Version 1.a Mai 2015 Kontakt: Referat 1.4 - Allgemeine Studienberatung und Career Service Christian Birringer, christian.birringer@uni-rostock.de

Mehr

Dezentralisiertes Quality-of-Service Monitoring

Dezentralisiertes Quality-of-Service Monitoring Dezentralisiertes Quality-of-Service Monitoring Mai 2013 netidee Zwischenbericht Dieses Dokument informiert über den aktuellen Stand des Netidee 2012 Projektes Dezentralisiertes Quality-of-Service Monitoring.

Mehr

IT-Governance und Social, Mobile und Cloud Computing: Ein Management Framework... Bachelorarbeit

IT-Governance und Social, Mobile und Cloud Computing: Ein Management Framework... Bachelorarbeit IT-Governance und Social, Mobile und Cloud Computing: Ein Management Framework... Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftswissenschaft

Mehr