CRC-Karten – ein hilfreiches Kartenspiel für Analytiker

Nach den letzten beiden Teilen der Blogserie zu unterstützenden Techniken bei der Anforderungsermittlung, die sich den Themen Audio- und Videoaufzeichnungen und Mind-Mapping gewidmet haben, beschäftigen wir uns heute mit einer der weniger alltäglichen unterstützenden Techniken: den CRC-Karten. Sie sind eine im wahrsten Sinne des Wortes „greifbare“ Technik zur Unterstützung objektorientierten Denkens und haben es immerhin in den CPRE Foundation Level Lehrplan geschafft.

Entstanden sind sie in den späten 80er Jahren, als die beiden US-Amerikaner Kent Beck und Ward Cunningham [KB/WC89] nach einer Methode gesucht haben, um Studenten die Objektorientierte Programmierung näher zu bringen. Ergebnis dieser Bemühungen war die CRC-Karten-Technik (CRC = Class Responsibility Collaboration). Mit den Jahren wurde diese Technik von anderen Autoren weiter verfeinert und nahm auch Einzug in die Anforderungsermittlung.

Das Arbeiten mit CRC-Karten ist ideal für das Ermitteln von Fachklassen, insbesondere bei größeren Systemen mit vielen Daten und komplexen Datenstrukturen. Es stellt einen stark objektorientierten Ermittlungsansatz dar und dient der einfachen Entwicklung eines Klassendiagramms. Die CRC-Karten-Technik ist für Einzelpersonen geeignet, oder kann in Gruppen bis zu 6 Personen eingesetzt werden. Es sollte allerdings mindestens ein Experte dabei sein, der objektorientiertes Denken in Form eines Klassendiagramms beherrscht. Das Format der Karten erzwingt eine knappe Ausdrucksweise und sorgt dafür, dass die Klassen nicht zu komplex werden. Zudem sind die Karten handlich und immer einsatzbereit.

Aufbau von CRC-Karten

Vorab: es gibt keine allgemein vorgegebene Syntax, wie eine CRC-Karte beschriftet wird. Es existieren also unterschiedliche Ausprägungen von CRC-Karten.

Zumindest enthalten sie aber die folgenden, bereits im Namen der Technik abgekürzten, Elemente (CRC). Diese werden auf eine Karteikarte im Querformat geschrieben:

Class:                Klasse bzw. Klassenname.

Responsibility:   Verantwortung, d.h. die Tätigkeiten, die diese Klasse verantwortlich auszuführen hat.

Collaboration:    Zusammenarbeit, d.h. die Klassennamen, mit denen diese Klasse zusammenarbeitet.

Zuerst wird oben in die Mitte der Klassenname notiert. Der Rest der Karte wird mit einer Linie in eine linke und eine rechte Seite unterteilt. Auf die linke Seite werden die Responsibilities, sprich die Tätigkeiten und Verantwortlichkeiten, der oben in der Mitte stehenden Klasse notiert. Die rechte Seite wird mit den Collaborations versehen, also den Namen der Klassen, die mit der Klasse dieser Karte zusammenarbeiten oder in einem direkten Verhältnis zu ihr stehen.

Neben dieser ursprünglichen Form haben sich einige Erweiterungen der CRC-Karten entwickelt. So kann man unterhalb des Klassennamens auch über- oder untergeordnete Klassen notieren. Weiterhin können auf der Rückseite die Attribute der Klasse und/oder deren Definition vermerkt werden.

Die Klassennamen sollten gut gewählt werden, damit die Anforderungen, bzw. die zu lösenden Probleme gut beschrieben werden können und die Verständlichkeit des entstehenden Modells gewährleistet. Dann kann von den Klassennamen auch leicht ein Glossar abgeleitet werden.

Die Tätigkeiten (linke Seite) einer Klasse stellen die Fähigkeiten dieser dar, also den Dienst, den diese Klasse Anwendern oder anderen Klassen anbietet. Die Beschreibung dieser Tätigkeiten sollte immer kurz sein und ein sinnvolles Verb enthalten; z.B. „Einträge suchen“.

Auf der rechten Seite werden nun weitere Klassen eingetragen, die direkt mit den von der betrachteten Klasse angebotenen Tätigkeiten auf der linken Seite in Verbindung stehen bzw. durch diese entstehen. Dabei können dieselben Klassen auch mehrmals auf einer Karteikarte auftreten, sofern sie bei mehreren Tätigkeiten beteiligt sind.

Einsatz von CRC-Karten in der Anforderungsermittlung

Insbesondere beim Einsatz von Brainstorming als Ermittlungstechnik im RE kann man CRC-Karten als unterstützende Technik einsetzen. Mittels der definierten Klassen kann man sehr schnell die zentralen Begriffe eines Systems erkennen und sammeln. Durch die Zusammenhänge der Klassen ergeben sich dann die Methoden, die wiederum zur weiteren Nutzung der Daten in einem Klassendiagramm herangezogen werden können. Auch bei einem Interview können im Vorfeld erstellte CRC-Karten als Diskussionsgrundlage dienen, um weitere oder detailliertere Anforderungen an das System zu ermitteln.

Vorteile von CRC-Karten in der Anforderungsermittlung

Da es sich um einen sehr objektorientierten Ermittlungsansatz handelt, der sich primär mit Daten befasst und erst in zweiter Linie auf die Funktionen des Systems eingeht, können mit ihm leicht Stakeholder begeistert werden, die objektorientiertes Denken gewohnt sind oder sehr datenorientiert denken. Eine große Stärke der Technik ist, dass sie besonders haptisch veranlagte Menschen anspricht: Die Probleme (Daten) können „in die Hand genommen“, analysiert und in Beziehung gesetzt werden.

Zudem findet man sehr früh die zentralen Begriffe des Fachgebietes und erhält in einer sehr frühen Phase ein umfangreiches Glossar.

Schattenseiten und Schwierigkeiten

Sofern den involvierten Stakeholdern objektorientiertes Denken sehr fremd ist, benötigt dieser Ansatz eine sehr stringente Moderation. Es ist für viele Stakeholder sehr ungewohnt, einem in der Realität leblosen Objekt (wie z.B. einem Leihobjekt einer Bibliothek) Verantwortlichkeiten zuzuordnen (z.B. seinen Reservier-Status zu überwachen), die dieses Realweltobjekt nicht wahrnimmt, der objektorientierten Denkweise nach aber übernimmt.

Entscheiden Sie selbst, ob CRC-Karten für Sie eine geeignete Technik sind, um Sie bei der Ermittlung von Anforderungen zu unterstützen.

Im vierten Teil unserer Serie erwartet Sie noch ein weiteres „Kartenspiel“: das Card-Sorting. Hierbei handelt es sich um eine Technik aus dem Usability Engineering, das uns auch bei der Anforderungsermittlung gute Dienste leisten kann.

Quellennachweis:

[KBWC89]                   Kent Beck / Ward Cunningham: „A Laboratory for Teaching Object-Oriented Thinking“, OOPSLA`89 Conference 1989 New Orleans, Lousiana
Link:   http://c2.com/doc/oopsla89/paper.html

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.


× fünf = 10