GoldenLine
Zaloguj się
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:
<<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)
Ty to jednak lubisz te potyczki językowe:P
Jak już w ten sposób podchodzić do problemu to zacznę od tego, że na etapie analizy nie wybiera się wzorców projektowych a MVC jest wzorcem obiektowym.
Dalej zaś - zawsze twierdzisz, że podział na systemowe i biznesowe przypadki użycia jest bez sensu - a tutaj ewidentnie widać jeden z problemów które takie podejście rozwiązuje.
Otóż z punktu widzenia funkcjonalności systemu Logowanie jak najbardziej kwalifikuje się jako przypadek użycia.
Jest to skończony ciąg interakcji aktor-system.
Pozwala na osiągnięcie konkretnego celu - uwierzytelnienia i autoryzacji.

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
True:P
Link do wypowiedziLink
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ę

Ponieważ właśnie zaktualizowałem soft to w ramach rozglądania się co się zmieniło postanowiłem zaprezentować moje podejście do zadania.
Michał Ka:
Witam. Mam do zrobienia diagram przypadków użycia dla zarządzania kontami. Mam pierwszy raz do czynienia z UML. Stworzyłem taki diagram:

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.

Pozdrawiam

Podejście pierwsze:
Ponieważ Michał pisze, że ma zrobić diagram przypadków użycia dla zarządzania kontami, na podstawie treści zadania, rozwiązanie prezentuje się jak na pierwszym obrazku.
Dlaczego? Ponieważ tylko te przypadki użycia z wszystkich jakie możemy zaproponować z załączonej treści zadania dotyczą jakkolwiek zarządzania kontami.

Obrazek


Jeżeli jednak mamy potraktować treść zadania jako user-story to na początek szukamy kandydatów na aktorów - a są to:
- użytkownik
- administrator
następnie szukamy kandydatów na przypadki użycia:
- dokonanie zakupu
- zakładanie konta
- podawanie danych adresowych - nie posiada żadnej wartości samodzielnie, jest jedynie opisem kroku scenariusza zakładanie konta
- podawanie e-maila - nie posiada żadnej wartości samodzielnie, jest jedynie opisem kroku scenariusza zakładanie konta
- podawanie hasła - nie posiada żadnej wartości samodzielnie, jest jedynie opisem kroku scenariusza zakładanie konta
- podawanie powtórki hasła - nie posiada żadnej wartości samodzielnie, jest jedynie opisem kroku scenariusza zakładanie konta
- logowanie - jest kilka podejść; ja osobiście umieszczam na diagramie, ale nie zaznaczam include/extend ponieważ w opisach przypadku użycia przy warunkach początkowych określam czy klient musi być zalogowany czy nie
- oglądanie statusu aktualnych zamówień
- oglądanie historii zamówień już zrealizowanych
- zamykanie konta
- usuwanie konta (po uprzednim zamknięciu)

a następnie zabieramy się za rysowanie:

Obrazek


Dla porównania załączam rysunek uwzględniający wynikające z treści zadania <<include>> gdyby zastosować inne podejście do przypadku użycia logowanie.
Już na pierwszy rzut oka widać, że takie podejście znacznie zmniejsza czytelność diagramu. Na pierwsze zastanowienie się, że nie wnosi prawie żadnej wiedzy.
Moja porada: Jeżeli kilka przypadków użycia "includuje" pojedynczy przypadek, warto pomyśleć, czy ten "includowany" przypadek użycia nie służy jedynie zmianie stanu jakiegoś obiektu w systemie (tutaj tak jest). W takim wypadku warto pomyśleć, czy nie lepiej jest zrezygnować z rysowania <<include>> na rzecz traktowania poszczególnych stanów wspomnianego obiektu jako warunku wejściowego dla danego przypadku użycia. Wtedy piszemy w warunkach początkowych np "użytkownik jest zalogowany i posiada stosowne uprawnienia"
o uprawnieniach rozpisywał się nie będę, bo wiele stron by to zajęło:)


Obrazek


P.S.
Proszę zwrócić uwagę, że z treści zadanie nie wynika, że dokonanie zakupu, zamykanie konta lub usuwanie konta wymaga zalogowania w systemie. Nie mówi też w jaki sposób system rozróżnia aktorów.Mateusz Kurleto edytował(a) ten post dnia 10.11.10 o godzinie 01:54
Link do wypowiedziLink
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:
Ty to jednak lubisz te potyczki językowe:P

;P
Jak już w ten sposób podchodzić do problemu to zacznę od tego, że na etapie analizy nie wybiera się wzorców projektowych a MVC jest wzorcem obiektowym.

Owszem, z tym się zgadzam :) z jednym ale: jeżeli uznamy (zaznaczam, że to moje podejście bazujące na DDD nie ukrywam), że analiza kończy się "modelem analizowanej rzeczywistości" a model ten jest modelem obiektowym (świadomie: analiza obiektowa) to model ten zostanie użyty do budowy systemu jako część (komponent) Model z wzorca MVC, jeżeli idąc dalej model dziedziny będzie implementowany to można w nim użyć wzorców.

Dalej zaś - zawsze twierdzisz, że podział na systemowe i biznesowe przypadki użycia jest bez sensu - a tutaj ewidentnie widać jeden z problemów które takie podejście rozwiązuje.

Nie twierdzę, że nie ma sensu a jedynie, że "klient kupuje" przypadki biznesowe i tu przyznaję rację. Ja w swojej pracy pracy (to tylko słownik pojęć) przypadków "systemowych" nie nazywam przypadkami użycia a elementami scenariusza by nie wprowadzać w błąd klienta (Czytelnika dokumentacji) i w tym kontekście masz rację, której nie neguję. To samo co poprzednio powiedziałem o procesach i scenariuszach: współpracę obiektów w systemie celowo nazywam sekwencję a nie procesem by nie powodować nieporozumień.
Otóż z punktu widzenia funkcjonalności systemu Logowanie jak najbardziej kwalifikuje się jako przypadek użycia.
Jest to skończony ciąg interakcji aktor-system.
Pozwala na osiągnięcie konkretnego celu - uwierzytelnienia i autoryzacji.

Masz rację :)! Ja tylko napisałem, że "oczywiste funkcjonalności" można pominąć, nie neguje zaś ich istnienia. Dodałem jedynie, że samo logowanie do systemu bez chęci wykonana jakiejkolwiek innej pracy jest pozbawione kontekstu no chyba, że mowa o systemie rejestracji czasu pracy :)

sam fakt kłopotów w jednoznacznej interpretacji tego diagramu stanowi jego wadę... diagram UC bez jakiegoś kontekstu (np. modelu procesu) jest "ułomny"..:)
True:P

:)

Zauważyłem teraz jednak jedną rzecz, na którą warto zwrócić uwagę czytelników: jakiekolwiek metody modelowania i pragmatyka muszą być przyjęte bo w przeciwnym wypadku ocena jakiekolwiek modelu staje się nie możliwa z powodu braku kryteriów oceny.

Celowo zawsze zaznaczam, że stosuję metodyką i wzorce DDD oraz wzorzec MVC do wyznaczania zakresu odpowiedzialności analityka projektanta (komponent Model) by takich nieporozumień uniknąć.

W zasadzie każdy model, jeżeli tylko zostanie (jest możliwy) odwzorowany w oprogramowaniu jest dobry, pytanie brzmi: czy tak powstały program jest, no jaki będzie? Jakie będzie ryzyko projektu wytworzenia oprogramowania?

Mateusz: jako developer uczysz mnie pokory :)
Link do wypowiedziLink
Pat R.

Pat R. profesjonalny opis

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

Witam.
Mam pytanie dotyczące diagramu sekwencji w programie StarUML czy jest on w miarę poprawny ?
Dotyczy on procesu rejestracji.


Obrazek


Dzięki za uwagi.
Link do wypowiedziLink
Jarosław Żeliński

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

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

miałem moment ;) i poczytałem.

od razu uwaga: diagram sekwencji obrazuje obiekty zaś komunikaty to odwołania do ich operacji.

tak więc czym jest obiekt "baza danych MySQL"???
Link do wypowiedziLink
Bartosz C.

Bartosz C. Student, Wyższa
Szkoła Informatyki i
Ekonomii w Olsztynie

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

Proszę o opinię, podpowiedz co do diagramu przypadków użycia m.in:
- czy taka ilość PU jest w zupełności wystarczająca,
- czy dodać bardziej szczegółowe PU,
- czy oczywiście sama logika jest zachowana,
- oraz o wszelkie zastrzeżenia, bądź propozycje.

...z góry dziękuję i pozdrawiam


Obrazek
Link do wypowiedziLink
Jarosław Żeliński

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

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

po pierwsze są przypadki użycia niepołączone z aktorami

o co chodzi z tym dziedziczeniem u dołu?

diagram UC to nie proces, to tylko sytuacje gdy użytkownik "coś chce" od systemu...

jaki cel ma "Przeglądanie dłużników"??? (przypadek użycia powinien do czegoś służyć)
Link do wypowiedziLink
Bartosz C.

Bartosz C. Student, Wyższa
Szkoła Informatyki i
Ekonomii w Olsztynie

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

dziękuje za szybką odp.

Dzięki tej legendzie dziedziczenia u dołu, chciałem zilustowac m.in to, że np. administrator może także używać tych samych PU, co np. bibliotekarz (nie jestem pewien czy jest to konieczne).

Co do łączenia aktorów z przypadkami, to trzeba robić to jawnie, pomimo tego że są zawierane, rozszerzane przez inne PU?

"Przeglądanie dłużników" wyświetla bazę danych zadłużonych czytelników np. za przetrzymanie książki, czyli praktycznie to samo co "Wyszukiwanie książek" (można "Przeglądanie dłużników" nazwać "Wyszukiwaniem zadłużonych kont czytelników").
Link do wypowiedziLink
Jarosław Żeliński

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

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

Dzięki tej legendzie dziedziczenia u dołu, chciałem zilustowac m.in to, że np. administrator może także używać tych samych PU, co np. bibliotekarz (nie jestem pewien czy jest to konieczne).

Zastanów się czy administrator jest gorliwym czytelnikiem....
Co do łączenia aktorów z przypadkami, to trzeba robić to jawnie, pomimo tego że są zawierane, rozszerzane przez inne PU?

zasada jest prosta: przypadek użycia jest kojarzony z aktorem, relacje <include> wskazują wyłącznie na zawieranie się scenariuszy UC
"Przeglądanie dłużników" wyświetla bazę danych zadłużonych czytelników np. za przetrzymanie książki, czyli praktycznie to samo co "Wyszukiwanie książek" (można "Przeglądanie dłużników" nazwać "Wyszukiwaniem zadłużonych kont czytelników").

ale po co? Przypadek użycia z definicji tworzy jakiś końcowy stan, samo oglądanie nie jest statycznym rezultatem....
na początek niezłe jest to:
http://pl.wikipedia.org/wiki/Przypadek_u%C5%BCycia
Link do wypowiedziLink
Bartosz C.

Bartosz C. Student, Wyższa
Szkoła Informatyki i
Ekonomii w Olsztynie

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

Bardzo wdzięczny jestem za komentarze, dzięki którym wygenerowałem nowy diagram:


Obrazek


Zastanawiam się jednak w dalszym ciągu, czy taka prosta forma diagramu wystarczy, czy może rozbudowywać go np. o PU "Logowanie" itp...
Link do wypowiedziLink
Jarosław Żeliński

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

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

Bartosz C.:
Zastanawiam się jednak w dalszym ciągu, czy taka prosta forma diagramu wystarczy, czy może rozbudowywać go np. o PU "Logowanie" itp...

no ten jest moim zdaniem znacznie lepszy... sam diagram przypadków użycia nie zastąpi modelu dziedziny i diagramu sekwencji, nie ma sensu komplikowanie tego co jest... taki diagram przypadków użycia to raczej szkielet projektu a nie detaliczny projekt.... więc na początek wystarczy

dobrym zwyczajem jest nazywanie przypadków "realniej" to jest np. Zamiast wypożyczanie książek, "dopisywanie książek do rejestru wypożyczeń"... lub coś w tym sensie...Jarek Żeliński edytował(a) ten post dnia 23.03.11 o godzinie 22:07
Link do wypowiedziLink
Bartosz C.

Bartosz C. Student, Wyższa
Szkoła Informatyki i
Ekonomii w Olsztynie

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

Umieszczam ten diagram z nadzieją, że jest on lepszy od poprzednika.


Obrazek


Za wszelkie uwagi dodatkowe będę wdzięczny.
Link do wypowiedziLink

konto usunięte

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

Za wszelkie uwagi dodatkowe będę wdzięczny.

Obawiam się, że to nie jest diagram "Use Case" a "Diagram pomieszania technologi z domeną".

Uwagi:

Dziwne nazwy use case'ów np:
- 'edycja rekordów w bazie wypożyczeń'. Jeszcze nigdy nie słyszałem, żeby bibliotekarz tak nazywał np. 'wypożyczenie książki' albo 'oddanie książki'.

Dziwne obiekty domeny:
- rekord
- profil
- pozycja
- bazy: książek, wypożyczeń, rezerwacji

Niektóre use case'y są (jak dla mnie) zbyt ogólne np:
- zarządzanie kontami / profilem; w zasadzie, każda akcja na obiekcie domeny podpada pod definicję "zarządzania".

Niekonsekwentne słownictwo np:
edycja rekordów - aktualizacja rekordów - dodanie / usuwanie - zarządzanie

Ostatnia rzecz:
Kto to jest 'czytelnik' i dlaczego nie może wypożyczać książek ? :)

tak powinien wyglądać (mniej-więcej... raczej mniej) diagram use case:
http://imageupload.org/?d=4D8E40081

Przy okazji widać wszystkie wady tego diagramu...Jakub Wojt edytował(a) ten post dnia 27.03.11 o godzinie 20:52
Link do wypowiedziLink

konto usunięte

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

dobrym zwyczajem jest nazywanie przypadków "realniej" to jest np.
Zamiast wypożyczanie książek, "dopisywanie książek do rejestru wypożyczeń"... lub coś w tym sensie...

Wtedy takie coś nie jest use case'm ...
Można np. w tym samym czasie wielokrotnie dopisać jedna książkę do rejestru (cokolwiek to jest) wypożyczeń.

Ale 'wypożyczyć' w danym momencie można tylko raz i tylko jednemu czytelnikowi.

Co jeśli wypożyczenie polega na wykonaniu kilku akcji (dodanie do rejestru, dodanie do historii wypożyczeń (użytkownika i biblioteki), usunięcie książki z rejestru książek niewypożyczonych)?
Link do wypowiedziLink
Jarosław Żeliński

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

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

Jakub Wojt:
Za wszelkie uwagi dodatkowe będę wdzięczny.

Obawiam się, że to nie jest diagram "Use Case" a "Diagram pomieszania technologi z domeną".

to prawda, nie wspomniałem o tym, ale uzywanie słownictwa "implementacyjnego" nie pomoże klientowi zrozumieć tego,
Ostatnia rzecz:
Kto to jest 'czytelnik' i dlaczego nie może wypożyczać książek ? :)

tu nieco w obronę wezmę autora: diabram UC musi mieć jakiś opis dający mu kontekst (user story a lepiej opis procesów biznesowego), bez tego ocena "kim jest czytelnik" nie ma podstaw

tak powinien wyglądać (mniej-więcej... raczej mniej) diagram use case:
http://imageupload.org/?d=4D8E40081

Przy okazji widać wszystkie wady tego diagramu...Jakub Wojt edytował(a) ten post dnia 27.03.11 o godzinie 20:52
Link do wypowiedziLink
Jarosław Żeliński

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

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

Jakub Wojt:
dobrym zwyczajem jest nazywanie przypadków "realniej" to jest np.
Zamiast wypożyczanie książek, "dopisywanie książek do rejestru wypożyczeń"... lub coś w tym sensie...

Wtedy takie coś nie jest use case'm ...
Można np. w tym samym czasie wielokrotnie dopisać jedna książkę do rejestru (cokolwiek to jest) wypożyczeń.


Jest, kwestia konwencji, bardzo dobrze sprawdzającą się konwencją w dokumentacji jest stosowanie takich samych nazw na czynności w procesie i na przypadki użycia, które z nich są wywodzone...

Co jeśli wypożyczenie polega na wykonaniu kilku akcji (dodanie do rejestru, dodanie do historii wypożyczeń (użytkownika i biblioteki), usunięcie książki z rejestru książek niewypożyczonych)?

to jest mieszanie poziomu UC ze scenariuszem UC, powyższy opis to sekwencja realizująca przypadek użycia Wypożyczenie, zresztą to także kwestia konwencji i ewentualnego poziomu gradacji na poziomie "systemowych UC", tego jednak (systemowe UC) osobiście nie stosuję z uwagi na zbyt "niski poziom" dla klienta, UC to jedna spójna i pełna czynność pracy człowieka a nie systemu.
Link do wypowiedziLink
Jarosław Żeliński

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

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

Jakub Wojt:
tak powinien wyglądać (mniej-więcej... raczej mniej) diagram use case:

http://www.imageupload.org/download.php?id=7850&type=2
Nie rozumiem dlaczego Zwrot jest połączony <<include>> z wypożyczaniem. UC połączone z Wypożyczeniem <<include>>? Dlaczego? Można przecież wypożyczyć nie zwracając nic, jeżeli strzałki <<include>> sugerują kolejność czynności to jest to raczej błąd... (diagram UC to nie miejsce na procesy).

Bałbym się jednak wgłębiać się w ocenę diagramu UC nie znając kontekstu w postaci opisu procesu. Dlatego tu chyba lepiej będzie poprzestać na poprawności notacyjnej i uniknięci złych nawyków, a na pewno jest takim używanie słów w rodzaju "edycja"... :)Jarek Żeliński edytował(a) ten post dnia 27.03.11 o godzinie 23:17
Link do wypowiedziLink
Bartosz C.

Bartosz C. Student, Wyższa
Szkoła Informatyki i
Ekonomii w Olsztynie

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

Jakub Wojt:

Ostatnia rzecz:
Kto to jest 'czytelnik' i dlaczego nie może wypożyczać książek ? :)

Od strony CU "Systemu ewidencji pożyczkowych biblioteki" czytelnik formalnie nie ma możliwości pożyczenia książki (nie jest zarazem czytelnikiem i bibliotekarzem), aby tego dokonać „pożyczyć” musi ona zostać mu wypożyczona (udostępniona) przez bibliotekarza. Od strony kodowej jak najbardziej np. metodę wypożyczenia wiążemy bezpośrednio z książką i czytelnikiem.

Dodatkowo zostałem poproszony o rozszerzenie złożonych CU i na chwilę obecną tak to wygląda:


Obrazek


Za wszelkie uwagi dodatkowe będę wdzięczny.Bartosz C. edytował(a) ten post dnia 29.03.11 o godzinie 14:06
Link do wypowiedziLink
Jarosław Żeliński

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

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

Bartosz C.:
Od strony CU "Systemu ewidencji pożyczkowych biblioteki" czytelnik formalnie nie ma możliwości pożyczenia książki (nie jest zarazem czytelnikiem i bibliotekarzem), aby tego dokonać „pożyczyć” musi ona zostać mu wypożyczona (udostępniona) przez bibliotekarza. Od strony kodowej jak najbardziej np. metodę wypożyczenia wiążemy bezpośrednio z książką i czytelnikiem.

dobry projekt jest odporny na przyszłe żądania, co zrobisz jeśli pojawi się wymaganie: kiosk samoobsługowy w bibliotece?
Link do wypowiedziLink
Bartosz C.

Bartosz C. Student, Wyższa
Szkoła Informatyki i
Ekonomii w Olsztynie

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

Jarek Żeliński:
dobry projekt jest odporny na przyszłe żądania, co zrobisz jeśli pojawi się wymaganie: kiosk samoobsługowy w bibliotece?

Przy dostępie do kodu źródłowego mogę zawsze dopisać metodę, a w tym przypadku to raczej jakiś dodatkowy moduł do obsługi kiosku(i w tedy m.in miałby oddzielny diagram CU,itp..).
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy





Wyślij zaproszenie do
Anuluj