archivo

Archivos diarios: enero 10, 2012

En el antipatrón “Requisitos esparcidos por la pared” nos encontrábamos en una situación de desorden general en los requisitos: podían encontrarse en distinto grado de acabado, no existía priorización de los mismos o la misma era demasiado general como para poder hacer una ordenación adecuada por ese criterio, etc…, circunstancia que normalmente era provocada por una colaboración (si es que existe) inadecuada por parte del área usuaria.

En el caso de los requisitos ocultos, el origen puede ser el equipo de proyecto o el área usuaria:

– El equipo de proyecto conocedor de la dificultad o coste de implementar un determinado requisito lo obvia dentro del catálogo de requisitos, le asigna una prioridad muy baja o lo engloba dentro de un requisito de mayor nivel quedando difuminado en el mismo. En este caso, el equipo de proyecto es el que origina el antipatrón, pero también tiene responsabilidad el área usuaria y/o el área técnica del cliente por no haber revisados los mismos de manera adecuada.

– El área usuaria no especifica un requisito o no lo especifica de manera adecuada, en algunos casos con el objeto de obstaculizar (o sabotear) el desarrollo del sistema de información y/o el trabajo del equipo de proyecto y en otros simplemente por no haber dedicado la atención adecuada en la etapa o distintas etapas (en función de la metodología) de especificación de requisitos, solicitando explicaciones a posteriori por la no implementación de ese requisito o por su comportamiento incorrecto.

Existe la tentación, cuando se hace uso de la técnica de tarjetas CRC de aprovechar e incluir en la misma la implementación de la clase (aunque sea en pseudocódigo), convirtiéndose automáticamente la tarjeta CRC (Class-Responsibility-Collaboration) en CRCI (Class-Responsibility-Collaboration-Implementation).

Pues bien, esa práctica se considera un antipatrón, ya que se considera que se puede estar perdiendo el tiempo realizando la implementación de una clase, cuando todavía no está totalmente diseñado el sistema y por tanto no se tiene una visión todavía a nivel de detalle del mismo, lo que obligará más que probablemente a tener que rehacer la implementación especificada en la tarjeta en reiteradas ocasiones.

La utilización de tarjetas CRC (Class-Responsibility-Collaboration) es una técnica de diseño orientado a objetos propuesta por Kent Beck (introductor de la metodología de programación extrema) y Ward Cunningham (también muy conocido entre otras muchas materias, por sus aportaciones a dicha metodología).

El objetivo de la misma es hacer, mediante tarjetas, un inventario de las clases que vamos a necesitar para implementar el sistema y la forma en que van a interactuar, de esta forma se pretende facilitar el análisis y discusión de las mismas por parte de varios actores del equipo de proyecto con el objeto de que el diseño sea lo más simple posible verificando las especificaciones del sistema.

Un esquema típico de tarjeta CRC puede ser aquel en el que se indiquen los siguientes datos:

– Nombre de la clase.
– Nombre de las superclases y subclases (si procede).
– Las responsabilidades de la clase.
– Las clases con las que va a colaborar para poder realizar las responsabilidades indicadas.
– Autor, fecha, etc…

Este antipatrón se basa en la utilización dentro de un mismo sistema de diferentes “clases de propósito general”, “clases hombre-orquesta” o “clases multicasuística” en las cuales están definidos una amplia gama de comportamientos con el objeto de poder ser utilizados por otras.

También es frecuente encontrarlo en implementaciones de componentes en los que se delegan funcionalidades de otros, con el objeto de dar un amplio rango de alternativas posibles al cliente.

El problema no es dar esas facilidades, sino que el problema se encuentra en la complejidad que se le añade al código como consecuencia de las mismas (generalmente alto acoplamiento, baja cohesión, alta complejidad ciclomática, etc…).

En el antipatrón “objeto todopoderoso“, la funcionalidad de la aplicación pivota generalmente sobre una de estas clases, mientras que en la navaja suiza se trata de diferentes clases (generalmente, de utilidad) que contiene el sistema.