🚀 go-pugleaf

yapann wrote:

> Użytkownik "Mariusz Lotko" <imie.nazwisko@wp.pl> napisał w wiadomoś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>>.
> 
> oj nienie (ale wiedziałam, że tak ktoś zrozumie -  I TO JEST WŁAŚNIE DOWÓD
> na to , iż jedno (to/takie właśnie ) przekłamnie szwęda się po necie i
> rozmnaża! Przeczytaj proszę moje zdanie raz jeszcze, a ja wyjaśnię co w
> nim istotnie było, a czego nie, otóż:
> 
> Mogę w pewnym przebiegu pewną podsekwencję (załóżmy, iż wykonywana jest
> ona raz) zaklamrować i nazwać includem. Tak? Ale później mogę się obrazić
> na include' i swoja podsekwencję spowrotem 'wtekstować' w mój przebieg?
> Mogę? W tym znaczeniu, zastosowanie include'a jest opcjonalne. Mogę
> przecież niejdeen z algorytmów (oczywiśnie, nie każdy, lecz wiele) napisać
> z użyciem modularyzacji, lub bez niej. Tak?
Piszesz tutaj o swoistym "refaktoringu use-case'ów", który można by nazwać
"inline use-case".
Ja natomiast przepisałem bezwstydnie, lekko parafrazując, specyfikację
UML 2.0.


> 
>> I tak i nie. Taki przypadek realizuje pewien cel użytkownika: zapewnienie
>> dostępu do pewnych danych
> Nie mogę się zgodzić: jeśli PU jest 'logowanie' to celem jest zalogowanie.
Nie zawsze czynność (użycie) jest wykonane przez aktora, dla którego jest
zdefiniowany cel. Być może nie wszystkim podoba się fakt, że do systemu
trzeba się logować, ale ktoś taki cel zdefiniował.

> A jeśli tak, jak napisałeś - to nazwą i celem PU będzie jakaś konsekwencja
> zalogwania (wyświetlenie info o koncie, udostępnienie okna gównego z menu,
> czy też cokowliek mniej lub jawniej będącym czymś powstałym w konsekwencji
> zalogowania. W drugim z przyopadków zawsze logowanie mozesz wyłączyć do
> include'a. W pierwszym - zawsze masz ten sam PU, który będzie miał prawo
> bytu wówczas, gdy piszesz system, gdzie logowanie jest funkcjonalnością.
> Czemu nie - napiszmy programik do prezentacji autoryzacji /
> uwierzytelnienia.
Wydaje mi się, że zanadto tutaj teoretyzujesz :-)

> 
>> 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.
> nazwałabym to wymaganiem specjalnym (niefunkcjonalnym) do jakiejś
> funkcjonalności (gwarancją systemu w obrębie innej/innych 
> funkcjonalności), nadal nie zgodzę się, iż 'zalogowanie' jest tu funkcją
> (funcjonalnością). Chyba, że piszemy system_do_logowania.
A gdzie jest napisane, że tylko wymagania funkcjonalne mogą posiadać
odpowiadające im przypadki użycia?

> Nie zgodzę się, jako wcześniej, iz jest to przypadek użycia użycia - jest
> to przebieg.:p
Możesz wyjaśnić termin "przebieg"?

-- 
Mariusz Lotko