Re-Estructuracin de CU - Apunte No Oficial

Autor: Juan Pablo Beltramone

Versin: 1.0
UTN FRR


Re-Estructuracin de CU Anlisis de Sistemas - UTNFRR Pgina 1 de 8


RE-ESTRUCTURACION DE CASOS DE USO

Introduccin

Luego de haber hecho el Anlisis de Metas, la correspondiente definicin del Alcance del
Sistema, los respectivos CU de Sistema (Sin Estructurar) de cada meta Principal y
Complementaria, entramos en una etapa crucial de definiciones de requisitos del Sistema.

Repacemos un poco lo que hicimos hasta ahora:

Arrancamos con un Modelo de Negocio.
Lo hicimos para Analizar, entender y documentar como es el Negocio Actualmente.
Confeccionamos varios artefactos, utilizamos la herramienta de CU para describir los
procesos (a pesar de que los CU no fueron creados para ese fin), realizamos parte de su vista
esttica y dinmica.

Luego nos pusimos a pensar:
Cmo podra un nuevo sistema de Software asistir a los Actores del Negocio a cumplir sus
metas actuales?
Considerando la respuesta a lo anterior mas las necesidades para con el nuevo sistema,
hicimos el Anlisis de Metas, Actividades por Actor, Metas por Actor, Metas Intra-Actor,
Metas Inter-Actor, hasta llegar a las metas independientes, clasificadas como Principales y
Complementarias, para luego definir los CUR con alcance de Sistema, donde se describe
muy resumidamente, cmo los Actores van a valerse del sistema a construir para cumplir
cada uno sus metas individuales, por lo general de nivel usuario, que luego sumadas
contribuirn a cumplir las metas Resumen Principales y Complementarias.

Lo que tenemos son grandes CU, con varios escenarios cada uno (caminos alternativos), y
con metas, por lo general, Resmenes de alto nivel. (Podra haber ya en este punto CU Nivel
Usuario)

El paso siguiente que vamos a encarar, es el de Re-Estructurar cada uno de esos CU
Resumen de Sistema con el fin de obtener los CU de Nivel Usuario (ya no aclaramos que
son de Sistema) que van a representar en cierto modo, la operatoriedad requerida del
sistema.


Re-Estructuracin de CU - Apunte No Oficial
Autor: Juan Pablo Beltramone
Versin: 1.0
UTN FRR


Re-Estructuracin de CU Anlisis de Sistemas - UTNFRR Pgina 2 de 8

Conceptos Fundamentales

Para poder hacer la Re-Estructuracin de CU Resumen de Sistema es necesario tener bien en
claro los siguientes conceptos:

BPE: Business Processes Elementary - Proceso elemental de Negocio
Vamos a definir al Proceso elemental de Negocio como una o ms tareas o actividades
realizadas por Actores del Negocio al que pertenece el BPE, en un perodo corto de tiempo,
como respuesta a un disparador o evento de negocio, que al ser ejecutada con xito
proporciona un valor apreciable a los Actores del Negocio, dejando el estado del mismo en
un estado consistente.

y

Metas de Nivel Usuario:

La meta de usuario es de gran inters para la captura de requisitos dirigida por casos de
uso. La meta de usuario de un actor primario se define como el objetivo para conseguir la
finalizacin de un trabajo. La meta de usuario corresponde a un concepto de ingeniera de
proceso de negocio llamado proceso elemental de negocio.
Una meta de usuario pone atencin en las preguntas:

El actor primario se retira feliz luego de realizar el trabajo?
La performance del trabajo del usuario depende de cuantas veces haga esto hoy?

Tambin pone atencin en la prueba del caf de descanso, luego de finalizar esto,
puedo tomarme un tiempo de descanso. En la mayora de las situaciones, pasa el siguiente
test:

una persona, un asiento de 2 a 20 minutos

Estos dos conceptos son los que debemos tener en cuenta para la Re-Estructuracin de los
CUR-Sistema.

Por lo general, podemos establecer como Regla que:

Por cada proceso elemental de Negocio se corresponde un CU de Nivel Usuario.

Decimos por lo general, porque que pueden existir situaciones donde la regla anterior no
aplique en su sentido ms estricto.


Re-Estructuracin de CU - Apunte No Oficial
Autor: Juan Pablo Beltramone
Versin: 1.0
UTN FRR


Re-Estructuracin de CU Anlisis de Sistemas - UTNFRR Pgina 3 de 8

Re-Estructurando Casos de Uso de Sistema de Nivel Resumen:

Nuestro CU tendr un escenario bsico, y podr tener, ninguno (raramente), o muchos
escenarios alternativos. (Caminos Alternativos).

Empezamos analizando el camino bsico.

Analizamos el uso del sistema descripto en el escenario principal con el objetivo de
detectar los distintos BPE involucrados.

Dependiendo del nivel de detalle en el que haya sido escrito el CU Resumen, podremos
encontrarnos con un BPE por cada paso del CUR Resumen, o detectar que ms de un paso
involucran al mismo BPE. Podra tambin ser posible, aunque menos comn, encontrarnos
con un paso que involucre ms de un BPE, por ejemplo para CUR resmenes de muy alto
nivel.

Por cada BPE encontrado definimos un Caso de Uso de Nivel Usuario. Le definimos un
nombre que identifique lo ms claramente posible su meta y su contenido y un cdigo
incremental del Tipo CUU X.Y, donde CUU es Caso de Uso de Usuario, X es el nmero del
CU Resumen, e Y es un numerador incremental de los CUU definidos derivados de ese CU
Resumen.


Continuamos analizando los escenarios alternativos.

Luego analizamos los pasos de los caminos alternativos, donde nos podemos encontrar con
dos situaciones:

a) El paso est incluido dentro de alguno de los BPE ya definidos y para los que ya se
estableci un CUU. En este caso no debe definirse un nuevo CUU, dado que estos
pasos se incluirn en el posterior detalle del CUU ya definido.
b) El paso corresponde a un BPE diferente a los ya considerados. En este caso si se
deber definir un nuevo CUU.

Escritura del CUR-Re-Estructurado.

La escritura del Caso de Uso Resumen, de Sistema, Re-Estructurado, lo hacemos partiendo
del mismo CU Sistema sin Estructurar. (Si es que existe, podra darse el caso de escribir un
CU Re-Estructurado directamente sin haber escrito el CUR sin estructurar).

Lo nica variacin va a estar en la forma de escribir los escenarios bsicos y alternativos,
Justamente, de eso estamos hablando, la escritura de los escenarios vamos a hacerla en
forma Estructurada, de all que, a la dimensin o calificacin del caso de uso Estructura
la vamos a consignar como Re-Estructurado.

El resto queda igual (Meta, Actores, Pre y Post Condiciones, Disparador, etc.).

Re-Estructuracin de CU - Apunte No Oficial
Autor: Juan Pablo Beltramone
Versin: 1.0
UTN FRR


Re-Estructuracin de CU Anlisis de Sistemas - UTNFRR Pgina 4 de 8


En la sintaxis ms dura, podramos escribir directamente la invocacin al CU:

1 Encargado de Turno invoca CUU 1.1 Gestin de Turnos

Pero, para un mejor lectura e interpretacin del mismo, se recomienda referenciar
brevemente lo que el actor hace al invocar a ese CUU:

1 Encargado de Turno consulta Canchas Disponibles, controla RN07 y RN08, e
ingresa la reserva invocando CUU 1.1 Gestin de Turnos.

Cada paso debe incluir la invocacin a al menos un CU (por lo general uno), pero podra
darse el caso de invocar ms de uno.

Respecto de los Caminos Alternativos, solo deben escribirse aquellos que originaron un
nuevo CUU, mientras que los pasos correspondientes a caminos alternativos de BPE del
camino bsico, no deben volver a escribirse.

Adyacencias del Negocio
Pueden incluirse adyacencias del Negocio para clarificar el momento dentro del workflow
de trabajo en el que se invoca a cada CUU.


Ejemplo de Re-Estructuracin de un CU Resumen:

Descripcin de los Casos de Uso Resumen con Alcance de Sistema

Cdigo y Nombre del CASO DE USO: R1 Administrar Reserva para tomar clase de tenis
Nivel Estructura Alcance Caja Instanciacin I nteraccin
Resumen Sin-estructurar Sistema Negra Real Semntico
Meta del CASO DE USO: Tomar clases de tenis
ACTORES
Primario: Interesado (IN) Otros: Encargado del Turno (ET), Profesor (PR)

(Nota: El Interesado es una Generalizacin del Socio. El Socio es un Interesado, es una
especializacin del IN)
(Un Interesado puede arrancar el CU, por ende el Socio tambin puede hacerlo)
(Similar a cuando un Gerente puede ejecutar un CU que normalmente ejecuta un Empleado pero
no se da la inversa)


PRECONDICIONES(de negocio): Existen interesados en tomar clases de tenis
PRECONDICIONES(de sistema)
Primarias: Las reservas ingresadas estn registradas
Complementarias: Existen Socios, Canchas, Profesor

DISPARADOR: Interesado se identifica y solicita reservar cancha tenis al ET.
FLUJO DE SUCESOS

Re-Estructuracin de CU - Apunte No Oficial
Autor: Juan Pablo Beltramone
Versin: 1.0
UTN FRR


Re-Estructuracin de CU Anlisis de Sistemas - UTNFRR Pgina 5 de 8

CAMINO BSICO:
1. ET ingresa datos de la reserva al sistema. Sistema valida RN07 y RN09 y le informa
las Canchas Disponibles. Luego el ET se lo comunicar al Socio.
El paso 1 puede repetirse para distintos das y horarios solicitados por el SO.
2. Cuando el Socio opt por una cancha el ET lo ingresa al sistema. Sistema lo registra.
Luego Encargado de Turno le informar al Socio la reserva realizada.
3. Cuando el SO anunci su presencia a la clase, el ET lo ingresa al sistema. Sistema
valida que la reserva exista y registra la asistencia. Luego el ET avisar al PR la
presencia del Socio para tomar clase de tenis.
CAMINOSALTERNATIVOS:

1.a <durante>El Interesado No es socio
1.a.1 Sistema informa condicin. Fin CU
1.b <durante>Socio tiene reserva para la fecha solicitada
1.b.1 Sistema informa condicin
1.c. <posterior>Socio no acepta sugerencias ofrecidas
1.c.1 Socio desisti de reservar. Fin CU
3.a <previo>Socio cancela reserva
3.a.1 Encargado del Turno ingresa cancelacin Sistema Registra.
3.a.1.a <reemplaza>Se venci el plazo para cancelar la Reserva.
3.a.1.a.1 Sistema informa condicin.
3.b <durante>No existe la reserva, est vencida o cancelada.
3.b.1 Sistema informa Situacin. Luego Encargado del Turno se lo
comunicar al Socio. Fin CU
3.c <durante>La reserva registrada no es para ese momento
3.c.1 Sistema informa fecha y hora de la reserva registrada. Luego el Encargado
del Turno se lo comunicar al Socio. Vuelve al paso 3

POSTCONDICIONES(de sistema)
xito: La Reserva est registrada como asistida.
Fracaso: La reserva est registrada como cancelada (3.a.1)
<vacio> (1.a)
xito alternativo: La Reserva est registrada como asistida (1.b)

POSTCONDICIONES(de negocio)
xito: El socio tom clases de tenis con el profesor seleccionado
Fracaso: No pudo tomar clases de tenis por no ser socio, o por no aceptar fecha alternativa,
o por no aceptar horarios alternativos, o por no acordar reserva, o por cancelar reserva, o
por no asistir a la reserva.
xito alternativo: El socio tomo clases de tenis con sugerencias de fechas alternativas, o
con sugerencias de horarios alternativos o con cambios en la formulacin de la reserva.

Reglas de Negocio relacionadas con el caso de uso:
PASO REGLA DE NEGOCIO
1
3

Restricciones (no completadas en esta iteracin)
Requerimientos no funcionales (no completadas en esta iteracin)

Cuestiones Abiertas:

Re-Estructuracin de CU - Apunte No Oficial
Autor: Juan Pablo Beltramone
Versin: 1.0
UTN FRR


Re-Estructuracin de CU Anlisis de Sistemas - UTNFRR Pgina 6 de 8


Cuestiones Cerradas: (no completadas en esta iteracin)


Cdigo y Nombre del CASO DE USO: RR1 Administrar Reserva para tomar clase de tenis
Nivel Estructura Alcance Caja Instanciacin I nteraccin
Resumen Re-Estructurado Sistema Negra Real Semntico
Meta del CASO DE USO: Tomar clases de tenis
ACTORES
Primario: Interesado (IN) Otros: Encargado del Turno (ET), Profesor (PR)

(Nota: El Interesado es una Generalizacin del Socio. El Socio es un Interesado, es una
especializacin del IN)
(Un Interesado puede arrancar el CU, por ende el Socio tambin puede hacerlo)
(Similar a cuando un Gerente puede ejecutar un CU que normalmente ejecuta un Empleado pero
no se da la inversa)


PRECONDICIONES(de negocio): Existen interesados en tomar clases de tenis
PRECONDICIONES(de sistema)
Primarias: Existen Reservas
Complementarias: Existen Socios, Canchas, Profesor

DISPARADOR: Interesado se identifica y solicita reservar cancha tenis al ET.
FLUJO DE SUCESOS
CAMINO BSICO:
1. ET consulta Canchas Disponibles, controla RNxx y RNx, e ingresa la reserva al Sistema
invocando CUU-1.1-Ingresar Reserva.
2. Cuando el SO anunci su presencia a la clase, el ET controla que la reserva exista y registra la
asistencia, invocando CUU-1.2-Registrar Asistencia. Luego el ET avisar al PR la presencia
del Socio para tomar clase de tenis.
CAMINOSALTERNATIVOS:
2.a <previo>Socio cancela reserva
2.a.1 Cuando el socio comunica la cancelacin el ET la ingresa al Sistema
invocando CUU.1.3-Cancelar Reserva

POSTCONDICIONES(de sistema)
xito: La Reserva est registrada como asistida.
Fracaso: La reserva est registrada como cancelada (3.a.1)
<vacio> (1.a)
xito alternativo: La Reserva est registrada como asistida (1.b)

POSTCONDICIONES(de negocio)
xito: El socio tom clases de tenis con el profesor seleccionado
Fracaso: No pudo tomar clases de tenis por no ser socio, o por no aceptar fecha alternativa,
o por no aceptar horarios alternativos, o por no acordar reserva, o por cancelar reserva, o
por no asistir a la reserva.
xito alternativo: El socio tomo clases de tenis con sugerencias de fechas alternativas, o
con sugerencias de horarios alternativos o con cambios en la formulacin de la reserva.

Reglas de Negocio relacionadas con el caso de uso:

Re-Estructuracin de CU - Apunte No Oficial
Autor: Juan Pablo Beltramone
Versin: 1.0
UTN FRR


Re-Estructuracin de CU Anlisis de Sistemas - UTNFRR Pgina 7 de 8

PASO REGLA DE NEGOCIO
1
3

Restricciones (no completadas en esta iteracin)
Requerimientos no funcionales (no completadas en esta iteracin)

Cuestiones Abiertas:

Cuestiones Cerradas: (no completadas en esta iteracin)














Re-Estructuracin de CU - Apunte No Oficial
Autor: Juan Pablo Beltramone
Versin: 1.0
UTN FRR


Re-Estructuracin de CU Anlisis de Sistemas - UTNFRR Pgina 8 de 8