Temat: Asocjacja a atrybut

Swego czasu pisałem, że od strony formalnej asocjacja to atrybut mówiący z którym innym obiektem dany obiekt jest trwale skojarzony.

Diagram klas to narzędzie do modelowania zarówno związków pojęciowych w oderwaniu od tworzenia oprogramowania, jak i elementów projektowanego oprogramowania. Na tym polega siła metod obiektowych: model rzeczywistości można niemalże "wprost" implementować w systemach IT (wymaga to jednak języka programowania w paradygmacie obiektowym).

Ciekawy artykuł, wyjaśniający subtelną różnicę (albo nawet jej brak) pomiędzy modelowaniem związków logicznych z pomocą asocjacji i atrybutów:
http://geertbellekens.wordpress.com/2011/08/10/uml-bes...

Moim zdaniem trzeba jednak bardzo ostrożnie stosować proponowana, przez autora artykułu, regułę:
Stosuj asocjacje dla klas i atrybuty dla typów danych
gdyż w moich oczach rodzi to ryzyko kojarzenia modelu dziedziny (diagram klas) z modelem danych co jest błędną interpretacją tych modeli.

Osobiście wolę "zasadę": asocjacja to zawsze związek logiczny a atrybut to jego implementacja. Dlatego diagramy klas należy opisywać jako implementacyjne czy pojęciowe.

Artykuł gorąco polecam. A tu ilustracja jego treści:

Temat: Asocjacja a atrybut

Arkadiusz Dąbrowski:
Nie wiem,czy dobrze zrozumiałem Twój wywód.
Zakładając, że tak uważam, że:
Skoro diagramy należy opisywać jako implementacyjne lub pojęciowe (z czym się zgadzam, chociaż wcale nie musi to być opis samego diagramu - to może określać pakiet) to gdzie tu ryzyko pomylenia modeli?

Wszędzie tam gdzie decyzja o użyciu np. asocjacji nie jest oczywista zachodzi ryzyko, że jej znaczenie zostanie "źle" odebrane". Dlatego ja zawsze pisze czy dany model jest modelem pojęciowym czy modele dziedziny "dla systemu". Dodam, ze "dla systemu" nie stosuję dziedziczenia a modelu pojęciowym tak.

Tu napisałem dlaczego:
http://it-consulting.pl/autoinstalator/wordpress/index...

Temat: Asocjacja a atrybut

Wojciech Kłujszo:
Moim zdaniem najlepszym funkcjonalnie (nie koniecznie ze względu na racochłonność) jest stosowanie atrybutu wraz asocjacją.

to znaczy, ze dublujesz atrybut....

moim zdaniem model dziedziny bez diagramu sekwencji, który pokazuje "jak klasy załatwiają sprawy" jest zawsze niekompletną informacją. A modelowanie logiki biznesowej asocjacjami to powrót do modelu relacyjnego...

Temat: Asocjacja a atrybut

Mateusz Kurleto:
Osobiście uważam, że na poziomie inżynierii wymagań schodzenie do szczegółowego diagramu sekwencji jest rzadko uzasadnione. Zastosowanie odpowiednich wzorców (jak np. Active Record, Fabryka itp.) jest moim zdaniem zadaniem architekta systemu - nie od parady są to wzorce projektowe a nie analityczne.

wzorce analityczne szczególnie w DDD np. fabryka, kontener, agregat itp..

Dla mnie model dziedziny winien traktowany być "słownikowo" na poziomie biznesowym, nie wchodząc w zakres implementacji i pozostawiając otwarte pole do popisu dla projektanta/architekta w imię zasady "premature optimalization is the root of all evil".

nie chodzi o "dotykanie" implementacji ale też sam słownik pojęć to za mało. Samo "dokument zamówienia" i jego wzór może być mało, znając pozostałe zależności "bytów biznesowych" warto to "zamówienie" rozebrać na kawałki (sekcje dokumentu) i rozważyć czy kawałki te nie są "współużytkowane" w innych "bytach biznesowych".

Faktycznie nie interesuje mnie jak zarządzasz danymi bo to implementacja, ale interesuje mnie to by logika biznesowa nie była w tej implementacji "zbyt uproszczona ani zafałszowana", diagram sekwencji zaś po pierwsze pozwala przetestować czy znam wszystkie potrzebne byty biznesowe a po drugie pokazuje jak one "gadają" bo wołanie metody innej klasy nie koniecznie oznacza asocjację do niej... (a nawet "raczej nie").

Temat: Asocjacja a atrybut

est także inny aspekt: szczegółowy projekt daje prawo autorskie do opisanej logiki biznesowej, zbyt ogólny niestety nie...