Ein umfassender Leitfaden zur CRC-(Klassenverantwortung-Zusammenarbeit)-Modellierung
Basierend auf den grundlegenden Prinzipien der objektorientierten (OO) Analyse beschreibt dieser Leitfaden den CRC-Modellierungsprozess. Die CRC-Modellierung ist eine äußerst effektive, technologiearme Methode, die darauf abzielt, die Kommunikationslücke zwischen Entwicklern und Nutzern zu schließen, um sicherzustellen, dass Geschäftsanforderungen genau erkannt und verstanden werden, bevor Code geschrieben wird.
1. Schlüsselkonzepte: Die Anatomie einer CRC-Karte
Die CRC-Modellierung basiert auf Standard-Notizzetteln, die in drei unterschiedliche Abschnitte unterteilt sind. Jeder Abschnitt steht für ein zentrales Konzept der objektorientierten Gestaltung.
A. Klasse (oben auf der Karte)
Eine Klasse stellt eine Sammlung ähnlicher Objekte dar. Ein Objekt kann eine Person, ein Ort, eine Sache, ein Ereignis, ein Konzept, ein Bildschirm oder ein Bericht sein, der für das System relevant ist.
-
Namensregel: Verwenden Sie ein oder zwei Singularwörter (z. B. Kunde, nicht Kunden).
-
Beispiel: In einem Versand-/Bestandsverwaltungssystem gehören zu den Klassen Bestandsartikel, Bestellung, Bestellartikel, Kunde, und Oberflächenadresse.
B. Verantwortung (linke Spalte)
Eine Verantwortung ist alles, was eine Klasse weiß oder tut.
-
Was es weiß (Daten/Eigenschaften): Beispiel: Ein Kunde Klasse weiß ihren Namen, Kundennummer und Telefonnummer.
-
Was es tut (Verhalten/Methoden): Beispiel: Ein Kunde Klasse kann Produkte bestellen, Bestellungen stornieren und Zahlungen vornehmen.
C. Kooperationspartner (rechte Spalte)
Zusammenarbeit tritt auf, wenn eine Klasse Informationen oder Unterstützung von einer anderen Klasse benötigt, um eine Verantwortung zu erfüllen.
-
Beispiel: Ein Bestellung Objekt hat die Verantwortung, „Gesamtsumme berechnen“ zu übernehmen. Es weiß jedoch nicht, wie viel die Artikel kosten oder wie viele bestellt wurden. Daher muss es zusammenarbeiten mit Bestellposition (welche die Menge kennt) und Lagerartikel (welcher den Preis kennt), um die endgültige Gesamtsumme zu berechnen.
2. Das CRC-Modellierungs-Team
Eine erfolgreiche CRC-Sitzung erfordert spezifische Rollen, um sicherzustellen, dass der Prozess reibungslos abläuft und die Geschäftslogik genau erfasst wird.
-
Fachexperten für Geschäftsbereiche (BDEs): Die eigentlichen Benutzer des Systems (typischerweise 4 bis 5 Mitarbeiter vor Ort). Sie verfügen über das tägliche Geschäftswissen. Hinweis: Führungskräfte sind im Allgemeinen nicht ideal für CRC; sie eignen sich besser für hochrangige Anwendungsfälle.
-
Moderator: Leitet die Sitzung, erläutert die Methode, stellt relevante Fragen, stellt sicher, dass die Karten korrekt ausgefüllt werden, und leitet die Szenario-Tests.
-
Schriftführer(innen): 1 oder 2 Personen, die in der hinteren/Seitenreihe sitzen. Sie modellieren nicht aktiv, sondern dokumentieren die detaillierte Geschäftslogik und Regeln, die auf die kleinen Indexkarten nicht passen.
-
Beobachter: Auszubildende oder Interessenten, die in der hinteren Reihe sitzen und ohne Teilnahme zuschauen.
3. Der 6-Schritte-CRC-Modellierungsprozess
Schritt 1: Das Team zusammensetzen
Sammeln Sie 4–5 Frontline-BDEs, einen Moderator und 1–2 Protokollanten. Stellen Sie sicher, dass die Managementunterstützung gegeben ist, damit die Teilnehmer die notwendige Zeit aufbringen können.
Schritt 2: Den Raum organisieren
-
Schreibbare Flächen: Flipcharts oder Whiteboards zum Brainstorming und Prototyping.
-
Modellierungstisch: Ein großer, zentraler Tisch, auf dem die BDEs Karten platzieren und bewegen können.
-
Protokollantenplätze: Schreibtische, die außerhalb des Weges platziert sind, aber eine klare Sicht haben.
-
Materialien: Indexkarten, Marker und ein weicher, gummiartiger Ball (wird später für die Szenariotests verwendet).
Schritt 3: Brainstormen
Erzeugen Sie Ideen, ohne sie zu bewerten. Der Moderator stellt offene Fragen, um die geschäftlichen Anforderungen zu verstehen.
-
Beispiel-Fragen: „Für wen ist dieses System?“, „Welche geschäftlichen Anforderungen unterstützt es?“, „Wie können wir dies schneller/günstiger/besser machen?“, „Gibt es einfache Aufgaben, die wir automatisieren können?“
Schritt 4: Die Technik erklären
Der Moderator verbringt 10–15 Minuten damit, CRC-Konzepte zu erklären, wobei Definitionen prominent an der Wand angezeigt werden, und führt das Team durch die Erstellung einiger Beispielkarten.
Schritt 5: Iterative CRC-Modellierung
Die BDEs stehen oder sitzen um den Tisch herum und bauen das Modell iterativ auf:
-
Klassen finden: Verfolgen Sie das Geld, suchen Sie nach Berichten/Bildschirmen und identifizieren Sie sofort die 3–5 Hauptklassen.
-
Verantwortlichkeiten finden: Fragen Sie, was die Klasse weiß und tut.
-
Zusammenarbeit definieren:Identifizieren Sie, wer die fehlenden Informationen hält, die benötigt werden, um eine Verantwortung zu erfüllen.
-
Karten anordnen: Wichtiger Schritt.Karten, die häufig zusammenarbeiten, werden nah beieinander auf dem Tisch platziert. „Beschäftigte“ Karten kommen in die Mitte. Das physische Bewegen der Karten hilft dem Team, Beziehungen und Assoziationen visuell zu erfassen.
Schritt 6: Use-Case-Szenario-Tests (Die „Ballwurf“-Übung)
Dies ist eine Validierungsübung, bei der das Team die Abläufe des Systems „vorspielt“, um sicherzustellen, dass das Modell korrekt ist.
-
Ein Szenario aufrufen:Der Moderator beschreibt ein Anwendungsfall (z. B. „Kunde stellt eine Bestellung auf“) und wirft den weichen Ball an den BDE, der die anfänglich verantwortliche Karte hält (z. B. Bestellung).
-
Verantwortung festlegen:Die Gruppe bestätigt, dass die Karte die Aufgabe übernimmt. Falls nicht, aktualisieren sie die Karte oder erstellen eine neue.
-
Logik beschreiben:Der BDE, der den Ball hält, beschreibt dem Protokollführer die schrittweise Geschäftslogik (Pseudocode).
-
Zusammenarbeiten:Wenn der BDE Informationen von einer anderen Klasse benötigt (z. B. Lagerartikel), wirft er den Ball an den BDE, der diese Karte hält. Dieser BDE beschreibt dann seinen Teil der Logik.
-
Den Ball zurückgeben:Sobald eine Aufgabe erledigt ist, wird der Ball an die vorherige Person zurückgeworfen, bis er schließlich wieder beim Moderator landet, um das nächste Szenario zu starten.
4. Wie CRC in den SDLC passt
CRC-Modellierung existiert nicht im Vakuum; sie ist Teil eines umfassenderen objektorientierten Modellierungsprozesses, der großräumig sequenziell (von Anforderungen über Design bis hin zum Code) und kleinräumig iterativ (Hin- und Herspringen zwischen Modellen).
-
Detailgrad:CRC befindet sich in der Mitte. Sie beginnen einfach mit Anwendungsfälle und Benutzeroberflächen-Prototypen, wechseln Sie zur mittleren Detailstufe von CRC-Modelle, und schließen Sie mit der hohen Detailstufe von Klassendiagramme.
-
Ergebnisse treiben Ergebnisse: Use-Casediagramme werden durch Use-Cases dokumentiert, die wiederum durch Sequenzdiagramme dokumentiert werden, die letztendlich den Quellcode erzeugen. CRC-Modelle fließen direkt in die Erstellung von Klassendiagrammen ein.
5. Best Practices und Tipps für den Erfolg
-
Senden Sie einen Tagesordnungspunkt: Verteilen Sie eine Tagesordnung ein paar Tage im Voraus, damit die BDEs sich vorbereiten können.
-
Definieren Sie sichtbar: Befestigen Sie eine große CRC-Karten-Anordnung und deren Definitionen an der Vorderseite des Raums.
-
Verwenden Sie Fachbegriffe: Vermeiden Sie fachliche Fachsprache; verwenden Sie genau die Wörter, die die BDEs in ihrer täglichen Arbeit verwenden.
-
Bleiben Sie einfach: Werkzeuge für CRC sind nur optional. Notizzettel sind billig, leicht transportierbar und äußerst effektiv.
-
Erwarten Sie Prototypen: Das Skizzieren von Bildschirmen und Berichten auf Flip-Charts während der Sitzung hilft den Benutzern, das System visuell zu erfassen.
-
Planen Sie mehrere Tage: Große Systeme erfordern mehrere Sitzungen. Das ist normal und notwendig.
-
Holen Sie sich die Unterstützung der Führungsebene: Stellen Sie sicher, dass die Führungsebene den Wert der Modellierung vor der Programmierung versteht.
-
Richten Sie sich an die Front-Line-Mitarbeiter: CRC ist sehr detailliert und funktioniert am besten mit täglichen Anwendern, nicht mit oberen Führungskräften.
6. Vor- und Nachteile
Die Vorteile
-
Experten führen die Analyse durch: Die Menschen, die die Arbeit tatsächlich ausführen, erstellen das Modell.
-
Hohe Akzeptanz durch die Benutzer:Aktive Beteiligung erhöht die Benutzerzufriedenheit und das Eigentumsgefühl.
-
Beseitigt Barrieren:Benutzer und Entwickler arbeiten Seite an Seite.
-
Einfach und nicht bedrohlich:Es sind einfach nur Indexkarten. Benutzer werden durch komplexe Softwarewerkzeuge nicht eingeschüchtert, und sie fühlen sich nicht bedroht, dass ihre Arbeit durch eine „Maschine“ automatisiert wird.
-
Kostengünstig und transportabel:Kostet ein paar Dollar und passt in eine Aktentasche.
-
Nahtloser Übergang:Passt perfekt zu Prototypen und führt direkt zu formalen Klassendiagrammen.
Die Nachteile
-
Bedrohlich für einige Entwickler:Einige Entwickler glauben irrtümlicherweise, dass ihr technisches Wissen das geschäftliche Wissen der Benutzer übertrifft.
-
Die Terminplanung ist schwierig:4-5 Schlüsselbenutzer gleichzeitig in einem Raum zu versammeln erfordert vorherige Planung.
-
Die Karten sind begrenzt:Ein Stapel von Indexkarten ist für die meisten Organisationen kein akzeptabler formeller Liefergegenstand. CRC muss durch formale Anwendungsfälle, Prototypen und Klassendiagramme ergänzt werden.
Fazit
Das endgültige Ziel der Anwendungsentwicklung ist es,Geschäftsprobleme zu lösen, nicht, um die intellektuelle Neugier eines Entwicklers mit neuer Technologie zu befriedigen. CRC-Modellierung zwingt Entwickler dazu, mit Benutzern zusammenzuarbeitenanstatt gegen sie zu arbeiten. Durch die Nutzung einer technisch einfachen, hochkooperativen Umgebung können Teams Geschäftsanforderungen genau erfassen, validieren und verfeinern, bevor überhaupt ein einziger Codezeile geschrieben wird.Benutzer, anstatt gegen sie zu arbeiten. Durch die Nutzung einer technisch einfachen, hochkooperativen Umgebung können Teams Geschäftsanforderungen genau erfassen, validieren und verfeinern, bevor überhaupt ein einziger Codezeile geschrieben wird.
