Einführung in die Arbeit mit CRC-Cards

Einführung in die Arbeit mit CRC Cards

Definition

CRC steht für:

• Class – Klasse
• Responsibility – Verantwortung
• Collaboration - Zusammenarbeit

Indizierte Karteikarte die ein Klasse beschreibt wie folgt:

• Eindeutiger Klassenname
• Liste aller Tätigkeiten/Aktionen für die diese Klasse verantwortlich ist
• Liste aller der Klassen mit denen eine Zusammenarbeit stattfindet bzw. die diese Klasse benötigt um die Aufgaben für die sie verantwortlich ist, erfüllen zu können

Historisches

1989 von Kent Beck und Ward Cunningham als Ansatz um objektorientierten Design zu unterrichten. Cunningham wählte den Ansatz über Karteikarten, weil er festgestellt hatte, daß OOD-Beginner die aus dem prozeduralen Lager kamen, ihre alten Kenntnisse mit dem OO-Ansatz vermischten. R. Wirfs-Brock und N.M. Wilkerson entwickelten die Technik weiter.

Syntax

Es gibt keine allgemein akzeptierte Syntax. Die einzigen notwendigen Elemente sind:

• Klassen-Name
• Eine Anzahl von Tätigkeiten die diese Klasse verantwortlich auszuführen hat

• Eine Anzahl von Klassennamen mit denen diese Klasse zusammenarbeitet

Das Grundmodell sieht wie folgt aus:

• Oberste Zeile: Klassenname

Darunter:

• Abgeleitete Klassen
• Übergeordnete Klassen
• Rest der Karte aufgeteilt in linke und rechte Hälfte Links: verantwortliche Tätigkeiten
• Rechts: Namen der Klasse mit denen diese zusammenarbeitet

Die Klassennamen bilden zusammen ein Vokabular das das zu lösende Problem hinreichend genau beschreibt. Gut gewählte Klassennamen erhöhen das Verständnis für das Modell. Die Liste der verantwortlichen Tätigkeiten dieser Klasse stellt die Fähigkeiten dieser Klasse dar als auch den Service den diese Klasse Anwendern bietet.

Die Bezeichnungen der verantwortlichen Tätigkeiten sollten immer kurz aber auch beschreibend sein und immer ein aktives Verb enthalten:

• Sucht Einträge
• Kennt Kontostand

Die Bezeichnungen der Klassen deren Zusammenarbeit eine Tätigkeit benötigt, werden genau gegenüber der Bezeichnung der Tätigkeit eingetragen. Dabei können dieselben Klassen mehrmals auf der Karteikarte auftreten

Drei wichtige Punkte zu beachten bei der Angabe der Klassen mit denen zusammengearbeitet werden soll:

• Die Zusammenarbeit gilt nur zur Erfüllung der verantwortlichen Tätigkeit und Zusammenarbeit impliziert, das die Klasse mit der zusammengearbeitet werden soll, eine verantwortliche Tätigkeitsbezeichnung hat, die die angeforderte Aufgabe erfüllt
• Zusammenarbeit wird nur dann aufgelistet, wenn auch wirklich eine Nachricht an die Klasse gesand wird mit der zusammengearbeitet werden soll. Grundsätzlich gilt, daß nur dann Zusammenarbeit angefordert wird, wenn die Erfüllung der Aufgabe wirklich eine Interaktion mit der anderen Klasse erforderlich ist. (3x3 kann jede Klasse selbst berechnen!)
• Zusammenarbeit wird immer nur in eine Richtung definiert, vom Initiator zum Zusammenarbeiter. Die angesprochene Klasse führt die geforderte Tätigkeit auch wirklich selber aus und gibt sie nicht weiter!

Die Rückseite der Karteikarte wird oft verwendet um die Attribute der Klasse festzuhalten oder um die Objekte der Klasse näher zu beschreiben

Warum CRC Cards ?

Die Methode ist:

• Einfach
• Keine bedrohliche Intelligenzanforderung
• Informell
• Positive Atmosphäre für kreative Prozesse

Aufgrund er Einfachheit erfolgt keine Überforderung bei Entwicklung eines Objektorientierten Modelles. Die Gruppendynamik unterstützt die Kreativität der Teilnehmer und führt zu einem effektiven Brainstorming mit guten, und vor allen Dingen, brauchbaren, Ergebnissen. CRC Karten fördern das Verständnis des Modells, sorgen für eine sinnvolle Verteilung der Aufgaben über alle Objekt hinweg.. Die physikalische Größe der Karten sorgt auch automatisch dafür, daß die Klassen nicht zu komplex werden. Karteikarten können überall verwendet werden, ohne Computer und außerhalb einer Büroumgebung. Sie sind anthropomorph (menschenähnlich) in der Hinsicht, das kein Computer den Gehalt (Essenz) der Interaktionen in der Weise interpretieren kann wie ein Mensch. Durch die Verwendung von Karteikarten werden Teilnehmer vermehrt zur persönlichen Auseinandersetzung mit dem Problem angeregt. Der wahre Wert von CRC Karten liegt in den auf Gruppen basierenden Sessions. Karteikarten sind billig zu kaufen oder selbst zu produzieren, leicht transportierbar, flexibel und immer arbeitsbereit.

CRC Card Session

Wie fängt man an?

Einer der wichtigsten Aspekte von CRC Cards ist nicht die Karte selbst, sondern die Erstellung der Karten innerhalb eines kreativen Prozesses

Eine Gruppe von Leuten die für die Modellierung und Lösung des Problems verantwortlich sind, treffen sich zu einer Session

Die abstrakte und kreative Natur der CRC Karten ermöglicht das Finden der besten Klassen und untersucht Szenarien bis in den letzten Winkel

Der einfache und informelle Ansatz dieser Technik macht die Teilnehmer schnell zu erfahrenen Anwendern des objektorientierten Ansatzes

Optimale Gruppengröße liegt bei 4-6 Teilnehmern

• Größere Gruppen als 6 verlangsamen den Prozess zu sehr durch Nebenkonversationen und dadurch enstehenden Informationsverlust

• Kleinere Gruppen können das Problem aufweisen, das sie nicht genug Wissen über alle Aspekte des zu lösenden Problems haben (die Lösung wird also zwangsläufig unvollständig)

Es sollte sich mindestens ein Experte in der Gruppe befinden der sich mit dem zu lösenden Problem bestens auskennt

Anforderungsdokument

• Anforderungskatalog mit allen Schnittstellen zur Umgebung des zu lösenden Problems
• Hinreichende Beschreibung des zu lösenden Problems
• Hinreichende Beschreibung der Grenzen des zu lösenden Problems

Die Session

Übersicht der Tätigkeiten

• Anforderungskatalog bearbeiten
• Klassen identifizieren
• Klassen in Karten umwandeln
• Tätigkeiten eintragen
• Zusammenarbeit zwischen Klassen festlegen

Jeder Teilnehmer ist verantwortlich für eine Anzahl Karten

• Er kennt seine Karten
• Ist verantwortlich für die Einträge
• Reagiert wenn er eine Message bekommt

Das Beispiel-Problem

Bibliothekssystem mit den Möglichkeiten

• Bücher ausleihen
• Bücher zurückgeben
• Bücher suchen

Die Applikation soll die Aufgaben einer technischen Bibliothek in einem größeren Unternehmen unterstützen. Die erforderlichen Aufgaben sind die Suche und Ausleihung von technischen Schriftstücken die in der Bibliothek verwaltet werden, Büchern, Videos und technischen Zeitschriften. Die Ausleiher haben eine eindeutige Personalnummer die mit der eindeutigen Materialnummer des Ausleihgegenstandes verknüpft wird bei Ausleihen und Rückgaben.

Jeder Ausleiher kann max. 5 Gegenstände ausleihen. Jeder Gegenstand kann für eine verschieden lange Zeit ausgeliehen werden (Bücher 4 Wochen, Zeitschriften 2 Wochen, Videos 1 Woche). Werden die Gegenstände zu spät zurückgegeben, dann wird eine Strafgebühr erhoben (Bücher 1 DM/Tag, Zeitschriften 3 DM/Tag, Videos 5 DM/Tag). Es wird nur etwas ausgliehen, wenn der Ausleiher keine überfälligen Gegenstände hat, weniger als 5 Gegenstände in Ausleihung hat und seine fälligen Strafgebühren kleiner als 100 DM sind.

Erstellen von Klassen

Das Finden der notwendigen Klassen ist der erste Schritt. Die Klassen werden in einem Brainstorming-Prozess ermittelt und aufgelistet bevor irgendwelche Karten erstellt werden. Dies ist ein erster Ansatz und verlangt nicht nach Vollständigkeit.

Brainstorming

Der Brainstorming-Prozess bestht darin, das eine Person alle Klassen aufschreibt die von den Gruppenmitgliedern vorgeschlagen werden. Es wird dabei keine Diskussion toleriert. Erfahrene Gruppen können schon während dieses Prozesses die Klassen filtern, aber besser ist es dies zu einem späteren Zeitpunkt zu tun.

Wo kommen die Namen der Klassen her??

Die Hauptquelle sind die Fachleute die in der Gruppe mitmachen. Leute die ihr Aufgabegebiet gut kennen kommen im allgemeinen mit einem ziehmlich kompletten Satz von Klassen daher. Diese Klassen beschreiben erstmal das definierte Aufgabengebiet. Später beim Design kommen noch Unterstützungsklassen hinzu.

Klassen können auch abgeleitet werden aus dem Anforderungsdokument

Filtern der gefundenen Klassen

Im nächsten Schritt werden die Klassen überarbeitet und Redundanzen gestrichen, fehlende Abstraktionen ergänzt und Relationen zwischen den Klassen festgehalten

Wichtig ist hier die Diskussion und die Übereinstimmung über eine kurze, prägnante Darstellung der Klasse, die später auf der Rückseite der Karte aufgeschrieben wird. Zum Beispiel könnte bei der Klasse Bücher stehen:

Menge von Objekten die Bücher der Bibliothek repräsentieren die ausgeliehen werden können.

Karten zuordnen

Wenn alle Klassen aufgeschrieben wurden, dann werden eine ungefähr gleiche Anzahl von Klassen auf die Teilnehmer verteilt und jeder Teilnehmer beginnt die Verantwortung für seine Klassen aufzunehmen. Wobei es sinnvoll ist solche Klassen einem Teilnehmer zuzuordnen deren Aufgaben er gut kennt. Die Teilnehmer schreiben dann auf die Karte die Namen der Klasse und auf die Rückseite die kurze Beschreibung. Jeder Teilnehmer liest dann die Daten seiner Karte vor und es muß Übereinstimmung über die Beschreibung herrschen.

Mögliches Ergebnis unseres Beispiel-Problems:

Bibliothekar
Das Objekt im System das die Benutzeranfragen zum Ausleihen, Rückgabe und Suche der Bibliothek-Objekte ausführt.

Benutzer
Die menschliche Person die die Bibliothek nutzt.

Ausleiher
Eine Menge von Objekten, die Benutzer repräsentieren, die Gegenstände aus der Bibliothek entliehen haben

Datum
Eine Menge von Objekten, die Datum-Werte im System repräsentieren

Ausleihbar
Eine Menge von Objekten, die die Gegenstände repräsentieren, die aus der Bibliothek entliehen werden können

Buch
Eine Menge von Objekten, die Bücher repräsentieren die entliehen werden können

Video
Eine Menge von Objekten, die Videos repräsentieren die entliehen werden können

Journal
Eine Menge von Objekten, die Zeitschriften repräsentieren die entliehen werden können

Superklassen und Subklassen

Es gibt unter den Experten keine Übereinstimmung darüber, ob diese Klassen am Anfang einer Session identifiziert werden sollen, am Ende oder überhaupt nicht. Wenn sich herausstellt, daß Klassen gleiche Eigenschaften haben, dann kann man diese in eine Superklasse gruppieren.

Verantwortliche Tätigkeiten (Responsibilities)

Wenn ausreichend Klassen identifiziert worden sind und die wirklich notwendigen und brauchbaren herausgefiltert wurden, dann ist es jetzt an der Zeit das Verhalten dieser Klassen festzulegen.

Einzelne Aufgaben die sich aus dem Anforderungskatalog ergebn oder die ganz offensichtlich zu einer Klasse gehören, können sofort auf die Karte geschrieben werden bevor ein Szenario gestartet wurde.

Zum Beispiel ist es ganz klar das der Bibliothekar zuständig ist für die Ausgabe und Annahme von Gegenständen der Bibliothek.

Attribute

Attribute können identifiziert werden aus dem Anforderungskatalog. Oftmals sind es Hauptwörter die im Text stehen und keine Klasse repräsentieren. Fälligkeitsdatum und Strafgeld sind Beispiele für solche Attribute. Diese Attribute können Klassen zugeordnet werden.

Szenarien

Wir kommen jetzt zum Herzstück einer CRC-Card Session, den Szenarios.

Wir beginnen jetzt, den Klassen verantwortliche Tätigkeiten zuzuweisen durch physikalisches verschieben der karten und blumenreicher Darstellung der jeweilige Aktion die wir gerade betrachten.

Szenarios sind detaillierte Beispiele der Funktion des Systems. Wobei mit Funktion hier kein prozeduraler Block gemeint ist, sondern ein einzelnes, sichtbares, überprüfbares Verhalten des Systems. Funktion entspricht in diesem Sinne einer Anforderung an das System. Für jede Funktion gibt es eine Anzahl möglicher Szenarien mit denen man untersuchen kann wie das system sich unter verschiedenen Annahmen (Parametern) verhält (verhalten würde/sollte).

Wo anfangen?

Wir sollten mit den einfachsten Szenarien einfach anfangen. Bezogen auf unser Beispiel:

Was passiert wenn Helmut Schmidt ein Video zurückbringt ‚Einführung in die Programmierung mit C++‘?

Wenn wir dann später zu den komplexeren und schwierigeren Szenarien kommen, dann haben wir bereits Tätigkeitsmerkmale auf die wir zurückgreifen können.

Richtlinien zur Durchführung von Szenarien

Szenarien sollten dynamisch und menschlich sein. Vor allen Dingen sollen sie Spaß bringen und kreativ sein. Die personen die eine bestimmte Karte verwalten sollten diese in die Luft halten und die Rolle einnehmen die der Kasrte entspricht. Sinn dieser Aktion ist die Darstellung des Objektorientierten Verhaltens. Wenn die Karte auf dem Tischliegt ist sie eine Klasse und wenn jemand sie hoch hält ist es ein instaziiertes Objekt.

Die Hauptszenarien bezogen auf das Beispiel-Problem:

• Ausleihen
• Rückgaben
• Ausnahmen

Ausleih- Szenario

Das erste Ausleih-Szenario ist einfach und präzise:

Was passiert wenn E.Mustermann , der weder Strafen zu bezahlen, noch irgendwelche anderen Bücher ausgeliehen oder irgend etwas überfällig hat, das Buch ausleiht ‚Effektive C++ Programmierstrategien‘?

Das Szenario wird definiert und schriftlich festgehalten (irgendjemand in der Gruppe muß sich als Sekretär zur Verfügung stellen). Jede Aufgabe die das System erfüllen soll, muß also als Szenario definiert und durchgespielt werden. Die Gruppe entscheidet wer für dieses Szenario angesprochen wird und entscheidet sich für den Bibiliothekar. Derjenige der die Bibliothekar-Karte hat ist also jetzt gefordert und schreibt in seine Responsibility-Spalte:

Ausleihen eines Buches

Dann wird überlegt wer denn für diese Aufgabe mit dem Bibliothekar zusammenarbeiten muß? Dazu muß erst überlegt werden ob diese Aufgabe in weitere Teilaufgaben zerlegt werden kann. Mögliche Teilaufgaben werden identifiziert von der Gruppe, schriftlich festgehalten und der Reihe nach abgearbeitet. In diesem Fall ist es:

Überprüfen ob der Ausleiher noch andere Gegenstände ausgliehen hat und Überprüfen ob der gewünschte Gegenstand ausleihbar ist.

Der Bibliothekar bittet also die Ausleiher-Klasse um Zusammenarbeit. Derjenige der die Ausleiher- Klasse hat schreibt also auf seine Karte unter Responsibility:

kann ausleihen

kennt ausgeliehene Bücher

Nach dem ersten Szenario haben folgende Karten Einträge:

Bibliothekar

• Ausgabe von Büchern an Benutzer – Ausleiher,Buch

Datum

• vergleich von Datumangaben – Datum

Ausleiher

• kann ausleihen – Buch
• kennt Menge der ausgeliehenen Bücher

Buch

• kennt Überfälligkeit – Datum
• markiert als ausgeliehen
• berechnet Fälligkeitsdatum
• kennt Fälligkeitsdatum
• kennt den Ausleiher
• weiß ob ausgeliehen oder nicht

Finden der Superklassen

Beim nächsten Szenario, dem Ausleihen eines Videos, gibt es nur wenig das vom ersten Szenario abweicht. Die Karte Video hat deshalb bis auf die Fälligkeitsberechnung, dieselben Einträge wie die Karte Buch. Es ist ganz einfach festzustellen, das Buch, Video und Journal gleiche Einträge haben. Diese können herausgenommen und einer Superklasse zugeordnet werden.

In Zusammenhang stehende Szenarien

Wenn alle Hauptszenarie durchgespielt worden sind, dann sollten Szenarie durchgespielt werden die mit den vorherigen Szenarien in Beziehung stehen. Zum Beispiel, wenn wir vorher ein Szenario durchgespielt haben mit der Ausleihung eines Buches, dann sollten wir jetzt das ausleihen von einem einem zweiten Buch durchspielen usw.

Ausnahme-Szenarien

Es sollten immer zuerst die Standard Situationen durchgespielt werden und danach die Ausnahmesituation. In unserem Beispiel wäre eine Ausnahmesituation der Fall, das jemand bereits 5 verschiedene Dinge ausgeliehen hat und jetzt noch etwas ausleihen möchte.

Finden neuer Klassen

Während des duchspielens der Szenarien wird sehr of festgestellt, das keine Klasse für eine bestimmte Aufgabe zuständig ist. Das führt zur Erstellung einer neuen Klasse mit dem gewünschten Verhalten.

Gruppieren von Karten

Die Karten sollten auf dem Tisch so geaordnet werden, daß sie ein visuelles Modell darstellen. Die Karten sollten so gruppiert werden, daß man die Beziehungen zwischen den Klassen einfach erkennen kann. Superklassen und Subklassen einer Klasse, sollten auf dem selben Stapel liegen wie die Klasse selbst.

Erweiterung des Basis-Prozesses

Die bisherige Darstellung macht den Kern einer CRC-Session aus. Eine Session kann kreativ und sinnvoll erweitert werden wie z.B. durch

• Liste der Szenarien
• Grafische Darstellung der Zusammenarbeit zwischen den Klassen

Weitergehende Literatur:

Empfohlen seien folgende Titel:

• Using CRC Cards - Nancy. M. Wilkinson
• Designing Object-Oriented Software - Rebecc Wirfs-Brock