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

Prezentacja na temat: "Efektywne tworzenie oprogramowania 2008/2009 cvs.ii.uni.wroc.pl/eto2008."— Zapis prezentacji:

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

2 Kartkówka 1. (16.X) Na czym polega testowanie sterowane błędami? Co to jest regresja błędów? Co to są testy imitujące klienta? Pracując nad wykonaniem projektu powinniśmy mieć aktywną listę zadań/funkcji (dostępną dla wszystkich członków zespołu). Co należy umieścić (określić) dla każdego zadania/funkcji na tej liście? Ktore elementy metodyki XP są Twoim zdaniem najważniejsze?

3 Testowanie sterowane błędami Polega na kierowaniu testów w kierunku fragmentów kodu, które zawierały lub zawierają błędy. Pozwala ono na szybkie opracowanie zestawów testów.

4 Regresja błędów Regresja błędów występuje wówczas, gdy problem, który został poprawiony, powraca do kodu. Na przykład, przez przypadek zapisany zostanie do SCM niepoprawny kod (gdy problem już wcześniej rozwiązano) lub gdy ten sam błąd zostanie wprowadzony ponownie.

5 Testy imitujące klienta Test imitujący klienta korzysta z programu dokładnie tak jak klient. Jeśli mamy scenariusze typowych czynności klienta, to możemy je umieścić w testach imitujących klienta i sprawdzić czy działają (także po zmianach). Testy te sprawdzają najważniejszą część kodu.

6 Aktywna lista zadań/funkcji Dostępna dla wszystkich członków zespołu. Co należy umieścić (określić) dla każdego zadania/funkcji na tej liście? Należy przypisać priorytety pozycjom listy, prognozę czasu wykonania, a po wykonaniu czas rzeczywistego wykonania. Uwaga: -nie ma błędnych prognoz, są tylko mniej lub bardziej dokładnie

7 Metodyka XP Które elementy metodyki XP są Twoim zdaniem najważniejsze? Gra w planowanie; krótkie wersje; metafora; prosty projekt; testowanie; refaktoring; programowanie parami, kolektywne prawa, ciągła integracja, 40-godzinny tydzień pracy; klient na miejscu, standardy kodowania.

8 Praktyki XP Prosty projekt – zbędne komplikacje usuwany, gdy takowe odkryjemy Krótkie wersje – szybko prosty system, potem dopracowywanie nowych wersji w krótkich cyklach Testowanie – ciągle pisanie testów; kontynuujemy przy pomyślnych wynikach; gdy kto wykryje błąd, napisz test pokazujący ten błąd Programowanie parami – dwie osoby, jeden komputer, klawiatura, mysz

9 Podsumowanie Przesłać, do 11.X.2008, godz. 10:00, podsumowanie w korespondencji e-mail na adres osoby prowadzącej ćwiczenia. Każdy podaje kolor grupy oraz imiona i nazwiska członków grupy. Wyjaśnić, które strategie zastosowane w grupie odniosły sukces, a które nie. Omówić strategie/podejście techniczne oraz organizację grupy (i jej pracy) Jakie doświadczenia wyciągnięto i zastosowano w kolejnym kroku iteracji

10 Specyfikacje Specyfikacje mówią nam co robić (ale nie jak to robić) Perfekcyjna implementacja nie jest dobra, jeśli rozwiązuje złe zagadnienie Ciężko jest utworzyć specyfikację, która jest –kompletna, spójna, precyzyjna, zwięzła

11 Czym jest projektowanie sterowane powinnościami (RDD)? RDD jest metodą sterowania projektowaniem oprogramowania w terminach współpracujących obiektów poprzez pytanie jakie odpowiedzialności muszą być spełnione, aby zaspokoić wymagania i przypisanie ich do odpowiednich obiektów (tzn. tych, które mogą je zrealizować).

12 Jak przypisywać odpowiedzialności? dont do anything you can push off to someone else dont let anyone else play with you Pelrine Projektowanie sterowane powinnościami różni się zasadniczo od projektowania sterowanego danymi lub tego, które otrzymuje się przy funkcjonalnej dekompozycji. Odpowiedzialności klas mają tendencję do większej stabilności w miarę upływu czasu niż funkcjonalność czy reprezentacja.

13 Przykład: Kółko i krzyżyk (Tic Tac Toe -TTT) Wymagania: Gra, w której jeden gracz zaznacza krzyżykami a drugi kółkami. Każdy z nich na przemian wypełnia swoim znakiem jedno z 9 pól figury, która jest utworzona przez skrzyżowanie dwóch linii poziomych i dwóch linii pionowych. Zwycięzcą jest ten, który pierwszy umieści swoje znaki w wierszu, kolumnie lub na przekątnej. Mamy zaprojektować program, który zaimplementuje zasady tej gry. Korzystam z opracowania przykładu przez prof. O.Nierstrasza

14 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

15 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

16 Kółko i krzyżyk - obiekty … !Jak można określić, kiedy mamy poprawny zbiór powinności ? Każdy obiekt ma jasny i naturalny zbiór powinności. Inne jednostki mogą zostać wyeliminowane: nie-obiektuzasadnienie krzyżyki, kółkato samo co znak znakiWartość pola linie poziomewyświetlanie stanu linie pionowewyświetlanie stanu zwycięzcastan gracza przekątnawidok stanu wierszwidok stanu

17 Opuszczone obiekty Sprawdzamy czy są nieprzypisane powinności: Kto rozpoczyna grę? Kto odpowiada za wyświetlenie stanu gry? Skąd gracze wiedzą, że gra skończyła się? Wprowadzamy sterownik do nadzorowania gry. ! Skąd wiadomo, że w projekcie opuszczono obiekty? Gdy zostały nieprzypisane powinności.

18 Scenariusze Scenariusz opisuje typową sekwencję interakcji: Czy są inne poprawne scenariusze dla tego problemu?

19 Szkielet – wersja 0 Pierwsza wersja niewiele robi W jaki sposób program rośnie iteracyjnie? Należy zawsze mieć działającą wersję class GameDriver { static public void main(String args[]) { TicTacToe game = new TicTacToe(); do { System.out.print(game); } while(game.notOver()); } public class TicTacToe { public boolean notOver() { return false; } public String toString() { return("TicTacToe\n"); } }

20 Wersja 1 - stan gry Korzystamy z notacji szachowej, aby mieć dostęp do stanu gry: -- kolumny od a do c -- wiersze od 1 do 3 Jak podjąć decyzję o poprawnym interfejsie? Naprzód napisać pewne testy.

21 Test przed programem public class TicTacToeTest extends TestCase { private TicTacToe game; protected void setUp() throws Exception { super.setUp(); game = new TicTacToe(); } public void testState() { assertTrue(game.get('a','1') == '); assertTrue(game.get('c','3') == ' '); game.set('c','3','X'); assertTrue(game.get('c','3') == 'X'); game.set('c','3',' '); assertTrue(game.get('c','3') == '); assertTrue(!game.inRange('d','4')); }

22 Reprezentowanie stanu gry

23 Sprawdzanie warunków wstępnych set() i get() tłumaczą notację szachową na wskaźniki tablicy

24 Drukowanie stanu Należy nadpisać Object.toString Reimplementujac TicTacToe.toString możemy obserwować stan gry

25 TicTacToe.toString Używamy StringBuffer a nie String do budowy reprezentacji

26 Dodajemy logikę gry – wersja 2 Chcemy dodać: Scenariusze testów Klasę gracza (Player) Metody do wykonywania ruchów Testowanie zwycięstwa

27 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ć.

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

29 Uruchomienie przypadków testowych

30 Gracz Używamy różnych konstruktorów przy tworzeniu graczy rzeczywistych i testowych. Gracz rzeczywisty czyta ze standardowego strumienia wejściowego. Ten konstruktor wywołuje inny …

31 Konstruktory gracza (Player) Można skonstruować gracza, który czyta swoje ruchy z wejściowego bufora. Ten konstruktor nie będzie wywoływany wprost.

32 Konstruktory gracza (Player) Testowy gracz pobiera swoje ruchy z bufora napisów: Umowny konstruktor zwraca gracza reprezentującego nobody

33 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

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

35 Wspomaganie testowych graczy Gra (Game) już nie tworzy graczy (Player) ale akceptuje ich jako argumenty konstruktora:

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

37 Delegowanie powinności Gdy sterownik (Driver) uaktualnia grę (Game), gra prosi gracza (Player) o wykonanie ruchu: Zauważ, że Driver nie może wykonać tego bezpośrednio.

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

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

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

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