Modelowanie „zwinne”

1. Modelowanie „zwinne” Piotr Pilinko

2. Plan szkolenia • Wprowadzenie o Prowadzącym i SMT Software • Podstawy modelowania • Dokumentacja • Kategorie modeli • FURPS+ • Przypadki użycia • Historie użytkownika • Diagramy sekwencji • Model domenowy • Testy akceptacyjne • Projektowanie • GRASP

3. Piotr Pilinko • Współpracuje z SMT Software od blisko 3 lat; • Starszy inżynier oprogramowania i architekt projektów; • Doświadczenie w tworzeniu aplikacji w C++ i C#; • Przez kilka lat tworzył funkcjonalności wyszukiwarki Bing (Microsoft); • Absolwent Informatyki, Inżynierii Oprogramowania na Wydziale Informatyki i Zarządzania Politechniki Wrocławskiej.

4. SMT Software SKA • Na rynku od 2002 roku • Ponad 500 specjalistów IT • 7oddziałów na terenie kraju: Wrocław (siedziba główna), Warszawa, Poznań, Kraków, Gliwice, Katowice, Białystok; oddział w Holandii, Francji, UK. • Część grupy kapitałowej Grupa SMT S.A. notowanej na GPW Outsourcing IT Projekty informatyczne aplikacje mobilne specjaliści zespoły usługi zarządzane dedykowane online mobilne GIS testy i audyty

5. Fałszywa dychotomia • PROJEKTOWANIE Vs. • IMPLEMENTACJA

6. Podstawy modelowania • Modelowanie w grupie (nie samotnie!) • Skalowanie modelowania (połączone warsztaty) • Użycie wielu równoległych modeli • Diagramy UC • Diagramy interakcji • Diagramy sekwencji • Diagramy FSM • Diagramy klas

7. Podstawy modelowania • „Dziel i zwyciężaj” • Burze mózgów z oddzielnych zespołach • Łączenie wypracowanych rozwiązań

8. Dokumentacja • Jest użyteczna dopiero PO tym jak kod zostanie NAPISANY i PRZETESTOWANY • Powinna być tworzona na warsztatach • Artefakty powstałe w procesie modelowania powinny być zachowane (np. na stronach WIKI) • MODELE to NIE jest dokumentacja • KAŻDY model jest błędny… • … i jest to akceptowalne

9. Kategorie modeli

10. FURPS: kategorie i wymagania • Funkcjonalność (Functional) • Cechy, ograniczenia, bezpieczeństwo • Użyteczność (Usability) • Czynnik ludzki, pomoc, dokumentacja • Niezawodność (Reliability) • Częstotliwość występowania błędów, przewidywalność, odzyskiwanie stanu operacyjnego po awarii • Wydajność (Performance) • Czas odpowiedzi, przepustowość, dokładność, zużycie zasobów • Utrzymywanie (Supportability) • Adaptacja, utrzymanie, konfigurowalność, internacjonalizacja

11. FURPS+: kategorie i wymagania • Implementacja • Ograniczone zasoby, języki i narzędzia, sprzęt • Interfejs • Ograniczenia wprowadzone przez interfejsy innych systemów z którymi ma współpracować nasz system • Operacyjność • Zarządzanie systemem poprzez ustawienia • Dystrybucja • Np. pakowanie w fizyczne pudełka • Wymagania prawne • Licencje

12. Przypadki użycia (UC) • Wszystkie ścieżki „krok po kroku” • Spełniają oczekiwania/cele użytkownika • Posiadają mierzalną wartość biznesową • Są skierowane na użytkownika końcowego • Zawierają pełny scenariusz (ze wszystkimi krokami)

13. Przypadki użycia: aktorzy • Aktorzy główni: • Operator • Agent zewnętrzny (człowiek lub system komputerowy) • Byt wykazujący się zachowaniem • Aktorzy pomocniczy (drugorzędni) • Inne byty użytkowane przez system, ale nie będące częścią systemu

14. Przypadki użycia: wskazówki • Nazwa • Rozpoczyna się od czasownika • Nie powinna zawierać elementów UI • „Usuń zadanie” zamiast „Naciśnij przycisk, by usunąć zadanie” • Małe operacje powinny być zgrupowane • Zbyt duże operacje powinny być podzielone na poszczególne przypadki użycia • Pełna operacja (od początku interakcji z systemem do odebrania wyników) • Odzwierciedla cele użytkownika

15. Przypadki użycia: przykład

16. Historie użytkownika (przykłady) • Jako operator chcę konfigurować system w celu odpalenia pocisku • Jako operator chcę odpalić pocisk aby zniszczyć cel • Jako operator chcę zweryfikować obecny stan pocisków, aby uzupełnić ich zapas

17. Opis przypadków użycia Cockburne’a • Przypadek użycia jest kolekcją scenariuszy pozytywnych i negatywnych (obsługa błędów) • Rozszerzenia przypadków użycia • Należy unikach ujęcia wielu ścieżek w jednym opisie (rozbicie na wiele opisów)

18. Opis przypadków użycia Cockburne’a • Główny scenariusz: Konfiguracja • 5. System wyświetla dostępne moduły użytkownikowi • 10. Operator wybiera moduł do konfiguracji • 15. System sprawdza licencje na wybrany tryb działania • 20. Operator wybiera ręczny tryb działania • 30. Operator wybiera pocisk • 40. Operator wprowadza warunki pogodowe • 50. Operator wprowadza współrzędne celu • 60. System konfiguruje podsystemy rakietowe dla wybranego modułu • 70. System wyświetla informację o poprawnej konfiguracji

19. Opis przypadków użycia Cockburne’a • Rozszerzenia: • 18a. System wyświetla informację o wygaśnięciu licencji • 1. System opuszcza tryb konfiguracji • 20a. Operator wybiera tryb automatycznej konfiguracji • 1. Wykonanie kroków 10-30 • 2. Operator wprowadza identyfikator celu • 3. System konfiguruje podsystem rakietowy dla wybranego w kroku 10 modułu • 4. Wykonanie kroków od 70.

20. Diagramy sekwencji • Nazwa operacji systemowej • Rozpoczyna się od czasownika • Interfejs użytkownika nie powinien przenikać do nazwy • Obrazuje zewnętrzne zdarzenia w scenariuszach systemowych

21. Diagramy sekwencji: przykład

22. Model domenowy • Wizualny słownik • Kontekst do rozmowy z klientem • Pomysły • SŁOWNICTWO! • NIE JEST modelem oprogramowania • Model mentalny • Ewolucyjny – rozpoczyna się od małego modelu i jest stopniowo rozszerzany

23. Model domenowy: przykład

24. Testy akceptacyjne • Właściciel produktu powinien zdefiniować przypadki testowe na każdą historię użytkownika • TA zawierają warunki końcowe: • Stan wyjść • Stan obiektów zachowanych trwale • Sprawdzenie istnienia nietrwałych obiektów • Sprawdzenie zajścia interakcji wewnętrznych • Sterowane przepływem danych, lub deklaratywne • Przykład: • PING do serwisu GPRS zakończył się sukcesem

25. Testy akceptacyjne (przykład)

26. Testy akceptacyjne PISZ KOD TYLKO WTEDY GDY ISTNIEJE TEST, KTÓRY NIE PRZECHODZI

27. Projektowanie • Warstwy • Prezentacji • Interfejs, UI, widoki • Aplikacji • Przepływy, procesy, mediatory, kontrolery aplikacji • Domeny • Serwis modelu biznesowego • Infrastruktury biznesowej • Niskopoziomowe serwisy biznesowe • Techniczna • Frameworki • Podstawowa • Podstawowe usługi, niskopoziomowa infrastruktura

28. Projektowanie: diagram FSM • Opis maszyny stanów: • Stany • Przejścia • Warunki • Akcje • Łączy się z: • Diagramem komunikacji • Diagramem sekwencji • Przedstawia: • Cykl życia obiektów

29. Projektowanie: diagram FSM

30. Projektowanie: diagram aktywności • Użyteczny podczas • Analizy • Procesy biznesowe lub domenowe (CO?) • Projektowania • Algorytmy (JAK?) • Każdy diagram sekwencji wymaga osobnego diagramu aktywności

31. Projektowanie: diagram aktywności

32. Projektowanie: diagram komunikacji • Reprezentacja projektowa systemowego diagramu sekwencji • Inspirowane przez diagramy aktywności • Powinny być wykonane dla każdej operacji systemowej • Prezentuje kolejność komunikacji pomiędzy obiektami

33. Projektowanie: diagram komunikacji

34. Projektowanie: diagram klas • Statyczny model struktur danych z nazwami operacji

35. Projektowanie: diagram klas • Zależności

36. GRASP General Responsibility Assignment Software Patterns

37. GRASP: podstawy • Information Expert • Creator • Controller • Low Coupling • High Cohesion • Polymorphism • Pure Fabrication • Indirection • Protected Variations

38. Refaktoring: kiedy? • Zduplikowany kod lub dane • Zbyt długie metody • Niejasne nazwy metod • Magiczne stałe • Mocne powiązanie klas • Niska spójność • Logika „if/switch” zamiast polimorfizmu • Dużo obiektów bez metod (data objects) • Komentarze, które wyjaśniają CO kod robi, zamiast DLACZEGO

39. Refaktoring: kiedy? • Zduplikowany kod lub dane • Zbyt długie metody • Niejasne nazwy metod • Magiczne stałe • Mocne powiązanie klas • Niska spójność • Logika „if/switch” zamiast polimorfizmu • Dużo obiektów bez metod (data objects) • Komentarze, które wyjaśniają CO kod robi, zamiast DLACZEGO

40. Testy modułowe: FIRST • F – fast • Średnio wykonanych 100-1000 testów na sekundę • I – independent • Nie używają systemu plików, baz danych, sieci • R – repeatable • Nie zmieniają permanentnie stanu dzielonych obiektów • S – self-validating • Nie wymagają analizy operatora • T – timely • Powstają PRZED rozwiązaniem

41. Źródła • http://www.agilemodeling.com • http://www.uml.org • http://www.omg.org

42. Zadanie: Monopoly

43. Zadanie: pierwszy sprint • 40 ponumerowanych pól na planszy • Pole „0” – „GO” • 39 generycznych pól • Dwie kostki (sześciościenne) • Konfiguracja: 2-4 graczy, N tur • Gracze reprezentowani przez symbole • Gracze rozpoczynają od pola „GO” • Automatyczne ruchy wykonywane przez komputer (brak interakcji) • Gra kończy się po N turach • Status gry jest reprezentowany przez zdarzenia tekstowe

44. Zadanie: pierwszy sprint • 40 pól na planszy • Pole 0: GO • Pole 4 and 38: Podatek od przychodu • Pole 10: Więzienie • Pole 30: Idziesz do więzienia • Pole 7, 22 and 36: Szansa • Gracz zaczyna grę z 1500$ • Gracz otrzymuje $200 po każdym przejściu przez GO • Po wejściu na pole 30 gracz przechodzi na pole 10 i traci następną turę • Gracz unika straty tury, jeśli posiada kartę „Wychodzisz z więzienia” (używana automatycznie) • Po wejściu na pole „Podatek od przychodu” gracz traci min(10% posiadanych pieniędzy, 200$) • Po wylądowaniu na polu „Szansa” gracz losuje kartę • „Wyjście z więzienia” • „Idź do więzienia” • „Urodziny” – każdy gracz musi zapłacić 100$ graczowi, który wylosował tę kartę • Gra kończy się po N turach, lub też gdy wszyscy gracze (poza jednym) stracą wszystkie pieniądze