Um Guia Completo sobre Modelagem CRC (Classe Responsabilidade Colaborador)
Baseado nos princípios fundamentais da análise orientada a objetos (OO), este guia descreve o processo de modelagem CRC. A modelagem CRC é uma metodologia altamente eficaz e de baixa tecnologia projetada para eliminar a lacuna de comunicação entre desenvolvedores e usuários, garantindo que os requisitos de negócios sejam identificados e compreendidos com precisão antes da escrita do código.
1. Conceitos Principais: A Anatomia de um Cartão CRC
A modelagem CRC depende de cartões de índice padrão divididos em três seções distintas. Cada seção representa um conceito central no design orientado a objetos.
A. Classe (Parte Superior do Cartão)
Uma classe representa uma coleção de objetos semelhantes. Um objeto pode ser uma pessoa, lugar, coisa, evento, conceito, tela ou relatório relevante para o sistema.
-
Regra de Nomeação: Use uma ou duas palavras no singular (por exemplo, Cliente, não Clientes).
-
Exemplo: Em um sistema de envio/estoque, as classes incluem Item de Estoque, Pedido, Item do Pedido, Cliente, e Endereço de Superfície.
B. Responsabilidade (Coluna Esquerda)
Uma responsabilidade é qualquer coisa que uma classe sabe ou faz.
-
O que ele sabe (Dados/Attributos): Exemplo: Um Cliente a classe sabe seu nome, número do cliente e número de telefone.
-
O que ele faz (Comportamentos/Métodos): Exemplo: Um Cliente a classe pode pedir produtos, cancelar pedidos e efetuar pagamentos.
C. Colaborador (Coluna da Direita)
A colaboração ocorre quando uma classe precisa de informações ou assistência de outra classe para cumprir uma responsabilidade.
-
Exemplo: Um Pedido um objeto tem a responsabilidade de “calcular o total”. No entanto, ele não sabe o preço dos itens nem a quantidade pedida. Portanto, ele deve colaborar com Item do Pedido (que sabe a quantidade) e Item do Estoque (que sabe o preço) para calcular o total final.
2. A Equipe de Modelagem CRC
Uma sessão CRC bem-sucedida exige papéis específicos para garantir que o processo ocorra de forma suave e capture com precisão a lógica de negócios.
-
Especialistas em Domínio de Negócios (EDNs): Os usuários reais do sistema (normalmente 4 a 5 funcionários de linha de frente). Eles possuem o conhecimento do dia a dia dos negócios. Observação: Executivos geralmente não são ideais para CRC; eles são mais adequados para Casos de Uso de alto nível.
-
Facilitador: Conduz a sessão, explica a técnica, faz perguntas pertinentes, garante que os cartões sejam preenchidos corretamente e conduz os testes de cenários.
-
Escritor(es): 1 ou 2 pessoas que sentam nas partes de trás/laterais. Elas não participam ativamente da modelagem, mas registram a lógica e as regras detalhadas do negócio que não cabem nas pequenas fichas.
-
Observadores: Estagiários ou partes interessadas que sentam nas partes de trás e observam sem participar.
3. O Processo de Modelagem CRC de 6 Etapas
Etapa 1: Montar a Equipe
Reúna 4 a 5 BDEs de linha de frente, um facilitador e 1 a 2 redatores. Garanta o apoio da gestão para que os participantes possam dedicar o tempo necessário.
Etapa 2: Organizar a Sala
-
Superfícies para escrever: Quadros de papel ou quadros brancos para brainstorming e prototipagem.
-
Mesa de modelagem: Uma mesa grande e central para os BDEs colocarem e moverem as fichas.
-
Estações de redação: Mesas colocadas fora do caminho, mas com vista clara.
-
Fornecimentos: Fichas, marcadores e uma bola macia e esponjosa (utilizada posteriormente para testes de cenários).
Etapa 3: Brainstorm
Gere ideias sem avaliá-las. O facilitador faz perguntas abertas para entender as necessidades do negócio.
-
Perguntas Exemplo: “Para quem é este sistema?”, “Que necessidades do negócio ele atende?”, “Como podemos fazer isso mais rápido/melhor/barato?”, “Há tarefas triviais que podemos automatizar?”
Etapa 4: Explicar a Técnica
O facilitador gasta 10 a 15 minutos explicando os conceitos CRC, exibindo prominentemente as definições na parede e orientando a equipe na criação de algumas fichas exemplo.
Etapa 5: Modelagem CRC Iterativa
Os BDEs ficam em pé ou sentam-se ao redor da mesa e constroem o modelo de forma iterativa:
-
Encontrar Classes: Siga o dinheiro, procure por relatórios/telas e identifique imediatamente as 3 a 5 classes principais.
-
Encontrar Responsabilidades: Pergunte o que a classe sabe e faz.
-
Definir Colaboradores:Identifique quem detém as informações ausentes necessárias para cumprir uma responsabilidade.
-
Organize os Cartões: Passo Crucial.Cartões que colaboram frequentemente são colocados próximos uns dos outros na mesa. Cartões “ocupados” vão para o centro. Mover os cartões fisicamente ajuda a equipe a visualizar relações e associações.
Passo 6: Teste de Cenários de Caso de Uso (Exercício do “Lançamento da Bola”)
Este é um exercício de validação em que a equipe “representa” os fluxos de trabalho do sistema para garantir que o modelo esteja correto.
-
Chame um Cenário:O facilitador descreve um caso de uso (por exemplo, “Cliente faz um pedido”) e lança a bola macia para o BDE que segura o cartão inicial de responsabilidade (por exemplo, Pedido).
-
Determine a Responsabilidade:O grupo confirma que o cartão trata a tarefa. Caso contrário, atualizam ou criam um novo cartão.
-
Descreva a Lógica:O BDE que segura a bola descreve, passo a passo, a lógica de negócios (código-pseudônimo) para o secretário.
-
Colabore:Se o BDE precisar de informações de outra classe (por exemplo, Item de Estoque), eles lançam a bola para o BDE que segura esse cartão. Esse BDE então descreve sua parte da lógica.
-
Passe a Bola de Volta:Uma vez que uma tarefa é concluída, a bola é lançada de volta para a pessoa anterior, retornando eventualmente ao facilitador para iniciar o próximo cenário.
4. Como o CRC se encaixa no SDLC
A modelagem CRC não existe em um vácuo; ela faz parte de um processo mais amplo de modelagem Orientada a Objetos que é serial no grande (passando dos requisitos para o design até o código) e iterativo no pequeno (saltando entre modelos).
-
Nível de Detalhe:O CRC está no meio. Você começa de forma simples com Casos de Uso e Protótipos de UI, passe para o detalhamento médio de Modelos CRC, e finalize com o detalhamento alto de Diagramas de Classes.
-
Entregáveis Impulsionam Entregáveis: Os diagramas de casos de uso são documentados por casos de uso, que são documentados por diagramas de sequência, que eventualmente geram o código-fonte. Os modelos CRC alimentam diretamente o diagrama de classes.
5. Melhores Práticas e Dicas para o Sucesso
-
Envie uma Pauta: Distribua uma pauta alguns dias antes para que os BDEs possam se preparar.
-
Exiba as Definições: Cole um layout grande de cartões CRC e suas definições na frente da sala.
-
Use Terminologia do Domínio: Evite jargões técnicos; use exatamente as palavras que os BDEs usam em seus trabalhos diários.
-
Mantenha o Baixo-Tecnologia: Ferramentas para CRC são opcionais. Cartões de índice são baratos, portáteis e altamente eficazes.
-
Espere Prototipar: Esboçar telas e relatórios em quadros de flip-chart durante a sessão ajuda os usuários a visualizarem o sistema.
-
Planeje para Vários Dias: Sistemas grandes exigem várias sessões. Isso é normal e necessário.
-
Obtenha Apoio da Gestão: Garanta que a liderança entenda o valor da modelagem antes da codificação.
-
Alvo para Equipes de Linha de Frente: O CRC é altamente detalhado e funciona melhor com usuários diários, e não com executivos de alto nível.
6. Vantagens e Desvantagens
As Vantagens
-
Especialistas fazem a análise: As pessoas que realmente fazem o trabalho constroem o modelo.
-
Alto Engajamento dos Usuários:A participação ativa aumenta a satisfação do usuário e o sentimento de posse.
-
Quebra barreiras: Usuários e desenvolvedores trabalham lado a lado.
-
Simples e não ameaçador: São apenas fichas. Os usuários não se sentem intimidados por ferramentas de software complexas, e não sentem que seus trabalhos estão sendo automatizados por uma “máquina”.
-
Barato e portátil: Custa alguns dólares e cabe em uma pasta.
-
Transição contínua: Combina perfeitamente com prototipagem e leva diretamente aos diagramas de classe formais.
As desvantagens
-
Ameaçador para alguns desenvolvedores: Alguns desenvolvedores acreditam erroneamente que seus conhecimentos técnicos superam o conhecimento dos usuários sobre negócios.
-
Agendamento é difícil: Reunir 4 a 5 usuários-chave na mesma sala ao mesmo tempo exige planejamento prévio.
-
As fichas são limitadas: Uma pilha de fichas não é um entregável formal aceitável para a maioria das organizações. O CRC deve ser complementado com casos de uso formais, protótipos e diagramas de classe.
Conclusão
O objetivo final do desenvolvimento de aplicativos é resolver problemas de negócios, e não satisfazer a curiosidade intelectual de um desenvolvedor com novas tecnologias. O modelo CRC força os desenvolvedores a trabalhar com usuários em vez de contra eles. Ao utilizar um ambiente de baixa tecnologia, altamente colaborativo, as equipes conseguem capturar, validar e refinar com precisão os requisitos de negócios antes de escrever uma única linha de código.
