1 / 45

Modelowanie „zwinne”

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.

halen
Download Presentation

Modelowanie „zwinne”

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related