UML: Unterschied Aggregation-Assoziation

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Antworten
T.T. Kreischwurst
User
Beiträge: 52
Registriert: Dienstag 2. Februar 2016, 10:56

Liebes Forum,

ich bin Python Neuling und mache gerade ein Redesign eines kleinen Programms, das ich zu Übungszwecken geschrieben habe. Dazu mache ich (ebenfalls zu Übungszwecken) ein UML-Diagramm zur sauberen Planung. Dazu folgende Frage:
Mir ist der theoretische Unterschied zwischen einer Aggregation und einer Assoziation durchaus klar. Was ich mir nicht vorstellen kann ist, wie sich das konkret in der Programmierung (im Python-Code) auswirkt. Kann mir das jemand erklären? Danke!
DasIch
User
Beiträge: 2718
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

Damit es sich auswirkt müsste man UML nutzen. Letzteres ist weder sonderlich sinnvoll noch praktikabel im Kontext von modernen Entwicklungsprozessen.
BlackJack

@T.T. Kreischwurst: Eine Assoziation kannst Du auch zeichnen wenn die Objekte keine Referenz halten, also zum Beispiel können Objekte a und b assoziiert sein, weil eine Methode von a Objekt b als Argument entgegen nimmt oder als Rückgabewert liefert. Ansonsten betritt man bei der Unterscheidung eine Grauzone. Jede Aggegation könnte man auch als Assoziation zeichnen.

Es gibt Leute die finden Assoziation überflüssig/”gefährlich” und verwenden sie gar nicht. Um nicht ständig über die Frage nachdenken zu müssen ob ein Objekt tatsächlich ”Bestandteil” eines anderen ist, oder eher eine lockerere Verbindung besteht. Also zum Beispiel könnte man bei einem Mietwagen der aus Rahmen, Motor, Rädern, Sitzen, …, und einem Fahrer-Objekt ”besteht”, sagen das die ganzen Autoteile-Objekte Aggregation sind, und der immer wieder ausgetauschte Fahrer nur eine Assoziation. Kann mir vorstellen, dass so etwas in Teams zu lustigen ”Bikeshed”-Diskussionen führen kann. :mrgreen:
Benutzeravatar
Hyperion
Moderator
Beiträge: 7478
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

DasIch hat geschrieben:Damit es sich auswirkt müsste man UML nutzen. Letzteres ist weder sonderlich sinnvoll noch praktikabel im Kontext von modernen Entwicklungsprozessen.
Da pauschalisierst Du zu hart! Ich halte es mit Eric Evans, der in seinem Klassiker "Domain Driven Design" so schön anmerkt, dass man stets ein zum Gesamtkontext passendes und funktionierendes Modellierungsmodell nutzen sollte. Das kann ein "abgespecktes" UML sein; denn mal ehrlich: zeichnest Du nie ein paar Kästen für Klassen und verbindest diese mit Strichen? Ist nicht mehr als ein Graph und wird einem bereits in der Schule in Geschichts-, Bio. oder gar Erdkundebüchern für alles mögliche näher gebracht. (Kasten mit Begriff, Linie mit Pfeil zu nem anderen, fertig ist die Beziehung) Natürlich ist 100% pures UML insofern sinnfrei, als dass es keiner beherrscht und man die Feinheiten, die es verlangt, auch erst während des Codens festlegen kann oder durchaus auch aufgrund der Frameworkauswahl fix definiert sind. Zudem kann niemand solche Modell aktuell halten; da braucht es dann übergewichtige Werkezuge wie Rational Rose o.ä. furchtbares. Aber in Ansätzen kann man das zum Gewinnen eines Überblicks schon benutzen.

Und sich zu überlegen, welches Objekt eine Referenz zum anderen hält, ist oftmals hilfreich bei der Modellierung, um Entitäten und die Aggregate zu identifizieren.
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
DasIch
User
Beiträge: 2718
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

Natürlich kann eine visuelle Darstellung von Algorithmen, Datenstrukturen und der Code Struktur zur Kommunikation hilfreich sein. UML ist aber nicht nur eine visuelle Darstellung von Klassen und wie sie zueinander stehen. Es versteht sich nicht als visuelle Darstellung die begleitend irgendwelche Erklärungen beschreibt. UML maßt sich an selbst komplett und vollständig möglichst alles präzise zu beschreiben.

UML ist mehr als nur begleitende Diagramme in einem Lehrbuch, UML ist der Vesuch den gesamten Text durch Diagramme zu ersetzen. Natürlich sind Diagramme nützlich aber nicht immer sondern nur manchmal.
T.T. Kreischwurst
User
Beiträge: 52
Registriert: Dienstag 2. Februar 2016, 10:56

Danke für eure Antworten! Blackjack hat es ganz gut erklärt - ich will mich da gar nicht auf eine UML-Grundsatzdiskussion einlassen, dafür kenn ich mich zu wenig aus. Mir ist klar, dass das, was ich da treibe, nur am Rande mit "echtem" UML zu tun hat. Mir geht es auch eher darum, prinzipiell mal ein Diagramm zeichnen zu lernen, das für andere Leute die Idee meines Programmes sichtbar macht UND vor allem mir einen Plan/Überblick gibt, BEVOR ich zu coden anfange. Bisher lief das eher chaotisch ab: ich schreib einfach mal irgendwas, fummel solange rum, bis es funktioniert und schreib später irgendwie ne Klasse oder Funktion hinzu... Wozu das führt, dürfte klar sein. Daher diesmal mit etwas mehr Vorausplanung. :mrgreen:
Insofern trifft
Und sich zu überlegen, welches Objekt eine Referenz zum anderen hält, ist oftmals hilfreich bei der Modellierung, um Entitäten und die Aggregate zu identifizieren.
genau mein Ziel. Perfektion ist nicht angestrebt, und die Info, dass es sich im konkreten Code nicht so 100% niederschlägt, finde ich beruhigend.
Antworten