Pontos de Verificação: Classe de Design
Tópicos
- 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.
- 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.
- Os nomes das classes indicam sua finalidade.
- Os nomes das classes seguem as convenções de nomenclatura especificadas
nas diretrizes de design do projeto.
- 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.
- 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.
- 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.
- 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.
- 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.
| |
|