Efektywne tworzenie oprogramowania 2008/2009 cvs.ii.uni.wroc.pl/eto2008

Plan Prezentacja przykładowych tematów projektów: z EFL i z firmy Insert Jak rozszerzyć naszą realizację O i X Projekt i wokół (realizacja na ETO) Historyjki użytkownika – element XP

Kółko i krzyżyk - określanie zakresu Pytania:  Czy będziemy wspomagać inne gry?  Czy powinien być interfejs graficzny?  Czy gra powinna odbywać się w sieci? Przez przeglądarkę?  Czy gry mogą być magazynowane i odtwarzane? Monolityczny projekt papierowy – zły! Iteracyjna strategia rozwijania:  ograniczyć początkowy zakres do minimalnej liczby wymagań  rozszerzać system przez dodawanie cech i przypadków testowych  pozwalać, aby projekt ukazywał się poprzez refaktoryzację ról i powinności ! Ile funkcjonalności należy dostarczyć w 1. wersji systemu? Wybrać minimalny zbiór wymagań, który ma znaczenie dla klienta

Kółko i krzyżyk - obiekty Pewne obiekty mogą być identyfikowane z wymagań ObiektyPowinności Grapielęgnuje zasady gry Graczwykonuje ruchy pośredniczy w interakcji z użytkownikiem Polezapisuje znaki Figura (stan) pielęgnuje stany gry

Ulepszamy interakcję Chcemy mieć graczy zarówno testowych jak i rzeczywistych, a więc powinni być tworzeni przez instancję Driver. Osobnymi operacjami powinno być uaktual- nianie oraz drukowanie stanu gry. Gra (Game) powinna prosić gracza o wyko- nanie ruchu, a gracz powinien to zrobić.

Scenariusze testowania Nasze scenariusze testowania powinny grać i testować przykładowe scenariusze gry.

Kółko i krzyżyk - kontrakty Jawne inwarianty:  ruchem (bieżącego gracza) jest albo X albo O  X i O są naprzemienne (ruch nigdy nie jest taki sam jak ruch poprzedni)  stanem gry jest tablica 3 na 3 wypełniona X, O lub puste (‘ ’)  zwycięzcą jest X lub O wtedy i tylko wtedy, gdy zwycięzca ma 3 w jednym wierszu, kolumnie lub na przekątnej Niejawne inwarianty:  na początku nikt nie jest zwycięzcą; na początku ruch ma X  gra jest zakończona, gdy wszystkie pola są zajęte lub jest zwycięzca  gracz nie może zaznaczyć pola, które jest już zaznaczone Kontrakty:  bieżący gracz może zrobić ruch, jeśli spełnione są inwarianty

Kodowanie kontraktu Musimy wprowadzić zmienne stanu, aby zaimplementować kontrakty.

Inwarianty Te warunki wyglądają, jako oczywiste. Dlatego właśnie powinny być sprawdzane. Asercje i testy często mówią nam, jakie metody powinny być implementowane i czy powinny być one publiczne czy prywatne.

Delegowanie powinności Gracz (Player) wywołuje teraz metodę move z Game:

Małe metody Wprowadzaj metody, które czynią intencje Two- jego kody bardziej przejrzystymi.

Metody dostępu Metody dostępu (accessor) zabezpieczają klienty przed zmianami w implementacji. Zmienne nie powinny być na ogół publiczne. Zamiast tego lepiej stosować metody dostępu.

Sterownik gry (Driver) Aby uruchomić gry testowe oddzielamy instancje gracza (Player) od grania.

Gomoku Gra rozgrywana jest na planszy 19x19 lub 15x15 pól. Każdy z dwóch graczy ma do dyspozycji kamienie: jeden koloru białego, drugi -- czarnego, które układają na przemian na wolnych polach planszy. Celem gry jest ułożenie na planszy DOKŁADNIE PIĘCIU (nie więcej) kamieni swojego koloru w ciągłej linii -- poziomej, pionowej lub ukośnej. Pierwszy gracz, który tego dokona, zostaje zwycięzcą; jeśli nie uda się to nikomu (plansza zostanie zapełniona), następuje remis.

Gomoku – O i X Chcemy dzielić jak najwięcej kodu z O i X 1.Pomysł – dziedziczenie (implementacji) z TTT 2.Kopiować kod – duplikacja kodu 3.Zmienić projekt, aby grać O i X lub Gomoku (oba implementują ten sam interfejs; część kodu wspólna) – klasa abstrakcyjna, interfejs?? Kto po kim dziedziczy

O i X - Gomoku Najprościej: 1.Zdefiniować interfejs Plansza wymagany przez granie – X i O imlementuje ten interfejs 2.Ustalić interfejs – większa plansza zmiana set() get() inRange() 3. Wprowadzić AbstrakcyjnąGrę „działającą” dla obu O i X oraz Gomoku O i X oraz Gomoku nadpisują ją i rozszerzają

Projekt i wokół Planowanie pracy Organizacja zespołu Pułapki Zadania

Projekt i wokół Raport – status prac W regularnych odstępach info o postępach prac „mały” raport cotygodniowo „duży” na końcu wydania (lub iteracji)

Projekt i wokól Na stronie m. in. Nazwa projektu Członkowie zespołu i ich adresy Każdy prowadzi dziennik Zadania do realizacji, w trakcie realizacji, zrealizowane (termin realizacji, priorytet) Raport o postępach prac (cotygodniowy)

Projekt i wokół Raport (info) o spotkaniach zespołu np. rzeczy do zmiany, nierozpatrywane, procedura, ważne daty Ponadto 2-3 spotkania tygodniowo 15-minutowe

Projekt – strona WWW Opis projektu (temat, cele, wizja itp.) Raporty ze spotkań Plan: szczegółowy na najbliższy tydzień oraz na cały okres (może się zmieniać) Pojedyncze dokumenty, np.: słownik, przypadki użycia, historyjki użytkownika Informacje o narzędziach

Projekt - terminy Do 28.X.2008 Kierownik zespołu zgłasza tytuł projektu i dane członków, aby założyć stronę repozytorium projektu na CVS