C++ als UML

inflames2k

Nö, das sind gerichtete Assoziationen.

Deine Klasse C hat das Attribut B.
C -> B

Deine Klasse A hat die Attribute B und C.
A -> B
|
v
C

// EDIT:
Wobei ich aufgrund der gerichteten Assoziation schon einen Punkt entdecke, bei dem ich mich frage ob die Verbindung notwendig ist.
A verwendet C, soweit ok.
A verwendet B, u. U. ok.
C verwendet B, wenn A - B verwendet, warum B noch einmal in C verwenden? Oder anders, ums logisch richtiger darzustellen, wenn C - B verwendet, warum sollte A noch einmal B verwenden? Du kannst doch über C auf B zugreifen.

ich muss sowohl in C also auch in A auf B zugreifen. C erbt ja nicht von A.
oder versteh ich was falsch?

im prinzip sind das bei mir nur member-zeiger die einfach auf das objekt zeigen.

Müsste es dann nicht so aussehen?

B <--- A ---> C

und zusätzlich noch ein pfeil von C ----> B ?

inflames2k

Naja aber du hast doch folgende Möglichkeit:

A -- > C -- > B

Wenn du das jetzt richtig betrachtest, siehst du, dass du trotz das A - B nicht direkt kennt die Möglichkeit besteht von A auf B zuzugreifen, zum Beispiel durch Methoden von B oder direktzugriff via C.B.IrgendWas(); Vom Direktzugriff rate ich dir dann jedoch aber dennoch ab.

ok danke das mit den Klassen habe ich vestanden. wie sieht es mit den Pointern jetzt aus? Wie stellt man pointer bzw. arrays oder 2dimensionale arrays dar?

Nohc eine zweite frage:

Zeigt man dann im obigen Beispiel in der Attributsliste von A auch z.B. den Pointer auf C auf? Also ist das dann nicht redundant? Brauche ich Attribut UND gerichtete Assoziation auf C oder reicht die Assoziation?

Zeus

GastXXL schrieb:

Nohc eine zweite frage:

Zeigt man dann im obigen Beispiel in der Attributsliste von A auch z.B. den Pointer auf C auf? Also ist das dann nicht redundant? Brauche ich Attribut UND gerichtete Assoziation auf C oder reicht die Assoziation?

In der Modellierung wird zwischen Assoziation(auch verschiede Typen) und Attribute unterschieden (eigentlich reicht die einmal Nennung) technisch also im Code sind Assoziation und Attribut Felder/Attribute/Eigenschaften dieser Klasse.

dot

UML ist eine Sprache um objektorientierte Systeme zu beschreiben und nicht C++ Code.

Wie willst du mit UML auch ein Design mit Templates darstellen?

inflames2k

GastXXL schrieb:

Nohc eine zweite frage:

Zeigt man dann im obigen Beispiel in der Attributsliste von A auch z.B. den Pointer auf C auf? Also ist das dann nicht redundant? Brauche ich Attribut UND gerichtete Assoziation auf C oder reicht die Assoziation?

Ich sagte bereits, dass du die Pointer einfach als Attribute der Klassen angeben sollst. Auf die Tatsache, dass es sich um einen Pointer handelt musst und solltest du nicht eingehen.

Zeus

wsderftgzh schrieb:

Wie willst du mit UML auch ein Design mit Templates darstellen?

http://www.sts.tu-harburg.de/~r.f.moeller/lectures/se-ss-05/05-Spezifikation-UML-Teil-1.pdf siehe Folie 12

UML ist eine Sprache um objektorientierte Systeme zu beschreiben und nicht C++ Code.

? du meinst also objektorientiertes C++ verdient nicht mit UML dargestellt zu werden?

Ich sagte bereits, dass du die Pointer einfach als Attribute der Klassen angeben sollst. Auf die Tatsache, dass es sich um einen Pointer handelt musst und solltest du nicht eingehen.

vielen dank - leider verstehe ich deine antwort eben nicht ganz. du meinst
wenn in C++ int* a; steht sollte ich einfach a : int screiben?
dann frage ich mich aber gleichzeitig warum ich an vielen stellen z.B. auch stl::vector oder einfache c-arrays dargestellt sehe über int* a = new int[n] (C++) mittels a : int[0..*] z.B.

inflames2k

GastXXL schrieb:

UML ist eine Sprache um objektorientierte Systeme zu beschreiben und nicht C++ Code.

? du meinst also objektorientiertes C++ verdient nicht mit UML dargestellt zu werden?

Das wurde in dem Satz mit keinem Wort gesagt. UML beschreibt aber den Programmaufbau, nicht den Programmaufbau mit der jeweiligen Programmiersprache. Darüber solltest du dir im klaren sein. Ein Klassendiagramm muss zum Beispiel auf alle Sprachen anwendbar sein, die OOP konform arbeiten.

Auf den zweiten Punkt gehe ich nicht weiter ein, außer dass viele Leute auch viele Möglichkeiten haben, wie sie etwas darstellen.

Ein Klassendiagramm muss zum Beispiel auf alle Sprachen anwendbar sein, die OOP konform arbeiten.

wie soll das mit Template-Klassen (UML2.0) und Java gehen?

wird eigentlich wenn man ein Attribut hat sowohl das Attribut in der Klasse dargestellt und zusätzlich dann noch die (un)gerichtete Assoziation oder ist das redundant? Also wenn man eine assoziation hat fügt man dann auch noch das attribut hinzu in die klasse?

..denn ich verstehe diese antwort nicht ganz von Zeus:

In der Modellierung wird zwischen Assoziation(auch verschiede Typen) und Attribute unterschieden (eigentlich reicht die einmal Nennung) technisch also im Code sind Assoziation und Attribut Felder/Attribute/Eigenschaften dieser Klasse.

danke

Zeus schrieb:

wsderftgzh schrieb:

Wie willst du mit UML auch ein Design mit Templates darstellen?

http://www.sts.tu-harburg.de/~r.f.moeller/lectures/se-ss-05/05-Spezifikation-UML-Teil-1.pdf siehe Folie 12

Ist das jetzt wirklich UML Standard? Wird alles was irgendwann mit Java geht irgendwann auch in UML aufgenommen?

Wie sieht sowas in UML aus?

template<class T>
class Foo : public T
{
};

class Bar
{
public:
	void b(){std::cout << "bar"; }
};

int main()
{
		Foo<Bar> fb;
		fb.b();
}