Lista de Verificação: Classe de Design
Essa lista de verificação ajuda a certificar-se de que uma Classe de Design seja modelada corretamente.
Relacionamentos
Descrição Principal


Itens de Verificação
Geral
  • O nome da classe reflete claramente o papel que ela desempenha.
  • A descrição da classe transmite claramente sua finalidade.
  • A classe representa uma única abstração bem-definida.
  • As operações e os atributos da classe são todos fundamentais para o cumprimento das responsabilidades da classe.
  • Cada classe representa um conjunto de responsabilidades pequeno, consistente e exclusivo.
  • As responsabilidades da classe estão bem-definidas, foram especificadas com clareza e estão claramente relacionadas à respectiva finalidade.
  • Cada classe é relativamente autônoma e pouco relacionada a outras classes.
  • As responsabilidades da classe estão em um nível consistente de abstração (ou seja, as responsabilidades de nível superior (relacionadas ao aplicativo) e de nível inferior (relacionadas à implementação) não estão misturadas).
  • As classes que estão na mesma hierarquia de herança possuem atributos de classe, operações e relacionamentos exclusivos (ou seja, eles herdam todos os atributos, operações e relacionamentos em comum).
  • O ciclo de vida completo de uma instância da classe é levado em consideração. Cada objeto é criado, usado e removido por uma ou mais realizações de casos de uso.
  • A classe atende aos requisitos comportamentais estabelecidos pelas realizações de casos de uso.
  • Todos os requisitos estabelecidos para a classe na especificação de requisitos foram considerados.
  • As demandas da classe (conforme refletidas na descrição da classe e pelos objetos em diagramas de seqüência) são consistentes com a máquina de estado da classe.
  • Todas as responsabilidades da classe estão relacionadas, de forma que a classe não pode existir em um sistema no qual algumas de suas responsabilidades são usadas, mas nem todas elas.
  • Não existem duas classes com a mesma finalidade.
Generalização/Especialização
  • A hierarquia de generalização é balanceada, não havendo classes para as quais ela é excepcionalmente simples ou complexa.
  • O aspectos comuns óbvios estão refletidos na hierarquia de herança.
  • Não existem superclasses que parecem ser provenientes de uma combinação de atributos das subclasses.
  • Não existem classes abstratas intermediárias na hierarquia de herança com propriedades ortogonais; os exemplos incluem subclasses duplicadas em ambos os lados de uma árvore de herança.
  • A herança é usada para capturar abstrações de design comuns e não especificamente para considerações de implementação, isto é, para reutilizar parte da estrutura de classes ou do código.
Convenções de Nomenclatura
  • Os nomes das classes indicam sua finalidade.
  • Os nomes das classes seguem as convenções de nomenclatura especificadas nas orientações de design do projeto.
Operações
  • O nome de cada operação é descritivo e inteligível.
  • A máquina de estado e as operações são consistentes.
  • A máquina de estado e as operações descrevem integralmente o comportamento da classe.
  • Os parâmetros de cada operação estão corretos em termos de número, nome e tipo.
  • As especificações de implementação de cada operação, quando definidas, estão corretas.
  • As assinaturas de operação estão de acordo com o padrão da linguagem de programação de destino.
  • Cada operação é usada por ao menos uma realização de casos de uso.
Atributos
  • Todos os relacionamentos da classe devem oferecer suporte a alguma operação da classe.
  • Cada atributo representa um único conceito.
  • O nome de cada atributo é descritivo e transmite corretamente as informações que contém.
Relacionamentos
  • Os nomes de papéis de agregações e associações descrevem o relacionamento entre as classes associativas e associadas.
  • As multiplicidades dos relacionamentos estão corretas.
Máquinas de Estado
  • A máquina de estado é tão simples quanto o possível e, ao mesmo tempo, expressa o comportamento obrigatório.
  • A máquina de estado não contém transições ou estados supérfluos.
  • A máquina de estado tem um contexto claro.
  • Todos os objetos referenciados estão visíveis ao objeto incluso.
  • A máquina de estado é eficiente e seu comportamento apresenta um equilíbrio ideal no que se refere ao tempo e aos recursos definidos pelas ações que executa.
  • A máquina de estado é inteligível.
    • Os nomes de estado e transição são inteligíveis no contexto do domínio do sistema.
    • Os nomes de estado indicam o que se está aguardando ou o que está acontecendo e não o que aconteceu.
    • Os nomes de estado e transição são exclusivos na máquina de estado (embora não seja um requisito rígido, isso auxilia na depuração, impondo o uso de nomes exclusivos).
    • Agrupamentos lógicos de estados estão contidos em estados compostos.
    • Os estados compostos foram utilizados com eficiência para reduzir a complexidade?
    • As identificações de transição refletem a causa fundamental da transição.
    • Não existem fragmentos de código em transições de estado com mais de 25 linhas de código de detalhes; pelo contrário, as funções foram usadas com eficiência para reduzir a complexidade do código de transição.
    • O aninhamento das máquinas de estado foi verificado para assegurar que não seja tão profundo a ponto de comprometer seu entendimento; um ou dois níveis de subestados normalmente são suficientes para a maioria dos comportamentos complexos.
  • Foram usadas classes ativas em vez de subestados simultâneos; as classes ativas quase sempre são uma alternativa melhor e mais inteligível do que os subestados simultâneos.
  • Em sistemas em tempo real, foram usadas cápsulas para representar threads lógicos de controle.
  • Estados de erro ou manutenção foram considerados.
  • Subestados foram utilizados em vez de variáveis de estado estendido; não há evidência de condições de guarda na transição testando diversas variáveis para determinar em qual estado a transição deve ocorrer.
  • A máquina de estado não se parece com um fluxograma.
  • A máquina de estado não parece ter sido dividida exageradamente, sendo formada por máquinas de estado aninhadas com um único subestado. Nos casos em que o subestado aninhado representa um trabalho de design ou divisão em subclasses no futuro, isso pode ser temporariamente aceito, desde que a escolha seja consciente.