Presentazione delle CRC Cards

Abstract
In questo articolo presentiamo le CRC Cards, introdotte nel 1989 da Kent Beck e Ward Cunningham.

Benché oggi UML sia la metodologia più usata (e forse abusata) per l'analisi ed il design software, esistono molte altre strade che sono state sviluppate a questo scopo.

Nel 1989 l'UML non era ancora nato, e la difficoltà maggiore era introdurre l'OOP presso quegli sviluppatori che venivano da un'ottica prettamente procedurale.

La difficoltà maggiore è che l'OOP fonde tra loro diverse idee e concetti in modo sinergico, per cui la curva di comprensione iniziale può sembrare accettabile.
Poi però quando si tenta di usare quanto è stato acquisito, si vede che non è facile capire dove (e quando) è il caso usare l'ereditarietà, l'incapsulamento o le aggregazioni...

Le CRC Cards sono uno strumento semplice, ma che aiutano ad abbozzare rapidamente un domain model e che si servono di pochi concetti mutuati dallo sviluppo della programmazione ad oggetti.
Kent Beck e Ward Cunningham le introdussero nel 1989^[1]. Una CRC cards è grande 4 x 6 pollici, cioè circa 10,2 x 15,2 cm. Come vedremo, le ridotte dimensioni delle "card" sono una delle loro caratteristiche salienti.

Nella programmazione procedurale classica, si focalizza l'attenzione sui processi, i flussi di dati ed il modello dei dati.
Parallelamente nelle CRC Cards si sposta l'attenzione sul nome della classe, le sue responsabilità (indicate con brevi frasi "verbo-complemento oggetto") e le altre classi con cui collabora.

Si inizia prendendo un certo numero di card vuote, che possono essere appiccicate su di una lavagna (tipo post-it).

I partecipanti alla discussione iniziano definendo gli "oggetti" dell'analisi. Per esempio per un sistema di controllo degli ascensori avremo la cabina dell'ascensore, la pulsantiera, il motore dell'argano.
Definite le CRC card si può continuare la discussione, scrivendo sui foglietti le responsabilità. Per esempio la pulsantiera deve "ricevere" dall'utente il piano di destinazione, mentre deve mostrare il piano corrente. Deve inoltre comunicare la destinazione all'argano.
Allo stesso modo, la cabina deve comunicare in qualche modo alla pulsantiera il piano corrente (magari grazie a dei sensori elettro-meccanici) e l'argano deve collaborare con la cabina in qualche modo.
Una volta definite le responsabilità e chi-collabora-con-chi, si dispongono i fogli in modo che le card (entità) che collaborano in modo stretto tra loro siano messe vicine sulla lavagna (e spesso parzialmente sovrapposte).

La discussione può procedere, per esempio notando che la pulsantiera fa troppe cose, e la cabina troppo poche: così per esempio si può pensare di dare alla cabina la sola responsabilità di comunicare con l'argano, "alleggerendo" le responsabilità della pulsantiera.
Inoltre si osserva che l'argano è un concetto confuso, e lo si può spezzare in due: un "motore", ed un "sistema di controllo e diagnostica"; il sistema di controllo ha la responsabilità di eseguire il programma "torna al piano terra" in caso di malfunzionamenti o mancanza di corrente principale, IGNORANDO le richieste della cabina...

Si può procedere di questo passo, spezzando o riaggregando le carte, e cambiando loro le responsabilità. Si osservi che:

È importante osservare come le sole due domande "con chi collaboro? di cosa sono responsabile?" siano più che sufficienti per modellare piccoli sistemi. È altresì significativo il fatto che il modello non è scritto sulla pietra, ma evolve con la discussione, portandoci ad espanderlo mano a mano che lo riteniamo opportuno, cambiando le relazioni tra le entità in gioco, e rivedendolo mano a mano.
Le CRC card sono state usate nei "contest" che seguono spesso durante le conferenze sull'OOP, perché sono uno strumento facile da capire, e che può essere usato da persone di estrazione differente, ed anche da non addetti ai lavori.

Conclusioni

Per una trattazione esaustiva delle CRC Cards, si rimanda anche agli esempi in Java^[3] ed in Smalltalk^[2] presentati nelle risorse.

Informazioni sull'autore

Giovanni Giorgi, classe 1974. Dopo il diploma di liceo Classico, si è laureato in Informatica nel febbraio 2000, e attualmente lavora nel campo del software finanziario (trading on line, soluzioni web).
Appassionato di linguaggi di programmazione, si interessa anche di politica e letteratura.

È possibile consultare l'elenco degli articoli scritti da Giovanni Giorgi.

Altri articoli sul tema Design.

Risorse

1. Qui trovate l'articolo originale di Kent Beck e Ward Cunningham, dove approfondire l'argomento.
   http://c2.com/doc/oopsla89/paper.html
2. Questa pagina mostra un esempio di design che parte dalle CRC Cards, arriva al diagramma UML e poi al codice in Squeak Smalltalk
   http://www.cc.gatech.edu/classes/cs2390_99_spring/slides/design/outline.html
3. Questo esempio si serve delle CRC Cards, arrivando fino alla generazione del codice Java.
   http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/
4. Self è un linguaggio in cui non esistono istanze e classi, ma solo "prototipi", cioè oggetti vivi da cui derivarne altri; è completamente dinamico. I creatori del linguaggio avevano un ottica minimalista, ma Self non è mai sembrato convincente. Infatti la sua comprensione è meno immediata rispetto a linguaggi che distinguono tra Classi e Istanze (praticamente tutti...).
   È stato importante perché dal suo studio sono nate parecchie ottimizzazioni usate nei linguaggi dinamici, e potenti Garbage Collector. L'HotSpot è anche figlia della ricerca su Self.
   http://research.sun.com/research/self/language.html
5. Class Responsibility Collaborator (CRC) Model Overview
   http://www.agilemodeling.com/artifacts/crcModel.htm