Actividad CASO de USO

7/25/2019 Actividad CASO de USO

1/12


2/12

Docente: Victor M. Chapilliqun Estrada [email protected] Pgina 2

CASOS DE USO (USE CASE)

QU SON LOS CASOS DE USO?Los casos de uso son una tcnica para especificar el comportamiento de un

sistema:"Un caso de uso es una secuencia de interacciones entre un sistema yalguien o algo que usa alguno de sus servicios."

Todo sistema de software ofrece a su entorno -aquellos que lo usan- unaserie de servicios. Un caso de uso es una forma de expresar cmo alguien oalgo externo a un sistema lo usa. Cuando decimos "alguien o algo" hacemosreferencia a que los sistemas son usados no slo por personas, sinotambin por otros sistemas de hardware y software.

Por ejemplo, un sistema de ventas, si pretende tener xito, debe ofrecer unservicio para ingresar un nuevo pedido de un cliente. Cuando un usuario

accede a este servicio, podemos decir que est "ejecutando" el caso de usoingresando pedido.

DIAGRAMAS CASO DE USO

El diagrama de casos de uso representa la forma en como un Cliente (Actor)opera con el sistema en desarrollo, adems de la forma, tipo y orden encomo los elementos interactuan (operaciones o casos de uso).

Un diagrama de casos de uso consta de los siguientes elementos:

Elementos Actor:

Una definicin previa, es que un Actor es un rol que unusuario juega con respecto al sistema. Es importantedestacar el uso de la palabra rol, pues con esto seespecifica que un Actor no necesariamente representa auna persona en particular, sino ms bien la labor querealiza frente al sistema.

Como ejemplo a la definicin anterior, tenemos el caso de un sistemade ventas en que el rol de Vendedor con respecto al sistema puedeser realizado por un Vendedor o bien por el Jefe de Local.

Caso de Uso:

Es una operacin/tarea especfica que se realiza tras una orden deAlgn agente externo, sea desde una peticin de un actor o bien

desde laInvocacin desde otro caso de uso.


3/12

Docente: Vctor M. Chapilliqun Estrada [email protected] Pgina 3

Relaciones:

o Asociacin

Es el tipo de relacin ms bsica que indica la invocacin

desde un actor o caso de uso a otra operacin (caso de uso).Dicha relacin se denota con una flecha simple.

o Dependencia o Instanciacin -----------------------

Es una forma muy particular de relacin entre clases, en la cualuna clase depende de otra, es decir, se instancia (se crea).Dicha relacin se denota con una flecha punteada.

o Generalizacin

Este tipo de relacin es uno de los ms utilizados, cumple unadoble funcin dependiendo de su estereotipo, que puede ser deUso (uses) o de Herencia (extends).

Este tipo de relacin esta orientado exclusivamente para casosde uso (y no para actores).

extends: Se recomienda utilizar cuando un caso de uso essimilar a otro (caractersticas).

Uses (include): Se recomienda utilizar cuando se tiene unconjunto de caractersticas que son similares en ms de uncaso de uso y no se desea mantener copiada la descripcin dela caracterstica.

De lo anterior cabe mencionar que tiene el mismo paradigmaen diseo y modelamiento de clases, en donde esta la dudaclsica de usar oheredar.

DESCRIPCIN DE LOS CASOS DE USO

Los casos de uso se documentan con texto informal. En general, se usa unalista numerada de los pasos que sigue el actor para interactuar con elsistema. A continuacin se muestra una parte simplificada de la descripcindel caso de uso "Ingresando Pedido".


4/12


Caso de Uso: Ingresando Pedido.

Actor: Empleado de Ventas.

1) El cliente se comunica con la oficina de ventas, e informa su nmero de

cliente

2) El oficial de ventas ingresa el nmero de cliente en el sistema

3) El sistema obtiene la informacin bsica sobre el cliente

4) El cliente informa el producto que quiere comprar, indicando la cantidad

5) El sistema obtiene la informacin sobre el productosolicitado, y confirma su disponibilidad.

6) Se repite el paso 4) hasta que el cliente no informa ms productos.

7)

Al describir los casos de uso aparece una de sus principales limitaciones.Supongamos que queremos describir un sistema en el cual la interaccin con elusuario es muy simple: ingresa un conjunto bsico de datos, y con esos datos elsistema realiza una gran cantidad de clculos, aplicando complejas frmulas.

Cmo hago con un caso de uso para especificar el comportamiento interno delsistema, si su comportamiento no es trivial? La respuesta es que los casos de usoson muy limitados para lograr este objetivo, ya que se basan en el uso de textoinformal. Por lo tanto, deberemos usar una nueva notacin para especificar estecomportamiento interno, algo equivalente a los diagramas de flujo de datos delanlisis estructurado. En UML se propone usar una notacin llamada "Diagrama deActividad", el moderno heredero del diagrama de flujo, o "flowchart".

Otra de las limitaciones de los casos de uso es que no hay una sintaxis clara paraindicar, dentro de la descripcin del caso, las decisiones e iteraciones. De estaforma, es comn que en las descripciones de los casos se deba recurrir a frasescomo "Se repite el paso X hasta que ocurre C", o "Si ocurre C se pasa al paso X".En estas situaciones lo importante no es la forma en la que se expresan lascondiciones e iteraciones, sino hacerlo de una forma consistente. Si la descripcindel caso fuera muy compleja, es conveniente usar notaciones grficas, por ejemplo

los diagramas de actividad.

AlternativasDurante la ejecucin de un caso de uso, suelen aparecer errores o excepciones.Por ejemplo, mientras se ingresa un pedido, el cliente puede solicitar un productoque est discontinuado. El sistema deber en este caso informar esta situacin alempleado que ingresa el pedido. Esas desviaciones del curso normal del caso deuso se llaman alternativas. Las alternativas tienen las siguientes caractersticas:1) Representan un error o excepcin en el curso normal del caso de uso.2) No tienen sentido por s mismas, fuera del contexto del caso de uso en el queocurren.


5/12


Si bien en la bibliografa las alternativas se documentan al final del caso deuso, la experiencia demuestra que resulta til documentar los casos entablas, mostrando el curso principal en la primera columna, y las alternativasen una segunda columna, como lo muestra el siguiente ejemplo:

De esta forma, es mucho ms simple ver en qu parte del caso de usopuede ocurrir la excepcin, y se mantiene la ventaja de poder leer de corridoel curso normal.

RELACIONES DE EXTENSIN

Muchas veces, la funcionalidad de un caso de uso incluye un conjunto depasos que ocurren slo en algunas oportunidades. Supongamos queestamos especificando un sistema en el cual los clientes pueden ingresarpedidos interactivamente, y que dentro de la funcionalidad del ingreso depedidos el usuario puede solicitar al sistema que le haga una presentacinsobre ios nuevos productos disponibles, sus caractersticas y sus precios.En este caso, tengo una excepcin dentro del caso de uso IngresandoPedido.

3) Caso de Uso: Ingresando PedidoActor: Empleado de ventas

Curso Normal Alternativas

1) El cliente se comunica con la oficina deventas, e informa su nmero de cliente2) El oficial de ventas ingresa el nmero decliente en el sistema3) El sistema obtiene la informacin bsicasobre el cliente

3.1 Si no est registrado, se leinforma que debe registrarse en

la oficina de clientes4) El cliente informa el producto que quierecomprar, indicando la cantidad5) El sistema obtiene la informacin sobre elproducto solicitado, y confirma sudisponibilidad.

5.1 Si no hay disponibilidad delproducto, el sistema informa lafecha de reposicin

6) Se repite el paso 4) hasta que el clienteno informa ms productos


6/12


La excepcin consiste en interrumpir el caso de uso y pasar a ejecutar el caso deuso Revisando Presentacin de Nuevos Productos. En este caso decimos que elcaso de uso Revisando Presentacin de Nuevos Productos extiende el caso de usoIngresando pedido y se representa por una lnea de trazos desde el caso que'extiende a'al caso que es "extendido"

Sistema de Ventas. II

Las extensiones tienen las siguientes caractersticas:

1) Representan una parte de la funcionalidad del caso que no siempre ocurre.

2) Son un caso de uso en s mismas.

3) No necesariamente provienen de un error o excepcin. En su libro, Jacobson

ejemplifica los casos de uso con ir a cenar a un restaurant. Para l, tomar cafdespus de cenar es un ejemplo de una extensin.

La pregunta que surge claramente es cul es la diferencia entre una alternativa y unaextensin? La respuesta puede derivarse de las caractersticas de cada uno:

Una extensin es un caso de uso en s mismo, mientras que una alternativa no.

Una alternativa es un error o excepcin, mientras que una extensin puede noserlo.

De todas formas, en la prctica aparecen dudas con respecto a la conveniencia deconsiderar algo optativo en un caso como una alternativa o una extensin, sobre todo

porque no queda claro si algo puede ser visto como un caso de uso en s mismo o no.Como regla aproximada en este caso podemos pensar que si algo opcional debe serexpresado con ms de un paso, seguramente es una extensin y no una alternativa.

RELACIONES DE USO (INCLUDE)

Es comn que la misma funcionalidad del sistema sea accedida a partir de varios casosde uso. Por ejemplo, la funcionalidad de buscar un producto puede ser accedida desde elingreso de pedidos, desde las consultas de productos, o desde los reportes de ventas porproducto. Cmo hago para no repetir el texto de esta funcionalidad en todos los casosde uso que la acceden? La respuesta es simple:


7/12


Sacando esta funcionalidad a un nuevo caso de uso, que es usado por los casos de loscuales fue sacada. Este tipo de relaciones se llama relaciones de uso y se representa poruna lnea punteada desde el caso que 'usa a'al caso que es 'usado'. Decimos, porejemplo, que el caso de uso Obteniendo reporte de ventas por producto usa al caso deuso Buscando producto.

Este concepto no es novedoso, es simplemente el concepto de la subrutina osubprograma usado en un nivel ms alto de abstraccin.

Las caractersticas de las relaciones de uso son:

1) Aparecen como funcionalidad comn, luego de haber especificado varios casos deuso.

2) Los casos usados son casos de uso en s mismos.

3)

El caso es usado siempre que el caso que lo usa es ejecutado. Esto marca ladiferencia con las extensiones, que son opcionales.

La definicin de las relaciones de uso y extensin deja una zona sin definir:

Qu pasa con la funcionalidad que es comn a varios casos de uso, pero al mismotiempo es opcional? Por ejemplo, pensemos en la impresin de un comprobante, algo queel usuario de un sistema puede o no hacer en distintos casos de uso. Si uno se gua por lafuncionalidad comn a varios casos, piensa que el caso de uso imprimiendo comprobantees usado por otros casos, pero si se gua por la opcionalidad, piensa que extiende a otroscasos. Como esto no queda claro a partir de la bibliografa, creemos conveniente que estetipo de situaciones se especifiquen como extensiones, ya que de esta forma podemosremarcar grficamente la opcionalidad de la relacin.

Obteniend

Sistema de Ventas

Ingresandoedido

Buscandodatos

Gerente

Empleadode ventas

Obteniendo reportede venta por

producto


8/12


EL PROCESO DE ANLISIS DE REQUERIMIENTOS CON CASOS DE USO

Esta seccin describe los pasos a seguir para aplicar la tcnica de anlisis de requerimientos concasos de uso.

Ident i f icar los Acto res

Si la primera pregunta que un analista debe hacer a sus usuarios es Para qu es estesistema?, la segunda es claramente Para quines es este sistema? Como mencionamosal hablar sobre los actores, identificar a todos ellos es crtico para un buen anlisis derequerimientos. Por lo tanto, antes de avanzar con los casos de uso, debo tratar deidentificar todos los tipos de usuario diferentes que tiene el sistema. Si el sistemafuncionar en una empresa, debo preguntar cules de las reas afectadas usarn oactualizarn su informacin.

A pesar de hacer una identificacin inicial de los actores, tambin debo repetirla a medidaque empiezo a describir los casos de uso, ya que al conocer ms detalles del sistema

pueden aparecer nuevos tipos de usuarios.

Ident i f icar los Principales Casos de us o de Cada Actor

El siguiente paso es enunciar los nombres de los principales casos de uso de cada uno delos actores que identifiqu en el paso anterior. No es necesario especificar cules son lasacciones dentro del caso de uso. Tampoco debo preocuparme si no aparecen muchoscasos, ya que existen tcnicas para encontrar nuevos casos de uso a partir de losexistentes.

Ident i f icar Nuevos Casos a Part i r de los Existentes

Uno de los principales errores que se pueden cometer al identificar requerimientos es algoque parece obvio, pero que muchas veces ocurre: olvidarse de algn requerimiento!Como los requerimientos estn en la cabeza de los usuarios, el xito de esta tareadepende de la habilidad del analista. Para ayudarnos a identificar nuevos casos de uso apartir de los casos existentes, podemos aplicar las mismas tcnicas utilizadas paraidentificar eventos segn el anlisis estructurado. Esta tcnica se basa en el anlisis decuatro situaciones posibles a partir de los requerimientos ya identificados.

Variaciones Significativas de Casos de Uso Existentes

Muchas veces existen variaciones en los casos de uso en funcin del actor que losejecuta, o del tipo de objeto sobre el que se apliquen. Por ejemplo, en el caso del sistemaque procesa pedidos, podemos hacernos las siguientes preguntas:

1) Existen distintos tipos de cliente que hagan pedidos?

2) Existen distintos tipos de pedidos, que lleven a acciones distintas por parte delsistema?


9/12


10/12


El caso "No Pagando Pedido", puede de nuevo ser significativo. Si el cliente nopaga el pedido, tal vez nuestro sistema deba hacer algo, y podemos estar frente aun nuevo caso de uso.

Casos de Uso que Preceden a Casos ExistentesUna buena pregunta para hacer frente a un caso de uso es:Qu es lo que tiene que ocurrir antes de este caso de uso?En el caso del cliente que hace un pedido, son muchas las cosas que puedenocurrir antes de ese caso:1) El cliente, por ejemplo, debe ser cliente. En esta situacin tal vez tenga unnuevo caso de uso 'Ingresando Cliente", que puede o no ser un caso de misistema.3) El cliente debe poder consultar cules son los productos existentes.

Probablemente este sea un caso de uso que ya haya sido identificado. Sin

embargo, usando esta tcnica muchas veces se descubren nuevosrequerimientos.

Casos de Uso que Suceden a Casos ExistentesEsto es similar al punto anterior. La pregunta que debo hacerme es:Qu ocurre despus de este caso de uso?En nuestro ejemplo de los pedidos, es evidente que la mayora de la funcionalidadde nuestro sistema recin empieza cuando el cliente hace un pedido. Por lo tanto,

analizar "cmo sigue la historia" es una buena forma de asegurarme que no estoydejando requerimientos sin identificar.

Ejemplo:

Como ejemplo esta el caso de una Mquina Recicladora:

Sistema que controla una mquina de reciclamiento de botellas, tarros y jabas. El

sistema debe controlar y/o aceptar. Registrar el nmero de temes ingresados. Imprimir un recibo cuando el usuario lo solicita:

a. Describe lo depositadob. El valor de cada itemc. Total

El usuario/cliente presiona el botn de comienzo


11/12


Existe un operador que desea saber lo siguiente:a. Cuantos temes han sido retornados en el da.b. Al final de cada da el operador solicita un resumen de todo lo

depositado en el da. El operador debe adems poder cambiar:

a.

Informacin asociada a temes.b.

Dar una alarma en el caso de que:i. tem se atora, i. No hayms papel.

Como una primera aproximacin identificamos a los actores que interactuan con elsistema:

Cliente Operador

Generar reporte diario

Depositar tem

Cambiar tem Operador

Luego, tenemos que un Cliente puede Depositar tems y un Operador puedecambiar la informacin de un tem o bien puede Imprimir un informe:

Adems podemos notar que un tem puede ser una Botella, un Tarro o una Jaba.

Depositar tem

extends

extends

\

extends

Depositar Botella Depositar Tarro

Depositar Jaba

SistemaMaquina deReciclaje


12/12


Otro aspecto es la impresin de comprobantes, que puede ser realizada despus de depositaralgn item por un cliente o bien puede ser realizada a peticin de un operador.

Depositar item Generar reportediario

Imprimir

Entonces, el diseo completo del diagrama Use Case es:

Depositar Botella

Documents

Actividad CASO de USO