UML und Umsetzung in ein Programm

[bernstein]

Hallo allerseits,
Falls dieses Thema nicht in diese Gruppe gehört, bitte ich um einen Vorschalg, wo ich dies posten kann. Oder weiß jemand ein spezielles UML-Forum

Zu UML-Diagrammen habe ich folgende Fragen:
1) In wie fern muß ein UML-Diagramm vollständig sein, bzw. was darf weggelassen werden.
Muß z.B. die Kardinalität, Navigation, Assoziationsnamen, Rolle, Leserichtung, usw. angegeben werden oder ist das im Ermessen des UML-Erstellers?
Müssen alle Attribute einer Klasse in das zugehörige UML-Diagramm aufgenommen werden?

2) Wenn die Kardinalität angegeben wird, liegt doch schon programmtechnisch die Navigation fest (durch die entsprechenden Attribute in den Klassen).
Wenn dies nicht der Fall sein sollte, sehe ich nicht den Sinn einer Kardinalität.

3) Muss die ungerichtete Linie als bidirektionale Assoziation interpretiert werden, bzw. wie werden bidirektionale Assoziation dargestellt (An jedem Ende der Linie ein Pfeil)?

4) Was bedeutet der Satz (und ist er richtig?):
"In UML werden assoziierte Objekte nicht noch einmal als Eigenschaft der Klasse im Diagramm aufgeführt".

5) Beispiel:

Es soll das folgende UML-Diagramm in Java umgesetzt werden.


1.* 1
Fahrer ------------------------ Rennen
Teilnehmer

Dies bedeutet:
Zu einem Fahrer gehört genau ein Rennen.
Zu einem Rennen gehören mehrere (mindestens 1) Fahrer.
Der Bezeichner "Teilnehmer" bei "Fahrer" bedeutet, dass -beim Umsetzen in Java-Code) in der Klasse Fahrer sich das Attribut Teilnehmer mit dem Datentyp Rennen befinden muss oder kann das Attribut auch mit einem anderen Namen im Java-Code beteichnet werden?

Sind diese Aussagen richtig?

mfg
Bernstein

 

[Mumpitzelchen]

Ja heute ist Sonntag und morgen Montag wo man die Hausaufgaben abgeben muss.

 

[NuminousDestiny]

1)Wann ist ein UML Diagramm vollständig? Genau dann, wenn es ausreicht den Sachverhalt unmissverständlich zu beschreiben. Das ist eben von Personen abhängig.
2)NEIN! Die Kardinalität alleine sagt lediglich etwas über die Mengenbeziehung aus. Quallifier legen die Navigation fest.
3)Abhängig davon, wie es definiert wurde.
4)Siehe 2, was verstehst du überhaupt darunter?
5)1 & 2 würde ich anderst formulieren. 3 ist komplett falsch!

 

[bernstein]

>
>Wann ist ein UML Diagramm vollständig? Genau dann, wenn es ausreicht den Sachverhalt
>unmissverständlich zu beschreiben. Das ist eben von Personen abhängig.
>

Gibt es dazu keine klare Vorschrift, oder lässt die Vorschrift dies zu ?

>
>2)NEIN! Die Kardinalität alleine sagt lediglich etwas über die Mengenbeziehung aus. >Quallifier legen die Navigation fest.
>

Wenn es zu jedem Auto genau einen Fahrer und zu jedem Fahrer genau ein Auto gibt,
dann wird dies doch so implemntiert:
class Auto{
private Fahrer myFahrer;
...
}

class Fahrer {
private Auto myAuto;
...
}

Damit hat man doch automatisch von jeder Klasse Zugriff auf die andere
und damit hat man auch eine Navigation in jede Richtung.

>
>3)Abhängig davon, wie es definiert wurde.
>

Es muss doch irgendwelche Vorschriften geben, wie in UML eine
bidirektionale Assoziation gezeichnet wird.
Klassen werden doch auch als Rechtecke gezeichnet und nicht als Kreise.

>
>4)Siehe 2, was verstehst du überhaupt darunter?
>

Ich habe den Satz irgendwo gelesen und kann damit wenig anfangen.
Vielleicht versteht ihn jemand von euch.

>
>5)1 & 2 würde ich anderst formulieren.
>
wie ?

>
>3 ist komplett falsch!
>
was ist daran falsch ?

mfg

bs

 

[NuminousDestiny]

Eine klare Vorschrift gibts sowei ich weiß hierzu wohl nicht, kannst aber zur Sicherheit gerne die UML Spezifikation der OMG durchlesen, da muss sowas drinstehen

Nochmal zu 2) Eben nicht! Es wird nirgends erzwungen, dass das so umgesetzt wird. Gegenfrage, was ist, wenn das Auto zu dem es zwar nur 1 Fahrer gibt seinen Fahrer aber niemals kennen soll? Wie drückst du das dann aus? Die Antwort habe ich dir ja bereits gegeben.

Nochmal zu 3) Richtig, die Spezifikation gibt es s.o. Aber eine ungerichtete Assoziation muss niemals als bidirektional interpretiert werden. Das ist abhängig davon, wie es im Projekt/Unternehmen definiert wurde.

4) Bevor du mir nicht sagst, was du darunter verstehst und ob du ihn für richtig hälst, werde ich dir keine ausfürlichere Antwort als den Verweis auf 2 geben.

5) "gehören" ist hier als Assoziationsbezeichnung relativ blöd, wie wäre es mit fährt?
Und
"Der Bezeichner "Teilnehmer" bei "Fahrer" bedeutet, dass -beim Umsetzen in Java-Code) in der Klasse Fahrer sich das Attribut Teilnehmer mit dem Datentyp Rennen befinden muss oder kann das Attribut auch mit einem anderen Namen im Java-Code beteichnet werden? "

Diese Aussage ist totaler Schmarn.
Das steht ebenfalls in der UML Spezifikation.

Etwas Eigeninitiative ist beim Lernen/Hausaufgaben definitiv angebracht!

 

[bernstein]

>
>Nochmal zu 2) Eben nicht! Es wird nirgends erzwungen, dass das so umgesetzt wird.
>Gegenfrage, was ist, wenn das Auto zu dem es zwar nur 1 Fahrer gibt seinen Fahrer aber
>niemals kennen soll? Wie drückst du das dann aus?
>
Gar nicht, da ich es für sinnlos halte.
Gegenfrage:
Wie implementierst du diesen Fall?

>
>4) Bevor du mir nicht sagst, was du darunter verstehst und ob du ihn für richtig hälst,
>werde ich dir keine ausfürlichere Antwort als den Verweis auf 2 geben.
>
Ich wiederhole:
Ich habe den Satz irgendwo gelesen und kann damit _nichts_ anfangen.
Verstehst du ihn ? (so wie ich dich bisher interpretiert habe, geht es dir so wie mir).

>
>5) "gehören" ist hier als Assoziationsbezeichnung relativ blöd, wie wäre es mit fährt?
>
Ok, dann nimm doch eher die mathematische Notation:
Zu einem Auto gibt es genau einen Fahrer.
Was hältst du von dieser Notation?

>
>> "Der Bezeichner "Teilnehmer" bei "Fahrer" bedeutet, dass -beim Umsetzen in Java-
>> Code) in der Klasse Fahrer sich das Attribut Teilnehmer mit dem Datentyp Rennen
>> befinden muss oder kann das Attribut auch mit einem anderen Namen im Java-Code
>>beteichnet werden? "
>>
>Diese Aussage ist totaler Schmarn.
>
Kannst du dies näher begründen ?
>
>
>Etwas Eigeninitiative ist beim Lernen/Hausaufgaben definitiv angebracht!
>
Ja, habe schon einiges, aber widersprüchliches, zu diesem Thema gelesen bzw.
gehört. Deswegen meine Fragen.

mfg
bs

 

[NuminousDestiny]

>
Gar nicht, da ich es für sinnlos halte.
Gegenfrage:
Wie implementierst du diesen Fall?

Wie gesagt, das ist abhängig davon, ob es relevant ist, dass das Auto seinen Fahrer kennt oder nicht.
Falls das Auto den Fahrer nicht kennt:
Fahrer{
Auto* mycar
}
Auto hat kein Attribut mit Fahrer.

Falls es benötigt wird, hat Auto eben auch ein Attribut vom Typ Fahrer.

>
Ich wiederhole:
Ich habe den Satz irgendwo gelesen und kann damit _nichts_ anfangen.
Verstehst du ihn ? (so wie ich dich bisher interpretiert habe, geht es dir so wie mir).

Interpretieren ist so eine Sache man kann dabei, wie du total falsch liegen....
Der Satz sagt lediglich, dass man z.B. in einem Diagramm bei dem Fahrer und Auto assoziiert sind, die Attribute nicht nochmal in die Objekte/Klassen schreibt, sondern weglässt oder einen passenden Namen über die Assoziation an die Klasse.
z.B.
mycar
Auto 1----------------- 1 Fahrer.
-weight: int -name: String
-maxSpeed: int
(Die Formatierung ist bisschen schlecht, aber sollte dennoch erkennbar sein)

>
Ok, dann nimm doch eher die mathematische Notation:
Zu einem Auto gibt es genau einen Fahrer.
Was hältst du von dieser Notation?

Das ist alles andere als eine mathematische Notation. Wenn du das Mathematisch ausdrücken möchtest musst du Mengenbegriffe und Quantoren benutzen...
Wie aber gesagt, "hat" klingt einfach nach nichts. War aber nur ein Vorschlag.

>
Kannst du dies näher begründen ?

Die Begründung steht jetzt oben bei dem Beispiel. Der Fall ist genau anderst herum!

~Nmn

 

[bernstein]

>
>Wie gesagt, das ist abhängig davon, ob es relevant ist,
>dass das Auto seinen Fahrer kennt oder nicht.
>Falls das Auto den Fahrer nicht kennt:
>Fahrer{
>Auto* mycar
>}
>Auto hat kein Attribut mit Fahrer.
>
Ich verstehe deine programmtechnische Umsetzung.
Wenn aber das Auto keinen Fahrer kennt, ist es doch völlig egal, wie viele
Fahrer zu einem Auto gehören (also wie die Kardinalität aussieht), denn die
programmtechnische Umsetzung ist immer die gleiche.
Deswegen verstehe ich den Sinn nicht.
Oder wie würdest du es programmtechnisch umsetzen, wenn ein Auto den Fahrer nicht kennt, aber zu einem Auto einmal genau 1 und das andere Mal genau 2 Fahrer gehören.

>
>Der Satz sagt lediglich, dass man z.B. in einem Diagramm bei dem Fahrer und Auto
>assoziiert sind, die Attribute nicht nochmal in die Objekte/Klassen schreibt, sondern
>weglässt oder einen passenden Namen über die Assoziation an die Klasse.
>
>z.B.
>mycar
>Auto 1----------------- 1 Fahrer.
>-weight: int -name: String
>-maxSpeed: int
>(Die Formatierung ist bisschen schlecht, aber sollte dennoch erkennbar sein)
>
D.h. also (oder habe ich dich falsch verstanden) dass Auto mindestens aus den Attributen
int weight
int maxSpeed
besteht.
und Fahrer mindestens aus den Attributen
String name

Bist du sicher dass das stimmt?
Meine wenigen UML-Kenntnisse "sagen" folgendes (bzw. so habe ich dies schon notiert gesehen):

Auto 1<------------------------------------------------------------ >1 Fahrer.
Auto myauto Fahrer myfahrer

Dies bedeutet, dass die Klasse Auto mindestens aus dem Attribut myfahrer
und die Klasse Fahrer mindestens aus dem Attribut myauto besteht.
Die Navigation geht in alle 2 Richtungen (bidirektional).

Was stimmt nun ?

mfg
bs

 

[TheCadillacMan]

Wenn aber das Auto keinen Fahrer kennt, ist es doch völlig egal, wie viele Fahrer zu einem Auto gehören (also wie die Kardinalität aussieht), denn die
programmtechnische Umsetzung ist immer die gleiche.
Deswegen verstehe ich den Sinn nicht.
Oder wie würdest du es programmtechnisch umsetzen, wenn ein Auto den Fahrer nicht kennt, aber zu einem Auto einmal genau 1 und das andere Mal genau 2 Fahrer gehören.

UML dient eben i. d. R. nicht nur zum Beschreiben eines Programms, sondern so ein Diagramm sollte eben auch Wissen über die Problemdomäne dokumentieren.
Selbst wenn es auf den ersten Blick in der Klasse "Auto" egal ist, wie viele Fahrer es haben kann, kann es in anderen Bereichen des Programms durchaus sinnvoll zu sein, ob ein Auto mehrere Fahrer haben kann.
Bei Datenbankabfragen möchte ich wissen ob ich einen oder mehrere Datensätze zu erwarten haben.
Und in der Oberfläche will ich wissen ob ich dem Benutzer die Möglichkeit geben darf dem einem Auto mehrere Fahrer zuzuweisen oder nur einen Fahrer auszuwählen.

D.h. also (oder habe ich dich falsch verstanden) dass Auto mindestens aus den Attributen
int weight
int maxSpeed
besteht.
und Fahrer mindestens aus den Attributen
String name

Dein Satz 2) sagt ja nur aus (wie NuminousDestiny schon gesagt hat), dass Attribute die aufgrund einer Beziehung zu einer anderen Klasse vorhanden sind, nur an der Beziehung selbst und nicht noch mal in der Klasse dokumentiert werden.
Beispiel:

     1                                 1
Auto ----------------------------------- Fahrer
     myAuto                     myFahrer

Klasse Auto:                Klasse Fahrer
- weight                    - name
- name
- maxSpeed

myAuto bzw. myFahrer sind ja schon über die Beziehung ausgedrückt und müssen nicht noch mal dokumentiert werden.


Allgemein wird UML in der Praxis nicht besonders formal ausgelegt. Solange der dargestellte Sachverhalt erkennbar ist, ist ein Klassendiagramm ausreichend. Ein solches Diagramm ist eh niemals vollständig und kann es auch nicht sein, es muss nur ausreichend sein, das Problem zu lösen.

"Essentially, all models are wrong, but some are useful." (George Box)

 

[NuminousDestiny]

Ich denke TheCadillacMan hat deine Fragen beantwortet.
Falls du immernoch Fragen hast, kannst du sie natürlich gerne stellen, sofern diese nicht für eine Hausaufgaben sind.

Ansonsten würde ich dir aber mal empfehlen diverse Internetartikel hierzu zu lesen.
Ganz besonders bezogen auf Klassendiagramme wie bei Wiki:
http://de.wikipedia.org/wiki/Klassendiagramm

@TheCadillacMan
Mit der Aussage, dass ein Diagramm niemals komplett sei, habe ich ein Problem und kann dem auch nicht zustimmen.
Meiner Ansicht nach ist dieses komplett, wenn es den Sachverhalt korrekt(widerspruchsfrei, richtig und ausführlich genug, zu Vermeidung von Fehlinterpretationen) beschreibt.
Schließlich ist ein Modell eine Abstraktion und soll das Augenmerk auf bestimmte Aspekte legen und nicht notwendigerweise den realen Sachverhalt vollständig widergeben.

 

[TheCadillacMan]

Schließlich ist ein Modell eine Abstraktion und soll das Augenmerk auf bestimmte Aspekte legen und nicht notwendigerweise den realen Sachverhalt vollständig widergeben.

Genau darauf wollte ich hinaus.

 

[bernstein]

>UML dient eben i. d. R. nicht nur zum Beschreiben eines Programms,
>sondern so ein Diagramm sollte eben auch Wissen über die Problemdomäne
>dokumentieren.
>Selbst wenn es auf den ersten Blick in der Klasse "Auto" egal ist,
>wie viele Fahrer es haben kann, kann es in anderen Bereichen des
>Programms durchaus sinnvoll zu sein, ob ein Auto mehrere Fahrer haben kann.
>Bei Datenbankabfragen möchte ich wissen ob ich einen oder mehrere
>Datensätze zu erwarten haben.
>Und in der Oberfläche will ich wissen ob ich dem Benutzer die Möglichkeit
>geben darf dem einem Auto mehrere Fahrer zuzuweisen oder nur einen Fahrer
>auszuwählen.
>
Ich habe das immer noch nicht verstanden:
Wenn es aber wichtig ist, dass ein Auto mehrere Fahrer haben kann,
ist mir immer noch nicht klar, warum es dann unwichtig ist, von einem Auto
zu diesem einen oder mehreren Fahrer navigieren zu können.
Kannst du mir dazu ein konkretes Beispiel nennen ?

mfg
bs

Ergänzung (20. April 2012)

>
>Falls du immernoch Fragen hast, kannst du sie natürlich gerne stellen,
>sofern diese nicht für eine Hausaufgaben sind.
>
Ich wette mit dir (Navigation in alle 2 Richtungen) um 1 Million Euro, dass
ich weder in diesem noch in anderen Foren weder in der Vergangenheit noch in
Zukunft jemals Fragen zu meinem Hausaufgaben gestellt habe bzw. stellen werde.
Das liegt ganz einfach daran, dass ich "in letzter Zeit" keine Hausaufgaben machen musste
noch in Zukunft irgendwelche machen werden muss.

>
>Ansonsten würde ich dir aber mal empfehlen diverse Internetartikel hierzu zu lesen.
>Ganz besonders bezogen auf Klassendiagramme wie bei Wiki:
>http://de.wikipedia.org/wiki/Klassendiagramm
>
Ich kenne diese diversen Artikel im Internet.
Sie beantworten mir leider nicht die Fragen:
- Was ist obligat an den UML-Diagrammen, d.h. in wie weit müssen
sie vollständig sein (was darf weggelassen werden, was nicht)
- Wie wird bidirektionale Assoziation dargestellt?



mfg
bs

 

[NuminousDestiny]

Nunja wenn sich jmd. im Forum anmeldet, um solche Fragen zu stellen, dann kommt mir das eben spanisch vor. Gabs ja schon oft genug, dass Leute versucht haben Lösungen für ihre Hausaufgaben hier abzugreifen...

Das Beispiel mit dem Auto:
Es ist vllt. nicht das beste Beispiel. Versuchen wir es mal mit einer Spielesammlung, Spielbrettern und Würfeln.
Ein Spielbrett hat 0...* Würfel.
Ein Würfel gehört zu 0...* Spielbrettern.

Das wäre ja eine bidirektionale Assoziation. (Genaugenommen wäre es sogar eine Aggregation)
Programmtechnisch ist aber vllt. gar nicht relevant, dass der Würfel sein Spielbrett kennt, da nur das Spielbrett wissen muss, welche und wie viele Würfel es besitzt, um die Summe aller Würfelaugen zu bestimmen.
Warum also in der Klasse Würfel ein Attribut Spielbrett einführen, wenn es doch nie benötigt/benutzt wird?
Man möchte den Sachverhalt lediglich Ausdrücken wie es ist. Würde hier aber den Qualifier "SpielbrettDesWürfels" bei der Assoziation weglassen.
Die Assoziation egal ob bidirektional oder einseitig, gibt lediglich an, ob bestimmte Objekte/Klassen miteinander in Verbindung stehen oder ob nicht.
Die Qualifier(Bezeichner) bei den Assoziationen entsprechen i.d.R. der technischen Umsetzung.

Diese können wir folgt dargestellt werden:


Jede dieser Assoziationen ist bidirektional.
Lediglich die Qualifier unterscheiden sich.

In wie weit die Diagramme vollständig sein müssen, haben wir jetzt schon x mal geschrieben.
Aus deiner Aussage kann ich leider nicht entnehmen, ob es dir immer noch unklar ist oder ob du lediglich sagen wolltest, dass kein Artikel diese Fragestellung beantwortet.

 

[bernstein]

>Das wäre ja eine bidirektionale Assoziation. (Genaugenommen wäre es sogar
>eine Aggregation)
>Programmtechnisch ist aber vllt. gar nicht relevant, dass der Würfel sein
>Spielbrett kennt, da nur das Spielbrett wissen muss, welche und wie viele Würfel es
>besitzt, um die Summe aller Würfelaugen zu bestimmen.
>Warum also in der Klasse Würfel ein Attribut Spielbrett einführen,
>wenn es doch nie benötigt/benutzt wird?
>

Deswegen ist es doch eine unidirektionale Assoziation und keine
bidirektionale.

>
>
>Man möchte den Sachverhalt lediglich Ausdrücken wie es ist.
>Würde hier aber den Qualifier "SpielbrettDesWürfels" bei der Assoziation weglassen.
>Die Assoziation egal ob bidirektional oder einseitig, gibt lediglich an, ob bestimmte
>Objekte/Klassen miteinander in Verbindung stehen oder ob nicht.
>
Ja, aber die Verbindung wird doch durch die Attribute realisiert.

>
>Diese können wir folgt dargestellt werden:
>Jede dieser Assoziationen ist bidirektional.
>Lediglich die Qualifier unterscheiden sich.
>

Nur die 1. Assoziation ist bidirektional.
Die 2. und die 3. sind unidirektional.
Und von der 4. weiss ich nicht, wie man diese bezeichnet.
Wenn man den Begriff bidirektional so weitgehend wie du interpretiert,
dann kann man jede unidirektionale Assoziation als bidirektional bezeichnen.
Oder kannst du mir eine Assoziation angeben, die nicht bidirektional ist,
sondern nur unidirektional.

>
>In wie weit die Diagramme vollständig sein müssen, haben wir jetzt schon x
>mal geschrieben.
>Aus deiner Aussage kann ich leider nicht entnehmen, ob es dir immer noch
>unklar ist oder ob du lediglich sagen wolltest, dass kein Artikel
>diese Fragestellung beantwortet.
>
Kein Artikel beantwortet diese Fragestellung.

mfg
bs

 

[NuminousDestiny]

Von Wiki geklaut: "Assoziationen, die auf beiden Seiten navigierbar sind, heißen bidirektionale Assoziationen, nur an einem Ende navigierbare Assoziationen entsprechend unidirektional."

Ich habs grad in der Spezifikation nachgesehen aber aufgegeben innerhalb von 740 genau den Punkt zu finden...

Worauf ich mich bezogen habe ist eben die programmtechnische Umsetzung. Das ändert nichts daran, dass man es trotzdem so im Diagramm modellieren kann, weil der Sachverhalt so korrekt wäre.