🚀 go-pugleaf

Tomecki napisał(a):
> Witam,
> Zaczynam dopiero przygodę z UML i mam pytanie na które nie
> doszukałem się odpowiedzi jasnej. chodzi mi o diagram klas.
> Załóżmy że mam dwie klasy A i B. klasa A zawiera jako atrybut
> obiekt klasy B. I teraz czy powinienem taki obiekt wpisać na listę
> atrybutów klasy A, czy też powiązać je za pomocą agregacji. Cały
> czas myślałem że to drugie. Ale z ciekawości wygenerowałem sobie
> kod w C++ i zamiast mieć obiektu w klasy B w klasie A miałem jedynie
> wskaźnik do niego. A gdy zastosowałem obie te formy miałem i
> wskaźnik i obiekt.
> 
wydaje mi sie, ze to zalezy od notacji. W wielu ksiazkach spotkalem sie
z "polaczonym" zapisem jaki opisujesz. Jest wiec i wskaznik 
(strzaleczka) i znajduje sie dana klasa na liscie atrybutow.

przyklad:

IInterface
{
	void A();
}

abstract class Abs
{
	IInterface i = null;
}
rysunek:

+---------+
|Abs      |
|---------+
|IInteface|---------->[IInteface]
+---------+

Pozdrawiam,
L.

oczywiscie musialem zjesc "i"

+-----------+
|Abs        |
|-----------+
|IInteface i|-------------->[IInterface]
+-----------+

Pozdrawiam,
L.

lll napisał(a):
> wydaje mi sie, ze to zalezy od notacji. W wielu ksiazkach spotkalem sie
> z "polaczonym" zapisem jaki opisujesz. 

To nie jest zaden "polaczony" zapis tylko zupelnie inna sytuacja.

> Jest wiec i wskaznik 
> (strzaleczka) i znajduje sie dana klasa na liscie atrybutow.
> [...]

Ta strzaleczka w Twoim przykladzie nie oznacza asocjacji tylko mowi, ze 
klasa Abs implementuje interfejs IInterface.

Pozdrawiam,
Adam

> To nie jest zaden "polaczony" zapis tylko zupelnie inna sytuacja.
> 
>> Jest wiec i wskaznik (strzaleczka) i znajduje sie dana klasa na liscie 
>> atrybutow.
>> [...]
> 
> Ta strzaleczka w Twoim przykladzie nie oznacza asocjacji tylko mowi, ze 
> klasa Abs implementuje interfejs IInterface.
> 
nie prawda :)
implementuje: - - - - - |>
dziedziczy: ------------|>
agreguje: -------------->

jesli masz ksiazke "head first design patterns", to zobacz
np. na strone 54

pozdr.
L.

> Pozdrawiam,
> Adam

lll@lll.pl wrote:

> 
>> To nie jest zaden "polaczony" zapis tylko zupelnie inna sytuacja.
>> 
>>> Jest wiec i wskaznik (strzaleczka) i znajduje sie dana klasa na liscie
>>> atrybutow.
>>> [...]
>> 
>> Ta strzaleczka w Twoim przykladzie nie oznacza asocjacji tylko mowi, ze
>> klasa Abs implementuje interfejs IInterface.
>> 
> nie prawda :)
> implementuje: - - - - - |>

OK

> dziedziczy: ------------|>

OK, choc rozumiem nieporozumienie: klopoty z konwersja ciaglej linii na
ASCII ;-)

> agreguje: -------------->

ZALEZY!!!
A ----> B
Obiekty klasy A zaleza (maja w swoim interfejsie, np. jako parametry
wywolan!) od obiektow klasy B.

Agregacja to
A <>---------- B
Obiekty klasy B naleza do obiektow klasy A. Celowo pisze "obiektow klasy A",
bo to agregacja dzielona. Agregacja kompozycyjna (nie wiem jak
przetlumaczyc "composite agregation") zaznacza sie wypelnionym
rombem, ktory trudno w ASCII przedstawic.

> 
> jesli masz ksiazke "head first design patterns", to zobacz
> np. na strone 54

Jesli niczego nie pomieszales i jest tam napisane tak jak Ty piszesz, to
radze te ksiazke... odpuscic.


-- 
Mariusz Lotko

Dnia Sat, 06 Jan 2007 11:13:41 +0100, Mariusz Lotko napisał(a):

> Agregacja kompozycyjna (nie wiem jak przetlumaczyc
> "composite agregation")

Może "agregacja złożeniowa" albo "agregacja poprzez zawieranie"?
Konkretnie to ja bym po prostu powiedział "zawieranie" ;) [jako
szczególny przypadek agregacji].

> zaznacza sie wypelnionym rombem, ktory trudno w ASCII przedstawic.

Może tak?:  <#>----

-- 
SasQ

Dnia Sat, 02 Dec 2006 17:08:07 -0800, Tomecki napisał(a):

> Załóżmy że mam dwie klasy A i B. klasa A zawiera jako
> atrybut obiekt klasy B. I teraz czy powinienem taki obiekt
> wpisać na listę atrybutów klasy A, czy też powiązać je za
> pomocą agregacji. Cały czas myślałem że to drugie. Ale z
>ciekawości wygenerowałem sobie kod w C++ i zamiast mieć
>obiektu w klasy B w klasie A miałem jedynie wskaźnik do niego.

Jeśli masz problemy z rozróżnieniem co jest agregacją, a co
kompozycją [zawieraniem, składaniem się z...], to pomóc może
zastanowienie się, czy czas życia obiektów klasy B zależy jakoś
od czasu życia obiektów klasy A.
Jeśli obiekty klasy B mogą istnieć "samodzielnie", nawet przed
utworzeniem obiektów klasy A, lub po jej zniszczeniu, to używasz
agregacji [wskaźnik, referencja, oznaczana pustym rombem <>----
na diagramach UML].
Jeśli czas życia obiektów klasy B jest związany z czasem życia
obiektów klasy A, to masz do czynienia z zawieraniem [composition] i
wtedy obiekt klasy B jest "wbudowany" w obiekt klasy A [oznacza
się to zapełnionym rombem <#>---- na diagramach UML ;)].

Przykładowo obiekt klasy ZespółProgramistów agreguje w sobie
grupę obiektów klasy Programista ;)  Obiekty klasy Programista
składają się więc na obiekt klasy ZespółProgramistów, ale jest
to agregacja, bo ZespółProgramistów może się rozpaść, ale jego
składowi Programiści nadal istnieją i mogą utworzyć inny
ZespółProgramistów ;)  W dodatku jeden Programista może być
częścią kilku ZespołówProgramistów ;) co w przypadku kompozycji
[zawierania] nie jest możliwe.
Z kolei obiekt klasy Samochód jest kompozycją dwóch obiektów
klasy Koło, jednego lub więcej obiektów klasy Silnik, obiektu
klasy Kierownica itp. ;)  Są one jego integralnymi częsciami
i jeśli puścisz samochód z dymem, to spłonie jako całość, wraz
z obiektami składowymi ;) W dodatku jedno Koło nie może być
częścią składową kilku Samochodów, jak mogłoby to mieć miejsce
w przypadku agregacji ;)

-- 
SasQ