No nic nie poradzę na to, że znany w branży autor ([[Alistair Cockburn]]) moim zdaniem pływa w czymś co ja nazywam „mnożenie bytów”, świat zna to pod nazwą [[Brzytwa Ockhama]], tu raczej jest to zaprzeczenie tej zasadzie a w moich oczach A.C. jest mistrzem w tej dziedzinie:
Alistair Cockburn przytacza na swojej stronie definicję stwierdzającą, że ?komunikacja osmotyczna oznacza, że informacja przepływa w tle słyszana przez członków zespołu, dzięki czemu mogą zapoznać się z informacją jakby przez osmozę. Zwykle jest to realizowane przez zespół siedzący w jednym pomieszczeniu. W momencie, gdy jedna osoba zadaje pytanie, inni w pomieszczeniu mogą albo zareagować lub zignorować pytanie, zaangażować się w dyskusję lub kontynuować swoją pracę.? (źr. Komunikacja osmotyczna a proces).
Czytam sobie o tej komunikacji osmotycznej i dziw bierze, że takie słowotwórstwo ma miejsce. Dlaczego? Owa „osmotyczna komunikacja” to nic innego jak [[komunikacja metoda publish/subscribe]]. Prosty mechanizm, znany z teorii komunikacji mówiący, że system jakim jest ludzki mózg i ucho broniąc się przez nadmiarem informacji, odbiera wszystkie dźwięki ale reaguje jedynie na pewne „oczekiwane”. To oczekiwanie jest niczym innym jak „informacją pomocną”, np. w przeżyciu (kiedyś). To bardzo stary mechanizm ukształtowany przez ewolucje także u zwierząt. Dokładnie tak samo są nie raz projektowane systemy komunikujących się modułó, procesów, podsystemów.
Klasyczny przykład użycia tego wzorca projektowego w projektach:
Jak śledzę książki Pana Cockburn’a to niestety mam wrażenie, że po pierwsze Przypadki Użycia dawno stały się u niego „syndromem młotkowego” (człowiekowi, który dostanie do ręki wielki młotek natychmiast wszystko zaczyna kojarzyć się z gwoździem). Po drugie dziwi mnie, że można z takim zacięciem ignorować pozostałe dokonania tuzów analizy takich jak Yourdon, Fowler czy Evans.
Tak więc proponuję rozważenie, by zamiast wprowadzania nowego pojęcia: komunikacja osmotyczna (choć wiem, że brzmi super i pewnie pozwala zostać celebrytą niejednej konferencji) pozostać przy starym dobrym wzorcu publish/subscribe nie tylko w obszarze modelowania procesów czy oprogramowania ale także na niwie zwykłej komunikacji. Dla zainteresowanych wzorcem i jego zastosowaniem w modelach procesów więcej w artykule jaki napisałem o CRM.
A kończąc w kwestii Cockbourn’a i jego orędowników: osobiście i bardzo subiektywnie uważam, że nawet jeśli dowolną kupę mało spójnego tekstu rozłożymy na wiersze i kolumny dowolnej ilości tabel (to się czasem nazywa czasem nadawaniem tekstowi struktury) to taki tekst nadal będzie mało spójny. Przypadki użycia jako tabelaryczna forma zapisu „user story” lub wymagań funkcjonalnych, nie uzyskają spójności poprzez sam fakt ich stabelaryzowania.
Przypadki użycia zaś jako efekt analizy całości zachowań i świadomego wyboru części z nich to jest dopiero spójny i kompletny opis wymagań. Bo jak to ktoś powiedział: kompletna lista najładniejszych kobiet w danym mieście to nie lista spotkanych ładnych w ostatnim miesiącu a lista wybranych spośród wszystkich w tym mieście. Taka lista ma sens bo nie grozi nam to, ze następnego dnia w tym mieście spotkamy inna ładniejszą.
Jeżeli ktoś Ci przyniesie specyfikację przypadków użycia do systemu i nie będzie potrafił jednoznacznie odpowiedzieć na pytanie dlaczego jest ich akurat tyle a nie np. jeden mniej lub dwa więcej albo dlaczego akurat te a nie inne, to najprawdopodobniej znaczy to, że podczas wdrożenia na pewno „spotkasz kilka innych ładniejszych kobiet”.
w którym miejscu Cockburn twierdzi, ze «Przypadki użycia jako tabelaryczna forma zapisu ?user story? lub wymagań funkcjonalnych, uzyskują spójność poprzez sam fakt ich stabelaryzowania.»?
Bazując na ksiązce «Jak pisać efektywne przypadki uzycia» miałem zupełnie odwrotne wrażenie – Cockburn dokladnie opisuje jak wyodrębniać PU – poprzez trzy poziomy celów.
Polecam dwa akapity książki „Jak pisać efektywne przypadki użycia” Cockbourna (wydanie polskie, WNT 2004). We wstępie pada stwierdzenie „gdy przypadki użycia służą do dokumentowania procesów gospodarczych…”, to już jest pogwałcenie idei przypadków użycia: to nie są żadne procesy. Rozdz. 1.2: „przypadki użycia są rodzajem pisarstwa…”, dalej ten rozdział (str. 33): „nie wystarczy jeden szablon przypadku użycia. Musza być co najmniej dwa: nieformalny dla przedsięwzięć z małym formalizmem i w pełni sformatowany, dla przedsięwzięć z dużym formalizmem.”
Z całym szacunkiem dla autora: w moich oczach to bełkot. Reszta książki jest w podobnym duchu. Owszem, można dorabiać ideologię do wszystkiego ale są pewne reguły” formalizm to między innymi zasady: przestrzeń nazw, syntaktyka. Tworzenie całego systemu kolejnych rozbudowanych wzorów tabel bez zdefiniowania systemu pojęciowego gwarantującego proste i jednoznaczne zasady ich wypełnianiami to niestety nadal nieformalna proza, a ubieranie jej w tabelki niczego nowego nie wnosi do tej prozy.
Jeżeli miał bym polecić coś o przypadkach użycia to: Stosowanie przypadków użycia, Geri Schneider, Jason P. Winters, WNT 2004. Tu słowo wstępne napisał Ivar Jacobson (ciekawe, że Cockbourn’owi nie udaje się na to namówić klasyków analizy obiektowej). Podkreślam, to moje odczucia po lekturze książki Cockbourna i można się z tymi opiniami nie zgadzać. Nie ja jeden mam takie wątpliwości, podobne wyraził w jednej z książek (niestety nie pamiętam która to) wyrażał M.Fowler.
Zgadzam się z niektórymi stwierdzeniami, aczkowliek pozwole sobie na kilka spostrzeżeń:
1. Stwierdzenie Cocburna, że «Musza być co najmniej dwa szablony PU – formalny i nieformalny» stoi nieco w sprzeczności, w tym co sugerowano w artykule jakoby «PU uzyskiwały spójność poprzez sam fakt ich stabelaryzowania». Cocburn twierdzi, ze forma nie jest najważniejsza, wazniejsze jest jej dostosowanie do celu.
2. Stwierdzenie z artykułu, że «kompletny opis wymagań to celowo wybrane PU» znajduje moim zdaniem odzwierciedlenie w książce Cocburna – autor sugeruje wydrębnić trzy poziomy celów – streszczenia, użytkownika i podfunkcji i opisać tylko dwa pierwsze. To daje podstawy do wytłumaczenia, dlaczego te a nie inne PU znalazły się w dokumencie analizy.
Generalnie zaskoczyła mnie tak negatywna opinia o autorze – czy kilka kolokwializmów i nieprecyzyjnych stwierdzeń ma przekreślać pozostałe wartościowe treści?:)
Moja dezaprobata ma swoje źródło w braku formalizmu Cockbourna, niestety prowadzi to sytuacji gdy „tekst zdzierży wszystko”.… a już jego sugestia by modelować procesy przypadkami użycia…