Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Modelowanie zwinne Piotr Pilinko. Plan szkolenia Wprowadzenie o Prowadzącym i SMT Software Podstawy modelowania Dokumentacja Kategorie modeli FURPS+ Przypadki.

Podobne prezentacje


Prezentacja na temat: "Modelowanie zwinne Piotr Pilinko. Plan szkolenia Wprowadzenie o Prowadzącym i SMT Software Podstawy modelowania Dokumentacja Kategorie modeli FURPS+ Przypadki."— 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 aplikacje mobilne Outsourcing IT Projekty informatyczne dedykowaneonlinemobilneGIStesty i audyty specjaliścizespołyusługi zarządzane

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 AnalizaProjekt StatyczneModel domenowy Diagram UC Diagram pakietów Diagram klas Diagram pakietów DynamiczneHistorie 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 Cockburnea 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 Cockburnea 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 Cockburnea 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 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 CaseActionIN Module IdIN StatusOUT Status Fire Missile1. Fire missile Id=1missileNo=3missileNo=2 Id=1missileNo=1missileNo=0 Id=1missileNo=0 Test CaseAction IN Current Mode IN AMA License IN Module Id IN Desired Mode OUT Chosen Mode Configuration1. Mode selection under AMA license existence condition cuMode=MMAlicense=0Id=1dMode=AMAchMode=MMA cuMode=AMAlicense=1Id=2dMode=AMAchMode=AMA cuMode=MMAlicense=1Id=1dMode=AMAchMode=AMA

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 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

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 Dywizja Południe SMT Software Spółka z ograniczoną odpowiedzialnością SKA ul. Piłsudskiego Wrocław tel fax Dziękujemy za uwagę Wrocław WarszawaPoznańKraków Gliwice Katowice Białystok Dywizja Centrum SMT Software Spółka z ograniczoną odpowiedzialnością SKA ul. Jutrzenki Warszawa tel fax


Pobierz ppt "Modelowanie zwinne Piotr Pilinko. Plan szkolenia Wprowadzenie o Prowadzącym i SMT Software Podstawy modelowania Dokumentacja Kategorie modeli FURPS+ Przypadki."

Podobne prezentacje


Reklamy Google