13-06-2014

m1

CU- Resolucin de problemas

detectados

El modelo m1 se interpreta como:

- La funcionalidad del caso_1 incluye a la funcionalidad de caso_3
- Para completar la funcionalidad de caso_1 se requiere la funcionalidad de caso_3.
- En el primer modelo m1 el caso_3 no es necesario ya que es include de slo 1 caso de uso.
Se hace un include para implementar funcionalidad comn a varios otros CU u actores, como
lo muestra el modelo m2.

Pedro Campos
Christian Vidal
Alejandra Segura
rea curricular Ingeniera de Software

m2

m2

m3

Nombre
Descripcin
Precondicin
Flujo bsico
Flujo alternativo
Pos condicin

En la especificacin del caso de uso caso_1 y caso_2 , especficamente en el FLUJO DE

ACCIONES, debe aparecer como un paso del SISTEMA que se invoca, llama o hace inclusin
del caso_3.
Si el caso_3 puede devolver distintos resultados (no errores), en el mismo flujo del CU que
invoca al caso_3 (caso_1 o caso_2) pueden incluirse las secuencias de acciones distintas para los
tipos de resultados.
Los errores que puedan ocurrir en el caso_3 deben ser tratados en el caso_3 no en los CU que le
usan o invocan.
En la especificacin del caso_3 no debe existir referencia al caso_1 o caso_2.
Dado que el caso_3 tambin puede ser usado por el actor 2, en la especificacin del FLUJO DE
ACCIONES debe existir una secuencia para cuando el caso_3 es invocado por el sistema o por un
actor, por ejemplo al actor los resultados se le muestran por pantalla en cambio si la llamada es
por sistema los resultados se retornan como parmetros o mensajes.

ERROR DE MODELAMIENTO M4 por:

- La funcionalidad del caso_3 requiere
la funcionalidad de caso_1, por lo
tanto el actor puede usar el caso_1
pero no el caso_3.

En el modelo M5, que un caso de

uso sea extends de ms de 1 caso
de uso, es muy extrao, poco
comn, y posiblemente un error.

m4

El modelo m3 se interpreta como:

- La funcionalidad del caso_3 requiere de la funcionalidad de caso_1, pero para ejecutar la
funcionalidad de caso_1 no se requiere la funcionalidad del caso_3, es decir, el caso_3 es
opcional para caso_1 pero no al revs.
En la especificacin del caso de uso caso_1, especficamente en el FLUJO, debe aparecer la
EXPRESIN CONDICIONAL que se invoca o llama al caso_3.

ERROR DE MODELAMIENTO DE MANTENEDORES

m6

ERROR DE MODELAMIENTO M6 por las

siguientes razones:
1. En la tcnica de CU no se usa
descomposicin.
2. Qu hace el CU gestionar?, si slo
es un men, entonces no es
suficiente para ser un CU.

m5

ERROR DE MODELAMIENTO M7 por:

1. En la tcnica de CU no se usa
descomposicin.
2. En trminos prcticos, el modelo
dice que cuando el actor ingresa
puede acceder a modificar o
eliminar. Pero en la practica el actor
no necesita pasar por el ingresar
para modificar o eliminar.

m7

13-06-2014

ERROR DE MODELAMIENTO DE MANTENEDORES

ERROR DE MODELAMIENTO M8 por las
siguientes razones:
1. En la tcnica de CU no se usa
descomposicin.
2. Si son relaciones de extends
significa que son OPCIONALES es
decir que el actor puede slo
gestionar! , pero gestionar no hace
nada slo llama a otros CU.
3. Qu hace el CU gestionar?, si slo
es un men, entonces no es
suficiente para ser un CU.

ERROR DE MODELAMIENTO DE CONTROL DE ACCESO (LOGIN)

ERROR DE MODELAMIENTO M12 por las siguientes razones:
1. Lo que se intenta representar implcitamente con este
modelo es que Antes de modificar, ingresar o eliminar
el usuario debe ejecutar el login, PERO ESTO
significara que se intenta modelar relaciones de
secuencia entre CU. La tcnica de CU no permite
representar secuencia.
2. Si son relaciones de include significa que cuando se
implementa el login, habrn expresiones condicionales
para permitir acceder a ingresar, modificar o eliminar.
3. Para eliminar, el actor debe ejecutar el login. Si luego
desea modificar tambin deber ejecutar el login, etc.?

Alternativas CORRECTAS PARA EL MODELAMIENTO de MANTENEDORES

m8

m9
Modelo m9 es simple, no
obstante la
especificacin puede
extenderse.
La especificacin debe
incluir en el flujo de
acciones las
EXPRESIONES
condicionales para
indicar cuando el usuario
quiere INGRESAR,
MODIFICAR O ELIMINAR.

m12

m10
Modelo m10 es simple,
la funcionalidad de
buscar el tem a
modificar o eliminar se
duplicar.

m11
Modelo m11 es mas
complejo de leer, aunque la
funcionalidad de buscar el
tem a modificar o eliminar
se factoriz en el CU buscar.
Es decir para modificar o
eliminar, si se requiere, se
utiliza la funcionalidad de
buscar.
La funcionalidad de buscar
debe ser igual tanto para el
modificar como para
eliminar.

Alternativa CORRECTA PARA EL MODELAMIENTO de LOGIN

m14

1. En este modelo se debe considerar

que los cu ingresar, modificar Y
eliminar deben tener una
precondicin que indique que el
usuario es vlido y tiene el perfil de
administrador o vendedor (segn
sea el caso).

m13

ERROR DE MODELAMIENTO M13 por las siguientes

razones :
1. Para ingresa, el actor deber ejecutar el login, u si
luego desea modificar o eliminar deber ejecutar
nuevamente el LOGIN? O bien se manejara la
sesin, es decir que en el flujo de acciones de
cualquiera de los CU debe existir una condicional
que diga el sistema verifica si existe una sesin
abierta, sino invoca al CU login

Alternativa MEJORADA PARA EL MODELAMIENTO de LOGIN

m15

INTERPRETACIONES DE 1 CU donde participan varios actores

INTERPRETACION 1

1. Este modelo consta de 2 diagramas

2. Se utiliza la generalizacin de actores para simplificar o
facilitar la lectura del modelo.
3. En este modelo se debe considerar que los cu ingresar,
modificar y eliminar deben tener una precondicin que
indique que el usuario es vlido y tiene el perfil de
administrador o vendedor (segn sea el caso).

Ambos actores
ejecutan
exactamente el
mismo flujo de
acciones.
En este caso es
mejor utilizar la
generalizacin de
actores.

INTERPRETACION 2

El actor con perfil

alumno ejecuta una
secuencia de
acciones distinta
que el Jefe de
carrera.
Por lo tanto debe
existir una expresin
CONDICIONAL que
indique, si el actor
tiene el perfil de
alumno el sistema.
Si tiene el perfil Jefe
de Carrera.

m16

INTERPRETACION 3

Los actores participan en

el flujo de acciones de
forma interactiva.
Por ejemplo, el alumno
ingresa una propuesta,
el sistema valida los
datos y si son correctos,
guarda y enva
notificacin al Jefe de
Carrera. Luego el Jefe de
carrera recibe
notificacin y evala la
propuesta actualizando
su estado en aprobada
da rechazada.