En este resource, se especificarán unos cuantos principios básicos para documentar lo que podríamos llamar un caso de uso "bien formado", en el sentido que provea toda la información necesaria para arquitectura y desarrollo y la misma se encuentre correctamente organizada. Además, este resource también tiene por propósito definir cabalmente algunos conceptos vertidos en los casos de uso que a veces se usa de forma indistinta.
Principalmente, el analista debe proporcionar toda la información necesaria para implementar el caso de uso, organizada en los siguientes items:
Actores: enumera qué perfiles de usuario pueden ejecutar el caso de uso. Se hace siempre referencia al usuario transportador (es decir, el usuario que interactúa directamente con el sistema)
Resumen: describe el propósito del caso de uso en el ambiente del sistema. Sintetiza qué es lo que desea lograr el actor al correr el caso de uso, cuándo, por qué, para qué.
Precondiciones: validaciones que deben cumplirse para que el caso de uso se ejecute. Si estas validaciones no se cumplen, el caso de uso no se inicia.
Flujo Normal de Eventos: especifica el diálogo entre el actor (transportador) y el sistema, desde que el transportador inicia el caso de uso hasta que éste termina exitosamente. Rige el principio de "caja negra", por lo cual solo se especifican entradas (estímulos con que el usuario opera el sistema), salidas (todo lo que el sistema devuelve al usuario) y efectos (cambios producidos en el ambiente del sistema). No incluye desviaciones por validaciones ni desvíos por decisión del usuario (si el usuario puede optar por distintos caminos, se debe hacer un flujo normal por cada uno de ellos)
Flujos Alternativos: indica secuencias que puede haber en el diálogo entre el transportador y el sistema por cirsuntancias no estándares (datos incorrectos, condiciones inesperadas). Todo flujo alternativo implica que el caso de uso no pudo terminarse normalmente cumpliendo su propósito.
Validaciones: controles que se hacen sobre los datos ingresados por el usuario.
Poscondiciones: efectos causados sobre el ambiente del sistema cuando el caso de uso termina exitosamente.
Adicionalmente, el arquitecto debe incluir en el caso de uso las siguientes secciones, según sean necesarias o no (un ABML simple requeriría solamente la especificación de entidades, si es que ninguna tiene propiedades excepcionales o no se necesitan métodos específicos en los repositorios):
Entidades: referencias al modelo de dominio donde el arquitecto especifica qué clases persistentes están vinculadas al caso de uso.
Propiedades: explicación de algunas propiedades especiales que puedan tener las entidades alcanzadas en el caso de uso.
Interfaces: indicación por parte del arquitecto de métodos puntuales en los repositorios para consultas en particular que los desarrolladores deberán consumir (y eventualmente implementar) en la codificación del caso de uso.
Especificar en la sección validaciones reglas que, si no se cumplen, el caso de uso no debe ejecutarse (como ser control de permisos del usuario). Las reglas que impiden iniciar un caso de uso deben enumerarse en la sección precondiciones.
A la inversa, incluir en las precondiciones reglas que solo pueden evaluarse cuando el usuario ingresa datos durante el caso de uso y que si no se cumplen el caso de uso ejecuta por un camino alternativo (por ejemplo controlar que un producto tenga stock suficiente al cargar los datos de una factura). Los controles que dependen de datos ingresados por el usuario deben incluirse en la sección validaciones.
Incluir detalles de lógica y procesamiento en la sección flujo normal de los eventos. Los resultados y efectos que debe causar el sistema solamente se mencionan en esta sección, y en caso de implicar lógica de negocio compleja, toda esta complejidad se saca a una sección aparte del caso de uso.
Definir respuestas del sistema o flujos de eventos como poscondiciones (por ejemplo incluir como poscondición que el sistema presenta un mensaje o vuelve a una pantalla en particular). La finalización del diálogo entre el sistema y el actor debe incluirse en la sección flujo normal de los eventos. Una poscondición es, por ejemplo, insertar, borrar o modificar datos; crear usuarios o asignar permisos a un usuario; generar un archivo; provocar un cambio de estado en un objeto del sistema (por ejemplo, "el archivo queda marcado como procesado, pendiente de revisión", etc)
Especificar los criterios de validación únicamente en términos de datos obligatorios, no especificando (por ejemplo) rangos de validez. En el caso de fechas, podría ser que la misma debe ser sí o sí una fecha pasada, o bien una fecha futura. En el caso de números, podría ser que la cantidad debe ser sí o sí positiva. Incluso en algunos casos puede ser que la validación dependa de propiedades combinadas, como ser la fecha de alta de un paciente no puede ser menor a su fecha de ingreso.