Assoziation & Aggregation

finix

Gast++ schrieb:

@finix:
Siehst Du noch eine andere Entsprechung unter C++ die sie nicht zur Aggrgation/Koposition spezialisiert?

Um, ja, mein voriges Beispiel.

Ich sehe die Formulierung "unter C++" eigentlich eher als problematisch an. Du hast im Modell Assoziationen, Aggregationen etc., und das wird dann, in welcher Form auch immer, in C++ umgesetzt.

Aber du kannst z.B. bei

struct foo
{
  bar* baz;
};

nicht hergehen und aus dieser Definition herleiten dass das jetzt eine Aggregation oder was auch immer ist. Könnte genauso gut eine stinknormale Assoziation sein, oder eine Komposition, oder auch gar nicht im Modell vorkommen sondern einfach nur ein Artefakt der Implementation sein.

Artchi

Deshalb habe ich oben schon gesagt, das man die UML nicht in C++ abbilden kann. C++ (und andere Sprachen) bieten garnicht den entsprechenden Sprachumfang an.

Gast++

finix schrieb:

Gast++ schrieb:

@finix:
Siehst Du noch eine andere Entsprechung unter C++ die sie nicht zur Aggrgation/Koposition spezialisiert?

Um, ja, mein voriges Beispiel.

"Auto kennt die Strasse"

// Car.hpp
#include "Street.hpp"
//...
class Car {
public: // or whatever visibility
    void drive(Street& street);
//...
}:
// resp
// Car.cpp
#include "Street.hpp"
//...
void Car::drive(void) {
    Street street;
    //...  
}

Oder wie sonst noch?

finix schrieb:

Ich sehe die Formulierung "unter C++" eigentlich eher als problematisch an.

Stimmt. Imo besser "Umsetzung mittels". Einverstanden?

finix schrieb:

Aber du kannst z.B. bei
struct foo
{
  bar* baz;
};

Das ist aber jetzt die Richtung Code Model.
Bei "Assoziation" et al sehe ich eher die Umsetzung Model Code als klärenswert an.

Grüsse

*this

finix

Artchi schrieb:

Deshalb habe ich oben schon gesagt, das man die UML nicht in C++ abbilden kann. C++ (und andere Sprachen) bieten garnicht den entsprechenden Sprachumfang an.

Natürlich kann man UML in C++ (und vielen anderen Sprachen) abbilden!? Man kann es nur im Allgemeinen schlecht umkehren.

finix

Gast++ schrieb:

Oder wie sonst noch?

Ich meinte eigentlich eher

class car
{
  street*  location;
};

Das ist eine normale Assoziation.

Gast++ schrieb:

finix schrieb:

Ich sehe die Formulierung "unter C++" eigentlich eher als problematisch an.

Stimmt. Imo besser "Umsetzung mittels". Einverstanden?

Perfekt

Gast++ schrieb:

Bei "Assoziation" et al sehe ich eher die Umsetzung Model Code als klärenswert an.

Naja, Assoziation läuft doch im Prinzip zumeist darauf hinaus ein bar* oder container<bar*> im foo zu haben. Aber das kann man natürlich implementieren wie man will - wenn von 100.000 foo in der Regel nur 4, 5 tatsächlich zu bar s in Beziehung stehen könnte man diese auch einfach "auslagern".

Eine Operation car::crash_into(tree) würde ich jetzt nicht als Assoziation zwischen car und tree sehen, und einen "lokalen Ausdruck in einer Methode" noch viel weniger. Das war nicht wirklich was ich mit "kennen" meinte.

Gast++

finix schrieb:

Ich meinte eigentlich eher
class car
{
  street*  location;
};
Das ist eine normale Assoziation.

Jein. Ich geb ja gerne zu dass ich PDFs hasse und insbesondere die von der OMG (Object Managemtn Group aka "Oh My God" aka "Our Metaspec Gospel"), aber dies ist imo eine Aggregation (UML "by reference"), also eine spezialisierte Assoziation.

finix schrieb:

Gast++ schrieb:

Bei "Assoziation" et al sehe ich eher die Umsetzung Model Code als klärenswert an.

Naja, Assoziation läuft doch im Prinzip zumeist darauf hinaus ein bar* oder container<bar*> im foo zu haben.

Dto; ich kenne das als Aggregation(UML "by reference")

Grüsse

*this

P.S.:

finix schrieb:

Eine Operation [c]car::crash_into(tree)

Ach was, sowas löst man mit einem Sentry

class Sentry {
public:
    Sentry(Tree* pTree) {
         delete pTree;
    }
};

class Car { 
public:
    void crash_into(Sentry s) {

    }
};

...und schon isser weg, der Baum.

Kennst Du den MS-Airback?

"Es hat sich ein Auffahrunfall ereignet! Airbag wirklich aufblasen?"
<Ja> <Nein> <Abbrechen>

finix

Gast++ schrieb:

Jein. Ich geb ja gerne zu dass ich PDFs hasse und insbesondere die von der OMG (Object Managemtn Group aka "Oh My God" aka "Our Metaspec Gospel"), aber dies ist imo eine Aggregation (UML "by reference"), also eine spezialisierte Assoziation.

Hmm, naja, ich bin kein UML-Spezialist, von daher könntest du ggf. recht haben. Gibt's da irgendwo ein Zitat zu?

Gast++ schrieb:

...und schon isser weg, der Baum.

Gast++

finix schrieb:

Hmm, naja, ich bin kein UML-Spezialist, von daher könntest du ggf. recht haben. Gibt's da irgendwo ein Zitat zu?

Zitate gibt's viele (z.B. könnten meine ehemaligen Kursteilnehemr mich zitieren) aber was bringt das?

Autoritativ wäre

- ein Statement der OMG
- ein Statement von Prof. Stroustrup

Die OMG begibt sich aber nicht in gerne in die Niederungen konkreter Programmiersprachen und von Prof. Stroustrup kenne ich nichts explizites zum Verhältnis C++/UML.

In den "Sekudaärpublikationen" zu den OMG Standards findet sich der Terminus "Whole/Part" Beziehung, z.B. hier

http://www-306.ibm.com/software/rational/uml/

in Document "Basics III" auf S. 9.

"Whole/Part" führt mittels C++ umgesetzt zu einer "Membervariable" ggf. in einem Container.
Und für komplexe Typen gilt dies auch umgekehrt.

Grüsse

*this

finix

Gast++ schrieb:

"Whole/Part" führt mittels C++ umgesetzt zu einer "Membervariable" ggf. in einem Container.
Und für komplexe Typen gilt dies auch umgekehrt.

Dem ersten Teil kann ich - im Allgemeinen, s.o. - zustimmen, aber wieso sollte dies auch umgekehrt gelten?

Wie würdest du denn Flight und Plane in C++ umsetzen, das Beispiel zur bidirektionalen (Standard-) Assoziation auf Seite 6?

Gast++

finix schrieb:

Gast++ schrieb:

"Whole/Part" führt mittels C++ umgesetzt zu einer "Membervariable" ggf. in einem Container.
Und für komplexe Typen gilt dies auch umgekehrt.

Dem ersten Teil kann ich - im Allgemeinen, s.o. - zustimmen, aber wieso sollte dies auch umgekehrt gelten?

Wenn "etwas" (die Membervaiable) in etwas anderem (der Klasse resp ihren Instanzen) enthalten ist ist es ein Teil.
Meine Einschränkung bezog sich auf PODs und Basistypen (std::string), die muss man nicht als Supplier einer Aggregation/Komposition modellieren; sondern nimmt sie einfach als "normale" Attribute auf.

finix schrieb:

Wie würdest du denn Flight und Plane in C++ umsetzen, das Beispiel zur bidirektionalen (Standard-) Assoziation auf Seite 6?

Was da zu sehen ist ist eine fachliche Modellierung; das sollte man nicht 1:1 abzubilden versuchen sondern mit einer weiteren Klasse zu einem Dreieck erweitern.

"CFlight" und "CPlane" kennen sich dann nicht mehr sondern z.B. "CSchedule" kennt beide und garantiert die Kardinalitäten.

Grüsse

*this

finix

Gast++ schrieb:

Was da zu sehen ist ist eine fachliche Modellierung; das sollte man nicht 1:1 abzubilden versuchen sondern mit einer weiteren Klasse zu einem Dreieck erweitern.

"CFlight" und "CPlane" kennen sich dann nicht mehr sondern z.B. "CSchedule" kennt beide und garantiert die Kardinalitäten.

"Sollte" und "versuchen" hören sich nicht direkt an wie "OMFG hat entschieden das muss so gemacht werden".

Btw, Ungarische Notation ist evil

Gast++

finix schrieb:

"Sollte" und "versuchen" hören sich nicht direkt an wie "OMFG hat entschieden das muss so gemacht werden".

Dazu brauch ich nicht die OMG; dazu reicht mir meine Logik und meine Erfahrung mit zyklischen Abhängigkeiten und Forward-Deklaratioenen.

Was würde Dir ein Statement der OMG bringen wenn Du's in der Programmiersprache nicht ohne weitgehende Zugeständnisse zu Lasten guten Progrmmierstils umsetzen könntest?

Grüsse

*this

Assoziation &amp; Aggregation

Assoziation & Aggregation