Ejercicios Diagramas de casos de uso Ejercicio 1. Para cada una de las siguientes afirmaciones indicar si es Verdadera o Falsa. Verdadera
Falsa
Los actores de un sistema representan, en particular, personas (mas precisamente precisamente roles que interpretan personas), dispositivos u otros sistemas, y en general, cualquier cosa que interactúa con dicho sistema. Los casos de uso, sus especificaciones y el diagrama de casos de uso de un sistema permiten acordar, entre el equipo de desarrollo y el cliente, los límites y los requisitos funcionales de dicho sistema. La especificacin de un caso de uso descri!e cmo se implementa el comportamiento requerido para el sistema en dicho caso de uso. "n escenario representa una instancia de un caso de uso. #l diagrama de casos de uso de un sistema puede organi$arse por medio de relaciones que se pueden dar entre los diferentes diferentes casos de uso. #stas #stas relaciones son las las de% generali$acin&especiali$acin, generali$acin&especiali$acin, inclusin, y e'tensin. e!ería utili$arse una relacin de e'tensin, entre casos de uso, cuando es necesario factori$ar el comportamiento común a varios casos de uso en otro caso de uso. "n caso de uso incluido en otros, es un caso de uso que es usado* por esos otros casos de uso. #l caso de uso usado* se activa* toda ve$ que el caso de uso que lo usa se activa*.
Ejercicio 2. +onsiderando el siguiente diagrama de casos de uso%
pto. L-, #scuela "niversitaria de -ngeniería de Vitoria/astei$.
0
#1ercicios +"
a. -ndicar cada uno de los elementos de notacin que est2n presentes en dicho diagrama. b. escri!ir !revemente qu3 interpretacin proporciona dicho diagrama.
Ejercicio 3. +onsiderando los siguientes iagramas de +asos de "so (+"), corregir todos los errores de notacin que se presentan en ellos. Las siglas 4F significan 4equisito Funcional y en aquellos +" que aparecen no se trata de un error.
5
pto. L-, #scuela "niversitaria de -ngeniería de Vitoria/astei$.
#1ercicios +"
pto. L-, #scuela "niversitaria de -ngeniería de Vitoria/astei$.
6
#1ercicios +"
Ejercicio 4. #n este istema de Venta por +at2logo los clientes hacen pedidos que reci!e el departamento comercial y la empresa los sirve lo antes posi!le7 y adem2s ellos tam!i3n pueden devolver productos y cancelar pedidos. 8nali$ar la identificacin de actores y casos de usos del siguiente diagrama de casos de uso y el te'to que lo acompa9a, e'traídos del li!ro “Applying Use Cases. A Practical Guide” de /. chneider y :. ;inters, relativo a este istema de Venta por +at2logo.
<
pto. L-, #scuela "niversitaria de -ngeniería de Vitoria/astei$.
#1ercicios +"
< < include> > M ostrar inform ac ión produc to
Realiz ar P edi do < < incl ude> >
< < include> >
A ctualiz ar Inventario < < inc lude> >
S is tem a Inventario
< < inc lude> > Devolver P roduc to
Cliente
< < include> >
A ctualizar Contabilidad
Loin < < in clude > > Cancelar P edido < < include> >
S is tem a Contabilidad < < inc lude> > < < inc lude> > Consult ar P edido
Cl ie nte Rep Reis trar Reclam aciones
P repa rar Inform e ! en tas
" nc arado A tenc ión Cli ente " nviar Cataloo
Most rar inform aci ón prod ucto
A dm inistrativo
" nviar P edido < < inc lude > > " m presa " nvios
A c tualizar Inventario S istem a Inventario
En el diagrama de casos de uso se pueden observar un buen número de relaciones
include entre casos de uso, pero no extend. Las relaciones include aparecen pronto para mostrar aspectos comunes entre partes del sistema. La relación extend tiende a aparecer más tarde, cuando encuentras nuevos requisitos que extienden al sistema actual. Dado que todavía no hemos desarrollado el primer sistema no tenemos nada que extender.
Nótese que todos los casos de uso que involucran al actor Cliente requieren el acceso al sistema, por lo que hemos aadido un caso de uso Login. !ero entonces teníamos que establecer su relación con los otros casos de uso. Nuestra primera idea "ue que cada caso de uso arrancase usando Login. Esta idea parece apropiada si se ve el sistema como un con#unto de aplicaciones independientes, cada una con su propia inter"a$. %sí nosotros arrancamos la aplicación Realizar Pedido que invoca a Login como su primera tarea Nosotros no vemos el sistema de esta manera, sino que el proceso de Login es un "ront& end para entrar en la aplicación. 'egún sea nuestra selección, se invoca a una determinada operación. (omo resultado tenemos una rami)cación en Login que usa relaciones include a los otros casos de uso. 'e pueden ver estos resultados en un diagrama algo con"uso. Nosotros podríamos decidir rescribir los include del caso de uso Login * colocar Login como una precondición de cada uno de ellos+ .
pto. L-, #scuela "niversitaria de -ngeniería de Vitoria/astei$.
=
#1ercicios +"
Ejercicio 5. #n este istema de +ompras por -nternet los usuarios se registran en el sistema y pueden reali$ar pedidos a trav3s del mane1o de un carro de la compra. 8nali$ar la identificacin de actores y casos de usos correspondiente al +" de la Figura 0 (istema de +ompras por -nternet) y despu3s al +" de la Figura 5 (+omercio #lectrnico).
>
pto. L-, #scuela "niversitaria de -ngeniería de Vitoria/astei$.
#1ercicios +"
#estionarCuentasClientes
#estionarPedidos
Cliente
#estionarCarroCompra
Inventario ReistrarPedido
Sistema Proceso $ar%etas "&plorarProductos
"ncontrarProductos
Lo'n(ser
$endero
#estionarProductos
Administrador Sistema
CerrarPedido
"ncarado "nv)os
#estionar(suarios
Figura 0 El signi)cado de los casos de uso es el siguiente. •
•
• •
• •
•
•
#estionarCuentasCliente* el cliente puede crear, modi)car * eliminar detalles de su
cuenta como nombre o dirección #estionarPedidos* el cliente puede crear, ver * cambiar pedidos #estionarCarroCompra* el cliente puede aadir * eliminar ítems de su carro de compra ReistrarPedido* el cliente paga * lan$a una orden de pedido "&plorarProductos* el cliente busca un producto en venta "ncontrarProductos* el cliente puede encontrar uno o más productos que satis"acen algún criterio de búsqueda Lo'n(ser* los actores involucrados deben validarse para entrar al sistema #estionarProductos* el tendero puede aadir, actuali$ar o eliminar productos
pto. L-, #scuela "niversitaria de -ngeniería de Vitoria/astei$.
?
#1ercicios +"
•
•
#estionar(suarios* el administrador puede aadir, eliminar o modi)car cuentas de
usuario para usuarios que no son clientes CerrarPedido* el encargado establece el pedido a cerrado * entonces está listo para el envío.
Figura 5
@
pto. L-, #scuela "niversitaria de -ngeniería de Vitoria/astei$.
#1ercicios +"
El signi)cado de algunas palabras es el siguiente. •
•
•
C!$ +Continuousl, !ariable $ransmission-* -ransmisión de ariación (ontinua S.op/eeper* (omerciante Dispatc.er* Expedidor.
pto. L-, #scuela "niversitaria de -ngeniería de Vitoria/astei$.
A