SYMULATOR MODELU PROCESÓW Piotr GIERA, Rafał KLAUS, Arkadiusz RZEKANOWSKI Streszczenie: W referacie przedstawiono założenia i koncepcję realizacji symulatora procesów zachodzących w dziekanacie. Opisano przykładowy proces związany z realizacją programu międzynarodowej wymiany studentów w oparciu o punkty ECTS. Scharakteryzowano architekturę i budowę symulatora zwracając uwagę na takie aspekty jak interfejs użytkownika, pobieranie danych studentów i danych encji oraz raporty symulacji i logi procesów. Słowa kluczowe: symulator, procesy, modele, dziekanat, JavaDoc 1. Wprowadzenie W dobie wielkich i kosztownych przedsięwzięć gospodarczych, każdy błąd popełniony na etapie projektowania procesów lub nieefektywny proces może spowodować straty. Aby uniknąć nieporozumień dobrym rozwiązaniem jest wcześniejsze zamodelowanie i przeprowadzenie symulacji procesów. Symulacja procesów gospodarczych pozwala na przyjrzenie się całemu procesowi bez konieczności jego rzeczywistego uruchamiania, co często na etapie projektowym jest bardzo kosztowne lub wręcz niemożliwe. Dodatkowym atutem jest symulowanie już istniejących procesów. W czasach szybkiego postępu technicznego, procesy starzeją się i stają się nieefektywne. Często dochodzi do sytuacji, gdzie dany proces można byłoby usprawnić, jednakże kosztowne lub niemożliwe jest monitorowanie rzeczywistego procesu. Z pomocą przychodzą komputerowe symulatory, które umożliwiają spojrzenie na całość procesu, wykrycie wąskich gardeł i momentów krytycznych dla całego systemu. W artykule rozważą się przykładowe zastosowanie symulatorowa do badania procesów zachodzących w dziekanacie. W przypadku dziekanatu rzeczywiste uruchomienie całości procesu dla celów badania efektywności jest niemożliwe, ze względu na czasochłonność, zaangażowanie w proces wielu nie powiązanych ze sobą osób i liczbę czynności zachodzących podczas jednego procesu. Symulator ma ułatwić prowadzenie badań na tego typu procesach. 2. Koncepcja rozwiązania Aby rozwiązać problem symulacji procesów zachodzących w dziekanacie uczelni wyższej należy spojrzeć na proces jako na system działający w określony sposób pod wpływem podanych parametrów. Podstawowym pojęciem w takim systemie jest encja. Pojęcie to definiuję się jako reprezentacje pewnego obiektu obecnego w procesie (systemie), przyjmującego pewne dane wejściowe i komunikującego się z innymi obiektami procesu. Encja może reprezentować każdą cześć systemu, zarówno stanowisko, osobę biorącą udział w procesie jak i np. konkretny dokument. Wymiana informacji pomiędzy encjami odbywa się za pomocą pewnych kanałów komunikacji, w których przekazywane są informacje odnośnie zdarzeń zaistniałych w systemie. Komunikat
wymieniany pomiędzy encjami może zawierać zarówno informacje o zaistniałym zdarzeniu jak i przekazywać pewne dane (np. dane studenta który zdarzenie zainicjował). Kanały komunikacji zdefiniowane pomiędzy encjami umożliwiają wymianę komunikatów w obu kierunkach i są zdefiniowane jednoznacznie. Oznacza to, iż każdy kanał posiada ściśle określoną encję początkową i końcową, przez co wymiana informacji w danym kanale odbywać się może tylko pomiędzy dwoma encjami zdefiniowanymi jako wejście i wyjście kanału. Każda encja odpowiadająca zdarzeniom powinna symulować zdarzenie poprzez wymianę informacji i danych z innymi encjami, podejmowanie pewnych decyzji na podstawie tych danych i przesyłanie informacji o decyzjach do innych encji. Encja powinna również odzwierciedlać estymowany, sumaryczny czas potrzebny do wykonania symulowanego procesu. W przyjętej koncepcji rozwiązania, każdy proces składa się ze zdefiniowanego zbioru encji, których kanały komunikacji są ściśle określone. Konfiguracja encji odbywa się poprzez zdefiniowanie jej czasów przetwarzania, liczebności zasobów reprezentowanych przez encję oraz sposobu dalszej komunikacji z encjami. Symulacja każdego procesu powinna generować raport opisujący jej przebieg, aby możliwe było ustalanie zależności pomiędzy parametrami wejściowymi, a zachowaniem poszczególnych encji oraz wyjściowymi parametrami symulacji. Oprócz raportu powinna istnieć informacja o zdarzeniach występujących podczas symulacji, aby możliwe było prześledzenie całego procesu przebiegu danej informacji w systemie. Informacje takie można nazwać systemem logów procesu. Projektowany symulator odzwierciedla specyfikę komunikacji oraz wymiany informacji w rzeczywistych procesach dziekanatu, nie jest natomiast implementacją matematycznych modeli tych procesów. Powyższa koncepcja została zrealizowana z użyciem biblioteki SimJava [1,2,3,4,5]. Biblioteka ta jest zbiorem klas i metod napisanych w języku Java rozwijanych i rozpowszechnianych przez Uniwersytet w Edynburgu. Służy ona do definiowania i uruchamiania symulacji zorientowanych procesowo. Każdy system (symulacja) postrzegany jest jako zbiór procesów (podprocesów), encji oraz kanałów komunikacji. Biblioteka SimJava implementuje system symulacji oparty na encjach i komunikacji pomiędzy nimi. Poprzez rozdzielenie symulacji na zbiór encji i ich kontroler, możliwe jest prowadzenie stałej kontroli nad procesem i encjami, a w szczególności nad zbieraniem informacji odnośnie prowadzonej symulacji. Biblioteka udostępnia również możliwość generowania szczegółowych raportów odnośnie symulacji, jak i interfejs graficznej reprezentacji symulacji. Ważną cechą zawartą w bibliotece jest możliwość definicji wyników raportu pod kątem wyników optymalizacyjnych bądź symulacyjnych. 3. Przykładowy proces Przykładowym procesem na bazie którego zostanie przeprowadzona analiza symulatora będzie program ECTS. Program ECTS pozwala określić zasady odbywania studiów za granicą i wymagania konieczne do ich zaliczenia. System daje możliwość porównania programów nauczania, a także ułatwia formalny transfer osiągnięć studenta w nauce z jednej instytucji do drugiej. Jest to możliwe dzięki zastosowaniu punktów ECTS oraz wspólnej skali ocen. Kluczową rolę w systemie ECTS pełnią trzy dokumenty: Pakiet informacyjny zawiera ogólne informacje na temat uczelni przyjmującej, kalendarza akademickiego, procedur administracyjnych oraz szczegółowy opis programu studiów i dostępnych zajęć na jednym lub kilku kierunkach studiów.
Porozumienie o programie zajęć to rodzaj kontraktu pomiędzy studentem, a współpracującymi uczelniami (wysyłającą i przyjmującą). Wykaz zaliczeń opisuje osiągnięcia studenta w nauce przed i po okresie studiów za granicą. Podstawowym problemem występującym podczas symulacji tego procesu jest trzykrotne wystąpienie encji reprezentującej studenta, w rzeczywistości będącego jednym bytem. Problem ten może zostać rozwiązany na dwa sposoby. Pierwszy z niech opiera się na połączeniu wszystkich wystąpień studenta w jedną encję i podzielenie jej sposobu działania na części składowe uruchamiane tyko w przypadku otrzymania odpowiednich komunikatów. Ten sposób solucji problemu jest bliższy rzeczywistemu procesowi. Drugi sposób rozwiązania problemu prowadzi do stworzenia trzech osobnych encji reprezentujących studenta, jednakże pobierających identyczne parametry. Każda encja parametryzowana jest tymi samymi danymi jednakże sposób jej zachowania jest różny. Rozwiązanie to jest bliższe rzeczywistości z punktu widzenia realistyczności zachowań encji w procesie. Rozwiązanie przyjęte w symulatorze jest odpowiednikiem pierwszego sposobu rozwiązania problemu. Opis kroków procesu: Start inicjalizacja procesu Rys.1. Model procesu ECTS
Student chce pobrać pakiet informacyjny ECTS Pobranie pakietu informacyjnego przez studenta Przygotowanie planu programu studiów Skorzystanie z pomocy koordynatora studenta przy tworzeniu porozumienia o programie zajęć. Przygotowanie niezbędnych dokumentów ECTS przez studenta Formularz zgłoszeniowy Lista zaliczeń Porozumienie o programie zajęć Całość dokumentów tworzy wniosek studenta. Dostarczenie wniosku studenta do dziekanatu Analiza wniosku przy wykorzystaniu koordynatora ECTS uczelni przyjmującej Przyjęcie bądź odrzucenie wniosku. 4. Architektura Architektura symulatora zawiera zarówno elementy wspólne jak i specyficzne dla każdego procesu. Do elementów wspólnych wszystkich modułów należą klasy zapewniające następujące funkcjonalność: pobieranie i tworzenie instancji studentów biorących udział w procesach, wczytywanie danych wejściowych procesów, obliczanie czasów pracy encji na podstawie przekazanych parametrów, zapis logów w pliku tekstowym, zbieranie statystyk odnośnie danych wejściowych. Wspólny pozostaje również silnik wizualizacyjny dostarczony rzez bibliotekę SimJava. Dla każdego procesu różni się on jedynie reprezentacją graficzną modelu. Interfejs użytkownika w głównej części okna zawiera graficzna reprezentacja procesu, zawierająca wizualizację encji oraz kanałów komunikacyjnych. Przy każdej encji znajduje się parametr w postaci cyfry, reprezentującej liczbę zasobów danej encji, pobieraną bezpośrednio z pliku z parametrami procesu. Dolna część aplikacji dostarczana jest automatycznie przez bibliotekę SimJava i zawiera przyciski służące do uruchamiania, zatrzymywania i kontroli szybkości przebiegu symulacji. Dwa okienka docelowo tekstowe wyświetlają informacje na temat przebiegu symulacji oraz raport. Pole tekstowe z raportem symulacji wypełniane jest danymi dopiero po zakończeniu symulacji. Każda wizualizacja procesów zawiera również parametry określające aktualny stan podjętych decyzji. Dane o studentach biorących udział w procesach umieszczone zostały w pliku tekstowym, którego domyślna nazwa to students.sim. Struktura pliku wejściowego opisującego studenta została stworzona w taki sposób, aby można w miarą potrzeby rozbudować plik o dodatkowe dane nie powodując znacznych zmian w strukturze aplikacji. Istniejąca lista parametrów powstała na podstawie zapotrzebowania na informacje przez poszczególne procesy. Każdy proces ma dostęp do wszystkich informacji o studencie jednakże wykorzystuje tylko niezbędne dla siebie parametry. Dodanie nowych parametrów jest intuicyjne oraz w sposób przejrzysty i klarowny identyfikuje studenta. Powyższy wiersz opisuje studenta który charakteryzuje się następującymi cechami:
Identyfikuje się nazwę: Student9 Posiada średnią ocen 4.1 Nie posiada rodzeństwa starszego niż 26 lat Miesięczny dochód netto na osobę w rodzinie tego studenta to 900 (zł) Odległość miejsca zamieszkania studenta od uczelni to 540 (km) Frekwencja studenta na zajęciach : 80 % Udokumentowany koszt wynajmu lokalu to 500 (zł) Student nie posiada orzeczenia o niepełnosprawności Rys.2. Widok interfejsu użytkownika Każda encja procesu jest parametryzowana poprzez dane umieszczone w pliku tekstowym, który przy starcie procesu jest parsowany. Na podstawie danych zawartych w pliku klasa główna procesu (kontroler procesu), tworzy obiekty odpowiadające encjom. Składnia wiersza z pliku z parametrami procesu reprezentujący dane dla jednej encji przedstawia się następująco:
Nazwa encji jest jej unikalnym identyfikatorem używanym w procesie. Nazwa encji powinna zawsze być zgodna z nazwami encji tworzonymi przez symulator zapisanymi w kodzie źródłowym aplikacji. Niezgodność nazw spowoduje niezdefiniowanie parametrów danej encji, a tym samym przyjęcie domyślnych parametrów równych 0. Czas przetwarzania encji jest ustalanym przez użytkownika szacowanym czasem, odpowiadającym czasowi poświęconemu na zdarzenie w systemie rzeczywistym. Czasy w pliku tekstowym podane są jako liczba milisekund przez która dana encja będzie symulować wykonywanie konkretnego zadania. Liczba zasobów jest liczbą określającą liczbę zasobów danej encji w symulowanym procesie. Oznacza np. liczbę osób zajmujących się analizą podań studentów. Przykładowo we fragmencie rzeczywistego procesu w którym student korzysta z pomocy koordynatora studenta, a czas poświęcony przez koordynatora równy jest 4 jednostkom oraz dla studentów dostępnych jest trzech koordynatorów, jest opisywany jako następujący wiersz w pliku z parametrami : Parametry encji o nazwie koordynator_studenta, której czas pracy to 4000 ms, oraz definiuje liczbę dostępnych koordynatorów jako trzy. Czas podawany dowolnej jednostce ma znaczenie symboliczne jednakże traktowany jest jako liczba milisekund przez moduł wizualizacyjny, który zaznaczy i zaloguje podczas wyświetlania realizacji procesu czas pracy encji jako 4000 milisekund. Rozwiązanie takie posiada wielką zaletę w postaci dokładnego odwzorowywania stosunków czasów pracy poszczególnych encji, i jednocześnie wpływa na polepszenie realistyczności symulacji procesów, udostępniając możliwość dokładnego definicji czasów pracy poszczególnych encji w zależności od przyjętej przez użytkownika jednostki. Symulator nie narzuca żądnych ograniczeń na jednostki w których zapisane są czasy pracy encji jednakże podczas wizualizacji zawsze traktuje je jako milisekundy, co pozwala na szybkie działanie symulatora, który pozwala symulacje procesu który trwa wiele dni zakończyć w kilka minut, zachowując duży poziom realistyczności. W przypadku niektórych encji zachodzi potrzeba zdefiniowania czasu pracy oraz liczebności dla różnych okresów pracy danej encji. Dlatego w specyficznych przypadkach w plikach wejściowych za pomocą więcej niż jednego wiersza można parametryzować pojedynczą encję. Powyższy zapis reprezentuje definicje parametrów encji, która zostanie wykorzystana w procesie dwa razy, przyjmując za każdym razem inny czas pracy i liczebność. Każdy symulowany proces tworzy raport z przeprowadzonej symulacji. Raport zawiera informacje zarówno odnośnie całości symulacji jak i statystyk poszczególnych encji. Budowanie raportu oparte jest na możliwościach biblioteki SimJava. W szczególności raport symulacji zawiera następujące informacje odnośnie całości symulacji: datę przeprowadzenia symulacji, czas rozpoczęcia symulacji, czas zakończenia symulacji, wersję biblioteki SimJava,
całkowity czas symulacji, warunki zakończenia symulacji. Raport dla poszczególnych encji zawiera: Nazwę encji średni czas oczekiwania, maksymalny czas oczekiwania, minimalny czas oczekiwania, średnią długość kolejki dla danej encji, maksymalną długość kolejki dla danej encji, minimalna długość kolejki dla danej encji, liczbę zdarzeń obsłużonych przez encję. Każdy proces symulowany przez aplikacje tworzy również zestaw logów zapisywany w pliku tekstowym, aby można było prześledzić przebieg działania procesu. Format pliku z logami procesu opiera się na zapisaniu informacji o każdym zdarzeniu w jako pojedynczej jednostki, która w zestawieniu z innymi informacjami daje możliwość śledzenia każdego kroku symulowanego procesu. W miejscach podejmowania przez
symulator decyzji zostają również wypisane parametry studenta, którego decyzja dotyczy. Format informacji zapisanej w pliku jest następujący: Przykład zanotowanie informacji o podjęciu decyzji: 5. Uwagi końcowe Stworzoną aplikacje jest prototypem, który odpowiednio rozwijany udoskonalany może stać się użytecznym narzędziem wykorzystywanym do usprawniania pracy dziekanatu. Wizualizacja pozwala na prezentacje dokonanych symulacji w sposób zrozumiały dla osób nie posiadających wiedzy o symulacji procesów gospodarczych. Zestaw raportów i logów pozwala na dokładne prześledzenie przebiegu wykonywanych procesów, ich zachowań i statystyk poszczególnych encji. Literatura 1. Code Conventions for the Java Programming Language.http://java.sun.com/docs/codeconv/html/CodeConvT OC.doc.html. 2. Eclipse Home Page. http://www.eclipse.org. 3. GNU General Public License, http://www.gnu.org/copyleft/gpl.html 4. Oficjalna Strona Języka Java. http://java.sun.com. 5. SimJava Home Page, http://www.icsa.inf.ed.ac.uk/research/groups/hase/simjava/ dr inż. Rafał Klaus mgr inż. Piotr Giera mgr inż. Arkadiusz Rzekanowski Instytut Informatyki Politechnika Poznańska 60-965 Poznań ul. Piotrowo 3a Wyższa Informatyczna Szkoła Zawodowa w Gorzowie Wlkp. 66-400 Gorzów Wlkp. ul. Myśliborska 34 tel. (0-95) 733-66-22 http://wisz.edu.pl e-mail: rafal.klaus@cs.put.poznan.pl