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