Architektura systemu Gra strategiczna „Strusia Jama” Krzysztof Rychlicki-Kicior Mateusz Papiernik Inżynieria Oprogramowania II Poniedziałek, 12:15 2009/2010

Cel i założenia Cel: Stworzenie internetowej turowej gry strategicznej Skalowalność gry – gra ma umożliwiać prowadzenie dowolnej ilości niezależnych rozgrywek wieloosobowych. Rozproszenie aplikacji – gracze mają mieć możliwość uczestniczenia w niej przez Internet za pomocą aplikacji klienckiej, łączącej się z serwerem – zastosowanie architektury klient-serwer Możliwość stosowania różnych źródeł danych – wyodrębnienie w architekturze serwera warstwy abstrakcji bazy danych

Wymagania Wymagania funkcjonalne: Możliwość rejestracji, logowania, pobrania listy aktualnie rozgrywanych gier Tworzenie miast, budynków, uruchamianie rakiet, wysyłanie szpiegów Prowadzenie rozgrywki przez Internet lub w sieci lokalnej Wymagania niefunkcjonalne: Niezależność od systemu operacyjnego – zarówno gra jak i serwer wykonane mają być w technologii Java zapewniając możliwość uruchomienia gry jak i serwera w dowolnym środowisku. Niezależność serwera od składnicy danych – serwer ma składować dane korzystając z niezależnego modułu, możliwego do reimplementacji w innej technologii składowania (wariant podstawowy – moduł obsługujący relacyjną bazę SQL). Niezależność funkcjonalnej części gry i serwera od protokołu – architektura ma umożliwiać modyfikację sposobu komunikacji klient-serwer, wraz ze zmianą użytego protokołu oraz sposobu transmisji komunikatów, bez konieczności ingerencji w moduł logiki gry oraz serwera. Rozszerzalność zasad gry i aspektów rozrywki – architektura gry ma umożliwiać łatwe dalsze rozbudowanie zasad rozgrywki bez konieczności ingerencji w architekturę szkieletu gry. W tym wprowadzenie nowych struktur, jednostek oraz akcji w grze wzbogacając rozgrywkę o nowe funkcje.

Diagram przypadków użycia

Diagram komponentów

Diagram wdrożeń

Baza danych

Serwer

Klient

Logika gry

Interfejs użytkownika

Model (serwer) <> Baza

Serwer <> Model (serwer)

Klient <> Serwer

Klient <> Logika gry

Logika gry <> Interfejs

Uproszczony diagram klas (struktura systemu i nazewnictwo)

Architektura a założenia Skalowalność gry – Dzięki wyodrębnieniu protokołu gry możliwe jest obsługiwanie przez serwer wielu gier jednocześnie. System komunikatów pozwala też na uczestnictwo w rozgrywce dowolnej liczby graczy (ograniczonej jedynie zasadami samej gry) Rozproszenie aplikacji – serwer gry ma być niezależny od klientów gry. Wymiana informacji między serwerem a grą zachodzić ma zgodnie z wyspecyfikowanym protokołem (wzorzec projektowy DTO), umożliwiając wymianę aplikacji gry bez konieczności ingerencji w platformę serwera. Niezależność źródła danych – dzięki wprowadzeniu warstwy abstrakcji bazy danych (wzorzec projektowy DAL, a także strategii) w architekturze serwera możliwe jest stosowanie różnych źródeł – systemów baz danych, plików XML, plików binarnych, etc. Użycie wzorca obserwatora na spojeniach komponentów systemu pozwala na łatwą rozszerzalność architektury (a co za tym idzie – możliwość rozbudowy zasad rozgrywki) poprzez zmniejszenie silnych powiązań między konkretnymi klasami. Ideę braku silnych powiązań realizuje również zastosowanie w architekturze klienta gry wzorca MVC (Model-Widok-Kontroler).