Temat: Diagram E/R w UML?

Ja proponuje rozdzielić wątek i z mojej strony:
- UML to nie ERD, mylenie tego świadczy nie zrozumieniu tego czym te notacje są i czym jest notacja jako taka (a jest językiem)
- figur geometrycznych można używać dowolnych do czegokolwiek, jakość tego procesu jest mierzona efektami...

na dobrą sprawę można zamiast worda użyć eclipse i odwrotnie, w sumie każdy jest panem swojego losu... i nikt nie ma prawo tego nikomu zakazać, żyjemy w wolnym kraju.

Po tej dyskusji, każdy tu wyjdzie z nowym doświadczeniem :)

ale jedno jest pewne:
ERD powstał do modelowania danych
UML powstał do modelowania systemów zorientowanych obiektowo

to jak i do czego każdy z nas tego używa to jego sprawa... podobnie jak efekty. Ostatnią tu rzeczą dla mnie jest zakazywanie komukolwiek czegokolwiek...

Temat: Diagram E/R w UML?

Do Jakuba:

Widzę, że nie jarzysz.

Chodziło mi o to, że dokumentację i kod systemu tworzysz nie dla komputera, ale dla osób, które będą ten system później utrzymywały, pielęgnowały czy modyfikowały. Im więcej więc użyjesz rozwiązań niestandardowych (nie ważne, czy w kodzie, czy w dokumentacji), tym te późniejsze działania będą trudniejsze (bo niestandardowe), a więc kosztowniejsze.
Więc to, że coś Ci działa, nie znaczy wcale, że system jest dobry, bo np. z powodu dużej ilości śrubek wbitych młotkiem będzie trudno serwisowalny (a weź potem to wykręć). Chyba, że jesteś fanem metodologii ZZZ (zaprogramować, zainkasować, zapomnieć) - ale wtedy cała ta dyskusja nie ma żadnego sensu.

Jakość systemu określana jest nie tylko tym, jak dobrze ten system działa i na ile spełnia założenia, ale również tym, jak łatwo jest go potem utrzymywać i rozbudowywać.

Po to właśnie są standardy - bo procesorom w kompach czy serwerach one są na plaster (wręcz często dają im więcej pracy).Piotr Głudkowski edytował(a) ten post dnia 28.10.11 o godzinie 13:20

Temat: Diagram E/R w UML?

jako osoba z gatunku "ja analizuje i piszę wymagania" mam zwyczaj żądania od oferentów następujących składników kosztu:
- koszt uruchomienia (czyli koszt wymagany by ludzie zaczęli pracować)
- średnioroczny koszt utrzymania za okres trzech lat minimum,
- kosztu wprowadzenia nowej funkcjonalności do systemu już po jego oddaniu do użytku

od razu wyjaśniam trzecia pozycję bo nie raz budzi straszne emocje: skoro firma potrafi złożyć ofertę (np. w przetargu) na pierwsze pięćdziesiąt funkcjonalności to nie ma problemu by podała cenę jednej kolejnej. Jak ktoś nie potrafi to znaczy, że ściemnia... (a potrafią to jednak zrobić po roku od podpisania umowy jak padnie takie pytanie!).

Czemu o tym piszę? Bo od kilku lat obserwuję, że oferty firm mających "swoje metody" a nie standardy są ok. dwa a nawet trzykrotnie droższe od tych bazujących na uznanych metodach i frameworkach i wylatują jak z procy z tych postępować...

Ostatnio pewien Pan programista, próbował mnie przekonać, że ta cała java i .net to g....no, on już 20 lat pisze w Pascalu (Delphi) super systemy i nie używa żadnych juemeli więc po co kombinować, problem w tym, że jego oferta (jego firma) była najdroższa... z czym nie potrafił się pogodzić...Jarek Żeliński edytował(a) ten post dnia 28.10.11 o godzinie 13:34

Temat: Diagram E/R w UML?

Jakub Wojt:
...
Dobra, sam sobie odpowiem: diagram E/R pozwala na zaznaczenie klucza głównego.

klucza obcego i widoku :)

Na diagramie klas nie można wyrazić pewnych informacji jakie można wyrazić na E/R.

Diagram klas jest obiektowym opisem problemu, bazy danych są relacyjne --- dwa kompletnie różne modele opisów rzeczywistości.

...
Ja odpowiadam na pytanie "Czy informacje z E/R można (i jakie to ma zalety) wyrażać diagramami UML".

kluczy głównych, kluczy obcych i widoków UML nie da rady. Zalet brak --- MySQL ma darmowe narzędzie CASE do projektowania baz danych.

Dobrze wiem, co "w książkach stoi".
Po prostu uważam, że pewne rzeczy można robić lepiej.
... Pewnie nie podoba to się ludziom którzy wiedzą i robią wszystko i najlepiej

"lepiej" jest pojęciem względnym. Jakość, jeśli jest sparametryzowana bezwzględnym. Dobrej jakości projekt powinien być jednoznaczny (UML zamiast ERD tego nie zapewnia).

Temat: Diagram E/R w UML?

Ostatnio pewien Pan programista, próbował mnie przekonać, że ta cała java i .net to g....no,

Tu akurat miał rację :)
Co nie zmienia faktu, że stały się standardami i już.

Taka mała dygresja.

Temat: Diagram E/R w UML?

Piotr Głudkowski:

Ostatnio pewien Pan programista, próbował mnie przekonać, że ta cała java i .net to g....no,

Tu akurat miał rację :)
Co nie zmienia faktu, że stały się standardami i już.

Taka mała dygresja.

tylko, że mnie interesuje wyłącznie koszt per use case :))

Temat: Diagram E/R w UML?

Jarek Żeliński:

Piotr Głudkowski:

Ostatnio pewien Pan programista, próbował mnie przekonać, że ta cała java i .net to g....no,

Tu akurat miał rację :)
Co nie zmienia faktu, że stały się standardami i już.

Taka mała dygresja.

tylko, że mnie interesuje wyłącznie koszt per use case :))

I słusznie.
Dlatego pisze się w tym, co jest standardem, a nie w tym, w czym się lubi (ja lubię C, a kiedyś lubiłem Fortran, a piszę w C# i, ostatnio, w PHP).

Temat: Diagram E/R w UML?

Jarek Żeliński:
od razu wyjaśniam trzecia pozycję bo nie raz budzi straszne emocje: skoro firma potrafi złożyć ofertę (np. w przetargu) na pierwsze pięćdziesiąt funkcjonalności to nie ma problemu by podała cenę jednej kolejnej. Jak ktoś nie potrafi to znaczy, że ściemnia... (a potrafią to jednak zrobić po roku od podpisania umowy jak padnie takie pytanie!).

A ja nie potrafię, bo nie wiem jaka to będzie funkcjonalność. Potrafię oszacować co do kosztu per use-case (z podziałem na prosty, typowy i złożony) pod warunkiem nienaruszania dotychczasowej architektury systemu.
Ale fakt faktem - jak ktoś nie ma nic do powiedzenia na temat kosztów rozbudowy to ściemnia - oznacza to tyle, że nie potrafi wymiarować pracy i że podejmując się kontraktu zachowywał się jak w kasynie - uda się albo nie uda.Mateusz Kurleto edytował(a) ten post dnia 28.10.11 o godzinie 14:05

Temat: Diagram E/R w UML?

Mateusz Kurleto:

Jarek Żeliński:
od razu wyjaśniam trzecia pozycję bo nie raz budzi straszne emocje: skoro firma potrafi złożyć ofertę (np. w przetargu) na pierwsze pięćdziesiąt funkcjonalności to nie ma problemu by podała cenę jednej kolejnej. Jak ktoś nie potrafi to znaczy, że ściemnia... (a potrafią to jednak zrobić po roku od podpisania umowy jak padnie takie pytanie!).

A ja nie potrafię, bo nie wiem jaka to będzie funkcjonalność. Potrafię oszacować co do kosztu per use-case (z podziałem na prosty, typowy i złożony) pod warunkiem nienaruszania dotychczasowej architektury systemu.

czyli potrafisz :)

Ale fakt faktem - jak ktoś nie ma nic do powiedzenia na temat kosztów rozbudowy to ściemnia - oznacza to tyle, że nie potrafi wymiarować pracy i że podejmując się kontraktu zachowywał się jak w kasynie - uda się albo nie uda.

bingo :)

Temat: Diagram E/R w UML?

O, cztery plusy - muszę odpowiedzieć ;)

Chodziło mi o to, że dokumentację i kod systemu tworzysz nie dla komputera, ale dla osób, które będą ten system później utrzymywały, pielęgnowały czy modyfikowały.

yhm.
i dla sądu.

Im więcej więc
użyjesz rozwiązań niestandardowych (nie ważne, czy w kodzie, czy w dokumentacji), tym te późniejsze działania będą trudniejsze (bo niestandardowe), a więc kosztowniejsze.

To się zgadza. Trzeba jednak dodać, że to samo dotyczy stosowania wielu różnych standardów; Im mniej standardów tym lepiej. Jeśli można jakiś standard wyeliminować z procesu produkcji to trzeba to zrobić.

Korzystając z prawa do mylenia się, stwierdzam, że E/R nie ma praktycznych przewag nad diagramem klas. Przynajmniej w zakresie projektowania architektury aplikacji 'po mojemu'.

Argument (?) 'E/R to standard i właśnie dlatego tak to trzeba robić' do mnie nie trafia, ponieważ uważam, że standardy są po to, żeby usprawniać pracę a nie po to, żeby "było standardowo"'.

Ja też, póki co, oddaje przełożonemu / klientowi jakiś diagram E/R kiedy ten sobie życzy dokumentacji "modelu danych". Napiszę to jeszcze raz: po prostu zastanawiam się, czy można to (przekazywać informacje) zrobić 'lepiej' (bez zbędnych standardów).

Czy zdanie 'E/R jest najlepsze' jest święte i niepodważalne ?
Podważanie tego na prawdę nie spowoduje gradobicia ...

Więc to, że coś Ci działa, nie znaczy wcale, że system jest dobry, bo np. z powodu dużej ilości śrubek wbitych młotkiem będzie trudno serwisowalny (a weź potem to wykręć).

Pisząc 'działa' miałem na myśli wszystkie wymagania systemu.

Chyba, że jesteś fanem metodologii ZZZ (zaprogramować, zainkasować, zapomnieć) - ale wtedy cała ta dyskusja nie ma żadnego sensu.

wtedy bym jej w ogóle nie rozpoczynał :)

Temat: Diagram E/R w UML?

Ja odpowiadam na pytanie "Czy informacje z E/R można (i jakie to ma zalety) wyrażać diagramami UML".

kluczy głównych, kluczy obcych i widoków UML nie da rady.

Najprawdopodobniej 'widok' nie jest częścią "Semantic data model"...
Podobnie z kluczami - to techniczna realizacja 'relacji'.

A z kluczami głównymi jest ciekawa sprawa - diagramy E/R pozwalają na ich ustalenie.

Ile razy spotkałeś się z bazami w których tabele miały klucze główne założone na 'stringach', albo na kilku różnych kolumnach (E/R pozwala na zakładanie klucza głównego na kilku kolumnach) ?

Czyli z techniczne punktu widzenia PK na E/R są bezużyteczne.
Jeśli mają przekazywać 'wiedzę o domenie' - są redundantne bo te informacje są już wyrażone w jakimś innym dokumencie.

Chyba ...

Zalet brak

Ja parę wypiszę :)
- nie trzeba znać E/R
- dobrze zrobiony diagram klas domeny (przykłady mogę podać) będzie zawierać 99% informacji jakie wyraża E/R (nie trzeba robić E/R i nie redundancji dokumentacji)

Dobrej jakości projekt powinien być jednoznaczny (UML zamiast ERD tego nie zapewnia).

Proszę o diagramy które to ilustrują :)Jakub Wojt edytował(a) ten post dnia 29.10.11 o godzinie 16:43

Temat: Diagram E/R w UML?

Argument (?) 'E/R to standard i właśnie dlatego tak to trzeba robić' do mnie nie trafia, ponieważ uważam, że standardy są po to, żeby usprawniać pracę a nie po to, żeby "było standardowo"'.

języki standardowe to jakość komunikacji, są specjalizowane do czegoś. Na tej samej zasadzie można dowolny program napisać w języku maszynowym jednak z jakiegoś powodu powstały macroasembler z jednej strony i PHP z drugiej, także Java czy C#...

Temat: Diagram E/R w UML?

- dobrze zrobiony diagram klas domeny (przykłady mogę podać) będzie zawierać 99% informacji jakie wyraża E/R (nie trzeba robić E/R i nie redundancji dokumentacji)

problem w tym, że taki diagram klas będzie klasycznym przykładem antywzorca "anemiczny model dziedziny"..

Temat: Diagram E/R w UML?

Zgadzam się. Właśnie dlatego napisałem 'jeśli ktoś robi model danych to prędzej czy później będzie musiał zrobić model domeny'.

nie będzie musiał bo:
- jak zrobi model danych to może potem tylko dopisać do tego kawał kodu np. w Pascalu i model dziedziny mu na plaster

Skąd ten programista wie, jaki będzie model danych (encje, atrybuty, ograniczenia) jeśli wcześniej nie zrobił sobie analizy tego, co i jak aplikacja ma robić ?

Model danych ma zapewnić możliwość realizacji wymaganej funkcjonalności, czy na odwrót ?

dodam na koniec: jako audytor wywalam bez skrupułów do kosza modele danych w UML... jak ktoś tego nie rozumie to ... akapit o zmianie zawodu.

Pozostaje mieć nadzieję, że takie postępowanie rzeczywiście ułatwia pracę wykonawcom.

Temat: Diagram E/R w UML?

Jakub Wojt:

nie będzie musiał bo:
- jak zrobi model danych to może potem tylko dopisać do tego kawał kodu np. w Pascalu i model dziedziny mu na plaster

Skąd ten programista wie, jaki będzie model danych (encje, atrybuty, ograniczenia) jeśli wcześniej nie zrobił sobie analizy tego, co i jak aplikacja ma robić ?

nie rozumiem pytania, napisano: "jak zrobi model danych to może potem tylko dopisać do tego kawał kodu"

Model danych ma zapewnić możliwość realizacji wymaganej funkcjonalności, czy na odwrót ?

wydaje się proste: "Model danych ma zapewnić możliwość realizacji wymaganej funkcjonalności"

dodam na koniec: jako audytor wywalam bez skrupułów do kosza modele danych w UML... jak ktoś tego nie rozumie to ... akapit o zmianie zawodu.

Pozostaje mieć nadzieję, że takie postępowanie rzeczywiście ułatwia pracę wykonawcom.

zapewniam, ze bardzo w szczególności, że wraz z modelem danych w UML "do kosza" leci taki wykonawca...

Temat: Diagram E/R w UML?

Jakub Wojt:
Najprawdopodobniej 'widok' nie jest częścią "Semantic data model"...
Podobnie z kluczami - to techniczna realizacja 'relacji'.

A z kluczami głównymi jest ciekawa sprawa - diagramy E/R pozwalają na ich ustalenie.

Ile razy spotkałeś się z bazami w których tabele miały klucze główne założone na 'stringach', albo na kilku różnych kolumnach (E/R pozwala na zakładanie klucza głównego na kilku kolumnach) ?

Witam,
Tutaj pozwolę sobie nie zgodzić się z Jakubem. Bardzo często spotykam bazy danych, w których klucz główny jest oparty na stringu, czy np. dacie - są to klucze naturalne. Klucz główny oparty na wielu kolumnach również nie jest zjawiskiem egzotycznym.

Połączenie klucz główny-klucz obcy jest podstawową informacją zawartą w diagramie bazy danych i nie wyobrażam sobie pominięcia jej w jakikolwiek sposób.

Podobnie jak wielu moich przedmówców, uważam że UML nie nadaje się do wyrażania relacji - po prostu został zaprojektowany do czego innego.

Pozdrawiam,
Kamil.

Temat: Diagram E/R w UML?

Zdaje się, że UML został zaprojektowany tak, by możliwe było rozszerzanie notacji (mam na myśli profile UML) i niektórzy to wykorzystują do modelowania danych (http://www.agiledata.org/essays/umlDataModelingProfile...

Technicznie jest więc to wykonalne, jednak nie jest to standard. Ot, ciekawostka ;)

Temat: Diagram E/R w UML?

Paweł Grzegorz Kwiatkowski:
Zdaje się, że UML został zaprojektowany tak, by możliwe było rozszerzanie notacji (mam na myśli profile UML) i niektórzy to wykorzystują do modelowania danych (http://www.agiledata.org/essays/umlDataModelingProfile...

Technicznie jest więc to wykonalne, jednak nie jest to standard. Ot, ciekawostka ;)

rozszerzenia buduje się poprzez stereotypy, pojęcie profilu to dodanie do systemu klasyfikatorów (klas) dodatkowego aparatu pojęciowego ale profil taki nie zmienia obiektowego paradygmatu całej notacji UML, po protu problem w tym, że aparat matematyczny rachunku relacji w systemie relacyjnego opisu danych i paradygmat obiektowy to dwa światy, niestety stale trafiają się chętnie na modelowanie danych w UML...

można co najwyżej mówić o podobieństwie modelu klas do modelu konceptualnego danych ale z pewnymi jednak różnicami (ograniczeniami), podstawowe wybrane różnice to:
- relacyjny model danych ER nie dopuszcza relacji wiele-do-wiele (musi być rozwiązywane dodatkową encją "w środku", w modelu (paradygmacie) obiektowym nie istnieje takie ograniczenie
- obiekty (model obiektowy) mogą być logicznie kojarzone z pomocą odwołania do wartości atrybutów, w modelu relacyjnym skojarzenia to są trwałe asocjacje (relacje), nie zmieniane (związek dwóch klas nie musi oznaczać ich trwałego skojarzenia asocjacją obiekt jest aktywny i może sam "poszuka" skojarzonej logicznie klasy, krotki w RDBMS to martwe zapisy)

to tylko jakieś tam różnice a jest ich więcej, niestety traktowanie klasy jako kontenera na kawałek kodu prowadzi do herezji...

Przytoczona strona Amblera, w moich oczach to kulawe atrapy rodem z EJB (POJO i binsy)... mało to ma wspólnego z UML i obiektowością, a profil ma poważne wady (stereotyp sam jest klasa, definicja profilu to także rodzaj diagramu klas rozszerzającego taksonomię notacji, tak więc profil bez spójnego metamodelu jest niereyfikowalny). Samo naklepanie stereotypów nie oznacza, że stworzyliśmy profil dla UML.Jarek Żeliński edytował(a) ten post dnia 31.10.11 o godzinie 15:30

Temat: Diagram E/R w UML?

Ok. Mój ostatni post w tym temacie. Nie będę walczyć z wiatrakami.

Jeśli ktoś robi model obiektowy funkcjonalności to powinien dostarczyć mi kompletny model obiektowy. W UML są wszystkie potrzebne rodzaje relacji. Jeśli ktoś nie potrafi zrobić modelu obiektowego w UML i posiłkuje się 'modelem danych' to niech się podszkoli albo znajdzie sobie inne zajęcie.

Jeśli ma być - obiektowo to nich będzie obiektowo ale od początku do końca. Jeśli ma być relacyjnie - niech będzie relacyjnie ale w całości.

'Model danych' sugeruje architektowi sposób przechowywania stanu modelu;
Relacyjna baza danych to jest jedyna metoda przechowywania danych. Są inne: np. bazy obiektowe, xml itd...
Stąd moja prośba - niech analityk nie wchodzi w kompetencje architekta i nie narzuca pewnych technicznych rozwiązań.

nie będzie musiał bo:
- jak zrobi model danych to może potem tylko dopisać do tego kawał kodu np. w Pascalu i model dziedziny mu na plaster

Skąd ten programista wie, jaki będzie model danych (encje, atrybuty, ograniczenia) jeśli wcześniej nie zrobił sobie analizy tego, co i jak aplikacja ma robić ?

nie rozumiem pytania, napisano: "jak zrobi model danych to może potem tylko dopisać do tego kawał kodu"

Model danych ma zapewnić możliwość realizacji wymaganej funkcjonalności, czy na odwrót ?

wydaje się proste: "Model danych ma zapewnić możliwość realizacji wymaganej funkcjonalności"

dodam na koniec: jako audytor wywalam bez skrupułów do kosza modele danych w UML... jak ktoś tego nie rozumie to ... akapit o zmianie zawodu.

Pozostaje mieć nadzieję, że takie postępowanie rzeczywiście ułatwia pracę wykonawcom.

zapewniam, ze bardzo w szczególności, że wraz z modelem danych w UML "do kosza" leci taki wykonawca...

Pisząc "wykonawca" miałem na myśli architektów i programistów systemu którzy wykorzystywali by dokumentację analityka.

Kurcze, to na prawdę ciekawe, że analityk wie lepiej od 'swoich klientów' czego ci naprawdę potrzebują.

Nie mam nic przeciwko otrzymywaniu 'semantycznego diagramu danych' ale w związku z tym, że nie wnosi niczego nowego do 'dobrego' modelu obiektowego (bo oczywiście nikt nie podał żadnej przewagi / przykładu jednego nad drugim) to zamiast go czytać, oglądać odłożę go na półkę bo z związku z tym, że np. dane będę przechowywać w obiektowej bazie danych, do niczego ten diagram nie będzie mi potrzebny.

Temat: Diagram E/R w UML?

Witam,
Tutaj pozwolę sobie nie zgodzić się z Jakubem. Bardzo często spotykam bazy danych, w których klucz główny jest oparty na stringu, czy np. dacie - są to klucze naturalne. Klucz główny oparty na wielu kolumnach również nie jest zjawiskiem egzotycznym.

Ja też wiele rzeczy widziałem. Proszę powiedzieć jaki to ma sens ? "Dodatkowa walidacja wprowadzanych danych" ? "Zabezpieczenie przed rozspójnieniem" ? Przecież to wszystko powinno być w 'programie obiektowym'.

Podobnie jak wielu moich przedmówców, uważam że UML nie nadaje się do wyrażania relacji - po prostu został zaprojektowany do czego innego.

Diagram klas UML nie wyraża niczego innego jak relacje między i organizację danych w klasach...

Czy program który nie przechowuje swoich danych w 'tabelach' (nie ma diagramu E/R) jest programem 'bezsensownym' i jego projekt musi iść do kosza ?