Scribd
Cargar
373 vistas14 páginas

Ejercicios de Diagramas de Casos de Uso

El documento presenta ejercicios sobre diagramas de casos de uso. El primer ejercicio consiste en identificar afirmaciones como verdaderas o falsas sobre casos de uso. El segundo ejercicio analiza un diagraama de casos de uso de un sistema de comunicaciones móviles. El tercer ejercicio corrige errores en varios diagramas de casos de uso. El cuarto ejercicio analiza los actores e identifica casos de uso de un sistema de ventas por catálogo.

Cargado por

isidro gonzalez
Derechos de autor
© All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como DOCX, PDF, TXT o lee en línea desde Scribd
373 vistas14 páginas

Ejercicios de Diagramas de Casos de Uso

El documento presenta ejercicios sobre diagramas de casos de uso. El primer ejercicio consiste en identificar afirmaciones como verdaderas o falsas sobre casos de uso. El segundo ejercicio analiza un diagraama de casos de uso de un sistema de comunicaciones móviles. El tercer ejercicio corrige errores en varios diagramas de casos de uso. El cuarto ejercicio analiza los actores e identifica casos de uso de un sistema de ventas por catálogo.

Cargado por

isidro gonzalez
Derechos de autor
© All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como DOCX, PDF, TXT o lee en línea desde Scribd

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 (más precisamente roles que
interpretan personas), dispositivos u otros sistemas, y en general, cualquier cosa que X
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 X
dicho sistema.
La especificación de un caso de uso describe cómo se implementa el comportamiento
requerido para el sistema en dicho caso de uso. X
Un escenario representa una instancia de un caso de uso. X
El diagrama de casos de uso de un sistema puede organizarse por medio de relaciones que se
pueden dar entre los diferentes casos de uso. Estas relaciones son las de: X
generalización/especialización, inclusión, y extensión.
Debería utilizarse una relación de extensión, entre casos de uso, cuando es necesario
factorizar el comportamiento común a varios casos de uso en otro caso de uso. X
Un caso de uso incluido en otros, es un caso de uso que es “usado” por esos otros casos de
uso. El caso de uso “usado” se “activa” toda vez que el caso de uso que lo usa se “activa”. X

Ejercicio 2.
Considerando el siguiente diagrama de casos de uso:

Actor

Dpto. LSI, Escuela Universitaria de Ingeniería de Vitoria-Gasteiz. 1


Ejercicios DCU Ejercicios DCU

a. Indicar cada uno de los elementos de notación que están presentes en dicho diagrama.

b. Describir brevemente qué interpretación proporciona dicho diagrama.

Es un sistema de comunicaciones celular como dice la nota, de un lado está el cliente el cual puede
ser particular o pertenecer a un corporativo, este pude realizar llamadas y si quiere establecer una
llamada de conferencia. También puede recibir llamadas o hacer uso
de su agenda.

Ejercicio 3.
Considerando los siguientes Diagramas de Casos de Uso (DCU), corregir todos los errores
de notación que se presentan en ellos. Las siglas RF significan Requisito Funcional y en aquellos
DCU que aparecen no se trata de un error.

2 Dpto. LSI, Escuela Universitaria de Ingeniería de Vitoria-Gasteiz.


Ejercicios DCU Ejercicios DCU

De Vacunas

3 Dpto. LSI, Escuela Universitaria de Ingeniería de Vitoria-Gasteiz.


Ejercicios DCU Ejercicios DCU

4 Dpto. LSI, Escuela Universitaria de Ingeniería de Vitoria-Gasteiz.


Ejercicios DCU Ejercicios DCU

Dpto. LSI, Escuela Universitaria de Ingeniería de Vitoria-Gasteiz. 3


Ejercicios DCU Ejercicios DCU

Ejercicio 4.
En este Sistema de Venta por Catálogo los clientes hacen pedidos que recibe el departamento
comercial y la empresa los sirve lo antes posible; y además ellos también pueden devolver
productos y cancelar pedidos.
Analizar la identificación de actores y casos de usos del siguiente diagrama de casos de
uso y el texto que lo acompaña, extraídos del libro “Applying Use Cases. A Practical Guide”
de G. Schneider y J. Winters, relativo a este Sistema de Venta por Catálogo.

Dpto.
4 LSI, Escuela Universitaria de Ingeniería Dpto.
de Vitoria-Gasteiz.
LSI, Escuela Universitaria de Ingeniería de Vitoria-Gasteiz.4
Ejercicios DCU Ejercicios DCU

< < in c lud e> >

M o s t ra r in fo rm ac ió n prod uc to
R e aliz ar P edi do

< < in c lud e> > < < in c l ude> >


A c t u a liz ar In ve nt ario
S is t e m a In ve nta rio

< < in c lud e> >


< < in c lu d e > >

D e vo lve r P rod uc to

C lie n t e < < in c lu de> > A c t u a liz a r C o n t a b ilid a d

Lo gin
< < in c lud e > >
C a n c ela r P e dido
S is t e m a C o nt ab ilid a d
< < in c lud e> >

< < in c lud e> >

< < in c lu d e > >

C o ns u lt ar P e dido
C l ie n te Re p
R e g is t ra r R e c lam ac io nes

P repa rar In fo rm e V en t as

E n c a rg a do
A t enc ió n C li e nt e
E n via r C a t a lo g o

Mo s t ra r in f o rm a c i ón prod uc to

A d m in is t ra t ivo E n viar P e d ido


< < in c lud e > >

E m pres a E n vios

A c tu a liz ar In ve nta rio

S is t em a In ve nt ario

“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 añadido un caso de uso Login. Pero entonces teníamos que establecer su
relación con los otros casos de uso. Nuestra primera idea fue que cada caso de uso arrancase usando
Login. Esta idea parece apropiada si se ve el sistema como un conjunto de aplicaciones
independientes, cada una con su propia interfaz. Así 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 front-end para entrar en la aplicación. Según sea nuestra
selección, se invoca a una determinada operación. Como resultado tenemos una ramificación en
Login que usa relaciones include a los otros casos de uso. Se pueden ver estos resultados en un

Dpto.
5 LSI, Escuela Universitaria de Ingeniería Dpto.
de Vitoria-Gasteiz.
LSI, Escuela Universitaria de Ingeniería de Vitoria-Gasteiz.5
Ejercicios DCU Ejercicios DCU

diagrama algo confuso. Nosotros podríamos decidir rescribir los include del caso de uso Login y
colocar Login como una precondición de cada uno de ellos”.

Dpto.
6 LSI, Escuela Universitaria de Ingeniería Dpto.
de Vitoria-Gasteiz.
LSI, Escuela Universitaria de Ingeniería de Vitoria-Gasteiz.6
Ejercicios DCU Ejercicios DCU

Ejercicio 5.
En este Sistema de Compras por Internet los usuarios se registran en el sistema y pueden
realizar pedidos a través del manejo de un carro de la compra.
Analizar la identificación de actores y casos de usos correspondiente al DCU de la Figura
1 (Sistema de Compras por Internet) y después al DCU de la Figura 2 (Comercio
Electrónico).

Dpto.
7 LSI, Escuela Universitaria de Ingeniería Dpto.
de Vitoria-Gasteiz.
LSI, Escuela Universitaria de Ingeniería de Vitoria-Gasteiz.7
Ejercicios DCU Ejercicios DCU

GestionarCuentasClientes

GestionarPedidos

Cliente GestionarCarroCompra

Inventario
RegistrarPedido

Sistema Proceso Tarjetas

ExplorarProductos

EncontrarProductos

LogOnUser

Tendero

CerrarPedido Encargado Envíos


GestionarProductos

Administrador Sistema GestionarUsuarios

Figura 1

El significado de los casos de uso es el siguiente.


• GestionarCuentasCliente: el cliente puede crear, modificar y eliminar detalles de su cuenta
como nombre o dirección;
• GestionarPedidos: el cliente puede crear, ver y cambiar pedidos;
• GestionarCarroCompra: el cliente puede añadir y eliminar ítems de su carro de compra;
• RegistrarPedido: el cliente paga y lanza una orden de pedido;
• ExplorarProductos: el cliente busca un producto en venta;
• EncontrarProductos: el cliente puede encontrar uno o más productos que satisfacen algún
criterio de búsqueda;
• LogOnUser: los actores involucrados deben validarse para entrar al sistema;

Dpto.
8 LSI, Escuela Universitaria de Ingeniería Dpto.
de Vitoria-Gasteiz.
LSI, Escuela Universitaria de Ingeniería de Vitoria-Gasteiz.8
Ejercicios DCU Ejercicios DCU

• GestionarProductos: el tendero puede añadir, actualizar o eliminar productos;

Dpto.
9 LSI, Escuela Universitaria de Ingeniería Dpto.
de Vitoria-Gasteiz.
LSI, Escuela Universitaria de Ingeniería de Vitoria-Gasteiz.9
Ejercicios DCU Ejercicios DCU

• GestionarUsuarios: el administrador puede añadir, eliminar o modificar cuentas de usuario


para usuarios que no son clientes;
• CerrarPedido: el encargado establece el pedido a cerrado y entonces está listo para el envío.

1
Dpto. LSI, Escuela Universitaria de Ingeniería Dpto. LSI, Escuela Universitaria de Ingeniería de Vitoria-Gasteiz.1
de Vitoria-Gasteiz.
0 0
Ejercicios DCU Ejercicios DCU

Figura 2

1
Dpto. LSI, Escuela Universitaria de Ingeniería Dpto. LSI, Escuela Universitaria de Ingeniería de Vitoria-Gasteiz.1
de Vitoria-Gasteiz.
1 1
Ejercicios DCU Ejercicios DCU

El significado de algunas palabras es el siguiente.


• CVT (Continuously Variable Transmission): Transmisión de Variación Continua;
• Shopkeeper: Comerciante;
• Dispatcher: Expedidor.

1
Dpto. LSI, Escuela Universitaria de Ingeniería Dpto. LSI, Escuela Universitaria de Ingeniería de Vitoria-Gasteiz.1
de Vitoria-Gasteiz.
2 2

Common questions

Con tecnología de IA

Correct identification and notation of actors and use cases are crucial because they ensure clarity in how different entities interact with the system, help define precise system boundaries, and facilitate mutual understanding among stakeholders about the system’s intended functionalities and requirements, minimizing ambiguities during system development .

Re-designing include relationships as preconditions, such as in login operations, arises from a desire to streamline process flows and reduce redundancy. By setting login as a precondition rather than an action invoked by each use case, the system ensures all relevant interactions commence with validated access, improving security while maintaining a clean and efficient interaction model .

Using an "extend" relationship in an early-stage use case diagram may be inappropriate because the extend relationship is typically more beneficial later in the development process when additional requirements are identified that naturally extend the existing system functionality. If the system is still being initially developed, there might not be existing functionality to extend, and focus should instead be on defining clear and complete primary use cases .

Customer returns and order cancellations demonstrate the system's ability to handle post-sale processes effectively, ensuring customer satisfaction and operational flexibility. These capabilities allow customers to reverse transactions, manage customer service expectations, and reflect the system's comprehensive nature in supporting full transaction lifecycle management .

"GestionarCarroCompra" encapsulates the customer interaction within an e-commerce system related to managing their virtual shopping cart. It involves actions such as adding and removing items, reflecting common customer behavior of browsing, selecting items to potentially purchase, and maintaining control over their shopping list until checkout .

The use case 'CerrarPedido' represents the business process of finalizing an order, making it ready for shipment. It is critical to order management as it signifies the transition of an order from open to closed status, confirming that all information is correct, payment is received, and the product is ready to be dispatched, thereby maintaining process integrity and efficiency .

Creating a "Login" use case affects structuring by necessitating its inclusion as a prerequisite or entry point for other use cases that involve user interaction. Initially considered to make each use case invoke "Login," it shifts to implementing it as a front-end process that validates system access without redundancy, thus streamlining user entry before triggering related operations .

Actors in a use case diagram represent any entity that interacts with the system, such as people (specifically roles played by individuals), devices, or other systems. They are essential because they help define, clarify, and visualize the interactions between external entities and the system, ensuring that all necessary interactions are captured in the system design .

Initial system design may lack 'extend' relationships because the system requirements are in the process of being fully defined, and the focus is on capturing primary functionalities. Without finalized system features, there are no existing use cases to extend, making the 'extend' relationship more relevant for later iterations when extensions or enhancements to system capabilities are clearly identified .

An inclusion relationship in use case diagrams is used to factor out common behavior shared by multiple use cases into a separate, reusable use case. This inclusion mechanism allows various use cases to 'include' this common use case, promoting reusability and reducing duplication of behavior definition across the system .

Ejercicios Diagramas de casos de uso Ejercicio 1. Para cada una de las siguientes afirmaciones indicar si es Verda
Ejercicios DCU Ejercicios DCU 2 Dpto. LSI, Escuela Universitaria de Ingeniería de Vitoria-Gasteiz. a. Indic
Ejercicios DCU Ejercicios DCU 3 Dpto. LSI, Escuela Universitaria de Ingeniería de Vitoria-Gasteiz.
Ejercicios DCU Ejercicios DCU 4 Dpto. LSI, Escuela Universitaria de Ingeniería de Vitoria-Gasteiz.
Ejercicios DCU Ejercicios DCU Dpto.
Ejercicios DCU Ejercicios DCU 4 Dpto. LSI, Escuela Universitaria de Ingeniería de Vitoria-Gasteiz. Dpto. LSI, Escuela Uni
Ejercicios DCU Ejercicios DCU 5 Dpto. LSI, Escuela Universitaria de Ingeniería de Vitoria-Gasteiz. Dpto. LSI, Escuela Uni
Ejercicios DCU Ejercicios DCU 6 Dpto. LSI, Escuela Universitaria de Ingeniería de Vitoria-Gasteiz. Dpto. LSI, Escuela Uni
Ejercicios DCU Ejercicios DCU 7 Dpto. LSI, Escuela Universitaria de Ingeniería de Vitoria-Gasteiz. Dpto. LSI, Escuela Uni
Ejercicios DCU Ejercicios DCU 8 Dpto. LSI, Escuela Universitaria de Ingeniería de Vitoria-Gasteiz. Dpto. LSI, Escuela Uni

También podría gustarte