code design – Criterios para el análisis orientado a objetos

Criterios para el análisis orientado a objetos

Introducción

Estos criterios de evaluación usados en el análisis orientado a objetos fueron definidos por Spencer Rugaber miembro del College of Computing en Georgia Institute of Technology. La versión original puede ser descargada desde este enlace. Este documento indica una seria de puntos que se deben revisar o tener en cuenta al momento de diseñar:

• Clases, atributos y operaciones
• Asociaciones de agregación y generalización
• Escenarios y consideraciones de arquitectura
• Uso de nomenclaturas
• Traza de requerimientos
• Etc

El documento original esta escrito en ingles y mi labor en este articulo ha sido traducirlo de modo que si existe algún problema con la traducción me pueden avisar para corregirlo.

Criterios para el análisis orientado a objetos

Legenda:

(c) Para elementos que deben ser revisados antes de la revisión actual.

(d) Para elementos que deben ser parte de la revisión detallado del diseño

I. Clases de objetos

• ¿La clase denota una colección de instancias similares? Si no, ¿Se ha documentado la posibilidad de usar un singleton?
• ¿Las responsabilidades de los objetos han sido descritas adecuadamente?
• (c) ¿Los objetos están anotados para indicar si son internos o externos?

II. Atributos

• (c) ¿Cada uno de los atributos tiene un tipo de dato asociado?
• (c) Si los tipos de datos no son primitivos, ¿Estos deben ser reemplazados por una asociación a una clase existente?
• (d) ¿Se han especificado valores iniciales para los atributos?
• (d) ¿Se ha usado un pointer attribute en lugar de una asociación?
• (c) ¿Se han expresado state invariants?
• (c) ¿Se han indicados los atributos derivados?
• (c) ¿Se han indicados los atributos de clases?

III. Operaciones

• (c) ¿Los parámetros y el resultado de una operación están definidos?
• Para una operación polifórmica, ¿Se especificó con una definición de una función virtual en el lugar correcto dentro de la jerarquía de clases?
• (d) Si la operación es polifórmica, ¿Su firma es consistente?
• (c) ¿Las operaciones son anotadas para indicar si ellas alteran el estado o solo la examinan (y posiblemente la retornan)?
• (d) ¿Las pre.-condiciones de una operación son indicadas?
• ¿Se especifica la responsabilidad de una operación?
• (d) ¿Las post-condiciones de una operación son descritas?
• (c) ¿Se han indicados las operaciones de clase?
• (c) ¿Las operación están anotadas para saber si son acciones o actividades?
• (c) Si la operación de en una clase sobreescribe a una de la clase padre, ¿El tipo de retorno de la operación de la clase hija es un subtipo del tipo de retorno de la operación de la clase padre?

IV. Asociaciones

• (c) ¿Está indicada la aridad de cada asociación?
• ¿Pueden las asociaciones con aridad > 2 ser reemplazadas por una asociación binaria más significativa?
• (c) ¿La cardinalidad de los constraints son indicados?
• (c) ¿Están definidos los nombres de los roles para cada una de las clases que participan en una asociación recurrente?
• (c) ¿Se ha indicado alguna restricción de ordenación?
• ¿Se han provisto las calificaciones para reducir la multiplicidad de las asociaciones?
• ¿Puede una asociación one-to-one ser hecha muchas veces?
• ¿Se ha indicado algún constraint de integridad referencial?
• (c) ¿Cada asociación requiere una representación persistente? Si no, ¿Podría ser modelada como una operación?
• ¿Debe la asociación ser normalizada para introducir clases intermedias y asociaciones?
• ¿Se han anotado los atributos de enlace y de operación?

V. Asociaciones de agregaciones

• ¿Podría una agregación ser modelada mejor con atributos?
• (c) ¿Es la asociación transitiva?
• (c) ¿Es la asociación anti simétrica?
• (c) ¿Se ha indicado la existencia de dependencias?
• (c) ¿Están indicadas las propiedades de propagación?

VI. Asociaciones de generalización

• ¿Se han factorizado atributos comunes de varias clases dentro de una súper clase?
• ¿La asociación es transitiva?
• ¿Se han movido métodos comunes a la clase base?
• ¿Se han indicado discriminadores para cada generalización?
• ¿Se han anotado overrides restrictivos?
• Si un conjunto de subclases hermanas se diferencian solo por el valor de un atributo, ¿Podría este caso ser mejor modelado usando un atributo (enumerado) en la clase padre?
• ¿El conjunto de subclases particiona completamente a la clase padre?

VII. Escenarios/event traces

• (c) ¿Los escenarios de arquitectura están separados de los escenarios de detalle?
• (c) ¿Están suficientemente abreviados los mensajes en cascada?
• ¿Se han revisado las transiciones ante la necesidad de usar guard clases?
• ¿Se han revisado los eventos en cascada para evitar race conditions?

IX. INTERMODEL CONSISTENCY

• (O: indica modelo de objetos, D: modelo dinámico y F: modelo funcional)
• (c) ¿Están indicados las condiciones de datos (triggers)? (O-D)
• ¿Causan los eventos apropiados?
• (c) ¿Están las acciones indicadas en el modelo de control? (D-F)
• (c) ¿Están los eventos indicados en el modelo funcional? (F-D)
• (c) ¿Están todos los nombres de mensajes de escenarios definidos como operaciones de objetos?

X. Consideraciones de arquitectura

• (c) ¿Se han provisto las tres vistas del espacio del problema? (data, función y control)
• ¿Se ha examinado la jerarquía de clases para una posibilidad de volver a utilizarlo?
• ¿Se han identificado y documentado posibles frameworks?
• ¿La documentación incluye una descripción del patrón de colaboración (intra-framework protocol) del framework?
• ¿Se han especificado los límites o fronteras del sistema?

XI. Uso de nombres

• (c) ¿Existe el diccionario de datos?
• (c) ¿Están incluidos en el diccionario todos los nombres usados en los modelos y diagramas?
• c) ¿Cada nombre es único?
• (c) ¿Cada entrada del diccionario de datos tiene asociado un comentario descriptivo?
• (c) ¿Cada nombre sigue el estándar definido?

XII. Control general del documento

• (c) ¿El documento sigue un estilo estándar?
• (c) ¿El documento incluye un glosario?
• (c) ¿El documento incluye una tabla de contenido?
• (c) ¿El documento incluye un índice?
• ¿El documento presenta un uniforme nivel de detalle?
• (c) ¿Todas las convenciones de diagramas tienen labels?

XIII. Traza de requerimientos

• ¿Han sido examinados los requerimientos definidos en el documento para determinar si todas las restricciones del sistema han sido indicadas como asociaciones o han sido asignadas a operaciones?
• ¿Ha sido el documento de requerimientos examinado para identificar objetos, atributos y métodos (sustantivos, adjetivos y verbos)?
• (c) ¿Están las características del modelo anotadas con el número de requerimiento correspondiente?
• ¿Han sido todos los requerimientos usados en algunos de los modelos?

XV. Control de estructura

• Sugiere cinco modificaciones para realizar a los requerimientos. Evalúa que objetos se ven afectados por cada cambio. Juzga el valor del modelo localizando los cambios.
• Selecciona cinco escenarios para analizar. Crea los diagramas de interacción por cada uno. Detecta las situaciones donde la responsabilidad de una tarea pequeña es compartida entre varios objetos.

Referencias:

• OBJECT-ORIENTED ANALYSIS – DOCUMENT CRITERIA

Metal Tip:

Este artículo lo escribí escuchando la canción Nosferatus de la banda Iron Mask de Bélgica, les comparto el enlace.

Happy coding and Stay Heavy lml