Asocjacja i agregacja w diagramach UML

Witam, ucze się wykorzystywać język UML w projektowaniu aplikacji. Stworzyłem sobie taki o to diagram klas:

Jak widać zastosowałem tutaj relacje asocjacji i agregacji pomiędzy klasami.
Moje pytanie jest takie, czy jeżeli klasa stockQuotes jest w relacji kompozycji z klasą MainWindow to czy może być też w relacjach agregacji z klasami simulationGrowthVolume i simulationOptimalStrategy? Bo jak wynika z zasady relacji kompozycji to może ona być członkiem tylko jednej klasy. Na przykład tak jak pokoje budynku mogą należeć tylko do jednego budynku i nie więcej. Jak to się ma do sytuacji przedstawionej na moim diagranie? Czy jest on nierozsądny? Klasy simulationGrowthVolume i simulationOptimalStrategy będą zawierać wskaźniki na obiekt stockQuotes.

Dwie uwagi na począek:

1. Kompozycja vs. agregacja - obydwie modelują sytuację "jest częścią". Różnica jest w cyklu życia.
   Kompozycja oznacza, że "część" kończy życie razem z bytem nadrzędnym (hotel - pokój), w agregacji
   (rezerwacja - pokój) tak nie jest.

2. Asocjacja vs Kompozycja vs Agregacja - Kompozycja/Agregacja są szczególnymi przypadkami Asocjacji,
   tzw. asocjacje binarne (czyli mogą mieć dwa końce, zaś asocjacja może łączyć >=2 koncepty)

Specyfikacja (UML Superstructure Specification, v2.4.1, pkt. 7.3.2) o smeantyce agregacji mówi tyle:

"Precise semantics of shared aggregation varies by application area and modeler. The order and way in which part instances are created is not defined."

Po co używać na diagramie agregacji, skor każdy rozumie ją inaczej? :)

Wracając do diagramu:
a) Czy *stockQuotes *ma prawo istnieć jeśli nie istnieje MainWindow?
b) Po co kompozycje do specjalizacji symulacji, skoro masz ogólną klasę simulation?
Jeśli dodasz w przyszłości nową specjalizację symulacji, to *MainWindow *trzeba będzie modyfikować?
Nie lepiej zrobić kompozycję MainWindow->simulation? (0..N)

c) Zamiast agregacji może po prostu asocjacja, które modeluje sytuację "używa/korzysta z" ?