Tópicos

Geral Superior

    • 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 Superior

    • 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 Superior

    • Os nomes das classes indicam sua finalidade.
    • Os nomes das classes seguem as convenções de nomenclatura especificadas nas diretrizes de design do projeto.

Operações Superior

    • 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 Superior

    • 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 Superior

    • 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 Superior

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


Rational Unified Process   2003.06.15