¿Qué son los actores y cómo identificarlos?
Actor es algo o alguien fuera del
Sistema que interactúa con el Sistema.
Un actor especifica un rol que
alguna entidad externa adopta cuando interactúa con el sistema directamente.
Puede representar un rol de usuario o un rol jugado por otro sistema o
hardware que toca la frontera del sistema. [NEUSTADT]
La siguiente es la lista de
preguntas que permiten identificar a los actores que interactuarán con el
Sistema:
-
¿Quién o qué utiliza el Sistema?
-
¿Qué roles toman en la
interacción?
-
¿Quién toma información del
Sistema?
-
¿Quién provee información al
Sistema?
-
¿En qué parte de la compañía es
utilizado el Sistema?
-
¿Quién instala, soporta y
mantiene el Sistema?
-
¿Quién inicia y termina la
ejecución del sistema?
-
¿Qué otros sistemas utilizan el
Sistema?
-
¿Ocurre algo en algún momento
específico?
La siguiente es la tabla que
describe a los actores del sistema. El código del actor reseñado como ACT.#
se refiere al prefijo ACT. seguido por el número de actor asignado. La
descripción se refiere a una breve reseña del rol del actor para el sistema
y las fuentes son los involucrados del negocio que ayudaron a definir y
describir al actor.
|
Actor |
ACT.# Nombre
del Actor
|
|
Descripción |
<descripción del actor>
|
|
Responsabilidades |
-
<Responsabilidad 1>
-
<Responsabilidad 2>
|
|
Fuentes |
<Stakeholders que
identificaron y contribuyeron a definir al actor> |
¿Cómo se hace el
Diagrama de CU?
El diagrama de CU ofrece la visión
global que cuenta lo que hay afuera del sistema y lo que hay adentro del
sistema. Esto es, especifica las fronteras del sistema.
El aspecto de diagramas de casos de
uso para sistemas batch varía con respecto a los empleados para interfaces
con usuarios.
El diagrama de CU no debe reflejar
ni el flujo de control ni el flujo de datos, sino de asociaciones que son
canales de comunicación.
Los casos de uso reflejan las
relaciones entre los actores y los casos de uso.
Tampoco se trata de diseño.
Cuando la comunicación es iniciada
por el actor, la relación de comunicación contiene una flecha hacia el lado
del CU. Si no la contiene entonces el CU es quien solicita al actor de la
interacción.
Que un sistema invoque a un actor
para alguna función solo ocurre con el caso de actores no humanos (otros
sistemas), y nunca ocurre que el CU por sí solo invoca al actor, siempre
tiene que haber un actor que solicite su activación, considere que si esto
no ocurre, probablemente lo que Ud. esté tratando de modelar no sea un CU.
Arlow y Neustadt sugieren la incorporación de un actor llamado tiempo para
cuando un CU es disparado no por la interacción directa de un actor sino
cada cierto período de tiempo, ejemplo, «CU.1 Recolectar información de
campo»: Breve descripción «Cada 5 minutos el sistema dispara
automáticamente este CU que se comunica con los dispositivos de campo para
solicitar información».
¿Qué son Casos de Uso y cómo identificarlos?
Los Casos de Uso representan lo que
un actor desea que haga el Sistema. Los casos de uso definen una secuencia
de acciones ejecutadas por un sistema que producen un resultado observable
de valor para un actor.
En el libro “The UML Reference
Manual” de RUMBAUGH se definen los casos de uso como: la especificación de
secuencia de acciones, incluyendo variaciones a la secuencia y secuencia de
los errores, que un sistema, subsistema o clase realizan con la interacción
de actores externos.
Los casos de uso son siempre
iniciados por un actor y son escritos desde el punto de vista del actor.
La siguiente es la lista de
preguntas que permiten identificar los casos de uso dentro de las fronteras
de un sistema:
-
¿Qué funciones del sistema son
requeridas por un actor específico?
-
¿El sistema guarda o recupera
información? Si es así ¿Qué actores disparan esta acción?
-
¿Qué ocurre cuando el sistema
cambia de estado? ¿Algún actor es notificado?
-
¿Algún evento externo afecta al
sistema? ¿Qué notifica el sistema respecto de estos eventos?
-
¿El sistema interactúa con algún
sistema externo?
-
¿El sistema genera algún
reporte?
¿Como especificar Casos de Uso?
La especificación de los casos
de uso se refiere a la descripción de cada una de las partes definidas
para lograr su descripción completa.
En la organización, la
especificación de los Casos de Uso se hará bajo el formato presentado a
continuación. El siguiente cuadro muestra las partes y las indicaciones
básicas para iniciar su redacción. En las siguientes secciones del
documento se presentan las recomendaciones que hacen que la redacción de
CU sea más fácil, sencilla de leer y escribir.
|
Caso de Uso
|
CU.1 XX |
|
Fuentes
|
<Stakeholders que
proporcionaron información de esta funcionalidad> |
|
Actor
|
Act.# <nombre de los
actores> [(<Pseudónimos>)] [ – secundario] |
|
Descripción
|
<Descripción del
caso de uso> |
|
Flujo básico |
1. Titulo del
paso
Descripción del paso.
2. Titulo del paso
Descripción del paso. |
|
Flujos alternos |
1. Titulo del FA
Descripción del FA
2. Titulo del FA
Descripción del FA. |
|
Pre-condiciones |
1. Titulo del
Precondición
Descripción del PRC |
|
Post-condiciones |
1. Titulo del
Poscondiciones
Descripción de la PTC |
|
Requerimientos trazados |
1. Titulo del
requerimiento
Descripción del requerimiento o porqué se enlaza a el desde
este caso de uso |
|
Puntos de inclusión |
1. Título del
punto de inclusión
Descripción del punto de inclusión |
|
Puntos de extensión |
1. Título del
punto de extensión
Descripción del punto de extensión |
|
Notas |
1. Titulo de la
Nota
Descripción de la nota |
Caso de Uso
El nombre del CU debe comenzar por
un verbo y ser lo más corto posible, pero que a su vez, describa lo que el
CU hace. El nombre del CU debe indicar el valor u objeto que genera para el
actor. El nombre del CU comienza por su identificación CU.# donde # es el
número asignado a este CU.
Fuentes
Son las personas que conocen del
negocio, y las que proporcionan información para la descripción de la
funcionalidad.
Actores
Los actores que interactúan
directamente con el sistema, tanto los primarios quienes inician el CU, como
los secundarios que interactúan con el sistema luego que este ha iniciado.
Cuando se nombran los actores en la sección de actores del CU se coloca el
código asignado en la sección de actores ejemplo Act.1. En caso de haber
actores segundarios, el CU debe indicar cuales son secundarios, el resto se
asumen primarios, de lo contrario se asume que todos son primarios. Los
actores secundarios se les coloca luego del pseudónimo un guión y la palabra
«secundario» en letra itálica.
El nombre del actor puede contener
al lado una lista de pseudónimos, estos son utilizados en el CU para
describir su funcionamiento con el empleo del pseudónimo en vez del nombre
del actor (o rol) que puede ser muy largo. El pseudónimo también puede ser
empleado en forma de lista de actores, si un pseudónimo está indicado en
varios actores, entonces la referencia al pseudónimo en el detalle del CU
hará indistinta la sustitución por cualquiera de los actores.
Descripción
Es un párrafo que resume el objetivo
del caso de uso. Sin dar detalles del cómo, la descripción del caso de uso
resume todo lo que el caso de uso hace, que es el valor que da al actor (o
actores) primario, así como la necesidad de la existencia de actores
secundarios, para los casos que aplique.
Ejemplo. “El caso de uso permite al
Administrador crear, modificar y borrar usuarios en el sistema” ó “El caso
de uso permite al Cliente obtener la información sobre su estado de cuenta
del Sistema de Manejo de Clientes”.
Flujo básico
El flujo básico (FB) describe los
pasos que se sucederían en el escenario del “mundo perfecto” o del “día
feliz”. El flujo básico es un camino simple, sin ramificaciones y en él
suelen hacerse una serie de asunciones, las alternativas a estos presuntos
son los flujos alternos.
Cada paso del flujo básico contiene
1) un número de paso o flujo, 2) titulo del paso, y 3) la descripción del
paso. La numeración del paso es un consecutivo que inicia con el número 1 en
el primer paso. El título del paso representa un resumen de lo que el paso
realiza, suele ser una oración que inicia con un verbo en estado activo Ej.
“crear usuario”, “buscar datos de clientes mayores”. La descripción del paso
contiene el detalle de lo que se espera que ocurra en el paso. Dependiendo
de la complejidad del sistema o los datos manejados, los pasos pueden tener
varios intercambios, ejemplo:
Es obligatorio que cada paso
contenga el número del paso y su título, la descripción puede ser opcional
en casos de uso cuyos pasos se limitan a la oración del título.
Los pasos de los flujos básicos no
contienen, nunca, referencias a los flujos alternos ni a flujos básicos.
La descripción del primer paso del
FB indica que actor comienza el flujo y cuál es el disparador del mismo,
ejemplo “El caso de uso inicia cuando el Administrador de Tablas de O/S
indica al sistema la opción de visualizar órdenes de servicio.”. El último
paso del flujo básico cierra indicando que el caso de uso termina, o
finaliza, ejemplo ver Tabla 1.
Flujos alternos
Los flujos alternos (FA) se definen
como flujos independientes, no como subflujos, permitiendo hacer que un
flujo alterno aplique de manera global a todo el CU, o a varios flujos
básicos u alternativos. Mantener los FA de forma plana facilita su lectura,
su escritura y su comprensión.
El formato utilizado emplea una
sección separada para los flujos alternos. Los flujos alternos pueden hacer
referencia a flujos básicos u otros flujos alternos. Todos los FA deben
indicar (en este orden):
· ¿Dónde
comienzan? Desde donde parte este FA, puede ser un FB o un FA.
· ¿Qué
los dispara? Que hace que este FA inicie
· ¿Qué
sucede? Lo que pasa cuando el FA es invocado, análogo al FB.
· ¿A
dónde regresa? Una vez que termina de ejecutarse el flujo alterno, ¿A
dónde regresa la ejecución del caso de uso?
El siguiente es un ejemplo de un FA.
|
1. Excepción:
No se encontraron O/S para el criterio aplicado
En el paso 2 del flujo básico el resultado de
la búsqueda no arroja ningún resultado. El sistema muestra al
Usuario un mensaje alertando sobre tal situación. El usuario acepta
el mensaje. El caso de uso retorna al paso 1 del flujo básico con
los valores anteriormente empleados para la búsqueda.
2. Mostrar
la lista de mensajes asociados a una O/S
En el paso 2 o el paso 3 del flujo básico el
Usuario selecciona ver la lista de mensajes asociados. El sistema
muestra una tabla con todos los mensajes contenidos por la O/S. El
caso de uso retorna al paso en que fue llamado. |
Tabla 2. Listado del último paso de un CU
Al igual que los FB, los FA cuentan
con un número de flujo, un título y una descripción. El número de flujo es
un secuencial que se inicia en 1 con el primer FA del CU.
El título describe la acción que
realiza FA y se escribe con las mismas normas que en los FB, sin embargo,
los FA que indican excepciones se presentan de forma diferente, se indica
que son excepciones y el comportamiento que es erróneo, no se escriben
comenzando con verbo en forma activa.
La descripción debe contener la
respuesta a las cuatro preguntas presentadas en el mismo orden en que se
encuentran listadas.
Pre-condiciones
Las precondiciones son elementos
opcionales de los CU. Cada precondición listada tiene: 1) número, 2) título
3) descripción (opcional). El número es un consecutivo. El titulo debe
resumir muy brevemente la condición. La descripción puede dar detalles de
cómo la condición es evaluada, o el rango de valores que pueden ser
aceptados para la condición.
Bittner y Spence hacen énfasis en
que las precondiciones no son eventos que disparan o activan el CU en el
sistema. Sin embargo son declaraciones en las cuales el caso de uso puede
comenzar. Las precondiciones son necesariamente ciertas para que el CU pueda
comenzar, pero no suficientes. El CU sólo puede ser comenzado por el actor
cuando las precondiciones son ciertas.
Las precondiciones no son evaluadas
en los FB ni los FA pues se asumen como ciertas. Si las precondiciones
aplican para todos los CU del sistema entonces es un requerimiento y no debe
indicarse.
Para hallar precondiciones formúlese
las siguientes preguntas:
· ¿En
qué estado debe encontrarse el sistema para que el CU se pueda disparar?
· ¿Qué
elementos deben estar presentes para que el CU pueda iniciar?
· ¿Cuáles
son los supuestos asumidos?
· ¿Qué
restricciones aplican al empleo del CU por los actores?
Note que las precondiciones son
opcionales de no existir no agregue precondiciones que no aporten a la
explicación del CU. Evite precondiciones como «El usuario debe estar vivo» o
«La maquina debe estar encendida y el sistema debe estar activado y
funcionando», pues no agregan valor al diseño y son obvias.
Post-condiciones
Las postcondiciones son elementos
opcionales de los CU. Los elementos y patrones para describir
postcondiciones son iguales a los de las precondiciones.
Bittner y Spence explican que las
postcondiciones deben ser ciertas cuando el CU termina, sin importar el
curso de eventos que se sucedieron. Si algo puede fallar Ud. debe cubrirlo
en las postcondiciones para describir el estado en el que el sistema se
encontrará cuando el CU se completa.
Las postcondiciones son importantes
puesto que dan las luces sobre las condiciones que garantizan que siempre
que termine el CU el sistema queda en un estado válido y los datos
inherentes (en caso de existir) se encuentran consistentes. Las
postcondiciones son igualmente útiles para verificar que las pruebas que se
realicen sobre este CU aseguren que estas condiciones se darán al salir, sea
cual fuere el curso de acciones tomadas.
Para hallar postcondiciones
formúlese las siguientes preguntas:
· ¿En
qué estado debe quedar el sistema luego que termina el CU?
· ¿Qué
debe garantizarse cuando termine para que el sistema no quede inconsistente
o no utilizable?
· ¿Cuáles
son las únicas condiciones válidas en las que puede acabar una ejecución del
CU?
Armour y Miller aclaran que tanto
las precondiciones como postcondiciones se refieren a estados del sistema,
no del ambiente fuera del mismo, ello debido a que las condiciones del
ambiente no se modelan dentro del sistema.
Requerimientos trazados
Los requerimientos son formas de
enlazar los CU o especificaciones funcionales con el resto de las
especificaciones no funcionales. Estas especificaciones o requerimientos
deben encontrarse en el repositorio de requerimientos con la información
completa de los atributos definidos.
Aunque la trazabilidad con los
requerimientos especiales se da por demostrada en el mapa de trazabilidad de
los requerimientos, el tenerlos presentes en el CU hace más fácil su lectura
para el diseñador e constructor.
Para los requerimientos se debe
especificar el número, el título y la descripción del requerimiento
(opcional). El título puede contener el código del requerimiento y el título
del mismo según la definición que se establezca para las especificaciones no
funcionales del sistema.
La descripción puede omitirse puesto
que se asume que la misma se encuentra en el repositorio de requerimientos,
sin embargo se pueden dar indicaciones adicionales de cómo el CU debe
cumplir con este requerimiento.
Puntos de inclusión y extensión
Los puntos de inclusión son los
enlaces para incluir un funcionamiento específico del CU que es empleado por
más de un CU.
Los puntos de extensión son los
enlaces que permiten extender la funcionalidad de un CU en un punto
específico de flujo básico.
Para determinar cuando colocar y qué
colocar en un punto de inclusión o un punto de extensión ver la sección de
«¿Cómo estructurar Casos de Uso?».
Notas
Las notas son elementos opcionales
muy importantes de los CU pues reflejan el análisis y la comprensión del
funcionamiento del sistema, más allá de la descripción de las interacciones
entre los usuarios.
Las notas en los CU se utilizan para
plasmar explicaciones, detalles sobre la información, formatos de archivos
que ya se encontraban establecidos y otros acuerdos con los que la
aplicación debe cumplir. Es importante que todas las notas se encuentren
referenciadas con algún elemento del Caso de Uso, ejemplo la descripción, el
FB, el FA, las referencias justifican la existencia de la nota.
Las notas son características muy
importantes de los CU puesto que permiten capturar conocimientos propios del
sistema que no se está describiendo, que son útiles a la hora de hacer el
diseño y la implementación, sin embargo, no representan una funcionalidad
propia del CU que se está especificando.
Recuerde que en su rol de analista
de requerimientos, su misión es plasmar la mayor cantidad posible de detalle
posible, ello debido a que es Ud. quién se encuentra más cercano a los
funcionales que puedan estar revelando la información.
Consideraciones a la hora de escribir
un Caso de Uso
La siguiente es una serie de
consideraciones que deben ser tomadas a la hora de escribir o especificar
casos de uso.
Empleo del SI
Condicional
Referido en inglés como “using if-statement”.
Ni los flujos básicos ni los alternos deben contener SI condicionales,
en esencia, los casos de uso no son algoritmos, sino que describen la
interacción entre los actores y el sistema. Para hacerlos no ambiguos, los
casos de uso asumen un camino ideal y el resto son caminos alternativos.
|
INCORRECTO
|
1. Modificar
el horario
Si el
usuario ya tenía un horario en su cuenta entonces proceder a mostrar
el detalle del horario. Si no, mostrar un mensaje que indica que el
usuario no tiene horario asignado. |
|
CORRECTO
|
2. Modificar
el horario
El sistema
muestra el detalle del horario.
NOTA: El sino
representa un flujo alterno
|
Tabla 3. Empleo del si condicional
Opciones de los actores
Referido en inglés como
“actor choices” o “avoid CRUD use cases”. Tanto en flujos básicos,
principalmente, como en flujos alternos, un paso puede contener varias
alternativas. El paso debe presentar al lector todas las alternativas
posibles para el actor y tomar una de ellas, la que corresponde al día
feliz.
El resto de las opciones
corresponderán a flujos alternos del caso de uso. El listado de las opciones
debe ser completo, no debe utilizarse el etc. pues es un indicio de
elementos que no han sido especificados y dejarán al diseñador la opción
para que los sustituya por cualquier cosa. El siguiente ejemplo muestra el
uso de opciones de los actores.
|
3. Crear
código de movimiento manual
El sistema permite al
Administrador de Tablas de O/S crear, modificar o borrar códigos de
movimiento manual. El Administrador de Tablas de O/S indica al
sistema crear código de movimiento manual.
El sistema solicita al
Administrador de Tablas de O/S la información de código descripción
del código.
El Administrador de Tablas
de O/S suministra los valores para estos campos y le indica al
sistema guardar la información. El caso de uso termina.
|
Tabla 4. Opciones de los actores
Mostrando iteraciones
Las iteraciones son descritas en el
caso de uso de manera plana, no se debe escribir en forma de algoritmo con
pasos, sino de forma descriptiva. El siguiente es un ejemplo del uso de
iteraciones.
|
1. Seleccionar
O/S
El sistema muestra la lista
de las órdenes de servicio que aplican según los criterios de
búsqueda seleccionados por el Usuario.
Para cada elemento de la
lista el sistema muestra el Código de movimiento, el estatus de la
Orden, la fecha de la orden, el tipo de error, el número de la
orden de servicio, la interfaz que originó la O/S, si la orden ha
sido marcada para ser archivada, un indicador que especifica si la
O/S tiene Formato 2000 asociado y un indicador que especifica si la
O/S tiene mensajes asociados.
El Usuario puede visualizar
el F2K asociado a la O/S (en caso de contenerlo) o la lista de
mensajes asociados (en caso de contenerlos). El Usuario selecciona
visualizar el F2K asociado. |
Tabla 5. Uso de iteraciones
Secuencias de eventos y
eventos opcionales
A la hora de especificar secuencias
de eventos, debe considerarse que no se indiquen secuencias que no son
requeridas. Cada paso en el flujo básico indica un orden, en el cual los
eventos deben ocurrir, sin la posibilidad (explicita) de hacerse en otro
orden.
En el caso en que esto ocurre, se
deben especificar los eventos como parte de un mismo flujo o, de forma
explícita, de que forma los eventos pueden ser ejecutados en otro orden. El
siguiente ejemplo muestra los pasos en un flujo básico que indican
secuencias que no son requeridas y dos alternativas para resolverlas.
|
Secuencia no requerida. No hay razón
para solicitar información de la tarjeta de crédito en este orden. |
1. Introducir
información de compra
El CU inicia cuando el usuario indica crear una
solicitud para la venta de un ítem. El sistema solicita al usuario
la información del cliente: nombre, apellido, CI, dirección y
teléfono; la cantidad de productos a incluir en el pedido y la
categoría de precios en la que se encuentra el cliente. El usuario
indica al sistema la información solicitada e indica validar la
información.
2. Validar
información de compra
El sistema verifica que todos los datos
solicitados tengan información, y determina si el cliente ya se
encuentra registrado en el sistema. El sistema determina que todos
los datos suministrados son correctos y que el cliente no se
encuentra registrado. El sistema solicita al usuario la confirmación
del pedido.
3. Confirmar
la información de compra
El sistema presenta al usuario todos los datos
suministrados en referencia al cliente, el pedido y la lista de
precios solo en forma de lectura. El usuario puede confirmar la
compra o indicar nuevos valores para este campo. El usuario confirma
los datos.
4. Indicar
información de tarjeta de crédito
El sistema solicita al usuario la información
de la tarjeta de crédito del cliente: banco, tipo, número, fecha de
expiración, código de seguridad y nombre en la tarjeta de crédito.
El usuario indica todos los datos y le indica al sistema realizar la
compra.
5. Crear
solicitud de compra
El sistema crea la orden de compra con los
datos suministrados y realiza la transacción con el banco. El banco
autoriza la compra.
6. Presentar
resultado de la transacción
El sistema muestra al usuario un mensaje
indicando que la transacción ha sido realizada de forma exitosa,
presenta los datos de la compra y el detalle de los elementos
vendidos. El sistema indica al usuario que entregue el pedido. |
|
Alternativa 1. La solicitud de
información de tarjeta de crédito no requiere hacerse luego de la
validación. |
1. Introducir
información de compra
El CU inicia cuando el usuario indica crear una
solicitud para la venta de un ítem. El sistema solicita al usuario
la información del cliente: nombre, apellido, CI, dirección y
teléfono; la cantidad de productos a incluir en el pedido y la
categoría de precios en la que se encuentra el cliente; y la
información de tarjeta de crédito del cliente banco, tipo, número,
fecha de expiración, código de seguridad y nombre en la tarjeta de
crédito. El usuario indica al sistema la información solicitada
e indica validar la información.
2. Validar
información de compra
El sistema verifica que todos los datos
solicitados tengan información, y determina si el cliente ya se
encuentra registrado en el sistema. El sistema determina que todos
los datos suministrados son correctos y que el cliente no se
encuentra registrado. El sistema solicita al usuario la confirmación
del pedido.
3. Confirmar
la información de compra
El sistema presenta la usuario todos los datos
suministrados en referencia al cliente, el pedido y la lista de
precios solo en forma de lectura. El usuario puede confirmar la
compra o indicar nuevos valores para este campo. El usuario confirma
los datos.
4. Crear
solicitud de compra
El sistema crea la orden de compra con los
datos suministrados y realiza la transacción con el banco. El banco
autoriza la compra.
5. Presentar
resultado de la transacción
El sistema muestra al usuario un mensaje
indicando que la transacción ha sido realizada de forma exitosa,
presenta los datos de la compra y el detalle de los elementos
vendidos. El sistema indica al usuario que entregue el pedido. |
|
Alternativa 2. El sistema solicita al
usuario toda la información pero no indica el orden en que debe ser
presentada. Caso análogo a trabajar con tabs o pestañas.
|
1. Iniciar
compra
El CU inicia cuando el usuario indica crear una
solicitud para la venta de un ítem.
2. Introducir
información de usuario
El sistema solicita al usuario la información
del cliente: nombre, apellido, CI, dirección y teléfono.
3. Introducir
información de volumen de compra
El sistema solicita al usuario la cantidad de
productos a incluir en el pedido y la categoría de precios en la que
se encuentra el cliente. Este paso puede ocurrir en cualquier
momento luego de iniciar la compra.
4. Introducir
información de tarjeta de crédito
El sistema solicita al usuario la
información de tarjeta de crédito del cliente banco, tipo, número,
fecha de expiración, código de seguridad y nombre en la tarjeta de
crédito. Este paso puede ocurrir en cualquier momento luego
de iniciar la compra.
5. Validar
información de compra
El usuario indica al sistema la información
solicitada e indica validar la información. El sistema verifica que
todos los datos solicitados tengan información, y determina si el
cliente ya se encuentra registrado en el sistema. El sistema
determina que todos los datos suministrados son correctos y que el
cliente no se encuentra registrado. El sistema solicita al usuario
la confirmación del pedido.
6. Confirmar
la información de compra
El sistema presenta la usuario todos los datos
suministrados en referencia al cliente, el pedido y la lista de
precios solo en forma de lectura. El usuario puede confirmar la
compra o indicar nuevos valores para este campo. El usuario confirma
los datos.
7. Crear
solicitud de compra
El sistema crea la orden de compra con los
datos suministrados y realiza la transacción con el banco. El banco
autoriza la compra.
8. Presentar
resultado de la transacción
El sistema muestra al usuario un mensaje
indicando que la transacción ha sido realizada de forma exitosa,
presenta los datos de la compra y el detalle de los elementos
vendidos. El sistema indica al usuario que entregue el pedido. |
Tabla 6. Manejo de secuencia de eventos
Si una secuencia de eventos se
presenta, el diseñador o desarrollador asumirá que ésta es la forma correcta
de realizar las actividades, sin dejar posibilidad a otras formas de
realizar la secuencia de pasos.
Nivel de detalle esperado
Se espera que el nivel de detalle
del caso de uso no contemple detalles sobre la interfaz, ni la arquitectura,
ni el procesamiento interno de los datos cuando estos no sean concernientes
a los involucrados. Los casos de uso presentan detalles de requerimientos,
no de diseño, otras herramientas son utilizadas para el diseño, como el
prototipo. Esta separación se realiza para hacer más fácil de entender los
CU.
El caso de uso debe contener el
detalle justo y necesario para explicar los intereses (requerimientos
funcionales) del involucrado y entregar el sistema.
El nivel de detalle esperado para el
caso de uso es el necesario para guiar al diseñador en la forma en que se
desea presentar los datos y expresar los resultados, en ningún momento se
debe limitar al diseñador en este aspecto. En caso de existir restricciones
o requerimientos de algún otro tipo que limiten las opciones, los mismos
deben ser referenciados en la sección de restricciones o requerimientos
especiales según el caso.
Las siguientes palabras, como regla
general, indican un nivel de detalle incorrecto: Base de Datos, archivo,
etc., botón, HTML, http, SMTP, radio button.
¿Dónde colocar información necesaria
sobre requerimientos de interfaz o arquitectura?
El documento que contiene los
requerimientos debe contener esta información. Es deber del analista de
requerimientos tomar en consideración todos los requerimientos recolectados
y presentarlos de manera total y consistente para que el diseñador y
desarrollador los puedan tener en cuenta a la hora de hacer su trabajo. Los
requerimientos pueden ser presentados en el listado de requerimientos
especiales.
Creatividad
Debe recordar que Ud. Está
escribiendo flujos que afectarán la experiencia del usuario en la
herramienta, y que eso que se defina será validado con el usuario. A la hora
de escribir, el CU hágase la pregunta ¿Qué es lo que el sistema debería
hacer mejor? ¿Qué hay detrás de los requerimientos? ¿A qué están
acostumbrado los usuarios? ¿Dónde el CU genera valor? ¿Las necesidades de
los usuarios quedarán totalmente satisfechas con la solución propuesta? ¿Qué
otra cosa se podría hacer para al sistema sea más usable?
Recuerde que cuando escribe los CU,
Ud. Está escribiendo como el sistema va a trabajar y como la experiencia del
usuario se verá afectada por el uso del sistema.
Sin embargo, debe tomar en cuenta
que si bien el CU debe agregar valor a los procesos que el actor realizará
con la herramienta, el mismo debe poderse implementar en los tiempos
solicitados, que el analista de requerimientos no debe introducir
requerimientos que no agreguen valor a la cadena.
Especificaciones fáciles pueden
hacer sistemas fáciles de utilizar. Especificaciones complicadas, harán, con
toda seguridad, sistemas complejos, lo cual incrementa la oportunidad de
rechazo del sistema por los usuarios, agregando a todo el equipo la
posibilidad de fracaso, pues su éxito está atado al éxito de la experiencia
que los usuarios con el uso del sistema que se está analizando.
Nombre de los actores en
todas las secciones del caso de uso
Cuando el CU especifica los pasos
que el actor está realizando en el sistema, el CU debe indicar claramente
quién es el actor, no deben emplearse expresiones como: «El actor hace…. »
en vez debe especificarse el nombre completo del actor el pseudónimo. Nótese
que el pseudónimo puede ser el mismo en varios CU para hacer referencia a
actores diferentes, entonces se debe estar claro que el alcance del
pseudónimo se restringe, de manera estricta, al CU.
Los nombres de los actores siempre
comienzan en mayúscula y todas las palabras que los componen comienzan en
mayúsculas, como el formato de cualquier nombre de persona (menos los
artículos, ejemplo: de, la, el, para, del, con, etc.
¿Cómo estructurar Casos de Uso?
La estructuración de los CU es un
paso posterior a la construcción del modelo inicial del modelo de CU. La
primera construcción del modelo de CU nunca incluye la estructuración, ello
ocurre producto de la especificación cuando se comienza a ver que los casos
de uso tienen definiciones semejantes, compartidas o dependientes. La
estructuración de CU busca simplificar la explicación del funcionamiento del
sistema y es el primer acercamiento para contemplar la reutilización y la
modularización en la definición del diagrama de clases. La estructuración de
CU consta de cuatro casos posibles que se listan a continuación, la
explicación contiene la repercusión el modelo de clases resultantes.
Generalización de actores
La generalización de actores permite
al analista identificar un rol que hace factor común de las funcionalidades
de varios usuarios. Si el actor A1 puede hacer {UC1, UC2 y UC3} y el actor
A2 puede hacer {UC1, UC3 y UC4} entonces se puede crear un actor A3 que
puede hacer {UC1 y UC3}, que los actores A1 y A2 extiendan de A3, que A1
pueda hacer {UC2} y que A2 pueda hacer {UC4}. Gráficamente:
Generalización de casos de uso
Expresión clave: Plantilla de CU.
La generalización de CU, al igual
que en los actores, permite extraer factor común de dos o más casos de uso
que comparten características. En la generalización de CU existe un CU padre
(o base, o general) y un CU hijo que es una especialización del base. En
estos casos el hijo hereda todas las características del padre, puede
agregar nuevas características, y puede modificar (sobrescribir)
características del padre excepto por las relaciones y los puntos de
extensión.
Cuando un CU es hijo de otro, en el
nombre debe indicar cual es su padre, indicando: «CU.1.2 Crear libro «child» ».
No es lógico el empleo de herencia múltiple en CU, por lo cual no está
permitido. En la generalización de CU la numeración se modifica para indicar
cual es el padre del caso de uso, en el ejemplo anterior el “CU.1.2 Crear
libro” es hijo del “CU.1 Crear producto”, adicionalmente se
agrega el indicador «child» para indicar que es la especialización de un
caso de uso base. En la descripción del CU se indica cual es su CU base y
que valor agrega sobre el mismo.
La especialización permite
establecer en el padre un comportamiento general y el cada hijo una
variación del comportamiento general, variando múltiples elementos del CU,
ejemplo flujos básicos, alternos, precondiciones, etc. para lograr un
resultado de valor. Un CU base puede ser especializado por múltiples veces.
Como buena práctica aunque no es
necesario, se recomienda que cuando se hace generalización de CU, el CU base
es abstracto, es decir que los actores no lo utilizan directamente sino que
utilizan las especializaciones.
Cuando se especializa un CU, se
inicia y termina la especialización y no el CU base.
Gráficamente, la generalización de
CU se representa como a continuación. Note que CU.2 y CU.3 son los hijos y
CU.1 es el padre.
Extensión de casos de uso
La extensión de CU se utiliza para
agregar nuevas funcionalidades o comportamientos a un CU. Cuando se extiende
un CU, el CU base indica el punto en los que se hace la extensión.
Los puntos de extensión en la
especificación del CU debe incluir, un título que es el nombre del CU que se
extiende, y un texto de indica: 1) el paso del flujo básico que se extiende
con esta funcionalidad o grupo de funcionalidades – note que los puntos de
extensión nunca son sobre los flujos alternos – 2) opcionalmente la
condición que establece que esta funcionalidad esté disponible para el
actor, y 3) la acción que realiza el actor para que el flujo de eventos se
curse hacia el CU extendido.
El nombre del CU que extiende
especifica cual es su caso base de manera semejante a la generalización: «CU1.1
Procesar O/S manuales «extend» ». En este caso, el CU1.1 extiende al CU1
“Visualizar O/S”, e indica que es una extensión de funcionalidad del
caso de uso base con la palabra clave “extend”.
En la extensión, los CU base son
instanciados, no abstractos, a diferencia de lo que ocurre en la
generalización.
Las extensiones son casos más
específicos que las generalizaciones porque una especialización de CU puede
contener muchas modificaciones al comportamiento de CU, mientras que una
extensión se refiere a la adición de una funcionalidad a un CU en un punto
específico. La extensión no sobrescribe las funcionalidades presentes en el
CU base. Una extensión no tiene que ser un CU completo. El caso de uso que
inicia es el CU base y se agrega la extensión.
Las extensiones se utilizan para:
-
Describir características que
son opcionales al comportamiento básico del sistema.
-
Describir errores o excepciones
complejas de considerarlas en el CU base complicaría su comprensión.
-
Personalización de
requerimientos para resolver necesidades específicas del cliente.
-
Mejorar la gestión del alcance y
la configuración de las soluciones entregadas.
Gráficamente, la
extensión de CU se representa como a continuación. Note que CU.6 es la
extensión de CU.1
.png "Dia")
