guia practica software.sesion06

10
ACTORES, CASOS DE USO, ASOCIACIÓN- ESPECIFICACIONES 2014 OBJETIVO ESPECÍFICO: Entender los modelos de caso de uso para detallar los requerimientos funcionales del Sistema. INDICADOR.- Identifica los actores y caso de uso para el desarrollo y construcción de software orientada a objeto (OO). CONCEPTO ACTORE S, ¿PARA QUE YO VOY A USAR EL SISTEMA? CADA RESPUESTAS ES UN CASO DE USO Ing. CAMAVILCA VEGA, Dámaris Martha 1

Upload: deisy-jakelin-celis-trinidad

Post on 19-Jan-2016

67 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Guia Practica Software.sesion06

2014

OBJETIVO ESPECÍFICO: Entender los modelos de caso de uso para detallar los requerimientos funcionales del Sistema.

INDICADOR.- Identifica los actores y caso de uso para el desarrollo y construcción de software orientada a objeto (OO).

CONCEPTO

ACTORES,

CASOS ¿PARA QUE YO VOY A USAR

EL SISTEMA?

CADA RESPUESTAS ES UN CASO DE USO

Ing.

CAM

AVIL

CA V

EGA,

Dám

aris

M

arth

a

1

Page 2: Guia Practica Software.sesion06

2014

I. GENERALIZACION.- Designa la relación de clasificación entre un elemento más general a un elemento más específico. Se representa por una flecha, que apunta de la clase más especializada, hacia la clase más general.

Ing.

CAM

AVIL

CA V

EGA,

Dám

aris

M

arth

a

2

Page 3: Guia Practica Software.sesion06

2014

Un des

cendiente hereda atributos y operaciones de sus antecesores.

II. ASOCIACION.- Se da por la interacción entre un actor y un caso de uso (suele ser bidireccional )

III. RELACIONES DE DEPENDENCIA.-

Existen varios tipos de dependencia predefinidas que se indican mediante estereotipos, por ejemplo:

Ing.

CAM

AVIL

CA V

EGA,

Dám

aris

M

arth

a

3

Page 4: Guia Practica Software.sesion06

2014

<< INCLUDE>>

Un caso de uso A incluye el caso de uso B, si la secuencia de interacciones de B forma parte de la secuencia de las interacciones de A.

Se suele utilizar esta relación cuando se detectan subsecuencias de interacciones comunes a varios casos de uso. Se saca “factor común”; así a reducir la duplicación de funcionalidad al factorizar el comportamiento común en los casos de uso que se reutilizan muchas veces.

SIEMPRE QUE OCURRE A TAMBIEN OCURRE B

1.- ES OBLIGATORIO

2.- NO SECUENCIAL

A este mismo caso de uso base A se le puede aplicar múltiples relaciones de inclusión. El mismo caso de uso incluido se puede incluir en múltiples casos de uso base.

A B

Ing.

CAM

AVIL

CA V

EGA,

Dám

aris

M

arth

a

4

Page 5: Guia Practica Software.sesion06

2014

La inclusión representa un comportamiento de encapsulado.

<<EXTEND>> Un caso de uso A puede extender el comportamiento de otro caso de uso B; típicamente cuando ocurren situaciones excepcionales. A completa la funcionalidad de B.

B AIn

g. C

AMAV

ILCA

VEG

A, D

ámar

is

Mar

tha

5

Page 6: Guia Practica Software.sesion06

2014

Cajero automático portátilEl banco UniBank necesita ayuda para modelar el sistema que hará funcionar sus nuevos cajeros automáticos portátiles. Éstos, del porte de un teléfono público, le permitirán al usuario realizar sólo las operaciones más simples: retirar, depositar y consultar saldo (no soportaran movimientos entre cuentas de otros bancos o compras de tarjetas de prepago telefónico). Para ello ten en consideración que:

Se pide ingresar la clave del usuario posteriormente al paso de la tarjeta por la ranura. No se puede retirar más fondos de los que realmente hay, notificando de esta

situación al usuario. Al 3er ingreso de clave no valida se queda decomisada la tarjeta en la ranura Si al hacer el retiro el saldo no alcanza, se notifica a la central y se cancela la

operación.

Ing.

CAM

AVIL

CA V

EGA,

Dám

aris

M

arth

a

6

Page 7: Guia Practica Software.sesion06

2014

Sistema de Registro:

Al comienzo de cada semestre, los estudiantes pueden requerir información de un catálogo de cursos, el cual contiene una lista de los cursos ofrecidos para el semestre, indicando para cada curso profesor, departamento y pre-requisitos. Información que es incluida para ayudar a los estudiantes a tomar decisiones.

El nuevo sistema permitirá a los estudiantes seleccionar cuatro cursos para el siguiente semestre. Además, cada estudiante podrá indicar dos cursos alternativos en caso de no poder ser asignado en su primera selección. El curso tendrá un máximo de diez estudiantes y un mínimo de tres. Un curso con menos de tres estudiantes será cancelado. Una vez que el proceso de registro es completado, el sistema de registro envía la información al sistema de cuenta, para que al estudiante le puedan cobrar por el semestre.

Los profesores deben ser capaces de acceder al sistema on-line para indicar qué cursos estarán enseñando. También necesitarán ver qué estudiantes se inscribieron para sus cursos.

Para cada semestre, existe un período de tiempo en el que los estudiantes pueden modificar sus horarios. Los estudiantes deben ser capaces de acceder el sistema durante este tiempo para agregar o retirarse de cursos.

Ing.

CAM

AVIL

CA V

EGA,

Dám

aris

M

arth

a

7

Page 8: Guia Practica Software.sesion06

2014

Un supermercado necesita automatizar la gestión de “pedidos a proveedores”, para cada una de sus sucursales. Para esto, se debe tener en cuenta lo siguiente:

El supermercado, tiene establecido un contrato de aprovisionamiento con varios proveedores. Un proveedor puede suministrar varios productos al supermercado, cada uno de ellos en exclusiva. A cambio, se negocia la frecuencia de distribución (cada día a las 8 de la mañana, cada martes, etc.), el “valor mínimo de pedido especial” y el precio de venta. Estos valores pueden volver a ser negociados posteriormente.

El sistema deberá realizar la solicitud automática de productos, según el nivel mínimo establecido para cada tipo de producto, para conseguir un aprovisionamiento a nivel normal, y sujetos a las restricciones temporales establecidas por los proveedores. Los valores mínimo y normal son definidos por el responsable de abastecimiento.

Un operario también puede realizar un pedido a proveedor. El sistema deberá evitar la duplicidad de pedidos. No deben existir dos pedidos a proveedor para un mismo producto.

El pedido es enviado al responsable de abastecimiento para su evaluación. Éste podrá decidir modificarlo o no. Independientemente de lo que haga, deberá decidir si aprueba el pedido. Si lo aprueba, enviará la solicitud de pedido al proveedor. Éste tramitará el pedido y lo entregará en el plazo establecido en la solicitud. Cuando llegue al centro de distribución, un operario se encargará de registrar la llegada del pedido.

El responsable de abastecimiento es el encargado de solucionar los conflictos que puedan aparecer, como por ejemplo, que una sucursal necesite un pedido lo antes posible y el proveedor no lo entregue hasta dentro de una semana. En este caso, deberá decidir si tramitar un pedido especial, consultando, si es necesario, al gerente de la sucursal.

Por último, el sistema deberá permitir registrar las variaciones extraordinarias del stock, como por ejemplo, por roturas, robos, incendios, etc.

Ejemplo: Descripción de la aplicación “Gestión de pedidos a proveedores”

Ing.

CAM

AVIL

CA V

EGA,

Dám

aris

M

arth

a

8

Page 9: Guia Practica Software.sesion06

2014

Ing.

CAM

AVIL

CA V

EGA,

Dám

aris

M

arth

a

9