Rubriques

GénéralitésHaut

    • Le nom de la classe reflète clairement le rôle qu'elle joue.
    • La description de la classe exprime clairement l'objectif de la classe.
    • La classe représente une seule abstraction bien définie.
    • Les attributs et les opérations de la classe sont tous essentiels pour s'acquitter des responsabilités de la classe.
    • Chaque classe représente un ensemble de responsabilités petit, cohérent et unique.
    • Les responsabilités de la classe sont bien définies, clairement exprimées, et clairement liées à l'objectif de la classe.
    • Chaque classe est relativement autonome, et est faiblement couplée à d'autres classes.
    • Les responsabilités de la classe sont d'un niveau d'abstraction cohérent (c'est-à-dire que les responsabilités de haut niveau (au niveau de l'application) et de bas niveau (au niveau de l'implémentation) ne sont pas mélangées).
    • Les classes de la même hiérarchie d'héritage possèdent des attributs, des opérations et des relations de classe uniques (c'est-à-dire qu'elles héritent d'attributs, d'opérations et de relations communs).
    • Le cycle de vie complet d'une instance de la classe est représenté. Chaque objet est créé, utilisé, et supprimé par une réalisation de cas d'utilisation ou plus.
    • La classe répond aux exigences comportementales établies par les réalisations de cas d'utilisation.
    • Toutes les exigences faites à la classe dans la spécification d'exigences sont traitées.
    • Les exigences faites à la classe (exprimées dans la description de classe et par les objets des diagrammes de séquence) sont cohérentes par rapport à l'automate à états de la classe.
    • Toutes les responsabilités de la classe sont liées, de telle façon que la classe ne peut exister dans un système dans lequel certaines de ces responsabilités sont utilisées, mais pas d'autres.
    • Deux classes n'ont jamais essentiellement le même objectif.

Généralisation/Spécialisation Haut

    • La hiérarchie de généralisation est équilibrée, de façon à ce qu'aucune classe n'ait de hiérarchie anormalement plate ou profonde.
    • Toute banalisation évidente est exprimée dans la hiérarchie d'héritage.
    • Aucune superclasse n'est une fusion des attributs des sous-classes.
    • Aucune classe abstraite intermédiaire de la hiérarchie d'héritage n'a de propriétés orthogonales, par exemple des sous-classes en doublon des deux côtés d'un arbre d'héritage.
    • L'héritage est utilisé pour consigner les abstractions de conception communes, et non principalement pour des considérations d'implémentation, c'est-à-dire pour réutiliser des parties de code ou de structure de classe.

Conventions de dénomination Haut

    • Les noms de classe indiquent l'objectif.
    • Les noms de classe suivent les conventions de dénomination définies dans les principes et conseils de conception spécifiques au projet.

Opérations Haut

    • Le nom de chaque opération est descriptif et compréhensible.
    • L'automate à états et les opérations sont cohérents.
    • L'automate à états et les opérations décrivent complètement le comportement de la classe.
    • Les paramètres de chaque opération sont corrects en terme de nombre, de nom et de type.
    • Les spécifications d'implémentation pour chaque opération, lorsqu'elles sont définies, sont correctes.
    • Les signatures d'opération se conforment aux standards du langage de programmation cible.
    • Chaque opération est utilisée par au minimum une réalisation de cas d'utilisation.

AttributsHaut

    • Toutes les relations de la classe sont requises pour prendre en charge une opération de la classe.
    • Chaque attribut représente un seul élément conceptuel.
    • Le nom de chaque attribut est descriptif et exprime correctement l'information stockée.

RelationsHaut

    • Les noms de rôle des agrégations et des associations décrivent la relation entre les classes associantes et associées.
    • Les multiplicités des relations sont correctes.

automates à états Haut

    • L'automate à états est aussi simple que possible tout en décrivant le comportement requis.
    • L'automate à états ne contient pas d'états ni de transitions superflus.
    • L'automate à états possède un contexte clair.
    • Tous les objets référencés sont visibles pour l'objet englobant.
    • L'automate à états est efficace, et effectue son comportement selon la durée et les ressources définies par les actions réparties.
    • L'automate à états est compréhensible.
      • Les noms d'état et de transition sont compréhensibles dans le contexte du domaine du système.
      • Les noms d'état indiquent l'événement attendu ou ce qui se passe actuellement et non ce qui s'est déjà produit.
      • Les noms d'état et de transition sont uniques dans le cadre de l'automate à états (bien que cela ne soit pas une exigence stricte, l'application de noms uniques aide le déboguage).
      • Des regroupements logiques d'états sont englobés dans les états composites.
      • Des états composites ont-il été utilisés pour réduire la complexité ?
      • Les libellés de transition reflètent la cause sous-jacente de la transition.
      • Aucun fragment de code sur les transitions d'état ne fait plus de 25 lignes de code détaillé ; au contraire, des fonctions ont été utilisées pour réduire la complexité du code de transition.
      • L'emboîtement de l'automate à états a été examiné afin de s'assurer que la profondeur de l'emboîtement n'est pas trop importante pour être compréhensible, généralement, un ou deux niveaux de sous-états suffisent pour des comportements plus complexes.
    • Des classes actives ont été utilisées au lieu des sous-états concurrents ; les classes actives représentent presque toujours une meilleure alternative et sont plus compréhensibles que les sous-états concurrents.
    • Les états d'erreur ou de maintenance ont été représentés.
    • Des sous-états ont été utilisés au lieu des variables d'état étendues ; il n'existe pas de preuve de conditions de protection de transition testant plusieurs variables pour déterminer l'état dans lequel la transition peut avoir lieu.
    • L'automate à états ne ressemble pas à un organigramme.
    • L'automate à états ne semble pas avoir été trop décomposé, et ne consiste que d'automates à états imbriqués avec un seul sous-état. Lorsque le sous-état imbriqué sert un signet pour une tâche ou un sous-classage ultérieur, cela peut être temporairement acceptable si ce choix a été délibéré.


RUP (Rational Unified Process)   2003.06.15