🚀 go-pugleaf

On 18 Cze, 12:51, "yapann" <yap...@odwa.pl> wrote:
> Pytanie do zajmujących się modelowaniem systemowych przypadków użycia: w
> 'całym' Internecie piszą, iż przypadek użycia typu <include> nie może
> istnieć 'samodzielnie', cytuję jeden z wielu tak twierdzących fragmentów:
>
> "Włączany przypadek nigdy nie występuje samodzielnie - jego egzemplarze mogą
> być tylko częścią większego zawierającego go przypadku użycia."

Ogólna uwaga: według mnie nie istnieją systemowe przypadki użycia.
Czym jest "egzemplarz przypadku użycia?????". Klasy mają egzemplarze.

Po drugie jeżeli jest <<include>> to sam z siebie nie ma on interfejsu
do aktora, czyż nie? Więc jak ma być samodzielny (gdyby tego czegoś
używać).

>
> Proszę o uzasadnienie takie (s)twierdzenia, gdyż osobiście niestety nie
> widzę żadnej logiki w tym, aby zabronić użyć 'modułu', jako odrębnie
> wykonywalnego scenariusza (jeśli spełnia określone warunki). W szczególności
> przecież, mogę napisać przypadek, który będzie zawierał inny, istniejący już
> przypadek najwyższego poziomu celu (- termin zaczerpnięty z lektury 'Jak
> pisać efektywne PU')?
>
Po drugie osobiście jestem wyznawcą teorii, że przypadki użycia to
metoda opisu interakcji użytkownika systemu (człowieka) z tymże
systemem. W tej postaci stanowią one liste wymagań co do tego
systemu.  Po trzecie do modelowania modułów pisanego systemu
(oprogramowania) w metodach obiektowych służą klasy a nie przypadki
użycia. Przypadki użycia sa

> Jeśli natomiast <include> będzie przypadkiem 'niższego poziomu celu', to
> wówczas owszem nie występuje jako samodzielny, ale nadal nie _dlatego_ zdaje
> mi się, iż jest <include>'m , lecz dlatego, iż nie realizuje (kompletnej)
> funkcjonalności systemowej.
>
> Proszę o dyskusję, dzięki.
>

Po trzecie uważam i zgadzam się z tymi książkami, które nie uznają
pojęcia aktora systemowego itp. że aktorem może być tylko człowiek.
Dla mnie drukarka to nie aktor który cos drukugje tylko obiekt, który
ma interfejs i metody. Odpowiada za pzretworzenie i wydrukowanie
przykazanego mu strumeinia danych.  Wymaga  interfejsu czyli
sterownika wybranej drukarki.  System współpracujący to obiekt a nie
aktor itp.


> Na podstawie powyższego rozumowania stwierdzam także, iż pokutuje powszechne
> powielanie błędnej interpretacji / tłumaczenia, gdyż powinno być: przypadek
> bazowy nie może istnieć samodzielnie bez przypadku włączanego (w odróżnieniu
> od tego, iż przypadek bazowy może istnieć bez przypadku rozszerzającego).
>
> Zachęcam do komentarzy

Wiecej o tym co napisałem między innymi tu:
http://www.merlin.com.pl/frontend/browse/product/1,352462.html

ToJaJarek wrote:

> On 18 Cze, 12:51, "yapann" <yap...@odwa.pl> wrote:
>> Pytanie do zajmujących się modelowaniem systemowych przypadków użycia: w
>> 'całym' Internecie piszą, iż przypadek użycia typu <include> nie może
>> istnieć 'samodzielnie', cytuję jeden z wielu tak twierdzących fragmentów:
>>
>> "Włączany przypadek nigdy nie występuje samodzielnie - jego egzemplarze
>> mogą być tylko częścią większego zawierającego go przypadku użycia."
> 
> Ogólna uwaga: według mnie nie istnieją systemowe przypadki użycia.
Według mnie również. Ale A. Cockburn, uważany tu i ówdzie za guru przypadków
użycia, używa takiego pojęcia. Ba! W swojej książce zamieścił "przypadek
użycia", który specyfikuje wymagania odnośnie implementacji wielowątkowości.
Stwierdzenia w rodzaju "blokada tylko do odczytu jest kowertowana na...".
Wydaje mi się, że coś takiego _nie_ powinno być specyfikowane przypadkiem
użycia, a raczej, jak każde wymaganie, językiem użytkownika. Użytkownikiem w
tym przypadku jest programista/projektant, więc taka specyfikacja powinna
się odbyć za pomocą diagramów implementacyjnych: stanu, przebiegów
czasowych, sekwencji, itd.

Myślę, że pojęcie "systemowy przypadek użycia" powstało jako konsekwencja
terminu "wymaganie systemowe".


> Czym jest "egzemplarz przypadku użycia?????". Klasy mają egzemplarze.
UC jest elementem behawioralnym. Niech mi ktoś pokaże "egzemplarz
czytania" :-) Ale to jest kolejny "kwiatek" z tej książki.

> Po drugie jeżeli jest <<include>> to sam z siebie nie ma on interfejsu
> do aktora, czyż nie? Więc jak ma być samodzielny (gdyby tego czegoś
> używać).
Specyfikacja UML2.0 nie wspomina nic o interfejsie do aktora, czy
zawieraniu.
Stwierdza się jedynie, że:
- włączający przypadek użycia nie może mieć poprawnego przebiegu bez
wykonania włączanych przypadków użycia (stąd kierunek strzałki)
- 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.

Co jest jednak faktem, ilekroć staram się wymyślić przypadek, gdzie 
włączany przypadek byłby samodzielny, dochodzę do <<extend>>, np.
- logowanie - może występować samodzielnie i jako część innego przypadku
użycia. Jednak należy zauważyć, że "tylko w przypadku, gdy użytkownik
nie jest zalogowany", a więc warunkowo.


>> Proszę o uzasadnienie takie (s)twierdzenia, gdyż osobiście niestety nie
>> widzę żadnej logiki w tym, aby zabronić użyć 'modułu', jako odrębnie
>> wykonywalnego scenariusza (jeśli spełnia określone warunki). W
>> szczególności przecież, mogę napisać przypadek, który będzie zawierał
>> inny, istniejący już przypadek najwyższego poziomu celu (- termin
>> zaczerpnięty z lektury 'Jak pisać efektywne PU')?
Też się wziąłem za tę lekturę. Proponuję potraktować ją z przymrużeniem oka.
Wprawdzie autor jest przedstawiony jako ekspert w tworzeniu oprogramowania,
jednak jego bujanie w chmurach i często powtarzające się stwierdzenia:
"jeden z moich studentów..." należy raczej wnioskować, że o przemyśle
to głównie czytał. Lub też "zapomniał wół jak cielęciem był" :-)

Po sprawiedliwości: jeśli potraktuje się ją z przymrużeniem oka, to kilku
dobrych praktyk można się nauczyć.

>>
> Po drugie osobiście jestem wyznawcą teorii, że przypadki użycia to
> metoda opisu interakcji użytkownika systemu (człowieka) z tymże
> systemem. W tej postaci stanowią one liste wymagań co do tego
> systemu.  Po trzecie do modelowania modułów pisanego systemu
> (oprogramowania) w metodach obiektowych służą klasy a nie przypadki
> użycia. Przypadki użycia sa

Nie wiem, co chciałeś napisać dalej, ale z początkiem prawie w pełni się
zgadzam...

> 
>> Jeśli natomiast <include> będzie przypadkiem 'niższego poziomu celu', to
>> wówczas owszem nie występuje jako samodzielny, ale nadal nie _dlatego_
>> zdaje mi się, iż jest <include>'m , lecz dlatego, iż nie realizuje
>> (kompletnej) funkcjonalności systemowej.
>>
>> Proszę o dyskusję, dzięki.
>>
> 
> Po trzecie uważam i zgadzam się z tymi książkami, które nie uznają
> pojęcia aktora systemowego itp. że aktorem może być tylko człowiek.
> Dla mnie drukarka to nie aktor który cos drukugje tylko obiekt, który
> ma interfejs i metody. Odpowiada za pzretworzenie i wydrukowanie
> przykazanego mu strumeinia danych.  Wymaga  interfejsu czyli
> sterownika wybranej drukarki.  System współpracujący to obiekt a nie
> aktor itp.
...bo uznaję aktorów systemowych. Szcczególnie takich, którzy wzbudzają
system do działania, a są systemami zewnętrznymi. Owszem, zaraz możesz
napisać, że w takim razie muszę mu wystawić jakiś interfejs. Ale czym
się różni interfejs "do wywoływania" od interfejsu "do klikania"?

Nie chcę się tutaj zanadto spierać, bo rozumiem Twoją argumentację.
Często właśnie jakieś "drukarki", czy inne rzeczy, z którymi nasz system
musi się komunikować, to "aktory". To takie średnie rozwiązanie.

> 
> 
>> Na podstawie powyższego rozumowania stwierdzam także, iż pokutuje
>> powszechne powielanie błędnej interpretacji / tłumaczenia, gdyż powinno
>> być: przypadek bazowy nie może istnieć samodzielnie bez przypadku
>> włączanego (w odróżnieniu od tego, iż przypadek bazowy może istnieć bez
>> przypadku rozszerzającego).
>>
>> Zachęcam do komentarzy
> 
> Wiecej o tym co napisałem między innymi tu:
> http://www.merlin.com.pl/frontend/browse/product/1,352462.html

Przypadek włączający (nadrzędny) nie może być _wykonany_ bez włączanych
(podrzędnych). Trudno mówić o istnieniu czynności. A przynajmniej
niezgrabnie.

-- 
Mariusz Lotko

Użytkownik "ToJaJarek" <tojajarek@gmail.com> napisał w wiadomości

Twoje rozumowanie jest ok. Oczywiście, rozumiejąc Twoje założenia.



Ponieważ owszem:

> do modelowania modułów pisanego systemu [.]

- rzeczywiście nigdy w życiu, bo ..systemowe przypadki użycia nie służą 
opisowi _rozwiązań
> [.] służą klasy"

- a i owszem.


Dlatego w zasadzie rozumiem Twoje poprzednie stwierdzenie "nie istnieją 
systemowe przypadki użycia". Kwestia definicji, I tak:

"przypadki użycia to metoda opisu interakcji użytkownika systemu" - tak 
długo to jest prawda, jak się nie zacznie (a zaczęto, dla pewnych powodów) 
definiować sztucznego tworu, jakim jest np. <include>. I przyznam że 
właściwie to zreflektowałam się do twej uwagi - podzielam, rzeczywiście: to 
nie powinien być i nie jest żaden przypadek. (przykład logowania użytkownika 
jest tylko wyjątkiem powodującym utwierdzanie w budowaniu niezbyt 
użytecznych definicji).



Kwestia aktorów natomiast jest mało istotna:

"aktorem może być tylko człowiek" - dziś to człowiek, a jutro zostanie 
podmieniony na maszynę i kawałek aktora - ja bym nie budowała 
ograniczających definicji. Z resztą w ogóle aktor nie ma znaczenia w 
przpadkach! - istotna jest wyłącznie jego rola (tutaj aktora wyrzucamy do 
kosza, twór jednorazowego użytku).





Dzięki za dotychczasową i dalszą dyskusję.

Użytkownik "Mariusz Lotko" <imie.nazwisko@wp.pl> napisał w wiadomości 
news:f592k6$j46

> Cockburn
> zamieścił "przypadek
> który specyfikuje wymagania odnośnie implementacji wielowątkowości.
> Stwierdzenia w rodzaju "blokada tylko do odczytu jest kowertowana na...".
> Wydaje mi się, że coś takiego _nie_ powinno być specyfikowane przypadkiem
no ja ten wyskok (!) Cocburna traktuję jako szakleństwo artysty. A w ogóle, 
na stweirdzenie, że przy użyciu PU można modelować aspekty architektury 
syst, uszy więdną mi do samej podstawy.

> taka specyfikacja powinna
> się odbyć za pomocą diagramów implementacyjnych: stanu, przebiegów
oczywistość, założę się, że o tym jest w Biblii! (Tylko się języków nie 
uczymy :])

> Myślę, że pojęcie "systemowy przypadek użycia" powstało jako konsekwencja
> terminu "wymaganie systemowe".
raczej wg mnie jako kontr-nazwa do biznesowego PU.

>> Czym jest "egzemplarz przypadku użycia?????"
artefaktem utworzonym przy użyciu notacji PU?

> - 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ą

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





ps:
> 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.

reasumując, zaproponuję:
1) 'przypadek typu <include>', powinno się raz na zawsze zaminić na 
'przebieg typu <include>'
2) bzdurę (<-według mnie), iż przypadek typu <include> nie może występować 
samodzielnie, należałoby skasować z całego internetu. Na szczęście 
zastosowanie reguły 1) załatwia sprawę.


proszę o Wasze  komentarze do powyższych tez, dzięki. 

On 20 Cze, 11:26, "yapann" <yap...@odwa.pl> wrote:
> reasumując, zaproponuję:
> 1) 'przypadek typu <include>', powinno się raz na zawsze zaminić na
> 'przebieg typu <include>'
> 2) bzdurę (<-według mnie), iż przypadek typu <include> nie może występować
> samodzielnie, należałoby skasować z całego internetu. Na szczęście
> zastosowanie reguły 1) załatwia sprawę.
>
> proszę o Wasze  komentarze do powyższych tez, dzięki.

przeszedłem wszytkie Twoje kometarze i w zasadzie ... witam w
klubie :). Dodał bym tylko tyle: nie lubię przypadków użycia w wersji
ludziki i bąbelki bo to wg, mnie jakaś kulawa atrapa diagramu klas.
Lubie przypadki użycia w rozumieniu scenariuszy zamienianych
ewentualnie z tekstu na diagramy sekwencji (traktuje taka zamianę jako
testowanie logiki słownomuzycznego opisu uzyskanego z wywiadów).

Metoda analizy Catalysis jest tu dobrym przykładem (w zasadzie nie ma
tam mowy o przypadkach użycia).  Doświadczenie moje plus tę metodę
stosuję do wypracowania wymagań metodą: (1) Model procesowy całej
firmy (raczej BPMN bo biznesowi ludzie nie kumają UML'a), (2) na
modelu procesów wybieram z np. zarzadem firmy jej obszar dla którego
planowany jest system, dla każdego tak wybranego procesu biznesowego
określam jego interakcje z planowanych systemem -> mam wymagania
funkjconalne w postaci przypadków użycia, (3) tworzę scenariusze dla
przypadkow użycia (np. opis + tabela lub/i diagramy sekwencji), (4)
model obiektowy firmy (diagram klas, model logiczny danych), (5)
odddaje taki model dalej inżynierom systemowym i programistom.

Nie ma tu miejsca na bąbelki i ludziki. Mój wniosek? zapomnieć o
przypadkach użycia i <<include>>, no troszke radykalny asle...;)

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

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?

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

> 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.
Nie zgodzę się, jako wcześniej, iz jest to przypadek użycia użycia - jest to 
przebieg.:p

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

Użytkownik "Mariusz Lotko" <imie.nazwisko@wp.pl> napisał w wiadomości 
news:f5m9h5$6a9

> przepisałem bezwstydnie, lekko parafrazując, specyfikację
> UML 2.0.
Acha. Acz ty przepisałeś prawidłowo i nie skończyłeś tam, gdzie wielu 
innych: czyli w przeinterpretowaniu logicznego następstwa, że:
  - przypadek _bazowy_ nie może istnieć bez swego include'a.
  - przypadek _bazowy_ może istnieć bez swego extend'a.
w odóróżnieniu od (mącących i bezuzytecznych) wniosków (które nota bene moim 
zdaniem wynikają z fatalnych tłumaczeń), jakoby:
  - przypadek include nie może występować samodzielnie (co z tego, że to nie 
występuje)
  - przypadek extend może występować samodzielnie (co z tego, że to 
przypadek rozszerzający ma 'wiedzę' o swoim wykonaniu)
które to informacje niczemu nie służą (z resztą pradziwości przynajlnej z 
nich odmawiam).

> 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ł.
nadal zaryzykuję podtrzymanie opinii, iż jednak jest to wymaganie 
niefunkcjonalne, nie cel. (Słowy innemi, gdyby nagle wszyscy byli uczciwi, 
to logowanie służyłoby już tylko np. segregacji dostępu (zaloguj sie jako 
kasjer kiedy zamierzasz tylko sprzedawać, zaloguj się jako kierownik, aby 
dokonać zaawansowanych operacji..) - funkcjonalności systemu natomiast nie 
zmieniają się (nadal ma wypłacać pieniądze i pakować prezenty)

>> Czemu nie - napiszmy programik do prezentacji autoryzacji /
>> uwierzytelnienia.
> Wydaje mi się, że zanadto tutaj teoretyzujesz :-)
Zdefiniuj 'zanadto' :p. Isototą jest znalezienie przykładu, które jest dobrą 
metodą obalania tez, a ja niniejsztym obalam tezę, jakoby include mógł być 
przypadkiem użycia.

> A gdzie jest napisane, że tylko wymagania funkcjonalne mogą posiadać
> odpowiadające im przypadki użycia?
bo założenie jest, że mówimy o zadaniowych PU :p .
Niefunkjonalne mogą posiadać przebieg (stanowiący część jakiegoś scenariusza 
przypadku). - Dotyczy to tych wymagań niefunkcjonalnych, które wynikają z 
gwarancji systemu w obrębie udostepnianej funkcjonalności (PU). Jeśli 
natomiast jest to wymaganie niefunkcjonalne 'ogólnosystemowe' (nie będące 
obwarowaniem żadnego z przypadków użycia (a logowanie jest (- zwykle 
każdego))) - wówczas _można (i wygodnie będzie) użyć notacji PU do 
zamodelowania/udokumenetowania. Przykład spod hebla: system dla ośób 
niepełnosprawnych: każda reakcja systemu powinna byc opóźniona o n sekund, 
gdzie n zalezy od ilości zwracanych wyników w taki a siaki sposób. Nadal nie 
zmienia się zestaw funkcji świadczonych użytkownikowi (zadaniowych 
przypadków użycia), chociaż istnieje przebieg, który należy uwzględnić i 
któs go przedstawił jako PU.

> Możesz wyjaśnić termin "przebieg"?
zestaw akcji[/zdarzeń/..], mogący zawierać podciągi (akcje o zdefiniowanej 
wzajemnej kolejności).

"yapann" <yapann@odwa.pl> writes:

[...]

> Proszę o uzasadnienie takie (s)twierdzenia, gdyż osobiście niestety
> nie widzę żadnej logiki w tym, aby zabronić użyć 'modułu', jako
> odrębnie wykonywalnego scenariusza (jeśli spełnia określone
> warunki).

Ja bym w opisanym przypadku zamiast <<include>> użył <<extend>>.

"yapann" <yapann@odwa.pl> writes:

[...]

>> Wydaje mi się, że zanadto tutaj teoretyzujesz :-)
> Zdefiniuj 'zanadto' :p. Isototą jest znalezienie przykładu, które
> jest dobrą metodą obalania tez, a ja niniejsztym obalam tezę, jakoby
> include mógł być przypadkiem użycia.

Ale zdajesz sobie sprawę, że to jest tylko konwencja?

On Mon, 18 Jun 2007 12:51:14 +0200, yapann wrote:

> w 'całym' Internecie piszą, iż przypadek użycia typu
> <include> nie może istnieć 'samodzielnie'

Chyba jednak nie w całym, skoro jeszcze się na takie
stwierdzenia nie natknąłem ;) A nawet jakbym się natknął
to bym pewnie to olał, bo nieraz miałem przypadki, że
jeden przypadek użycia wywoływany przez aktora był
jednocześnie nieodzowną częścią innego przypadku użycia,
też wywoływanego przez aktora, więc żeby nie powtarzać
opisów używałem <<include>> ;)

> "Włączany przypadek nigdy nie występuje samodzielnie

Nigdy nie mów "nigdy" ;)
Taki mały kontr-przykład:

                 .-------------------------------.
                 |     _-----------------_   IDE |
                 |__--( Skompiluj moduł   )      |
   O        __--"T     '-----------------'       |
 --+--  --""     |              ^                |
   |             |              : <<include>>    |
  /'\    --__    |              :                |
 /   \       ""--L_     _---------------------_  |
                 | ""--( Zbuduj cały projekt   ) |
 Programista     |      '---------------------'  |
                 '-------------------------------'
Wyjaśnienie:
Programista używający IDE może wydać polecenie skompilowania
wybranego modułu [np. by zobaczyć, czy nie zrobił w nim
błędów, albo dlatego że coś w nim zmienił i wymaga on
rekompilacji ;J]. Może też chcieć czasami przebudować cały
projekt od nowa i wtedy siłą rzeczy przebudowywane są też
wszystkie moduły składające się na cały projekt, a więc
są używane czynności z przypadku użycia "Skompiluj moduł".
Są one ZAWSZE WYMAGANE do zbudowania całego projektu, stąd
rozsądnym jest użycie relacji <<include>>, by nie trzeba
było się niepotrzebnie powtarzać ;J
Oczywiście to, że przypadek użycia "Skompiluj moduł" jest
dołączany przez jakiś inny przypadek użycia i jest jego
częścią nie oznacza jeszcze, że nie można go używać
samodzielnie ;J co zresztą widać na załączonym obrazku ;)
                            
> jego egzemplarze mogą być tylko częścią większego
> zawierającego go przypadku użycia."

Tere fere :P ;)

> Jeśli natomiast <include> będzie przypadkiem 'niższego
> poziomu celu', to wówczas owszem nie występuje jako
> samodzielny, ale nadal nie _dlatego_ zdaje mi się, iż
> jest <include>'m , lecz dlatego, iż nie realizuje
> (kompletnej) funkcjonalności systemowej.

Takie też się zdarzają. Często robi się tak wtedy, gdy
chce się po prostu "wyłączyć wspólny czynnik" kilku
przypadków użycia "przed nawias" ;)  Na przykład zarówno
sprawdzenie salda, jak i wypłacenie gotówki z bankomatu,
wymagają włożenia karty, więc żeby nie powtarzać tego w
każdym przypadku użycia bankomatu można tą wspólną akcję
wyłączyć przed nawias i użyć <<include> ;) Ale nie wkłada
się karty "bez celu" ;) więc ten wyłączony wspólny czynnik
nie jest używany bezpośrednio przez aktora.

> Na podstawie powyższego rozumowania stwierdzam także, iż
> pokutuje powszechne powielanie błędnej interpretacji /
> tłumaczenia, gdyż powinno być: przypadek bazowy nie może
> istnieć samodzielnie bez przypadku włączanego (w odróżnieniu
> od tego, iż przypadek bazowy może istnieć bez przypadku
> rozszerzającego).

Pewnie tu jest właśnie pies pogrzebany. Jeden źle zrozumiał,
źle przetłumaczył, a inni powtarzali te jego "mądrości"
powołując się na jego "autorytet" ;J  Dlatego warto zawsze
kwestionować autorytety i myśleć samodzielnie. Szukać
wyjątków w każdej regule ;)

Dokładnie tak pewnie to powinno brzmieć: że przypadek
dołączający nie może istnieć bez dołączanego, bo MUSI
go dołączyć, ZAWSZE, BEZWARUNKOWO, bo jest on jego
NIEODERWALNĄ CZĘŚCIĄ, i dlatego jest dołączany przez
<<include>>, a nie przez <<extends>> który może być
dołączony warunkowo, opcjonalnie.
Ale to oczywiście nie działa w obie strony [jak widać
na wielu przykładach ;J] - przypadek dołączany może
być użyty samodzielnie, jeśli stanowi sensowną akcję
używaną przez aktora.

-- 
SasQ

SasQ <sasq1@go2.pl> writes:

> On Mon, 18 Jun 2007 12:51:14 +0200, yapann wrote:
>
>> w 'całym' Internecie piszą, iż przypadek użycia typu
>> <include> nie może istnieć 'samodzielnie'
>
> Chyba jednak nie w całym, skoro jeszcze się na takie stwierdzenia
> nie natknąłem ;) A nawet jakbym się natknął to bym pewnie to olał,
> bo nieraz miałem przypadki, że jeden przypadek użycia wywoływany
> przez aktora był jednocześnie nieodzowną częścią innego przypadku
> użycia, też wywoływanego przez aktora, więc żeby nie powtarzać
> opisów używałem <<include>> ;)
>
>> "Włączany przypadek nigdy nie występuje samodzielnie
>
> Nigdy nie mów "nigdy" ;)
> Taki mały kontr-przykład:
>
>                  .-------------------------------.
>                  |     _-----------------_   IDE |
>                  |__--( Skompiluj moduł   )      |
>    O        __--"T     '-----------------'       |
>  --+--  --""     |              ^                |
>    |             |              : <<include>>    |
>   /'\    --__    |              :                |
>  /   \       ""--L_     _---------------------_  |
>                  | ""--( Zbuduj cały projekt   ) |
>  Programista     |      '---------------------'  |
>                  '-------------------------------'

To są raczej funkcje, a nie przypadki użycia.  Przypadki użycia tym
różnią się od funkcji, że uwzględniają właśnie złożoną kooperację
użytkownik-program.

> Wyjaśnienie:
> Programista używający IDE może wydać polecenie skompilowania
> wybranego modułu [np. by zobaczyć, czy nie zrobił w nim
> błędów, albo dlatego że coś w nim zmienił i wymaga on
> rekompilacji ;J]. Może też chcieć czasami przebudować cały
> projekt od nowa i wtedy siłą rzeczy przebudowywane są też
> wszystkie moduły składające się na cały projekt,

Ja bym wszystkie te czynności umieścił w jednym przypadku użycia
'praca interaktywna z kodem' (czyli redagowanie tekstu programu
zakończona kompilacją, jeden etap cyklu napisz-skompiluj-przetestuj).

> a więc są używane czynności z przypadku użycia "Skompiluj moduł".
> Są one ZAWSZE WYMAGANE do zbudowania całego projektu, 

Nie, przynajmiej w większości znanych mi środowisk programistycznych.
Mylisz pojęcie przypadku użycia z pojęciem funkcji systemu.

> stąd rozsądnym jest użycie relacji <<include>>, by nie trzeba było
> się niepotrzebnie powtarzać ;J

No właśnie w twoim przykładzie wszystko wskazuje na to, że programista
_musi_ się powtarzać, czyli w ramach przypadku użycia 'zbuduj cały
projekt' musi wykonać takie same czynności, jak w przypadku, gdy
kompiluje pojedynczy moduł.

-- 
http://www.piotr.dembiński.prv.pl

pdemb@gazeta.pl (Piotr Dembiński) writes:

[...]

> To są raczej funkcje, a nie przypadki użycia.  Przypadki użycia tym
> różnią się od funkcji, że uwzględniają właśnie złożoną kooperację
> użytkownik-program.

Jeśli chodzi o podobny ale bardziej obiektowy przykład, to może być
'redaguj plik' i 'praca interaktywna z kodem projektu'.

pdemb@gazeta.pl (Piotr Dembiński) writes:

[...]

> To są raczej funkcje, a nie przypadki użycia.  Przypadki użycia tym
> różnią się od funkcji, że uwzględniają właśnie złożoną kooperację
> użytkownik-program.

Jeśli chodzi o podobny ale bardziej obiektowy przykład, to może być
'redagowanie pliku' i 'praca interaktywna z kodem projektu'.

On 16 Wrz, 20:34, pd...@gazeta.pl (Piotr Dembiński) wrote:

> To są raczej funkcje, a nie przypadki użycia. Przypadki użycia tym
> różnią się od funkcji, że uwzględniają właśnie złożoną kooperację
> użytkownik-program.

Więc podaj jakiś lepszy przykład. Sam jestem ciekaw.

> Ja bym wszystkie te czynności umieścił w jednym przypadku użycia
> 'praca interaktywna z kodem' (czyli redagowanie tekstu programu
> zakończona kompilacją, jeden etap cyklu napisz-skompiluj-przetestuj).

Zależy od poziomu abstrakcji ;J
Tak do sprawy podchodząc, to mógłbym nawet zrobić jeden przypadek
użycia: "Używaj IDE" :P  Dlatego uważam, że mój przykład jest dobry,
dopóki nie interesują nas szczegóły implementacji tych przypadków
użycia, czyli jak dokładnie te zadania są realizowane.

> Nie, przynajmiej w większości znanych mi środowisk programistycznych.

No ok, jakby wejść w szczegóły to się okaże, że IDE nie musi ponownie
kompilować modułów, które się nie zmieniły ;J ale dopóki jest to
przezroczyste dla użytkownika, on widzi to jako dwa przypadki użycia,
z których może użyć obu osobno, ale jeden włącza automatycznie
działanie drugiego.

> Mylisz pojęcie przypadku użycia z pojęciem funkcji systemu.

Nie ma sprawy, pokaż mi różnicę ;) Człowiek się całe życie uczy.

> No właśnie w twoim przykładzie wszystko wskazuje na to, że programista
> _musi_ się powtarzać, czyli w ramach przypadku użycia 'zbuduj cały
> projekt' musi wykonać takie same czynności, jak w przypadku, gdy
> kompiluje pojedynczy moduł.

Nie musi, bo nie musi wykonywać dołączanego przypadku użycia
"ręcznie". MOŻE to jednak zrobić i kompilować sobie każdy moduł
ręcznie, zgodnie z pierwszym z tych przypadków użycia ;)

--
SasQ

sasq.gamecreator@gmail.com writes:

> On 16 Wrz, 20:34, pd...@gazeta.pl (Piotr Dembiński) wrote:
>
>> To są raczej funkcje, a nie przypadki użycia. Przypadki użycia tym
>> różnią się od funkcji, że uwzględniają właśnie złożoną kooperację
>> użytkownik-program.
>
> Więc podaj jakiś lepszy przykład. Sam jestem ciekaw.
>
>> Ja bym wszystkie te czynności umieścił w jednym przypadku użycia
>> 'praca interaktywna z kodem' (czyli redagowanie tekstu programu
>> zakończona kompilacją, jeden etap cyklu
>> napisz-skompiluj-przetestuj).
>
> Zależy od poziomu abstrakcji ;J

Chodzi właśnie o poziom abstrakcji.  'Kompiluj' i 'zbuduj' to będą
metody klas, a 'redagowanie tekstu' to będzie przypadek użycia.  
Tak to widzę.

> Tak do sprawy podchodząc, to mógłbym nawet zrobić jeden przypadek
> użycia: "Używaj IDE" :P

Jeśli projektujesz system, którego IDE jest tylko częścią (np. system
obsługi całego cyklu życia oprogramowania), to wcale nie jest to
absurdalne :)

> Dlatego uważam, że mój przykład jest dobry,

Nie jest, zwłaszcza że -- jak napisałem uprzednio -- wprowadza w błąd
osobę czytającą diagram.

> dopóki nie interesują nas szczegóły implementacji tych przypadków
> użycia, czyli jak dokładnie te zadania są realizowane.

To, co podałeś, to nazwy metod, a nie przypadki użycia.

>> Nie, przynajmiej w większości znanych mi środowisk
>> programistycznych.
>
> No ok, jakby wejść w szczegóły to się okaże, że IDE nie musi
> ponownie kompilować modułów, które się nie zmieniły ;J ale dopóki
> jest to przezroczyste dla użytkownika, on widzi to jako dwa
> przypadki użycia, z których może użyć obu osobno, ale jeden włącza
> automatycznie działanie drugiego.
>
>> Mylisz pojęcie przypadku użycia z pojęciem funkcji systemu.
>
> Nie ma sprawy, pokaż mi różnicę ;) Człowiek się całe życie uczy.

Różnica polega właśnie na złożonej kooperacji.  Innymi słowy --
pojęcie funkcji systemu jest IMO pojęciem znaczeniowo szerszym
od pojęcia przypadku użycia.

>> No właśnie w twoim przykładzie wszystko wskazuje na to, że
>> programista _musi_ się powtarzać, czyli w ramach przypadku użycia
>> 'zbuduj cały projekt' musi wykonać takie same czynności, jak
>> w przypadku, gdy kompiluje pojedynczy moduł.
>
> Nie musi, bo nie musi wykonywać dołączanego przypadku użycia
> "ręcznie". MOŻE to jednak zrobić i kompilować sobie każdy moduł
> ręcznie, zgodnie z pierwszym z tych przypadków użycia ;)

Dlatego to są nazwy metod, a nie przypadki użycia.

-- 
http://www.piotr.dembiński.prv.pl

On Thu, 20 Sep 2007 21:39:50 +0200, Piotr Dembiński wrote:

>> Więc podaj jakiś lepszy przykład. Sam jestem ciekaw.

To co, będzie jakiś przykład?

>> Zależy od poziomu abstrakcji ;J
>
> Chodzi właśnie o poziom abstrakcji. 'Kompiluj' i 'zbuduj' to
> będą metody klas, a 'redagowanie tekstu' to będzie przypadek
> użycia. Tak to widzę.

Ja widzę tak, że jeśli IDE jest pewnym systemem, z którym
użytkownik [aktor] pracuje, to "Skompiluj moduł" i "Zbuduj
cały projekt" [a nie "Kompiluj" u "Zbuduj"] będą przypadkami
użycia, bo są to sposoby, w jakie użytkownik chce używać
tego systemu. "Edytowanie kodu źródłowego" także jest
przypadkiem użycia IDE, nie przeczę. I chociaż przypadki
użycia często przekładają się w jakimś stopniu na metody
klas [jeśli IDE byłoby jedną wielką spasioną klasą :P],
to jednak na tym etapie nie traktuję ich jeszcze jako
metody klasy czy funkcje programu, bo przypadki użycia są
jak dla mnie bardziej abstrakcyjne i nie mówią jeszcze nic
o sposobie ich zaimplementowania w programie [czy to w
postaci metod klasy, czy zbioru metod wielu klas, czy
jakichś luźnych funkcji]. Jest to po prostu system widziany
oczami użytkownika, "na powierzchni", bez zagłębiania się
w szczegóły jego działania i realizacji poszczególnych zadań.

>> Tak do sprawy podchodząc, to mógłbym nawet zrobić jeden
>> przypadek użycia: "Używaj IDE" :P
>
> Jeśli projektujesz system, którego IDE jest tylko częścią
> (np. system obsługi całego cyklu życia oprogramowania), to
> wcale nie jest to absurdalne :)

Wiesz, z pewnego punktu widzenia to nawet słoń może wyglądać
jak mrówka ;J ale ja tutaj mówię o konkretnym przykładzie
[moim], a nie takim, w którym IDE jest tylko częścią systemu :P
Więc nie odbiegaj od tematu tylko po to, by z jakiegoś
odległego punktu widzenia mogło wyjść na twoje ;J

>> Dlatego uważam, że mój przykład jest dobry,
>
> Nie jest, zwłaszcza że -- jak napisałem uprzednio -- wprowadza
> w błąd osobę czytającą diagram.

Więc mi to udowodnij. Samo "nie jest" i "wprowadza w błąd"
nic dla mnie nie znaczy.

>> dopóki nie interesują nas szczegóły implementacji tych
>> przypadków użycia, czyli jak dokładnie te zadania są
>> realizowane.
>
> To, co podałeś, to nazwy metod, a nie przypadki użycia.

Możliwe, że z twojego punktu widzenia tak to wygląda,
jednak nadal nie chcesz wykazać mi różnicy, więc
nie potrafię dojść do tego, dlaczego tak ci się wydaje ;)

>>> Mylisz pojęcie przypadku użycia z pojęciem funkcji systemu.
>>
>> Nie ma sprawy, pokaż mi różnicę ;) Człowiek się całe życie
>> uczy.
>
> Różnica polega właśnie na złożonej kooperacji. Innymi słowy --
> pojęcie funkcji systemu jest IMO pojęciem znaczeniowo szerszym od
> pojęcia przypadku użycia.

Aha... to super... fajnie godosz :>  ino mało konkretnie ;)

>> Nie musi, bo nie musi wykonywać dołączanego przypadku użycia
>> "ręcznie". MOŻE to jednak zrobić i kompilować sobie każdy moduł
>> ręcznie, zgodnie z pierwszym z tych przypadków użycia ;)
> 
> Dlatego to są nazwy metod, a nie przypadki użycia.

Ja nie widzę, jak jedno miałoby wynikać z drugiego.

-- 
SasQ

SasQ <sasq1@go2.pl> writes:

> On Thu, 20 Sep 2007 21:39:50 +0200, Piotr Dembiński wrote:
>
>>> Więc podaj jakiś lepszy przykład. Sam jestem ciekaw.
>
> To co, będzie jakiś przykład?

Przecież podałem przykład.

>>> Zależy od poziomu abstrakcji ;J
>>
>> Chodzi właśnie o poziom abstrakcji. 'Kompiluj' i 'zbuduj' to będą
>> metody klas, a 'redagowanie tekstu' to będzie przypadek użycia.
>> Tak to widzę.
>
> Ja widzę tak, że jeśli IDE jest pewnym systemem, z którym użytkownik
> [aktor] pracuje, to "Skompiluj moduł" i "Zbuduj cały projekt" [a nie
> "Kompiluj" u "Zbuduj"] będą przypadkami użycia

Będą, ale IMO zdegenerowanymi :)

> , bo są to sposoby, w jakie użytkownik chce używać tego
> systemu. "Edytowanie kodu źródłowego" także jest przypadkiem użycia
> IDE, nie przeczę. I chociaż przypadki użycia często przekładają się
> w jakimś stopniu na metody klas [jeśli IDE byłoby jedną wielką
> spasioną klasą :P], to jednak na tym etapie nie traktuję ich jeszcze
> jako metody klasy czy funkcje programu, bo przypadki użycia są jak
> dla mnie bardziej abstrakcyjne

Przypadki użycia nie są abstrakcyjne.

> i nie mówią jeszcze nic o sposobie ich zaimplementowania w programie
> [czy to w postaci metod klasy, czy zbioru metod wielu klas, czy
> jakichś luźnych funkcji]. Jest to po prostu system widziany oczami
> użytkownika, "na powierzchni", bez zagłębiania się w szczegóły jego
> działania i realizacji poszczególnych zadań.

Niemniej jednak to nie jest abstrakcja.

>>> Tak do sprawy podchodząc, to mógłbym nawet zrobić jeden przypadek
>>> użycia: "Używaj IDE" :P
>>
>> Jeśli projektujesz system, którego IDE jest tylko częścią
>> (np. system obsługi całego cyklu życia oprogramowania), to wcale
>> nie jest to absurdalne :)
>
> Wiesz, z pewnego punktu widzenia to nawet słoń może wyglądać
> jak mrówka ;J ale ja tutaj mówię o konkretnym przykładzie
> [moim], a nie takim, w którym IDE jest tylko częścią systemu :P
> Więc nie odbiegaj od tematu

Cały czas dyskutujemy na temat przypadków użycia typu <<include>>,
a dokładnie na temat tego, czy takie przypadki użycia mogą być
związane z aktorem.  Właśnie zajrzałem do normy ISO/IEC 19501:2005
i wygląda na to, że nie stawia ona wymagania co do związku przypadku
użycia typu <<include>> z aktorem.

> tylko po to, by z jakiegoś odległego punktu widzenia mogło wyjść 
> na twoje ;J

Sorry, ale nie mam takich wymagań, żeby koniecznie wyszło na moje.

>>> Dlatego uważam, że mój przykład jest dobry,
>>
>> Nie jest, zwłaszcza że -- jak napisałem uprzednio -- wprowadza
>> w błąd osobę czytającą diagram.
>
> Więc mi to udowodnij. 
> Samo "nie jest" i "wprowadza w błąd" nic dla mnie nie znaczy.

Wprowadza w błąd.  Ja bym to narysował inaczej :)

>>> dopóki nie interesują nas szczegóły implementacji tych przypadków
>>> użycia, czyli jak dokładnie te zadania są realizowane.
>>
>> To, co podałeś, to nazwy metod, a nie przypadki użycia.
>
> Możliwe, że z twojego punktu widzenia tak to wygląda, jednak nadal
> nie chcesz wykazać mi różnicy, więc nie potrafię dojść do tego,
> dlaczego tak ci się wydaje ;)

Pokazałem różnicę.  Włączenie przypadku użycia kompilowania modułu
w skład przypadku użycia budowania projektu sugeruje, że na kooperację
użytkownika z systemem wiążącą się ze zbudowaniem całego projektu
składa się również kooperacja użytkownika z systemem wiążąca się ze
zbudowaniem pojedynczego modułu.

>>>> Mylisz pojęcie przypadku użycia z pojęciem funkcji systemu.
>>>
>>> Nie ma sprawy, pokaż mi różnicę ;) Człowiek się całe życie uczy.
>>
>> Różnica polega właśnie na złożonej kooperacji. Innymi słowy --
>> pojęcie funkcji systemu jest IMO pojęciem znaczeniowo szerszym od
>> pojęcia przypadku użycia.
>
> Aha... to super... fajnie godosz :> ino mało konkretnie ;)

IMO bardzo konkretnie.

>>> Nie musi, bo nie musi wykonywać dołączanego przypadku użycia
>>> "ręcznie". MOŻE to jednak zrobić i kompilować sobie każdy moduł
>>> ręcznie, zgodnie z pierwszym z tych przypadków użycia ;)
>> 
>> Dlatego to są nazwy metod, a nie przypadki użycia.
>
> Ja nie widzę, jak jedno miałoby wynikać z drugiego.

Oczywiście nie wynika.  Po prostu ja bym to w ten sposób zamodelował.

-- 
http://www.piotr.dembiński.prv.pl

pdemb@gazeta.pl (Piotr Dembiński) writes:

[...]

> Włączenie przypadku użycia kompilowania modułu w skład przypadku
> użycia budowania projektu sugeruje, że na kooperację użytkownika
> z systemem wiążącą się ze zbudowaniem całego projektu składa się
> również kooperacja użytkownika z systemem wiążąca się ze zbudowaniem
> pojedynczego modułu.

...oczywiście takie rozwiązanie również jest możliwe (np. odpowiednio
napisany plik dla programu 'make').