 Strona główna forum UML
Diagram klas - oceńcie | Zarejestruj się by pisać |
| Wcięte | Najpierw najnowsze | Poprzedni temat | Następny temat | Koniec |
| Postujący | Wątek |
|---|---|
| bryniu | wysłane dnia: 2007/7/7 0:51 |
Nowicjusz  Dołączył: 2007/7/3 z: Posty: 7 |
Diagram klas - oceńcie Witam!
Jestem nowicjuszem, gdy chodzi o diagram klas, a taki mam zamodelować względem stworzonego przez siebie serwisu do obsługi komisu samochodowego/sieci komisów (PHP, MySQL). Czytam w różnych źródłach - diagram klas przedstawia strukturę systemu w perspektywie obiektowej (szczególnie gdy mamy doczynienia z bazą danych) , a często nawet służy do modelowania klas implementowanych w konkretnym obiektowym języku programowania. Serwis zrobiłem nie korzystając z OOP (niestety) więc wersja z klasami do implementacji raczej odpada, szczególnie że dostałem wytyczne:"diagram klas warstwy biznesowej". I teraz przedstawię może opis systemu i link do aktualnego diagramu klas, który chciałbym żebyście ocenili, podpowiedzieli czy w dobrą stronę idę, sugestie. Opis sytemu: system obsługuje komis samochodowy/sieć komisów; użytkownicy: Potencjalny klient (internauta), Administratorzy(Kierownik/Pracownik komisu); Potencjalny klient może jedynie przeglądać ofertę, wysyłać maile na konto pocztowe danego komisu, zapoznawać się z danymi kontaktowymi komisu i jego działalnością; Administrator może wszystko to co Potencjalny klient + zarządzanie ofertą (pojazdami i tym co z nimi związane) swojego komisu, klientami, dokumentami, edytuje swój profil, tylko Kierownik komisu może zmieniać ustawienia kont adminów. Klienci są rejestrowani w systemie w roli sprzedawcy/nabywcy (komis też może pełnić taką rolę, a dokładnie Kierownik komisu) - dokumenty określają rolę klienta. Dokumenty zawierają informacje o pojeździe oraz sprzedawcy/nabywcy i autorze/modyfikatorze (Administrator) dokumentu. Administrator może edytować dane komisu. Tylko Kierownik może edytować ustawienia strony WWW komisu. http://picasaweb.google.com/bryniu1/KomisSamochodowySiecKomisow/photo#5084215874996642242 |
| Jacek | wysłane dnia: 2007/7/22 11:18 |
Nie może przestać Dołączył: 2005/12/27 z: Gliwice Posty: 91 |
Re: Diagram klas - oceńcie Witaj,
mam pytanie, do czego wykorzystasz klasę potencjalny klient? Jeżeli chcesz wiedzieć, co aplikacja ma robić zacznij od diagramu przypadków użycia. Wypisz wszystkie kluczowe funkcjonalności systemu. Myślę, że profil klienta może być reprezentowany przez klasę Klient. Jako sam byt profil klienta nie ma za bardzo sensu. Czy klient zapoznaje się z pojazdami w komisie, czy z samym komisem? Na razie to tyle. Może inni użytkownicy coś jeszcze zauważą.
|
| bryniu | wysłane dnia: 2007/7/24 13:07 |
Nowicjusz Dołączył: 2007/7/3 z: Posty: 7 |
Re: Diagram klas - oceńcie Klasa Potencjalny klient ma obrazować tylko, że Internauta może być właśnie potencjalnym klientem zainteresowanym oglądaną ofertą, a Admninistrator ma dostęp do systemu również z zewnątrz i może wykonywać wszelkie operacje Internauty.
Mam diagram przypadków użycia i z niego korzystałem przy tworzeniu diagramu klas. Co do Profilu to chodziło o edycje profilu administratora - rzeczywiście ta klasa jest niepotrzebna bo mieści sie w klasie Administrator. Dane klienta, który bezpośrednio fatyguje sie do komisu, są rejestrowane przez dany komis. Internauta natomiast ma możliwość przeglądania oferty firmy oraz zapoznawania się z jej działalnością i danymi kontaktowymi, a także wysyłania do konkretnego komisu wiadomości. A tutaj trochę zmieniony już diagram klas opisujący mój system: http://picasaweb.google.com/bryniu1/KomisSamochodowySiecKomisow/photo#5090712858739047890 |
| Jacek | wysłane dnia: 2007/7/27 8:57 |
Nie może przestać Dołączył: 2005/12/27 z: Gliwice Posty: 91 |
Re: Diagram klas - oceńcie Witaj,
skoro internauta może być potencjalnym klientem, to nadal nie widzę potrzeby tworzenia osobnej klasy. Zarówno od potencjalnego klienta, jak i internauty nie pobierasz danych. Jest to dublowanie klas, a tak naprawdę można w słowniku pojęć napisać Internauta alias: Potencjalny klient. Ta ostatnia klasa nie wnosi nic nowego do klasy Internauta. Tu się trochę poczepiam - klasa administrator mogłaby się w rzeczywistości nazywać użytkownik (klient nie pracuje na systemie). Myślę, że fajnie by było, gdybyś zamieścił diagram przypadków użycia - tak dla sprawdzenia idei systemu. Pozostałe klasy moim skromnym zdaniem reprezentują się naprawdę coraz lepiej.
|
| bryniu | wysłane dnia: 2007/7/31 21:13 |
Nowicjusz Dołączył: 2007/7/3 z: Posty: 7 |
Re: Diagram klas - oceńcie DPU:
http://picasaweb.google.com/bryniu1/KomisSamochodowySiecKomisow/photo#5093434996126350818 Z klasą Potencjalny klient chodziło mi o to, że klasa Internauta to klasa abstrakcyjna, więc (jak czytałem) obiekt klasy abstrakcyjnej jest jednocześnie wcieleniem/obiektem klasy podrzędnej (czyli w tym wypadku klasy Admnistrator lub Potencjalny klient), także chciałem tu unaocznić, że internautą może być pot. klient lub administrator (zdalny dostęp do systemu i mozliwość wykonania tych samych działań co pot. klient). Czytałem, że specjalizację (wyspecjalizowane klasy) wyznacza się na podstawie różnych wartości konkretnego argumentu - jak np. atrybut "uprawnienia" rozróżnia administratora na kierownika i pracownika komisu. A w przypadku internauty nie widzę takiego atrybutu... Chyba rzeczywiście o jedną klasę za dużo, tak więc kolejna wersja diagramu klas przedstawia się następująco: http://picasaweb.google.com/bryniu1/KomisSamochodowySiecKomisow/photo#5093440115727367666 Co do nazwy klasy administrator to nazwa ta wyraźnie raczej mówi, iż do panelu administracyjnego nie ma dostępu klient. |
| Jacek | wysłane dnia: 2007/8/3 7:58 |
Nie może przestać Dołączył: 2005/12/27 z: Gliwice Posty: 91 |
Re: Diagram klas - oceńcie Witam,
Teraz już lepiej. Klasy abstrakcyjne zaznacza się na diagramach poprzez fakt, iż ich nazwa jest pisana czcionką pochyłą. Ale diagram jest ok.
|
| Wcięte | Najpierw najnowsze | Poprzedni temat | Następny temat | Top |
| Zarejestruj się by pisać | |