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

Witam,

prosiłbym o zerkniecie na moje usecasy systemu zarządzania treścią dość dużym portalem społecznościowo-informacyjnym

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

i tutaj drugi:

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

Jeśli chodzi o DPU panelu admina to dałbym związek zawierania między przypadkami typu "zarządzaj ..." a przypadkiem "zaloguj do panelu" oraz skierował asocjację od przypadku "wyślij wiadomość" w kierunku aktora użytkownik.

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

Michał S:
Witam,

prosiłbym o zerkniecie na moje usecasy systemu zarządzania treścią dość dużym portalem społecznościowo-informacyjnym

A czy niewygodniej byłoby dokonac dekompozycji tego diagramu na kilka mniejszych? Łatwiej jest znaleźć właściwe powiązania.

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

Michał Wolski:

A czy niewygodniej byłoby dokonac dekompozycji tego diagramu na kilka mniejszych? Łatwiej jest znaleźć właściwe powiązania.

Zastanawiałem się nad tym, ale jest mi to potrzebne do pracy inzynierskiej i caly diagram bedzie wydrukowany na A3. Z drugiej stony gdybym chcial dokonac dekompozycji w kazdym z grafow to bym napisal ksiazke chyba a z objetoscia pracy tez nie mozna przesadzac

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

Moim skromnym zdaniem lepiej mieć o kilkanaście stron więcej niż jeden diagram wydrukowany na A3. Liczy się także użyteczność dokumentacji a nie jej objętość. Diagram A3 jest nieużyteczny bo nieczytelny. Ale tak jak wspomniałem tylko moim skromnym zdaniem.

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

Mam dziwne wrażenie, że ten diagram UC próbuje tu zastąpić diagram klas. Nie jest chyba dobrą drogą:
- diagram klas to baza danych
- diagram UC to architektura (moduły) systemu, kolejność zdarzeń itp...

a UML to:
- UC to przypadku użycia, TYLKO interakcje użytkownika z systemem (jeden bąbel na elementarną i niezależna funkcjonalność)
- diagram klas zawiera klasy encyjne (materiał na bazę danych, model dziedziny) i klasy "wykonawcze" czyli moduły systemu, jak ktoś ma kłopot polecam opis wzorca np. MVC.

Nie wyobrażam sobie sytuacji w której diagram UC jest jedynym dokumentem opisującym system, nawet mały.Jarek Żeliński edytował(a) ten post dnia 29.06.09 o godzinie 21:51

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

Michał Wolski:
Moim skromnym zdaniem lepiej mieć o kilkanaście stron więcej niż jeden diagram wydrukowany na A3. Liczy się także użyteczność dokumentacji a nie jej objętość. Diagram A3 jest nieużyteczny bo nieczytelny. Ale tak jak wspomniałem tylko moim skromnym zdaniem.

Nie chce wchodzić w głębszą polemikę, ale profesorowie na uczeli pokazywali diagramy US, które zajmowaly wiele wiele wiecej niz marne A3

Jarek Żeliński:
Mam dziwne wrażenie, że ten diagram UC próbuje tu zastąpić diagram klas. Nie jest chyba dobrą drogą:
- diagram klas to baza danych
- diagram UC to architektura (moduły) systemu, kolejność zdarzeń itp...

wiem co to jest diagram klas i jakos ni wzab nie widze na moim UC podobnosci?? Prosze o wsparcie decyzji konkretnym przykladem

a UML to:
- UC to przypadku użycia, TYLKO interakcje użytkownika z systemem (jeden bąbel na elementarną i niezależna funkcjonalność)
- diagram klas zawiera klasy encyjne (materiał na bazę danych, model dziedziny) i klasy "wykonawcze" czyli moduły systemu, jak ktoś ma kłopot polecam opis wzorca np. MVC.

wiem co to encje... ale chyba nie taka byla moja prosba... Chodzi mi o wstepny komentarz UC, czy to co zaprezentowalem wydaje sie zrozumiale i w jakis sposob czytelne....

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

Michał S:
i tutaj drugi:

Co do wielkości samego diagramu - zdekomponował bym - tym bardziej,że wydaje mi się, że powinno się dać. Ale nie jestem przekonany, czy jest to konieczne - ostatecznie daję radę go czytać.

Zmienił bym też układ w otoczeniu przypadku "oglądaj swój profil". Po pierwsze nazwa przypadku sugeruje, że jest to operacja czytania, a z rozszerzeń wnioskuję, że także edycji. Więc "zarządzaj profilem" albo "Edycja profilu użytkownika" były by bardziej na miejscu. Wszystko to, jeżeli jesteś faktycznie przekonany o tym, że extend na tym etapie projektu wynika faktycznie z analizy wymagań i użytkownik nie powinien od razu referować do tego co aktualnie jest rozszerzeniem.

Zauważ też, że wprowadziłeś dwie kategorie użytkowników systemu - Gościa i Użytkownika. W zasadzie to wystarczy dla oreślenia reguł security. Nie ma więc powodu dodawać przypadku "Uwierzytelnianie". Wystarczy, że Użytkownik będzie korzystał z przypadku "Logowanie" (chyba go nie widzę) i inne przypadki w cale nie muszą być z nim powiązane. Domyślam się, że intencja była taka, żeby użytkownik mógł zalogować się z dowolnej strony serwisu. Niemniej jednak jest to raczej element wymagań funkcjonalnych który pojawi się potem w architekturze czy design'ie.

Poza tym, to co widzę, to tylko bombelki - diabeł tkwi w samym opisie przypadków. Dla mnie osobiście same bombelki mają jedynie charakter ilustracji do tekstu.

Poza tym, jeżeli jest to praca na zaliczenie, to stosuj reguły, których nauczyli Cie Twoi profesorowie a nie słuchaj ludzi na GL ;-)

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

Michał S:

Michał Wolski:
Moim skromnym zdaniem lepiej mieć o kilkanaście stron więcej niż jeden diagram wydrukowany na A3. Liczy się także użyteczność dokumentacji a nie jej objętość. Diagram A3 jest nieużyteczny bo nieczytelny. Ale tak jak wspomniałem tylko moim skromnym zdaniem.

Moja subiektywna opinia, diagram na całą ścianę urąga wszelkim dobrym praktykom... w szczególności utrzymywania właściwego poziomu szczegółowości na właściwym poziomie abstrakcji. Nie przypadkiem kartografia dorobiła się podziału map na skale, wielko- i małoskalowe mapy, w tym ich podziału na sensowne arkusze.

Nie chce wchodzić w głębszą polemikę, ale profesorowie na uczeli pokazywali diagramy US, które zajmowaly wiele wiele wiecej niz marne A3

bez komentarza

Jarek Żeliński:
Mam dziwne wrażenie, że ten diagram UC próbuje tu zastąpić diagram klas. Nie jest chyba dobrą drogą:
- diagram klas to baza danych
- diagram UC to architektura (moduły) systemu, kolejność zdarzeń itp...

wiem co to jest diagram klas i jakos ni wzab nie widze na moim UC podobnosci?? Prosze o wsparcie decyzji konkretnym przykladem

zarządzanie galerią zdjęć to klasa zdjęcie zaś wiele z tych extend i include to operacje tej klasy, UC dodaj, usuń itp. to typowe CRUD, pozostałe UC to możliwe elementy scenariuszy jednego prostego przypadku użycia, tym przypadkiem jest zarządzanie repozytorium zdjęć. "Zobacz ranking zdjęć konkursowych" to także operowanie na klasie zdjęcie, pozostałe UC maja podobne wady. Czym się różni zdjęcie konkursowe od pozostałych poza atrybutem i powiązaniem z konkretnym konkursem zaś brakuje UC "organizacja (założenie) konkursu. Diagram w moich oczach jest bardzo trudny w czytaniu i mocno niekompletny.

a UML to:
- UC to przypadku użycia, TYLKO interakcje użytkownika z systemem (jeden bąbel na elementarną i niezależna funkcjonalność)
- diagram klas zawiera klasy encyjne (materiał na bazę danych, model dziedziny) i klasy "wykonawcze" czyli moduły systemu, jak ktoś ma kłopot polecam opis wzorca np. MVC.

wiem co to encje... ale chyba nie taka byla moja prosba... Chodzi mi o wstepny komentarz UC, czy to co zaprezentowalem wydaje sie zrozumiale i w jakiś sposób czytelne....

Zakładam, że kolega wie co to encje i mimo to podtrzymuje swój komentarz do diagramu UC.

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

Dziękuje za cenne uwagi,

Macie Panowie (nie wiem jak mam się zwracać :P) rację. Niezbędna jest dekompozycja diagramów.

W celu sprecyzowania tego jak ma funkcjonować system chciałem pokazać ile to on nie bedzie miał opcji i wogle.... i chyba to nie było słuszne załozenie.

Prosze jeszcze o pomoc z tymi extendami. Moja logika polegala na tym ze np. ogladajac swoj profil mamy dostep do nastepnych funkcji jak zarzadzanie galeria zdjec itp... Chcialem by na podstawie UC bylo to widoczne (nie mozna edytowac galerii zdjec bez wejscia na strone profilową) tylko nie wiem czy zamierzony efekt mi wyszedl...

Co do logowania tez prosze o opinie. Uzytkownik to specjalny przypadek goscia, ktory poprostu jest zalogowany. To jest warunek by dostac dostep do szerszej funkcjonalnosci. Zreszta taki warunek wystepuje jako pierwszy w kazdym z Controlerow (uzywam ZEND framework, cala aplikacji jest w php)Michał S edytował(a) ten post dnia 01.07.09 o godzinie 00:33

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

Michał S:
W celu sprecyzowania tego jak ma funkcjonować system chciałem pokazać ile to on nie bedzie miał opcji i wogle.... i chyba to nie było słuszne załozenie.

Nie do końca. Właśnie dla tego nie powiedziałem kategorycznie "NIE". Pokazanie takiego diagramu może okazać się przydatne bo uczy pokory wobec zadania. Przy dalszej analizie jest to oczywiście szalenie niepraktyczne podejście - tak więc zależy do czego chcesz użyć tego diagramu.

Prosze jeszcze o pomoc z tymi extendami. Moja logika polegala na tym ze np. ogladajac swoj profil mamy dostep do nastepnych funkcji jak zarzadzanie galeria zdjec itp... Chcialem by na podstawie UC bylo to widoczne (nie mozna edytowac galerii zdjec bez wejscia na strone profilową) tylko nie wiem czy zamierzony efekt mi wyszedl...

Myślę, że notatka w opisie przypadku (warunek wejściowy) ewentualnie jakiś diagram sekwencji powinny lepiej to zobrazować.
Rozszerzenie mówi, że czynność opisywana przez przypadek A może być rozszerzona przez czynność przypadku B. Czyli myśląc w kategorii web-page - na stronie "Edycji Profilu" jest kawałek pozwalający na "Edycję zdjęć". A to już po pierwsze nie musi być prawdą, po drugie nie rozstrzygał bym tego teraz. Jeżeli już jakaś czynność rozszerzała by przypadek "Edycja Profilu" to było by to "Przejście do galerii zdjęć". Nie jest to jednak dobry kandydat na przypadek użycia.
Z tego co piszesz ("wejscia na strone profilową") myślisz już o strukturze serwisu jako sekwencji stron WEB. Trochę na to za wcześnie - albo zbyt dużo oczekujesz od analizy przypadków użycia.

Co do logowania tez prosze o opinie. Uzytkownik to specjalny przypadek goscia, ktory poprostu jest zalogowany. To jest warunek by dostac dostep do szerszej funkcjonalnosci. Zreszta taki warunek wystepuje jako pierwszy w kazdym z Controlerow (uzywam ZEND framework, cala aplikacji jest w php)Michał S edytował(a) ten post dnia 01.07.09 o godzinie 00:33

Zauważ, że używasz słowa "warunek". Moim zdaniem wystarczy, że w opisie przypadku podasz jako warunek wejścia - "użytkownik jest zalogowany".
Tak na prawdę nie jest to konieczne, ponieważ Użytkownik i Gość korzystają z innych przypadków użycia, taka dodatkowa informacja, może być jedynie przydatna po to, żeby rozwiać ewentualne wątpliwości. Ważne abyś w słowniku projektu, opisał pojęcie Użytkownik'a i Gościa w taki sposób, aby było widać, że ten pierwszy będzie mógł więcej.

Aha, nie wiedzę nic o rejestracji/tworzeniu nowego użytkownika?

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

Jeśli chcesz naprawdę sprawdzić, czy dobrze narysowałeś "bąbelki", to powinieneś zacząć od dobrej strony, czyli od scenariuszy.
Pierwsze co użytkownik powinien zrobić to wpisać adres serwisu. I co wtedy powinno mu się pokazać ? Z Twojego diagramu wynika raczej, że użytkownik wpisuje adresy do stron realizujących UC: wyloguj, oglądaj, komentuj, a przez gościa: oglądaj, zobacz, czytaj itd. Czy tak działają serwisy ????????
Zacznij od scenariusza głównego:
1. Aktor loguje się do systemu; 2. System realizuje Logowanie, po czym System pokazuje menu główne
3. Aktor wybiera "Przeglądaj artykuł", 4. System realizuje UC...
5. Aktor wybiera "Wyloguj", 6. System wylogowuje z systemu.
Rozrysuj sobie teraz ten przebieg główny, a następnie dorzuć alternatywne przebiegi. Na koniec narysuj sobie wreszcie diagram UC.
Z kroku 1. wynika, że logowanie to <<include>>, bo zawsze się wykonuje. Podobnie wylogowanie.
Z kroku 5. wynika, że "Przeglądaj.." to <<extend>> z warunkiem: wybranie opcji "Przeglądanie...".
Postępując iteracyjnie w ten sposób narysujesz odpowiedni diagram UC, a przede wszystkim będziesz miał uzasadnienie swojego spojrzenia na projektowany system.

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

Do tego co Kolega Jerzy napisal dodał bym jeszcze jedno: zrób sobie liste zdrzeń, które chcesz obsłużyć (które system ma obsłużyć). Te zdarzenia 9prawdopodobnie większośc ad-hoc) to początki opsanych przez Jerzego sceanriuszy. Poszperaj tez za hasłe 'event driven developmnet'

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

Jacek Woźniczak:

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

W metamodelu UML aktor jest uszczegółowieniem klasyfikatora (classifier), natomiast asocjacja jest uszczegółowieniem związku (relationship). Oznacza to, że aktor dziedziczy również asocjacje. Sam opis aktora w UML nie mówi tego nam jednoznacznie.
Ponieważ dziedziczenie to jest niejawne, więc zazwyczaj na diagramie przypadków użycia nie pokazujemy dziedziczenia między aktorami, gdyż zazwyczaj klient nie zauważa takich "asocjacji niejawnych". Ponadto takie "asocjacje niejawne" mogą wprowadzać zamieszanie, gdy ktoś narysuje jednak asocjację jawną. Nie wiadomo wtedy, czy jest to pomyłka, czy jest to nadpisanie "overriding", czy może nawet redefinicja.
W każdym bądź razie ja staram się unikać jak tylko można "asocjacji niejawnych".

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

Mam następujący problem, natury raczej ogólno-teoretycznej niemniej jednak występujący w praktyce.
Otóż: załóżmy, że mamy diagram deployment z kilkoma komponentami.
Komponenty te udostępniają interfejsy przynajmniej dwóch rodzajów: nazwijmy to systemowe (do komunikacji z innymi systemami lub komponentami) oraz stanowiące interfejs użytkownika.
O ile prosto jest przedstawić który komponent korzysta z interfejsów systemowych, o tyle nie bardzo wiem, jak zobrazować fakt, że dany interfejs jest interfejsem użytkownika.
Spotkałem się z rozwiązaniem, gdzie interfejsy użytkownika były modelowane za pomocą komponentów ze stereotypem <GUI>. Nie bardzo mi się to rozwiązanie podoba, ponieważ jest nielogiczne semantycznie (ponieważ komponent to nie interfejs).
Można też na diagramie pokazywać komponent pod hasłem WebBrowser - i jest to moim zdaniem bardziej poprawne, przy założeniu, że umiemy powiedzieć które komponenty są elementami projektowanego systemu, a które są dostarczane z zewnątrz. Nadal jednak założenie, że korzysta z WebBrowser'a człowiek jest raczej zapisane pomiędzy wierszami.
Można by też wstawiać element aktora, z tym, że nie jestem przekonany czy jest to zgodne ze składnią UML.
Na wikipedi jest diagram obrazujący webbrowser jako oddzielny węzeł

. Wydaje mi się to też trochę dziwne, ponieważ węzły - w moim odczuciu - powinny obrazować raczej lokalizację komponentów - czy web browser może być lokalizacją? Jeżeli tak, to pewnie dla stron web, albo aplikacji web (w dobie RIA).
Ciekawi mnie jakie jest Wasze podejście do problemu?

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

Artur Kęska:
Mam następujący problem, natury raczej ogólno-teoretycznej niemniej jednak występujący w praktyce.
Otóż: załóżmy, że mamy diagram deployment z kilkoma komponentami.
Komponenty te udostępniają interfejsy przynajmniej dwóch rodzajów: nazwijmy to systemowe (do komunikacji z innymi systemami lub komponentami) oraz stanowiące interfejs użytkownika.
O ile prosto jest przedstawić który komponent korzysta z interfejsów systemowych, o tyle nie bardzo wiem, jak zobrazować fakt, że dany interfejs jest interfejsem użytkownika.

Ogólnie znany jest problem asocjacji w UML, że ciężko jest je "ładnie i prosto" je opisać. Jest to dość słąby element UML.

Spotkałem się z rozwiązaniem, gdzie interfejsy użytkownika były modelowane za pomocą komponentów ze stereotypem <GUI>. Nie bardzo mi się to rozwiązanie podoba, ponieważ jest nielogiczne semantycznie (ponieważ komponent to nie interfejs).

Jest jak najbardziej logiczny semantycznie i UML zezwala na to.

Można też na diagramie pokazywać komponent pod hasłem WebBrowser - i jest to moim zdaniem bardziej poprawne, przy założeniu, że umiemy powiedzieć które komponenty są elementami projektowanego systemu, a które są dostarczane z zewnątrz. Nadal jednak założenie, że korzysta z WebBrowser'a człowiek jest raczej zapisane pomiędzy wierszami.

element Actor w UML to rola, która może być interpretowana zarówno jako człowiek jak i jakiś system zewnętrzny.

Można by też wstawiać element aktora, z tym, że nie jestem przekonany czy jest to zgodne ze składnią UML.

też jest zgodne, aktor może wchodzić w interakcje nie tylko z use-case'ami, ale też z komponentami i klasami, przy czym asocjacje te muszą być binarne.

Na wikipedi jest diagram obrazujący webbrowser jako oddzielny węzeł

. Wydaje mi się to też trochę dziwne, ponieważ węzły - w moim odczuciu - powinny obrazować raczej lokalizację komponentów - czy web browser może być lokalizacją? Jeżeli tak, to pewnie dla stron web, albo aplikacji web (w dobie RIA).
Ciekawi mnie jakie jest Wasze podejście do problemu?

No niezbyt to wygląda poprawnie, ale być może autor użył jakichś stereotypów, o których nic nie wiemy. Raczej w węźle powinien być komponent reprezentujący przeglądarkę, ale ....

Ogólnie mówiąc zamodeluj tak, by wszyscy zainteresowani wiedzieli o co chodzi. ja ostatnio użyłem aktora związanego z komponentem, by podkreślić, że administrator przesyła mejlem do systemu jakieś tam dokumenty. Chodzi o to by było czytelnie i prosto.

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

Artur Kęska:
Mam następujący problem, natury raczej ogólno-teoretycznej niemniej jednak występujący w praktyce.
Otóż: załóżmy, że mamy diagram deployment z kilkoma komponentami.
Komponenty te udostępniają interfejsy przynajmniej dwóch rodzajów: nazwijmy to systemowe (do komunikacji z innymi systemami lub komponentami) oraz stanowiące interfejs użytkownika.

W zasadzie każdy program ma jeden GUI będący modułem, komponentem implementującym przypadki użycia. GUI samo w sobie jest interfejsem (dla użytkownika) do wszystkich pozostałych.

We wzorcu MVC np. także jest to jedna warstwa, komponent. Więc użytkownik ma styczność wyłącznie z komponentem implementującym widok.

Więc moim zdaniem przykład z WIKI jest jak najbardziej OK.

O ile prosto jest przedstawić który komponent korzysta z interfejsów systemowych, o tyle nie bardzo wiem, jak zobrazować fakt, że dany interfejs jest interfejsem użytkownika.

a nie wystarczy nadać mu nazwy IUżytkownika?

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

Jarek Żeliński:
Więc moim zdaniem przykład z WIKI jest jak najbardziej OK.

Unified Modeling Language: Superstructure, version 2.0, formal/05-07-04.
16.3 Class Descriptions
16.3.1 Actor (from UseCases)
Constraints
[1] An actor can only have associations to use cases, components, and classes. Furthermore these associations must be binary.

Zatem aktor nie może posiadać asocjacji z węzłem.
Proszę nie wprowadzać w błąd innych osób.

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

Jerzy N.:
Zatem aktor nie może posiadać asocjacji z węzłem.
Proszę nie wprowadzać w błąd innych osób.

Interfejs to klasa, jeżeli jakiś moduł (kod) jest komponentem obsługującym ekran logowania to aktor ma logiczny związek z tym kawałkiem kodu, po drugie, wymienione ograniczenie dotyczy "Actor (from UseCases)" a tu nie mamy przypadku użycia tylko aktora i kawałek kodu,

pomijam tu fakt, że osobiście nie stosuję takich konstrukcji bo są sztuczne... model wdrożenia pokazuje gdzie co jest zainstalowane a kto czego używa...

autor pytania sam zaznacza, że pytanie jest "ogólno-teoretyczne" więc tak samo zostało potraktowane.... zastanawiam się jaki cel miała by taka konstrukcja na diagramie...