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.
