Modelowanie „zwinne” Piotr Pilinko

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

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.

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

Fałszywa dychotomia PROJEKTOWANIE Vs. IMPLEMENTACJA

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

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

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

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

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

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

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)

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

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

Przypadki użycia: przykład

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

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)

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

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.

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

Diagramy sekwencji: przykład

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

Model domenowy: przykład

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

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

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

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

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

Projektowanie: diagram FSM

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

Projektowanie: diagram aktywności

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

Projektowanie: diagram komunikacji

Projektowanie: diagram klas Statyczny model struktur danych z nazwami operacji

Projektowanie: diagram klas Zależności

General Responsibility Assignment Software Patterns GRASP General Responsibility Assignment Software Patterns

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

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

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

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

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

Zadanie: Monopoly

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

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