LABORATORIO # 3

Análisis de sistemas

M en C JESUS MARTIN SILVA FERNANDEZ

UNSA –EPIS Calidad de Software Laboratorio 03: Análisis de sistemas

LABORATORIO 03: Análisis de Sistemas

OBJETIVO

Conocer, analizar y utilizar adecuadamente alguna herramienta para el análisis de sistemas

utilizando alguna metodología (Ejemplo UML).

ACTIVIDADES

Utilizando la herramienta ArgoUML, elaborar:

1. Diagrama de casos de uso para la descripción 1 del Anexo 1.

2. La descripción del diagrama 2, indique tipo de diagrama y regenere.

3. Diagrama de clases para la descripción 3 del Anexo 1

4. Completar los 3 tipos de diagramas para cada caso.

5. Revisar e indicar que normatividad se ha cumplido del estándar IEEE Std. 1016-1998
Recommended Practice for Software Design Descriptions

6. Genere una tabla de todos los diagramas UML, describa la utilidad de cada uno.

7. Genere un reporte de la práctica y exponga sus conclusiones

CRONOGRAMA

Generación de artefactos 90 minutos

Generación de reporte 15 minutos

UNSA –EPIS Calidad de Software Laboratorio 03: Análisis de sistemas

ANEXO 1

Descripción 1

Se ha de realizar el diagrama de casos de uso de un cajero automático en el que se pueden realizar las
operaciones siguientes:

 Retirar efectivo.

 Ingresar o depositar efectivo.

 Hacer transferencias.

 Obtener información de nuestra cuenta: movimientos, saldo, etc.

Para realizar cualquiera de las operaciones el cajero automático ha de validar la tarjeta y la clave que
introduce el usuario. Se debe considerar la interacción que tiene con el cajero, a la hora de realizar estas
operaciones, el banco y el consorcio. Llamaremos consorcio a la red de cajeros automáticos a las que se
suscriben los bancos para que los cajeros automáticos realicen las operaciones.

Diaggrama 2

Descripcion 3

Realiza el diseño de una aplicación para la gestión de pedidos. La aplicación deberá:

 Manejar clientes (se guarda su nombre, dirección, teléfono y e-mail), que pueden realizar

pedidos de productos, de los cuales se anota la cantidad en stock. Un cliente puede

tener una o varias cuentas para el pago de los pedidos. Cada cuenta está asociada a una
UNSA –EPIS Calidad de Software Laboratorio 03: Análisis de sistemas

tarjeta de crédito, y tiene una cierta cantidad disponible de dinero, que el cliente debe

aumentar periódicamente para poder realizar nuevos pedidos.

 Un cliente puede empezar a realizar un pedido sólo si tiene alguna cuenta con

dinero disponible. Al realizar un pedido, un cliente puede agruparlos en pedidos

simples o compuestos. Los pedidos simples están asociados a una sola cuenta de
pago y (por restricciones en la distribución) contienen un máximo de 20 unidades
del mismo o distinto tipo de producto. A su vez, un pedido compuesto contiene dos
o más pedidos, que pueden ser simples o compuestos. Como es de esperar, el sistema
debe garantizar que todos los pedidos simples que componen un pedido compuesto se
paguen con cuentas del mismo cliente. Además, sólo es posible realizar peticiones de
productos en stock.

 Existe una clase (de la cual debe haber una única instancia en la aplicación) responsable del

cobro, orden de distribución y confirmación de los pedidos. El cobro de los pedidos se

hace una vez al día, y el proceso consiste en comprobar todos los pedidos pendientes
de cobro, y cobrarlos de la cuenta de pago correspondiente. Si una cuenta no tiene
suficiente dinero, el pedido se rechaza (si es parte de un pedido compuesto, se
rechaza el pedido entero). Una vez que el pedido está listo para servirse, se ordena su
distribución, y una vez entregado, pasa a estar confirmado.