Architektura systemu Gra strategiczna „Strusia Jama”

Prezentacja na temat: "Architektura systemu Gra strategiczna „Strusia Jama”"— Zapis prezentacji:

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

2 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

3 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.

4 Diagram przypadków użycia

5 Diagram komponentów

6 Diagram wdrożeń

7 Baza danych

8 Serwer

9 Klient

10 Logika gry

11 Interfejs użytkownika

12 Model (serwer) <> Baza

13 Serwer <> Model (serwer)

14 Klient <> Serwer

15 Klient <> Logika gry

16 Logika gry <> Interfejs

17 Uproszczony diagram klas (struktura systemu i nazewnictwo)

18 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).