Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

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

Mateusz Kurleto:
można dac UC "przeglądanie informacji o przepełnieniu bufora" od biedy:P

pod warunkiem, że bufor (czym by miał nie być) jest czyms przydatnym dla użytkownika (aktora)

konto usunięte

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

Olga Makushenko:
Narysowałam po raz kolejny diagram do Zadania 1.
Jeśli naprawdę jesteś zainteresowana scenariuszowym opisem systemu informatycznego, to zapraszam do grupy "Architektura oprogramowania" do tematu "Scenariusze: sterowanie sygnalizacją świetlną".
Pozdrawiam.

konto usunięte

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

http://www.goldenline.pl/forum/1813802/scenariusze-ste...
Michał W.

Michał W. Student, Wyższa
Szkoła Technologii
Informatycznych w
Kato...

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

Witam jestem całkowicie początkującą osobą jeśli chodzi o UML-a. Stworzyłem następujący diagram przypadków użycia do aplikacji, którą aktualnie piszę w javie. Chciałbym uzyskać waszą opinię na temat tego diagramu i ewentualne wskazówki gdzie popełniłem błąd(błędy). Proszę o dużą wyrozumiałość :)


Obrazek


Z góry dziękuje i pozdrawiam.
Mateusz Kurleto

Mateusz Kurleto Szukamy wybitnych
talentów do
świetnego zespołu IT
w Gdańsku

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

Michał W.:

Niestety - jak to zwykle bywa - muszę Ci poradzić zacząć od wyrzucenia całego diagramu i nie patrzenia na niego robiąc nowy.

Najlepiej by było gdybyś przeczytał kilka ciekawych pozycji o modelowaniu, ale jak się domyślam nie masz na to czasu i/lub ochoty.

Projektując więc nowy diagram weź pod uwagę kilka rad:
- diagram przypadków użycia to nie diagram przepływu ekranów
- diagram przypadków użycia to nie spis wszystkich opcji w menu
- przypadki użycia na diagramie powinny być na tym samym poziomie szczegółowości
- dobry kandydat na przypadek użycia to taki ciąg interakcji aktor-system który pozwala zrealizować pojedynczy cel
- projektując przypadki użycia dla systemu pisanego z wykorzystaniem frameworków, zwykle można CRUD dla pojedynczego obiektu lub grupy obiektów uznać za jeden przypadek użycia
- nie należy używać za dużo extendów, includów i generalizacji
- prawie zawsze system posiada więcej niż jednego aktora
- tak na oko nie potrzebujesz tam więcej niż 10 UC
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

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

Diagram wygląda jak praca na konkurs: "Kto użyje więcej dostępnych w książkach kresek". Do uwag Mateusza dodam: daj ten diagram do przeczytania swojej dziewczynie lub koleżance, najlepiej gdyby była np. historykiem sztuki, Wyrzuć z niego wszytko to czego nie zrozumiała. Pamiętaj,że diagram UC jest dla zamawiającego... dla programistów są diagramy klas, sekwencji, maszyny stanów itp....

Nie zrażaj się, pamiętaj, że UC to nie projekt systemu a opis czarnej skrzynki o nazwie "System". Zrób ten diagram jeszcze raz, spróbuj na początek nie używać żadnego Include, Extend a szczególnie nie używaj dziedziczenia.
Michał W.

Michał W. Student, Wyższa
Szkoła Technologii
Informatycznych w
Kato...

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

Witam. Dziękuje za szybką odpowiedz.
Zakładam, że pewnie i tym razem będzie coś nie tak z tym moim diagramem , ale mam nadzieje że jest już on o wiele lepszy niż poprzednio. Zrezygnowałem z nadmiernej szczegółowości.
Jeśli chodzi o aktora to wydaje mi się że będzie tylko jeden w postaci użytkownika aplikacji. Aplikacja ta będzie aplikacja desktopową, nie wymagającą dostępu do sieci. Użytkownik z niej korzystający będzie miał pełne prawa administratora.


Obrazek


Proszę Państwa o ponowne sprawdzenie diagramu i ewentualne porady, z góry dziękuje i pozdrawiam.
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

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

w zasadzie każdy przypadek użycia (UC) powinien mieć sens i być użyteczny (do czegoś konkretnego służyć), więc np. czy Szukaj spełnia tę zasadę? A inne?

pytanie drugie: co oznaczają strzałki przerywana linią? Semantyka (słownik) UC nie zawiera takich...
Mateusz Kurleto

Mateusz Kurleto Szukamy wybitnych
talentów do
świetnego zespołu IT
w Gdańsku

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

Michał W.:
Po pierwsze reprezentuje on inną funkcjonalność niż poprzedni. To na pewno. I to mniejszą.

Po drugie - przypadek użycia to ciąg interakcji aktor-system pozwalających spełnić określony cel. To odpowiedź na pytanie - jak użytkownik będzie korzystał z systemu.

Po trzecie - wszystkie przypadki użycia powinny być na tym podobnym poziomie szczegółowości.

Jeśli masz szukanie - to cała reszta jest zbędna, bo opiszesz ją scenariuszami z alternatywnym przebiegiem.

Pamiętaj, że diagram przypadków użycia to wysokopoziomowy opis funkcjonalności. Często prezentowany zarządom. Co to jest rekord? Dużo lepiej jest powoływać się na znane obiekty biznesowe. Np. Zarządzanie fakturami, dostawami, kontrahentami.

konto usunięte

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

Witam. Mam do zrobienia diagram przypadków użycia dla zarządzania kontami. Mam pierwszy raz doczynienia z UML. Stworzyłem taki diagram:


Obrazek


Poprosze o jakis komentarz.

Dokładna treść zadania brzmi:

Aby dokonać zakupu w sklepie internetowym klient musi założy sobie konto podając dane adresowe, e-mail, który będzie nazwą konta oraz hasło. Hasło musi być podane dwukrotnie w celu uwierzytelnienia.Logując się na konto klient może obejrzeć status aktualnych zamówień lub historię zamówień już zrealizowanych.Klient może również zamknąć swoje konto.Czasami zdarza się, że administrator musi usunąć konto klienta uprzednio je zamykając.

PozdrawiamMichał Ka edytował(a) ten post dnia 05.11.10 o godzinie 22:27
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

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

ogólnie nie wygląda źle, na początek: jeden przypadek użycia nie ma aktora..
Mateusz Kurleto

Mateusz Kurleto Szukamy wybitnych
talentów do
świetnego zespołu IT
w Gdańsku

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

Michał Ka:
a na koniec, jeśli już korzystasz z <<include>> i <<extend>> do pokazania przebiegów, to usuń konto powinien rozszerzać zamknięcie konta, ponieważ treść wskazuje "uprzednio je zamykając". Pojawia sie oczywiście wątpliwość - czy można usunąć zamknięte wcześniej konto? Ja jednak zrobił bym extenda.

konto usunięte

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

Witam.
Dziękuje bardzo za podpowiedzi.
Mateusz:
Zastanawiałem się też nad tym że "usuń konto" powinno rozszerzać "zamknięcie konta" i treść zadania wskazuje właśnie na usunięcie konta, po uprzednim jego usunięciu.
Jarku:
Co do braku przypadku użycia, który nie ma aktora to rozumie że chodzi o "rejestracje", która powinna wskazywać na aktora"klient"?
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

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

co do zasady przypadek użycia jest interakcją systemu z aktorem ...;)
Mateusz Kurleto

Mateusz Kurleto Szukamy wybitnych
talentów do
świetnego zespołu IT
w Gdańsku

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

Jarek Żeliński:
co do zasady przypadek użycia jest interakcją systemu z aktorem ...;)
Ale on tam korzystał ze <<include>> i <<extend>> do pokazania przepływu, więc ponieważ istnieje ścieżka aktr -> przypadek to zasada ta jest zachowana:P
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

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

Mateusz Kurleto:
Jarek Żeliński:
co do zasady przypadek użycia jest interakcją systemu z aktorem ...;)
Ale on tam korzystał ze <<include>> i <<extend>> do pokazania przepływu, więc ponieważ istnieje ścieżka aktr -> przypadek to zasada ta jest zachowana:P

uogólniając, nawet jeżeli jakiś UC jest <<include>> do innego to jest to jednak nadal UC i powinien być dostępny także bezpośrednio, w przeciwnym wypadku jest niesamodzielnym elementem większego scenariusza więc nie jest to UC...

po drugie o ile mi wiadomo model UC nie modeluje żadnych przepływów :)
Mateusz Kurleto

Mateusz Kurleto Szukamy wybitnych
talentów do
świetnego zespołu IT
w Gdańsku

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

Jarek Żeliński:
Mateusz Kurleto:
Jarek Żeliński:
co do zasady przypadek użycia jest interakcją systemu z aktorem ...;)
Ale on tam korzystał ze <<include>> i <<extend>> do pokazania przepływu, więc ponieważ istnieje ścieżka aktr -> przypadek to zasada ta jest zachowana:P

uogólniając, nawet jeżeli jakiś UC jest <<include>> do innego to jest to jednak nadal UC i powinien być dostępny także bezpośrednio, w przeciwnym wypadku jest niesamodzielnym elementem większego scenariusza więc nie jest to UC...

po drugie o ile mi wiadomo model UC nie modeluje żadnych przepływów :)
To ja wiem:P ja tłumaczę schemat, który widzę tak jak go rozumiem:)
Tomasz Dudek

Tomasz Dudek Analityk
Biznesowy/Systemowy
OCEB, PRINCE2, Six
Sigma Gr...

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

Jarek Żeliński:

uogólniając, nawet jeżeli jakiś UC jest <<include>> do innego to jest to jednak nadal UC i powinien być dostępny także bezpośrednio, w przeciwnym wypadku jest niesamodzielnym elementem większego scenariusza więc nie jest to UC...

A jeżeli jest extend to chyba też? wtedy to raczej dwa UC nie mają tutaj aktora.

Co do diagramu - czy nie wynika z niego czasem tak, że klient sprawdzając status, historię, zamkając konto zawsze będzie musiał się logować niezależnie od tego, że może juz być zalogowany? Chyba, że zakładamy tutaj, że UC Logowanie to też sprawdzenie aktywnej sesji klienta (np. jako przebieg alternatywny), która zapewne jest wymagana do tego by móc te operacje wykonać... A może nie warto tego specjalnie oznaczać na tym diagramie, a np. na diagramie czynności?
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

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

Tomasz Dudek:
Jarek Żeliński:

uogólniając, nawet jeżeli jakiś UC jest <<include>> do innego to jest to jednak nadal UC i powinien być dostępny także bezpośrednio, w przeciwnym wypadku jest niesamodzielnym elementem większego scenariusza więc nie jest to UC...

A jeżeli jest extend to chyba też? wtedy to raczej dwa UC nie mają tutaj aktora.

Czym jest ta Rejestracja? kto i co (kogo) rejestruje?
Co do diagramu - czy nie wynika z niego czasem tak, że klient sprawdzając status, historię, zamkając konto zawsze będzie musiał się logować niezależnie od tego, że może juz być zalogowany?

<<include>> nie mówi czy "logowanie" jest pierwszym elementem scenariusza czy ostatnim :), ono po protu tam jest... po drugie wymóg "bycia zalogowanym" umieszcza się jako warunek początkowy dla przypadku użycia, po trzecie logowanie nie jest funkcjonalnością biznesową a ograniczeniem (lub jak kto woli wymaganiem pozafunkcjonalnym: system musi kontrolować prawa dostępu. w moich oczach na diagramie mamy troszkę pomieszanie pojęć, tym bardziej, że logowanie i tak będzie obsługiwał Controller frameworka a nie komponent dziedzinowy... (wzorzec MVC)

Chyba, że zakładamy tutaj, że UC Logowanie to też sprawdzenie aktywnej sesji klienta (np. jako przebieg alternatywny), która zapewne jest wymagana do tego by móc te operacje wykonać... A może nie warto tego specjalnie oznaczać na tym diagramie, a np. na diagramie czynności?

sam fakt kłopotów w jednoznacznej interpretacji tego diagramu stanowi jego wadę... diagram UC bez jakiegoś kontekstu (np. modelu procesu) jest "ułomny"..:)Jarek Żeliński edytował(a) ten post dnia 09.11.10 o godzinie 15:07

konto usunięte

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

Przerobiłem trochę wykres i teraz chyba jest już bardziej jednoznaczny :)


Obrazek
Michał Ka edytował(a) ten post dnia 09.11.10 o godzinie 23:06



Wyślij zaproszenie do