Koszalin, 21.05.2011 r. Dokument Detaliczny Projektu Temat: Gra karciana Makao Colakao Zespół projektowy: Mateusz Radziuk Maciej Madaj Łukasz Młynik Bartłomiej Machnik Prowadzący: Dr inż. Walery Susłow
Streszczenie Niniejszy dokument detaliczny projektu (DDP) opisuje detale pracy zespołu projektowego, który skupia się na stworzeniu gry karcianej Makao-Colakao opartej na architekturze klient-serwer. Pierwsza częśd dokumentu zawiera wstęp opisujący ogólne założenia projektowe, a także wykorzystywane standardy i konwencje. Druga częśd opisuje specyfikacje poszczególnych komponentów. Wszystkie zmiany w dokumencie odnotowane będą w historii wersji (zmieszczona poniżej). Historia dokumentu Wersja Opis modyfikacji Autor modyfikacji Data 1.0 Wersja początkowa Mateusz Radziuk 21.05.2011 1.1 Aktualizacja specyfikacji komponentów Mateusz Radziuk 25.05.2011
Spis treści 1. Opis ogólny...4 1.1 Wstęp...4 1.1.1 Cel...4 1.1.2 Zakres...4 1.1.3 Definicje...4 1.1.4 Odsyłacze...5 1.1.5 Omówienie...5 1.2 Standardy projektu, konwencje, procedury...5 1.2.1 Standardy projektowe...5 1.2.2 Standardy dokumentacyjne...5 1.2.3 Konwencje nazewnicze...6 1.2.4 Standardy programistyczne...6 1.2.5 Narzędzia...6 2. Specyfikacja komponentów...7 2.1 Card...7 2.2 Dealer...7 2.3 Player...7 2.4 DrawTable...7 2.5 Util...7 2.6 NetworkAdapters...7 2.7 MouseAdapters...7 2.8 MainMenu...8 2.9 Main...8 2.10 Label...8 2.11 DrawTransformation...8 3. Załączniki...8 3.1 Harmonogram prac (diagram Gantta)...8 3.2 Diagram klas...9 3.3 Diagram klas konceptualnych... 10 3.4 Diagram przypadków użycia... 10 3.5 Diagram czynności... 11 3.6 Interfejs aplikacji... 12
1. Opis ogólny 1.1 Wstęp 1.1.1 Cel Niniejszy dokument ma za zadanie sprecyzowad sposób realizowanych prac. Określid założenia projektu, standardy, narzędzia i komponenty wchodzące w skład implementacji, oraz opis realizacji tych komponentów. 1.1.2 Zakres Założeniem projektu Gra karciana Makao Colakao jest stworzenie w pełni funkcjonalnej gry w karty Makao. Aplikacja ma za zadanie udostępnid osobą lubiącym ten rodzaj rozrywki funkcjonalną oraz wygodną aplikację do gry przez sied z innymi ludźmi, a także zachęcid nowych graczy. Aplikacja będzie wykorzystywała architekturę klient-serwer. Użytkownik ma do wyboru: może hostowad grę (utworzyd serwer) albo podłączyd się do serwera innego gracza. 1.1.3 Definicje Gra w tym przypadku odnosimy się do Makao gry karcianej (na zachodzie znanej jako Mau-Mau). Karty papierowe lub plastikowe przybory do gry w Makao Talia zestaw kart do gry. Zawiera 52 prostokątne karty w 4 kolorach: trefl(żołądź), karo(dzwonek), kier(czerwieo), pik(wino). W skład talii wchodzą także 3 Jokery. Joker karta, która może zastąpid każdą inną kartę. Reguły zasady określające sposób postępowania w grze. Gracz uczestnik gry. Ruch czynnośd jaką gracz wykonuje podczas gry, np.: pobranie karty, rzucenie karty. Kara konsekwencja jaką należy ponieśd w przypadku nie wykonania określonego ruchu. Karą może byd pauzowanie kolejki lub wyciągnięcie określonej ilości kart. Kara pauzowania może wystąpid tylko po rzuceniu "czwórki na stół. Kara może zostad ominięta jedynie poprzez położenie kolejnej czwórki. To jedyna kara podczas której gracz nie może wykonad żadnego ruchu. Kara trwa tyle rund, ile zostało położonych czwórek na stół. Kara wyciągnięcia kart gdy na stole zostanie położona 2,3 lub Król kier następny gracz musi wyciągnąd określoną liczbę kart z talii. Jeżeli
jest to Król gracze muszą wziąd 5 kart, jeżeli 2 2 karty I tak dalej. Jeżeli jest to Król pik poprzedni gracz musi wziąd 5 kart. Gracz może wziąd jedną kartę z talii i jeżeli kolor/figura pasuje rzucid ją na stół. Żądanie ruch 1 gracza wymuszający na 2 graczu rzucenie na stół określonej karty, pod groźbą kary. Występują dwa rodzaje żądad koloru lub figury. Żądanie figury może wystąpid tylko po rzuceniu Waleta na stół. Żądanie trwa przez jedną rundę lub do zmiany żądania na inną figurę. Gracz może wyciągnąd kartę z wolnych i jeżeli pasuje ona do żądanej figury lub figury Waleta może ją rzucid na stół. Żądanie koloru może wystąpid tylko po rzuceniu Asa na stół. Żądanie trwa dopóki żądany kolor nie jest położony lub do zmiany żądania na inny kolor. Gracz może wyciągnąd kartę z wolnych i jeżeli pasuje ona do żądanego koloru lub figury może ją rzucid na stół. 1.1.4 Odsyłacze -Zasady gry w Makao 1.1.5 Omówienie Dokument ten powstał na bazie Specyfikacji wymagao systemowych. Zawiera on definicje standardów, strategii i konwencji które będą przestrzegane podczas realizacji projektu. Dalsza częśd dokumentu zawiera informacje o modułach i komponentach systemu i interfejsie graficznym aplikacji. 1.2 Standardy projektu, konwencje, procedury 1.2.1 Standardy projektowe Podczas tworzenia projektu wykorzystamy model przyrostowy tworzenia oprogramowania. Wybraliśmy go, ze względu na jego zalety: -Klienci nie muszą czekad na dostarczenie całego systemu, zanim zaczną czerpad z niego korzyśd. -Klienci mogą używad wstępnych przyrostów jako rodzaju prototypu i zdobywad doświadczenia, które inspirują wymagania wobec późniejszych przyrostów. -Ryzyko całkowitej porażki przedsięwzięcia jest mniejsze. -Usługi o najwyższym priorytecie będą dostarczane jako pierwsze. -Łatwośd powrotu do prawidłowo działającej wersji programu w przypadku błędów; 1.2.2 Standardy dokumentacyjne
Wszystkie dokumenty będą utworzone na podstawie jednego szablonu. W miarę możliwości (ze względu na ich czytelnośd i łatwośd w zrozumieniu) będą tworzone diagramy przedstawiające dane zagadnienie. Przy programowaniu w języku Java będziemy stosowad komentarze w stylu JavaDoc, co umożliwi proste wygenerowanie czytelnej dokumentacji kodu źródłowego aplikacji. 1.2.3 Konwencje nazewnicze Nazewnictwo zastosowane w projekcie będzie ukierunkowane na jednoznacznośd i prostotę. Zarówno komponenty, jak i poszczególne funkcje będą nazywane w ten sposób by można było jednoznacznie odczytad cel danej funkcji czy komponentu. Wersje dokumentów będą oznaczane w następujący sposób: nazwa_dokumentu_vx, gdzie X to numer wersji (inkrementowany począwszy od numeru 1). 1.2.4 Standardy programistyczne W projekcie będzie wykorzystane podejście obiektowe do programowania. Możemy wyróżnid obiekty: karta, gracz, diler, stół itp. Podejście to odzwierciedla rzeczywistośd, co ułatwia pisanie oraz zrozumienie kodu aplikacji. Ułatwia to również poprawianie oraz zwiększanie funkcjonalności wystarczy, że zmienimy dany komponent(obiekt). 1.2.5 Narzędzia Do realizacji projektu będzie użyty język Java, z uwagi na najlepszą multiplatformowośd. Będziemy korzystad ze środowiska RAD(Rapid Application Development) w postaci NetBeans-a. Podczas tworzenia dokumentacji, będą wykorzystywane m.in. programy: -StarUml program do tworzenia diagramów UML, -FreeMind tworzenie map myśli, -Microsoft Office pakiet oprogramowania wykorzystywany przy tworzeniu dokumentacji, -GanttProject program do tworzenia harmonogramów Podczas projektowania będziemy korzystad z repozytorium online - http://code.google.com/p/colakao-pk-2011 oraz plugina Subversion dostępnego w NetBeansie umożliwiającego dostęp do systemu kontroli wersji SVN z poziomu aplikacji.
2. Specyfikacja komponentów 2.1 Card Definiuje obiekt rzeczywisty jakim jest karta oraz jej zmienne i funkcje. Zawiera m.in. takie właściwości jak: kolor karty, jej rangę, informację czy była przekształcona z jokera, karę karty oraz jej wygląd (który można zmienid w menu). Klasa karty zawiera konstruktory tworzące karty o określonych parametrach (ranga, kolor, wygląd), a także tworzący kartę na podstawie utworzonej wcześniej. Dostępne są również metody ustawiające właściwości karty, zwracające karę za daną kartę. 2.2 Dealer Klasa definiuje talię kart(zbiór kart). Ustawia właściwości talii oraz tworzy ją. Odpowiedzialna jest również za rozgrywkę: rozdaje karty, tasuje je, wydaje dodatkowe karty(przy pobieraniu). Obiekt posiada pola odpowiedzialne za karty użyte już w grze, karty dostępne na stole dla graczy, informacje o aktywnej karcie, aktywnym żądaniu/karze. Zawiera metody do tasowania kart, wydawania dodatkowych kart graczom oraz zmianie aktywnej karty. 2.3 Player Klasa tworzy gracza. Każdy gracz ma określoną aktywnośd. Posiada określoną liczbę i rodzaj kart. Obiekt posiada funkcje dodająca określoną kartę do zbioru kart gracza, zwracającą określoną kartę, a także możliwośd rzucenia karty. Posiada również metodę określająca czy dana karta gracza może zostad rzucona na stos wykorzystywane są funkcje pomocnicze określające czy jest aktywne żądanie/kara. 2.4 DrawTable Klasa jest odpowiedzialna za wyświetlenie (rysowanie) stołu do gry, oraz elementów znajdujących się na nim (kart itp.). Tworzy graczy, ich karty oraz dilera. Ustawia również wybrany wygląd stoły, talii kart. 2.5 Util Klasa pomocnicza. Posiada tylko metody statyczne. Odpowiada za sortowanie kart w 1 z 4 porządków (rosnąco/malejąco i według kary/figury). 2.6 NetworkAdapters Klasa, w której zdefiniowane zostały statyczne metody odpowiedzialne za zapis/odczyt danych wysyłanych w transmisji sieciowej miedzy 2 aplikacjami (graczami). W celu przyspieszania transmisji obiekty tworzone są na komputerze gracza, a przesyłane są tylko pojedyncze składowe karty/talii/klasy DrawTable wymagane do potrzebnej pracy programu. 2.7 MouseAdapters Klasa zawiera statyczne metody typu MouseAdapter/MouseMotion metody są potrzebne by obsługiwad kliknięcia myszą (np. dodawanie kart do rzutu, pobieranie kart, zamiana jokera itp.) Ilośd metod i ich objętośd jest spora, ale wywoływanie ich to kwestia tylko 1 linii (zwiększa sie czytelnośd działania aplikacji).
2.8 MainMenu Klasa odpowiada za tworzenie interfejsu graficznego menu nowej gry. Możliwe jest wywołanie menu pomocy, menu opcji, gdzie można zmienid talie/rewers/stół. 2.9 Main Zawiera statyczną metodę main odpowiedzialną za utworzenie obiektu klasy MainMenu uruchomienie aplikacji. 2.10 Label Klasa pomocnicza. Dzięki statycznym metodom dodawanie zdarzeo, określanie wymiarów i obrazka jest bardziej czytelne oraz zajmuje mniej linii kodu. 2.11 DrawTransformation Klasa realizuje rysowanie menu kontekstowego do sortowania kart oraz gdy wybrana/dolosowana jest karta typu As, Joker lub Walet. 3. Załączniki 3.1 Harmonogram prac (diagram Gantta)
3.2 Diagram klas
3.3 Diagram klas konceptualnych 3.4 Diagram przypadków użycia
3.5 Diagram czynności
3.6 Interfejs aplikacji