13
UPLA (UNIVERSIDAD PERUANA LOS ANDES) TRABAJO PRÁCTICO ING. SW Diagramas de casos de uso Ejercicio 1. Para cada una de las siguientes afirmaciones indicar si es Verdadera o Falsa. Verdadera Falsa a) Los actores de un sistema representan, en particular, personas (mas precisamente roles que interpretan personas), dispositivos u otros sistemas, y en general, cualquier cosa que interactúa con dicho sistema. Un Actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza Rpta. Verdadero. b) 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. Rpta. Verdadera. c) La especificación de un caso de uso describe cómo se implementa el comportamiento requerido para el sistema en dicho caso de uso. Rpta. (Falsa, por que describe el curso básico y alternativo de los eventos) d) Un escenario representa una instancia de un caso de uso. Rpta. (Verdadera) e) 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: generalización/especialización, inclusión, y extensión. f) 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. g) 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”. Ejercicio 2. Considerando el siguiente diagrama de casos de uso: INGENIERIA DE SOFTWARE Página 1

TRABAJO PRÁCTICO UML

Embed Size (px)

Citation preview

Page 1: TRABAJO PRÁCTICO UML

UPLA (UNIVERSIDAD PERUANA LOS ANDES)

TRABAJO PRÁCTICO ING. SW

Diagramas de casos de uso

Ejercicio 1.Para cada una de las siguientes afirmaciones indicar si es Verdadera o Falsa.Verdadera Falsa

a) Los actores de un sistema representan, en particular, personas (mas precisamente roles que interpretan personas), dispositivos u otros sistemas, y en general, cualquier cosa que interactúa con dicho sistema.Un Actor no necesariamente representa a una persona en particular, sino más bien la labor que realizaRpta. Verdadero.

b) 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.Rpta. Verdadera.

c) La especificación de un caso de uso describe cómo se implementa el comportamiento requerido para el sistema en dicho caso de uso.Rpta. (Falsa, por que describe el curso básico y alternativo de los eventos)

d) Un escenario representa una instancia de un caso de uso.Rpta. (Verdadera)

e) 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: generalización/especialización, inclusión, y extensión.

f) 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.

g) 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”.

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

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

INGENIERIA DE SOFTWARE Página 1

Page 2: TRABAJO PRÁCTICO UML

UPLA (UNIVERSIDAD PERUANA LOS ANDES)

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 usode 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.

Casos de uso del UML

INGENIERIA DE SOFTWARE Página 2

Page 3: TRABAJO PRÁCTICO UML

UPLA (UNIVERSIDAD PERUANA LOS ANDES)

Describe la relación del usuario y los requisitos funcionales → se

representan mediante elipses.

definen los límites del sistema.

relaciones con el entorno.

ej: en un criadero de caballos, un caso de uso sería la compra de un

caballo.

Contienen:

requisitos funcionales (deseados o existentes).

actores (usuarios del sistema, no forman parte de él) → entidad

externa (persona, dispositivo) que interactua con el sistema

siguiendo un rol.

o primarios: para ellos el objetivo del caso de uso es esencial.

ej: el comprador del caballo.

o secundarios: el objetivo no es esencial. ej: parada del estado

que registra el certificado de venta.

relaciones que unen a actores y funcionalidades (caso de uso).

o relación de comunicación "comunicate": un actor con un

caso de uso en concreto (ej: el comprador fulanito, en un caso

de uso comprar, adquiere un caballo (objeto de la clases

caballo). Se representan con una linia ←→.

relaciones entre casos de uso. Tipos:

o inclusión "include" →son subfunciones obligatorias del caso

de uso. Sirve para compartir una funcionalidad para diversos

caso de uso (componentes preexistentes). Se representa con

INGENIERIA DE SOFTWARE Página 3

Page 4: TRABAJO PRÁCTICO UML

UPLA (UNIVERSIDAD PERUANA LOS ANDES)

linia discontinua.

o extensión "extend" → su aplicación es opcional, se decide en

el escenario. Sirve para estructurar el caso de uso básico.

INGENIERIA DE SOFTWARE Página 4

Page 5: TRABAJO PRÁCTICO UML

UPLA (UNIVERSIDAD PERUANA LOS ANDES)

Línia discontinua.

o generalización "generalize" → se consigue un subcaso, que

hereda el comportamiento y las relaciones del supercaso (sus

includes y extends).

existen generalizaciones abstractas no completas, y

seran los subcasos los que lo concretaran. ej: Compra

INGENIERIA DE SOFTWARE Página 5

Page 6: TRABAJO PRÁCTICO UML

UPLA (UNIVERSIDAD PERUANA LOS ANDES)

Caballo. Se escribe en cursiva.

Objetivos:

Soporte para modelado, desarrollo y validación (testeo) de la

aplicación.

Referencia para diálogo

Base de la documentación funcional del pliego de condiciones.

Escenario

Es una instancia de un caso de uso, dónde se fijan las condiciones

relativas de los eventos.

Un caso de uso puede encontrarse en distintos escenarios.

INGENIERIA DE SOFTWARE Página 6

Page 7: TRABAJO PRÁCTICO UML

UPLA (UNIVERSIDAD PERUANA LOS ANDES)

INGENIERIA DE SOFTWARE Página 7

Page 8: TRABAJO PRÁCTICO UML

UPLA (UNIVERSIDAD PERUANA LOS ANDES)

INGENIERIA DE SOFTWARE Página 8

Page 9: TRABAJO PRÁCTICO UML

UPLA (UNIVERSIDAD PERUANA LOS ANDES)

Ejercicio 4.En este Sistema de Venta por Catálogo los clientes hacen pedidos que recibe eldepartamento comercial y la empresa los sirve lo antes posible; y además ellos tambiénpueden devolver productos y cancelar pedidos.Analizar la identificación de actores y casos de usos del siguiente diagrama de casos deuso 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.

INGENIERIA DE SOFTWARE Página 9

Page 10: TRABAJO PRÁCTICO UML

UPLA (UNIVERSIDAD PERUANA LOS ANDES)

“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 RealizarPedido 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 enLogin que usa relaciones include a los otros casos de uso. Se pueden ver estos resultados en un 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”.

INGENIERIA DE SOFTWARE Página 10

Page 11: TRABAJO PRÁCTICO UML

UPLA (UNIVERSIDAD PERUANA LOS ANDES)

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 Figura1 (Sistema de Compras por Internet) y después al DCU de la Figura 2 (ComercioElectrónico).

Figura 1

El significado de los casos de uso es el siguiente.• GestionarCuentasCliente: el cliente puede crear, modificar y eliminar detalles de su cuentacomo 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;• GestionarProductos: el tendero puede añadir, actualizar o eliminar productos;• 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.

INGENIERIA DE SOFTWARE Página 11

Page 12: TRABAJO PRÁCTICO UML

UPLA (UNIVERSIDAD PERUANA LOS ANDES)

Figura 2

El significado de algunas palabras es el siguiente.• CVT (Continuously Variable Transmission): Transmisión de Variación Continua;• Shopkeeper: Comerciante;• Dispatcher: Expedidor.

INGENIERIA DE SOFTWARE Página 12

Page 13: TRABAJO PRÁCTICO UML

UPLA (UNIVERSIDAD PERUANA LOS ANDES)

Actor Semántica

Cliente Alguien que compra productos de Educativos con stock Limitado.

Comerciante Un Usuario del sistema que es responsable de manejar el catálogo de productos.

Administrador de sistema

Un Usuario especial del sistema que puede establecer derechos de acceso para otros Usuarios.

Distribuidor Un Usuario del sistema que es el trabajador del departamento comercial al cual se le limita

usuario Alguien que usa el sistema, al cual no es un Cliente.

Inventario El sistema de inventario de la Educación es limitada Claro.

Empresa de Tratamiento de Tarjeta

Una empresa externa que procesa transacciones con tarjeta de crédito de parte de la Educación en forma limitada.

INGENIERIA DE SOFTWARE Página 13