Pobierz prezentację
Pobieranie prezentacji. Proszę czekać
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
Podobne prezentacje
© 2024 SlidePlayer.pl Inc.
All rights reserved.