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

Jak najlepiej według Was zamodelować na diagramie klas przedstawione poniżej fakty:
1. Jedna osoba może posiadać wiele adresów
2. Jeden adres może być przypisany do jednej osoby
3. Każdy adres ma jeden określony typ
4. Jedna osoba może posiadać jeden adres danego typu

jak rozumieć pkt. 3.?

w każdym razie:
- adres to ValueObject (poczytaj wzorce DDD)
- adres jest kompozycją skojarzony z osobąJarek Żeliński edytował(a) ten post dnia 04.03.12 o godzinie 20:34

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

skąd ten drugi warunek? jest "nienaturalny"...

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

Mateusz Zakrzewski:

Jarek Żeliński:
skąd ten drugi warunek? jest "nienaturalny"...

Nie mogę zdecydowanie zaprzeczyć, ani też zdecydowanie poprzeć tego stwierdzenia. Aczkolwiek, czy możemy założyć na potrzeby tej dyskusji, że taki jest (abstrachując od jego "naturalności") i jedyne co możemy z tym faktem zrobić, to go zamodelować ? :)

sugeruje modelować stan możliwy (kilku ludzi pod jednym adresem) i ograniczenie wbić w logike (np. zmienny parametr).

tak więc jak opisałem: klasa osoba i adres jako ValueObject

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

chodzi o to:
http://domaindrivendesign.org/node/135

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

na początek rzuć okiem na to:
http://it-consulting.pl/autoinstalator/wordpress/2012/...

i na hasło "anemiczny model dziedziny" tu:
http://pl.wikipedia.org/wiki/Antywzorzec_projektowy

na razie to troszkę pomieszanie relacyjnej bazy z obiektowym modelem ...

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

Radosław Zadroga:
Możliwe że słabo znam urząd miasta i obiekty które w nim sie znajdują, takie jest moje "odczucie" - poznanie tej organizacji. Czyli rozumiem że powinienem jednak lepiej zrozumieć organizację i pomimo że to pracownik urzędu wykonuje te operacje to tak na prawdę on tylko steruje a to obiekty umożliwiają dodanie danych, Zameldowanie - zamelduj, wymelduj?

rzecz w tym, że system to nie urzędnik tylko narzędzie pracy
ale kilka pytań:
- dane rodowe zawierają dane osobowe?
- jak rozumieć dziedziczenie kierownika po urzędniku?
- jak rozumieć, ze dane kontaktowe zawierają referat?

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

Radosław Zadroga:

- dane rodowe zawierają dane osobowe?

Dane rodowe zawierają dane osobowe rodzica, dziecka.

a mogę mieć ich wiele rożnych i "odłączanych"

- jak rozumieć dziedziczenie kierownika po urzędniku?

Kierownik ma te same operacje i atrybuty co urzędnik ale ma jeszcze swoje operacje, których jeszcze nie podałem, lub z braku ich usunę kierownika.

czym jest obiekt kierownik w oprogramowaniu?

- jak rozumieć, ze dane kontaktowe zawierają referat?

Lokal jest zawierany, referat ZP to katalog w którym znajduje się klasa w programie do modelowania.

nie rozumiem, Lokal ma adres, referatów może tam być wiele ale to wiele referatów mających "taki sam"adres jeżeli wynajmę mieszkanie kilku studentom to będą to "studenci, każdy z osobna" a to, że akurat dziś maja ten sam adres nie zmienia niczego "w nich", jutro mogą mieszkać gdzie indziej,

to dlatego napisałem, że diagram jest "bliski bazie danych" a nie dzidzinie

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

Radosław Zadroga:
jeden obiekt danych rodowych mam rozumieć jako dane ojca,
drugi obiekt jako dane matki,
trzeci dane jednego dziecka,
itd ?

dlaczego nie obiekt "osoba" z informacją o rodzicach?

czym jest obiekt kierownik w oprogramowaniu?

obiektem który ma te same operacje co urzędnik i dodatkowo własne

jakie operacje ma urzędnik?

kierownik nie jest potomkiem urzędnika i dlatego nie powinno być dziedziczenia?

potomkiem urzędnika jest jego dziecko :)

czy w związku z tym, zarządzaniem ma zajmować się Zarządca
spraw obywatelskich i od niego wtedy mogliby dziedziczyć urzędnik i kierownik?

tu chyba doszło do nieporozumienia, Lokal ma adres ale z adresu nie zrobiłem obiektu(może powinienem), nie chodzi o to że referat ma adres, tylko o to że Dane zameldowania zawierają Adres, Dane kontaktowe zawierają Adres.

proponuję wzorzec ValueObject na adres

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

Radosław Zadroga:

Jarek Żeliński:

Radosław Zadroga:
jeden obiekt danych rodowych mam rozumieć jako dane ojca,
drugi obiekt jako dane matki,
trzeci dane jednego dziecka,
itd ?

dlaczego nie obiekt "osoba" z informacją o rodzicach?

muszę Kogoś zacytować ;)

Nie tworzymy więc klasy Produkt, bo produktem tym jest krzesło, które jest i będzie realnym krzesłem. Tworzymy klasę Dane produktu, bo tak na prawdę obiekt realizuje (zastępuje w aplikacji) papierową kartę, dane konkretnego produktu.

źródło: http://it-consulting.pl/autoinstalator/wordpress/2012/...

:) pisząc tu o klasie "osoba" trzymałem ducha projektu :) ... inaczej musiałbym wywrócić go od razu do góry nogami :)

jakie operacje ma urzędnik?

sprawdź dane,
Jednak poprzedni diagram wrzucam do "kosza".




Czy stworzenie tak wygladającego obiektu Kartoteka osobowa nie jest kolejnym błędem projektowania?

przede wszystkim należy się w projekcie trzymać jednej konwencji, umieszczanie aktora na modelu dziedziny jest "wprowadzaniem" bytów z poza modelu (użytkownik systemu nie jest elementem dziedziny tego systemu bo jest poza nim), każdy projekt prowadzący do działającego kodu jest "dobrym projektem", jednak projektów nie ocenia się tylko w kategoriach "zadziałało" ale także w kategoriach, zrozumiałości, kosztu utrzymania, i innych... jak wiemy nie muszą być nawet obiektowe... rzecz w tym by trzymać się konsekwentnie jakieś konwencji... magazyn formularzy w konwencji DDD nie tworzy ich a dostaje na przechowanie, czy może je tworzyć? owszem ale to "inna konwencja". Dalej, czy aktor (zewnętrzny użytkownik) ma mieć możliwość wywołania bezpośrednio klasy dziedzinowej Magazyn_formularzy? Jak?

więc w pewnym sensie ten diagram także jest błędny... tak na prawdę nie rozumiem kto czym i w jakim celu tu zarządza....