Desarrollo
Ayudar a comunicar los requerimientos a un alto nivel.
También ayuda a los grupos de interés a ver qué está dentro del alcance y qué
esta fuera.
Consejo: 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.
Consejo: Vaya con la corriente
Un caso de uso debería tener un único flujo principal y
múltiples flujos alternativos. El flujo principal explica que sucede cuando
todo sucede de forma correcta y el caso de uso cumple con su objetivo. Flujos
alternativos explican que sucede cuando algo causa una desviación desde el
flujo principal. Estas desviaciones pueden ser o no etiquetadas como
excepciones o errores.
Las referencias permiten a los usuarios reconstruir la
historia completa esto es realizable utilizando referencias, lo que
esencialmente define el comienzo y fin de un flujo alternativo, al
señalar un paso en particular en el flujo principal o en otro flujo
alternativo.
Consejo: 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. Es
recomendado que no utilice referencias en el flujo principal, que podrían
llevar al usuario a un flujo alternativo o a otro caso de uso si una condición
específica ocurre. Centrarse en el “camino feliz” mantiene el flujo simple
y fácil de leer, y comunica claramente qué sucede cuando el caso de uso ha sido
exitoso.
Consejo: Los
escenarios cuentan la historia completa
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.
Consejo: Sea
cuidadoso con las sentencias “if”
Esto puede resultar negativo para la legibilidad -
puede resultar difícil seguir un flujo de múltiples sentencias “if” a
través del texto. También resulta negativo para el diseño y prueba del sistema.
Es mejor, tanto para el lector, como para el proyecto, que rompa cada “if” en
su propio flujo. Se obtienen más flujos, pero el cambio vale la pena.
Consejo: Especificar
elecciones (opciones) del actor
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.
Consejo: Aleja el
CRUD
El peligro es la necesidad de manejar la complejidad
exponencial que a menudo se crea, resultando en comportamientos repetitivos innecesarios,
y, a la larga, casos de uso con valor mínimo. En vez de eso, trate de centrarse
en lo que el actor realmente quiere hacer, lo que generalmente no tiene
relación con las acciones de Crear, Leer, Actualizar y Borrar (CRUD).
Consejo: La secuencia
de los eventos puede ser opcional
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 pasó” a una línea. El punto es, usted no
quiere restringir a los diseñadores del sistema teniendo requerimientos
temporales implícitos cuando no son realmente necesarios.
Consejo: Utilice el
nivel correcto de detalle
De manera similar, los detalles arquitectónicos deben ser
evitados. Por ejemplo, en el modelo de registro de cursos, una sentencia como
“el horario es guardado en la base de datos SQL Server” no debería ir en un
caso de uso.
Consejo: 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.ESCRITO POR FELIPE SANDOVAL
No hay comentarios:
Publicar un comentario