AKADEMIA GÓRNICZO HUTNICZA IM. STANISŁAWA STASZICA W KRAKOWIE WYDZIAŁ INFORMATYKI ELEKTRONIKI I TELEKOMUNIKACJI Projekt inżynierski Komponentowy system ewolucyjny przeznaczony do optymalizacji wielomodalnej i wielokryterialnej Marcin Zbijowski Opiekun pracy: Dr inż. Rafał Dreżewski Kraków, rok 2012
OŚWIADCZENIE AUTORA PRACY OŚWIADCZAM, ŚWIADOMY ODPOWIEDZIALNOŚCI KARNEJ ZA POŚWIADCZENIE NIEPRAWDY, ŻE NINIEJSZY PROJEKT WYKONAŁEM OSOBIŚCIE I SAMODZIELNIE W ZAKRESIE OPISANYM W DALSZEJ CZĘŚCI DOKUMENTU I ŻE NIE KORZYSTAŁEM ZE ŹRÓDEŁ INNYCH NIŻ WYMIENIONE W DALSZEJ CZĘŚCI DOKUMENTU................................. PODPIS 2
1. Cel prac i wizja produktu Problemy optymalizacyjne są problemami często spotykanymi w życiu codziennym. Mamy z nimi do czynienia w wielu dziedzinach życia, często rozwiązujemy je intuicyjnie, nie zastanawiając się nad naturą rozwiązywanego problemu. Jednak niektóre z tych problemów są bardziej złożone i znalezienie ich najlepszego rozwiązania może wymagać wykorzystania bardziej zaawansowanych metod. Przykładem takich problemów mogą być na przykład inwestycje giełdowe wybierane tak, żeby zminimalizować ryzyko, oraz uzyskać jak największy zysk. Celem projektu było stworzenie platformy umożliwiającej rozwiązywanie złożonych problemów optymalizacyjnych z użyciem algorytmów ewolucyjnych. Głównym założeniem była możliwość łatwej modyfikacji zarówno przez wprowadzanie nowych elementów, jak i przerabiając funkcjonalności już napisane. 1 Początkowo plan zakładał modyfikację istniejącej aplikacji tego typu. Modyfikowana miała być napisana w języku C# platforma nevol. Jednak szybko okazało się, że zmiany, które miały być wprowadzone, generowały problemy w kolejnych miejscach systemu. Z tego powodu zdecydowaliśmy się na stworzenie własnego dedykowanego rozwiązania, dzięki czemu można było uniknąć konieczności obchodzenia ograniczeń wynikających z założeń poprzednich autorów aplikacji. 1.1. Przewidywane cechy produktu Głównymi cechami oczekiwanymi od finalnego produktu były: 2 Możliwość rozwiązywania dowolnych zdefiniowanych problemów optymalizacyjnych, z wielowymiarową dziedziną i pod kątem dużej liczby różnych kryteriów. Interfejs graficzny pozwalający na łatwe skonfigurowanie i rozpoczęcie obliczeń, oraz przegląd wygenerowanych wyników. Modularna budowa kodu, pozwalająca na łatwą modyfikację jednego elementu, bez wpływu na resztę aplikacji. 1 Szczegółowe informacje na temat rozwiązywanego problemu można znaleźć w rozdziale 1 dokumentacji technicznej projektu Jemo załączonej do projektu. 2 Dokładniejsze informacje na temat kształtu i założeń tworzonego systemu zostały umieszczone w punkcie 2 rozdziału 1 dokumentacji technicznej. 3
1.2. Studium wykonalności i analiza ryzyka Znajomość teorii działania algorytmów ewolucyjnych wiele szczegółów niedoprecyzowanych i niejasnych. Konieczność weryfikacji niektórych pomysłów za pomocą eksperymentów. Ryzyko 8/10. Wydajność aplikacji Bardziej złożone problemy wielowymiarowe, z dużą liczbą kryteriów i dla większych populacji, mogą być rozwiązywane długo i wymagać większej ilości zasobów systemowych. Konieczność optymalizacji kodu. Ryzyko 5/10. 2. Zakres funkcjonalności 2.1. Użytkownicy systemu Można wyróżnić dwie grupy użytkowników systemu. Użytkownicy docelowi, którzy będą przeprowadzać konkretne obliczenia. Z ich punktu widzenia najważniejsza będzie wydajność kodu i przejrzystość interfejsu użytkownika. 3 Użytkownicy rozwijający system i dodający nowe funkcjonalności. Ta grupa użytkowników będzie kładła główny nacisk na łatwość dopisywania nowych elementów systemu. Dla tych użytkowników istotna będzie dokładna dokumentacja techniczna. 4 2.2. Wymagania funkcjonalne Poprawna implementacja platformy, oraz dwóch przykładowych algorytmów SPEA2 i NSGA2. Graficzny interfejs użytkownika do konfiguracji parametrów algorytmów. Wykorzystanie narzędzia gnuplot do generacji wykresów rozwiązań problemu. Zapisywanie plików z wynikami działania algorytmu na twardym dysku. 3 Z myślą o tej grupie użytkowników powstała dokumentacja użytkownika, opisująca wszystkie etapy eksploatacji systemu 4 Najważniejsze z punktu widzenia tej grupy użytkowników będzie rozdział 2 dokumentacji technicznej, który zawiera szczegółowy i pełny opis implementacji systemu, oraz punkt 3 rozdziału 3 tego dokumentu, w którym opisane zostały ważniejsze aspekty rozwijania systemu 4
2.3. Wymagania niefunkcjonalne Jakościowe: Wydajność znajdowania wyników przez algorytmy. Przejrzystość dokumentacji. Systemowe: Łatwa modyfikacja systemu. Możliwość podmiany stosowanych do obliczeń komponentów. Pozostałe: Intuicyjne API z dobrze opisanymi metodami i atrybutami składowych. 3. Wybrane aspekty realizacji 3.1. Struktura rozwiązania System składa się z trzech głównych komponentów. Najważniejszym z nich jest komponent obliczeniowy, który może również zostać wykorzystany niezależnie od reszty systemu. Pozostałe dwa komponenty, to komponent odpowiadający za generację wykresów wynikowych i komponent obsługujący interfejs użytkownika. Rys 1. Struktura komponentu obliczeniowego Powyżej zaprezentowana została ogólna struktura komponentu obliczeniowego. Każdy z wyrysowanych pakietów zawiera, co najmniej jedną klasę ogólną zawierającą wspólną 5
funkcjonalność, oraz kilka klas z przykładowymi implementacjami konkretnych elementów składowych. 5 Stworzenie komponentu obliczeniowego było głównym wyzwaniem projektu i zajęło większość czasu tworzenia systemu. 6 Komponent ten został również dokładnie przetestowany. Udało się z jego użyciem przeprowadzić także pewne eksperymenty na wybranych funkcjach celu, wyniki tych eksperymentów dały wyniki potwierdzające poprawność działania systemu. Co więcej jakość tych wyników daje podstawy do prowadzenia dalszego rozwoju aplikacji i zastosowaniu jej dla prawdziwych problemów optymalizacyjnych. Interfejs użytkownika posiada prostą strukturę, aplikacja składa się praktycznie z jednego okna, podzielonego na zakładki odpowiadające konfiguracji konkretnych elementów zawartych w komponencie obliczeniowym. 7 Komponent generacji wykresów również posiada prostą budowę. Jego zadaniem jest, jeśli to możliwe, wygenerowanie skryptu dla aplikacji gnuplot, która następnie generuje na jego podstawie wykresy wynikowe. Komponent ten jest również odpowiedzialny za zapisywanie wyników algorytmu w formie tekstowej. 3.2. Zastosowane technologie Java Do realizacji projektu, został wybrany język programowania Java. Jest to język umożliwiający łatwe rozwijanie aplikacji przez kolejnych użytkowników. Język ten został zaprojektowany z myślą o programowaniu obiektowym, co ułatwia stworzenie systemu łatwego w utrzymaniu i rozwoju. Dodatkowo, dzięki popularności języka, jest dostępna spora liczba bibliotek rozwiązujących część problemów programistycznych. Eclipse Projekt będzie tworzony z wykorzystaniem środowiska programistycznego eclipse. Posiada ono pełne wsparcie, dla wbudowanych elementów, oraz standardowych bibliotek 5 Szczegóły implementacyjne każdego z elementów systemu, łącznie z przykładowymi implementacjami elementów, zostały dokładnie zaprezentowane w rozdziale 2 dokumentacji technicznej. Wybrane aspekty implementacji zostały również pokazane w rozdziale 3 dokumentacji technicznej 6 Czas poświęcony na implementację komponentu obliczeniowego został dokładniej pokazany w dokumentacji procesowej 7 Interfejs użytkownika został dokładnie pokazany w dokumentacji użytkownika, dołączonej do projektu 6
języka Java, a dzięki mechanizmowi wtyczek, jest dostępnych wiele narzędzi przydatnych przy tworzeniu projektu, jak na przykład wtyczka subclipse, integrująca eclipse z SVN em. JUnit Biblioteka JUnit zostanie wykorzystana do stworzenia testów poprawności działania poszczególnych składników, a także całości systemu. Wybór padł na tę bibliotekę, ze względu na dużą liczbę funkcjonalności przez nią udostępnianych. Log4J Logowanie w czasie wykonania aplikacji odbędzie się z wykorzystaniem biblioteki Log4J. Jest ona stosunkowo mało obciążająca dla systemu, dlatego narzut związany z jej wykorzystaniem będzie niewielki, z drugiej strony jednak posiada spore możliwości konfiguracyjne. Gnuplot Do generowania wykresów zostało wybrane narzędzie gnuplot, ze względu na szeroki zakres jego możliwości, w tym tworzenie wykresów trójwymiarowych. 7
4. Organizacja pracy W ramach tworzenia projektu ustalone zostały cele, które chcieliśmy osiągnąć. Powstawanie produktu zostało podzielone na kilka etapów, w ramach, których prace mogły być prowadzone równolegle, a ich zakończenie oznaczało pełne zrealizowanie pewnej funkcjonalności. Większość wykonanych prac opierała się na pełnej implementacji algorytmów NSGA2 i SPEA2 i uzyskaniu dla nich zadowalających wyników. Dlatego zespół podzielił się na dwie grupy pracujące możliwie niezależnie nad każdym z algorytmów. W ramach poszczególnych podzespołów, stosowane było programowanie w parach przy jednym komputerze, zaczerpnięte z zasad programowania ekstremalnego. Dzięki tak przyjętej metodyce prac, nie potrzebne było użycie narzędzi do podziału prac nad członkami zespołu. Komunikacja pomiędzy podzespołami była minimalna i do jej celów wystarczał w zupełności kontakt za pomocą poczty elektronicznej. Natomiast w ramach podzespołów prace wykonywane były wspólnie. Wykorzystywane było jednak repozytorium SVN, do kontroli wersji projektu. 8 4.1. Podział zadań Jakub Dąbrowski: Realizacja drzewa turniejowego Pomoc przy implementacji algorytmu SPEA2 Implementacja pierwszej wersji generatora wykresów Michał Grudzień: Współpraca przy tworzeniu algorytmu NSGA2 Stworzenie prototypu interfejsu użytkownika Stworzenie mechanizmu logowania przebiegu obliczeń Implementacja niektórych składowych systemu funkcji celu i operatorów ewolucyjnych Marcin Tkacz: Implementacja algorytmu SPEA2 Stworzenie pierwszej wersji szkieletu systemu 8 Szczegóły procesu powstawania systemu zostały opisane w dokumentacji technicznej. Zawiera ona również dokładniejszy podział prac w ramach każdego etapu 8
Implementacja niektórych składowych systemu funkcji celu i operatorów ewolucyjnych Marcin Zbijowski: Implementacja niektórych składowych systemu funkcji celu i operatorów ewolucyjnych Współpraca przy implementacji algorytmu NSGA2 Implementacja interfejsu użytkownika Stworzenie drugiej wersji komponentu generacji wykresów wyników Stworzenie drugiej i trzeciej wersji szkieletu systemu Stworzenie dokumentacji technicznej, użytkownika i procesowej 5. Wyniki projektu Na końcowy wynik projektu duży wpływ miały różnice celów stawianych aplikacji przez różnych członków zespołu. Cele te często były ze sobą sprzeczne, co prowadziło do wprowadzania zmian niezgodnych z przyjętą na początku architekturą systemu. W efekcie w celu utrzymania odpowiedniej jakości i przejrzystości kodu, dwukrotnie należało przepisać najważniejsze elementy aplikacji. Pomimo tego ostatecznie udało się uzyskać program realizujący przyjęte założenia, oraz generujący ciekawe wyniki dla wybranych problemów optymalizacyjnych. Warto tutaj podkreślić, że zrealizowane zostały wszystkie główne założenia systemu, program dał dobre wyniki zarówno dla prostych jak i złożonych problemów optymalizacyjnych. Uzyskanie takiego efektu było nie tylko wyzwaniem programistycznym, wymagało również znajomości różnych elementów matematyki, a także wykazania się pomysłowością przy znajdowaniu metod poprawy wyników. Przede wszystkim jednak konieczne było przeprowadzenie dużej liczby czasochłonnych eksperymentów, co pozwoliło zaobserwować i wyeliminować niewielkie anomalie w wynikach powstałe niedoskonałości stosowanych algorytmów. na skutek Niestety nie udało się przetestować działania systemu z problemami optymalizacyjnymi występującymi w realnym świecie. W stworzonym produkcie zostało również miejsce na dalsze usprawnienia: 9 Wprowadzenie mechanizmu klastrowania i integracja z interfejsem użytkownika 9 Propozycje usprawnień zostały opisane w rozdziale 3 dokumentacji technicznej 9
Wprowadzenie mechanizmu oceny populacji po każdym kroku, co mogłoby w dalszej kolejności pozwolić na definiowanie bardziej zaawansowanych warunków stopu algorytmu Usprawnienie metody wyświetlania wykresów wynikowych za pomocą interfejsu użytkownika Implementacja kolejnych operatorów genetycznych i funkcji celu 10
6. Materiały źródłowe 1. Carlos A. Coello Coello, Gary B. Lamont, David A. Van Veldhuizen: Evolutionary Algorithms for Solving Multi Objective Problems. 2. Deb K., Goldberg D. E.: An investigation of niche and species formation in genetic function optimization, [w:] Schaffer J. D. (red.), Proceedings of the 3rd International Conference on Genetic Algorithms, str. 42 50, Morgan Kaufmann, 1989. 3. Mike Preuss, Gunter Rudolph, Feelly Tumakaka, Solving Multimodal Problems via Multiobjective Techniques with Application to Phase Equilibrium Detection. 4. Eckart Zitzler, Marco Laumanns, and Lothar Thiele SPEA2: Improving the Strength Pareto Evolutionary Algorithm. 5. Kalyanmoy Deb, Samir Agrawal, Amrit Pratap, and T Meyarivan A Fast Elitist Non Dominated Sorting Genetic Algorithm for Multi Objective Optimization: NSGA II. 6. Oracle Thread Java 2 Platform SE v1.4.2 http://docs.oracle.com/javase/1.4.2/docs/api/java/lang/thread.html 11