Przypadki użycia w notacji UML1 to jedna z najstarszych metod dokumentowania wymagań i nadal budzi wiele kontrowersji w kwestii ich poprawnego użycia. Obiektowy paradygmat i pojęcie systemu Słownik j.polskiego mówi: paradygmat ?przyjęty sposób widzenia rzeczywistości w danej dziedzinie, doktrynie itp.? obiekt ?rzecz abstrakcyjna, np. cecha lub pojęcie?, ?przedmiot, który można zobaczyć lub dotknąć? system ?układ elementów mający określoną strukturę i stanowiący logicznie uporządkowaną całość?, ?zespół wielu urządzeń, dróg, przewodów itp., funkcjonujących jako całość? Ludwig von Bertalanffy w swojej Ogólnej Teorii Systemów?2? określa system: stanowiący określoną całość byt, złożony z mających interakcje elementów. Pojęciami powiązanymi są tu…
Wprowadzenie Właśnie zostałem zapytany: Witam Pana, czy interesował się Pan Use Case 2.0 ? Tak. Od czasu do czasu wpadają mi w ręce takie opisy. Ta idea jest ciekawym i pragmatycznym podejściem do etapu dokumentowania zakresu projektu. Warto jednak pamiętać, że przypadki użycia mają swój kontekst (są osadzone) w tym co robią użytkownicy, bez tego kontekstu są niestety ryzykownym narzędziem, bo deklaratywnym (skąd wiemy, że osoba A ma coś robić skoro nie wiemy jak wygląda cały proces biznesowy, czy mamy polegać tylko na subiektywnej deklaracji tej osoby?). Dość często spotykam…
Po kilku latach kolejnych doświadczeń upewniam się, że proste jest piękne: przypadek użycia to pojedyncza, elementarna kompletna usługa świadczona przez System dla jego użytkownika. Usługa ta jednak może mieć warianty.
Jaki z tego ma pożytek sponsor projektu? Koszt, projekt ma kilkanaście lub kilkadziesiąt a nie setki przypadków użycia i jest łatwiejszy w implementacji.
A gdzie przypadki systemowe? Nie ma takich. Pojęcie Aktora ma jasną definicję (osoba lub inny system mający interakcję z Systemem), pojęcie przypadku użycia także (specyfikacja działań Systemu w odpowiedzi na działania aktora lub innego podmiotu "zainteresowanego" Systemem) (źr.: OMG Unified Modeling LanguageTM (OMG UML), Superstructure Version 2.3). Wymyślanie nowych definicji nie tylko psuje standard bo nie pasuje do spójnej przestrzeni nazw. Wymyślanie swoich znaczeń po protu psuje zrozumiałość, niszczy role komunikacyjną modeli (języka ich tworzenia). Niestety Pan Cockbourn jest w moich oczach takim "dorabiaczem" i psującym sens prostego i jak widać trudnego zarazem, narzędzia jakim jest model przypadków użycia systemu.
