Ein komplexes Modell
Werbung
Teil III Komplexe Modelle 1 2 Epc Simulator und Bflow Toolbox Benutzerhandbuch zur Modellierung von Epc*s mit bflow Toolbox und deren Simulation mit dem Epc Simulator Teil III komplexe Modelle Letzte Aktualisierung: 6. Juni 2013 Impressum Prof. Dr. Christian Müller Technische Fachhochschule Wildau [FH] , Germany [email protected] 3 Inhaltsverzeichnis 1 Aufgabe des Simulationsmodells ....................................................................... 6 2 Erstellung der epc-Modelle................................................................................. 7 3 2.1 „BBI.epc“.................................................................................................. 7 2.2 „flughafen.epc“......................................................................................... 8 2.3 „einreise_nat.epc“ .................................................................................. 11 2.4 „einreise_inter.epc“ ................................................................................ 14 2.5 „ausreise_nat.epc“ ................................................................................. 17 2.6 „ausreise_inter.epc“ ............................................................................... 20 2.7 kontrolle.epc .......................................................................................... 23 2.8 personkontrolle.epc ............................................................................... 26 2.9 „gepaeckkontrolle.epc“ .......................................................................... 28 2.10 „crewbereich.epc“ .................................................................................. 30 2.11 „Zoll_crew.epc“ ...................................................................................... 32 2.12 Pfade der einzelnen Process Interfaces festlegen ................................. 33 2.12.1 Process Interface im BBI.epc ...................................................... 33 2.12.2 Process Interface im flughafen.epc ............................................. 33 2.12.3 Process Interface im epc-Diagramm „einreise_nat“ .................... 34 2.12.4 Process Interface im epc-Diagramm „einreise_inter“ .................. 34 2.12.5 Process Interface im epc-Diagramm „ausreise_nat“ ................... 34 2.12.6 Process Interface im epc-Diagramm „ausreise_inter“ ................. 34 2.12.7 Process Interface im epc-Diagramm „crewbereich“ .................... 34 2.12.8 Process Interface im epc-Diagramm „kontrolle“ .......................... 34 Das komplexe Simulationsmodel mit Java-Code anreichern ........................... 35 3.1 Epc_Modellname.java ........................................................................... 35 3.2 Logic_Modellname.java ......................................................................... 35 3.3 Master_NAME.java ................................................................................ 35 3.4 Model.java ............................................................................................. 35 3.5 Rule_<Rollenbezeichnung>.java ........................................................... 35 3.6 Slave_Ressourcenbezeichnung.java ..................................................... 35 3.7 Information_<Informationsobjektname>.java ......................................... 36 4 4 5 6 7 Datenbank anlegen und für das Simulationsmodell vorbereiten ...................... 36 4.1 Datenbank installieren ........................................................................... 36 4.2 MySQL Connector ................................................................................. 37 Anlegen der eigenen Java-Klassen.................................................................. 38 5.1 Erzeugen der Klasse „DataAccessObject“............................................. 38 5.2 Erzeugen der Klasse „Gepaeck“ ............................................................ 39 5.3 Erzeugen der Klasse „Handgepaeck“ .................................................... 41 5.4 Erzeugen der Klasse „Pass“ .................................................................. 42 Codefragmente in den bestehenden Klassen integrieren ................................ 43 6.1 Codeerweiterung in der Klasse „Information_Flugdaten“....................... 43 6.2 Codeerweiterung in der Klasse „Master_Passagier“ ............................. 45 6.3 Codeerweiterung in der Klasse „Information_Fluginformation“ .............. 48 6.4 Codeerweiterung in der Klasse „Master_Crewmember“ ........................ 50 6.5 Codeerweiterung in der Klasse „BBI“ .................................................... 53 6.6 Codeerweiterung in der Klasse „Epc_einreise_inter“ ............................. 54 6.7 Codeerweiterung in der Klasse „Epc_flughafen“ ................................... 55 6.8 Codeerweiterung in der Klasse „Epc_Gepaeckkontrolle“ ...................... 56 6.9 Codeerweiterung in der Klasse „Epc_kontrolle“ ..................................... 57 6.10 Codeerweiterung in der Klasse „Epc_personkontrolle“ .......................... 58 6.11 Codeerweiterung in der Klasse „Epc_Zoll_Crew“ .................................. 58 Abbildungsverzeichnis ..................................................................................... 60 5 1 Aufgabe des Simulationsmodells Das vorliegende Simulationsmodell soll den Ablauf an einem internationalen Flughafen aus Sicht der Zollbehörde simulieren. Hierzu wird unterschieden, ob der Passagier abfliegen möchte oder von einer Reise zurückkehrt. Anschließend werden die Passagiere, die Besatzung und das Gepäck durch Zollbeamte kontrolliert. Da ein weiblicher Passagier nicht von einem männlichen Zollbeamten kontrolliert werden darf, wird dieser Fall bei der Kontrolle ebenfalls unterschieden. Sollte der Zoll bei der Kontrolle etwas finden, so wird die Ware beschlagnahmt oder die Person festgenommen. Die Kontrollen sind bei nationalen Flügen leichter, als bei internationalen Flügen. HINWEIS: Da es sich hierbei um ein Hochschul-Tutorial handelt, sind die Abläufe nicht wahrheitsgetreu, sondern fiktiv. Der erste Abschnitt dieses Tutorials befasst sich mit der Modellierung der einzelnen epc-Diagramme und deren Attributen. Im zweiten Abschnitt werden die erstellten epc-Diagramme durch eigene JavaKlassen erweitert. Außerdem werden die vorhanden Java-Klassen teilweise mit eigenem Code angereichert, um den gewünschten Ablauf zu erhalten. Um die benötigten Informationen je Passagier zu halten und ggf. auch Informationen zu speichern, wird eine MySQL Datenbank eingebunden. Wie die Datenbank in das Simulationsmodell eingebunden wird, ist ebenfalls erläutert. 6 2 Erstellung der epc-Modelle 2.1 „BBI.epc“ Zu Beginn wird ein neues epc-Diagramm im dazu vorgesehenen Ordner erstellt. Eine Anleitung zum Erstellen eines neuen Projektes, eines Ordners und das Anlegen des epc-Diagramms ist im Tutorial Teil II – „Einfache Modelle“ erklärt. Wie im Tutorial Teil II – „Einfache Modelle“ bereits erwähnt, beginnt jedes Modell mit einem Group-Element. Nach dem die Group angelegt wurde, werden die Personentypen (PersonType), die im Modell vorkommen, angelegt. In diesem Modell handelt es sich dabei um „Passagier“, „Crewmember“, „Mitarbeiter“ und „Mitarbeiterin“. Sowohl an dem Personentyp „Mitarbeiter“, als auch am Personentyp „Mitarbeiterin“ wird nun ein Participant angelegt. Durch den Participant wird nun die Person „Zollbeamter“ bzw. „Zollbeamtin“ als Ressource angelegt und diese stehen von nun an im gesamten Modell zur Verfügung. Außerdem wird an den Personentypen „Passagier“ und „Crewmember“ ein Informationsobjekt gehangen, wodurch später im Java-Code ein Informationsobjekt bereit gestellt wird, welches für jede Entity des Typs Passagier im laufenden Simulationsmodell existiert und in dem dann die verschiedenen Informationen aus diesem Objekt abgerufen werden können. Abbildung 1- BBI.epc 7 Im Anschluss wird das Modell validiert. Der Validator hat automatisch die notwendigen Attribute für jedes Element als Platzhalter hinzugefügt. Es ist nun die Aufgabe des Anwenders diese Attribute mit den gewünschten Werten zu befüllen. Abbildung 2 - BBI.epc inkl. Attribute Hinweis: Die Attribute, die in der Abbildung 2 - BBI.epc inkl. Attributemit blau umrahmt sind, sind die Attribute des Modells. Nachdem alle Attribute eingepflegt sind, muss das nachfolgende epc angelegt werden, damit das Process Interface den Pfad zum neuen epc erhalten kann. 2.2 „flughafen.epc“ Nun, da das Hauptmodell fehlerfrei ist, wird das zweite Modell mit Inhalt gefüllt. Dieses Modell beginnt wie üblich mit einem Event, welches den Eintritt und damit den Prozessfluss startet. Wie bereits im Unterpunkt „Aufgabe des Simulationsmodells“ festgehalten, soll nachdem der Passagier den Flughafen betreten hat entschieden werden, ob er zum 8 Abflugterminal oder zum Ankunftsterminal muss. Diese Entscheidung wird durch ein exklusives „Oder“ (XOR) dargestellt (siehe Tutorial II – einfache Modelle), da der Passagier entweder durch einen Flug am Airport ankommt, oder er verreisen möchte. Ist diese Entscheidung getroffen und der Passagier ist zum Beispiel im Abflugterminal eingetroffen, so sucht er sich nun das von ihm benötigte Gate aus. Hierbei gibt es die Möglichkeiten, dass es sich um einen nationalen oder um einen internationalen Flug handelt. Auch bei dieser Entscheidung handelt es sich um ein exklusives „Oder“ (XOR), da es sich lediglich um eine Art des Fluges handeln kann. Das weitere Verfahren, welches der Passagier durchlaufen muss, ist in weiteren epc´s dargestellt. Um dies deutlich zu machen, wird jeweils ein Process Interface an dem jeweiligen Event für die unterschiedlichen Gates angeheftet. Dieses Vorgehen ist analog zum Vorgehen, wenn der Passagier in das Ankunftsterminal geht. Abbildung 3 - flughafen.epc 9 Nun, da das epc-Diagramm angelegt ist, wird dieses validiert. Durch die Validierung wird auch in diesem Modell darauf hingewiesen, dass benötigte Attribute noch fehlen. Als Platzhalter wurden diese bereits vom Validator eingefügt und müssen nun durch den Anwender mit den nötigen Informationen gefüllt werden. Abbildung 4 - flughafen.epc inkl. Attribute Da wir die Entscheidung später über den Java-Code klären wollen, muss dort immer Condition und Individual angegeben werden (siehe blaue Attribute Views in Abbildung 4). Nach erneuter Validierung sollten in diesem epc-Diagramm lediglich noch die Angaben der Pfade für die vier Process Interfaces fehlen. 10 2.3 „einreise_nat.epc“ Nachdem das Flugzeug das Terminal erreicht hat, steigen die Passagiere aus dem Flugzeug aus. Parallel wird das Gepäck der Passagiere ebenfalls entladen und durch die Gepäckkontrolle geprüft. Dies geschieht in einem separaten epc-Diagramm, welches durch ein Process Interface hier eingebunden wird. Anschließend wird dem Passagier sein Gepäck ausgehändigt. Sollte das Gepäck illegale Waren enthalten haben, so wird der Passagier durch den Zoll an die Polizei übergeben. War das Gepäck in Ordnung, so kann der Passagier den Flughafen verlassen. Diese Entscheidung wird durch ein exklusives „Oder“ (XOR) dargestellt, da das Gepäck entweder illegale Waren enthält oder in Ordnung ist. Nachdem dies modelliert wurde, sollte folgendes epc-Diagramm entstanden sein. 11 Abbildung 5 - einreise_nat.epc Nachdem dieses epc-Diagramm erneut validiert wurde, müssen auch hier die Attributwerte eingepflegt werden. 12 Abbildung 6 - einreise_nat.epc inkl. Attribute Nach erneuter Validierung sollte dieses epc-Diagramm ohne Fehler sein, Ausnahme bildet hierbei wieder das Process Interface. Dieses wird später den Pfad zum nachfolgenden epc-Diagramm erhalten. 13 2.4 „einreise_inter.epc“ Der Anfang dieses epc-Diagramms ähnelt dem des epc-Diagramms „einreise_nat.epc“. Nachdem das Flugzeug am Terminal angekommen ist, steigen die Passagiere aus und parallel wird das Gepäck entladen und durch den Zoll überprüft. Nachdem die Passagiere ihr Gepäck erhalten haben, findet die Passkontrolle, durch einen Zollbeamten, statt. Bei dieser Entscheidung gibt es zwei mögliche Ausgänge, die durch ein exklusives „Oder“ (XOR) modelliert sind. Entweder, der Pass ist in Ordnung und der Besucher kann die Passkontrolle verlassen, oder der Pass ist nicht in Ordnung und der Passagier wird in Gewahrsam genommen. Sollte der Pass in Ordnung sein, so muss der Passagier sich nun entscheiden, ob er etwas zu verzollen hat, oder nicht. Entscheidet er sich für den Ausgang, dass er etwas zu verzollen hat, wird eine Kontrolle durchgeführt, welche in einem separaten epc-Diagramm abgebildet wird. Bei dieser Kontrolle gibt es ebenfalls zwei mögliche Ausgänge. Der erste mögliche Ausgang ist der, dass die Ware illegal ist und der Passagier in Gewahrsam genommen wird. Der zweite Ausgang ist, dass der Passagier nach der Kontrolle, den Flughafen verlassen darf. Diese Entscheidung ist ebenfalls durch ein exklusives „Oder“ (XOR) modelliert, da nur eines der beiden Ereignisse eintreten darf. Entscheidet sich der Passagier für den Ausgang, dass er nichts zu verzollen hat, so werden durch einen Zollbeamten per Zufall Passagiere bestimmt, die doch zur Kontrolle müssen. Da diese Kontrolle ebenfalls via Process Interface auf das gleiche kontrolle.epc-Diagramm zeigt, gibt es auch hier die bereits genannten zwei möglichen Ausgänge. Sollte der Passagier nicht durch den Zollbeamten ausgewählt worden sein, so kann er den Flughafen verlassen. Nachdem dieser Vorgang modelliert ist, sollte folgendes epc-Diagramm entstanden sein. 14 Abbildung 7 - einreise_inter.epc Nun muss das epc-Diagramm validiert werden und die eingefügten Platzhalter für die benötigten Attribute durch den Anwender ausgefüllt werden. Die nachfolgende Abbildung zeigt die einzelnen Attribut Views mit den angegebenen Werten. 15 Abbildung 8 - einreise_inter.epc inkl. Attribute Sind alle Attributwerte gesetzt, sollte eine erneute Validierung lediglich noch Fehler an den Process Interfaces melden, um die wir uns später kümmern werden (siehe 2.12 „Pfade der einzelnen Process Interfaces festlegen“). 16 2.5 „ausreise_nat.epc“ Sobald der Passagier angekommen ist, legt er sein Gepäck auf das Förderband und geht zur Sicherheitskontrolle des Zolls. Parallel läuft das Gepäck zur Gepäckkontrolle, welche sich in einem separaten epc-Diagramm befindet. Bei der Sicherheitskontrolle gibt es zwei mögliche Ereignisse, die eintreten können. Diese Entscheidung wird durch ein exklusives „Oder“ (XOR) dargestellt, da nur eins der beiden Ereignisse eintreten kann. Das erste Ereignis ist, dass der Passagier Waren mitführt, die er nicht mit ins Flugzeug nehmen darf. Tritt dieser Fall ein, so muss der Passagier diese Waren dem Zoll aushändigen und darf anschließend die Sicherheitskontrolle verlassen. Der zweite Fall besagt, dass der Passagier keine verbotenen Waren mit sich führt und direkt den Kontrollbereich verlassen darf. Anschließend wird das Gepäck an die Fluggesellschaft übergeben und der Passagier wartet auf das Bording seines Flugzeuges, bis er an Bord gehen kann. Die nachfolgende Abbildung zeigt das fertige „ausreise_nat.epc“. 17 Abbildung 9 - ausreise_nat.epc Ist das epc-Diagramm fertig modelliert, so muss es validiert werden und mit den nötigen Attributen gefüllt werden. 18 Abbildung 10 - ausreise_nat.epc inkl. Attribute Nachdem das epc-Diagramm mit allen notwendigen Attributen ausgefüllt ist, sollte eine erneute Validierung nur noch darauf hinweisen, dass das Process Interface 19 noch den Pfad zum weiterführenden epc-Diagramm benötigt. Dies wird im Abschnitt 2.12 – „Pfade der einzelnen Process Interfaces festlegen“ umgesetzt. 2.6 „ausreise_inter.epc“ Die internationale Ausreise beginnt ebenfalls damit, dass der Passagier sein Gepäck auf das Förderband legt und zur Sicherheitskontrolle geht. Bei der Sicherheitskontrolle angekommen, wird sowohl der Passagier, als auch sein Handgepäck überprüft. Die Überprüfung des Handgepäcks findet in einer Funktion statt. Die Überprüfung der Person findet in einem weiteren epc-Diagramm statt und wird hier durch ein Process Interface eingebunden. Wurde der Passagier und sein Handgepäck überprüft, stellt sich die Frage, ob er verbotene Waren dabei hat. Hat er verbotene Gegenstände dabei, so muss er diese direkt beim Zoll abgeben und darf anschließend den Kontrollbereich verlassen. Hat er keine verbotenen Gegenstände dabei, so darf er direkt den Kontrollbereich verlassen. Da jeweils nur eins der beiden Ereignisse eintreten kann, wird diese Entscheidung durch ein exklusives „Oder“ (XOR) modelliert. Parallel dazu, wird das Gepäck zur Sicherheitskontrolle gebracht und dort überprüft. Die Überprüfung findet in einem separaten epc-Diagramm statt und wird durch ein Process Interface hier eingebunden. Anschließend stellt sich die Frage, ob nun alles in Ordnung ist. Da es sich auch hierbei um eine Frage handelt, die genau eine Antwort haben darf, wird dies ebenfalls durch ein exklusives „Oder“ (XOR) modelliert. Sollte alles in Ordnung sein, so wird das Gepäck verladen und der Passagier wartet auf das Bording seines Fluges. Abschließend geht der Passagier an Bord des Flugzeuges. Sollte es doch noch Unstimmigkeiten geben, so wird weder das Gepäck des Passagiers verladen noch darf der Passagier selbst das Flugzeug betreten. Der Zoll führt in diesem Fall erneut eine Überprüfung durch und es wird anschließend entschieden, ob der Passagier (inkl. Gepäck) an Bord des Flugzeuges darf, oder ob er nicht fliegen darf. Das gesamte „ausreise_inter.epc“ ist in Abbildung 11 zusehen. 20 Abbildung 11 - ausreise_inter.epc Sobald das epc-Diagramm komplett modelliert ist, muss es validiert werden, damit die benötigten Attribute als Platzhalter eingetragen werden. Nun erfolgt das Ausfüllen der Attributwerte mit den gewünschten Angaben (siehe Abbildung 12). 21 Abbildung 12 - ausreise_inter.epc inkl. Attribute Nachdem alle Attributwerte eingetragen wurden, sollte das epc-Diagramm erneut validiert werden. Der Validator sollte wieder nur darauf hinweisen, dass die Process Interfaces noch die entsprechenden Pfade benötigen. 22 2.7 kontrolle.epc Bei der Kontrolle wird er Passagier normal vom Zoll überprüft. Findet die erste Prüfung etwas, das den Vorschriften widerspricht, so besteht die Möglichkeit, dass eine Personenkontrolle durchgeführt wird. Die Personenkontrolle ist als eigenständiges epc-Diagramm angelegt und wird somit durch ein Process Interface in diese Prozesskette integriert. Diese Überprüfung kann dann als Ergebnis haben, dass etwas gefunden wurde und der Passagier an die Polizei übergeben wird, oder dass alles in Ordnung ist und der Passagier die Kontrolle verlassen darf. Findet die erste Überprüfung nichts, kann der Passagier sofort den Kontrollbereich verlassen. Das komplette epc-Diagramm ist in Abbildung 13 zusehen. 23 Abbildung 13 - kontrolle.epc Anschließend muss auch dieses epc-Diagramm validiert werden, damit die benötigten Attribute als Platzhalter hinzugefügt werden und vom Anwender mit Werten versehen werden können. Die Werte der einzelnen Attribute ist in Abbildung 14 abgebildet. 24 Abbildung 14 - kontrolle.epc inkl. Attribute Nach erneuter Validierung sollte auch dieses epc-Diagramm nur noch den Fehler besitzen, dass das Process Interface den Pfad zum epc-Diagramm „personkontrolle“ benötigt. 25 2.8 personkontrolle.epc Zu Beginn der Personenkontrolle muss der Passagier seine Taschen leeren. Anschließend wird je nach Geschlecht die Überprüfung durch einen Zollbeamten oder durch eine Zollbeamtin durchgeführt. Die Überprüfung kann als Ergebnis haben, dass entweder der Passagier illegale Waren dabei hat, oder das er keine verbotenen Gegenstände besitzt. Das vollstände epc-Diagramm ist in Abbildung 15 dargestellt. Abbildung 15 - personkontrolle.epc Anschließend muss validiert werden, damit die Attribute eingetragen werden können. 26 Abbildung 16 - personkontrolle.epc inkl. Attribute Sind alle Attribute, wie in Abbildung 16 eingetragen, muss das epc-Diagramm erneut validiert werden. Es sollte nun fehlerfrei sein. 27 2.9 „gepaeckkontrolle.epc“ Im epc-Diagramm „Gepaeckkontrolle“ wird das Gepäck zuerst gescannt. Sollte dabei ein Verdacht entstanden sein, wird dieses Gepäckstück gesondert von einer Zollbeamtin überprüft. Diese Überprüfung bestätigt entweder den Verdacht und das Gepäckstück erhält eine Markierung oder es handelte sich um eine Fehleinschätzung und das Gepäckstück ist in Ordnung. Das komplette epc-Diagramm ist in der Abbildung 17 zusehen. Abbildung 17 - gepaeckkontrolle.epc 28 Nachdem das epc-Diagramm fertig modelliert ist, muss es validiert werden. Dadurch werden wieder die Attribute als Platzhalter eingetragen und können nun vom Anwender ausgefüllt werden. Abbildung 18 - gepaeckkontrolle.epc inkl. Attribute Sind alle Attribute ausgefüllt, wie in Abbildung 18 zusehen, muss das epc-Diagramm erneut validiert werden. Der Validator sollte nun zeigen, dass das epc-Diagramm fehlerfrei ist. 29 2.10 „crewbereich.epc“ Die Flugzeugbesatzungen werden nicht in der Prozesskette der Passagiere betrachtet, sondern in einem separaten Fall. Sobald ein Crewmitglied den Flughafen betritt, geht er in den Crewbereich. Dort überprüft er den Flugplan. Diese Überprüfung kann als Ausgang haben, dass der Flug gestrichen ist und das Crewmitglied neu eingeteilt wurde. Der zweite Ausgang dieser Überprüfung kann sein, dass das Crewmitglied zum Briefing geht und anschließend zur Zollkontrolle, damit der Flug stattfinden kann. Das komplette epcDiagramm ist in Abbildung 19 dargestellt. Abbildung 19 - crewbereich.epc 30 Nachdem das epc-Diagramm fertig modelliert ist, muss es validiert werden. Durch die Validierung werden die benötigten Attribute als Platzhalter eingefügt. Diese können nun wie in Abbildung 20 dargestellt ausgefüllt werden. Abbildung 20 - crewbereich.epc inkl. Attribute Nachdem alle Attribute eingetragen wurden, sollte das epc-Diagramm erneut validiert werden. Der Validator sollte nun nur noch darauf hinweisen, dass das Process Interface den Pfad zum nachfolgenden epc-Diagramm benötigt. 31 2.11 „Zoll_crew.epc“ In diesem epc-Diagramm wird die Sicherheitsüberprüfung der Crewmitglieder dargestellt. Hierfür überprüft ein Zollbeamter den Pass des Crewmitglieds. Ist dieser nicht in Ordnung, so wird er in Gewahrsam genommen. Ist der Pass in Ordnung, so wird im nächsten Schritt das Gepäck des Crewmitgliedes überprüft. Auch diese Überprüfung hat die beiden Ausgangmöglichkeiten, dass das Crewmitglied entweder in Gewahrsam genommen wird, oder es den Zollbereich verlassen darf. Das fertige epc-Diagramm ist in Abbildung 21 dargestellt. Abbildung 21 - Zoll_crew.epc Nach der Modellierung des epc-Diagramms, muss dieses validiert werden. Dadurch werden auch in diesem epc-Diagramm die Attribute als Platzhalter eingefügt. Diese müssen nun durch den Anwender ausgefüllt werden (siehe Abbildung 22). 32 Abbildung 22 - Zoll_crew.epc inkl. Attribute Wurden alle Attribute richtig eingepflegt, so sollte eine erneute Validierung zeigen, dass das epc-Diagramm nun fehlerfrei ist. 2.12 Pfade der einzelnen Process Interfaces festlegen Nun, da alle epc-Diagramme fertig sind, können, soweit noch nicht geschehen, alle Process Interfaces den entsprechenden Pfad zum nachfolgenden epc-Diagramm erhalten. Wie diese Pfade gesetzt werden wurde bereits im Tutorial Teil II – „Einfache Modelle“ erklärt. 2.12.1 Process Interface im BBI.epc Das Process Interface „Flughafen“ soll auf das epc-Diagramm „flughafen.epc“ zeigen. Das Process Interface „Crewbereich“ soll auf das epc-Diagramm „Crewbereich.epc“ verweisen. 2.12.2 Process Interface im flughafen.epc Das Process Interface „Ausreise national“ soll auf das epc-Diagramm „ausreise_nat.epc“ verweisen. Das Process Interface „Ausreise international“ soll auf das epc-Diagramm „ausreise_inter.epc“ zeigen. Das Process Interface „Einreise national“ soll auf das epc-Diagramm „einreise_nat.epc“ verweisen. 33 Das Process Interface „Einreise international “ soll auf das epc-Diagramm „einreise_inter.epc“ zeigen. 2.12.3 Process Interface im epc-Diagramm „einreise_nat“ Das Process Interface „Gepaeckkontrolle“ soll auf das epc-Diagramm „Gepaeckkontrolle.epc“ zeigen. 2.12.4 Process Interface im epc-Diagramm „einreise_inter“ Das Process Interface „Gepaeckkontrolle“ soll auf das epc-Diagramm „Gepaeckkontrolle.epc“ verweisen. Die Process Interfaces „kontrolle“ verweisen auf das epc-Diagramm „kontrolle.epc“. 2.12.5 Process Interface im epc-Diagramm „ausreise_nat“ Das Process Interface „Gepaeckkontrolle“ soll auf das epc-Diagramm „Gepaeckkontrolle.epc“ zeigen. 2.12.6 Process Interface im epc-Diagramm „ausreise_inter“ Das Process Interface „Gepaeckkontrolle“ soll auf das epc-Diagramm „Gepaeckkontrolle.epc“ verweisen. Die Process Interfaces „kontrolle“ verweisen auf das epc-Diagramm „kontrolle.epc“. 2.12.7 Process Interface im epc-Diagramm „crewbereich“ Das Process Interface „Zollbereich“ soll auf das epc-Diagramm „zoll_crew.epc“ zeigen. 2.12.8 Process Interface im epc-Diagramm „kontrolle“ Das Process Interface „Personkontrolle“ soll auf das epc-Diagramm „Personkontrolle.epc“ verweisen. Sind alle Process Interface mit den entsprechenden Pfaden belegt, so sollte die Validierung der einzelnen epc-Diagramme keine Fehler mehr aufweisen. Zum Abschluss muss nun das Simulationsmodell generiert werden. Hierzu wird der Generator aufgerufen. Das Simulationsmodell sollte nun als Java-Klassen im Projektbaum zu sehen sein. 34 3 Das komplexe Simulationsmodel mit Java-Code anreichern Hinweis: Für diesen Abschnitt sind Kenntnisse in der Java-Programmierung nötig! Im Kapitel 2(Erstellung der epc-Modelle) wurde ein komplexes Modell in Bflow angelegt. In diesem Kapitel soll dieses Modell nun mit Java-Klassen und Java-Code erweitert werden. Um diese Erweiterungen durchführen zu können, muss erst einmal klar sein, welche Aufgabe die erzeugten Java-Klassen übernehmen. 3.1 Epc_Modellname.java Die epc-Klassen stellen die einzelnen EPKs des Modells dar. 3.2 Logic_Modellname.java Die Logic-Klassen beinhalten die Prozesslogik, die in den EPKs hinterlegt ist. Zu beachten ist, dass an diesen Klassen keine Veränderungen durchgeführt werden! 3.3 Master_NAME.java In den Master-Klassen sind die vorhandenen Entities hinterlegt. In diesen Klassen kann die Entity durch Codeerweiterung zur Startzeit bestimmte Werte erhalten. 3.4 Model.java Die Klasse Model.java stellt das Hauptmodell dar. Diese Java-Klasse ist die ausführende Java-Klasse und startet somit die Simulation. 3.5 Rule_<Rollenbezeichnung>.java Die Rule-Klassen stellen die Ressourcen in dem Modell dar. In dieser Klasse wird die Ressource jedoch nur namentlich benannt. Die Klassen arbeiten mit den SlaveKlassen eng zusammen. 3.6 Slave_Ressourcenbezeichnung.java In den Slave-Klassen stehen die zu dieser Ressource angegeben Attribute. Sie beinhalten somit die eigentlichen Ressourceneigenschaften. 35 3.7 Information_<Informationsobjektname>.java In dieser Klasse können durch eigenen Code Informationen angelegt werden, auf die im Verlauf des Simulationsmodells Zugriff genommen werden kann. Nachdem das Simulationsmodell generiert wurde, beinhaltet diese Klasse lediglich einen Konstruktor sowie eine String Variable, welche den Namen enthält sowie eine Variable vom Typ Model, welches dem Simulationsprojekt entspricht. Beide Variablen werden im rudimentären Konstruktor befüllt. 4 Datenbank anlegen und für das Simulationsmodell vorbereiten 4.1 Datenbank installieren Im vorliegenden Projekt wird eine Datenbank genutzt, um zusätzliche Informationen sowohl bereitzustellen, als auch zu speichern. Bei der Datenbank handelt es sich um MySQL in der Version 5.1.41. MySQL Datenbanken können in den aktuellsten Versionen direkt unter http://www.mysql.de/downloads/ bezogen werden. Für das Projekt selbst wurde jedoch auf das XAMPP Paket von „apachefriends“ zurückgegriffen. Es ist unter http://www.apachefriends.org/de/xampp.html erhältlich und bietet gleichzeitig phpMyAdmin, welches ein auf PHP basierendes GUI für die MySQL Datenbank ist. Eine ausführliche Erklärung für die Installation der aktuellsten XAMPP Version findet man unter: http://www.apachefriends.org/de/xampp-windows.html#1098 Eine Installationsanleitung für die reine MySQL Datenbank ist zu finden unter: http://dev.mysql.com/doc/refman/5.1/de/windows-installation.html Achtung: Hierbei ist zu beachten, dass bei der reinen MySQL Installation, kein Administrationstool mit grafischer Oberfläche mit installiert wird. Hier wird zusätzlich ein Tool wie beispielsweise die MySQL Workbench benötigt: http://dev.mysql.com/downloads/gui-tools/5.0.html 36 Nach der Installation sollte eine Datenbank mit der Bezeichnung „bflow_flughafen“ angelegt werden und das dem Projekt beigelegt SQL File importiert werden. Anschließend sollten folgende 14 Tabellen zur Verfügung stehen: Abbildung 23 - Tabellenübersicht nach SQL File import 4.2 MySQL Connector Um eine Verbindung zwischen der Datenbank und Java zu etablieren, ist ein sogenannter JDBC- Treiber notwendig. Die jeweils aktuellste Version ist unter http://dev.mysql.com/downloads/connector/j/ erhältlich. Zur besseren Übersicht des Projektes wurde im entsprechenden Projektverzeichnis ein Unterordner „libs“ erstellt und die jar-Datei dort abgelegt. Als nächstes muss das jar-File in das Projekt eingebunden werden. Dazu wird das Projekt im Bflow Package Explorer rechts geklickt und die Eigenschaften im darauf erscheinenden Context Menü ausgewählt. Als nächstes wird der JavaBuildPath gewählt und auf Add JARs geklickt. Nun wird im Projektbaum das libs-Verzeichnis und dann die darin befindliche mysql-connector Datei ausgewählt. Ein Klick auf „OK“ bindet diese nun in das Projekt ein, so dass der Treiber in den Java Klassen zur Verfügung steht. 37 Abbildung 24 - JAR Datei importieren 5 Anlegen der eigenen Java-Klassen 5.1 Erzeugen der Klasse „DataAccessObject“ Das DataAccessObject ist ein Objekt, welches den Zugriff auf Daten in der Datenbank ermöglicht. In diesem Projekt wird eine MySQL Datenbank genutzt. Daher greift diese Klasse auf den Java-MySQL Connector(JDBC) zu. Neben den Variablen, welche für einen Zugriff auf eine Datenbank und die Authentifizierung bei dieser nötig sind, beinhaltet die DataAccessObjekt Klasse verschiedene Methoden, die das Absetzen von SQL Abfragen an die Datenbank ermöglichen sowie den Erhalt entsprechender Results. Variablen: Variable Username Password Driver Datenbank Connection Beschreibung Benutzername zur Authentifizierung Passwort zur Authentifizierung Klassenname der Treiber Klasse Name der Zieldatenbank Enthält die etablierte Verbindung zur Datenbank 38 Methoden: Methode Connect() Dissconnect() isConnected() ReturnQuery(String) RunQuery(String) getInsertID(String) Beschreibung Etabliert eine Verbindung basierend auf den Authentifizierungsveriablen Trennt die bestehende Verbindung zur Datenbank Gibt einen boolschen Wert zurück, der den Verbindungsstatus zur Datenbank widerspiegelt Liefert ein ResultSet als Ergebnis übergebenen Abfrage zurück Führt eine übergebene Abfrage aus und liefert einen boolschen Wert wieder, welcher den Erfolg oder Misserfolg der Abfrage wiederspiegelt. Liefert den Schlüssel eines Übergebenen Inserts zurück Das DataAccessObject (DAO) wird im Code selbst, in der Hauptklasse des Projektes (BBI.java) eingebunden und im Konstruktor dieser Klasse die connect() Methode aufgerufen. Von dort wird auf die Instanz des Objektes von allen anderen Klassen zugegriffen. Dies dient dazu, dass zu jeder Zeit lediglich eine Verbindung etabliert und genutzt wird. Mehrere Instanzen würden zu einem Connectiontimeout der Datenbank führen, da schnell die maximale Anzahl der Verbindungen erreicht werden würde. Natürlich kann im DataAccessObjekt auch ein beliebiger anderer JDBC Treiber genutzt werden, beispielsweiste eine PostgreS oder Oracle Database Variante. Hierzu muss lediglich die entsprechende Variable „Driver“ abgeändert werden. Hierbei ist jedoch zu beachten, dass der entsprechende Treiber zuvor korrekt eingebunden werden muss. (Vgl. 4.2) 5.2 Erzeugen der Klasse „Gepaeck“ Die Klasse „Gepaeck“ repräsentiert die Gepäckstücke, welche sowohl von den Passagieren als auch von den Crewmitgliedern durch den Zoll geführt werden. 39 Die Gepäckstücke, werden dabei zufällig aus einem Pool erzeugt. Der Gepäckpool selbst, ist eine Tabelle in der Datenbank mit der Bezeichnung „waren“. Insgesamt wird das Gepäckstück, durch 4 Variablen beschrieben. Variable Bezeichnung Verboten Wert maxMenge Bezeichnung Bezeichnung des Gepäckstücks Boolsches Flag, das anzeigt ob die Einfuhr verboten ist Monetärer Geldwert des Gepäckstücks Maximale Menge die von dieser Ware eingeführt werden darf Zu diesen Variablen, verfügt die Klasse über die jeweils entsprechenden Getter- und Setter-Methoden. Im Konstruktor dieser Klasse, werden zum Zeitpunkt der Erzeugung die einzelnen Variablen mit einem zufälligen Datensatz aus der Tabelle „waren“ befüllt: Abbildung 25 - Konstruktor der Klasse Gepaeck 40 5.3 Erzeugen der Klasse „Handgepaeck“ Die Klasse „Handgepaeck“ repräsentiert Kleinstgegenstände, welche der Passagier bei oder an sich führt und welche ebenfalls mit Restriktionen belegt sein können. Diese Klasse wird genau wie die Klasse „Gepaeck“ aus einer Datenpool-Tabelle aus der Datenbank befüllt. Die Tabelle heißt „handgepaeck“. Das Handgepäck verfügt jedoch nur über zwei beschreibende Variablen. Variable Bezeichnung verboten Beschreibung Bezeichnung des Gegenstandes Boolsches Flag, das anzeigt, ob die Mitnahme verboten ist Zu diesen Variablen verfügt die Klasse über die jeweils entsprechenden Getter- und Setter-Methoden. Im Konstruktor dieser Klasse werden zum Zeitpunkt der Erzeugung die einzelnen Variablen mit einem zufälligen Datensatz befüllt: Abbildung 26 - Konstruktor der Klasse Handgepaeck 41 5.4 Erzeugen der Klasse „Pass“ Die Klasse „Pass“ repräsentiert das Ausweisdokument von jedem Passagier oder Crewmitglied. Die Klasse verfügt dabei über zwei beschreibende Variablen. Variable passNummer Abgelaufen Beschreibung Passnummer, die das Dokument eindeutig identifiziert. Boolsches Flag, das anzeigt, ob das Dokument noch gültig ist Zusätzlich verfügt die Klasse über die entsprechenden Getter und Setter Methoden. Im Konstruktor der Klasse wird über eine random UUID eine repräsentative Passnummer generiert, sowie zufällig festgelegt, ob der Pass abgelaufen ist oder nicht. (Wahrscheinlichkeit 12:3). Abbildung 27 - Konstruktor der Klasse Pass 42 6 Codefragmente in den bestehenden Klassen integrieren ACHTUNG: Codefragmente dürfen nur innerhalb des gekennzeichneten Bereichs eingefügt werden, da sie sonst bei erneuter Generierung gelöscht werden. Codefragment 1 - Kennzeichnung für den Bereich der Codeerweiterung 6.1 Codeerweiterung in der Klasse „Information_Flugdaten“ Die Klasse „information_Flugdaten“ stellt ein zusätzliches Informationsobjekt dar, welches in die Klasse „Master_Passagier“ eingebunden ist und als Informationscontainer für diese dient. Variablenerweiterung: Variable Gepaeck Handgepaeck Einreise National Flugnummer airline Beschreibung Hierbei handelt es sich um ein ListenObjekt, welches Gepaeck-Klassen enthält und somit das Reisegepäck des Passagiers abbildet (vgl. 4.2) Hierbei handelt es sich um ein ListenObjekt, welches Handgepaeck- Klassen enthält und somit das Handgepäck des Passagiers abbildet (vgl. 4.3) Einreise Integerabbildung eines Boolsches Flags, welches signalisiert, ob es sich um einen ein- oder ausreisenden Passagier handelt Einreise Integerabbildung eines Boolsches Flags, welches signalisiert, ob es sich um einen nationalen oder internationalen Passagier handelt Zufällig generierte Stringrepräsentation der Flugnummer des Passagiers Zufällige Fluglinie aus der Datenbank für den Flug des Passagiers 43 Konstruktorerweiterung: Im Konstruktor werden zunächst die Arraylisten für das Gepäck und das Handgepäck initialisiert und anschließend mit mehreren Instanzen der jeweiligen Klassen befüllt. Anschließend wird die Flugnummer generiert und eine zufällige Fluggesellschaft aus der Datenbank abgefragt. Abbildung 28 - Konstruktorerweiterung Information_Flugdaten 44 Methodenerweiterung: Neben den Setter und Getter Methoden für die zusätzlich eingepflegten Variablen wurden drei weitere Methoden eingepflegt: Methode randBool() generateString() generateFlugnummer() Beschreibung Generiert mit Hilfe der java.util.Random Klasse eine Integerrepräsentation (0:1) eines zufälligen boolschen Wertes Generiert eine zufällige Zeichenkette mit einer Länge gemäß dem Parameter „length“ und aus dem Zeichenpool des String Parameters „characters“ generateFlugnummer greift auf die Methode generateString() zurück und übergibt dieser die gewünschte Länge und den gewünschten Zeichenvorrat Abbildung 29 - Methodenerweiterung Klasse Information_Flugdaten 6.2 Codeerweiterung in der Klasse „Master_Passagier“ Bei der „Master_Passagier“- Klasse handelt es sich um einen BFlow „PersonType“, welcher mit eigenem Java Code den Anforderungen entsprechend erweitert wurde. Zum einen wurden eigene Variablen eingeführt, zum anderen wurde der Konstruktor entsprechend modifiziert und eigene Methoden eingebunden. 45 Variablen Anpassungen: Innerhalb des individuellen Codeblocks wurden folgende Änderungen eingefügt: Variable Vorname Nachname Geschlecht Pass VORNAMEN_SQL_MAENNLICH VORNAMEN_SQL_WEIBLICH NACHNAMEN_SQL Beschreibung Der Vorname des Passagiers, welcher auch in den Logs Verwendung findet Der Nachname des Passagiers, welcher auch in den Logs Verwendung findet Boolsches Flag, welches das Geschlecht des Passagiers widerspiegelt und für die Auswahl der Vornamentabelle genutzt wird (Boolsches Flag per Integer Repräsentation == Performance Optimierung für SQL Inserts) Einbindung der Pass-Klasse, und Widerspiegelung des Ausweisdokuments des Passagiers Enthält die SQL Abfrage, um einen zufälligen männlichen Vornamen aus der Datenbank zu erhalten Enthält die SQL Abfrage, um einen zufälligen weiblichen Vornamen aus der Datenbank zu erhalten Enthält die SQL Abfrage, um einen Nachnamen aus der Datenbank zu erhalten Konstruktor Anpassungen: Im ersten Teil der Konstruktor Anpassungen, wird zunächst über die Funktion randBool() ein zufälliges Geschlecht festlegt. Als nächstes wird eine Passinstanz erzeugt. (siehe 5.4). Auf Basis des Geschlechts wird nun mit Hilfe der SQL Strings eine Abfrage an die Datenbank gestellt und die Variablen Vorname und Nachname mit den erhaltenen Werten belegt: 46 Abbildung 30 - Konstruktor Erweiterung - Teil 1 Im Zweiten Teil der Konstruktorerweiterung werden die generierten Passagierinformationen, sowie die zusätzlichen Daten aus dem Informationsobjekt „Information_Passagierdaten“ mit Hilfe der Datenbank mitgeloggt, um zusätzliche Informationen über den Programmablauf zu erhalten. Dabei wird die Tabelle „passagierlog“ genutzt, welche am Ende der Simulation eine Gesamtübersicht aller erzeugter Passagiere enthält. 47 Im nächsten Schritt wird zufällig entschieden, ob der entsprechende Passagier auf der Fahndungsliste steht, und im positiven Fall wird dies ebenfalls in der Datenbank geloggt, unter der Tabelle „Fahndung“: Abbildung 31 - Konstruktorerweiterung - Teil 2 Methodenerweiterung: Die Methodenerweiterung in dieser Klasse beschränkt sich ausschließlich auf die Setter und Getter Methoden für die zusätzlich eingepflegten Variablen. 6.3 Codeerweiterung in der Klasse „Information_Fluginformation“ Die Klasse „information_Fluginformation“ stellt ein zusätzliches Informationsobjekt dar, welches in die Klasse „Master_Crewmember“ eingebunden ist und als Informationscontainer für diese dient. Variablenerweiterung: 48 Variable Gepaeck Handgepaeck Flugnummer airline Beschreibung Hierbei handelt es sich um ein ListenObjekt, welches Gepaeck-Klassen enthält und somit das Reisegepäck das Passagiers abbildet (vgl. 4.2) Hierbei handelt es sich um ein ListenObjekt, welches Handgepaeck-Klassen enthält und somit das Handgepäck das Passagiers abbildet (vgl. 4.3) Zufällig generierte Stringrepräsentation der Flugnummer des Passagiers Zufällig Fluglinie aus der Datenbank für den Flug des Passagiers Konstruktorerweiterung: Im Konstruktor werden zunächst die Arraylisten für das Gepäck und das Handgepäck initialisiert und anschließend mit mehreren Instanzen der jeweiligen Klassen befüllt. Anschließend wird die Flugnummer generiert und eine zufällige Fluggesellschaft aus der Datenbank abgefragt. 49 Methodenerweiterung: Neben den Setter und Getter Methoden für die zusätzlich eingepflegten Variablen wurden drei weitere Methoden eingepflegt: Methode randBool() generateString() generateFlugnummer() 6.4 Beschreibung Generiert mit Hilfe der java.util.Random Klasse eine Integerrepräsentation (0:1) eines zufälligen boolschen Wertes Generiert eine zufällige Zeichenkette mit einer Länge gemäß dem Parameter „length“ und aus dem Zeichenpool des String Parameters „characters“ generateFlugnummer greift auf die Methode generateString() zurück und übergibt dieser die gewünschte Länge und den gewünschten Zeichenvorrat Codeerweiterung in der Klasse „Master_Crewmember“ Bei der Master_Crewmember Klasse handelt es sich um einen BFlow „PersonType“, welcher mit eigenem Java Code den Anforderungen entsprechend erweitert wurde. Zum einen wurden eigene Variablen eingeführt, zum anderen wurden der Konstruktor entsprechend modifiziert und eigene Methoden eingebunden. 50 Variablen Anpassungen: Innerhalb des individuellen Codeblocks wurden folgende Änderungen eingefügt: Variable Vorname Nachname Geschlecht Pass VORNAMEN_SQL_MAENNLICH VORNAMEN_SQL_WEIBLICH NACHNAMEN_SQL Beschreibung Der Vorname des Passagiers, welcher auch in den Logs Verwendung findet Der Nachname des Passagiers, welcher auch in den Logs Verwendung findet Boolsches Flag, welches das Geschlecht des Passagiers widerspiegelt, und für die Auswahl der Vornamentabelle genutzt wird (Boolsches Flag per Integer Repräsentation == Performance Optimierung für SQL Inserts) Einbindung der Pass-Klasse, und Widerspiegelung des Ausweisdokuments des Passagiers Enthält die SQL Abfrage, um einen zufälligen männlichen Vornamen aus der Datenbank zu erhalten Enthält die SQL Abfrage, um einen zufälligen weiblichen Vornamen aus der Datenbank zu erhalten Enthält die SQL Abfrage, um einen Nachnamen aus der Datenbank zu erhalten Konstruktor Anpassungen: Im ersten Teil der Konstruktor Anpassungen, wird zunächst über die Funktion randBool() ein zufälliges Geschlecht festlegt. Als nächstes wird eine Passinstanz erzeugt. (siehe 5.4). Auf Basis des Geschlechts wird nun mit Hilfe der SQL Strings eine Abfrage an die Datenbank gestellt und die Variablen Vorname und Nachname mit den erhaltenen Werten belegt: 51 Im Zweiten Teil der Konstruktorerweiterung werden die generierten Passagierinformationen, sowie die zusätzlichen Daten aus dem Informationsobjekt „Information_Crewmember“ mit Hilfe der Datenbank mitgeloggt, um zusätzliche Informationen über den Programmablauf zu erhalten. Dabei wird die Tabelle „crewlog“ genutzt, welches am Ende der Simulation eine Gesamtübersicht des gesamten erzeugten Bordpersonals enthält. Im nächsten Schritt, wird zufällig entschieden, ob der entsprechende Crewmember auf der Fahndungsliste steht, und im positiven Fall wird dies ebenfalls in der Datenbank geloggt, unter der Tabelle „Fahndung“: 52 Methodenerweiterung: Die Methodenerweiterung in dieser Klasse beschränkt sich ausschließlich auf die Setter und Getter Methoden für die zusätzlich eingepflegten Variablen. 6.5 Codeerweiterung in der Klasse „BBI“ Wie bereits im Punkt 2.1 beschrieben, handelt es sich hierbei um das Haupt-epc des Simulationsmodells. Die Hauptklasse der Simulation „BBI“ wurde um das DataAccessObject erweitert. Dies wurde zum einen als Variable eingebunden, zum anderen wurde der Konstruktor erweitert, um in die Variable eine Instanz des Objektes zu laden und über dieses eine Verbindung zur Datenbank zu etablieren. (vgl. 5.1). 53 6.6 Codeerweiterung in der Klasse „Epc_einreise_inter“ In diesem epc-Diagramm werden alle Passagiere abgefertigt, die durch einen internationalen Flug einreisen. Hierzu durchlaufen die Passagiere mehrere Kontrollen. Für weitere Erklärungen siehe 2.4 - „einreise_inter.epc“. In dieser Klasse wurde die auf die Funktion „Pässe werden kontrolliert“ folgende XOR Komponente mit eigenem Java Code erweitert, um basierend auf den vorher beschriebenen Informationsobjekten zu entscheiden, ob der aktuell kontrollierte Passagier über einen gültigen Pass verfügt und nicht auf der Fahndungsliste (Datenbanktabelle „Fahndung“) steht. Abbildung 32 – Erweiterung von XOR 129 - nachfolgend der Funktion "Pässe werden kontrolliert" Wenn der Passagier über einen abgelaufenen Pass verfügt oder auf der Fahndungsliste steht, wird er in Gewahrsam genommen. Dies wird über die Datenbanktabelle „Gewahrsam“ zusätzlich mitgeloggt (unter Angabe eines entsprechend aussagekräftigen Grundes). 54 6.7 Codeerweiterung in der Klasse „Epc_flughafen“ In diesem epc-Diagramm soll sich der Passagier entscheiden, ob er abfliegt oder angekommen ist. Anschließend steht zur Auswahl, ob es sich um einen internationalen Flug oder um einen nationalen Flug handelt (siehe 2.2). Diese Klasse wurde erweitert, um die Auswahl der korrekten Warteschlagen (national oder international und jeweils Ankunft oder Abflug) basierend auf seinen Flugdaten zu treffen. Grundlage hierfür bilden die beiden Variablen „einreise“ und „national, welche als boolsche Operatoren fungieren. Insgesamt wurden hierfür 3 XOR Elemente erweitert. Erweiterung von XOR 333 – nachfolgend der Funktion “Auswahl des Terminals”: //@@_begin of individual code for this method Master_Passagier passagier = (Master_Passagier) proc; decision_id_342_Event_Betreten_Gate_national = (passagier.getInformation_id_329_Document_Flugdaten().getNational() == 1) ? true:false; decision_id_343_Event_Betreten_Gate_international = (passagier.getInformation_id_329_Document_Flugdaten().getNational() == 0) ? true:false; //@@_end of individual code for this method Erweiterung von XOR 339 – nachfolgend der Funktion “Auswahl des Gates”: //@@_begin of individual code for this method Master_Passagier passagier = (Master_Passagier) proc; decision_id_340_Event_Betreten_Gate_national = (passagier.getInformation_id_329_Document_Flugdaten().getNational() == 1) ? true:false; decision_id_341_Event_Betreten_Gate_international = (passagier.getInformation_id_329_Document_Flugdaten().getNational() == 0) ? true:false; //@@_end of individual code for this method Erweiterung von XOR 336 – nachfolgend der Funktion “Auswahl des Gates”: //@@_begin of individual code for this method Master_Passagier passagier = (Master_Passagier) proc; decision_id_335_Event_Betreten_des_Ankunftsterminals = (passagier.getInformation_id_329_Document_Flugdaten().getEinreise() == 1) ? true:false; decision_id_334_Event_Betreten_des_Abflugterminals = (passagier.getInformation_id_329_Document_Flugdaten().getEinreise() == 0) ? true:false; //@@_end of individual code for this method 55 6.8 Codeerweiterung in der Klasse „Epc_Gepaeckkontrolle“ In diesem epc-Diagramm wird das Gepäck der Passagiere kontrolliert und ggf. markiert, damit der Passagier zum Gepäck ausfindig gemacht werden kann. Siehe auch 2.9 - „gepaeckkontrolle.epc“. In der Klasse „Epc_Gepäckkontrolle“, wurden insgesamt zwei XOR Elemente mit Java Code angereichert. Dabei handelt es sich zum einen um das zur Funktion „Gepaeck scannen“ gehörige XOR Element, sowie um das zur Funktion „Prüfung durch Zollbeamten“ gehörige. Dabei sind beide Erweiterungen sehr ähnlich. In beiden wird die Gepäck – ArrayListe im Informationsobjekt des Passagiers geprüft. Die Prüfung besteht dabei in der Zustandsermittlung des „verboten“ Flags in der Klasse Gepäck. Bei der Prüfung durch den Zollbeamten, kommt noch ein Zufallswert zum Tragen, der eine vorherige Fehleinschätzung imitieren soll. XOR Erweiterung „Gepaeck scannen“ Abbildung 33 – Erweiterung von XOR 279 – nachfolgend der Funktion „Gepaeck scannen“ XOR Erweiterung „Prüfung durch Zollbeamten“ 56 Abbildung 34 – Erweiterung von XOR 285 – nachfolgend der Funktion „Prüfung durch Zollbeamten“ 6.9 Codeerweiterung in der Klasse „Epc_kontrolle“ Im kontrolle.epc wird das Handgepäck des Passagiers kontrolliert. Hat die Suche einen verbotenen Gegenstand gefunden, so kann es später ggf. zur Personkontrolle führen. Weitere Informationen zum epc-Diagramm „kontrolle“ finden Sie unter 2.7. In der Klasse „Epc_kontrolle“ wurde das XOR Element zur Funktion „Kontrolle wird durchgeführt“ so erweitert, dass die Kontrolle von Kleinstgegenständen am Passagier abgebildet wird. Die Funktionsweise ist ähnlich wie in 6.8. Es wird lediglich auf die Klasse „Handgepaeck“ im Informationsobjekt zugegriffen. Abbildung 35 – Erweiterung von XOR 152 – nachfolgend der Funktion „Kontrolle wird durchgeführt“ 57 6.10 Codeerweiterung in der Klasse „Epc_personkontrolle“ In diesem epc-Diagramm wird der Passagier selbst überprüft, d.h. es wird kontrolliert, ob er verbotene Gegenstände in den Jackentaschen bzw. am Körper mit sich führt (siehe 2.8). Im „Epc_personkontrolle“ wird die eigene Codeerweiterung nur genutzt, um zu bestimmten, ob es sich um einen männlichen oder weiblichen Passagier handelt und entsprechend der Zollbeamte oder eine Zollbeamtin die Kontrolle vornehmen muss. Dazu wird das boolsche Flag „geschlecht“ in der Klasse „Master_Passagier“ geprüft. Abbildung 36 - Codeerweiterung Klasse Epc_personkontrolle 6.11 Codeerweiterung in der Klasse „Epc_Zoll_Crew“ In dem epc-Diagramm „Zoll_Crew“ wird jedes Crewmitglied vor Abflug überprüft. Hierzu werden die Passdaten und das Gepäck durch den Zoll kontrolliert. Siehe Abschnitt 2.11 - „Zoll_crew.epc“. In dieser Klasse wird die Zollkontrolle des Bordpersonals gesondert betrachtet. Hierzu werden die Passdaten als auch das mitgeführte Gepäck kontrolliert. (vgl. 5.2 und 5.4) Bei der Passkontrolle wird sowohl die Passnummer mit der Fahndungsliste abgeglichen, als auch geprüft, ob der jeweilige Pass noch gültig ist. Bei der Gepäckkontrolle ist wiederum das Flag „verboten“ zu prüfen. 58 Abbildung 37 - Codeerweiterung Klasse Epc_Zoll_Crew – Passkontrolle Abbildung 38 - Codeerweiterung Codeerweiterung Klasse Epc_Zoll_Crew – Gepäckkontrolle 59 7 Abbildungsverzeichnis Abbildung 1- BBI.epc ....................................................................................................... 7 Abbildung 2 - BBI.epc inkl. Attribute ................................................................................. 8 Abbildung 3 - flughafen.epc ............................................................................................. 9 Abbildung 4 - flughafen.epc inkl. Attribute ...................................................................... 10 Abbildung 5 - einreise_nat.epc ....................................................................................... 12 Abbildung 6 - einreise_nat.epc inkl. Attribute ................................................................. 13 Abbildung 7 - einreise_inter.epc ..................................................................................... 15 Abbildung 8 - einreise_inter.epc inkl. Attribute ............................................................... 16 Abbildung 9 - ausreise_nat.epc ...................................................................................... 18 Abbildung 10 - ausreise_nat.epc inkl. Attribute .............................................................. 19 Abbildung 11 - ausreise_inter.epc .................................................................................. 21 Abbildung 12 - ausreise_inter.epc inkl. Attribute ............................................................ 22 Abbildung 13 - kontrolle.epc ........................................................................................... 24 Abbildung 14 - kontrolle.epc inkl. Attribute ..................................................................... 25 Abbildung 15 - personkontrolle.epc ................................................................................ 26 Abbildung 16 - personkontrolle.epc inkl. Attribute .......................................................... 27 Abbildung 17 - gepaeckkontrolle.epc ............................................................................. 28 Abbildung 18 - gepaeckkontrolle.epc inkl. Attribute ........................................................ 29 Abbildung 19 - crewbereich.epc ..................................................................................... 30 Abbildung 20 - crewbereich.epc inkl. Attribute ............................................................... 31 Abbildung 21 - Zoll_crew.epc ......................................................................................... 32 Abbildung 22 - Zoll_crew.epc inkl. Attribute ................................................................... 33 Abbildung 23 - Tabellenübersicht nach SQL File import ................................................ 37 Abbildung 24 - JAR Datei importieren ............................................................................ 38 Abbildung 25 - Konstruktor der Klasse Gepaeck ............................................................ 40 Abbildung 26 - Konstruktor der Klasse Handgepaeck .................................................... 41 Abbildung 27 - Konstruktor der Klasse Pass .................................................................. 42 Abbildung 28 - Konstruktorerweiterung Information_Flugdaten ..................................... 44 Abbildung 29 - Methodenerweiterung Klasse Information_Flugdaten ........................... 45 Abbildung 30 - Konstruktor Erweiterung - Teil 1 ............................................................. 47 Abbildung 31 - Konstruktorerweiterung - Teil 2 .............................................................. 48 Abbildung 32 – Erweiterung von XOR 129 - nachfolgend der Funktion "Pässe werden kontrolliert" ..................................................................................................................... 54 Abbildung 33 – Erweiterung von XOR 279 – nachfolgend der Funktion „Gepaeck scannen“ ........................................................................................................................ 56 Abbildung 34 – Erweiterung von XOR 285 – nachfolgend der Funktion „Prüfung durch Zollbeamten“ .................................................................................................................. 57 Abbildung 35 – Erweiterung von XOR 152 – nachfolgend der Funktion „Kontrolle wird durchgeführt“.................................................................................................................. 57 Abbildung 36 - Codeerweiterung Klasse Epc_personkontrolle ....................................... 58 Abbildung 37 - Codeerweiterung Klasse Epc_Zoll_Crew – Passkontrolle ...................... 59 Abbildung 38 - Codeerweiterung Codeerweiterung Klasse Epc_Zoll_Crew – Gepäckkontrolle ............................................................................................................. 59 60
