Wie kann ich Methoden-Attribute in UML darstellen?

[mutetella]

Hallo,

ich beschäftige mich gerade damit, wie ich eine Programmstruktur bzw. Objekte mittels UML darstellen kann.

UML besitzt ja ein eigenes Klassensymbol, das wiederum Attribute und Operationen (Methoden) darstellen kann. Wie stelle ich allerdings Attribute von Klassenmethoden dar, sprich Variablen, die im Namendsraum der Methode, aber nicht der Klasse, definiert sind?

Soweit ich das sehe, ist das in UML nicht vorgesehen. Denkfehler meinerseits?

Gruß
mutetella

EDIT: Als Beispiel:
ViewParameter.make_item_box().xy_item_box

[BlackJack]

@mutetella: Lokale Namen stellt man mit UML gar nicht dar. Die sind ja auch gar nicht sichtbar, warum sollte man die darstellen wollen? Man kommt da ja im laufenden Code (ausser mit schmutzigen Tricks über den Aufrufstapel) von aussen auch nicht heran.

Darum weiss ich auch nicht so recht was Du mit ``ViewParameter.make_item_box().xy_item_box`` sagen willst, denn da sehe ich keinen Namen der lokal in einer Methode ist. Die `make_item_box()`-Methode hat einen Rückgabewert und dieser Rückgabewert hat ein Attribut `xy_item_box`. Das Attribut gehört also zum Typ des Rückgabewerts und genau da kann man das in UML auch angeben.

Wobei der Begriff UML hier auch nicht so ganz eindeutig ist. Was willst Du denn eigentlich darstellen -- es gibt da ja verschiedene Diagrammtypen.

[bwbg]

Ich interpretiere diese Code-Zeile als einfachen Attributzugriff. Diese könnte man wie folgt ausschreiben:

Code: Alles auswählen

#ViewParameter.make_item_box().xy_item_box
itembox = ViewParameter.make_item_box()
itembox.xy_item_box

Ergo: Der erste Funktionsaufruf gibt ein Objekt (Referenz) zurück, auf dessen Attribut zugegriffen wird.

Daher folgendes Klassendiagramm

Code: Alles auswählen

ItemBox
-----
+ xy_item_box

ViewParameter
-----
-----
+ make_item_box() : ItemBox // class-method

[mutetella]

@BlackJack: Es ist so, dass ich mal wieder gemeint habe, klüger zu sein als alle anderen und mich mit dem ModelViewController-Konzept nicht beschäftigt habe. Das ist eh nur was für Profis und außerdem wollte ich nach endlosen Tutorien, Beispielprogrammen etc. pp. endlich mit Programmieren anfangen... Zwischenzeitlich habe ich mich in das Thema hineingelesen und möchte MVC einfach stärker beachten.
Um Model-, View- und Control-Bereiche künftig besser zu trennen, möchte ich die Klassen, Methoden und Funktionen meines Programmes in einem Diagramm darstellen. Ich bin mir überhaupt nicht sicher, welcher Diagrammtyp da geeignet erscheint. Ich möchte einfach darstellen, welche Klassen vorhanden sind, woher sie ihre Informationen bekommen und wem sie diese weitergeben (eigentlich dasselbe!). UML unterscheidet ja Struktur- und Verhaltensdiagramme.
Ok, ich habe also damit begonnen, Klassen, die ich verwenden möchte, darzustellen. Mein Beispiel war wohl nicht richtig dargestellt. Ich habe eben folgendes versucht, darzustellen:

ViewParameter()
-------------------
-------------------
+make_item_box()
-->xy_item_box
-->gap_item_box
-->title_item_box

Du meinst also, dass die Methoden-Attribute (xy_item_box, gap_item_box, title_item_box) in der Darstellung nichts verloren haben? Aber wie notiere ich dann Attribute, die von einer Klasse zu einer anderen gesendet werden?

@bwbg: So ähnlich hatte ich das bisher auch, allerdings wird damit ja schon fast ein Ablauf dargestellt. Mir geht es zuerst darum, die Klasse an sich darzustellen, mit Ihren Methoden und den Attributen, die innerhalb einer Methode verwendet werden.

[BlackJack]

@mutetella: Ich denke wir haben hier Begriffsprobleme: Was genau sind für Dich "Methoden-Attribute"? Ich würde darunter Attribute verstehen, die auf Methoden existieren, denn Methoden sind in Python ja auch Objekte. Aber das wirst Du wahrscheinlich nicht meinen.

Ich habe den Eindruck Du willst in einem UML-Diagramm mehr darstellen als dort vorgesehen ist. Welche Attribute von einer Methode benutzt werden, gehört da zum Beispiel IMHO nicht hinein.

Welche Klassen vorhanden sind, klingt nach einem Klassendiagramm. Informationsfluss habe ich noch nie in UML ausgedrückt und ich glaube auch noch nicht gesehen.

[mutetella]

@BlackJack: Ich hab' mich da falsch ausgedrückt. Du vermutest richtig, ich meinte Attribute, die von einer Methode verwendet werden (wie nennt man die dann eigentlich?). Und ja: Ich möchte mal wieder alles an einem Ort haben...

Aber welche Möglichkeit gibt es, die "Feinheiten" wie eben Variablennamen und dergleichen darzustellen? Oder fängst Du da dann bereits mit dem Code an?

[snafu]

Bist du sicher, dass du nicht eher die Methoden des Rückgabewerts eines Methodenaufrufs meinst? Also angenommen, `make_item_box()` gibt ein Exemplar der Klasse `ItemBox` zurück, dann willst du doch offenbar die Methoden des Exemplars beschreiben und nicht die Methoden des Objekts vom Typ `instancemethod`, welches an den Namen `make_item_box` gebunden ist. Falls du nicht verstehst, was gemeint ist, dann mach mal ein `type(make_item_box)` und ein `dir(make_item_box)`.

[bwbg]

(wie nennt man die dann eigentlich?).

Wahrscheinlich "Attribute, welche von einer Methode verwendet werden."

Mir ist noch kein Klassendiagramm untergekommen, wo die verwendeten Attribute (der Klasse) aufgeführt werden. Das macht auch nicht wirklich Sinn, da man getrost davon ausgehen kann, dass alle Attribute verwendet werden - auch wenn das tatsächlich nicht der Fall ist.

Da diese Klassendiagramme IMO dazu gedacht sind, die Klassenbeziehungen untereinander zu modellieren, ist es auch nicht notwendig. Die UML-Klassendiagramme lassen sich auf Python (Stichwort: Duck-Typing) auch nicht vollständig anwenden. Für gewöhnlich notiere ich lediglich die "öffentliche" Schnittstelle einer Klasse.

Grüße ... bwbg

[mutetella]

@snafu: Sorry, mit dem Methodenname 'make_item_box()' habe ich wohl ein wenig hochgestapelt... Die Methode liefert keine ItemBox(), sondern lediglich eine Liste mit den Koordinaten eines Rechtecks. Ok, sollte ich in 'make_item_coords()' umbenennen.

@bwbg: Wie schon gesagt, ich wollte mal wieder alles in kompakter Form möglichst auf einer DIN A5 Seite unterbringen. Du hast schon Recht, ein Klassendiagramm muss nicht jeden "Kram", der sich in der Klasse befindet, auch darstellen. Das Prinzip "Weniger ist oft mehr!" ist für mich immer wieder auf's Neue eine Herausforderung...

Gruß
mutetella

[Darii]

@BlackJack: Ich hab' mich da falsch ausgedrückt. Du vermutest richtig, ich meinte Attribute, die von einer Methode verwendet werden (wie nennt man die dann eigentlich?).

Die haben keinen Namen.

Wenn eine Methode das Vorhandensein bestimmter Attribute voraussetzt und du das dokumentieren willst, musst du eine entsprechende Schnittstelle definieren.

Aber welche Möglichkeit gibt es, die "Feinheiten" wie eben Variablennamen und dergleichen darzustellen? Oder fängst Du da dann bereits mit dem Code an?

Namen von Attributen gehören in die Klassenbeschreibung. Namen lokaler Variablen interessieren nicht. In UML erst recht nicht.

Ich habe die Befürchtung, dass du dich grad in irgendwelche völlig unwichtigen Details verrennst und dabei völlig das Problem aus den Augen verlierst. Vergiss am besten erstmal die Sache mit dem UML.

[mutetella]

Wenn eine Methode das Vorhandensein bestimmter Attribute voraussetzt und du das dokumentieren willst, musst du eine entsprechende Schnittstelle definieren.

Wenn ich folgendes habe:

Code: Alles auswählen

class IrgendWas():
    class_attribut = 123

    def meth_ode():
        meth_attribut = 456

Wo besteht hier eine Schnittstelle für 'meth_attribut'? Ich kann innerhalb des UML-Klassensymbols lediglich 'class_attribut' als Attribut und 'meth_ode()' als Operation angeben. Wo gehört da 'meth_attribut' hin?

Namen lokaler Variablen interessieren nicht. In UML erst recht nicht.

Ist 'meth_attribut' so eine lokale Variable, die Du meinst? Ich habe mal wieder das Gefühl, überhaupt nix kapiert zu haben, vielleicht sollte ich doch lieber Zeitungen austragen oder so...

Ich habe die Befürchtung, dass du dich grad in irgendwelche völlig unwichtigen Details verrennst...

Von oben betrachtet mögen diese Details tatsächlich nicht so wichtig sein, mir helfen diese Dinge allerdings sehr, das Wesen einer Sache zu verstehen. Oft schon waren es nur Begrifflichkeiten, die bei mir Lichter angehen ließen...

Vergiss am besten erstmal die Sache mit dem UML.

Was würdest Du mir denn empfehlen, um ein Python-Programm bzw. Objekte und ihre Beziehungen zueinander darin darzustellen (ernst gemeinte Frage!)? Nur über den Code und ein paar Notizen dazu schaff' ich das nicht. Ich bin zum Glück keine 16 mehr...

Gruß
mutetella

[Pekh]

Vergiss am besten erstmal die Sache mit dem UML.

Was würdest Du mir denn empfehlen, um ein Python-Programm bzw. Objekte und ihre Beziehungen zueinander darin darzustellen (ernst gemeinte Frage!)? Nur über den Code und ein paar Notizen dazu schaff' ich das nicht. Ich bin zum Glück keine 16 mehr...

Neben UML gibts da z.B. OPM. Dort hast du Abläufe und Strukturen in einem Diagrammtyp kombiniert. Allerdings liegt der Fokus hier auf der Analyse und Modellierung von Systemen. Die konkrete Umsetzung in ein Programm kannst du dort nicht auf einen Blick ersehen. Wenn du allerdings zusammengehörige (programmiertechnisch betrachtet) Objekte und Prozesse farblich markierst, ist auch das kein Problem mehr.

UML ist für den "kleinen" Anwender schlicht zu kompliziert. Auch braucht man mehrere Diagrammtypen, um bestimmte Sachverhalte ausdrücken zu können. Für den Hausgebrauch würde ich dir deshalb empfehlen, eine eigene Notation zu entwickeln.

[Darii]

Ich kann innerhalb des UML-Klassensymbols lediglich 'class_attribut' als Attribut und 'meth_ode()' als Operation angeben. Wo gehört da 'meth_attribut' hin?

Wie schon mehrfach von mehreren Leuten gesagt gesagt: Nirgends, hat absolut nichts in UML zu suchen. Ist auch völlig unsinnig das Ding irgendwo zu notieren. Das ist ein Implementierungsdetail das kein Schwein interessiert. Wenn du es unbedingt Dokumentieren willst, schreib nen Kommentar in die Methode. meth_attribut ist auch kein Attribut, sondern eine lokale Variable.

Vergiss am besten erstmal die Sache mit dem UML.

Was würdest Du mir denn empfehlen, um ein Python-Programm bzw. Objekte und ihre Beziehungen zueinander darin darzustellen (ernst gemeinte Frage!)?[/quote]Zettel Blankopapier aus dem Drucker + Bleistift und versuche dir für dich selbst klar zu machen was was tut.

Evtl. hilft auch erstmal nen Buch, das dir die Grundbegriffe beibringt. Wenn du schon mit „Variable“ nichts anfangen kannst, wird das mit dem MVC erstmal nichts.

[BlackJack]

@mutetella: `meth_attribut` ist kein Attribut sondern ein lokaler Name. Als Attribut bezeichnet man Namen auf Objekten, auf die man über den Punkt-Operator zugreift. `self.meth_attribut` wäre also ein Attribut. Das müsste aber dann eher `self.instance_attribute` heissen. Dein Beispiel etwas abgewandelt:

Code: Alles auswählen

class SomeThing(object):
    class_attribute = 123
    
    def method(self):
        self.instance_attribute = 456
        local_name = 0
    
    method.meth_attribute = 789

Die letzte Zeile zeigt das, was ich mir unter einem Methoden-Attribut vorstellen würde.

An `local_name` kommt man von aussen nicht heran. Der Name existiert ja nicht einmal solange `method()` nicht gerade im Moment ausgeführt wird oder der Name Teil eines "closures" ist. Und es können auch gleichzeitig mehrere davon existieren, wenn die Methode rekursiv ist, oder von mehreren Threads aus gleichzeitig aufgerufen wird, oder in "closures".

Dein `meth_attribut` bzw. mein `local_name` gehören jedenfalls bei UML nirgendwo hin. Das ginge auch ein wenig am Ziel von UML vorbei. Das ist ja eher dazu da eine Übersicht über Softwaresysteme zu geben, die sich aus dem Quelltext nicht so einfach erschliesst, weil man dort durch den Quelltext immer nur kleine, sehr detaillierte Ausschnitte auf einmal sieht. Lokale Namen sind aber für eine Übersicht über die Architektur total irrelevant, denn die sind nach aussen ja gar nicht sichtbar. Wenn man ein System auf *der* Ebene betrachtet, braucht man auch keine Zeichnung um den Überblick zu bewahren, denn eine Methode sollte ja nicht allzu lang werden. Wenn man den Quelltext einer Methode sieht und dort den Überblick über die lokalen Namen verliert, dann ist dringend ein Refactoring der Methode angesagt.

Für Klassen und Objekte und ihre Beziehungen zueinander ist UML schon ganz brauchbar. Man merkt halt manchmal, dass es eigentlich für statische Sprachen gedacht ist; dann muss man sich etwas ausdenken wie man bestimmte dynamische Aspekte von Python darin abbildet. Zum Beispiel kann man Module als Klassen und Funktionen darin als "statische" Methoden auf UML abbilden und als Stereotype für die "Klasse" «module» angeben.

[mutetella]

@Pekh: Vielen Dank für den Tipp, das klingt gut, hab' gerade kurz "reingelesen"...

@BlackJack: Bedeutet das, dass ein Attribut letztlich auch "nur" der Name einer Variablen (ok, genau genommen der Verweis auf ein Objekt) ist, wobei mit der Angabe vor dem Punkt auf den Namensraum verwiesen wird?
Sollte dem so sein, weshalb kann ich dann in Deinem Beispiel innerhalb von method() nur auf 'method.meth_attribute', nicht aber auf 'meth_attribute' zugreifen, obwohl ich mich doch im richtigen Namensraum befinde?
Welcher Unterschied besteht zwischen 'local_name' und 'method.meth_attribute' während der Ausführung von method()?

Für Klassen und Objekte und ihre Beziehungen zueinander ist UML schon ganz brauchbar.

Letztlich bin ich ja auch nur auf der Suche nach fertigen Symbolen und deren Verwendungsweise um nicht mit OODraw oder ähnlichem selbst Kästchen zeichnen zu müssen... Dass lokale Namen in so einer Übersicht fehl am Platz sind, ist mir jetzt klar geworden. Es wird für mich wohl darauf hinauslaufen, dass ich, so wie Du sagst, UML-Symbole teils zweckentfremde, oder ich mich für Pekh's Tipp erwärme...

[BlackJack]

@mutetella: Ja, man kann Objekte auch als Namensräume ansehen. Der Unterschied zwischen `local_name` und `meth_attribute` ist der, dass sie eben nicht im selben Namensraum sind. `local_name` ist in einem Namensraum der selbst keinen Namen hat. Der wird zur Laufzeit erzeugt wenn die Methode aufgerufen wird und wieder zerstört wenn sie endet. ("Closures" seien an dieser Stelle der Einfachheit mal ausgenommen.) Während `meth_attribute` ein Attribut der Methode ist und nicht nur während des Aufrufs existiert, sondern solange das Objekt existiert auf dem das Attribut sitzt. Und das wiederum existiert solange die Klasse existiert, die existiert solange das Modul existiert, und das existiert in aller Regel bis das Programm endet und der Interpreter alle Objekte zerstört.

[mutetella]

`local_name` ist in einem Namensraum der selbst keinen Namen hat.

Wieder etwas, das man wissen muss... Ich war der Ansicht, dass SomeThing.method derselbe Namensraum ist, der während der Ausführung von SomeThing.method() besteht.
Auch auf die Gefahr hin, dass ich mich jetzt wieder als Nullchecker oute:
Welchen Sinn macht ein Methodenattribut? Die Methode existiert ja nur, solange die Klasse existiert. Warum dann nicht nur Klassenattribute?

[cofi]

Auch auf die Gefahr hin, dass ich mich jetzt wieder als Nullchecker oute:
Welchen Sinn macht ein Methodenattribut? Die Methode existiert ja nur, solange die Klasse existiert. Warum dann nicht nur Klassenattribute?

Wie dir BlackJack schon gesagt hat: Es gibt keine Methodenattribute.
Deine Fragen machen so gar keinen Sinn.

1. Es gibt Klassenattribute.
2. Es gibt Instanzattribute.
3. Es gibt lokale Namen.

Alle 3 haben ihren zweck, so sind 1) global fuer alle Instanzen dieser Klasse 2) lokal fuer _jede einzelne_ Instanz und 3) ueberhaupt nicht von aussen zugaenglich.

[BlackJack]

@cofi: Ich denke die Frage bezog sich auf Methodenattribute wie ich sie "definiert" habe, also Attribute auf Methoden.

Deine Auflistung könnte man noch weiter verkürzen auf 1. Instanzattribute und 2. lokale Namen, denn Klassenattribute sind ja auch nur Instanzattribute auf dem Klassenobjekt.

@mutetella: Was ist denn *die* Ausführung einer Methode? Eine Methode kann ja gleichzeitig mehrfach ausgeführt werden, sei es nun weil sie sich selbst rekursiv aufruft, oder weil sie aus mehreren Threads aufgerufen wird. Dann muss ja jeder Aufruf seine eigenen lokalen Variablen haben, sonst passieren seltsame Dinge, bzw. Rekursion würde nicht so funktionieren wie man das gerne hätte.

Attribute auf Methoden machen Sinn wenn man die Information halt nicht an die Klasse, sondern an die Methoden binden möchte. Zum Beispiel kann eine Methode dort Attribute dran binden, die über Aufrufe hinweg verfügbar sein sollen, mit denen man aber nicht den Namensraum der Klasse vollmüllen möchte.

Attribute die eben zu einer Methode gehören und nicht zur ganzen Klasse. Zum Beispiel die Dokumentation der Methode -- die Klasse und jede einzelne Methode kann ihr eigenes `__doc__`-Attribut besitzen.

[Darii]

Welcher Unterschied besteht zwischen 'local_name' und 'method.meth_attribute' während der Ausführung von method()?

'local_name' wird einfach direkt gelesen. Wie genau ist ein Implementierungsdetail des Python-Interpreters, und das passiert nicht zwangsläuftig dadurch, dass in irgendeiner Art und Weise noch der Name 'local_name' selbst vom Interpreter verwendet wird. 'method.meth_attribute' hingegen verwendet eine wohldefinierte Schnittstelle nämlich indem so etwas wie getattr(method, 'meth_attribute') aufgerufen wird.

Bedeutet das, dass ein Attribut letztlich auch "nur" der Name einer Variablen (ok, genau genommen der Verweis auf ein Objekt) ist, wobei mit der Angabe vor dem Punkt auf den Namensraum verwiesen wird?

Ganz klar nein. Wie BlackJack schrieb man kann es zwar so sehen, es ist aber nicht dasselbe. Attributaufrufe in Python sind vergleichbar mit dem Aufruf von gettern und settern in Java/C++. Mit Variablen haben die erstmal nichts zu tun. Siehe auch erster Absatz.