Universität Augsburg. Lehrstuhl für Softwaretechnik. Bachelorarbeit. Design und Implementierung eines selbst-organisierenden

Transkript

1 Universität Augsburg Lehrstuhl für Softwaretechnik Bachelorarbeit Design und Implementierung eines selbst-organisierenden Lagerhaltungs- und Auftragsabwicklungssystems Studiengang: Autor: Informatik B.Sc. Michael Hübschmann Version vom: 6. November 2014 Erstprüfer: Zweitprüfer: Betreuerin: Prof. Dr. Wolfgang Reif Prof. Dr. Bernhard Bauer Dr. Hella Seebach

2 Abstract Selbst-organisierende, adaptive Multiagentensysteme sind ein Hauptforschungsgegenstand bei Organic Computing. Mittlerweile sind sowohl Entwicklungsprozesse als auch Entwicklungswerkzeuge verfügbar, sodass mit einer sich ergänzenden Kombination systematisch ein solches System entwickelt werden kann. Umgesetzt wird ein selbst-organisierendes Lagerhaltungs- und Auftragsabwicklungssystem, wie es bei manchen Logistikunternehmen eingesetzt wird. Dieses wird auf Basis des JADEX-Frameworks mit dem Softwareentwicklungsprozess PosoMAS entwickelt. Dabei werden verschiedene Konzepte, wie das Goal oriented Requirements Engineering, und Entwicklungsmuster, wie beispielsweise das Organic Design Pattern, integriert. 2

3 Inhaltsverzeichnis 1. Einleitung und Motivation 5 2. Grundlagen zu Prozess und Implementierung Zielorientierte Anforderungsanalyse mit KAOS PosoMAS: Softwareentwicklungsprozess für Scrum Organic Design Pattern und Restore Invariant Approach Belief-Desire-Intention-Agenten JADEX Active Components Vision und Anforderungsanalyse Das Kiva Mobile Fulfillment System Anforderungsanalyse Projektumsetzung Evaluierung des JADEX Frameworks - Evaluierungssprint Implementierung eingeschränkter Grundfunktionalitäten - Sprint Erweiterung zu grafischer Benutzeroberfläche und Ausbau von Agenteninteraktionen - Sprint Anwendung des Organic Design Patterns - Sprint Einbindung zusätzlicher Agenten und Abläufe - Sprint Einführung eines Wegfindungsalgorithmus sowie von Systemkonfigurationsund Systemmanipulationsoberfläche - Sprint Ausstehende Fehlerbehebungen und Abschlusstests - Sprint Zusammenfassung Ausblick 65 Literaturverzeichnis 66 A. Anhang 69 A.1. Glossar A.2. Goal-Model A.3. UML-Designklassendiagramm A.4. Entwicklungsdokumente A.5. Produktivsystem Eidesstattliche Erklärung 75 3

4 Abbildungsverzeichnis 1. Ausschnitt aus dem KAOS-Metamodell mit Goal-Model und Responsibility- Model, übernommen aus [23] Die statischen Elemente des Organic Design Patterns nach Seebach [25] Beispiel eines KIVA Warenhauses, entnommen aus [13] Vorläufiges Domänenmodell nach der Anforderungsanalyse Sprint-Backlog von Sprint Verfeinerte Anforderungen nach Abschluss des Sprints Ausschnitt der Textausgabe des Inkrements nach dem ersten Sprint Taskboard nach dem Sprint-Planning im zweiten Sprint Bereits teilweise verfeinertes Sprint-Backlog während des zweiten Sprints, die Verfeinerungen entsprechen teilweise den Tasks des Taskboards Für die Bewegung relevante Ziele, Pläne und Beliefs des Agententyps Robot Grafische Oberfläche mit Avataren für Agenten. Dargestellt ein Roboter, eine Packstation und zehn Regale auf 21 Slots Taskboard nach dem Sprint-Planning im dritten Sprint, die Agentennamen wurden teilweise abgekürzt: Die Packstation mit pack, die Auffüllstation analog, sowie der Dispatch-Server mit dispatch Endfassung eines vereinfachten statischen Modells des Mappings von ODP auf das AMHOFS, ODP-Konzeptnamen wurden über den entsprechenden Klassen hinzugefügt Sequenzdiagramm des Secure Task Allocation Protocols Auswahlbereich für Agenten (links) und ERP-System Simulator (rechts) des AMHOFS Control Centers Taskboard nach dem Sprint-Planning im vierten Sprint Ausschnitt aus dem Designklassenmodell, die ausgehenden ordersinprocess Assoziationen führen zu Replenishment- respektive Fulfillment-Order Das verfeinerte Goal-Model von Sprint Taskboard nach Aufwandsschätzung im Sprint-Planning des fünften Sprint Goal-Model nach den geringfügigen Verfeinerungen in Sprint Der Konfigurationswizard zum Einstellen aller Parameter des AMHOFS Taskboard während Sprint Die grafische Ausgabe des AMHOFS kurz nach dem Start mit einer größeren Zahl von Agenten

5 1. Einleitung und Motivation In Zeiten stetig wachsenden Online-Handels sind Logistikdienstleister und Online-Warenhäuser auf Expansionskurs. Die hochdynamischen Märkte erfordern schnelle Reaktionszeiten, hohe Transparenz und vor allem Adaptivität. Aufträge der Kunden sollen möglichst schnell abgearbeitet werden, die Pakete das Versandzentrum schnellstmöglich verlassen. Die Automatisierung spielt dabei eine große Rolle, die Unternehmen sehen darin die größten Steigerungsmöglichkeiten [32]. Dabei konkurrieren unterschiedliche Ansätze: auf Makro-, also Unternehmensebene, wie auf Mikro-ebene im Warenhaus, stehen sich Zentralisierung und Dezentralisierung mit den jeweiligen Vor- und Nachteilen als gegensätzliche Konzepte gegenüber [31]. Bereits ein Blick in die Natur zeigt jedoch, dezentrale und selbstständige Organisation scheint anpassungsfähiger und widerstandsfähiger zu sein. In der Disziplin Organic Computing wird dieser Aspekt in der Informatik untersucht. Längst sind Verfahren und Techniken entwickelt worden, um derartige, naturinspirierte Systeme sogar industriell einsetzen zu können. Für industrielle Einsatzzwecke ist es besonders wichtig, dass das Verhalten eines solch komplexen Systems trotzdem garantiert werden kann, um Qualitätsstandards halten zu können. Zudem stößt man wieder auf ähnliche Anforderungen wie bei Logistikunternehmen: Eine gute Anpassungsfähigkeit und hohe Performance sind wichtige Faktoren. Im Rahmen der Arbeit sollen einige Konzepte wie der Restore Invariant Approach (RIA) nach Nafz et al. [17] und das Organic Design Pattern (ODP) nach Seebach et al. [26] zur Entwicklung von selbst-organisierenden, adaptiven Ressourcenflusssystemen auf die Anwendungsdomäne der Automated Material Handling Order Fulfillment Systeme angewendet werden. Der Softwareentwicklungsprozess PosoMAS von Steghoefer et al. [28], der speziell für offene, selbst-organisierende Multi-Agenten Systeme entworfen wurde, findet hier Anwendung. PosoMAS wird in Verbindung mit Scrum verwendet und bietet vordefinierte Activities, anhand derer ein solches System systematisch entwickelt werden kann. Die Anforderungen werden zielorientiert mittels KAOS [3][15] modelliert. Für jeden der Sprints in Abschnitt 4 werden beim Sprint-Planning die Anforderungen weiter verfeinert und das Softwaredesign entworfen und umgesetzt. Am Ende jedes Sprints steht für das Sprint-Review ein funktioneller und dokumentierter Prototyp zur Verfügung. Für die konkrete Implementierung wird das Multi-Agenten Framework Jadex verwendet. Mittels der in Jadex integrierten Environment erfolgt eine visuelle Ausgabe, mithilfe der der Ablauf anschaulich verfolgt werden kann. Alle Grundlagen zu den Konzepten werden im folgenden Abschnitt 2 eingeführt. 2. Grundlagen zu Prozess und Implementierung Die in der Einleitung erwähnten Konzepte sind jeweils für sich betrachtet schon sehr umfangreich. Zum Verständnis der für dieses Projekt oft noch angepassten Konzepte werden 5

6 diese im Folgenden erläutert. Nach den für den zugrundeliegenden Prozess wichtigen Abschnitten 2.1 und 2.2 folgen Erläuterungen des ODP- und BDI-Konzepts und abschließend implementierungsrelevante Teile der JADEX Active Components. Die Anpassungen dieser Konzepte werden erst im Abschnitt Projektumsetzung beschrieben Zielorientierte Anforderungsanalyse mit KAOS Um Anforderungen für Softwaresysteme vollständig und eindeutig zu erfassen, hat sich insbesondere für die betrachteten Multiagentensysteme ein Ansatz als geeignet erwiesen: Goal-oriented Requirements Elicitation, also zielorientierte Anforderungsanalyse. KAOS bietet Methoden und Werkzeuge um eine solche Anforderungsanalyse strukturiert durchzuführen und übersichtliche Modelle zu generieren. KAOS steht dabei für Knowledge Acquisition in automated Specification oder auch Keep All Objectives Satisfied, legt also Schwerpunkte auf das automatisierte Generieren der Spezifikation aus den Anforderungsmodellen, sowie darauf, möglichst alle Zielvorgaben der Auftraggeber zu erfüllen[5]. Erfahrungen aus Forschung und Softwareprojekten in der Industrie haben gezeigt, dass die oft äußerst umfangreichen und vom Endprodukt weit entfernten Anforderungsdokumente mithilfe des zielorientierten Ansatzes deutlich schneller, nachvollziehbarer und widerspruchsfreier erstellt werden können. Dabei sind Ausprägungen von formalen Definitionen und damit einhergehender Überprüfbarkeit bis zur abstrakten natürlichsprachlichen Beschreibung möglich. Ein agiler Prozess profitiert zusätzlich von der leichten Anpassbarkeit der Anforderungsdokumente, da Änderungen an den Anforderungen hier oft nötig oder sogar gewünscht sind. KAOS weist außerdem den Akteuren bei der Anforderungsanalyse klare Verantwortungsbereiche zu und erleichtert dadurch die Kommunikation der Projektteilnehmer [14]. Eine vollständige Anforderungsanalyse mittels KAOS führt zu verschiedenen Modellen, die alle ausgehend vom Goal-Model entwickelt werden. Dieses Goal-Model wird für das gesamte System erstellt und bezieht auch die Umgebung mit ein. Ein einzelnes Ziel (Goal) soll durch die Zusammenarbeit der Agenten vom System irgendwann erreicht werden und lässt sich meist in mehrere untergeordnete Ziele aufsplitten. An der Spitze eines solchen hierarchischen Goal-Models stehen somit abstrakte Ziele - strategische Ziele und Unternehmensziele - welche für das gesamte System gelten. Je weiter man diese Ziele verfeinert, also in untergeordnete Ziele aufsplittet, die zusammen das höhere Ziel erfüllen, desto mehr ändert sich die Formulierung der Ziele von abstraktem, domänenspezifischem Vokabular hin zu technischerer Sprache. Umso besser lassen sich die resultierenden Ziele dem Verantwortungsbereich eines Agenten zuordnen. Ein Agent kann bei KAOS ein Mensch, ein Softwaresystem, oder natürlich in einem Multiagentensystem ein eigenständiger Agent sein. Aus den Zielen, die sozusagen die Blätter dieses Ziel-Baumes bilden, lassen sich Anforderungen (Requirements) formulieren, wobei eine Anforderung ein Ziel ist, welches in der Verantwortlichkeit (Responsibility) eines Agenten liegt. Somit kann man das System vollständig auf Anforderungen herunterbrechen, die 6

7 von einzelnen Agenten(-typen) erfüllbar sind. Aber auch der umgekehrte Weg ist möglich. Höhere Ziele lassen sich finden, in dem man sich fragt, warum man ein Ziel erfüllen sollte. Neben dem System selbst muss auch die Umgebung in das Goal-Model einfließen. Diese lässt sich hauptsächlich mittels Erwartungen (Expectations) modellieren, welche wieder in der Verantwortlichkeit eines Agenten liegen, aber gleichzeitig nicht Teil des Systems sind. Spielt Unsicherheit (Uncertainty) im System eine Rolle, sollten sogenannte Hindernisse (Obstacles) identifiziert werden. Ist das Goal-Model soweit vollständig erstellt, bestimmt man an den Blättern des Baumes aufsteigend Unsicherheitsfaktoren, die ein Ziel verhindern könnten. Oft ergeben sich Unsicherheiten aus Objekten der Umgebung, weshalb man darauf ein besonderes Augenmerk legen sollte. Durch neue untergeordnete Ziele oder das RELAXen 1 eines übergeordneten Ziels, beispielsweise durch das Erweitern der Formulierung durch soweit möglich können diese Hindernisse eliminiert werden [3] [15]. Mit dem Goal-Model als Basis lässt sich leicht ein Object-Model generieren, welches alle Beziehungen der Agenten enthält und durch Objekte (Entities) ergänzt wird. Um die Abläufe in den Anforderungsdokumenten zu dokumentieren, verwendet man das Operation-Model. Das Verhalten der Agenten um bestimmte Anforderungen zu erfüllen, wird durch Abläufe (Operations) mit Vor- und Nachbedingung sowie ein- und ausgehenden Daten festgelegt [29]. KAOS stützt sich auf eine speziell für den Ansatz entwickelte An- Abbildung 1: Ausschnitt aus dem KAOS-Metamodell mit Goal-Model und Responsibility- Model, übernommen aus [23] wendung namens Objectiver. Objectiver ermöglicht das Erstellen der obigen Modelle und generiert automatisch eine Spezifikation daraus, die Glossar, Anforderungsliste und weitere Dokumente enthält [23]. Die graphische Entsprechung der oben eingeführten Konzepte lässt sich in Abbildung 1 einsehen. 1 RELAX ist eine formal beschriebene Sprache um Anforderungen mit Unsicherheit zu formulieren. Weitere Details finden sich in [21] und [30] 7

8 2.2. PosoMAS: Softwareentwicklungsprozess für Scrum Da PosoMAS in der betrachteten Anpassung auf Scrum basiert, soll erst ein kurzer Überblick über Scrum gegeben werden, bevor die Besonderheiten von PosoMAS und schlussendlich ein paar Anpassungen, die speziell für das AMHOFS Projekt angefertig wurden, beschrieben werden. Überblick über Scrum Scrum ist ein kompaktes Rahmenwerk und wird hauptsächlich als agiler Softwareentwicklungsprozess umgesetzt. Im Agile Atlas der ScrumAlliance [24] sind alle Elemente von Scrum erläutert: Scrum setzt auf inkrementelles Vorgehen, um die hohe Komplexität heutiger Software für Entwickler etwas herunterzubrechen und in kleinere Teilprobleme zu zerlegen. Hauptpunkte, auf die sich Scrum stützt, sind dabei Focus, Courage, Openness, Commitment, Respect. Teamwork verträgt sich damit sehr gut und die drei Rollen in Scrum machen dies ebenfalls deutlich: Das Entwicklungsteam besteht aus Entwicklern, die neben Programmierung auch System-Architektur und Testing verantworten. Der Product-Owner vertritt den Auftraggeber und andere Stakeholder innerhalb des Scrum-Teams, bemüht sich um ein bestmögliches Produkt und steuert dementsprechend einen großen Teil des Prozesses. Ein Scrum-Master unterstützt das Entwicklungsteam bei Problemen und ist mit dem Scrum-Rahmenwerk bestens vertraut, um alle Beteiligten dahingehend zu beraten. Die Entwicklung läuft bei Scrum in Sprints. Nach jedem Sprint steht ein funktionsfähiges Produktinkrement bereit, dass mit jedem 1-4 wöchigen Sprint weiterentwickelt wird. Zu Beginn eines Sprints findet ein Sprint-Planning statt, bei dem das Vorgehen für den Sprint geplant wird. Dabei bedient man sich des Product-Backlogs. Dieses wird vom Product-Owner mit Anforderungen gefüllt und die Einträge werden beständig verfeinert und priorisiert. Das Scrum-Team fügt dem sogenannten Sprint-Backlog alle Einträge des Product-Backlogs hinzu, die es für den Sprint als machbar erachtet. Dabei muss das Entwicklerteam abschätzen, wieviel Aufwand ein Eintrag bedeutet und was in dem Sprint alles erledigt werden kann. Gegen Ende des Sprint-Plannings treffen die Entwickler bereits grobe Designentscheidungen, um im Sprint-Backlog festhalten zu können, welche spezifischen Aufgaben anstehen. Im Scrum-Team sollte es zudem einen Konsens geben, was das Ziel des Sprints ist, bzw. welche Definition of Done das Team hat. Anhand dessen wird nach dem Entwicklungsschritt das Produktinkrement beurteilt und der Sprint abgenommen. Während des Entwicklungsschrittes hält das Team täglich ein Daily Scrum ab, um jeweils Tagesziele festzulegen und den Grundsatz Transparenz zu pflegen. Am Ende steht dann ein getestetes, lauffähiges Produkt, das im Sprint-Review vorgestellt wird. Zudem kann im Sprint-Review das Product-Backlog erweitert oder geändert werden. Zuletzt trifft sich das Scrum-Team zur Sprint-Retrospective. Probleme während des Sprints werden rückblickend diskutiert und Verbesserungen, meist vom Scrum-Master, eingeleitet. PosoMAS - Process for open self-organising Multi-Agent Systems Um den besonderen Anforderungen der Softwareentwicklung bei Organic Computing Systemen zu be- 8

9 gegnen, gibt es verschiedene Prozessvorlagen. Meist sind diese jedoch auf spezifische Systemarchitekturen zugeschnitten und nicht generell verwendbar. PosoMAS, der Prozess für offene, selbstorganisierende Multiagentensysteme begegnet diesem Problem mit einer flexiblen und generischen Struktur. Dabei ist PosoMAS auf Anpassungsfähigkeit und Erweiterbarkeit ausgelegt und ist unabhängig von verwendeter Agenten-Architektur oder den Entwicklungswerkzeugen. Basierend auf Steghoefer et al. [28] wird im Folgenden ein kurzer Überblick über den Prozess gegeben. Der Prozess erweitert in der ursprünglichen Form den OpenUP und ist mithilfe des Software Process Engineering Metamodels 2 formuliert. Das Ziel des Prozesses ist es dabei hilfreiche Werkzeuge und Anleitungen für die MAS spezifischen Probleme anbieten zu können und viele Techniken und Konzepte im Prozess zu vereinigen. Dazu setzt PosoMAS auf eine flexible Formulierung durch Practices. Sie erweitern den OpenUP um Techniken wie GORE oder Pattern-Driven MAS Design. Vier Bereiche lassen sich bei der Architektur aller selbst-organisierender Multiagentensysteme unterscheiden: der Aufbau ( Agent Architecture ) sowie die Organisation der Agenten ( Agent Organisation ), Kooperation und Kommunikation zwischen Agenten ( Agent Interaction ) und alle weiteren Bestandteile des Systems und der Umwelt ( System Architecture ). Diese Bereiche werden durch Practices abgedeckt und die verschiedenen Architekturdomänen werden klar voneinander getrennt. Jede Practice bildet eine abgeschlossene Einheit, für die definiert ist, welche Prozessbeteiligten welche Aufgaben zu erfüllen haben, welche Arbeitserzeugnisse sich ergeben und was vorher an Dokumenten bereit stehen sollte. Zudem werden zu jeder Practice Richtlinien angeboten, die beispielsweise bei der Wahl eines geeigneten Algorithmus oder einer geeigneten Agenten-Architektur unterstützen. Die sieben Practices decken dabei das gesamte Softwaredesign und die Implementierung der Komponenten ab: Goal-driven Requirements Elicitation Wie bereits im Abschnitt 2.1 zu GORE und KAOS vorgestellt, wird für die Anforderungsanalyse ein zielorientierter Ansatz gewählt. PosoMAS gibt vor, dass die Anforderungen immer System-Zielen entsprechen müssen und bis auf eine Ebene verfeinert werden, auf der jeder Anforderung klar einem Agenten zugewiesen werden kann. Product-Owner und Entwicklungsteam müssen eng zusammenarbeiten und erhalten dadurch ein Kommunikationsmittel. Model-driven Observer Synthesis Wurden während der Anforderungsanalyse bereits Bedingungen (Constraints) entwickelt, können diese auf eine für MAS übliche Observer/Controller-Architektur transformiert werden. Dieser modellgetriebene Entwicklungsansatz bietet viele Vorteile bezüglich Konsistenz und Validität. Pattern-Driven MAS Design Um das Multiagentensystem zu entwickeln, können auf verschiedenen Ebenen Entwurfsmuster verwendet werden. Diese vordefinierten Muster können auf Interaktionen, Agenten-Architektur und Gesamtarchitektur des Systems angewendet werden. 2 weitere Informationen zum SPEM unter 9

10 Trust-based Interaction Design Vertrauensbasierte Kommunikation zwischen Agenten ist für MAS mit großen Unsicherheiten besonders wichtig. Dabei werden verschiedene Parameter verwendet um Agenten effizienter kommunizieren zu lassen. Evolutionary Agent Design Diese Practice unterstützt die evolutionäre Entwicklung der Agenten. Erst über die Dauer des Entwicklungsprozesses werden die Anforderungen immer klarer und die Agenten müssen beständig dementsprechend fortentwickelt werden. Agent Organisation Design Bei großen MAS sind Gruppierungen und Formationen von Agenten oft hilfreich. Die Zusammenarbeit und verschiedene Organisationformen der Agenten können mit dieser Practice verbessert und eingesetzt werden. Agent System Design Alle Teile des Software-Systems, die um die Agenten herum funktionieren, stehen hier im Fokus. Dabei werden Umgebung und Infrastruktur und Interaktion mit beiden Elementen betrachtet. In Scrum ist die Zahl der verschiedenen Rollen im Gegensatz zum OpenUP viel geringer und eine strikte Aufteilung von Zuständigkeiten gibt weniger Sinn. Auch ist die Unterteilung in Practices aufgebrochen. In PosoMAS für Scrum kann das Entwicklerteam daher aus der gesamten Bibliothek von Activities und Tasks auswählen (die den Practices untergeordnet sind), und im Daily Scrum selbst entscheiden, was für den jeweiligen Tag zu verwenden ist. Teilweise kann bereits der Umfang einzelner Steps in einem Task ausreichend Arbeit für den Tag bereitstellen. Alle Methoden, Arbeitserzeugnisse und Abläufe finden sich Online [27] Organic Design Pattern und Restore Invariant Approach Der sogenannte Restore Invariant Approach, also der Ansatz, Invarianten wiederherzustellen, bildet die Grundlage für viele Verfahren bezüglich der Entwicklung von selbstorganisierenden Systemen und damit auch für das im zweiten Punkt erläuterte Organic Design Pattern. Mit beiden Ansätzen kann man bestimmte Eigenschaften bei selbstorganisierenden Systemen sicherstellen. So kann trotz der starken Dynamik und der strukturellen Veränderungen des Systems zur Laufzeit bereits während des Entwicklungsprozesses funktionale Korrektheit garantiert werden. Die Kurzvorstellung von RIA stützt sich auf Nafz et al. [17] und Güdemann et al.[9], die Beschreibung des ODP wurde von Seebach et al. [26] sowie Nafz et al. [16] zusammengefasst. RIA - Restore Invariant Approach Da ein Organic-Computing-System im Gegensatz zu herkömmlichen Systemen auf vielfältige Umwelteinflüsse reagieren muss, ohne dass jeder mögliche Fall genau spezifiziert werden kann, entwickelt man nach dem RIA eine Invariante, die das gewünschte Verhalten des Systems eingrenzt. Diese Invariante ist aber relativ liberal definiert und gibt nur einen Verhaltenskorridor für das System vor. Solange das System sich in diesem Korridor bewegt, ist die Invariante erfüllt und das System führt, 10

11 auch formal überprüfbar, die intendierten Aufgaben durch. Eine solche Invariante besteht aus mehreren Bedingungen, die auf einzelne Systemkomponenten heruntergebrochen werden. Dadurch können die Bedingungen auch meist für jede Systemkomponente getrennt und damit dezentral überwacht werden, was vorteilhaft für Multiagentensysteme ist. Verlässt das System den zulässigen Verhaltenskorridor, ist also eine Bedingung nicht mehr erfüllt, wird der Rekonfigurationsmechanismus aktiviert. Je nach eingetretener Verletzung der Invariante können dann unterschiedliche Aktionen durch den Mechanismus getätigt werden, um das System zurück zu einem korrekten Verhalten zu führen. Dabei ist der Mechanismus unabhängig vom oben beschriebenen funktionalen Teil. Um eine Rekonfiguration zu ermöglichen, trifft eine Invariante Aussagen über Variablen des Systems, die durch den Mechanismus entsprechend geändert werden können. Das System muss zudem gewisse Freiheiten bieten, um eine Rekonfiguration überhaupt möglich zu machen. Redundanz der Komponenten oder bei den Belegungen für die Zustandsvariablen ist daher wichtig, um die selbst-x Eigenschaften zu erhalten. Die möglichen Systemzustände lassen sich eindeutig unterteilen. Einerseits in solche, bei denen die Invariante erfüllt ist und sich das System nicht anders als herkömmliche Systeme verhält. Andererseits in solche, für die die Invariante nicht erfüllt und ein Rekonfigurationsmechanismus aktiv ist, der das System neu organisiert und in einen funktionalen Zustand zurückführt, wodurch die Invariante wieder erfüllt ist [18]. Für die Rekonfiguration wird normalerweise eine Observer/Controller Architektur verwendet. Der funktionale Teil des Systems wird vom Observer beobachtet, welcher jegliche Verletzung der Bedingungen an den Controller gibt. Dieser besteht aus Selbst-x Algorithmen (beispielsweise selbst-heilende oder selbst-organisierende Algorithmen), welche eine neue Konfiguration für das System berechnen, sowie einem Result-Checker. Der Result- Checker wurde bereits im Vorlauf verifiziert und überprüft die resultierende Konfiguration des Controllers, stellt also sicher, dass die neue Konfiguration die Invariante erfüllt. Nach dieser Verifizierung kann die neue Konfiguration auf das System angewendet werden, die Invariante ist wieder erfüllt und das System handelt korrekt. Im folgenden wird eine solche Umsetzung des RIA mit einer Observer/Controller Architektur beschrieben. ODP - Organic Design Pattern Für die Softwareentwicklung sind bestimmte Muster, nach denen ein System gestaltet wird, auch Patterns genannt, von entscheidender Bedeutung, um wiederkehrende Problemstellungen zu lösen. Das Organic Design Pattern ist ein solches Entwurfsmuster, das speziell auf selbstorganisierende Ressourcenflusssysteme ausgerichtet ist. Die Klasse der selbstorganisierenden Ressourcenflusssysteme beschreibt alle Multiagentensysteme, in denen für bestimmte Aufgaben oder Rollen Ressourcen durch das System bewegt werden, wobei die verschiedenen Agenten interagieren und ihre jeweiligen Fähigkeiten auf die Ressourcen anwenden können. Die Aufgaben bestehen meist aus einer Aneinanderreihung von Tätigkeiten, die für eine Ressource durchgeführt werden. Durch 11

12 Selbstorganisation kann dieser Ressourcenfluss auch bei Problemen wie beispielsweise dem Ausfall von Agenten aufrechterhalten werden. Es stehen also die selbst-x Eigenschaften des Systems im Vordergrund, welche unabhängig von der eigentlichen Funktion des Systems implementiert werden sollen. Zudem soll nach dem RIA ein gewisses Verhalten des Systems garantiert werden können. Das ODP gibt ein statisches Modell für solche Systeme vor (siehe Abbildung 2). Die zentrale Einheit stellt der Agent dar. Ein Agent besitzt bestimmte Fähigkeiten (Capabilities). Das sind Tätigkeiten, die er an einer Ressource theoretisch ausführen kann. Hat er eine solche Ressource von einem anderen Agenten erhalten und ist ihm eine entsprechende Rolle zugeteilt, kann er die Aufgabe (Task), die für die Ressource erfüllt werden soll, mit seiner Fähigkeit ausführen und somit den Status der Ressource verändern. {complete, disjoint} Caps Produce ODP {ordered, nonunique} -state * {nonunique} {nonunique} -requiredcapabilities 2..* * -state Capability -availablecapabilities * * * -capabilitiestoapply {ordered, nonunique} Resource * -resources 0..1 Agent {CapabilityConsistency, I/O-Consistency, Pre-PostconditionConsistency} + * -port task 1 -inputs * * -outputs 1 * Task {Produce-/Consume-Assurance, Producer-/Consumer-Roles} * -agents -currenttasks * 0..1 Observer/Controller 1 -oc -task 1 Process Consume * -allocatedroles 1..* Role {isconsumerrole(), isproducerrole(), Task-Equality} -precondition postcondition * Condition * + Abbildung 2: Die statischen Elemente des Organic Design Patterns nach Seebach [25] Ein Agent hat zudem einige Bedingungen, die Bestandteil der globalen Invariante sind, und die immer erfüllt sein müssen. Beispielsweise sichert die Bedingung CapabilityConsistency zu, dass alle Rollen, die einem Agenten zugewiesen sind, auch nur Fähigkeiten enthalten, die der Agent beherrscht. Würde einem Agenten also eine Rolle zugewiesen werden, die er nicht erfüllen kann, da ihm dazu die Befähigung fehlt, würde der Observer diese Bedingung als falsch auswerten und den Rekonfigurationsmechanismus anstoßen. Dieser dynamische Teil ist im ODP ebenfalls generisch vorgegeben. Dazu wird, wie bereits beim RIA erwähnt, ein Observer und ein Controller genutzt: Funktionale Agenten des Systems werden um Observer-Funktionalitäten erweitert und Rekonfigurationsagenten für die verschiedenen Aufgaben hinzugefügt, die als Controller nur bei Verletzung der Invarianten tätig werden. Die Verschmelzung aus einem funktionalen Agenten und dem Observer-Teil wird BaseAgent genannt. Auf der funktionalen Seite empfängt ein Agent 12

13 Ressourcen von einem input-agenten, wählt entsprechende Rollen und wendet seine Fähigkeiten auf die Ressource und die damit verbundene Aufgabe an, um sie danach an einen output Agenten weiterzugeben. Auf der Observer-Seite überprüft der Agent ständig die für ihn geltenden Bedingungen und reagiert auch auf Anfragen anderer Agenten, die Daten für die Auswertung ihrer eigenen Bedingungen benötigen. Stößt ein beliebiger Agent eine Rekonfiguration an, müssen alle für die Rekonfiguration benötigten Agenten die Ausführung des entsprechenden Tasks stoppen und auf eine neue Konfiguration warten. Diese wird von Rekonfigurationsagenten erstellt. Die Mechanismen für Rekonfigurationsagenten werden im ODP nicht spezifiziert, damit können domänenspezifische selbst-x Mechanismen implementiert werden. Gemein ist allen Rekonfigurationsagenten aber, dass sie dem oder den Agenten eine neue, korrekte Rollenkonfiguration zuweisen. Dadurch können nach der Neuzuweisung alle Agenten zur Ausführung zurückkehren. Das Mapping des ODP auf die Domäne des AMHOFS wird in Kapitel 4.4 genau beleuchtet Belief-Desire-Intention-Agenten Die Belief-Desire-Intention Architektur für Agenten ist eine etablierte Methode um autonome Agenten zu beschreiben und zu implementieren. Vor allem der einfache Ansatz und die Äquivalenzen zur Beschreibung menschlichen Verhaltens vereinfachen die Entwicklung. Im Quasi-Standard-Werk von Rao und Georgeff [22] werden die drei Elemente eines solchen Agenten beschrieben: Beliefs bilden die Weltsicht des Agenten ab. Sowohl Informationen über sich selbst, als auch über die dem Agenten bekannte Umgebung, werden in Beliefs gespeichert. Desire - die Wünsche - entsprechen ungefähr den Zielen eines Agenten. Passend zur zielorientierten Anforderungsanalyse verfolgt ein Agent bestimmte Ziele und kann auf verschiedenen Wegen versuchen, diese Ziele zu erfüllen. Intentions sind kurzfristigere Ziele, die vom Agenten sofort konkret angegangen werden. Agenten bedienen sich dabei vordefinierter Pläne. Alle Fähigkeiten und Reaktionsmöglichkeiten, die ein Agent besitzt, sind als Pläne abgelegt und werden je nach angenommenen Zielen ausgeführt. Ein BDI-Agent reagiert also auf spezifische Situationen und verfolgt gleichzeitig auch langfristige Ziele, jeweils indem er Pläne ausführt. Dadurch balanciert er zwischen zielgerichtetem und reaktivem Verhalten und kann adaptiv Probleme meistern JADEX Active Components JADEX baut auf dem JADE-Framework 3 auf. JADE bietet bereits eine Grundlage um ein Multiagentensystem zu entwickeln, indem es alle anwendungsunspezifischen und von der 3 JADE steht für Java Agent DEvelopment Framework" 13

14 Agentenarchitektur möglichste unabhängigen Funktionen vorimplementiert anbietet. JA- DE ist eine Middleware, der Fokus des Frameworks liegt also auf der FIPA-konformen 4 Umsetzung von Agenteninteraktion und Agentenmanagement. Der Lebenszyklus eines Agenten oder der direkte Nachrichtentransport zwischen zwei Agenten sind konkrete Beispiele hierfür[1]. JADEX möchte die Erstellung von MAS weiter simplifizieren und bietet daher zusätzlich eine mächtige interne Agentenarchitektur, die auf dem BDI-Paradigma basiert. Braubach et al. [2] setzten hierzu ursprünglich eine Kombination aus XML und Java ein, gingen später aber dazu über, Die XML-Dateien durch Java-Annotationen zu ersetzen. Die JADEX-BDI-Agenten stützen sich auf drei Konzepte. Die Agenten besitzen Beliefs, die als Attribute implementiert wurden. Ziele werden von den Agenten dynamisch angenommen und wollen erfüllt werden. Zudem sind sie durch weitere Eigenschaften unterteilt, sodass es unterschiedliche Zieltypen gibt. Manche Ziele werden bei Änderungen von Beliefs aktiviert, andere werden aktiv, wenn bestimmte Bedingungen nicht mehr gelten - das Ziel besteht dann darin, die Bedingungen wieder herzustellen. Um Ziele zu erreichen implementiert man in JADEX Pläne, die prozedurale Abläufe im Agenten sind und die verschiedenen Lösungswege zum Erreichen eines Ziels anbieten. Wird beispielsweise ein Ziel durch einen Plan nicht erfüllt, kann der Agent einen anderen Ansatz mit einem anderen Plan versuchen. JADEX bietet zudem eine Environment an, die eine unkomplizierte zwei- oder dreidimensionale Visualisierung einer JADEX-Simulation ermöglicht. Diese Darstellung ist vollständig von einem JADEX-System entkoppelt und kann daher optional eingebunden werden [20]. Nach mehreren Jahren Entwicklung hat JADEX inzwischen einen Reifegrad entwickelt, dass es sogar den hohen Ansprüchen bei industriellen Anwendungsszenarien genügen kann und daher für die Implementierung eines selbst-organisierenden Lagerhaltungs- und Auftragsabwicklungssystems sehr geeignet erscheint[19]. 3. Vision und Anforderungsanalyse Im Vorfeld des Entwicklungsprozesses entwirft der Product-Owner eine grobe Version des gewünschten Systems. Da dieses Projekt auf einem bereits real existierenden System basiert, greift auch das Entwicklungsteam im späteren Verlauf auf die in dieser Phase entwickelte Vision zurück Das Kiva Mobile Fulfillment System Als Vorbild für die Implementierung eines selbst-organisierenden Lagerhaltungs- und Auftragsabwicklungssystems dient das Kiva Mobile Fulfillment System von Kiva Systems. Zentrale Eckdaten des Systems sollen auch für die Implementierung gelten. Da kein Zugriff auf interne Dokumente des Unternehmens möglich war, erfolgte die Analyse des Systems 4 FIPA steht für Foundation for Intelligent Physical Agents, einem Komitee, das Standards für Agenteninteraktionen festlegt 14

15 hauptsächlich durch Sichtung von Marketingmaterial wie Videos [10], aber auch von Whitepapers [13][11][12]. Zentrale Eckdaten zum Verhalten und Aufbau des Systems lassen sich aber auch aus diesen Unterlagen gewinnen. Ein Kiva Warenhaussystem umfasst sowohl die chaotische Lagerhaltung auf Regalen und das Nachfüllen dieser Regale als auch das Packen von Päckchen an verbundenen Picking stations. Im Lager selbst muss kein Mensch mehr eingreifen und auch das gesamte Kiva System verwaltet sich selbst und wird im Unternehmenskontext als Black-Box eingebunden. Das heißt, wo genau im Lager sich bestimmte Artikel befinden oder welcher Roboter welche Aufgabe hat, ist einem Bestellsystem oder ERP-System, welche Daten mit dem Kiva-System austauschen, nicht bekannt. Ein Kiva Warenhaus besteht aus beweglichen Regalen, die von mobilen Robotern zu den Picking-Stationen transportiert werden. Dabei bedienen fünf bis zehn solcher batteriegetriebener Roboter eine Station, um einen kontinuierlichen Nachschub an Regalen zu gewährleisten. An einer Station verpacken Menschen computergestützt die Waren von ankommenden Regalen in Pakete. Es können hier mehrere Pakete parallel gepackt werden. Die Roboter besuchen von Zeit zu Zeit eine Auflade- oder Reparaturstation und orientieren sich vermutlich an in den Boden eingebrachten Markierungen. Die Steuerung der Roboter erfolgt hauptsächlich durch einen zentralen Server, an den auch Hindernisse gesendet werden und der Routenberechnung und Auftragsverteilung übernimmt. Die Regale bieten verschiedene Fächer und sind modular aufgebaut, sodass von Stück- bis Schüttware verschiedene Warentypen aufgenommen werden können. Sie werden in einer speziellen Anordnung platziert, sodass Regale mit stark nachgefragten, populären Waren näher an den Picking-Stationen abgestellt werden. Auch die Anzahl an Regalen mit gleichen Produkten, aktuell ausstehende Bestellungen und die Bestellhistorie fließen in die Berechnung mit ein. Die Roboter bringen dann beständig die entsprechenden Regale zu den Stationen, an denen Waren entnommen oder aufgefüllt werden und befördern das Regal danach auf einen immer neu berechneten Platz. Für die weitere Logistik wie den Transport der Pakete zu den Lastwagen bietet Kiva Systems ebenfalls Lösungen an, diese Ausarbeitung beschränkt sich allerdings auf den Lagerhaltungs-Teil eines Warenhauses [13][10]. Die Firma Grenzebach bietet ein sehr ähnliches System mit nur geringfügigen Unterschieden an: Die Roboter können sich beispielsweise über Induktionsschleifen auf den Hauptfahrwegen aufladen. Außerdem gibt es verschiedenste Regaltypen für verschiedene Waren. Auch hier wird ein Flottenmanager eingesetzt, der zentral Wegefindung und -zuteilung übernimmt [8] Anforderungsanalyse Die Anforderungen wurden größtenteils mithilfe des GORE-Ansatzes dokumentiert. Die Dokumentation der Anforderungen erfolgte dabei mittels des für den KAOS-Ansatz entwickelten Programms Objectiver, in dem sich das Goal-Model grafisch schön darstellen 15

16 Abbildung 3: Beispiel eines KIVA Warenhauses, entnommen aus [13] lässt. Auf die Nutzung aller weiteren Funktionen des Programms und auch auf eine vollständige Anwendung von KAOS wurde verzichtet. Alle Ziele und Anforderungen werden informell und mit domänenspezifischem Vokabular beschrieben. Dadurch wurde der gesamte Prozess der Anforderungsanalyse verschlankt, da auf das Operation-Model verzichtet wird. Die resultierenden Dokumente lassen manchen Spielraum offen, da Systemabläufe nur mündlich ausgetauscht wurden. Dem Entwicklungsteam ermöglicht diese Vorgehensweise große Freiheiten bei der Gestaltung des Systems. Die Anforderungen wurden inkrementell ausformuliert, auch noch während der Implementierungsphase. Im ersten Schritt wurde ein Goal-Model erstellt. Das Hauptziel eines solchen Systems ist bereits aus der Bezeichnung abzulesen: die Auftragserfüllung. Das oberste Ziel im Goal- Model lautet daher deliver goods to complete orders, das heißt das System soll Waren ausliefern um entsprechende Aufträge zu erfüllen. Anhand der Daten, die bei Betrachtung des Kiva Mobile Fulfillment Systems extrahiert wurden, ergaben sich Subziele wie " create jobs from orders and assign robots, packstations respectively. Aber auch Anforderungen die der Vision von einem System entstammen, wie provide graphical simulation of the system fanden bereits Einzug in das relativ grobe Modell. Das Product Backlog besteht damit im Wesentlichen aus dem Goal-Model. Es wurde vom Scrum Team nur eine mündliche Aufwandsschätzung abgegeben, diese ist in Unkenntnis der Implementierungsspezifika zusätzlich wenig verlässlich. Die Priorisierung durch den Product-Owner ist daher ebenfalls nur eine mündliche Absprache. Parallel zur Entwicklung des Goal-Models wurde bereits ein erstes Domänenmodell entwickelt um die Beziehungen und Verhältnisse innerhalb des Systems festzulegen. Während die Anforderungen im Goal-Model noch nicht soweit verfeinert wurden, dass sie bereits 16

17 in die Zuständigkeit von bestimmten Agenten fallen würden, sind die Agententypen im Domänenmodell bereits dokumentiert (siehe Abbildung 4). Alle Begriffe, die im Systemkontext für die Anforderungen elementar sind, wurden in einem Glossar (siehe Anhang A.1) erklärt. Für eine weitere Verfeinerung der Ziele müssen bestimmte Rahmenbedingungen des JADEX-Frameworks evaluiert werden, daher endete die Vorfeld-Anforderungsanalyse zugunsten eines Evaluierungssprints. stores Dispatch Server 1 Good * -neighbour * 1 Slot 1 locatedon locatedon * Shelf 0..1 transports activeorders * Order 1 Station adjacentto Robot ReplenishmentOrder PackingOrder * * fulfills Pack station Replenishment station ERP-System fulfills Abbildung 4: Vorläufiges Domänenmodell nach der Anforderungsanalyse 4. Projektumsetzung Vor Beginn der Sprints wurde ein grobes Release-Planning durchgeführt. Da das Product- Backlog noch keine endgültige Form hat, fiel eine Zeitplanung anhand des Backlogs schwer. Trotzdem konnten Scrum-Team, Scrum-Master und Product-Owner sich auf gemeinsame Parameter verständigen, sodass ungefähr 5 Sprints angesetzt wurden und der gesamte Zeitrahmen für das Ein-Mann-Entwicklungsteam ambitioniert auf 4 Monate eingeschränkt wurde Evaluierung des JADEX Frameworks - Evaluierungssprint Da das verwendete JADEX-Framework bereits viele low-level Funktionalitäten implementiert, kann auf einer abstrakteren Ebene begonnen werden. Dazu ist es wichtig, alle Konzepte und Dienste des Frameworks gut zu kennen, um diese in der vorgesehenen Weise nutzen zu können. Der Evaluierungssprint soll hier dem Entwicklerteam, das keine Vorerfahrung mit dem Framework besitzt, die Zeit geben, Kompetenz aufzubauen. 17

18 Der Evaluierungssprint folgt daher nicht dem klassischen Aufbau und es wurde auf ein größeres Sprint-Planning oder Sprint-Review verzichtet. Anstatt dessen fanden kurze Feedback-Gespräche statt. Im Rahmen des Sprints wurde anhand der Online verfügbaren Tutorials geprüft, welcher Agententyp von JADEX genutzt werden sollte oder ob sogar möglicherweise eine eigene Agentenarchitektur implementiert werden sollte. Im Vergleich zeigten sich die relativ jungen BDIv3-Agenten von Syntax, Aufbau und Funktionalität den älteren BDI- Umsetzungen überlegen. Andere Agenten-Architekturen bot JADEX nicht an und eine Eigenimplementierung wurde aufgrund des großen Implementierungsumfangs ausgeschlossen. Die Dokumentation und der User-Guide zu BDIv3-Agenten war im Gegensatz zu den Dokumenten der älteren BDI-Umsetzungen jedoch eingeschränkt, weshalb sich das Entwicklerteam mit dieser eigentlich obsoleten Dokumentation ebenfalls befasste. Viele Funktionen wurden bei der BDIv3-Umsetzung augenscheinlich von der ehemaligen XML-Syntax zu Java-Annotationen und JQL transferiert und Teile der Dokumentation blieben daher gültig. Die servicebasierte Kommunikation zwischen JADEX-Komponenten wurde im Evaluierungssprint ebenfalls anhand von Beispielprojekten getestet. Asynchronität und die diesbezüglich JADEX-eigenen Datenstrukturen stellten die größten Neuerungen für das Entwicklerteam dar. Erst mit dem Hinweis der JADEX-Entwickler, bei Serviceaufrufen für die Datenübertragung zwischen Agenten seien ausschließlich JavaBeans 5 zu verwenden, wurde Kommunikation zwischen den Agenten möglich. Trotz teilweise mangelhafter Dokumentation konnten aber alle gewünschten Funktionalitäten umgesetzt werden. Als vorteilhaft erwies sich hier vor allem, dass JADEX bereits eine große Anzahl von Testprojekten mitbringt. Am Ende des Evaluierungssprints war das Entwicklungsteam soweit mit den Grundlagen des Frameworks vertraut, dass während der folgenden Sprint-Planning-Meetings die notwendigen Design-Entscheidungen getroffen werden konnten Implementierung eingeschränkter Grundfunktionalitäten - Sprint 1 Im ersten produktiven Sprint sollte bereits ein lauffähiges System entstehen. Dafür musste der Umfang durch grobe Einschränkungen von Funktionalitäten reduziert werden. Im Gegensatz zum Evaluierungssprint fand erstmals ein Sprint-Planning statt. Nach der Beschreibung der Sprint-Activities folgen dann Sprint-Review und Sprint-Retrospektive. Zum Ende jedes Sprint-Abschnitts werden die gewonnenen Erkenntnisse aufgeführt. 5 serialisierbare Datencontainer in JAVA, die einen parameterlosen Konstruktor und öffentliche Getter/Setter-Methoden gemein haben 18

19 Sprint-Planning Bei der Benutzung des Goal-Models von Objectiver für das Product-Backlog und anschließend entsprechend für das Sprint-Backlog, ist keine Möglichkeit vorgesehen, eine Priorisierung durchzuführen. Daher handelten Product-Owner und Sprint-Team diese Parameter mündlich aus und die Gestaltung des Sprint-Backlogs erfolgte in Anwesenheit des Product-Owners. Im ersten Sprint-Meeting wurden dementsprechend aus dem bisherigen KAOS-Goal- Model des Gesamtsystems (siehe auch Anhang A.2) alle Ziele ermittelt, um das vereinbarte Sprint-Ziel zu erfüllen. Das Sprint-Ziel, ein System zu erhalten, welches bereits eine grundlegende Auftragserfüllung beherrscht, aber auf alle zusätzlichen Funktionalitäten verzichtet, wurde vorher im Gespräch zwischen Product-Owner und Sprint-Team festgesetzt. Dadurch kann beispielsweise darauf verzichtet werden, mehrere Agenten eines Typs und sich daraus ergebende Zuweisungsprobleme zu implementieren. Trotzdem wird bereits im ersten Sprint ein System erstellt, welches das Top-Goal deliver goods to complete orders erfüllen kann. Dieses Top-Goal findet daher Einzug in das Sprint-Backlog (siehe Abbildung 5). Untergeordnete Ziele decken verschiedene Aspekte ab, um einerseits dieses übergeordnete Ziel zu erfüllen, andererseits aber auch eine Darstellung für den Benutzer zu erhalten: das Ziel create jobs from orders and assign robots respectively sorgt dabei für den wichtigsten Schritt (und hat daher die höchste Priorität): Die eigentliche Auftragserfüllung durch das Liefern von Waren an die entsprechende Station. Im Sprint-Planning-Meeting wurde dieses Ziel soweit verfeinert, dass vom Product-Owner ein impliziter Ablauf vorgegeben ist und eine Zuweisung von Verantwortlichkeiten an die Agententypen vorgenommen werden kann. Dies liegt noch im Zuständigkeitsbereich des Product-Owners, während weitere Verfeinerungen der Ziele implementierungsspezifisch, und damit alleinige Zuständigkeit des Scrum-Teams liegen. Da nach der Auftragserfüllung Regale an den Stationen stehen bleiben würden, wurde ein weiteres Hauptziel ( ensure continuous workload for pack stations ) mit ins Sprint- Backlog genommen um sicherzustellen, dass die Regale von dort zurückgebracht werden. Eine Trennung vom Prozess der Auftragserfüllung erfolgt aufgrund dessen, dass Regale ja möglichst optimal und effizient platziert werden sollen, was eine funktional unabhängige Anforderung darstellt. Eine erste Anbindung an die Umgebung des Systems ist ebenfalls bereits in diesem ersten Sprint mit vorgesehen, indem das außenliegende ERP-System über eine Schnittstelle Aufträge an das System liefern kann. Um den Arbeitsaufwand für diese Schnittstelle zu begrenzen und Zuständigkeiten bei dem externen ERP-System zu belassen, werden zwei Annahmen getroffen: Ein Auftrag, der an die Schnittstelle gegeben wird, sei immer erfüllbar. Dies scheint zuerst der Vision, dass das AMHOFS vom ERP-System als Blackbox behandelt werden soll, zu widersprechen. Da aber dem ERP-System Warenaus- und -eingänge 19

20 One packstation, one shelf, one robot, shelf has all necessary items to fulfill jobs Abbildung 5: Sprint-Backlog von Sprint 1 bekannt sind und ein Auftrag im Prinzip ebenfalls lediglich einen Warenausgang darstellt, kann das ERP-System bereits vorher berechnen, ob ein Auftrag erfüllbar ist. Erst nach dieser Prüfung wird der Auftrag an das AMHOFS weitergegeben. Damit ist die Annahme konform mit den Anforderungen. Es sollen alle Waren, welche im System zirkulieren, jeweils als Einzelteile aufgefasst werden. Zwischen Stückware oder Schüttware wird also kein Unterschied gemacht. Eine Ware wird immer in einer bestimmten Anzahl angefordert und transportiert. Obwohl das ERP-System Bestandteil der Umgebung ist, soll ein simpler Dummy dafür implementiert werden, der die Schnittstelle füttert, um entsprechend Aufträge zum Testen des AMHOFSs zu haben. Die grafische Ausgabe ist ein weiteres Ziel und soll sich auf zwei Punkte beschränken: Es soll eine Repräsentation der Agenten zu verfolgen sein, aber auch alle Aufträge sollen grob verfolgbar sein, damit man den Ablauf im System nachvollziehen kann. Die Umsetzung und genaue Ausgestaltung bleibt dabei völlig dem Entwicklungsteam überlassen. Sprint-Activities Alle Arbeiten, die während des ersten Sprints durchgeführt wurden, sollen im Folgenden aufgeführt und erläutert werden. Die Strukturierung erfolgt anhand der im PosoMAS definierten Sprint-Activities, die jeweils wieder Activities oder aber mehrere Tasks enthalten. Je nach Stand und Anforderung werden mehrere oder alle Tasks einer Activity abgearbei- 20

21 tet. Dabei orientiert man sich meist an den vordefinierten Schritten 6 und Abweichungen werden erläutert. Activity: Activity: Develop System Architecture Das Entwickeln einer Systemarchitektur steht als Erstes an. Da durch das verwendete JADEX-Framework bereits viele grundlegende Dienste und Strukturen umgesetzt sind, kann damit auf einer abstrakteren Ebene begonnen werden. Task: Identify Required Supporting Infrastructure Die offensichtlichste benötigte Infrastruktur stellt das Wegenetz, auf dem sich die Roboter bewegen, dar. Das Scrum-Team entschied sich für eine Umsetzung durch miteinander vernetzte Slots, wobei jeder Slot ein BDI-Agent mit stark begrenzten Zielen und Plänen ist. Dadurch wird diese Infrastruktur integraler Bestandteil des Systems und ist in dem Sinne keine Infrastruktur mehr. Fast alle anderen Dienste werden bereits durch das JADEX-Framework bereitgestellt. So ist es für die Kommunikation nötig, dass einzelne Agenten andere Agenten finden, oder beispielsweise die Identität aller Agenten eines Typs herausfinden können. JADEX bietet hier den SServiceManager an, der genau diese Funktionalität bietet. Auch die Anforderung, eine grafische Repräsentation zu jedem Agenten zu haben, weist auf eine von allen Agenten benötigte Infrastruktur hin. JADEX bietet hier das Environment - Konzept an, für welches verschiedene Visualisierungen angeboten werden. Product-Owner und Scrum-Team entschieden sich hier für eine 2D-Darstellung in Draufsicht, mithilfe derer man die Bewegungen und Abläufe am besten verfolgen kann. Zuletzt wird auch zum Starten des Systems eine gemeinsame Institution benötigt. Um im späteren Verlauf die Startaufstellung komplett konfigurierbar machen zu können, wurde aus den verschiedenen Möglichkeiten ein JADEX-Multiagentensystem zu starten der IComponentManagementService ausgewählt. Im Gegensatz zur statischen Variante mittels XML-Konfigurationsdatei kann man Anzahl und Attribute der Agenten dynamisch, später auch durch Benutzereingabe, wählen und erhält sofort die Verweise auf die erstellten Agenten, um weitere tiefgreifende Einstellungen vorzunehmen. Task: Identify System Environment Als einziger Bestandteil der Umgebung wurde das ERP-System identifiziert. Weitere real-weltliche Konzepte, die bei einer Umsetzung, die nicht nur der softwaretechnischen Evaluierung dient, zu identifizieren wären, entfallen. Die grafische Darstellung des Systems könnte zwar als externe Komponente angesehen werden, da diese in JADEX jedoch (wie bereits erwähnt) sehr eng mit der Umsetzung des BDI-Konzepts verzahnt ist und auch in der Zukunft keine alternative grafische Darstellung vorgesehen ist, wird sie als integraler Bestandteil des Systems eingestuft. Damit existieren zwei Hauptverbindungen des AMHOFS zur Umgebung, also zum ERP-System: Es müssen Aufträge vom ERP-System an das AMHOFS gesendet werden können. Nach den Annahmen im Sprint-Backlog ist das Risiko für das AMHOFS, dass inva- 6 Alle Elemente finden sich online in der Practice Library von PosoMAS unter 21