Wie ist folgende Abhängigkeit in UML2 zu formulieren.

[lack]

Hallo!

Wie ist folgende Abhängkeit mit UML2 zu beschreiben?

class A {

public void aFunction() {
B myB = new B();
// benutze B-Objekt

}

}

class B {

// some functions

}

Ich schwanke da sehr, auch die gängige Literatur hat mir da leider keinen Königsweg aufgezeigt.

Gruß

lack

 

[ms]

Assoziation bzw. Aggregation oder Komposition.
Wobei schwankst du?

ms

 

[diggaa1984]

ich hät da auch gleich ma ne passende frage

hab nun MS Visio Prof 2007 installiert und da gibt einmal "Verknüpfung" (einfache Linie ohne Pfeile oder so, mit Ende-Beschriftungen) und "navigierbare Assoziationen" (einfache Linie mit möglichen Pfeilen an Enden, Multiplizität und Beschriftung) ... also unidirektionale Beziehung seh ich ja noch ein, aber wo wäre der Unterschied zwischen Bidirektional (jedes Ende hat ein Pfeil) und der Verknüpfung? ... kann da so recht kein logischen Unterschied finden.

Wenn ich klasse A mit B verknüpfe, kann ich doch von ausgehen das mind. unidirektional, oder eben bidirektionale beziehung (assoziation) besteht. Hab da schon UML2-Spec durchgewühlt, aber die war mir so spontan ein wenig zu undurchsichtig.

 

[FArt]

Annahme: es geht um ein Klassendiagramm.

Es gibt keinen Köngisweg, denn eine Instanz von B als Attribut in A kann verschiedenes bedeuten... Assoziation, Komposition, Aggregation... mach einfach einen Strich... *G*

 

[SnooP]

mit einem new B() innerhalb einer Methode hat man noch überhaupt nischts... bei einer Assozation, die auch eine Komposition im besten Fall sein kann, hält Klasse A eine Beziehung oder Referenz zur Klasse B... das ist im oberen Fall aber nicht der Fall... evtl. will man ja gerade keine Abhängigkeiten haben... hier ist die Beziehung ein <<uses>> - sprich ein gestrichelter Pfeil auf B.

Das Visio-Teil für UML ist nicht unbedingt brauchbar... es gibt dafür eigene visio stencils die man sich im Netz ziehen kann, die besser das ermöglichen was man eigentlich darstellen will... (sprich mehr Freiheiten).

Eine Verknüpfung ist die schwächste Form einer Assoziation wenn man so will... wenn man also gezielt unterspezifizieren will... ich würde davon abragen... navigierbar sollte es schonn sein.

Bidirektional (also beide Pfeile) ist schon zwingend navigierbar... eine Verknüpfung (glatter Strich ohne Pfeilspitzen) ist nicht navigierbar und trifft darüber auch keine Aussage... entweder man ist sich noch nicht sicher wo die Referenz hinkommen soll später oder man geht davon aus, dass man das auf anhieb sieht ... wenn's letzteres ist, kann man dem Zeichner das Ding nur um die Ohren schlagen *g*

 

[FArt]

SnooP hat recht.
Man könnte es dann als Schnittstelle (nicht Inteface im Java-Sinn!) schreiben... Anbieter und Benutzer ...das ist dieser Stecker beim Anbieter und die Buchse beim Nutzer.

 

[ms]

SnooP hat recht.

Jup

Man könnte es dann als Schnittstelle (nicht Inteface im Java-Sinn!) schreiben... Anbieter und Benutzer ...das ist dieser Stecker beim Anbieter und die Buchse beim Nutzer.

Du meinst den Lollipop?
Das ist aber genaugenommen nur eine andere Darstellungsform für ein Interface (im Java und UML-Sinn).

ms

 

[FArt]

Das ist aber genaugenommen nur eine andere Darstellungsform für ein Interface (im Java und UML-Sinn).
ms

Kann sein, muss aber nicht. Es ist eine zugesicherte Schnittstelle. In Java ist das in der Regel ein Interface, kann aber auch anderweitig festgelegt sein. Eigentlich reicht es, zugreifbare (z.B. öffentliche) Methoden zur Verfügung zu stellen. In der Regel solle aber der Zugriff und das Verhalten irgendwie zugesichert werden.
Es gibt ja auch OO-Sprachen, die keine Interfaces kennen ...

 

[ms]

Es gibt ja auch OO-Sprachen, die keine Interfaces kennen ...

Welche denn?

ms

 

[maki]

C++ zum Beispiel, alles nur Klassen..

 

[tfa]

Es gibt ja auch OO-Sprachen, die keine Interfaces kennen ...

Welche denn?

Duck-Type-Sprachen wie z.B. Ruby.

 

[ms]

C++ zum Beispiel, alles nur Klassen..

Ich meinte jetzt im UML-Sinn. Ein Interface wird in verschiedenen Sprachen anders realisiert.
Aus UML-Sicht sind es aber immer Interfaces, also eine Schnittstellenvereinbarung.

ms

 

[tfa]

Wie gesagt, Ruby kennt keine Interfaces. Es gibt auch keine Methodenaufrufe im Sinn von etwa Java oder C++, also besteht auch kein Bedarf an Interfaces, die ja nichts weiter machen, als Methodenimplementierungen vorzuschreiben.

 

[ms]

Ist UML somit als Beschreibungssprache für Ruby ungeeignet?
Oder umgekehrt: Ist Ruby als Zielsprache für MDA unbrauchbar?
Ich kenne Ruby nicht wirklich, scheint aber nach kurzem überfliegen der Fall zu sein.
Was sagt ihr?

ms

 

[tfa]

Ob UML bei Rubyaner weit verbreitet ist, weiß ich nicht. Wahrscheinlich eher weniger. Ich habe es jedenfalls noch nie ausprobiert.
Das Problem ist, dass UML sehr statisch ist und Ruby oder auch Python sehr dynamisch. Jedes Objekt hat zwar eine Klasse, von der es erzeugt wurde, aber es lassen sich nachträglich Methoden hinzufügen und entfernen oder ganze Module "herein mixen".

Mit MDA kenn ich mich zu wenig aus. Aber wird da nicht auch viel Code automisch generiert? Man beschreibt sein Model in einer Sprache und der Rest geschieht praktisch von selbst. Diese Sprache muss ja nicht UML sein, es kann auch eine DSL sein (wofür dynamische Skriptsprachen ja sehr gut geeignet sind). Also sollte Ruby eher besonders gut für MDA geeignet sein -- meine Vermutung (wie gesagt ich nix MDA).

 

[SnooP]

Sehe ich genau so... und ob UML so geeignet für MDA/MDD bzw MD* ist, hatten wir auch schon mehrfach in der Diskussion...

und ich glaube tatsächlich nicht, dass es klug wäre ein UML-Diagramm zu malen, wenn man dann in Ruby realisieren will ... UML (also Klassendiagramme) schreit ja geradezu nach statischer getyptheit, die man in dynamischen Sprachen wie Ruby ja aber nich hat... schon aus Prinzip nicht.