Modelowanie „zwinne” Piotr Pilinko.

Prezentacja na temat: "Modelowanie „zwinne” Piotr Pilinko."— Zapis prezentacji:

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
7 oddziałó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 Analiza Projekt Statyczne Model domenowy Diagram UC
Diagram pakietów Diagram klas Dynamiczne Historie użytkownika Opis UC Diagram sekwencji Testy akceptacyjne Diagram aktywności procesu Diagram maszyn stanów (FSM) Diagram aktywności (algorytm) Diagram interakcji (komunikacji) Pseudo kod

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)
Test Case Action IN Module Id IN Status OUT Status Fire Missile 1. Fire missile Id=1 missileNo=3 missileNo=2 missileNo=1 missileNo=0 IN Current Mode IN AMA License IN Desired Mode OUT Chosen Mode Configuration 1. Mode selection under AMA license existence condition cuMode=MMA license=0 dMode=AMA chMode=MMA cuMode=AMA license=1 Id=2 chMode=AMA

26 PISZ KOD TYLKO WTEDY GDY ISTNIEJE TEST, KTÓRY NIE PRZECHODZI
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 General Responsibility Assignment Software Patterns
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 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

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

45