Lista de comprobación: Clase de diseño
Esta lista de comprobación le ayuda a garantizar que una clase de diseño se modele correctamente.
Relaciones
Elementos relacionados
Descripción principal


Elementos de comprobación
General
  • El nombre de la clase refleja con claridad el rol que desempeña.
  • La descripción de la clase transmite con claridad la finalidad de la clase.
  • La clase representa una única abstracción bien definida.
  • Los atributos de clase y las operaciones son todas esenciales para cumplir con las responsabilidades de la clase.
  • Cada clase representa un conjunto pequeño, coherente y exclusivo de responsabilidades.
  • Las responsabilidades de la clase están bien definidas, claramente indicadas y claramente relacionadas con la finalidad de la clase.
  • Cada clase es relativamente independiente, y mantiene vínculos poco rígidos con otras clases.
  • La clase tiene responsabilidades en un nivel coherente de abstracción (por ejemplo, las responsabilidades de nivel alto (nivel de aplicación) y de nivel bajo (nivel de implementación) no se mezclan).
  • Las clases de la misma jerarquía de herencia poseen atributos de clase, operaciones y relaciones exclusivos (por ejemplo, heredan todos los atributos, operaciones y relaciones comunes).
  • El ciclo vital completo de una instancia de la clase se tiene en cuenta. Cada objeto lo crea, utiliza y elimina una o más ejecuciones de guión de uso.
  • La clase satisface los requisitos de comportamiento establecidos por las ejecuciones de guión de uso.
  • Todos los requisitos de la clase definidos en la especificación de requisitos se han abordado.
  • Las demandas que se realizan a la clase (como se refleja en la descripción de la clase y en los objetos en los diagramas de secuencia) son coherentes con la máquina de estado de la clase.
  • Todas las responsabilidades de la clase están relacionadas, de forma que no es posible que la clase exista en un sistema en el que se utilicen algunas de sus responsabilidades, pero no otras.
  • No hay dos clases que compartan esencialmente la misma finalidad.
Generalización/Especialización
  • La jerarquía de generalización está equilibrada, de forma que no hay clases para las que la jerarquía sea excepcionalmente plana o profunda.
  • Los factores comunes más obvios se han reflejado en la jerarquía heredada.
  • No hay superclases que sean fusiones de atributos de las subclases.
  • No hay clases abstractas intermedias en la jerarquía de herencia que tengan propiedades ortogonales, y ejemplo de ello son las clases duplicadas en ambos lados de un árbol de herencia.
  • La herencia se utiliza para capturar abstracciones de diseño comunes, su misión fundamental no son las consideraciones de implementación, es decir, para reutilizar fragmentos de código o de estructura de clase.
Convenios de denominación
  • Los nombres de clase indican finalidad.
  • Los nombres de clase siguen los convenios de denominación especificados en las directrices de diseño de proyectos.
Operaciones
  • El nombre de esa operación es descriptivo y comprensible.
  • La máquina de estado y las operaciones son coherentes.
  • La máquina de estado y las operaciones describen completamente el comportamiento de la clase.
  • Los parámetros de cada operación son correctos en términos de número, nombre y tipo.
  • Las especificaciones de implementación para cada operación, cuando están definidas, son correctas.
  • Las firmas de las operaciones cumplen los estándares del lenguaje de programación de destino.
  • Cada operación la utiliza al menos una ejecución de guiones de uso.
Atributos
  • Todas las relaciones de la clase son necesarias para dar soporte a alguna operación de la clase.
  • Cada atributo representa un único aspecto conceptual.
  • El nombre de cada atributo es descriptivo y transmite correctamente la información que almacena.
Relaciones
  • Los nombres de rol de las agregaciones y asociaciones describen la relación entre las clases de asociación y las clases asociadas.
  • Las multiplicidades de las relaciones son correctas.
Máquinas de estado
  • La máquina de estado es lo más simple posible aunque sigue expresando el comportamiento necesario.
  • La máquina de estado no contiene ningún estado ni transición superfluo.
  • La máquina de estado tiene un contexto claro.
  • Todos los objetos con referencias son visibles para el objeto inclusivo.
  • La máquina de estado es eficaz y lleva a cabo su comportamiento con un equilibro óptimo de tiempo y recursos según se define en las acciones que cursa.
  • La máquina de estado resulta comprensible.
    • Los nombres de estado y de transición son comprensibles en el contexto del dominio del sistema.
    • Los nombres de estado indican lo que se espera o lo que está sucediendo, en lugar de lo que ha sucedido.
    • Los nombres de estado y de transición son exclusivos en la máquina de estado (aunque no se trata de un requisito en el sentido estricto, es de gran ayuda en la depuración para forzar los nombres exclusivos).
    • Las agrupaciones lógicas de estados están contenidas en los estados compuestos.
    • Los estados compuestos se han utilizado de forma eficaz para reducir la complejidad.
    • Las etiquetas de transición reflejan la causa subyacente de la transición.
    • No hay fragmentos de código en transiciones de estado que tienen más de 25 líneas de código detallado; por el contrario, las funciones se han utilizado con eficacia para reducir la complejidad del código de transición.
    • La anidación de la máquina de estado se ha examinado para garantizar que la profundidad de anidado no sea demasiado profunda como para ser comprensible; uno o dos de los niveles de subestados suelen ser suficientes para la mayoría de los comportamientos complejos.
  • Las clases activas se han utilizado en lugar de los subestados concurrentes; las clases activas son casi siempre una alternativa preferible y más comprensible que los subestados concurrentes.
  • En los sistemas de tiempo real, se han utilizado cápsulas para representar hebras lógicas de control.
  • Los estados de mantenimiento o de error se han tenido en cuenta.
  • Los subestados se han utilizado en lugar de las variables de estado ampliado; no hay evidencia de que condiciones de vigilancia de la transición que prueben varias variables para determinar el estado en el que debe producirse la transición.
  • La máquina de estado no se parece a un gráfico de flujo.
  • La máquina de estado no parece haberse descompuesto excesivamente y consta de máquinas de estado anidadas con un único subestado. En los casos en los que el subestado anidado es un marcador de posición para futuros trabajos de diseño o subclases, esto puede ser temporalmente aceptable siempre y cuando la elección haya sido consciente.