Mrówki – symulacja

Mrówki – symulacja
Napisz aplikację do symulacji 2 gatunków mrówek – czarnych i czerwonych wg następujących wytycznych:
1.
2.
3.
4.
5.
6.
7.
8.
Teren symulacji to duży prostokąt. W każdym kroku czasowym symulacji mrówka może się przemieścić o co najwyżej jedno pole, na jedno z 8 sąsiednich pól.
Na symulowanym terenie znajdują się następujące elementy rozmieszczane losowo na początku symulacji:
a) mrowisko mrówek czarnych i mrowisko mrówek czerwonych;
b) obszary zawierające pokarm dla mrówek;
c) obszary zawierające przeszkody statystyczne, nie do przejścia dla mrówek (np. kałuża, pień drzewa itp.). Wszystkie mrówki, niezależnie od przynależności gatunkowej, posiadają następujące atrybuty:
a) przynależność gatunkowa;
b) poziom energii życiowej: 0­100;
c) agresywność (uzbrojenie/wielkość): 0­100.
Mrówki czarne dzielą się na:
a) robotnice: Poszukują pokarmu. Agresywność bardzo mała (możliwość zmiany w parametrach symulacji). Przebytą drogę znakują feromonem, który wietrzeje z czasem. Jeśli w niewielkim obrębie widzenia mrówki znajduje się pokarm – mrówka kieruje się jego stronę, w przeciwnym razie mrówka robi krok tam, gdzie znajduje się najmocniejszy zapach feromonowy, a jeśli w najbliższym sąsiedztwie brak takiego zapachu lub zapach tak samo intensywny na wszystkich polach sąsiednich – mrówka losuje nowy kierunek w którym pójdzie, przy czym największe prawdopodobieństwo wylosowania ma kontynuacja dotychczasowego kierunku. Jeśli mrówka trafi na pokarm to zabiera go i transportuje go z powrotem do mrowiska. Kolejne mrówki, które trafią na tą samą ścieżkę, będą pozostawiać tam feromon zapobiegając jego wywietrzeniu, dzięki czemu powinny się tworzyć coraz bardziej uczęszczane szlaki do miejsc z pokarmem. Mrówka transportująca pokarm traci stopniowo swoją energię życiową – od czasu do czasu musi więc stanąć i odpocząć by ta energia ponownie wzrosła; b) mrówki – żołnierze: Pilnują mrowiska. Agresywność duża (możliwość zmiany w parametrach symulacji). Patrolują tylko pewne otoczenie swojego mrowiska. Jeśli w niewielkim obrębie widzenia mrówki znajduje się mrówka innego gatunku to kieruje się w jej stronę.
Mrówki czerwone występują tylko w jednym rodzaju:
a) mrówki – rozbójnicy: Agresywność duża (możliwość zmiany w parametrach symulacji). Jeśli w niewielkim obrębie widzenia mrówki znajduje się pokarm (także niesiony przez mrówkę czarną) – mrówka kieruje się jego stronę, w przeciwnym razie mrówka losuje nowy kierunek w którym pójdzie, przy czym największe prawdopodobieństwo wylosowania ma kontynuacja dotychczasowego kierunku. Jeśli mrówka trafi na mrówkę innego gatunku, to dochodzi do konfrontacji (patrz pkt. ). Jeśli mrówka trafi na leżący pokarm (w tym porzucony przez mrówkę czarną po walce) to zjada go na miejscu zwiększając swoją energię życiową. Mrówce bez pokarmu stopniowo obniża się poziom energii życiowej;
Przy spotkaniu mrówek różnych gatunków dochodzi do konfrontacji zależnej od posiadanego przez nie poziomu agresji:
a) jeśli obydwie mrówki mają poziom agresji 0 – przechodzą koło siebie obojętnie;
b) jeśli przynajmniej jedna mrówka ma poziom agresji większy od zera to dochodzi do walki. Wynik walki ma zależeć od poziomu energii życiowej oraz agresji obydwu przeciwników. Przegrany ucieka ze zmniejszonym poziomem energii życiowej lub umiera.
Aplikacja powinna umożliwić:
a) wygodne ustawianie/wprowadzanie jak największej ilości parametrów symulacji np. czasu symulacji (w umownych jednostkach), poziomu agresywności i zasięgu widzenia dla poszczególnych grup mrówek w obrębie każdego gatunku, szybkości wietrzenia feromonu itp., a także archiwizację tych parametrów (zapis i odczyt z pliku);
b) czytelną i przejrzystą wizualizację przeprowadzanej symulacji z możliwością zmiany jej tempa oraz zatrzymywania w dowolnym momencie. Wizualizacja powinna nieść jak największa informację o aktualnym stanie symulacji, w szczególności powinny być widoczne wszystkie wymienione wyżej obiekty występujące w symulacji, w tym natężenie feromonu (np. im więcej tym jaśniejszy odcień koloru użytego do wizualizacji feromonu), zachodzące akcje (np. walka) oraz niezbędne liczniki (np. aktualnej ilości mrówek danego gatunku).
Całą aplikację zaprojektuj obiektowo w taki sposób, by składała się z przynajmniej 3 jak najbardziej niezależnych modułów/warstw:
a) zestaw klas opisujących obiekty symulacji np. mrówki;
b) menadżer symulacji ­ zestaw klas odpowiedzialnych za przeprowadzanie symulacji (pilnowanie przebiegu czasowego, zarządzanie obiektami symulacji i ogólnymi regułami np. przebiegiem walki mrówek itp.);
c) warstwa graficzna ­ zestaw klas odpowiedzialnych za wizualizację symulacji (odczytuje aktualny stan symulacji z menadżera i wyświetla go) oraz interfejs (komunikacja z użytkownikiem).
Dobry projekt powinien zapewniać wysoką elastyczność aplikacji tzn. możliwość modyfikacji lub wymiany poszczególnych warstw z jak najmniejszą lub bez ingerencji programistycznej w innych modułach (np. dodanie nowego gatunku mrówek powinno ograniczyć się tylko do dopisania odpowiednich klas w warstwie , bez ingerencji w pozostałych warstwach (za wyjątkiem co najwyżej niezbędnych operacji tworzenia nowych obiektów na początku symulacji czy ustawiania ich parametrów z poziomu interfejsu). 9. Dozwolone jest rozbudowywanie algorytmów poruszania się mrówek, jeśli prowadzi to do bardziej realistycznego (ciekawszego) odtwarzania zachowania się mrówek i nie powoduje ograniczenia elastyczności projektu (patrz pkt. ).
Kryt eria ocen y
L
p
Waga łąc zn
a
Kry te ri a oceny
1
20
Elastyczność ­ czy w projekcie wydzielono warstwy odpowiadające za logikę i Elastyczność interfejs aplikacji (patrz pkt. ) i jak bardzo są one niezależne ? Przykładowe pytania projektu weryfikujące elastyczność:
obiektowego  jak dużych zmian w kodzie i w jakich warstwach wymaga dodanie (tzn. jak łatwo do symulacji nowych obiektów (nowego gatunku lub nowych będzie rozwijać gatunków mrówek lub/i ich nowych podgrup w obrębie i modyfikować gatunków) ?
oprogramowani
 jak dużych zmian w kodzie i w jakich warstwach wymaga zmiana e powstałe na samego interfejsu aplikacji lub wizualizacji symulacji (np. użycie bazie projektu).
innej biblioteki graficznej) ?
20
Jakość projektu 1. Czy poprawnie zidentyfikowano i zaprojektowano wszystkie niezbędne klasy i obiekty, ich atrybuty i metody, powiązania między obiektami i ich interfejsy obiektowego i oraz przepływ informacji między nimi (współpraca obiektów) ? Waga: 4.
wykorzystane 2.
Stopień i sensowność wykorzystania:
techniki.
Opis i przykładowe s pos oby oceny/wery fikacji
2
a)
b)
c)
d)
3
40
4
10
5
5
enkapsulacji (waga: 4); dziedziczenia (waga: 4);
polimorfizmu (waga: 4);
abstrakcji (waga: 4).
Funkcjonalność Czy aplikacja posiada wszystkie żądane/wymienione w powyższej specyfikacji funkcjonalności tzn:
aplikacji
Obsługa błędów
Formatowanie kodu
a) moduł zarządzania parametrami symulacji (waga: 10);
b) zaimplementowany model symulacji wyspecyfikowany w treści zadania (wszystkie obiekty symulacji, żądane zachowania i interakcje itp.) (waga: 15);
c) wizualizację symulacji (waga: 15).
Czy zastosowano jednolity i konsekwentny sposób obsługi wszystkich możliwych błędów w całym kodzie (np. wyjątki) ?
1. Czy zastosowano czytelną, jednolitą i konsekwentną konwencję notacyjną w nazewnictwie funkcji, klas, zmiennych itp. (np. notacja węgierska, angielskie albo polskie skróty lub nazwy ale nie mieszane, nazwy czytelne, intuicyjne, oraz sugestywne itd.) ?
2. Czy duże fragmenty kodu są odpowiednio dzielone na mniejsze, autonomiczne fragmenty (funkcje, klasy, każda klasa w oddzielnych plikach itp.) ?
3. Czy kod jest odpowiednio okomentowany np. komentarze przy ważniejszych funkcjach (wejście, wyjście, krótki opis działania, obsługa sytuacji błędnych), klasach i ich składowych, strukturach danych itp., czy okomentowane są trudniejsze fragmenty kodu (np. nieoczywisty algorytm), czy komentarze nie są nadużywane tzn. czy nie komentuje się oczywistych fragmentów kodu np. i++ ?
4. Czy nie nadużywa się nadmiernej optymalizacji kodu i sztuczek programistycznych, szczególnie bez odpowiednich komentarzy, tworząc kod trudno czytelny i nierozwijalny (np. przez innych programistów) ? 5. Czy zastosowano jednolity sposób tworzenia wcięć (stała ilość spacji albo tabulacje) oraz wydzielania fragmentów kodu (np. nawiasy klamrowe otwierające w tej samej linii albo w następnej w tej samej kolumnie co zamykające itp.) ?
6
5
7
20
Czy aplikacja łatwa i intuicyjna w obsłudze nawet jeśli nie ma „help­a” ? Czy Przyjazność wizualizacja symulacja czytelna i przejrzysta tzn. czy widać co gdzie jest i co się w aplikacji, czytelność i danym momencie dzieje („legenda” na dole ekranu lub odpowiednie opisy, stale aktualizujące się liczniki pokazujące stan symulacji itp.) przejrzystość interfejsu 1. Wykorzystanie (sensowne) dodatkowych technik projektowania zwiększających Ekstra bonus
elastyczność projektu np. wzorce projektowe, programowanie abstrakcyjne itp.
2. Wykorzystanie (sensowne) dodatkowych technik programowania oraz stopień wykorzystania możliwości i mechanizmów specyficznych dla użytego do implementacji języka programowania np. wielowątkowość, szablony/typy ogólne, delegaty (C#) itp.