Modelowanie „zwinne”
description
Transcript of 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
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
aplikacje mobilne
Outsourcing IT Projekty informatyczne
dedykowane online mobilne GIS testy i audytyspecjaliści zespoły usługi zarządzane
Fałszywa dychotomia
PROJEKTOWANIEVs.
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 domenowyDiagram UCDiagram pakietów
Diagram klasDiagram pakietów
Dynamiczne Historie użytkownikaOpis UCDiagram sekwencjiTesty akceptacyjneDiagram aktywności procesuDiagram 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
Management Software System
Operator
Configure System
Fire Missile
Get Status
Application
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
:Operator:System
:Application
getStatus()
getStatus()
missileInfo()
systemInfo()
For each Application
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
MSS
Radar
- Type
MMA/AMA
- ID- Mode- State- Weather
1..5
Configures/Fires/Gets Status
0..1
1..5
Gets Target’s Data
Fires
- License
Operator
CEM
- ID
EM
- ID
Missile
- ID
Target
- ID- Coordinates
Operates
0..3
Aims at
Runs on
0..5
ForwardsOrders
0..1
TransfersTarget’s Data
0..3
Runs on
Runs on
1
0..3
TransfersCoordinates/
Orders
0..3
TransfersCoordinates/
Orders
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 missileId=1 missileNo=3 missileNo=2
Id=1 missileNo=1 missileNo=0
Id=1 missileNo=0 missileNo=0
Test Case ActionIN Current
ModeIN AMA License
IN Module Id
IN Desired Mode
OUT Chosen Mode
Configuration 1. Mode selection under AMA license existence condition
cuMode=MMA license=0 Id=1 dMode=AMA chMode=MMA
cuMode=AMA license=1 Id=2 dMode=AMA chMode=AMA
cuMode=MMA license=1 Id=1 dMode=AMA chMode=AMA
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
Armed
WaitingForTarget ReadyToLaunch
[Setting mode]
[Automatic] [Manual]
[Target acquired]
[Fire] / Fire
[Abort] / Abort
[Timeout] / Abort
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
System prints available modules
Operator chooses module
System obtains licenses
System prints available modes
Configure MANUAL mode Configure AUTOMATIC Mode
System displays 'Succesful Configuration' Info
Chosen mode
Operator starts
configuration
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
ui : UI mss : MSS
lm : LicenseManager
mm : ModuleManagerm : Module
StartConfiguration
1.modules=GetModule()
2.modes=getLicenses(module)
3.info=setModes(mode,module)
1.1.m=getModules()
3.2.info=configModule(mode,module)3.3.setMode(mode)
1.2.max=getMaxModulesInfo()
2.1.lic=getLicense(module)
3.1.cond=checkLicense(mode,module)
Projektowanie: diagram klas
Statyczny model struktur danych z nazwami operacji
UI MSS
-maxLicenses : unsigned int
LicenseManager
ModuleManager
-mode : ModeType-moduleId : ModuleId
ModuleCommunication
Remote Local
-moduleId : ModuleId
License
1
1
1 11
*
1
*
Projektowanie: diagram klas
Zależności Link
Socket Socket
AssociationClass
TCP UDP
{OR}
Constraint
«interface»Protocol
Generalization
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
Dywizja Południe
SMT Software Spółka z ograniczoną odpowiedzialnością SKA
ul. Piłsudskiego 1350-048 Wrocław
tel. +48 71 769 59 00fax +48 71 769 59 01
Dziękujemy za uwagę
Wrocław Warszawa Poznań Kraków Gliwice Katowice Białystok
Dywizja Centrum
SMT Software Spółka z ograniczoną odpowiedzialnością SKA
ul. Jutrzenki 18302-231 Warszawa
tel. +48 22 380 47 50fax +48 22 380 47 51