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”.