🚀 go-pugleaf

yapann wrote:

>> - włączany przypadek użycia nie jest jednak częścią włączającego jak
>> to ma np. miejsce w przypadku relacji kompozycji klas. Należy to raczej
>> traktować jak wywołanie procedury.
> to samo możesz wykonać bez procedury albo z jej użyciem - <include>y są
> opcjonalnością
Oj nie! <<include>> oznacza, że przy każdym "wykonaniu" przypadku
włączającego wywoływany jest również włączany. Obowiązkowo.
Warunkowy jest <<extend>>.

>> - logowanie - może występować samodzielnie
> ale nie jako przypadek modelujący TĘ SAMĄ funkcjonalność (chyba, że
> piszesz system, który realizuje logowanie (celem jest zalogowanie). W
> kontekście natomiast każdego inngo systemu, logowanie nie będzie funkją
> systemu, zatem (na bazie tych założeń) wg mnie nie może wystepiowac
> samodzielnie jako to, co nazywamy systemowym PU.
I tak i nie. Taki przypadek realizuje pewien cel użytkownika: zapewnienie
dostępu do pewnych danych tylko zarejestrowanym użytkownikom.
Wyobraźmy sobie teraz wymaganie: "jeśli użytkownik nie wykona żadnej
czynności do 5 min. po zalogowaniu, system ma go automatycznie wylogować".
Piszemy do tego oczywisty przypadek użycia (w celu zasugerowania przypadku
testowego) i już mamy przypadek użycia występujący samodzielnie.

>> Po sprawiedliwości: jeśli potraktuje się ją z przymrużeniem oka, to kilku
> Cocburn napiosał na tyle wiele użytecznych nieoczywistości, iż zgodnie z
> rachunkiem prawdopodobieństwa nie stało się to przypadkowym wciśnieciem
> sekwencji klawiszy - i należy się tu obiektywnie dobra opinia. W sprawach,
> gdzie ewidentie generuje zgrzyty - poprosiłabym samego autora o
> uzasadnienie istnienia takich himer :), przed wydaniem ostatecznej,
> neagtywnej w tym obszarze opinii.
Jestem bardziej krytyczny dla błędów w tego typu publikacjach. I to błędów
tego kalibru! Weźmy pod uwagę, że dla niektórych to może być pierwsza
książka o analizie wymagań. Cockburn z analizą wymagań wchodzi w kompetencje
projektowe i takie podejście proponuje czytelnikom. Czasem uważam, że lepiej
czegoś nie wiedzieć niż wiedzieć źle. 
Przykład: lepiej nie wiedzieć jak się przechodzi przez ulicę niż wiedzieć,
że na czerwonym świetle.



-- 
Mariusz Lotko