Casos de uso del sistema

Comportamiento del Sistema 08/09/2002

Comportamiento del sistema

UML, rimenri@hotmail .com
Comportamiento del sistema , hoja 1

Objetivos: Comportamiento del sistema

Usted será capaz de:
n Definir el comportamiento del sistema
n Definir casos de uso y actores
n Entender cómo documentar casos de uso
n Usar un diagrama de caso de uso para mostrar los actores, los casos
de uso, y sus interacciones
n Definir los escenarios para los casos de uso


Ing. Ricardo Mendoza Rivera Hoja 1


¿Qué es el comportamiento del sistema?

n El comportamiento de un sistema es cómo un sistema actúa y
reacciona
o La actividad exterior visible y “testeable” de un sistema
n El comportamiento del sistema es capturado en los casos de uso
o Ellos describen el sistema, su ambiente, y la relación entre el
sistema y su ambiente


Conceptos importantes al modelar el caso
de uso

n Un actor representa cualquier cosa
que interactúe con él sistema

n Un caso de uso es una secuencia
Actor de acciones que un sistema realiza,
que produce un resultado
observable de valor para un agente

Use-Case




¿Qué es un modelo de Caso de Uso?

n Un modelo de caso de uso es un modelo de las funciones previstas del
sistema (casos de uso) y su entorno (actores)
n El mismo modelo de caso de uso es usado en análisis de requisitos,
diseño y prueba
n Especifica una secuencia de acciones, incluyendo variantes, que el
sistema puede incluir, y que produce un resultado observable de valor
para un actor

El propósito primario del modelo caso de uso es comunicar las funciones
El propósito primario del modelo caso de uso es comunicar las funciones
y el comportamiento del sistema al cliente o al usuario final
y el comportamiento del sistema al cliente o al usuario final


Beneficios del modelo de Casos de Usos
n El modelo de casos de usos
o Es usado para comunicarse con el usuario final y el experto del
dominio
l Proporciona credibilidad en una etapa inicial del desarrollo
del sistema
l Asegura una comprensión mutua de los requisitos
o Es usado para identificar
l Quién interactuará con el sistema y qué deberá hacer el
sistema
l Qué interfaz deberá tener el sistema
o Es usado para verificar que:
l Se capturan todos los requisitos
l Que los desarrolladores hayan entendido los requisitos




Actores

n Los actores no son parte del
sistema, ellos representan
roles que un usuario del
sistema puede desempeñar
n Un actor puede intercambiar
activamente la información
con el sistema
Actor n Un actor puede ser un
recipiente pasivo de la
información
n Un actor puede representar
a un humano, una máquina
u otro sistema


Encontrando Actores: Preguntas Útiles

n ¿Quién está interesado en cierto requisito?
n ¿Dónde en la organización se utilizará el sistema?
n ¿Quién proveerá, utilizará y eliminará esta información del sistema?
n ¿Quién utilizará esta función?
n ¿Quién le dará soporte y mantenimiento al sistema?
n ¿Usa el sistema un recurso externo?
n ¿Qué actores necesita el caso de uso?
n ¿Un actor desempeña varios roles?




Instancias de Actores

Insert card
1 2 3
Ivar actúa 4 5 6
como un 7 8 9
* 0 #
actor
Tom actúa
como un
actor

Modelo de Caso de uso

Actor Caso de uso


Un usuario puede actuar como varios
actores

César como
Insert card
1 2 3 operador
4 5 6
7 8 9
* 0 #

César Operador
César como
cliente
Cliente




Límites de los actores y del sistema

Mantenimiento
ATM
¿Límite del
Sistema?
Sistema ATM

Sistema Bancario
Cajero
Bancario


Casos de Uso

n Un caso de uso modela un diálogo
entre los actores y el sistema
n Un caso de uso puede ser iniciado
por un actor para invocar una cierta
funcionalidad en el sistema
Caso de Uso n Un caso de uso es un flujo de
eventos completos y significativos
n Tomados al mismo tiempo, todos
los casos de uso constituyen todas
las formas posibles de utilizar el
sistema




Encontrando Casos de Uso:
Preguntas Útiles

n ¿Cuáles son las tareas de este actor?
n ¿El actor, creará, guardará, cambiará, eliminará o leerá la información
en el sistema?
n ¿Cuál caso de uso creará, guardará, cambiará, eliminará o leerá esta
información?
n ¿Necesitará el actor informar al sistema sobre cambios externos e
imprevistos?
n ¿Es necesario que el actor esté informado sobre ciertas ocurrencias
en el sistema?
n ¿Le proporciona una correcta secuencia el sistema a las tareas?
n ¿Cuáles casos de uso le darán soporte y mantenimiento al sistema?
n ¿Pueden todos los requerimientos funcionales ser realizados por los
casos de uso?

Fuentes de Información para Casos de
Uso

n Especificaciones del sistema / Manifestación del problema
n Literatura relevante del dominio
n Entrevistas con expertos del dominio
n Conocimiento personal del dominio
n Sistema heredados




El Diagrama de Caso de Uso
n Un diagrama de un caso de uso ilustra como los casos de uso y los
actores interactúan, enviándose estímulos entre ellos

Realizar Transacciones

Cliente
Banco

Realiza reportes

ATM Mantenimiento
Mantener maquina ATM


Documentación de Caso de Uso

n Los casos de uso están documentados en
o Una breve descripción
l El propósito del caso de uso en unas pocas líneas
o Flujo de eventos detallados
l Descripción del flujo de eventos primario y alternativos que
ocurren cuando el caso de uso es iniciado
o La documentación debe leerse como un diálogo entre el actor y
el caso de uso
n Ambos documentos están escritos en términos que el cliente
entenderá




Flujo de Eventos Caso de Uso

n Cada caso de uso
o Tiene una secuencia de transacciones normal y básica
o Puede tener varias secuencias de transacciones alternativas
o Generalmente tiene varias secuencias de transacciones
excepcionales, las cuales manejan situaciones de error
o También puede tener pre y post condiciones bien definidas


Flujo de Eventos Caso de Uso (cont.)

n Describe solamente los eventos que pertenecen al caso de uso, y no
los que suceden en otros casos de uso
n Evita terminología vaga tal como “por ejemplo”, “etc.” e “información”.
n El flujo de eventos debe describir:
o Cómo y cuándo comienza y termina el caso de uso
o Cuándo el caso de uso interactúa con los actores
o Qué información se intercambia entre un actor y el caso de uso
l No describe los detalles de la interfaz del usuario
o El flujo de eventos básico
o Cualquier flujo de eventos alternativo




¿Quién Lee la Documentación de Casos
de Uso?
n Clientes -- aprueban lo que debe hacer el
sistema
n Usuarios -- obtienen comprensión del
sistema
n Desarrolladores del Sistema --
documentan el comportamiento del
sistema
n Revisores --examinan el flujo de eventos
n Analistas del Sistema (Diseñadores) --
proveen la base para un análisis y diseño
n “Probador” del Sistema -- usado como
base para casos de prueba
n Líder de Proyecto -- provee entradas para
el planeamiento de proyectos
n Escritor Técnico -- base para escribir la
guía del usuario

Ejemplo de Registro en Curso

n 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 prerequisitos . Información que es incluida para ayudar
a los estudiantes a tomar decisiones.
n 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 cobranzas, para
que al estudiante le puedan cobrar por el semestre.




Ejemplo de Registro en Curso (cont.)

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


Diagrama de un Caso de Uso




Breve Descripción -- Registrar Pedidos

1.1 Breve Descripción

El caso de uso es iniciado por el Asistente Comercial cuando des ea realizar
desea registrar los pedidos efectuados por los Agentes Comerciales a los
Clientes. Le proporciona la capacidad de crear, modificar, grabar, revertir,
eliminar y consultar pedidos; adem ás de finalizar la opción.


Flujo de Eventos -- Caso de Uso Registrar
Pedidos
2.1 Pre-condiciones
n El Asistente Comercial debe haber ingresado al sistema.
n Para el caso de ventas al crédito, los clientes deben de tener este status
definido previamente por el Supervisor Comercial
n Los datos del producto deben haber sido ingresados previamente.
n Se debe tener la información de los vendedores.
n Haber definido las diferentes formas de pago para las ventas realizadas.
2.2 Flujo principal
n El sistema muestra las actividades que se pueden seleccionar: Agregar,
Modificar, Grabar, Revertir, Consultar, Eliminar, Imprimir, Grabar y Salir.
n Si la actividad seleccionada es AGREGAR, se ejecuta un subflujo de Crear
Pedido
n Si la actividad seleccionada es MODIFICAR, se ejecuta un subflujo de Modificar
Pedido.
n Si la actividad seleccionada es ELIMINAR, se ejecuta un subflujo de Eliminar
Pedido.




Pedidos (cont.)
2.2 Flujo principal
n Si la actividad seleccionada es GRABAR, se ejecuta un subflujo de Grabar
Pedido.
n Si la actividad seleccionada es REVERTIR, se ejecuta un subflujo de Revertir
Pedido.
n Si la actividad seleccionada es IMPRIMIR, se ejecuta un subflujo de Imprimir
Pedido.
n Si la actividad seleccionada es CONSULTAR, se ejecuta un subflujo de
Consultar Pedido.
n Si la actividad seleccionada es SALIR, finaliza la ejecución de la opción.


Flujo de Eventos -- Caso de Registrar
Pedidos (cont.)
2.3 Sub-Flujo
A-1: Crear Pedido
n El sistema permite ingresar el Nro de Pedido
n El sistema verifica si existe el numero de Pedido (E-1)
n El usuario seleccionar el vendedor respectivo
n Se ingresa además el c ódigo del cliente, lo cual debe ser verificado por el
sistema (E-2)
n El usuario confirma o cambia la fecha del pedido y selecciona la forma de pago
que el sistema valida (E-3)
n Por cada item el usuario ingresa
o Código del producto
o El sistema muestra descripción del producto.
o El usuario ingresa cantidad a requerir (E-4).
o El sistema muestra el precio unitario, total por cada item
n El sistema le da la posibilidad de Quitar alguna línea en el detalle.
n El sistema muestra total del pedido por cada línea ingresada.




Pedidos (cont.)
2.3 Sub-Flujo
A-1: Crear Pedido
n Terminado el ingreso, el Asistente Comercial elige “Grabar” información de los
datos ingresados.
n El sistema valida la información ingresada (E-5).
n El sistema guarda la información ingresada (E-6).
n El caso de uso comienza nuevamente.

A-2: Modificar Pedido
n Puede modificar el documento editado o el Asistente Comercial selecciona el
pedido a modificar a partir del caso de uso: Consultar Pedido .
n El sistema muestra el contenido del pedido seleccionado.
n El usuario elige la opción de modificar (E-7).
n Puede modificar la parte de la cabecera de acuerdo a las validaciones
efectuadas en el Sub-Flujo Agregar Pedido.
n Por cada item mostrado por el sistema, el usuario puede modificar la cantidad
(E-4) y/o precio unitario.


Pedidos (cont.)
2.3 Sub-Flujo
A-2: Modificar Pedido
n Terminado el ingreso, si el Asistente Comercial elige
La actividad “Grabar” se ejecuta el flujo alternativo A -4: Grabar pedido
La actividad “Revertir” se ejecuta el flujo alternativo A -5: Revertir pedido
n El caso de uso comienza nuevamente .

A-3: Eliminar Pedido
§ Puede eliminar el documento editado o el Asistente Comercial selecciona el
pedido a eliminar a partir del caso de uso: Consultar Pedido.
§ El sistema muestra el contenido de pedido.
§ El usuario elige eliminar el Pedido (E-7).
§ El sistema solicita la confirmación de la eliminación del pedido.
n Si se confirma, el sistema elimina el pedido, caso contrario la petición es
cancelada y el caso de uso comienza nuevamente.




Pedidos (cont.)
A-4: Grabar Pedido

n El sistema valida la información ingresada (E-5)
n El sistema guarda la información ingresada (E-6).

A-5: Revertir Pedido
n El sistema deshecha los cambios efectuados
n El caso de uso comienza nuevamente .

A-6: Consultar Pedido
n El Asistente Comercial selecciona el pedido a modificar a partir del caso de uso:
Consultar Pedido.
n Mostrar datos del Pedido Seleccionado


Pedidos (cont.)
A-4: Imprimir un programa
n Puede imprimir el documento editado o el Asistente Comercial selecciona el
pedido a imprimir a partir del caso de uso: Consultar Pedido.
n El sistema muestra contenido del Pedido
n El usuario elige imprimir el Pedido
n El sistema muestra la interfaz de impresión de Windows .
n El caso de uso comienza nuevamente. El sistema imprime el programa (E-6). El
caso de uso comienza de nuevo.

2.5 Flujos Alternativos o de Excepción

E-1 : Verifica la existencia del pedido, si existe un mensaje es mostrado y se
permite el reingreso del nro del pedido
E-2 : Si el código del cliente existe se muestra la razón social y si no existe da la
posibilidad de reingresar el código o de hacer una búsqueda por la razón
social.




Pedidos (cont.)
2.5 Flujos Alternativos o de Excepción

E-3 : Si se elige la forma de pago al crédito y el cliente no está sujeto de crédito el
sistema emite un mensaje y no permite venta al crédito. Así mismo si la
venta es al crédito y el cliente está sujeto de crédito se verifica que no
tengan dos documentos pendientes de pago, si lo tiene se emite un mensaje
y no se permite venta al crédito.
E-4 : Se verifica la cantidad con el stock actual del producto, si no hay stock
suficiente se emite mensaje y se da la posibilidad a reingresar la cantidad o
anular la línea del item requerido.
E-5 : Antes de proceder a grabar se verifica, en caso la venta sea al crédito, si el
monto no es superior al saldo de crédito que posee el cliente.
E-6 : Se verifica que por lo menos exista una línea en el detalle y se halla elegido
un cliente.
E-7 : El sistema verificará que no se halla emitido el documento de pago, si es así
emite mensaje y termina ejecución de Sub-Flujo


Asociaciones y Relaciones

n La relación normal entre un Actor y un caso de uso está definida por
una asociación del esterotipo <<comunicate>> el cual se acostumbra
a no incluirlo, ya que constituye una relación natural, veamos el gráfico
sgte:

<<communicate>>

RegistrarPedido
AsistenteComercial

Equivale

RegistrarPedido
AsistenteComercial




n Hay 2 tipos de relaciones que podrían existir entre casos de uso: include
y extend. Muchos casos de uso podrían combinar la funcionalidad de
otros casos de uso
n Una relación Include entre casos de uso significa que el caso de uso
base incorpora explícitamente el comportamiento de otro caso de uso
en una instancia específica. Una relación include es dibujado como una
dependencia desde el caso de uso base hacia el caso de uso usado.
Esta relación implica obligatoriedad.
n Por ejemplo: imaginemos el caso de uso Registrar Pedido (caso de uso
base) incorpora el comportamiento del caso de uso Generar Documento.



n Cada vez que registra un Pedido en el sistema este deberá de generar
documentos sobre los cuales se manejarán las factura o boletas de pago,
a partir de los mismos se harán seguimiento de los pagos. Este caso de
uso implica una relación <<include>> ya que Registrar Pedido adquiere
todo el comportamiento de GenerarDocumentos. .




n Una relación Extend entre casos de uso significa que el caso de uso
base incorpora el implícitamente el comportamiento de otro caso de uso
en una instancia específica. Es usada para mostrar:
o Comportamiento opcional

o Comportamiento que es ejecutado bajo ciertas condiciones como
un disparador o alarma
o Diferentes flujos que pueden ejecutarse bajo una elección del
actor.


n Una.




n Se pueden elegir una clase
genérica de actores como Cliente y
especializarlas como: ClienteFijo y
ClienteTemporal. Esto se denomina
Generalización.
n Para el caso ha desarrollar los
clientesFijos son aquellos que están
sujetos de crédito y tienen precios
preferenciales. Un cliente
normalmente cuando compra por
primera vez es un Cliente Temporal,
luego bajo ciertas requisitos el
SupervisorComercial puede
cambiarle de tipo.


Lab 02: Comportamiento del Sistema



Casos de uso del sistema

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (19)

Similaire à Casos de uso del sistema

Similaire à Casos de uso del sistema (20)

Dernier

Dernier (16)

Casos de uso del sistema