Pergunta

Sempre me perguntei como as pessoas usam cartões CRC (colaboração de responsabilidade de classe).Li sobre eles em livros, encontrei informações vagas na internet, mas nunca entendi direito.Acho que alguém deveria fazer um vídeo no youtube mostrando uma sessão com cartões CRC, já que um dos meus livros descreveu como sendo muito difícil de formular em texto, que deveria ser "ensinado por alguém que já domina".Infelizmente, não conheço ninguém por aqui que use cartões CRC e gostaria de saber mais.

ATUALIZAR

Quaisquer links para vídeos mostrando pessoas elaborando esta técnica serão apreciados.

Foi útil?

Solução

Vou tentar dar uma resposta.Portanto, os cartões CRC são geralmente usados ​​para modelagem em um ambiente orientado a objetos para obter uma melhor compreensão do sistema que deve ser desenvolvido (mas acho que você já sabe).Os cartões CRC chegam bem no final, quando você chega pouco antes da implementação real.As diferentes etapas para atingir esse nível podem ser as seguintes:

  1. O ponto de partida é fazer a elicitação de requisitos.Envolver o cliente precoce e continuamente é sugerido aqui (dê uma olhada nas abordagens Agile, ou seja,Programação extrema)
  2. Os requisitos podem então ser modelados com diagramas de casos de uso (UML) ou com histórias de usuários (abordagem de programação ágil extrema).O principal problema aqui é encontrar os objetos envolvidos corretos.Isso depende muito do domínio em que você está, é claro.Se você seguir o caminho "difícil", poderá aplicar técnicas como "extração de substantivos".Assim, você analisa o documento de especificação e extrai todos os substantivos (incluindo nomes compostos e aqueles com adjetivos).Analise todos eles e descarte os irrelevantes.
  3. Depois de ter os substantivos corretos -> objetos, você pode começar a criar seus cartões CRC.Então, o que é feito em uma sessão CRC?A principal tarefa é encontrar e atribuir as responsabilidades dos seus objetos (anteriormente) encontrados, que são então colocados em pequenos cartões de índice (nossos cartões CRC)."Responsabilidades" são principalmente as funcionalidades principais de um objeto específico e a parte "colaboração" são os outros objetos necessários para cumprir determinadas funcionalidades (estas são as dependências entre os diferentes objetos no seu modelo).Um ponto importante para a atribuição de responsabilidades é que as responsabilidades sejam bem distribuídas por todo o sistema de alguma forma equilibrada.Outro ponto muito importante é evitar qualquer duplicação de responsabilidades entre os objetos (é aqui que os cartões CRC ajudam).
    Uma sessão de CRC deve começar com uma reunião de brainstorming, com uma discussão ativa entre os desenvolvedores e deve ser realizada diretamente nas fichas reais.

Espero ter conseguido de alguma forma ajudá-lo.

Cumprimentos,
Juri

Outras dicas

É difícil resumir em uma resposta tão, mas vou tentar. Um dos desafios de projetar objetos é equilibrar o pensamento de uma perspectiva geral com o pensamento da perspectiva de um objeto individual. Você precisa da perspectiva geral para concluir o cálculo, mas precisa da perspectiva do objeto individual para subdividir efetivamente a lógica e os dados.

Manter esse equilíbrio é onde os cartões CRC entram. Quando estão sentados na mesa, você pode olhar para o cálculo como um todo. Quando você pega uma única carta, porém, você é fisicamente, cinestesamente incentivado a ter o ponto de vista desse objeto-eu tenho esse pequeno pedaço desse cálculo a ver com recursos limitados, como vou realizar isso?

Com o tempo, a capacidade de manter as duas perspectivas parece absorver o cérebro. Metor e menos é escrito nos cartões. Então os cartões estão em branco. Depois de um tempo, as pessoas apenas apontam para onde o cartão estaria se se incomodassem em tirar uma em branco da pilha. Eventualmente, as pessoas têm os benefícios do estilo de pensamento sem precisar de cartões. Ao conversar com alguém que não dominou o equilíbrio, retirar os cartões reais pode ser uma assistência de comunicação útil.

A maior fraqueza que encontro com os cartões é a falta de feedback. Você pode se enganar sobre como o código vai acabar. Eu sugeriria o uso de cartões apenas até que uma pergunta interessante apareça, recorre aos testes/código para confirmação e retomar o design.

Ward e eu fizemos um vídeo há 15 anos ou mais de uma sessão de design, mas não o encontro on -line em lugar nenhum e não tenho uma cópia. Não tenho certeza se seria útil como uma ferramenta de ensino em qualquer caso. Não conheço outros vídeos, mas eles podem ser interessantes, especialmente se você tiver que comparar vários estilos de designers diferentes.

Vá para a fonte - Kent Beck, Ward Cunningham, já ouviu falar deles?

Eu acho que sua declaração "Eu conheço ninguém por aqui que usa cartões CRC" Praticamente resume o estado dos cartões de CRC em desenvolvimento. Os cartões da CRC, na minha opinião, foram um passo na estrada do desenvolvimento tradicional e orientado a planos para o desenvolvimento ágil. O mundo seguiu em frente. Em vez de me concentrar em como usar os cartões CRC, eu investigaria técnicas como Tdd, que podem usar técnicas como cartões UML e CRC como artefatos intermediários, mas que se concentram no código e mais particularmente nos testes. Esta é a direção que os inventores dos cartões CRC tomaram e eu recomendo que você adote também.

A maneira mais fácil de usá -los na minha opinião sem entrar em uma bagunça é escrever pequenos cartões CRC em seus cabeçalhos de arquivo como este:

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

Sempre, toda vez que você precisar adicionar um recurso, verifique seu cartão e verifique se você não quebra nenhum dos contratos que declarou nele. Como de repente, dependendo do UiMouseEvent, por exemplo, isso não está em lugar nenhum no cartão, então é um não-não incluí-lo.

Em seu livro Design de objetos: funções, responsabilidades e colaborações Publicado em 2003 Rebecca Wirfs-Brock & Alan McKean discutem cartões CRC com alguns detalhes. Eles realmente enfatizam a diferença que faz em todo o procedimento de que essa deve ser uma experiência muito tátil e afrouxa o pensamento das pessoas de passar um objeto físico ao tentar aprofundar um design / requisito.

O subtítulo desse capítulo sugere que o uso dos cartões faz parte da fase 'Design Exploratório', para que provavelmente chegue antes de fazer muita codificação, mas não vejo razão para você não voltar para eles em cada iteração de um projeto ágil e lembrando-se de onde você pensou que estava indo e analisando isso se precisar (como um grupo, é claro).

Parece que eles até sugerem passar uma bola pela sala, para que apenas a pessoa que tem a bola possa falar, então talvez não sejam tanto os cartões CRC, como o que todos estão em uma sala falando sobre papéis e responsabilidades de objetos que importam?

Se você quiser ler um estudo de caso de cartões CRC em ação (além do artigo original de Kent e Ward, é claro), dê uma olhada em O livro de cartão CRC.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top