Clase 07 Tecnicas de Busqueda de Requerimientos 29 12 23

CARRERA: DESARROLLO DE SISTEMAS DE INFORMACION
Curso
Técnicas de búsqueda de requerimientos.
Clase 7: Relaciones en los Casos de Uso: Association, Extend,
Include, Generalization. Ejercicios
.
Lima, 29 de diciembre de 2023
DATOS DEL DOCENTE
Profesor: Juan Daniel Daza Hermoza.
Correo: ingenieria.sistemas.2030@gmail.com
Página web: https://repasovirtual.jimdofree.com/
Fan Page : https://www.facebook.com/AsesoriaEducativa.JDDH
Prof. Juan Daniel Daza Hermoza

Diapositiva 2 Fecha: 29/12/2023
ingenieria.sistemas.2030@gmail.com
1. Tener los micrófonos apagados.
2. Sólo active su micrófono si va a participar,

después lo desactiva.

Para participar levante la
mano, indique su nombre y
el lugar de donde se conecta

Si están con celular… tengan cuidado!!!

Participación de todos ustedes
¡¡¡¡¡Poner en
el Zoom sus
nombres
completos!!!!!

¿Qué vimos la clase pasada?

 Un caso de uso es una técnica de modelado usada para describir lo
que debería hacer un sistema nuevo o lo que hace un sistema que
ya existe.
 Los casos de uso describen bajo la forma de acciones y reacciones el
comportamiento de un sistema desde el punto de vista de un usuario,
permiten definir los límites del sistema y las relaciones entre el sistema y el
entorno.
 Los componentes primarios de un modelo de casos de uso (case-use model) son los
casos de uso (use cases), los actores y el sistema modelado.
 Los casos de uso son descripciones funcionales del sistema; describen cómo los
actores pueden usar un sistema

 Los límites del sistema se definen por la funcionalidad que
se maneja en el sistema.
 La funcionalidad se representa mediante diversos casos de
uso, especificando cada uno una funcionalidad completa
(desde su inicio por parte de un actor externo hasta que
haya realizado la funcionalidad requerida). Un caso de uso
siempre debe devolver algún valor a un actor, siendo el
valor cualquier cosa que el actor desee del sistema.
 El actor es una entidad externa que tiene interés en
interactuar con el sistema. A menudo, es una persona que
usa el sistema, pero también puede ser otro sistema o
alguna clase de dispositivo hardware que necesita
interactuar con el sistema.
 Un sistema en un diagrama de casos de uso se describe mediante
un rectángulo que contiene el nombre del sistema y los símbolos
de los casos de uso en el sistema.
 Un actor es alguien o algo que interactúa con el sistema, pero que es externo al sistema.
 El actor envía o recibe mensajes a y desde el sistema, o
intercambia información con el sistema.
 Un caso de uso siempre es iniciado por un actor que le envía
un mensaje o estímulo (stimulus). Los actores llevan a cabo
casos de uso.
 Cuando un caso de uso se realiza, el caso de uso podría enviar
mensajes a uno o más actores. Estos mensajes también puede
ir a otros actores además del que inició el caso de uso.

Un caso de uso se representa en UML mediante una elipse que
contiene el nombre del caso de uso, o con el nombre del caso de uso
debajo.
Los casos de uso se conectan a los actores mediante
asociaciones, denominadas líneas de comunicación
(communication lines).
 Las asociaciones muestran con qué actores se
comunica el caso de uso, incluyendo el actor que
inicia la ejecución del caso de uso.
 La asociación normalmente es una relación uno a
uno sin dirección. Esto significa que una instancia de
actor se comunica con una instancia de caso de uso y
que pueden comunicarse en ambas direcciones.
Un caso de uso es un tipo de clasificador que describe la
funcionalidad como un todo, incluyendo posibles alternativas,
errores y excepciones que puedan ocurrir durante la ejecución del caso de uso en
colaboración con uno o más actores.
Los casos de uso se determinan precisando actor por actor:
 Las funciones que requiere el actor del sistema, si el actor necesita leer, crear, destruir,
modificar o almacenar alguna clase de información en el sistema.
 Si hay que informar al actor de los eventos del sistema o el actor necesita notificar algo al
sistema y qué representan esos eventos en términos de funcionalidad.
 Si se podría simplificar o hacer más eficiente el trabajo del actor añadiendo nuevas
funciones del sistema.
 Las entradas/salidas que necesita el sistema.
 Los principales problemas de la implementación actual del sistema.

Programas para desarrollar UML

¿Alguna pregunta?

Empecemos
la Clase!!!!

Relación Incluir y Extender

Un tema que genera mucha polémica entre la gente que modela
casos de uso es la elección entre la relación de <<include>> y
<<extend>>.
Lo peor es que muchas de esas discusiones generan muy
poco valor en el resultado final en el modelo y en cambio
quitan tiempo valioso del proyecto.
Esto se debe a que dichas relaciones, muchas veces no
son del todo comprendidas por la persona que la modela,
y mucho menos son comprendidas por las personas que
leen el modelo.
Así que al final no se le saca el provecho que en todo caso
debería de tener dicha elección.

Antes que todo, ¿qué es el “include” y el “extend”?
Gráficamente lo que mostramos es una relación de dependencia
entre el par de casos de uso, con el nombre correspondiente al tipo de relación de la
que se trate: ya sea <<include>> o <<extend>>.
Estas, son relaciones que usamos para ligar
gráficamente dos casos de uso, cuyos flujos de
eventos están unidos, normalmente en una sola
sesión del usuario.
En otras palabras, un caso de uso que está ligado, por medio de una de estas dos
relaciones, a otro caso de uso; también podría leerse o ejecutarse como un sólo caso
de uso en lugar de dos. Obviamente, hay una razón por la cual decidimos separarlos en
dos, lo cual explicaremos más adelante.
Imagina el conjunto de pasos que ocurren al realizar una compra
en una tienda departamental.
Seguramente no tendrás problema en visualizar el conjunto de pasos para solicitar la
autorización de la tarjeta de crédito con la que vas a pagar, ligado a los pasos donde el
vendedor registra los productos a comprar.
Es decir, los flujos de eventos de
ambos procesos forman una sola
cosa; juntos podrían formar un solo
caso de uso, en lugar de dos casos de
uso unidos por alguna de estas
relaciones que aquí estamos
tratando.

Include. En términos muy simples, cuando relacionamos dos
casos de uso con un “include”, estamos diciendo que el primero
(el caso de uso base) incluye al segundo (el caso de uso incluido).
Es decir, el segundo es parte esencial del primero. Sin el segundo, el primero no podría
funcionar bien; pues no podría cumplir su objetivo. Para una venta en caja, la venta no
puede considerarse completa si no se realiza el proceso para cobrarla en ese momento.
El caso de uso “Cobrar Renta” está incluido en el caso de uso “Rentar Video”, o lo que es
lo mismo “Rentar Video” incluye (<<include>>) “Cobrar Renta”.

Extend. La polémica al querer seleccionar una de las dos
relaciones es que en el “extend” también podemos ver, desde la
perspectiva del usuario, a los dos flujos como si fueran uno sólo.
Y en ciertos escenarios el caso de uso base no podría cumplir su objetivo si no se
ejecutara la extensión. Pero, una de las diferencias básicas es que en el caso del “extend”
hay situaciones en que el caso de uso de extensión no es indispensable que ocurra, y
cuando lo hace ofrece un valor extra (extiende) al objetivo original del caso de uso base.
En cambio en el “include” es necesario que ocurra el caso incluído, tan sólo para
satisfacer el objetivo del caso de uso base. Ejemplo: Puedes “Realizar Venta” sin
“Acumular Puntos de Cliente VIP”, cuando no eres un cliente VIP. Pero, si eres un cliente
VIP sí acumularás puntos. Por lo tanto, “Acumular Puntos” es una extensión de “Realizar
Venta” y sólo se ejecuta para cierto tipo de ventas, no para todas.

Y si realizo una venta y me dicen
que pueden pagar con tarjeta
¿El Caso de Uso autorizar pago
con tarjeta será Include o
Extend?

Veamos un ejemplo

Desarrollar un Caso de Uso…
Tomaremos en cuenta lo siguiente:

 Ingresar a la página Web. Puede
registrarse si desea.
 Buscar el Pedido teniendo en
cuenta que hay combos y
de compra de pollito por ofertas.
delivery  Consultar si hay delivery al
distrito.
 Realizar el pago. Se puede pagar
con tarjeta.
 El voucher se enviará al correo.

Se consideran otros casos de uso como es “si
se desea se registra el cliente”, “se puede
pagar con tarjeta” y “enviar vaucher al
correo”

Tenemos que ver que uso de Caso puede
ser Include o Extend. Considera que si es
opcional es extend en caso contrario es Opcional Obligatorio
include. En el siguiente texto:
“Ingresar a la página Web. Puede Extend
registrarse si desea.
¿El Registro del cliente es opcional o es
obligatorio?

En el texto: “Realizar el pago. Se puede
pagar con tarjeta”.
¿El pago con tarjeta es obligatorio o no? Entonces quedaría así
Opcional Obligatorio
Extend
¿Y con que caso de uso esta relacionado?

Por último ¿Enviar Vaucher es
opcional u obligatorio?
Opcional Obligatorio
Include

¿Preguntas?

Relaciones de Generalización

Una relación de generalización es una relación
en la que un elemento del modelo (hijo) se Relación entre un caso de uso general y otro
basa en otro elemento del modelo (padre). más específico que hereda características y
Las relaciones de generalización se utilizan en añade otras
diagramas de clases, diagramas de
componentes, diagramas de implementación y
diagramas de casos de uso para indicar que el La relación de generalización significa:
elemento secundario acepta todos los  El CU hijo hereda el comportamiento y
atributos, operaciones y relaciones definidas en significado del padre.
el elemento principal.  El CU hijo especializa al padre insertando
La Generalización indica que un caso de uso es pasos adicionales o redefiniendo pasos.
una variante de otro.  El hijo puede ser ubicado en cualquier
lugar donde aparezca el padre.
Esta relación se puede utilizar entre dos
casos de uso o entre dos actores. No se
puede utilizar entre un actor con un caso
de uso.
Por ejemplo:
 Un sistema de pedidos de venta que
maneja varios tipos, por ejemplo:
Realizar pedido en tienda, realizar
pedido por teléfono y realizar pedido
por internet.

La secuencia de pasos puede ser diferente
para los tres casos de uso, por ejemplo al
realizar pedido por teléfono o por internet
se necesita pedir una dirección de envío,
mientras que en el pedido en tienda sólo
se necesita la de facturación.
Se puede definir un caso de uso
denominado “Realizar pedido”, este caso
de uso tiene relaciones de especialización
con los casos de uso de pedido en tienda,
por teléfono y por internet. Veamos el ejemplo de un estacionamiento de
vehículos, donde se estacionan autos,
camiones y motos
También se puede dar
entre actores,
supongamos que un
actor es empleado,
luego vamos a tener
al vendedor, y al
cajero; ambos son
empleados, por lo
que tienen las
características del
empleado
Recordando:
Entre Actor y casos
de Uso Veamos algunos
Entre Casos de Uso
Entre Casos de Uso
Entre Casos de Uso o

entre actores

a) RF01: Inicio de sesión.
Dentro de la página Web, el sistema
podrá Administrar a un cliente o podrá
iniciar sesión con una cuenta el cliente.
Preguntas que nos hacemos:
¿Quiénes son los actores?
 Cliente.
 Administrador.
¿Cuáles son los casos de Uso?
 Administrar Cliente
 Iniciar Sesión

Nuevamente nos
preguntamos:
¿Quiénes son los
actores?
 Trabajador.
b) RF02: Creación de roles  Administrador.
y perfiles. ¿Cuáles son los casos de
El sistema creará y Uso?
¿Habrá relaciones de Extend,
asignará los distintos  Registrar Trabajador
Include o Generalization?
roles a los trabajadores  Asignar Roles
registrados. Trabajador

c c
c
¿Habrá relaciones de Asociacion, Extend, ¿Faltaría algo?

Include o Generalization?

c
c) RF03: Registro de los clientes.

El sistema permitirá registrar los datos esenciales El Caso de Uso Registrar Clientes ¿Qué
de los clientes como nombres, apellidos, DNI, tipo de asociación tiene y con quién?
RUC, teléfono, dirección, etc. Prof. Juan Daniel Daza Hermoza
¿Cómo van hasta ahí?

d) RF04: Búsquedas de los Nuevamente nos
productos y sus detalles. preguntamos:
Los clientes y vendedores ¿Quiénes son los actores?
podrán ver los detalles  Cliente.
del producto antes de  Vendedor.
realizar una venta, los ¿Cuáles son los casos de Uso?
datos a mostrar serán el  Mostrar Detalles Productos
stock y los detalles de los
componentes del
Aquí hay que tener en cuenta
producto, fecha de
que para mostrar los detalles de
producción, fecha de
los productos, alguien tuvo que
vencimiento, marca,
haberlos registrado
nombre, etc.
RF05: Búsqueda por filtros (Tipo de
producto, trabajadores, fechas, etc.).
Los usuarios del sistema podrán realizar
búsqueda con filtros de la diversa
información de la empresa según su rol.
Ejemplo: Los trabajadores podrán filtrar
al cliente por DNI, nombre, etc.
Los clientes podrán filtrar los productos
por: Marca, nombre, fecha de
producción, fecha de vencimiento, etc.

Taller

f) RF06: Movimientos de
los productos (entradas
y salidas).
El sistema deberá de
registrar las entradas y
las salidas de los
productos con su
respectiva fecha y
cantidad.

g) RF07: Administrar el catálogo
de productos.
El administrador podrá
registrar nuevos productos y
sus detalles, así como la
modificación y/o eliminación
de algún producto.

h) RF08: Creación de
Órdenes de Compra.
Los vendedores
podrán registrar las
órdenes de compra
en el sistema.

i) RF09: Registrar las
ventas. j) RF10: Consultas de
Los vendedores las ventas registradas
podrán registrar las para el despacho de
ventas en el los productos.
sistema, luego de El área de almacén
reconocer el pago podrá ver las ventas
efectuado en la registradas para
orden de compra. poder alistar los
productos a
despachar.

k) RF11: Ventas en línea.
El sistema deberá permitir
generar cotizaciones a
vendedores para poder
concretar una venta.

Cualquier duda o consulta escribir al:
correo
Página web
repasovirtual.jimdofree.com
Mi FanPage
https://www.facebook.com/AsesoriaEducativa.JDDH

Eres dueño de tu propio destino!!!!!
Gracias Totales!!!
Desde ahora tienes 365 días para
alcanzar tus sueños, metas,
propósitos y un año completo en el
que te apoyaré. ¡Feliz Año Nuevo!

Clase 07 Tecnicas de Busqueda de Requerimientos 29 12 23

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Clase 07 Tecnicas de Busqueda de Requerimientos 29 12 23

Cargado por

Copyright:

Formatos disponibles

CARRERA: DESARROLLO DE SISTEMAS DE INFORMACION

Prof. Juan Daniel Daza Hermoza

2. Sólo active su micrófono si va a participar,

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Tomaremos en cuenta lo siguiente:

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

¿Y con que caso de uso esta relacionado?

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Entre Casos de Uso

Entre Casos de Uso o

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

¿Habrá relaciones de Asociacion, Extend, ¿Faltaría algo?

Prof. Juan Daniel Daza Hermoza

c) RF03: Registro de los clientes.

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

También podría gustarte