Licencjacka Pracownia Oprogramowania Instytut Informatyki Uniwersytetu Wrocławskiego Jakub Kowalski, Andrzej Pilarczyk, Marek Kembrowski, Bartłomiej Gałkowski Dokumentacja projektu QUAIKE Architektura oprogramowania 11 października 2009 Wersja 0.7
QUAIKE. Architektura oprogramowania Tabela 1. Historia zmian w dokumencie Lp. Data Nr wersji Autor Zmiana 1. 2009-10-05 ε Jakub Kowalski Utworzenie dokumentu 2. 2009-10-05 0.4 Jakub Kowalski Uzupełnienie dokumentu 3. 2009-10-10 0.6 Jakub Kowalski Korekta i uzupełnienie treści 4. 2009-10-11 0.7 Jakub Kowalski Korekta Spis treści 1. Wstęp............................................. 3 2. Opis elementów architektury oprogramowania.................... 3 2.1. Serwer........................................... 3 2.2. Aplikacja klienta..................................... 3 2.3. Baza danych....................................... 3 2.4. Edytor map........................................ 3 2.5. Pliki konfiguracyjne................................... 3 2.6. Pliki zawartości..................................... 4 2.7. Pliki źródłowe...................................... 4 3. Perspektywa logiczna i implementacyjna....................... 4 4. Perspektywa procesowa.................................. 4 5. Architektura a cechy projektu Quaike......................... 5 5.1. Efektywność....................................... 5 5.2. Stabilność......................................... 5 5.3. Wygoda obsługi..................................... 5 5.4. Możliwość rozwoju.................................... 5 2
1. Wstęp 1. Wstęp Dokument architektury systemu ma na celu przedstawienie wizji architektury, wraz z uzasadnieniami i uargumentowaniem słuszności przyjętych rozwiązań. Opisana architektura może ulec zmianom, zwłaszcza w fazie implementacji, jednak ogólny obraz realizacji poszczególnych jej elementów nie powinien ulec większym modyfikacjom. 2. Opis elementów architektury oprogramowania 2.1. Serwer Serwer rozgrywek umożliwia prowadzenie walk pomiędzy botami różnych użytkowników, bez ujawniania implementacji tych botów. Planowane jest stworzenie ogólnodostępnej aplikacji serwera tak, aby każdy użytkownik był w stanie w stanie ją zainstalować i zarządzać własnym serwerem. 2.2. Aplikacja klienta Aplikacja klienta służy do wizualizacji prowadzonych gier i jest aplikacją projektu z którą najczęściej będzie miał do czynienia użytkownik. Aplikacja klienta będzie umożliwiała zapisywanie i odtwarzanie powtórek z wybranych rozgrywek, a także tworzenie pojedynków bez dostępu do serwera gry. 2.3. Baza danych Baza danych znajduje się na każdym serwerze i służy do przechowywania danych niezbędnych to jego działania. Baza danych serwera zawiera informacje o użytkownikach, wyekspediowanych na serwer botach, dostępnych mapach oraz prowadzonych grach. Informacje z bazy są pobierane przez użytkowników w trakcie np. tworzenia nowej gry lub ekspediowania botów i map na serwer (lub importowania ich stamtąd). Systemem zarządzania bazą w projekcie Quaike jest SQLite. 2.4. Edytor map Edytor map jest dodatkową aplikacją, pozwalającą użytkownikowi w wygodny sposób tworzyć nowe plansze oraz oglądać i modyfikować już istniejące. Za pośrednictwem edytora jest również możliwy import map z serwera i ich eksport. 2.5. Pliki konfiguracyjne Pliki konfiguracyjne zapisywane są w formacie XML i znajdują się w nich zarówno informacje o konfiguracji interfejsu użytkownika, jak i dotyczące mechaniki i zasad działania systemu (w wersji lokalnej). Edycja plików konfiguracyjnych serwera pozwala na zmiany zasad rządzących rozgrywką. 3
QUAIKE. Architektura oprogramowania 2.6. Pliki zawartości Są to pliki zawierające dane rozszerzające możliwości programu, które mogą być dodawane lub modyfikowane przez użytkowników i udostępniane publicznie. Takimi plikami są pliki map zapisywane z rozszerzeniem.qdl, które w rzeczywistości są plikami w formacie XML, oraz kody źródłowe botów napisane w języku C#. 2.7. Pliki źródłowe Kod źródłowy projektu Quaike jest napisany w języku C#. Wybrany został on ze względu na możliwość pracy z bibliotekami środowiska XNA oraz wygodę programowania w środowisku obiektowym. Kod źródłowy jako element architektury możemy podzielić na następujące klasy abstrakcji: - kod źródłowy serwera, - kod źródłowy aplikacji klienta, - kod źródłowy edytora map, - kod źródłowy zawierający mechanikę rozgrywki, - kod źródłowy zawierający interfejs dla botów, - pliki konfiguracyjne. Pliki źródłowe pełnią krytyczną rolę w projekcie, są bowiem elementem spajającym wszystkie pozostałe elementy architektury. 3. Perspektywa logiczna i implementacyjna Wykaz elementów architektury, wraz ze spisem technik użytych do ich implementacji znajduje się w tabeli 2. Tabela 2. Elementy architektury i techniki ich implementacji Element Technika Pliki źródłowe C# Baza danych SQLite Pliki konfiguracyjne XML Pliki zawartości XML, C# Interfejs użytkownika C#, XNA 4. Perspektywa procesowa Głównym problemem procesowym będzie równoczesne uruchamianie wielu programów botów na serwerze. Tak więc wydajność projektu będzie zależała w głównej mierze od konfiguracji komputera na którym zaostanie zainstalowany serwer gry, gdyż na nim będzie wykonywana zdecydowana większość obliczeń. 4
5. Architektura a cechy projektu Quaike Serwer będzie miał również za zadanie wysyłanie dużej ilości komunikatów do aplikacji klienckich, w związku z czym będzie wymagał szybkiego łącza. Aby zminimalizować problemy z tym związane nastąpi zmniejszenie objętości przesyłanych komunikatów. Dodatkowo, możliwość tworzenia przez użytkowników własnych serwerów gry, spowoduje odciążenie głównego serwera gry. 5. Architektura a cechy projektu Quaike 5.1. Efektywność Wysyłanie przez serwer w trakcie rozgrywki jedynie informacji niezbędnych do wizualizacji znacznie zmniejsza obciążenie komputera użytkownika. Kondensacja komunikatów pomiędzy serwerem, a aplikacją klienta powoduje odciążenie łącza serwera. 5.2. Stabilność Dojrzałość języka C# ułatwia wykrywanie błędów już we wczesnej fazie implementacji. Zmniejsza to liczbę przypadków, w których program zachowa się niezgodnie z oczekiwaniami autorów. Środowisko Quaike będzie gwarantowało swoją stabilność niezależnie od zachowania uruchamianych w nim programów botów. Jako, że na ten aspekt zostanie położony szczególny nacisk, będą przeprowadzane odpowiednie testy sprawdzające działanie aplikacji w wypadku krytycznych zachowań botów. 5.3. Wygoda obsługi W konstruowaniu wszystkich aplikacji przeznaczonych dla użytkownika duży nacisk jest kładziony na wygodę obsługi i intuicyjność interfejsu. Do każdego elementu projektu dołączona jest instrukcja obsługi pozwalająca użytkownikowi w szybki sposób zapoznać się z programem i jego funkcjami. Aby wspomóc pisanie przez użytkowników własnych botów, projekt udostępnia zaawansowaną bibliotekę funkcji do wykorzystania przez boty. Biblioteka ta jest szczegółowo opisana w dołączonym do programu dokumencie. Tworzenie botów ułatwia również samouczek, który krok po kroku opisuje w jaki sposób pisać coraz lepsze programy walczące i jak je uruchamiać oraz testować w środowisku Quaike. 5.4. Możliwość rozwoju Przewidziane możliwości rozwoju programu obejmują dodanie innych trybów rozgrywek oraz rozszerzenie gry o nowe przedmioty i sposoby interakcji botów. Ale sposób realizacji projektu, a w szczególności jego modularna budowa w perspektywie pozwalają na daleko bardziej idące zmiany. W szczególności w oparciu o architekturę projektu Quaike możliwa jest implementacja wielu, zupełnie innych gier. 5