análisis y diseño de sistemas de información inf-162cotana.informatica.edu.bo/downloads/4.2 casos...

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