Generalised Role Classes

Aus THM-Wiki
Wechseln zu: Navigation, Suche

Inhalt dieses Artikels ist es das Analysemuster Generalized Role Classes darzustellten. Die Art der Darstellung von Mustern in der Software-Entwicklung ist durch die verschiedenen Abschnitte (wie Name, Intent usw.) vorgegeben. Durch diese Vorgaben der Struktur der Darstellung ist sichergestellt das Muster vom Leserkreis einfach aufgenommen und leicht katalogisiert werden können. Analysemuster wurden durch das Standardwerk von Martin Fowler (siehe References) eingeführt. Mittlerweile gibt es sicher mehrere hundert Analysemuster welche in Websiten nach verschiedenen Kriterien katalogisiert sind. In den verschiedenen Analysemustern ist die Modellierungserfahrung von Domainenmodellierern aus vielen Software-Projekten extrahiert und mir dem Anspruch als Muster zu dienen verfügbar gemacht worden.

Das hier beschrieben Analysemuster Role Class Generalization geht auf den Artikel von Francis G. Mossé (siehe References) zurück. In diesem Artikel werden fünf verschiedene Muster zur Modellierung von Rollen vorgestellt.


Name

Generalised Role Classes, dieses Analysemuster wird auch als Role Class Generalization bezeichnet

Intent

Ein Model das es einer Klasse erlaubt in mehreren Rollen aufzutreten und den Zugriff auf Methoden der Klasse ohne Delegation gewährleistet.

Context

Das im Artikel von Mossé beschriebene Beispiel ist eine Firma die im Bezug auf Produkte sowohl als Kunde als auch Käufer auftreten kann. In Abbildung 1 ist ein entsprechendes Klassendiagramm des Beispiels wiedergegeben.

Ein anderes Beispiel könnte ein Mitarbeiter innerhalb eines Unternehmens sein. Oft sind Mitarbeiter zum Beispiel in Consulting Unternehmen zu einem gewissen Anteil ihrer Arbeitszeit verschiedenen Rollen, wie Teammanager oder Business Consultant zugeordnet. Am Mitarbeiter selbst hängen oft Eigenschaften wie Verfügbarkeit oder Gehalt. Wird in einem konkreten IT Projekt ein Business Consultant gesucht so muss über eine Assoziationsbeziehung zwischen den verschiedenen Klassen auf die Verfügbarkeit und das Gehalt zurückgegriffen werden.

Benutzt man das Role Classes Analysemuster so muss diese Informationsbeschaffung wiederholend durch Implementierung von Delegationsmethoden gelöst werden. Das Generalized Role Classes Muster bietet hier eine Lösung.

Problem

Es gibt mehrer Möglichkeiten das Auftreten einer Person in mehreren Rollen zu modellieren. Eine intuitive Möglichkeit wäre eine abstrakte Basisklasse Mitarbeiter mit zwei abgeleiteten Klassen Teammanager und BusinessConsultant zu modellieren. Dies ist für den Anwendungsfall eines Consulting Unternehmens jedoch nicht ausreichend, da ein Mitarbeiter dort mehrere Rollen eingesetzt wird.

Eine andere Möglichkeit wäre die Verwendung des Role Classes Musters. Diese erlaubt durch Implementierung von Delegationsmethode auf Infomationen der Klasse Mitarbeiter zuzugreifen. Ein Problem ist hier die Anzahl der entstehenden Delegationsmethoden die gleiche Codefragemente enthalten werden. Wir suchen aber eine Möglichkeit bei der wir die Benutzung von Delegationsmethoden vermeiden können.

Solution

Im Folgenden stellen wir die Lösung des im Problem Abschnitt beschriebenen Problems dar. Das eingefügte Klassendiagram in Abbildung 1 bezieht sich aus das im Mossé Artikel benutzte Beispiel eines Unternehmens das in verschiedenen Rollen auftreten kann.

Abbildung 1: Das Genaralized Role Classes Muster (entnommen aus Mossé Artikel)

Entsprechend des Musters in Abbildung 2 entspricht die Klasse Mitarbeiter der BaseClass aus dem Klassendiagramm. Die Klasse MitarbeiterImProjektRolle entspricht der AbstractRole. Die Methoden 'getVerfuegbarkeit' und 'getGehalt' werden in dieser abstrakten Klasse implementiert. Sie sind notwendig um zu entscheiden, ob ein Mitarbeiter in einem konkreten Projekt z.B. in der Rolle 'Business Consultant' eingesetzt werden kann. Durch die abstrakte Klasse die zwischen den konkreten Rollen Teammanager oder Business Consultant und der Klasse Mitarbeiter eingefügt wurde (vergleiche mit Role Classes Muster) gibt es einen Ort an dem diese Funktionaliät an einer Stelle implementiert werden kann, wobei die abgeleiteten Rollenklassen direkten Zugriff auf diese Methoden haben.


Abbildung 2: Klassendiagramm eines Beispiels welches das Genaralized Role Classes Muster verwendet (entnommen aus Mossé Artikel)

Strengths and weaknesses

Der Vorteil bei der Anwendung diese Muster ist das kein duplizierter Sourcecode für die Delegationsmethoden geschrieben werden muss und Wartungsänderungen an einer zentralen Stelle innerhalb der AbstractRole Klasse durchgeführt werden können. Der Nachteil der Musters besteht darin das keine neuen Rollen während der Laufzeit erstellt werden können. Gibt es im Unternehmen eine neue definierte Rolle, z.B. Bid-Manager, so muss eine entsprechende Unterklasse 'BidManager' implementiert werden. Mit dem Accociation Class Role Muster kann diese Beschränktheit aufgehoben werden.

References

  • Martin Fowler, Analysis Patterns: Reusable Object Models, Addison-Wesley, ISBN 0201895420, An introduction to object-oriented analysis with conceptual models