Buscar en Gazafatonario IT

viernes, diciembre 22, 2006

Lecturas Fundamentales 5 (2 de 2)

Lectura Fundamental Anterior: “Casos de Uso: ¿Cuándo Están Terminados? ... ¿Y qué hacer con ellos a continuación?” Parte 1

Lectura # 5
Casos de Uso: ¿Cuándo Están Terminados?... ¿Y qué hacer con ellos a continuación? Parte 2 de 2
Previamente en Lecturas Fundamentales…

En la parte 1 de este artículo enunciaba mi Ley de la Terminación del Caso de Uso. Decía que un caso de uso está terminado cuando se cumplen al menos diez de trece condiciones. Las primeras seis condiciones a las que me refería son:
1. ¿El caso de uso tiene especificado el Actor que lo inicia?
2. ¿El caso de uso ha sido leído y entendido por todos los interesados en el mismo, incluyendo representantes de los usuarios finales y los programadores del mismo?
3. ¿La secuencia de comunicación entre el actor y el caso de uso cumple con las expectativas del usuario?
4. ¿Está claro cómo y cuándo comienzan y terminan los flujos de eventos del caso de uso?
5. ¿Los subflujos en el caso de uso están modelados con precisión?
6. ¿Está claro quién quiere ejecutar el caso de uso? ¿El propósito del caso de uso también está claro?
Y aportaba algunos elementos de criterio para hacer la revisión con cada uno de esos puntos. Bien, estas son las demás:
¿Las interacciones del actor y la información intercambiada están claras?
¿Es comprensible la forma como el actor proporciona datos al sistema mediante el caso de uso y qué datos suministra? Esto es, establecer si el actor debe seleccionar de una lista o debe digitar el dato o debe escoger una de un conjunto de posibles opciones; o si debe especificar la ruta o la dirección de un archivo de datos o si debe autorizar la carga de información mediante un proceso.
También debe hacerse evidente el tipo y mecanismo de validación, si existe, para cada dato intercambiado con el sistema. En este contexto, “hacerse evidente” quiere decir “especificar o documentar”, que sea explícito en el caso de uso. No porque algo nos parezca evidente, como especificadores de requisitos, le parecerá evidente a los demás, hay que hacerlo incuestionable, axiomático.
¿La descripción breve ofrece un cuadro verdadero del caso de uso?
Aunque la descripción breve no hace parte de la funcionalidad establecida en el caso de uso, ésta debe brindar a los lectores del mismo una visión horizontal, concisa, que permita formar imágenes mentales precisas de lo que hace el caso de uso y hasta un bosquejo del mismo.
Durante la fase de exploración del proyecto, la fase de Concepción o Inicio, cuando se descubren los casos de uso, la descripción breve del caso de uso juega un papel muy importante no solo para los analistas y usuarios, sino para el Arquitecto del Software, que cuenta con que le facilitemos de estas descripciones para que comience a elaborar la arquitectura del producto, al menos, la arquitectura preliminar, o para que tome decisiones acerca de llevar a cabo pruebas de concepto o no.
¿La secuencia básica del caso de uso tiene un número de pasos pequeño? (Menos de 20)
El límite puede ser 20, 15, 25, 17, 13, 23. “Pequeño” es un término relativo, eso lo sabemos de sobra. Puede haber casos de uso “grandes”, de 30, 50 ó 70 pasos; sin embargo, éstos deben ser la excepción. Además, el tamaño es un índice de complejidad, pero no es el único. Y siempre puede suceder que un caso de uso de 50 pasos sea sencillo y uno de 10 pasos sea complejo.
En cualquier caso, cuando el número de pasos de un caso de uso empieza a crecer, debemos también comenzar a pensar en que quizás se pueda dividir. De hecho una de los lineamientos a seguir para crear casos de uso incluidos es precisamente la máxima de “divide y vencerás” que, en esta oportunidad, podríamos traducir como “divide y entenderás.”
Definición 12. Un caso de uso incluido es aquel cuyo comportamiento (funcionalidad) puede ser insertado en el comportamiento definido para otro caso de uso, llamado caso de uso base.
La inclusión, junto con la extensión y la generalización, son las relaciones que pueden existir entre casos de uso. En una lectura fundamental posterior les hablaré en detalle de este tema de las relaciones entre casos de uso.
¿Está claro que el caso de uso no se puede dividir en dos o más casos de uso?
En la lectura fundamental #1 anotaba que, desde el punto de vista del usuario, un caso de uso es una pieza indivisible de software, simple, con un objetivo exacto y único.
Siempre debemos buscar estas características en el caso de uso. Si observamos que el caso de uso hace varias tareas desacopladas, si la complejidad de algunas de sus acciones lo hace incomprensible para los usuarios o aún para los desarrolladores, si tiene un número excesivo de pasos o de secuencias alternativas, si la profundidad de las anidaciones (decisiones lógicas o ciclos) es mayor de dos (por ejemplo, si hay secuencias alternativas que se derivan no de la secuencia básica o principal, sino de otra secuencia alternativa), si parte de las acciones de un caso de uso se puede “ocultar” deliberadamente (en casos de uso incluidos) sin que se afecte el matiz que se obtenga de su lectura, si para entender el caso de uso se hace necesario acompañarlo de adjuntos como prototipos de usuario, manifiestos en prosa sobre la funcionalidad del caso de uso u otros elementos de diseño, entonces seguramente será necesario fraccionar la especificación en dos o más casos de uso.
Sí, otra vez, simplicidad es la clave.
¿Para un caso de uso incluido: se probó que si se modifica el caso de uso que lo incluye, el caso de uso incluido no se afecta?
En términos generales, un caso de uso incluido no es autónomo en cuanto a que por sí solo no entrega un resultado de valor observable para el actor. Esto lo convierte en dependiente del caso de uso base.
A pesar de tal interdependencia, el comportamiento de un caso de uso incluido no debe verse sobre-influido por un cambio al caso de uso base, sobre todo, cuando la razón de la inclusión es una factorización en la funcionalidad de varios casos de uso, es decir, distintos casos de uso tenían una funcionalidad común que se eliminó de éstos y se incluyó en un único caso de uso incluido por todos los demás.
De esta forma, si al modificar la funcionalidad de uno de los casos de uso, se acomete contra la funcionalidad “incluida”, todos los casos de uso que la usan deben someterse a una minuciosa inspección con el fin de mantener la consistencia en el modelo funcional o de casos de uso.
¿Cada caso de uso es independiente del resto?
Es realmente necesario abordar este chequeo con un pensamiento sistémico que nos permita no sólo modelar el producto sino también obtener varias perspectivas del modelo.
En particular, al revisar las interrelaciones de los casos de uso en los distintos modelos del sistema, el resultado debe ser uno que exhiba bajo acoplamiento y alta cohesión. Bajo acoplamiento quiere decir que hay poca o ninguna interdependencia entre el caso de uso y su entorno (otros casos de uso u otros actores distintos al que ejecuta este caso de uso). Entre tanto, el principio de alta cohesión señala que el caso de uso ejecuta una tarea simple y precisa y alcanza un objetivo predeterminado. En este contexto, los casos de uso a los que me refiero son casos de uso concretos, ejecutados por actores del sistema; esto excluye, si me permiten la disfunción, a los casos de uso incluidos y a los abstractos o generalizados. Estos últimos son aquellos que no se implementan, pero que existan para estabilizar el modelo y entenderlo mejor.
Este, que es un patrón común de diseño heredado cuidadosamente de las técnicas estructuradas de programación de computadores, requiere tanto un enfoque de bajo nivel para verificar el acoplamiento, como un punto de vista más alto para cotejar la cohesión. De allí la necesidad de hacer cálculos holistas con los elementos funcionales del sistema, o sea, con los casos de uso.
¿Este caso de uso hace algo muy parecido a otro caso de uso?
De ser así, quizás deberían convertirse ambos en un único caso de uso.
Ocurre mucho con los casos de uso descompuestos funcionalmente, que deberíamos evitar. Estos tienden a parecerse, porque, por ejemplo, uno es para adicionar un elemento y el otro es para actualizar los datos de ese elemento, digamos un producto o un cliente.
Pero en casos de uso no descompuestos funcionalmente también suele suceder, sobre todo, cuando obtenemos la visión de un rango heterogéneo de usuarios y cada uno de ellos expresa sus necesidades de acuerdo a sus criterios y ambiente de trabajo. Reservar Vuelo y Comprar Tiquete quizás sean dos casos de uso distintos, pero también pueden llegar a convertirse en uno solo, dependiendo de la meta que se quiera alcanzar con uno u otro.
¿Y qué hacer con los casos de uso una vez están terminados?
Realmente no es necesario terminar un caso de uso para continuar con su ciclo de vida. Desde la descripción breve y el esbozo que se obtiene durante la fase de Inicio del proyecto, ya es posible empezar a hacer el análisis y diseño del caso de uso. En este punto ya también el arquitecto puede considerar distintas variables para seleccionar los casos de uso más críticos o complejos para la arquitectura del software, aquellos que definen las bases del producto a construir.
Más adelante, durante cada una de las iteraciones, al completar la secuencia básica es factible diseñar prototipos, “realizar” los casos de uso y comenzar a implementarlos. Y también es posible diseñar los casos de prueba.
Todos estos eventos subsiguientes a la especificación de un caso de uso, serán temas que ocuparán nuestras lecturas fundamentales durante 2007.
Hasta entonces y feliz navidad.

Lectura Fundamental Siguiente: De Procesos y de Humanos.

lucho.salazar@gmail.com

No hay comentarios.:

Publicar un comentario