Ein wichtiges Thema ist ein nicht so super bekanntes, aber für den fortgeschrittenen

Entwickler trotzdem sehr wichtiges Thema namens Collaboration Based Design, manchmal auch

Rollenmodellierung genannt. Was meinen wir damit? Erstmal vielleicht Definitionen. Collaboration

Based Design ist einfach eine Art und Weise objektorientierten Entwurf zu beschreiben,

also wohl aktiv im Gedanken zu erarbeiten einen Entwurf und wie dann auch zu beschreiben.

Notationen kommen noch. Es ist also keine Programmiermethodik. Sie ist aber so nah an

der Programmierung dran, dass wir sehen werden, wie wir das Ganze auf Programmierung direkt

abbilden können. Die Kernidee von Collaboration Based Design ist, dass objektorientierte Designs

aus einer Menge überlappender Collaborations, also Zusammenarbeit von Objekten bestehen. Ein

anderes Synonym ist praktisch das Rollenmodell. Die Idee einer Collaboration ist, dass es die

Beschreibung, also die Beschreibung aller Collaboration ist eben die Beschreibung,

wie Objekte, nicht die Klassen, wie Objekte zur Laufzeit miteinander gemeinschaftlich eine

Aufgabe sich erarbeiten. Einfassendes Beispiel Beobachter und beobachtetes Objekt. Es gibt

ein Objekt im Beobachtermoster, wie Sie kennen, das Subject oder Observable oder wie auch immer

sind unterschiedlichen Anwendungen des dahinterstehenden Entwurfs, das heißen mag.

Also ein Objekt, das Zustandsveränderungen per Notifikation oder Event hinausschickt an die

beobachtenden Objekte. Da findet also ein Zusammenspiel statt zwischen einem beobachteten

Objekt und mehreren beobachtenden Objekten. Das sind die Rollen beobachtet und beobachtend.

Und diese Art von und das beides zusammen ist dann das Rollenmodell oder die Collaboration.

Das soll heißen, eine Collaboration versucht einen über das einzelne Objekt hinausgehende

Entwurfsperspektive zu haben, wo die Interaktion, eben die Collaboration mehrerer Objekte über

Rollen beschrieben wird. Und zwar nicht nur, indem man einfach die Rollen auflistet,

sondern indem man sagt, wie der Zusammenhang zwischen diesen Objekten, die Rollen spielen,

ist. Damit haben wir dann auch schon gesagt, naja, eine Collaboration besteht somit mindestens mal

wohl aus zwei Rollentypen, also Spezifikationen, die sagen, was ist denn das Verhalten eines

Objektes innerhalb eines Zusammenspiels mit anderen Objekten. Wenn ich das beobachtete Objekt bin,

dann bin ich halt jenes Objekt, das Zustandsnotifikation, Events hinausschickt. Also habe

ich da irgendwie Funktionalität, das zu tun. Weiterhin habe ich vielleicht Funktionalität,

je nachdem wie man es implementiert, aber häufigerweise habe ich die Funktionalität,

die Beobachter sich registrieren zu lassen. Also Send Event oder Update, eine Methode wird es geben,

und Register Observer, also registriere den Beobachter und unregistriere ihn. Genauso wird

der Beobachter auf der anderen Seite das andere Objekt in der Rolle Beobachter eine Methode haben,

wie Nimmzustandsänderungsnotifikation entgegen, auch Update oder Receive Event oder wie auch immer.

Oder mal Listener in Java, weiß gar nicht, wie es da heißt. So, das heißt, wir haben also Rollen,

von denen mehrere zusammenkommen, das Objekteverhalten beschreiben, das gesamte nennt man

Collaboration. Und weil wir modellieren, müssen wir halt konzeptuell unterscheiden zwischen,

es gibt die Beschreibung und es gibt die konkrete Ausprägung zur Laufzeit. Somit haben wir in der

Beschreibung sowas wie Rollentypen mit Methoden und zur Laufzeit haben wir Objekte, die sich

konform zu diesen Rollentypen verhalten. Wir werden noch sehen, wie das auf Klassen abbildet.

Im Augenblick hat das aber erstmal gar nichts mit objektorientierten Klassen zu tun. Also haben wir

dann jetzt Collaborations und natürlich Kern vom Ganzen sind immer die Objekte des modellierten

Systems in der Software abgebildet. Objekte spielen Rollen. Der Fokus war jetzt gerade zu sagen,

für einen Zweck arbeiten Objekte zusammen und ein Objekt spielt dann eine Rolle in dieser Zusammenarbeit.

Gleichzeitig ist aber ein Objekt ja häufig in verschiedenen Kontexten tätig und diese

unterschiedlichen Kontexte werden dann über unterschiedliche Collaborations abgebildet.

So ist ein Objekt in der Lage Zustandsnotifikationen auszusenden und gleichzeitig ist es vielleicht

ein Kindknoten in einer Objekthierarchie. Das heißt wir werden dann sehen, wie sich mehrere

Collaborations überlagern und zusammengenommen machen sie einen objektorientierten Entwurf aus.

So leider fange ich ein bisschen abstrakt an. Die Beispiele kommen dann gleich. Was ist denn

hier der Wert des Ganzen? Naja, wir brechen einen Entwurf auf seine Bestandteile runter. Die