análisis y diseño de sistemas de información inf-162cotana.informatica.edu.bo/downloads/4.2 casos...
TRANSCRIPT
IV. UML
MODULO IV
1
Análisis y Diseño de Sistemas de Información
INF-162
Facilitador: Miguel Cotaña Mier julio 2020
4.2 Casos de uso
2
Analista de negocios no-IT: esalguien que trabaja dentro del contextodel negocio (está implicada en la mejorade procesos, recorte de costes, etc.)
Un Information TechnologyBusiness Analyst: trabaja dentro delcontexto de proyectos IT (proyectospara comprar, adquirir o modificar algúnsoftware)
INTRODUCCION
3
La distinción no forma parte de UML,pero es un extensión válida y aceptada.
Las extensiones se realizan a través dela invención de nuevos estereotipospara los elementos de UML . Unestereotipo amplía el significado de unelemento de modelado. Por ejemplo, enel modelado de negocio, un “actor denegocio” es un estereotipo del actor deUML.
CASO DE USO DE NEGOCIO Y SISTEMA
4
Un “caso de uso” (sin calificativos) serefiere a la interacción con cualquiertipo de sistema.Un “caso de uso de negocio” es unainteracción con un sistema de negocio.Por ejemplo, “Procesar Reclamo” es uncaso de uso de negocio que describeuna interacción con una empresaproveedora de Internet.
5
En sus primeras reuniones con elcliente, querrá identificar todos losproceso de negocio a los que elproyecto afectará. Estos procesosson los casos de uso de negocio(representa un flujo de trabajoespecífico)
MODELAR CASOS DE USO DE NEGOCIO
6
Un diagrama de caso de uso denegocio (CUN) es un diagrama decaso de uso en el que el sistema quemodela es el área de negocio delmundo real. Ofrece una visióngeneral de los procesos y servicios(CUN) y las entidades que utilizanesos servicios o participan en suimplementación.
DIAGRAMAS-CASOS DE USO DE NEGOCIO
7
SIMBOLOS
Modelo de Casos de Uso del Negocio Vendedor
Caso de Uso de negocio
Actor de negocio
Trabajador
8
9
Un caso de uso especifica elcomportamiento de un sistema o deuna parte del mismo, y es ladescripción de un conjunto desecuencias de acciones, incluyendovariantes, que ejecuta un sistemapara producir un resultado observablede valor para un actor.
MODELAR CASOS DE USO DE SISTEMA
10
Es una técnica para capturarinformación de cómo un sistema onegocio trabaja actualmente, o decómo se desea que trabaje.Describe qué hace un sistema, pero noespecifica cómo lo hace.Proporcionan un medio para que losdesarrolladores, los clientes, usuariosfinales, lleguen a una comprensióncomún del sistema
11
Un caso de uso es el primer peldañoen la conversión de las necesidades delos usuarios a un sistemaautomatizado.Por ejemplo, se puede especificarcómo debería comportarse un cajeroautomático enunciando mediantecasos de uso cómo interactúan losusuarios con el sistema; pero no senecesita saber nada del interior delcajero.
12
Un caso de uso describe un conjuntode secuencias, donde cada secuenciarepresenta la interacción de loselementos externos al sistema (susactores) con el propio sistema.Se utiliza durante la captura derequisitos y el análisis para visualizar,especificar, construir y documentar elcomportamiento esperado del sistema.
13
Es un usuario del sistema, que necesita ousa alguno de los casos de uso. Unusuario puede jugar más de un rol. Unsolo actor puede actuar en muchos casosde uso; recíprocamente, un caso de usopuede tener varios actores. Los actoresno necesitan ser humanos pueden sersistemas externos que necesitan algunainformación del sistema actual.
ACTORES
Cliente
14
Requiere una lluvia de ideas y revisardocumentos sobre requerimientos. Unmétodo se basa en los actores:
Se identifican los actores relacionados con unsistema o empresa.
En cada actor, se identifican los procesos queinician o en que participan.
Otro método se basa en eventos:Se identifican eventos externos a los que unsistema ha de responder.
Se relacionan los eventos con los actores y
con los casos de uso.
IDENTIFICACION DE CASOS DE USO
Cliente
15
Explica gráficamente un conjunto decasos de uso de un sistema, losactores y la relación entre éstos y loscasos de uso. Estos últimos semuestran en elipses y los actores sonfiguras estilizadas.
Existe líneas de comunicaciones entrelos casos de uso y los actores; lasflechas indican el flujo de informacióno el estímulo.
DIAGRAMAS DE CASOS DE USO
16
Ofrece una clase de diagrama contextual, quepermite conocer rápidamente los actoresexternos de un sistema y las formas básica quela utilizan.
Cajero Cliente
Compra producto
Registra compra
Entrega cambio
Caja
17
Comunica (comunicates) Entre unactor y un caso de uso, denota laparticipación del actor en el caso deuso determinado.
TIPOS DE RELACIONES
ActorCaso de Uso
18
Incluye (include): Relación entre doscasos de uso, denota la inclusión delcomportamiento de un escenario enotro. Se utiliza cuando se repite uncaso de uso en dos o más casos deuso separados. Frecuentemente nohay actor asociado con el caso de usocomún.
Caso de Uso Origen Caso de Uso Destino
<<include>>
19
Un caso de uso incluido no contiene unafuncionalidad significante para laarquitectura del sistema;El diseñador se puede concentrar en elcaso de uso base y omitir los detallesparticulares del caso de uso incluido;Un caso de uso incluido está incompletopor naturaleza;Un caso de uso incluido no es ejecutadopor un actor distinto al actor del caso deuso base
20
Extiende (extends): Relación entredos casos, denota cuando un caso deuso es una especialización de otro. Seusa cuando se describe una variaciónsobre el normal comportamiento.
Caso de Uso Origen Caso de Uso Destino
<<extend>>
21
Un caso de uso extendido y suscasos de uso de extensión síentregan un resultado de valorobservable;Un caso de uso de extensión no esuna especialización del caso de usoextendido;Permite que el analista derequisitos se concentre con losusuarios en las nuevascaracterísticas del caso de usoextendido.
22
identificación
Transferenciaen Internet
Cliente
transferencia
<<include>>
<<extend>>
23
Los casos de uso se puedenaplicar al sistema completo.También se puede aplicar apartes del sistema, incluyendosubsistemas e incluso clases einterfaces individuales.
24
Pueden utilizarse también como labase para establecer casos deprueba.Aplicados a los subsistemas, sonuna fuente de pruebas deregresión; aplicados al sistemason fuente de pruebas del sistemay de integración.
25
Un caso de uso es, en esencia, unainteracción típica entre un usuario yun sistema de cómputo. Entre suspropiedades:
El caso de uso capta algunafunción visible para el usuario;El caso de uso puede ser pequeñoo grande;El caso de uso logra un objetivodiscreto para el usuario.
PROPIEDADES
26
En su forma más simple, el caso deuso se obtiene conversando con losusuarios habituales y analizando conellos las distintas cosas que deseenhacer con el sistema.Se debe abordar cada cosa discretaque quieran, darle un nombre yescribir un texto descriptivo breve.
27
¡No trate de obtener todos los detalles justo desde el principio; los obtendrá cuando los necesite!
¡Centrarse primero en los objetivos del usuario y después encontrar casos de uso que los
cumplan!
28
Una técnica excelente que permitemejorar la comprensión de losrequerimientos es la creación de casosde uso.UML incluye formalmente el conceptode casos de uso y sus diagramas deuso.
29
Es un documento narrativo quedescribe la secuencia de eventos deun actor que utiliza un sistema paracompletar un proceso.Son historias o casos de utilización deun sistema; no son exactamente losrequerimientos ni las especificacionesfuncionales, sino que ejemplifican eincluyen los requerimientos.
CASOS DE USO: Tipo texto
30
Según grado de detalle
Alto nivel
Expandido
Según prioridad para el desarrollo
Primarios
Secundarios
Opcionales
Según grado de abstracción
Esencial
Real
FORMATOS DE CASOS TIPICOS
31
Caso de uso: Comprar productos
Actores: Cliente, Cajero.
Tipo: Primario.
Descripción: Un Cliente llega a la caja con los artículos
que comprará. El Cajero registrará los artí-
culos, cobra y devuelve el cambio. El Clien-
te se va con los productos.
GRADO DE DETALLE: ALTO NIVEL
32
Muestra más detalles que uno dealto nivel; suelen ser útiles paraalcanzar un conocimiento másprofundo de los procesos y de losrequerimientos.
GRADO DE DETALLE: EXPANDIDO
33
La sección intermedia, secuencia depasos en los escenarios, es laparte medular del formatoexpandido; describe los detalles de laconversión interactiva entre losactores y el sistema (historia deactividades y terminación exitosa deun proceso).
34
Caso uso: Nombre del caso de uso
Actores: Lista de actores, indicando quién inicia.
Tipo: 1. Primario.
2. Esencial
Referencias
cruzadas: casos relacionados.
Propósito: Finalidad del caso típico.
Resumen: Repite el alto nivel o síntesis similar.
Secuencia de pasos en los escenariosAcción del actor Respuestas del sistema
Cursos alternos
35
Caso de uso: Comprar productos en efectivo
Actores: Cliente, Cajero.
Tipo: Primario y esencial
Resumen: Un cliente llega a la caja con artículos que desea
comprar. El cajero registra los productos y recibe
un pago en efectivo. Al terminar la operación, el
Cliente se marcha con los artículos comprados.
Referencias
cruzadas: funciones (casos relacionados).
Propósito: Capturar una venta y su pago en efectivo
Comprar productos en Libreria
36
Acción del actor Respuesta del sistema
1. Este caso de uso
comienza cuando un
Cliente llega a una caja
con productos que desea
comprar.
2. El cajero registra el
identificador de cada
producto;
Si hay varios productos de
una misma categoría, el
cajero también puede
introducir la cantidad.
Secuencia normal de eventos
3. Determina el precio del
producto e incorpora a la
transacción actual;
Se presentan la
descripción y el precio del
producto actual.
37
Acción del actor Respuesta del sistema
4. Al terminar de introducir el
producto, el Cajero oprime
el botón que indica que se
concluyó la captura del
producto.
5. Calcula y presenta el total
de la venta.
6. El Cajero le indica el total
al Cliente.
7. El Cliente efectúa un pago
en efectivo (efectivo
ofrecido) posiblemente
mayor que el total de la
venta.
38
Acción del actor Respuesta del sistema
8. El cajero registra la
cantidad de efectivo
recibida.
9. Muestra al Cliente la
diferencia. Genera factura.
10.El cajero deposita el
efectivo recibido y extrae
el cambio del pago.
11. Registra la venta
concluida
12.El Cliente se marcha con
los productos comprados.
Cursos alternos:Línea 2: introducción de identificador inválido. Indica errorLínea 7: el Cliente no tenia suficiente dinero. Cancelar latransacción.
39
SEGUN PRIORIDAD PARA DESARROLLO
Casos primarios de uso:representan los procesos comunesmás importantes.Casos secundarios de uso:representan procesos menores oraros;Casos opcionales de uso:representan procesos que pueden noabordarse.
40
GRADO DE ABSTRACCION: ESENCIALES
Los casos esenciales de uso son casosexpandidos que se expresan en unaforma teórica que contiene pocatecnología y pocos detalles deimplementación;Las decisiones de diseño se posponeny se abstraen de la realidadespecialmente las concernientes a lainterfaz para el usuario.
41
Acción de los actores Respuesta del sistema
1. El cajero registra el
identificador en cada
producto;
Si hay más de un producto
igual, el cajero puede
introducir de igual manera
la cantidad.
2. Determina el precio del
producto y agrega la
información sobre él a la
actual transacción de
venta.
Aparecen la descripción y
el precio del producto
actual.
3. Y así sucesivamente….. 4. Y así sucesivamente…..
42
GRADO DE ABSTRACCION: REAL
A diferencia de una versión esencial delcaso de uso, una versión real secompromete con el diseño
Acción de los actores Respuesta del sistema
1. En cada producto, el
Cajero teclea código del
producto en el campo de
entrada de la Ventana1.
Después oprime el botón
“introducir producto” con el
ratón u oprimiendo la tecla
<enter>
2. Muestra el precio del
producto y agrega la
información sobre él a la
actual transacción de
venta. La descripción y el
precio del producto actual
se muestran en el cuadro
de Texto2 de la Ventana1.
3. Y así sucesivamente….. 4. Y así sucesivamente…..