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

Witam :)
Wykonuję mały projekt na zajęcia. Zrobiłem taki Use Case Diagram i chciałbym usłyszeć opinie na jego temat, ponieważ coś mi w nim nie pasuje, ale nie wiem do końca co? :)
Aha i małe pytanie jeśli chodzi o nazwy funkcjonalności, czy mają to być formy rzeczownikowe czasownika (tak jak na moim diagramie), czy tej tryb rozkazujący czasownika (np. Rejestruj zlecenie)?





pozdrawiam

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

Dziękuję za cenne rady, na pewno z nich skorzystam przy poprawieniu diagramu :) pozdrawiam

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

Diagram przypadków użycia: diagram ten buduje się w oparciu o tzw. metodę separation of concern - podział na zagadnienia. W Twoim opisie np. Użytkownik używa przypadku Zaloguj się, który następnie zostaje rozszerzony o przypadek Załóż konto. Prawidłowo powinno być, że Aktor używa przypadku Załóż konto (bo tak naprawdę jest to jedno z głównych zagadnień), który to przypadek może być rozszerzony (a właściwie powinien być włączony - include) o przypadek użycia Logowanie. Logowanie jest pobocznym zagadnieniem w Twoim przypadku. Poza tym dziwne jest, że inni aktorzy nie wykorzystują przypadku użycia Zaloguj się. 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.
Ważniejsza sprawa to include i extend (zwracaj uwagę na strzałki w tych związkach). Zazwyczaj include oznacza bezwarunkowe włączenie wskazanego dodatkowego przypadku do tzw. bazowego, natomiast extend pokazuje warunkowe włączenie dodatkowego przypadku do wskazywanego, rozszerzanego przypadku (często pokazuje się w rozszerzanym przypadku punkt rozszerzenia i warunek). Poza tym na Twoim diagramie nie trzeba rysować asocjacji Użytkownika z przypadkiem Zaloguj się (przy założeniu, że to przypadek Zaloguj się rozszerza przypadek Załóż konto, a nie jak u Ciebie), gdyż wystarczy pokazanie asocjacji do przypadku Zaloguj się. Wszystkie pozostałe przypadki włączane (include, exclude) nie muszą już mieć asocjacji z tym aktorem. Nie określiłeś również związku pomiędzy przypadkami Wygeneruj listę galerii, a Przeglądaj galerię. Wszystkie "główne" przypadki powinne być skojarzone z aktorem.
To tylko pierwszy rzut oka na ten diagram. Jak wcześniej wspomniałem diagram ten należy budować w oparciu o tzw. separation of concern, czyli kojarzyć aktorów z głównymi zagadnieniami.
To oczywiście początek, bo tak naprawdę poinieneś najlepiej rozpisać wszystkie scenariusze i dopiero wtedy zaczną Ci się układać przypadki użycia we właściwe związki i powiązania.
Diagram klas:
Agregacja - z diagramu wynika, że Administrator składa się wyłącznie z jednego autora, natomiast Autor może wejść w skład Administratora .... chyba Ci nie o to chodziło, prawda ?
Agregacja całkowita oznacza, że jak nie ma zdjęcia, to nie ma galerii - też chyba nie o to Ci chodziło, prawda ?
Zdarzenie to zupełnie odrębny byt, tak mi się wydaje, aniżeli Autor, Galeria, Fotografia, więc co oznacza to dziedziczenie ? Chyba Ci chodziło wyłącznie o jakiś związek pomiędzy tymi, różnymi bytami.
Mam nadzieję, że Ci nie pomieszałem zbytnio ;)

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

Marcin Wrzesiński:
Jerzy N. no namieszałeś mi i to ostro,aż sam się pogubiłem :)

Ad Diagram przypadków użycia:
1. Aktor "Użytkownik" jak widać jest abstrakcyjny (jest pisany pochyła czcionką). Od "użytkownika" dziedziczą aktorzy "Administrator", "Autor" i "Użytkownik publiczny" (dla łatwość nazwijmy go po prostu "publiczny"). Tak więc w moim postrzeganiu PU poprzez aktora "użytkownik" może logować się i "administrator" i "autor" i "publiczny".

"Dziedziczenie" to pokazania tego typu mechanizmów rzadko się stosuje, albo wcale. Rozumiem o co Ci chodzi, że chciałeś sobie "skrócić", ale tego się nie praktykuje. A tak na dobrą sprawę musiałbym pogrzebać w UML czy to dozwolone ;)
Praktykuje się asocjacje od aktorów do odpowiednich przypadków.
Poza tym spróbuj może napisać sobie takie scenariusze (krok po kroku) ... ciekawe co Ci wyjdzie ;))))

2. Jeśli chodzi o PU "zaloguj się" i "załóż konto" ja to widzę tak:
publiczny korzysta z aplikacji i chce założyć konto więc od razu korzysta z przypadku "załóż konto" lub "publiczny" korzysta z PU "zaloguj się", okazuje się że nie posiada konta więc przypadek "zaloguj się" jest rozszerzany o "załóż konto".

Dla początkujących projektantów problem istnieje w przyswojeniu sobie idei przypadków użycia. Przypadki użycia mają być zestawem zamkniętych kroków. A związki include, czy extend to nie jest kontrola sterowania, ale wyróżnianie w danym przypadku pewnych wspólnych kroków. Nie patrz na use case'y jak na czynności, które są w jakiejś kolejności wykonywane.
Wyobraź sobie wpierw co robi Użytkownik. Wprowadza adres strony i co dalej ? Formularz pokazuje mu albo się zaloguj, albo załóż nowe konto. Może powinien być przypadek wejdź na stronę ? Ależ nie. Zaloguj się jest tym pierwszym ekranem, więc Użytkownik, by założyć konto musi wpierw uruchomić przypadek Zaloguj się.
Oczywiście, o ile nie powinniśmy stworzyć przypadku obsługa konta i włączyć do tego przypadku pozostałe przypadki i w ten sposób unikamy sporej ilości asocjacji. I raczej ten kierunek bym Ci polecał, od ogółu do szczegółu.

3. Includy i Extendy mam w dobra stronę (przynajmniej mi się tak wydaje) bo publiczny wywołując "wygeneruj listę autorów" włącza następnie (po wybraniu autora) "wygeneruj listę galerii". Tu z kolei po wybraniu galerii przechodzi do "przeglądaj galerie". (Za łożyłem że bez wybrania galerii z uprzednio wygenerowane listy nie można przejrzeć galerii)

Podobnie jak poprzednio. Włączany przypadek może być włączony na samym poczatku innego. Kolejność wchodzenia w interakcję aktora z przypadkami nie jest przedmiotem diagramu przypadków użycia. Opisuje tylko jakie funkcje oferuje system aktorowi.

Ad Diagram klas:
1. Spojrzałeś na poprzedni diagram a nie na ostatni chyba
2. Kompozycja (agregacja całkowita jak wolisz) z tego co wyczytałem i zrozumiałem to niema zdjęcia bez galerii gdyż galeria jest "całością" a zdjęcie "częścią" (z tego co mądre książki piszą to romb jest przy całości a nie przy części)

Kompozycja może powodować to, że usunięcie jej części powoduje usunięcie obiektu głównego. Znaczy, że jak ze stołu usuniesz blat, to nie będziesz miał stołu. Jest to związek bardzo mocnego typu i rzadko się go stosuje. Aczkolwiek istnieją inne wersje związane z mechanizmem usuwania całości i poszczególnych elementów.

3. W poprzednim diagramie klas klasa Zdarzenie była abstrakcyjna i posiadała operacje wykorzystywana przez 3 inne klasy w ten sam sposób.

Co do obiektów. Jaki cel mają obiekty związane z aktorami ? Aktorzy są poza systemem i nie wchodzą w jego skład. Tutaj coś Ci się chyba dość mocno pomyliło. Z tego diagramu wynika, że bierzemy obiekt np. Autor i uruchamiamy metodę usunKonto(). Tutaj powinieneś zamodelować obiekt Konto i wprowadzić metodę usunKonto(). Albo może trzy obiekty kontoAutora, KontoAdministratora, Kontoosoby .... tylko czy to ma sens ???? Trzy różne konta ? Konto zapewne to samo, ale różne uprawnienia, w zależności od tego kto to konto posiada, prawda ?

Chyba że ciągle coś źle pojmuję. :)
Mam nadzieję że dość jasno napisałem :)

Nie przejmuj się. Głównym celem modelowania jest to, by wszyscy, którzy mają mieć do czynienia z tym modelem, zrozumieli o co chodzi. A reguły używania poszczególnych elementów zawsze się mogą zmienić .... ;)))))))