Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

To inaczej:
- za pomocą np. diagramu czynności pokaż jak wygląda proces korzystania z tej galerii z perspektywy użytkownika (proces rejestracji, proces dodania nowego zdjęcia do galerii, itp.)
- wskaż czynności (tu pewnie wszystkie ale... nigdy nie mów nigdy...) które wymagają (stanowią wymaganie) kontaktu z systemem
- to będą przypadki użycia system
- każdy przypadek opisz scenariuszem opisującym dialog użytkownik- system, jeżeli wykryjesz takie, opisz scenariusze alternatywne (patrz na opis kolegi Kurleto)

UWAGA! długość scenariusza absolutnie nie jest podstawą do podzielenia takiego przypadku użycia na "dwa mniejsze" !!! kluczem jest stan początkowy i końcowy, ile jest "środka" nie ma znaczenia.

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Co do include'ow i exdende'ow to osobiście zwykłem przyjmować zasadę stosowania tychże tylko wtedy, kiedy includowane, lub będące extendami przypadki użycia występują też jako bezpośrednie UC, lub są wielokrotnie używane. Przykładem tutaj mogłoby być CRUD pojedynczego zdjęcia, gdybyśmy np pozwalali rónież dodawać w taki sam sposób zdjęcie do profilu, czy jako zdjęcie reprezentujące galerię. Pozatym robią śmietnik.
Pare słów o CRUD. Jest to typowy zestaw funkcjonalności dla obiektów typu persistent. W systemach w których pracujemy z różnego typu obiektami diagram UC byłby zupełnie nieczytelny gdyby przedstawiać je jako osobne przypadki użycia dla każdego typu obiektu, każdego modułu czy czegokolwiek. W dużych systemach stosuje się diagramy o różnym poziomie szczegółowości i tak na etapie definiowania wymagań systemu (SRS - System Requirements Specification) zwykle prezentuje się bardzo ogólnie dwa diagramy UC - jeden reprezentujący biznesowe przypadki użycia i kontekst systemu (np. zapłata za usługę, obsługa kasowa) drugi reprezentujący systemowe przypadki użycia (np. realizacja płatności (w systemie=obsługa urządzeń zewnętrznych (czytnik kodów, terminal POS) + praca użytkownika itd). Zwykle stosuje się też tak w procesie implementacji jak i analizy, czy projektowania piękny termin generalizacji.
Zauważmy, że większość danych w systemach to tabele. Nie ma sensu opisywac ani reprezentowac na diagramie UC osobno funcjonalności CRUD dla:
Faktur VAT, Korekt faktur VAT, Paragonów, Raportów kasowych itd. Z punkto widzenia systemowego są to te same funkcjonalności (na tym poziomie abstrakcji) możemy więc wyabstrachować sobie pojęcie obsługi dancyh tabelarycznych i dla nich zaprezentować i opisać scenariusze UC.
Wtedy do dospecyfikowania pozostają nam UC specyficzne dla danego typu obiektów np. Księgowanie faktur i korekt.
Definiując przypadki użycia nie powinieneś zastanawiać się jakie funkcje realizuje system (bo tu odpowiedzią jest na przykład przechowywanie zdjęć, a to nie jest UC) tylko CO SYSTEM OFERUJE UŻYTKOWNIKOWI? CO UŻYTKOWNIK CHCE ZROBIĆ W SYSTEMIE? i tu odpowiedzią będzie np Przeglądać zdjęcia w galerii, przeglądać galerie, przeglądać użytkowników, przeglądać i dodawać komentarze, zarządzać swoimi danymi - a to są już materiały na UC. Potem generalizacje i możemy przystępować do opisu scenariuszy, robienia diagramów sekwencji (zachęcam wykonywanie diagramu sekwencji dla każdego UC, szczególnie u początków zabawy z modelowaniem.
A tutaj sposób na ogarnięcie problemu CRUD:
Bardzo zły pomysł - ogromna szczegółowość, nic nie widać (prawie jak robienie mapy miasta w skali 1:1)



Nieco lepiej, mapa już ma skale 1:100, ale chyba nie wyobrażacie sobie używania mapy w takiej sklali dla np. Warszawy:



A tu już całkiem ok:



Szczegóły CRUD dla róznego typu obiektów można opisać w opisie UC, można nawet wykonać osobny diagram UC dla CRUDMateusz Kurleto edytował(a) ten post dnia 28.01.09 o godzinie 18:31

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Panie Mateuszu, patrząc na Pana diagram zwraca moją uwagę przypadek Print, który został umieszczony poza systemem.
Ja osobiście umieścił bym go w systemie i dodał aktora Printer albo PrintSystem na zewnątrz systemu.

Zastanawiam się też, czy nie wystarczy po prostu dodać notatki, mówiącej, że wszystkie obiekty zarządzane przez system mają podlegać działaniu CRUD?

Na marginesie mówiąc, robiąc analizę przypadków użycia, mam często wrażenie eéjà vu. Przykładowo piętnasty raz robię przypadek Print albo ManageUsers. Czy wypracowaliście Panowie jakieś metody bycia zgodnym z zasadą DRY niż cut&paste? Może jakiś design-pattern?

Jest też książka na ten temat: http://www.amazon.com/Use-Cases-Patterns-Blueprints-So...
Może ktoś już czytał?

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Mateusz Kurleto:
Definiując przypadki użycia nie powinieneś zastanawiać się jakie funkcje realizuje system (bo tu odpowiedzią jest na przykład przechowywanie zdjęć, a to nie jest UC) tylko CO SYSTEM OFERUJE UŻYTKOWNIKOWI? CO UŻYTKOWNIK CHCE ZROBIĆ W SYSTEMIE? i tu odpowiedzią będzie np Przeglądać zdjęcia w

No tak nie do końca, gdyż powinniśmy wpierw określić co chcemy, by system robił. Jeśli system ma przechowywać jedynie dane, wtedy pozostają nam jedynie przypadki związane z zarządzaniem tego systemu. Takie systemy zwane data-driven również wymagają scenariuszy, prawda ?
A więc wpierw powinnismy określić tzw. critical use-case, bądź w nowszych rozwiązaniach (AOSD, QAW, ADD, ATAM/CBAM, ARID) mówi się o architectural drivers, a więc o najbardziej znaczących zagadnieniach dotyczących systemu.

galerii, przeglądać galerie, przeglądać użytkowników, przeglądać i dodawać komentarze, zarządzać swoimi danymi - a to są już materiały na UC. Potem generalizacje i możemy przystępować do opisu scenariuszy, robienia diagramów sekwencji Wszystkie rozwiązania oparte na scenariuszach (use-case driven, scenario-driven) zalecają wpierw identyfikacji najważniejszego przypadku użycia, a następnie napisanie scenariusza. Dopiero po napisaniu scenariusza okazuje się, jakie inne przypadki mogą być niezbędne i w jaki sposób są wiązane z naszym głównym. Ze swojego doświadczenia zauważyłem radosną twórczość analityków pastwiących się nad diagramem przypadków użycia i wymyślajacych niestworzone nieraz rzeczy, zamiast po prostu opisania scenariusza. Po napisaniu scenariusza możemy dopiero zacząć rysować diagram przypadków użycia .... jest to tzw. perspektywa przypadków użycia. Następnie możemy zobrazować realizacje poszczególnych przypadków użycia w formie czy to diagramów sekwencji, czy też diagramów aktywności .... a to już jest tzw. perspektywa logiczna (logical view, bądź design view).(zachęcam wykonywanie diagramu sekwencji dla każdego UC, szczególnie u początków zabawy z modelowaniem.

Niektóre przypadki nie ma co opisywać (np logowanie), bo w sumie co my tu możemy zobrazować ?

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

@Artur K.
Co do Printa - można i tak - chciałem tylko koniecnzie zobrazować, że zaznaczamy zakres systemu:) w końcu drukowanie to sprawa "poza nami":)

@Jerzy N.
Dyskutuję konkretny przykład, myślę że obydwaj możemy długo wymieniać inne podejścia mogące prowadzić do sukcesu, szczególnie w zależności od typu projektu:)

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Mateusz Kurleto:
@Artur K.
Co do Printa - można i tak - chciałem tylko koniecnzie zobrazować, że zaznaczamy zakres systemu:) w końcu drukowanie to sprawa "poza nami":)

Zgoda. Wyznaczenie granic systemu to jedno.
Zainteresowało mnie jednak samo umieszczenie przypadku użycia poza systemem. Po prostu pierwszy raz widzę takie podejście, a ponieważ nie do końca je rozumiem chciałem prosić o wyjaśnienie.

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Artur Kęska:

Mateusz Kurleto:
@Artur K.
Co do Printa - można i tak - chciałem tylko koniecnzie zobrazować, że zaznaczamy zakres systemu:) w końcu drukowanie to sprawa "poza nami":)

Zgoda. Wyznaczenie granic systemu to jedno.
Zainteresowało mnie jednak samo umieszczenie przypadku użycia poza systemem. Po prostu pierwszy raz widzę takie podejście, a ponieważ nie do końca je rozumiem chciałem prosić o wyjaśnienie.

w tym przypadku można to uznać za błąd, neimniej jednak czasem się tak robi, żeby pokazać kontekst (ale to w biznesowych UC)

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Mateusz Kurleto:
@Artur K.
Co do Printa - można i tak - chciałem tylko koniecnzie zobrazować, że zaznaczamy zakres systemu:) w końcu drukowanie to sprawa "poza nami":)

Dla porządku: ważne jest czy system odpowiada (wymagania) za udostępnienie możliwości drukowania czy odpowiada za treść i kształt wydruku. W pierwszym przypadku w granicach zabezpieczamy interfejs w drugim drukarka jest w granicy systemu aktorem zaś jest osoba korzystająca z wydruku, ma tro miejsce gdy dostawca systemu ponosi odpowiedzialność, za szczegółu wydruku np. kolory, marginesy itp. np.jeśli tzreba się dokładnie wpasować w poddruki.

Moim zdaniem nic w systemach nie jest oczywiste.

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

w tym przypadku można to uznać za błąd, neimniej jednak czasem się tak robi, żeby pokazać kontekst (ale to w biznesowych UC)

obawiam się, ze jednak z zasady przypadki użycia są w granicy definiowanego systemu, po za nim są aktorzy i inne systemy (czyli także aktorzy) czyli jego użytkownicy, kto odpowiada i wykonuje przypadek użycia umieszczony poza systemem? Jeżeli chcemy cos "dokomentować" to stosujemy notatkę lub metki.

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Jarek Ż.:

w tym przypadku można to uznać za błąd, neimniej jednak czasem się tak robi, żeby pokazać kontekst (ale to w biznesowych UC)

obawiam się, ze jednak z zasady przypadki użycia są w granicy definiowanego systemu, po za nim są aktorzy i inne systemy (czyli także aktorzy) czyli jego użytkownicy, kto odpowiada i wykonuje przypadek użycia umieszczony poza systemem? Jeżeli chcemy cos "dokomentować" to stosujemy notatkę lub metki.

Osobiście spotkałem się niejednokrotnie i uznaję za użyteczne stosowanie zaprezentowanego przeze mnie rozwiązania na etapie definiowania wymagań systemu, przy prezentacji biznesowych przypadków użycia. Jeżeli przypadkami użycia opiszemy szerszy kontekst usług biznesowych, które organizacja świadczy klientowi, możemy zaznaczyć zakres, który obejmie system pokazując bardzo czytelnie kontekst. Inaczej nie do końca widzę sens rysowania granic systemu...

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Osobiście spotkałem się niejednokrotnie i uznaję za użyteczne stosowanie zaprezentowanego przeze mnie rozwiązania na etapie definiowania wymagań systemu, przy prezentacji biznesowych przypadków użycia. Jeżeli przypadkami użycia opiszemy szerszy kontekst usług biznesowych, które organizacja świadczy klientowi, możemy zaznaczyć zakres, który obejmie system pokazując bardzo czytelnie kontekst. Inaczej nie do końca widzę sens rysowania granic systemu...

Wszystko OK, jednak jeśli zaczniemy używać notacji niezgodnie jej specyfikacją to po za autorem diagramu nikt nie zrozumie jego treści, UML to wspólny język... będzie wtedy jak z pismem: znam znaczenie każdego słowa ale nic w ząb nie kumam całego zdania.

Elementy poza systemem to aktorzy z definicji, na granicy systemu są interfejsy, jeżeli bąbelek Print poza system wymaga 'dodefiniowania" to moim zdaniem reprezentuje coś "dziwnego" co nie do końca jest zrozumiane. Z diagramu (bez opowiadania autora) nie wiadomo czym jest bąbel "Print photo".

Moim zdaniem należy sobie zadac pytanie kto/co ponosi odpowiedzialność za wydruk zdjęcia, jeśli jest to funkcjonalność projektowanego systemu związana z drukowaniem to powinna być wewnątrz, jeśłi coś z zewnątrz drukuje korzystając z danych z systemu to to coś jest aktorem.

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Mateusz Kurleto:
w tym przypadku można to uznać za błąd, neimniej jednak czasem się tak robi, żeby pokazać kontekst (ale to w biznesowych UC)

Oj zaraz błąd. Zwyczajnie mnie to zdziwiło. Nawet odkurzyłem literaturę celem znalezienia odpowiedzi. Przyznam się, że nie znalazłem niczego podobnego. Wręcz dopiero teraz zauważyłem, że autorzy książek w przykładach często ignorują wymóg oznaczania granic systemu.
Pewnie bierze się to z cichego założenia, że wszystkie bąbelki to system a pamperki to świat na zewnątrz, więc cały ten kwadracik tylko marnuje farbę drukarską.
Osobiście lubię jednak ów kwadracik i będę sobie go rysował.
Bąbelki pozostawię też w jego wnętrzu (przynajmniej do czasu aż mi się nie trafi taki co mnie przekona do narysowania go na zewnątrz).
Tym samym przychylam się też do ostatniej wypowiedzi Pana Jarka.

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Jarek Ż.:

Osobiście spotkałem się niejednokrotnie i uznaję za użyteczne stosowanie zaprezentowanego przeze mnie rozwiązania na etapie definiowania wymagań systemu, przy prezentacji biznesowych przypadków użycia. Jeżeli przypadkami użycia opiszemy szerszy kontekst usług biznesowych, które organizacja świadczy klientowi, możemy zaznaczyć zakres, który obejmie system pokazując bardzo czytelnie kontekst. Inaczej nie do końca widzę sens rysowania granic systemu...

Wszystko OK, jednak jeśli zaczniemy używać notacji niezgodnie jej specyfikacją to po za autorem diagramu nikt nie zrozumie jego treści, UML to wspólny język... będzie wtedy jak z pismem: znam znaczenie każdego słowa ale nic w ząb nie kumam całego zdania.

Elementy poza systemem to aktorzy z definicji, na granicy systemu są interfejsy, jeżeli bąbelek Print poza system wymaga 'dodefiniowania" to moim zdaniem reprezentuje coś "dziwnego" co nie do końca jest zrozumiane. Z diagramu (bez opowiadania autora) nie wiadomo czym jest bąbel "Print photo".

Moim zdaniem należy sobie zadac pytanie kto/co ponosi odpowiedzialność za wydruk zdjęcia, jeśli jest to funkcjonalność projektowanego systemu związana z drukowaniem to powinna być wewnątrz, jeśłi coś z zewnątrz drukuje korzystając z danych z systemu to to coś jest aktorem.

Kwestia kompatybilności języka mnie przekonała:) TYlko po cholere wtedy rysować granice systemu:>

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Mateusz Kurleto:
Kwestia kompatybilności języka mnie przekonała:) TYlko po cholere wtedy rysować granice systemu:>

W sumie racja, po nic mi i pewnie o Tobie

... ale jest w językach (w graficznych w szczególności, polecam do poduszki teorie komunikacji społecznej) pojęcie semiologii (postrzegane znaczenie znaków), tu po protu przeciętny zjadacz chleba (czyli większość naszych klientów) oczekuje jawnie (kreseczki prostokąta) pokazania tej granicy z której obaj doskonale zdajemy sobie sprawę :), biorąc jednak pod uwagę, że diagram UC jako jeden z nielicznych jest prezentowany klientowi nie będącemu specjalistą od UML obrazek taki powinien być zgodny ze stereotypami funkcjonującymi u większości ludzi, z ich oczekiwaniami: tu po protu granice zaznacza się np. wyrysowanym prostokątem :)

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Diagram przypadków użycia pokazuje przypadki użycia pogrupowane w pakiety. Stąd ramki obrazujące pakiet. Na jednym diagramie może być kilka pakietów. Ponadto ramka może również oznaczać granice systemu (podsystemu), wskazując, że aktorzy (bądź inne obiekty) nie należą do systemu. Od wersji 2.0 jest pewna dowolność w zakresie rysowania diagramów i ich zawartości (można mieszać różne elementy na jednym diagramie, toteż np. na diagramie przypadków użycia można również umieścić diagram stanów). Stąd warto wiedzieć co należy do systemu, a co nie należy.

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Trochę odgrzebuje, ale dopiero teraz przejrzałem wątek i mam kilka pytań.

Mateusz Kurleto:
Generalnie te Twoje przypadki użycia są nieco zbyt szczegółowe, jeśli można tak powiedzieć. Przypadek użycia powinien reprezentować scenariusz współpracy aktora z systemem służący określonemu celowi. Dobry Przypadek użycia to np:
nazwa: tworzenie konta
warunek początkowy: klient jest nie zalogowany, strona widoczna jest w przeglądarce, nie posiada konta
przebieg:
1. klika sobie zarejestruj
2. wyświetlany jest formularz rejestracji
3. klient wypełnia dane rejestracyjne i klika zapisz
4. potwierdza poprawność danych
5. wyświetlany jest regulamin
6. klient potwierdza regulamin
7. wysyłany jest mail aktywacyjny
8. klient aktywuje konto klikając w link
9. wyswietlana jest informacja o aktywowaniu konta (powiązany przypadek użycia: logowanie)
przebiegi alternatywne -

Czy scenariusz nie jest lepszy bez elementów i akcji wykonywanych w GUI? Tak napisany scenariusz nie narzuca w trakcie czytania określonych rozwiązań (link, button etc) - może się okazać na przykład że aktywujemy nie linkiem a sms'em. W większości przypadków jest pewien obraz jak system będzie wyglądał i jaki będzie interfejs graficzny, ale czy nie lepiej na etapie przypadków użycia nie stosować technicznych aspektów?

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Jerzy N.:
To że Administrator dziedziczy własności Użytkownika wcale nie oznacza, że Administrator dziedziczy asocjację do przypadku użycia Zaloguj się. Przynajmniej tak się nie podchodzi do tworzenia tego diagramu.

No właśnie - jak to jest? Np. w tych prezentacjach
http://cs.cmu.edu/~eran/lectures/uml_use-case_lecture.ppt,
http://www.lifia.info.unlp.edu.ar/papers/2002/Pons2002...
i innych materiałach, które kiedyś przeglądałem stoi, że jednak dziedziczy. W książce, którą mam http://helion.pl/ksiazki/juml2.htm jeśli dobrze pamiętam też jest zapis, że aktor-potomek ma dostęp do przypadków swojego rodzica. W wolnej chwili rzucę okiem na dokumentację na OMG.Jacek Woźniczak edytował(a) ten post dnia 09.04.09 o godzinie 15:35

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Jacek Woźniczak:

systemem służący określonemu celowi. Dobry Przypadek użycia to np:
nazwa: tworzenie konta
warunek początkowy: klient jest nie zalogowany, strona widoczna jest w przeglądarce, nie posiada konta
przebieg:
1. klika sobie zarejestruj
2. wyświetlany jest formularz rejestracji
3. klient wypełnia dane rejestracyjne i klika zapisz
4. potwierdza poprawność danych
5. wyświetlany jest regulamin
6. klient potwierdza regulamin
7. wysyłany jest mail aktywacyjny
8. klient aktywuje konto klikając w link
9. wyswietlana jest informacja o aktywowaniu konta (powiązany przypadek użycia: logowanie)
przebiegi alternatywne -

Osobiście traktuję przypadki zgodnie z zasadą: przypadek użycia sam z siebie jest niezależny (podobnie jak dobra klasa) i opisuje jedną spójną czynność, możliwą potencjalnie do wielokrotnego użycia. Przypadki użycia są kojarzone często z pojedynczymi klasami.

Powyższy przykład to w moich oczach dwa przypadki użycia:
- 1 do 6 rejestracja, 7 to element metody (procesu) realizującej ten przypadek użycia (użytkownik tego nie widzi!)
- 8 i 9 to odebranie maila z linkiem, który tu jest wykorzystany do potwierdzenie rejestracji a w innym przypadku może być użyty do wskazania URL strony z nową treścią po protu monit.

Było by dobrze by monit jako UC był uniwersalny i możliwy do wielokrotnego użycia (klasa Monit mająca metodą wyślij mail z atrybutami adresat i URL. Cudowna zaletą metod obiektowych jest między innymi wielokrotne użycie.

Polecam książkę stosowanie przypadków użycia, Geri Schneider.

będzie interfejs graficzny, ale czy nie lepiej na etapie przypadków użycia nie stosować technicznych aspektów?

Oczywiście że lepiej ale przypadek użycia specyfikuje oprogramowanie, czynności specyfikuje proces biznesowy. W modelu procesów piszemy o celu czynności, ma zostać dokonane potwierdzenie ale w UC już implementujemy bo UC to także prototyp ekranu i diagramy sekwencji.

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Jacek Woźniczak:
No właśnie - jak to jest? Np. w tych prezentacjach
http://cs.cmu.edu/~eran/lectures/uml_use-case_lecture.ppt,
http://www.lifia.info.unlp.edu.ar/papers/2002/Pons2002...
i innych materiałach, które kiedyś przeglądałem stoi, że jednak dziedziczy. W książce, którą mam http://helion.pl/ksiazki/juml2.htm jeśli dobrze pamiętam też jest zapis, że aktor-potomek ma dostęp do przypadków swojego rodzica. W wolnej chwili rzucę okiem na dokumentację na OMG.

Osobiście stoję na stanowisku wielu autorów i projektów i książek: to że UML dopuszcza pewne konstrukcje nie znaczy ze wnoszą one coś do projektu i należy je stosować.

Po drugie jestem zwolennikiem tezy, że UC to nie model komponentów ani procesów... tylko diagram obrazujący przypadki kontaktu użytkownika z systemem. Projektu dokumentuje się innymi niż UC diagramami. Jak wielu autorów książek uznaję, że UC nie jest projektem systemu tylko specyfikacja zakresu projektu.

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Dziękuję za rzeczowe odpowiedzi. Sporo jest podejść do tematu UMLa, stąd moje pytania.