Domanda

Mi sono sempre chiesto come le persone usano le carte CRC (collaborazione per la responsabilità di classe).Ne ho letto nei libri, ho trovato informazioni vaghe su Internet, ma non le ho mai capite veramente.Penso che qualcuno dovrebbe realizzare un video su YouTube che mostri una sessione con le carte CRC, dal momento che uno dei miei libri lo descrive come molto difficile da formulare in un testo, che dovrebbe essere "insegnato da qualcuno che già lo padroneggia".Purtroppo non conosco nessuno qui che usi le carte CRC e mi piacerebbe saperne di più.

AGGIORNAMENTO

Qualsiasi collegamento a video che mostrano persone che elaborano questa tecnica sarebbe apprezzato.

È stato utile?

Soluzione

Proverò a dare una risposta.Quindi le schede CRC vengono generalmente utilizzate per la modellazione in ambiente Object Oriented per comprendere meglio il sistema che deve essere sviluppato (ma che penso tu già conosca).Le carte CRC arrivano proprio alla fine, appena prima dell'effettiva implementazione.I diversi passaggi per raggiungere quel livello potrebbero essere i seguenti:

  1. Il punto di partenza è l'elicitazione dei requisiti.Qui si suggerisce di coinvolgere il cliente in modo tempestivo e continuo (dai un'occhiata agli approcci Agile, ad es.Programmazione estrema)
  2. I requisiti possono poi essere modellati con diagrammi di casi d'uso (UML) o con storie di utenti (approccio di programmazione agile estremo).Il problema chiave qui è trovare gli oggetti coinvolti giusti.Questo dipende molto dal dominio in cui ti trovi, ovviamente.Se procedi nel modo "duro", puoi applicare tecniche come "estrazione dei nomi".Quindi analizzi il documento delle specifiche ed estrai tutti i nomi (compresi i nomi composti e quelli con aggettivi).Analizzali tutti e scarta quelli irrilevanti.
  3. Una volta che hai i nomi giusti -> oggetti puoi iniziare a creare le tue carte CRC.Quindi cosa viene fatto in una sessione CRC?Il compito principale è trovare e assegnare le responsabilità degli oggetti (precedentemente) trovati che vengono poi annotati su piccole schede (le nostre schede CRC).Le "responsabilità" sono principalmente le funzionalità principali di un oggetto specifico e la parte "collaborazione" sono gli altri oggetti necessari per soddisfare determinate funzionalità (queste sono le dipendenze tra i diversi oggetti nel modello).Un punto importante per l'assegnazione delle responsabilità è che le responsabilità siano ben distribuite sull'intero sistema in una sorta di modo equilibrato.Un altro punto molto importante è evitare qualsiasi duplicazione di responsabilità tra gli oggetti (qui aiutano le carte CRC).
    Una sessione CRC dovrebbe iniziare con un incontro di brainstorming, con una discussione attiva tra gli sviluppatori e dovrebbe essere eseguita direttamente sulle schede reali.

Spero di essere riuscito in qualche modo ad aiutarti.

Saluti,
Giuri

Altri suggerimenti

È difficile riassumere in una risposta SO, ma ci proverò.Una delle sfide della progettazione di oggetti è bilanciare il pensiero da una prospettiva generale con il pensiero dalla prospettiva di un singolo oggetto.È necessaria la prospettiva generale per completare il calcolo, ma è necessaria la prospettiva del singolo oggetto per suddividere efficacemente la logica e i dati.

Mantenere questo equilibrio è il punto in cui entrano in gioco le carte CRC.Quando sono seduti sul tavolo, puoi guardare il calcolo nel suo insieme.Quando prendi una singola carta, però, sei fisicamente, cinesteticamente incoraggiato ad assumere il punto di vista di quell'oggetto: ho a che fare con questa piccola parte di questo calcolo con risorse limitate, come posso realizzarlo?

Col passare del tempo, la capacità di sostenere entrambe le prospettive contemporaneamente sembra penetrare nel cervello.Sempre meno viene scritto sulle carte.Quindi le carte sono bianche.Dopo un po' le persone semplicemente indicano dove si troverebbe la carta se si prendessero la briga di prenderne una vuota dal mazzo.Alla fine, le persone ottengono i vantaggi dello stile di pensiero senza aver bisogno delle carte.Tuttavia, quando si parla con qualcuno che non ha padroneggiato l'equilibrio, estrarre le carte reali può essere un utile aiuto per la comunicazione.

Il più grande punto debole che trovo nelle carte è la mancanza di feedback.Puoi illuderti su come andrà a finire il codice.Suggerirei di utilizzare le carte solo fino a quando non viene sollevata una domanda interessante, passare a test/codice per conferma e quindi riprendere la progettazione.

Ward e io abbiamo realizzato un video circa 15 anni fa di una sessione di progettazione, ma non lo trovo online da nessuna parte e non ne ho una copia.Non sono sicuro che sarebbe utile come strumento didattico in ogni caso.Non conosco altri video, ma potrebbero essere interessanti, soprattutto se riesci a confrontare diversi stili di designer.

vai a la fonte - Kent Beck, Ward Cunningham, ne hai mai sentito parlare?

Penso che la tua affermazione "Non conosco nessuno qui che usi le carte CRC" riassume praticamente lo stato delle carte CRC in fase di sviluppo.Le carte CRC, a mio avviso, hanno rappresentato un passo avanti sulla strada dallo sviluppo tradizionale, basato sui piani, allo sviluppo agile.Il mondo è andato avanti.Invece di concentrarmi su come utilizzare le carte CRC, indagherei su tecniche come TDD, che può utilizzare tecniche come le schede UML e CRC come artefatti intermedi ma che si concentra sul codice e, più in particolare, sui test.Questa è la direzione che hanno preso gli inventori delle carte CRC e consiglierei di prendere anche tu.

Il modo più semplice per usarli secondo me senza finire nei guai è scrivere piccole carte CRC nelle intestazioni dei file in questo modo:

///////////////////////
//* CRC CARD
//*  Class: UISliderEvent
//*  Responsability: Event that holds the value and id of a Slider's movement
//*  Collaborators: UISlider, UIEvent
//////////////////////

Quindi ogni volta che devi aggiungere una funzionalità controlla la tua carta e assicurati di non infrangere nessuno dei contratti che hai indicato in essa.Ad esempio, all'improvviso, a seconda di UIMouseEvent, non si trova da nessuna parte sulla scheda, quindi è un no-no includerlo.

Nel loro libro Progettazione di oggetti:ruoli, responsabilità e collaborazioni pubblicato nel 2003 Rebecca Wirfs-Brock e Alan McKean discutono in dettaglio le carte CRC.Sottolineano davvero la differenza che fa all'intera procedura il fatto che questa dovrebbe essere un'esperienza molto tattile e allenta il pensiero delle persone di passare in giro un oggetto fisico quando cercano di concretizzare un progetto/requisito.

Il sottotitolo di quel capitolo suggerisce che l'uso delle carte fa parte della fase di "progettazione esplorativa", quindi probabilmente viene prima di fare molta codifica, ma non vedo alcun motivo per cui non dovresti continuare a tornare su di loro in ogni iterazione di un progetto Agile e ricordare a te stesso dove pensavi di andare e rivederlo se necessario (in gruppo ovviamente).

Mi sembra di ricordare che suggeriscono addirittura di passare una palla per la stanza in modo che solo la persona che ha la palla possa parlare, quindi forse non sono tanto le carte CRC quanto il fatto di far sì che tutti in una stanza parlino dei ruoli e delle responsabilità di oggetti che contano?

Se desideri leggere un caso di studio sulle carte CRC in azione (oltre all'articolo originale di Kent e Ward ovviamente), dai un'occhiata a Il libretto delle carte CRC.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top