Siemka.
Chciałbym Was poprosić o weryfikację poprawności tego diagramu UML. Mam pewne wątpliwości, zwłaszcza, przy Petencie zarejestrowanym i zleceniu. Ale... może uda Wam się wypatrzyć coś jeszcze (załącznik). Byłbym wdzięczny za pomoc. ;)
Wg mnie to dużo do poprawy, ja nie rozumiem tego diagramu. Za dużo zbędnych generalizacji to się nie uda przy implementacji. Dziwne nazewnictwo klas. Źle użyta kompozycja, która przedstawia związek część-całość gdy cykl życia obu obiektów jest powiązany. Zatem w Twoim diagramie w systemie lokalizacja czy pojazd medyczny nie może istnieć jeżeli usunę świadczenie medyczne. Raczej odpowiedzialność za obsługę faktur powinien mieć obiekt ku temu przeznaczony, a nie pracownik. Pracownik może być co najwyżej zależnością.
Do bani... Jeśli to na zaliczenie/studia/do szkoły to "pała" murowana.
Spojrzałem tylko na jedną klasę (pracownik) i są w niej różne metody jednak nie widzę klas za nie odpowiedzialnych t.j.: Faktury, raporty, zleceniodawcy, zlecenia.
W użytkowniki są metody zaloguj i wyloguj a nie ma nigdzie danych autoryzacyjnych. Może pokaż diagram ERD, który być może coś wyjaśni i jest jakimś uzupełnieniem powyższego. Jednak jeśli go nie ma to to co pokazałeś jest bez sensu i niekompletne. Nie wiadomo co te prostokąty rzeczywiście odzwierciedlają ..
Taki diagram w komplecie z bazą ( w tym przypadku wg mnie niezbędny ) ma pokazać jak działa system i co ma zaprogramować a z tego wynika jedynie jakiś chaos.
p.s. nie ma czegoś takiego jak "diagram UML" lub jest to bardzo nieprecyzyjne. W ramach UML mamy różne diagramy o różnych zastosowaniach i nazwach.
Twój diagram to diagram klas.
Mikołaj Kabała napisał(a):
Siemka.
Chciałbym Was poprosić o weryfikację poprawności tego diagramu UML. Mam pewne wątpliwości, zwłaszcza, przy Petencie zarejestrowanym i zleceniu. Ale... może uda Wam się wypatrzyć coś jeszcze (załącznik). Byłbym wdzięczny za pomoc. ;)
To jest źle. Dużo by pisać co jest nie tak.Kilka przykładów.
Najlepiej usuń to i narysuj od nowa, bo poprawa tego zajmie Ci więcej czasu.
Jak napisał @malencki lepiej narysuj to od nowa.
Dla ułatwienia wypisz tutaj na forum jakie element,i zdarzenia mają być obsługiwane w systemie - językiem potocznym.
a też przez obecną sytuację nie mamy skąd się dowiedzieć, jak takie diagramy tworzyć, stąd ta porażka i do niej się przyznaje :P
Błagam Cię...
Obejrzyj i wypisz jakie "elementy" masz w systemie.
katakrowa napisał(a):
a też przez obecną sytuację nie mamy skąd się dowiedzieć, jak takie diagramy tworzyć, stąd ta porażka i do niej się przyznaje :P
Błagam Cię...
Obejrzyj i wypisz jakie "elementy" masz w systemie.
Po obejrzeniu, zrozumiałem jedynie, że elementy są klasami. Więc odpowiedź pozostaje bez zmian. Nie ma tak naprawdę różnicy, jakie elementy, czy też relacje będą między nimi. Ogólnie chodziło mi o to, żeby w takim diagramie umieścić użytkownika, który będzie interfejsem/abstrakcją, posiadające wszelkie dane chronione (imię, nazwisko, adres zamieszkania szczegółowy, PESEL, telefon). Od klasy Użytkownika, chciałem żeby wychodził Pacjent, który jest zarejestrowany i on może korzystać i zlecać pewne rzeczy do wykonania w systemie. Fakultatywnie, pacjent niezarejestrowany, który może mieć możliwość rejestracji, po czym skorzystania z usług systemu, czyli również może wykonywać czynności dodawania/usuwania/modyfikowania zleceń. Jeśli chodzi o klasę Pracownik, zamysł jest taki, żeby od niego wychodziły 3 inne podklasy (jeśli to tak można nazwać). Pracownik Systemu/Księgowy, Informatyk/Administrator, Główny Zarządca. Informatyk może właściwie najwięcej z nich wszystkich, bo może dodawać/usuwać/modyfikować pracowników, w tym Głównego Zarządcę. Może korygować na przykład... płynność systemu. Sprawdzać, czy wszystko przebiega poprawnie. Nie może on jednak wykonywać czynności przeznaczonych jedynie dla głównego zarządcy. Dlatego też dyrektor czy też główny zarządca może przyjmować zlecenia od pacjentów, którzy są zapisani. Może mieć kilka możliwości (świadczonych usług medycznych). Pracownik właściwie może zapisywać wnioski osób ubiegających się o pacjenta, czyli po prostu przekazywać deklarację wyboru przychodni, może też je modyfikować, zmieniać. Wysyła je bezpośrednio do głównego zarządcy. Dodatkowo, miałby możliwość przekazywania chęci pacjenta skorzystania z jakichś usług, również do głównego zarządcy. Mam nadzieję, że wyczerpująco odpowiedziałem na Twoje pytanie :P Akcesoryjnie, spróbuję zrobić jeszcze drugi diagram i dosłać go jeszcze dzisiaj do weryfikacji.
Diagram przypadków użycia jest taki :P (załącznik). Co prawda do tego jest osobny temat i nie wiem, czy dobrze rozumiem zaznaczone błędy. Spróbowałem zinterpretować błędy następująco:
Błąd nr 2 przedstawia generalizację, jednakże, strzałki powinny iść w drugą stronę (ponieważ przypadki pochodne muszą pochodzić od przypadków bazowych). Zaznaczony błąd nr 3 pokazuje relację rozszerzania pomiędzy przypadkami użyć. W tym wypadku, kolejki oczekujących mogą być rozszerzone (ale nie muszą) o trzy przypadki. Samo połączenie jest bezbłędne, natomiast problem polega na tym, że przypadek kolejek oczekujących nie ma połączenia z niczym innym w tym systemie.
Błąd nr 4 wskazuje na asocjację petenta zarejestrowanego z jego weryfikacją na liście. Wydaje nam się, że tutaj zachodzi potrzeba asocjacji skierowanej, ze względu na to, że aktor inicjuje przypadek użycia. Stąd jest zastosowana zwykła asocjacja (podobnie jak w przypadku aktora poniżej, gdzie jest petent niezarejestrowany, który bierze udział w rejestracji - powinna być asocjacja skierowana).
Błąd nr 5 pokazuje relację rozszerzania. Powinien on być zamieniony z extend na include, bo przypadek wymaga oceny jakości zdrowia Petenta.
Błąd nr 6 przedstawia relację zawierania. W tym wypadku, przypadek użycia "Wysłanie zgłoszenia" wymaga wypełnienia formularza zgłoszeniowego, więc w tym wypadku przedstawiona relacja powinna być poprawna.
Błąd nr 7 wskazuje na przypadek "Zapisanie zgłoszenia", przy którym obecnie znajduje się jedynie zwykła asocjacja, a powinna być skierowana, ponieważ jest ona inicjowana przez aktora.
Błąd nr 8 pokazuje relację rozszerzania. Prawidłowo została zastosowana relacja extend, ale nieprawidłowo kierunek grotu strzałki - powinno być odwrotnie. Przypadek "Rejestracji" może być rozszerzony o "Przeglądanie korzyści Systemu".
Błąd nr 9 wskazuje na błędną relację. Zamiast relacji include, powinna być extend, bo wszystkie przypadki wsparcia mogą, ale nie muszą być rozszerzane. Nie są one natomiast wymagane.
Finalnie, błąd nr 10 pokazuje, że przypadek "Administrator" wymaga kilku innych przypadków. Otóż, powinna być zastosowana inna relacja. Mianowicie, relacja rozszerzania. Kilka przypadków wychodzących od Administratora powinny mieć groty strzałek skierowane ku niemu i być zamienione z "include" na "extend".
Podsumowując, walka na dwa fronty. Z jednej strony poprawność zaznaczonych błędów, z drugiej strony diagram klas :P (oczywiście kombinuję dalej go rozwijać). Z tego, co zauważyłem, w tym konkretnym przypadku, zbytnia nadgorliwość nie popłacała, więc diagram klas nie musi być taki obszerny jak diagram przypadków użycia.
Na Twoim miejscu najpierw wydzieliłbym co jest obiektem, a co działaniem.
Przykładowo obiekty z Twojego diagramu to:
Wiele różnych obiektów świadczeń/zabiegów(dziedziczenie), lub jeden obiekt świadczenie/zabiegi konfigurowany - tak możesz to ułożyć na diagramie klas.
Następnie operacje:
To są operacje w klasach czyli metody lub jeszcze inne obiekty, które wykonują operację na danych obiektach.
Na Twoim miejscu najpierw wydzieliłbym jedną część systemu, powiedzmy użytkowników i na niej się skupił. Tylko logowanie i jakieś role użytkownika (czyli kto kim jest i co może).
Następnie dodawał kolejno małe niezależne części systemu. Rozbudowując i poprawiając pozostałe.
// Brakuje mi tutaj jeszcze diagramów czynności. Gdyby były zrobione, to przejście do diagramów klas byłoby znacznie prostsze.
Diagramy czynności to taki diagram przepływu systemu, czyli co konkretnie się dzieje.
Staraj się dzielić diagramy:
Jedna część jeden diagram. Na mniejsze łatwiej się patrzy i ogarnia :)
malencki napisał(a):
Staraj się dzielić diagramy:
Jedna część jeden diagram. Na mniejsze łatwiej się patrzy i ogarnia :)
To znaczy... spróbowałem zrobić coś takiego, nie mam pojęcia, czy to jest dobrze, ale... spróbuję się dostosować dalej do Twoich wskazówek :) (załącznik)
EDIT: Ten załącznik będzie nieco wyraźniejszy :P
EDIT #2: Spróbowałem dostosować się do Twoich wskazówek i udało mi się stworzyć taki diagram klas (załącznik). Czy relacje i sam diagram teraz jest nieco poprawniejszy? Byłbym wdzięczny za pomoc i ewentualne dalsze wskazówki :P
Tak na marginesie - trochę bez sensu rysować diagram bez wiedzy w jaki sposób będzie on wykorzystywany. Jaki jest cel tego ćwiczenia? Co potem się zadzieje z tym diagramem? Będzie jakaś implementacja czy zaliczenie i do kosza?
malencki napisał(a):
Na Twoim miejscu najpierw wydzieliłbym jedną część systemu, powiedzmy użytkowników i na niej się skupił. Tylko logowanie i jakieś role użytkownika (czyli kto kim jest i co może).
Następnie dodawał kolejno małe niezależne części systemu. Rozbudowując i poprawiając pozostałe.
Nie wiem, czy dobrze zrozumiałem, masz na myśli, żeby wydzielić diagram na coś takiego mniej więcej? Jako... aplikację, składającą się z kilku diagramów (podsystemów), komunikujących się ze sobą? Bo właściwie jeśli chodzi o użytkowników, to... masz na myśli rozumiem większą ilość przypadków? Przykład w załączniku :P
Normalnie diagram klas tak jak robiłeś.
Miałem na myśli podział logiczny.
Na jednym diagramie umieszczasz samych użytkowników. W tym momencie bez żadnego łączenia z pozostałą częścią systemu.
Czyli klasę użytkownik oraz jego pola, jakieś metody typu zaloguj/wyloguj w tej klasie.
Do tego diagramu dodajesz kolejne klasy z użytkownikami typu Administrator, Patent i jeśli są w jakiś sposób połączone ze sobą to łączysz je. Jeśli nie są połączone to nie łączysz ich.
Potem kolejny niezależny diagram Zabiegi i tak samo postępujesz jak opisałem wyżej.
Następnie świadczenia, potem wnioski, itd ...
Wszystko co zawiera jakieś dane które musi przechowywać, aby spełniało swoje funkcje, porządkujesz w klasy.
Oczywiście dzielisz to tematycznie, aby nie robić burdelu, na całkowicie osobnych diagramach.
Potem jak ogarniesz jakie masz klasy z danymi możesz powoli łączyć wszystko do kupy, czyli jak ma działać.
Robisz wiele różnych diagramów, aby pokazać na nich jak współdziałają ze sobą klasy, aby wykonać konkretny przypadek użycia.
Możesz modyfikować istniejące diagramy, jak i zbudować od nowa.
Prawdopodobnie nie musisz wykonywać wszystkich przypadków użycia (przypadek użycia -> diagram klasowy), tylko skupiasz się na tych najważniejszych.
Na takich diagramach zawierasz tylko te klasy, które biorą udział w przypadku użycia.
Miej dużo naiwności w tym co robisz, nie wszystko musi być w 100% przemyślane, takie rzeczy zazwyczaj wychodzą przy implementacji.
Wiesz też nie jestem jakimś tam ekspertem w tej dziedzinie. Miałem zwyczajnie (nie)przyjemność pracować w takim systemie przez pewien czas.
To miałem na myśli :D
malencki napisał(a):
Normalnie diagram klas tak jak robiłeś.
Miałem na myśli podział logiczny.
Zastosowałem się do Twoich wskazówek i wyszedł obecnie taki diagram. Jedynie czego tam brakuje to metod i atrybutów, a czy sam model jest w porządku? Podzieliłem go na aplikację serwera i aplikację klienta. Nie mam też pewności, czy wszystkie relacje są poprawne :P (załącznik)
Przykład diagramu biblioteki:
diagram biblioteka
Jak widać na tamtym diagramie masz 2 części (na nim już połączone).
Chodziło mi o taki podział, że umieszczasz (1) oraz (2) na całkowicie osobnym diagramie, z wypełnionymi polami.
Nic na siłę nie łączysz.
Jak masz utworzone takie diagramy klas, czyli wiesz jakie obiekty (w tej chwili dane), będziesz przetwarzał to możesz powoli wykonywać przypadki użycia.
Kilka sztuk, łącząc je tak jak to robiłeś na diagramie z pierwszego postu.
Podstawową rzeczą jest to, aby określić z jakimi danymi oraz klasami będziesz miał do czynienia, wtedy będzie dużo prościej.
I to tyle.
malencki napisał(a):
Przykład diagramu biblioteki:
diagram bibliotekaJak widać na tamtym diagramie masz 2 części (na nim już połączone).
- Author, Account, Librarian, Patron
- Book, Book Item, Library, Catalog
Chodziło mi o taki podział, że umieszczasz (1) oraz (2) na całkowicie osobnym diagramie, z wypełnionymi polami.
Nic na siłę nie łączysz.
Jak masz utworzone takie diagramy klas, czyli wiesz jakie obiekty (w tej chwili dane), będziesz przetwarzał to możesz powoli wykonywać przypadki użycia.
Kilka sztuk, łącząc je tak jak to robiłeś na diagramie z pierwszego postu.Podstawową rzeczą jest to, aby określić z jakimi danymi oraz klasami będziesz miał do czynienia, wtedy będzie dużo prościej.
I to tyle.
Dzięki Mistrzu za pomoc i wskazówki, trochę przemodelowałem ten diagram, teraz wygląda tak jak w załączniku. Pozwól, że trochę odbiegnę od tematu. Otóż, mam jedno kluczowe pytanie do Ciebie, czy mogę Ciebie poprosić o ocenę, co w tym diagramie, w pakiecie "Baza danych" (prawy górny róg), jest modelowane: czy... struktura bazy, czy klasy używane w programie, które są mapowane na encje? :P
