El modo ordinario
Este modo exige mucho más trabajo que el modo resumen, pero no alcanza el nivel de rigor del modo formal.
El caso de uso se identifica con un nombre y se cita expresamente al actor principal. Seguidamente, se relatan los pasos del escenario principal y se identifican las extensiones mediante un nombre. Adicionalmente, se puede añadir una sección de requisitos especiales con los requisitos no funcionales relacionados.
Caso de uso: Efectuar reintegro. Actor principal: Usuario. Pasos: 1. El usuario introduce la tarjeta. 2. El cajero valida la tarjeta. 3. El usuario introduce su número de identificación personal (PIN). 4. El cajero valida el PIN. 5. El usuario introduce una cantidad de dinero. 6. El cajero valida la cantidad. 7. El usuario confirma la cantidad. 8. El cajero descuenta la cantidad del saldo. 9. El cajero entrega el dinero. 10. El usuario retira el dinero. 11. El cajero expulsa la tarjeta. 12. El usuario retira la tarjeta. Extensiones: E01. Tarjeta inválida. E02. PIN inválido. E03. Cantidad de dinero fraccionada. E04. Usuario no responde. E05. Dinero insuficiente en cajero. E06. Dinero insuficiente en cuenta. E07. Efectivo no retirado. E08. Tarjeta no retirada. E09. Tarjeta atascada. E10. Pérdida de conexión. Requisitos especiales: El cajero debe realizar toda validación en menos de 500 ms.
Para detallar el escenario principal es conveniente seguir este esquema:
1. Buscar la precondición bajo la cual se ejecuta el escenario, es decir, una condición que el sistema debe asegurar que se cumpla antes de que el caso de uso dé comienzo. Hay que pensar en condiciones simples sobre el estado del sistema en el momento en el que el caso de uso se vaya a iniciar como «El cajero está en modo espera» o «El cajero está en modo mantenimiento». Tampoco es raro que la condición haga referencia a un caso de uso que se tenga que ejecutar previamente.
Es importante no cometer el error de pensar en condiciones que no sean ciertas durante todo el transcurso del caso de uso. Una condición como «El cajero dispone de efectivo suficiente» quizá sea necesaria para ejecutar el escenario principal, pero dado que no se puede asegurar su cumplimiento ─razón por la cual aparece la extensión «E05. Dinero insuficiente en cajero»─ no es una precondición válida.
Adicionalmente, junto con la precondición propiamente dicha, puede pensarse en el suceso concreto que va a a poner en marcha el caso de uso. Dicho suceso se corresponde habitualmente con el primer paso del escenario («1. El usuario introduce la tarjeta»), pero también puede ser algo que ocurra antes. Por ejemplo, un caso de uso como «Enviar registro de actividad» puede estar vinculado al suceso «Son las 05:00 horas».
Si se cree conveniente, la condición puede dejarse escrita en un epígrafe llamado «Precondición».
2. Determinar el objetivo del actor y hacerlo coincidir con el nombre del caso de uso.
3. Escribir la secuencia de pasos que forma el cuerpo del escenario. Realmente nada impide que la secuencia no sea tal, es decir, si es necesario indicar que dos pasos se ejecutan en paralelo, que alguno se repite o incluso que otro es opcional, puede indicarse con algún tipo de nota o etiqueta. Los pasos se enmarcan dentro de tres tipos:
- Acciones del actor principal: «1. El usuario introduce la tarjeta».
- Validaciones del sistema: «4. El cajero valida el PIN».
- Cambios internos del sistema: «8. El cajero descuenta la cantidad del saldo».
Al final, un paso no debe ser más que una acción simple que describa la tarea que realiza el actor o cómo éste pasa información a otro actor. Para ello, debe usarse una gramática sencilla. El español tiene una sintaxis mucho más flexible que otras lenguas, lo cual puede ser una bendición para el lenguaje verbal pero una maldición para el lenguaje escrito de carácter técnico. Es recomendable seguir la sintaxis sujeto + verbo + complementos y utilizar el presente de indicativo.
4. Determinar la condición final. Pensar en aquello que hace cumplir el objetivo del actor: «El usuario tiene el dinero».
Una vez se han terminado de detallar los pasos del escenario principal debe decidirse qué hacer con la extensiones. Como se expuso al principio, una extensión no es más que un desvío del comportamiento normal del caso de uso provocado por una condición particular.
Existen dos formas de abordar las extensiones:
Si el caso de uso es secundario o se tiene el suficiente conocimiento como para proceder a la realización de la extensión simplemente por su nombre, se puede incluir un pequeño párrafo debajo del título de la extensión con algún detalle relevante o, sencillamente, no hacer nada más. Por ejemplo:
Caso de uso: Efectuar reintegro. … Extensiones: … E03. Cantidad de dinero fraccionada. Cantidad que no puede alcanzarse mediante la suma de billetes de 10, 20 y 50 €.
Por el contrario, si se considera que la extensión necesita de un nivel de detalle similar al del escenario principal, proceda a relatar sus pasos como se indica a continuación.
1. Buscar la condición bajo la cual el sistema adopta un comportamiento diferente y hacerla corresponder con el primer paso de la extensión. Escribir este primer paso debajo del título de la extensión y numerarlo de igual forma que el paso del escenario principal respecto al que se produce la alternativa seguido de una letra. Por ejemplo:
Caso de uso: Efectuar reintegro.
Actor principal: Usuario.
Pasos:
…
4. El cajero valida el PIN.
…
Extensiones:
…
E02. PIN inválido.
4a. El cajero rechaza el PIN.
Recuerde que la extensión se lee como «no es cierto que el cajero valida el PIN sino que el cajero rechaza el PIN». Como la alternativa se produce en el paso 4 del escenario principal, el primer paso de la extensión también se numero con 4 y se le añade la letra a que inicia una nueva lista, alfabética en este caso.
Es posible que una misma extensión tenga más de una condición. Cuanto más inconcreto sea el paso del escenario principal, más posibilidades habrá de que esto suceda. No obstante, incluso cuando el paso es preciso, es fácil que aparezcan varias condiciones que den lugar a acciones diferentes.
Extensiones:
…
E02. PIN inválido.
4a. El cajero rechaza el PIN por primera o segunda vez.
4b. El cajero rechaza el PIN por tercera vez.
La extensión «E02. PIN inválido» ahora tiene dos condiciones. Fíjese como la segunda continua la lista alfabética al numerarse como 4b. Aunque esencialmente ambas condiciones son la misma (el PIN no ha podido validarse) introducen más información que en el ejemplo previo, síntoma inequívoco de que el cajero va a reaccionar de forma distinta en función de una u otra.
2. Determinar el objetivo a alcanzar. Puede ser el mismo que el objetivo del escenario principal o aquel que determine como se va a gestionar la condición inicial para que la extensión termine uniéndose con el escenario principal.
Cuando el objetivo es el mismo que el del escenario principal, se señala una alternativa que también conducirá a que el actor cumpla con su objetivo. Por ejemplo, en un caso de uso como «Comprar artículo» es normal que haya extensiones que cubran las diferentes formas de pagarlo (efectivo, tarjeta, cheque) y todas terminarán cumpliendo el objetivo del actor.
Por el contrario, cuando la extensión termina volviendo al escenario principal, se está indicando cómo salvar un problema para dar la oportunidad al actor de seguir con su objetivo, como en el paso 4a.
Caso de uso: Efectuar reintegro.
Actor principal: Usuario.
Pasos:
…
3. El usuario introduce su número de identificación personal (PIN).
4. El cajero valida el PIN.
…
11. El cajero expulsa la tarjeta.
Extensiones:
…
E02. PIN inválido.
4a. El cajero rechaza el PIN por primera o segunda vez.
4a1. Ir al paso 3.
4b. El cajero rechaza el PIN por tercera vez.
4b1. Ir al paso 11.
3. Escribir la secuencia de pasos que forman el cuerpo de la extensión sangrando y numerando dichos pasos a partir de la numeración del primero. Véase el ejemplo anterior.
4. Determinar la condición final. Normalmente es la misma que el escenario principal. Sin embargo, habrá veces que el caso de uso termine sin cumplir con el objetivo del actor.
La condición final de 4a es la misma que el escenario principal («El usuario tiene el dinero») porque la extensión termina uniéndose con dicho escenario. Por el contrario, la condición final de 4b es devolver la tarjeta al usuario (paso 11) ante la imposibilidad de cumplir con el objetivo.
El modo formal
Como podrá imaginarse, una de las características de este modo es que todas las extensiones deben detallarse mediante una secuencia de pasos. Adicional y previamente a los pasos del escenario principal, deberán incluirse los siguientes epígrafes junto con los vistos hasta ahora (el nombre del caso de uso y el actor principal):
- Nivel. Existen dos niveles: objetivo o subfunción. El primero se refiere a los casos de uso encuadrados dentro del tipo visto hasta ahora, es decir, aquellos que hacen cumplir el objetivo de un actor; el segundo describe aquellas secuencias de acciones que es necesario detallar como complemento a un caso de nivel objetivo. Por ejemplo, el paso «4. El cajero valida el PIN» del caso «Efectuar reintegro» de nivel objetivo podría dar lugar a un caso de uso de nivel subfunción como «Validar PIN» que detalle qué debe ocurrir ─qué secuencia de acciones son necesarias─ para comprobar que el PIN es correcto. En la próxima entrega de la serie, donde se aborda cómo estructurar el modelo de casos de uso, se verá algún ejemplo.
- Precondiciones. Se abordaron en el primer punto del esquema empleado para detallar el escenario principal. Señalan algo que debe ser cierto antes de que el caso de uso dé comienzo y que el sistema debe comprobar. Las precondiciones se asumen como ciertas durante toda la secuencia de pasos de todos los escenarios, pero esto no implica escribir condiciones obvias para el lector como «el cajero está encendido». Es fácil que una precondición está ligada a la ejecución previa de otro caso de uso.
- Postcondiciones. Indican aquello que debe ser cierto cuando el caso de uso finalice cumpliendo el objetivo del actor. Por ejemplo, un par de postcondiciones razonables para el caso de uso «Efectuar reintegro» podrían ser: reintegro registrado y vuelta al modo espera. Fíjese que ambas son irrelevantes para el actor principal pero no para otros interesados en el desarrollo del cajero, como la entidad financiera. Por tanto, piense en las postcondiciones como hechos que satisfagan los intereses de otras partes interesadas en el correcto funcionamiento del sistema y no del actor, pues para eso está el caso de uso en sí.
- Desencadenante. Indica el suceso que pone en marcha el caso de uso. Hay sucesos que antecederán al primer paso del escenario principal y otros coincidirán exactamente con él. En este último caso el epígrafe debe omitirse porque no aporta nada.
- Requisitos especiales. Proporciona información adicional relevante de tipo no funcional, es decir, aquí se incluyen los requisitos no funcionales vinculados al caso. Nunca deben tratarse este tipo de requisitos en la secuencia pues distraerá al lector. Si existe la necesidad de incorporar información no funcional de otra índole como la especificación de la interfaz de usuario, problemas detectados, restricciones impuestas, reglas de negocio o diccionarios de datos, debería elaborarse en documentos aparte y asociarlos al caso de uso.
- Variantes tecnológicas. A veces es conveniente indicar las diferentes formas de hacer algo. Con esta afirmación no me estoy refiriendo a señalar qué alternativas distintas puede tomar el sistema, pues para eso se escriben la extensiones, sino cómo éstas pueden hacerse de manera diferente. Habitualmente, la razón para hacerlo viene dada porque es necesario hacer constar que una misma cosa puede realizarse con distintas variantes tecnológicas y formatos de datos. Por ejemplo, el paso «1. El usuario introduce la tarjeta» puede tener dos variantes tecnológicas: usar un lector de banda magnética y usar un lector de microchips.
- Dudas. Cualquier aspecto que deba aclararse. Lo más normal es que las dudas surjan cuando se esté detallando el caso. Son cuestiones relativas al dominio o a un abanico de posibilidades ─todas válidas─ que debería acotar el cliente.
A continuación se detalla el caso de uso «Efectuar reintegro» usando el modo formal. Por favor, tenga en cuenta que el ejemplo no pretende ser exhaustivo. En un proyecto real, un caso de uso como éste puede estar todavía más detallado.
Fíjese que en las dos primeras extensiones los pasos no están vinculados a un paso concreto del escenario principal sino que empiezan con un asterisco. Esta es la forma de indicar que la condición que desencadena la extensión puede ocurrir en cualquier momento.
Caso de uso: Efectuar reintegro.
Actor principal: Usuario.
Nivel: Objetivo.
Precondiciones: El cajero está en modo espera.
Postcondiciones: Reintegro registrado. Vuelta al modo espera.
Pasos:
1. El usuario introduce la tarjeta.
2. El cajero valida la tarjeta.
3. El usuario introduce su número de identificación personal (PIN).
4. El cajero valida el PIN.
5. El usuario introduce una cantidad de dinero.
6. El cajero valida la cantidad.
7. El usuario confirma la cantidad.
8. El cajero descuenta la cantidad del saldo.
9. El cajero entrega el dinero.
10. El usuario retira el dinero.
11. El cajero expulsa la tarjeta.
12. El usuario retira la tarjeta.
Extensiones:
E01. Usuario no responde.
*a. El cajero detecta que han transcurrido 40 segundos desde la última acción del usuario.
*a1. El cajero archiva la tarjeta.
*a2. Fin del escenario.
E02. Pérdida de conexión.
*b. El cajero detecta una pérdida de conexión con el ordenador central.
*b1. El cajero informa de problemas técnicos.
*b2. Ir al paso 11.
E03. Tarjeta inválida.
2a. El cajero no puede leer la tarjeta.
2a1. El cajero informa de posibles daños en la banda magnética.
2a2. Ir al paso 11.
2b. El cajero detecta que la tarjeta está caducada.
2b1. El cajero informa de la caducidad de la tarjeta.
2b2. Ir al paso 11.
E04. PIN inválido.
4a. El cajero rechaza el PIN por primera o segunda vez.
4a1. Ir al paso 3.
4b. El cajero rechaza el PIN por tercera vez.
4b1. Ir al paso 11.
E05. Cantidad de dinero fraccionada.
6a. El cajero detecta que la cantidad no es múltiplo de una suma de billetes de 10, 20 y/o 50 €.
6a1. Ir al paso 5.
E06. Dinero insuficiente en cajero.
6b. El cajero detecta que la cantidad introducida es superior a la disponible.
6b1. El cajero informa de la cantidad máxima que se puede reintegrar.
6b2. Ir al paso 5.
E07. Dinero insuficiente en cuenta.
7a. El cajero detecta que la cantidad solicitada es mayor que el saldo disponible.
7a1. El cajero informa de la cantidad máxima que se puede reintegrar.
7a2. Ir al paso 5.
E08. Efectivo no retirado.
10a. El cajero detecta que han pasado 30 segundos desde la entrega del dinero.
10a1. El cajero recoge el dinero.
10a2. El cajero suma la cantidad recogida al saldo.
10a3. Fin del escenario.
E09. Tarjeta atascada.
11a. El cajero detecta que no se puede expulsar la tarjeta.
11a1. El cajero informa que la tarjeta no se puede expulsar y cómo recuperarla en la entidad.
11a2. Fin del escenario.
E10. Tarjeta no retirada.
12a. El cajero detecta que han pasado 30 segundos desde la entrega de la tarjeta.
12a1. El cajero recoge la tarjeta.
12a2. El cajero archiva la tarjeta.
12a3. Fin del escenario.
Requisitos especiales:
* El cajero debe realizar toda validación en menos de 500 ms.
Variantes tecnológicas:
1a. Lector de banda magnética y lector de microchips.
Dudas:
* ¿El cajero puede dispensar billetes de 100 €?
* La actualización del saldo debe efectuarse ¿cuándo el cajero entrega el dinero o cuándo el usuario lo retira?
