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.
|
|