TIPS IBM Casos de Uso - Tarea 3

1.- No olvide el Diagrama 
 Los casos de uso son representados gráficamente como óvalos en los diagramas de casos de uso, y estos son también expresados como especificaciones textuales. El texto es definitivamente la esencia del modelo de caso de uso, y ciertamente puede beneficiarse de escribir el texto sin dibujar el diagrama. Sin embargo, el diagrama puede ayudar a comunicar los requerimientos a un alto nivel. 
 2.- Los actores humanos son el elemento más importante 
 Las figuras de palo utilizadas en los diagramas de caso de uso son aludidos como los actores. Ellos indican cualquier persona (o rol), otro sistema o quizás inclusive un dispositivo fuera del sistema que se está construyendo y que interactúa con él. Es el actor humano el que representa las interacciones mas interesantes y difíciles para la mayoría de los sistemas, y las interacciones humano/sistema son donde el verdadero valor de los casos de uso viene a la perspectiva. 
 3.-Vaya con la corriente 
 Buenos casos de uso no son sólo párrafos de texto claro y conciso. Ellos poseen una estructura que definen como las partes de un caso de uso calzan juntas. Y ellos pueden ser estructurados en muchas formas- referidos como un estilo de casos de uso. 
 4.- Colocar referencias en los flujos alternativos, no en los flujos principales 
El flujo principal muestra que sucede cuando todo en el caso de uso sucede de la forma correcta, y el usuario alcanza su objetivo. Incluye una serie de pasos (eventos) ordenados en orden cronológico que explican los que el sistema hace y lo que el actor realiza para llevar a cabo el caso de uso. Las referencias son simples sentencias sobre donde inicia un flujo y como y donde termina. 
 5.- Los escenarios cuentan la historia completa 
 Los actores no pueden ejecutar flujos alternativos, pero pueden ejecutar escenarios. El concepto de escenario puede ser confuso porque las personas definen los escenarios de maneras muy distintas. En IBM, nosotros los definimos simplemente como los caminos a través de un caso de uso o como una serie de pasos y flujos que un actor podría tomar – de inicio a fin- a través de un caso de uso para proveer un resultado. Dados los muchos flujos alternativos posibles, habrá muchos escenarios, con muchos resultados – ambos, positivos y negativos-.
 6.- Sea cuidadoso con las sentencias “if” 
 Los profesionales de las Tecnologías de Información (TI), particularmente aquellos con experiencia en programación, están familiarizados con las sentencias “if”, y por lo general puede observar dichas sentencias usadas en casos de uso. Un “if” en lenguajes de programación especifican comportamientos condicionales, y eso usualmente es verdad en los casos de uso también. Los problemas surgen cuando existen uno o más “if” en un flujo, ya que usualmente significa que se están especificando múltiples requerimientos. 
 7.- Especificar elecciones (opciones) del actor 
 Los actores generalmente realizan elecciones en los casos de uso. Considere el ejemplo de un sistema de registro de una universidad siendo definido en caso de uso “Registro para cursos”. En este ejemplo, un flujo principal podría ser: 1) Crear un horario, 2) modificar un horario y 3) Eliminar un horario. A menudo los escritores de casos de uso tratarán de usar sentencias “if” para mostrar al actor tomar una elección, pero por razones indicadas anteriormente, está podría no ser la mejor idea. Una mejor alternativa es tener todas las elecciones (opciones) del actor listadas en el punto apropiado, y tener una opción seleccionada y asignada al flujo actual y las otras repartirlas en flujos alternativos. Esta técnica mantiene cada flujo simple y reduce las ramificaciones. 
 8.- Aleja el CRUD 
 A menudo vemos a escritores dirigir las opciones del actor creando casos de uso separados para cada opción. Es una solución tentadora pero a la vez peligrosa. El peligro es la necesidad de manejar la complejidad exponencial que a menudo se crea, resultando en comportamientos repetitivos innecesarios 
9.- La secuencia de los eventos puede ser opcional 
 Hemos dicho que los pasos en los casos de uso, usualmente están ordenado cronológicamente, pero se debe considerar si el orden de los pasos es un requerimiento. Por ejemplo, ¿El actor tiene que haber completado el paso cuatro antes de completar el paso cinco?, generalmente la respuesta sería SI, pero no siempre. Es una cosa muy simple, al desarrollar el texto de un caso de uso, para aclarar cualquier restricción temporal, agregue comentarios como este “Este paso pude ocurrir en cualquier orden” o “Este paso puede ocurrir en cualquier momento antes que este paso” a una línea. 
 10.- Póngase en los zapatos del actor 
 Los casos de uso son diferentes con respecto al uso de sentencia “deberá”. Dado que ellos especifican pasos ordenados cronológicamente, ellos crean más contexto que las autónomas sentencias “deberá”, las cuales no son temporales. Es por esto que ellos son más reflexivos para la experiencia de los usuarios planeados. Tenga esto en mente. Si los casos de uso son requerimientos (y lo son), los diseñadores y desarrolladores estarán restringidos por lo que ellos dicen. Recuerde esto, sienta pena por el actor y escriba sus casos de uso de una forma que haga que el sistema sea lo más simple posible para el usuario.