Diagram przypadków użycia aplikacja webowa

Witam czy mógłby ktoś zerknąć na mój diagram przypadków użycia. Potrzebuje go do pracy inżynierskiej a szczerze nie polubiłem się z tym tematem.

Nie chciałbym zakładać nowego tematu sprobuje zapytać tutaj. Generalnie w pracach inżynierskich diagram er oraz model relacyjny pokazane są w dwóch schematach. Wygenerowałem przez Azura diagram i wydaje mi się ze spełnia on założenia zarówno diagramu er a także modelu relacyjnego. Czy jeśli dodam to jako jedno bez podzielenia będzie to duży błąd?![1.png](

Diagram przypadków użycia do kosza. Doczytaj trochę teorii: https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-use-case-diagram/

1. Diagram wygląda tak jakbyś chciał przedstawić strukturę strony webowej/aplikacji na tel., a nie przypadki użycia.
2. Nazwa aktora "Actor" - to nie jest rola biznesowa, chyba, że domena ma związek z filmami i aktorzy są użytkownikami systemu
3. Nazwy przypadków użycia powinny dotyczyć czynności, a u Ciebie "Baza wiedzy", "Dziennik treningowy". Jaki cel biznesowy realizuję przez przypadek użycia "Baza wiedzy"?
4. include/extends - extends dotyczy opcjonalnej czynności w ramach realizacji danego przypadku użycia, include oznacza włączenie innej czynności do danego przypadku użycia (=zawsze).
   Zawsze przy logowania wymuszasz na użytkowniku uzupełnianie danych? :-)
5. Pomyśl o pokazaniu osobnych grup przypadków użycia (pakiety, np. funkcjonalne) na jednym diagramie, albo główny diagram do zilustrowania pakietów i osobne diagramy dla zilustrowania co wchodzi w zakres pakietu.

Co do diagramu ER, modelu relacyjnego.

• ER - masz koncepty (encje) i związki między nimi
• model relacyjny (relacja=tabela) - masz pokazane tabele modelujące encje albo związki.

Diagram ma ułatwiać zrozumienie, a nie utrudniać. Spójrz na swój diagram, która relacja jest związkiem, a która encją? Czy powinieneś to komunikować odbiorcy? Spójrz na etykietkę "id" - co to znaczy? (Nie musisz mi odpowiadać na te pytania, ale samemu sobie :-) )

@yarel nawiązując do diagramu przypadków użycia chce się upewnić że dobrze zrozumiałem:
2. Zamiast aktora użytkownik ?
3. Bazą wiedzy czyli czynność wyświetlenie artykułów, strona główna czyli wyświetlenie strony głównej ?
4. No wydaje mi się że wymuszamy na użytkowniku jeśli chce się zalogować podania danych potrzebnych do zalogowania

Jeśli chodzi o diagram er coś takiego?
Dzięki wielkie za odpisanie

1. Zamiast aktora użytkownik ?

Powinieneś myśleć o aktorach jak o rolach w systemie i to co te role mogą realizować. Masz Użytkownik ok, ale co może zrobić w systemie? Czasem wypadałoby rozróżnić.
Możesz mieć, np. Guest (niezarejestrowany albo niezalogowany), Member (zarejestrowany i zalogowany), Moderator, Administrator, ...

To można pokazać jako:

• osobnych aktorów (role) połączonych na diagramie z przypadkami użytkownika
• generalizacją ("Użytkownik") i dwie specjalizacje ("Zalogowany użytkownik", "Niezalogowany użytkownik")

Niektóre przypadki użycia mogą być realizowane przez różne role, dlatego zamiast łączyć role z przypadkami użycia, można połączyć tylko generalizację.

1. Bazą wiedzy czyli czynność wyświetlenie artykułów, strona główna czyli wyświetlenie strony głównej ?

"Wyświetl artykuł"
"Dodaj artykuł do bazy wiedzy"
"Skoryguj artykuł"
"Otaguj artykuł"
"Wyszukaj artykuł"
...

1. No wydaje mi się że wymuszamy na użytkowniku jeśli chce się zalogować podania danych potrzebnych do zalogowania

Rozumiem o co Ci chodzi, ale z perspektywy diagramu przypadków użycia masz "Uzupełnienie danych", które jest obowiązkowe (include) przy rejestracji i logowaniu.
Pomyśl o przypadku użytkownika jako interakcji z systemem, gdzie input przekazujesz via formularze. Dlaczego chciałbyś wyświetlać ten sam formularz "Uzupełnij dane" dla rejestracji i dla logowania? Obstawiam, że to są różne zakresy danych (różne przypadki użycia) i różne formularze.

Co do ER, to tak bliżej temu o co chodzi. Sprawdź sobie jak modelujesz one-to-many, bo z diagramu wygląda, że wpadłeś w FAN TRAP (powiązania między encjami układają się w skrzydła wiatraka):

Diagram przypadków to prosta lista. W stylu Użytkownik możę dodać produkt, Użytkownik może dodać cwiczenie , Użytkownik może usunąć cwiczenie .

Moje rady:

• skup się na akcjach i tylko na akcjach. Wewnętrzna struktura aplikacji nie ma tu żadnego znaczenia
• include i extend prawie zawsze nie ma sensu
• zrób większe akcje. Np. zarządzanie produktami zamiast dodaj/usun/zobacz
• ma być prosto. Najczęściej jest to jeden aktor i kilka chmurek obok niego

@yarel jeżeli podzielę na zalogowanych i niezalogowanych jak powinno wyglądać w takim razie przejście do tabeli baza produktów? Tylko zalogowani mogą dodawać produkty. Zostawić to w taki sposób jak mam czyli dać komentarz? Jeśli chodzi o include/extend przy logowaniu i rejestracji nadal nie rozumiem ale zastosuję extend. Jeśli chodzi o resztę relacji jest ok? A z fan trap to już całkowicie nie wiem o co chodzi

@slsy dziękuję za odpowiedź. Żebym dobrze zrozumiał może to wyglądać tak użytkownik-zalogowany- uzupełnienie dziennika dietetycznego- dodanie posiłku- dodanie produktu-zarządzanie produktami?

macfal napisał(a):

@slsy dziękuję za odpowiedź. Żebym dobrze zrozumiał może to wyglądać tak użytkownik-zalogowany- uzupełnienie dziennika dietetycznego- dodanie posiłku- dodanie produktu-zarządzanie produktami?

Ja bym zrobił tak:

• użytkownik zalogowany - 1. zarządzanie dziennikiem dietetycznym
• użytkownik zalogowany - 2. zarządzanie dziennikem treningowym

I tyle. Zazwyczaj pod diagramem wypisuje się listę aktywności. Diagram to ma być tylko podgląd

Przykładowo:

1. zarządzanie dziennikiem dietetycznym

Użytkownik może:

• dodawać/przeglądać/usuwać/modyfikować listę produktów spożywczych
• dodawać/przeglądać/usuwać/modyfikować listę posiłków bazując na liście produktów spożywczych
• dodawać/przeglądać/usuwać/modyfikować dziennik dietetyczny na podstawie wprowadzonych posiłków
• przeglądać statystyki związane z dziennikem dietetycznym
  • spożyte kalorie per dzień
  • dla bieżacego dnia: ile jeszcze może zjeść
  • zmiany w trendzie np. w tym tygodniu zjadł mniej niż w poprzednim

macfal napisał(a):

@yarel jeżeli podzielę na zalogowanych i niezalogowanych jak powinno wyglądać w takim razie przejście do tabeli baza produktów? Tylko zalogowani mogą dodawać produkty.

Możesz dodać aktora "Użytkownik" i 2 specjalizacje "Zalogowany użytkownik" i "Niezalogowany użytkownik". Zrobić połączenia od "Użytkownik" do tych przypadków użycia, które są wspólne dla zalogowany/niezalogowany i strzałki od specjalizacji, które są specyficzne dla danej roli (np. rejestracja dla zalogowanego nie ma sensu).

Zostawić to w taki sposób jak mam czyli dać komentarz? Jeśli chodzi o include/extend przy logowaniu i rejestracji nadal nie rozumiem ale zastosuję extend.

Czy dane przy rejestracji i logowaniu są takie same? Jeśli nie, to są to różne przypadki użycia. Jeśli są różne, to dlaczego mają taką samą nazwę?
Wywaliłbym to uzupełnianie danych i miał takie przypadki użycia:

• Zarejestruj użytkownika/utwórz profil/załóż konto (nazwa czynności wedle uznania)
• Zaloguj (tu na upartego mógłbyś dodać opcjonalność rejestracji)
• Aktualizuj dane użytkownika (np. obrazek profilu, adres, nr telefonu itp.)

A z fan trap to już całkowicie nie wiem o co chodzi

Przy połączeniach encji można popełnić dwa podstawowe rodzaje błędów:

• fan traps
• chasm traps

O co chodzi? Lektura -> np. https://www.javatpoint.com/problems-with-er-model

U Ciebie, wizualnie na diagramie występuje formacja wiatraka (np. od MealProducts wychodzą 3 połączenia 1-0..N). Podejrzewam, że coś może być nie tak z modelem, albo diagramem.

Spójrz na połączenie między MealProducts i Meals. Nie wiem co chciałeś wyrazić, więc może jest ok, ale podejrzewam, że zamiast A->B chciałeś pokazać B ->A
Czy u Ciebe Meal ma dokładnie 1 MealProduct? Tak by wynikało z powyższego diagramu.

Dla poglądu połączenie 1-0..N

• Szkoła może mieć 0..N uczniów
• Uczeń chodzi do 1 szkoły

To na diagramie ER może wyglądać tak (screen zrobiony ze strony visual paradigm):

@yarel gemeralnie mocno sugerowałem się tym co mi wygenerował azure. Natomiast początkowo miałem to zrobione w ten sposób blob:null/0891f792-a1fd-4bfa-8052-897628ad3a25 Generalnie tabela mealprodukt jest łączącą w dzienniku tworzymy posiłek a do posiłku dodajemy produkty. Wieczorem postaram się zrobić raz jeszcze ten diagram przypadków użycia.

Przepraszam że w takiej formie ale aktualnie brak dostępu do komputera a czas bardzo mocno goni. Jeśli to nie problem proszę o opinię.

@yarel czy mógłbym liczyć jeszcze na Twoją pomoc

@macfal lepiej. Jeśli chodzi o nazwy przypadków, to powinny być "Zarządzaj...", a nie "Zarządzanie ... ". Powyższe Twoje zapiski można skonwertować do diagramu, np.

W finalnym diagramie możesz (w zależności od liczby przypadków użycia) utworzyć osobne grupy dla zarządzania, np. "Zarządzanie treningiem", "Zarządzanie dietą" itd.

@macfal Dostałeś bardzo dobrą odpowiedź od @yarel.

Od siebie dodam tylko, że nie należy mylić diagramów baz danych (tabele, klucze, id), z diagramem przypadków użycia. One nie koniecznie powinny być 1:1, często nie da się ich przemapować.

@yarel dziękuję bardzo za pomoc. Teraz wygląda to naprawdę dobrze