PRACTICA CASO DE USO (Caja “Self checkout” de Wal-Mart)

CASO DE USO COMPLETO

EJEMPLO DE CASO DE USO

ACTIVIDADES Y CASO DE USO

VIDEO UML

Que son los escenarios secundarios? Enumere escenarios secundarios del caso de uso: “Comprar gaseosa”.

Algunos escenarios secundarios a considerar son:

                      El estudiante no selecciona cuatro cursos primarios

                      El curso primario no está disponible

                      Cursos primarios y secundarios no están disponibles

                      No es posible agregar al estudiante a la lista de curso

                      No se puede crear el programa del estudiante

Caso de las gaseosas:

      El actor que inicia al caso de uso

      Condiciones previas para el caso de uso

      Pasos en el escenario

      Condiciones posteriores cuando se finaliza el escenario

      El actor se beneficia del caso de uso.

¿Enumere la secuencia de pasos en los escenarios?

      Escenario principal: El escenario principal representa el flujo exitoso más simple o habitual para el caso de uso.

     
Escenario Alternativo: Son formas alternativas al camino principal de llegar a las poscondiciones del caso de uso.

      Escenario de Excepción: Un escenario de excepción es una secuencia de pasos alternativos a los del camino principal que lleva a que el objetivo del caso de uso NO sea alcanzado, es decir que no se logre llegar a las post-condiciones el sistema.

¿Que es un escenario? Describa un ejemplo.

      Un escenario es una instancia de un caso de uso es un solo flujo a través de un caso de uso

      Cada caso de uso tendrá una red de escenarios

      Escenarios primarios

      Flujo normal - la forma en la que el sistema debiese funcionar  

      Escenarios secundarios

      Excepciones al escenario primario

Inserte las imágenes de las figuras: modelo de caso de usos proveniente de la máquina de gaseosas y con inclusión, extensión-inclusión.

En qué consisten las relaciones de inclusión y extensión (dibuje sus respectivos símbolos, e inserte la figura ejemplo de Relaciones de casos de uso).

 Inclusión:

Es una forma de interacción o creación, un caso de uso dado puede "incluir" otro. El primer caso de uso a menudo depende del resultado del caso de uso incluido. Esto es útil para extraer comportamientos verdaderamente comunes desde múltiples casos de uso a una descripción individual, desde el caso de uso. El estándar de Lenguaje de Modelado Unificado de OMG define una notación gráfica para realizar diagramas de casos de uso, pero no el formato para describir casos de uso

Extensión:

Es otra forma de interacción, un caso de uso dado, (la extensión) puede extender a otro. Esta relación indica que el comportamiento del caso de la extensión se utiliza en casos de uso, un caso de uso a otro caso siempre debe tener extensión o inclusión. Uso extensión puede ser insertada en el caso de uso extendido bajo ciertas condiciones. La notación, es una flecha de punta abierta con línea discontinua, desde el caso de uso extensión al caso de uso extendido, con la etiqueta «extend». Esto puede ser útil para lidiar con casos especiales, o para acomodar nuevos requisitos durante el mantenimiento del sistema y su extensión.

Resumen del caso de uso: “Comprar gaseosa” (utilice viñetas) hasta el tema “extensión de los casos de uso”.

      El caso de uso “comprar gaseosa”:

El actor en este caso de uso, es un cliente que desea comprar una lata de gaseosa. El escenario iniciara cuando el cliente inserte dinero, posteriormente realizara una selección; y si todo funciona bien, la maquina contara con, al menos, una lata de la gaseosa elegida, misma que podrá al alcance del cliente.

Veamos el caso en que la maquina se haya quedado sin gaseosa, otra secuencia de pasos en el caso de uso “comprar gaseosa”. Imagínelo como una ruta alternativa dentro del caso de uso. El cliente inicia el caso de uso al insertar dinero en la máquina y posteriormente hace una selección. La máquina no cuenta con ninguna lata de la gaseosa seleccionada, por la  que mostrara un mensaje al cliente que indicara que no tiene de esa marca. En ese punto, el cliente selecciona otra marca que la maquina entregara (siempre y cuando cuente con provisiones de esta marca), o devolverá el dinero.  

      Casos de uso adicionales:

Ya ha examinado a la máquina de gaseosa desde el punto de vista de un usuario: el cliente. Hay otros usuarios que intervienen, como el proveedor que tiene reabastecer a la máquina, el recolector de dinero (que tal vez sea el mismo que le proveedor) que tiene que recoger el dinero acumulado en la alcancía de la máquina. Esto nos indica que debemos crear al menos dos casos de uso “reabastecer” y “recolectar dinero”, cuyos detalles surgirán durante las entrevistas con los proveedores y los recolectores. 

El caso de uso de “Reabastecer”. El proveedor inicia este caso de uso dado que algún intervalo (digamos 2 semanas) ha pasado. El representante del proveedor la quita el seguro a la máquina, jala la puerta para abrir la máquina y llena el comportamiento de cada marca hasta su capacidad.  

El caso de uso de “Recolectar el dinero”, el recolector inicia debido también a que ha pasado cierto tiempo. La persona deberá seguir la misma secuencia que en “Reabastecer” para abrir la máquina. El recolector sacara el dinero de la máquina y seguirá los pasos de “Reabastecer” para cerrar y poner el seguro a la máquina.

      Inclusión de los casos de uso:

En los casos de uso “Reabastecer “y “Recolectar dinero”, tal vez distinguió ciertos pasos en común. Ambos empezaban con abrir la máquina, y finalizaban con el cierre de la máquina y su aseguramiento. ¿Podríamos eliminar la duplicación de pasos de un caso de uso al otro?

Si podemos. La forma de hacerlo es tomar cada secuencia de pasos en común y conforman un caso de uso adicional a partir de ellos. Combinemos los pasos necesarios para “quitar el seguro” y “abrir la maquina” y llamémoslos “exhibir el interior” y los pasos “cerrar la maquina” y “asegurarla” en otro caso de uso llamado “cubrir el interior”.

      Extensión de los casos de uso:

Es posible volver a utilizar un caso de uso de una forma distinta a una inclusión. En ocasiones crearemos un caso de uso agregándole algunos pasos a un caso de uso existente.

Si agregamos estos pasos a “Reabastecer”, tendremos un nuevo caso de uso llamaríamos “Reabastecer de acuerdo a las ventas”. Este nuevo caso de uso es una extensión del original, acción a la que se le conoce como extensión de un caso de uso. 

De esta forma, tendría que indicar al frente de la maquina el nuevo surtido de marcas disponibles. 

¿Cuales son las preguntas útiles para encontrar casos de uso?

Del Usuario

·                        ¿Quién es el cliente?

·                        ¿Quién es el usuario?

·                        ¿Son sus necesidades diferentes?

·                        ¿Cuáles son sus habilidades, capacidades, ambiente?

Del Proceso

·                        ¿Cuál es la razón por la que se quiere resolver este problema?

·                        ¿Cuál es el valor de una solución exitosa?

·                        ¿Cómo usted resuelve el problema actualmente?

·                        ¿Qué retrasos ocurren o pueden ocurrir?

Del Producto

·                        ¿Qué problemas podría causar este producto en el negocio?

·                        ¿En qué ambiente se usará el producto?

·                        ¿Cuáles son sus expectativas para los conceptos fácil de usar, confiable, rendimiento?

·                        ¿Qué obstáculos afectan la eficiencia del sistema?

¿Cuáles son las preguntas útiles para encontrar actores?

¿Quién arranca y para el sistema? 
¿Quién gestiona a los usuarios y la seguridad? 
¿Existe un proceso de control que reinicie el sistema si falla? 
¿Quién se encarga de la administración del sistema? 
¿Es un actor el "tiempo" porque el sistema hace algo como respuesta a un evento de tiempo? 
¿Quién evalúa la actividad o el rendimiento del sistema? 
¿Cómo se gestionan las actualizaciones de software? 
¿Actualizaciones automáticas o no? 
¿Quién evalúa los registros? 
¿Se recuperan de manera remota? 

¿Que es un diagrama de uso?

Jacobson (1994), además de introducir los casos de uso como elementos primarios del desarrollo del software, también diseñó un diagrama para la representación gráfica de los casos de uso. El diagrama de casos de uso es ya también parte del UML.

La descripción escrita del comportamiento del sistema al afrontar una tarea de negocio o un requisito de negocio. Esta descripción se enfoca en el valor suministrado por el sistema a entidades externas tales como usuarios humanos u otros sistemas

¿Cual es el propósito primario del modelo de caso de uso?

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

¿Por que el caso de uso es una herramienta valiosa?

El caso de uso es muy poderoso, pero lo es aun más cuando se visualiza por medio de UML. Esta visualización le permitirá mostrar los casos de uso a los usuarios para que ellos puedan dar mayor información. Es un hecho que los usuarios con frecuencia saben más de lo que dicen: el caso de uso ayuda a romper el hielo. A su vez, una representación visual le ayuda a combinar los diagramas de casos de uso con otro tipo de diagramas.

Una de las finalidades del proceso de análisis de un sistema es generar una colección de casos de uso. La idea es tener la posibilidad de catalogar y hacer referencia a esta colección, que sirve como el punto de vista de los usuarios acerca del sistema. Cuando llegue el momento de actualizar el sistema, el catalogo de casos de uso funcionara como un fundamento para obtener los requerimientos de la actualización

¿Que es un caso de uso (inserte la imagen)?

El caso de uso es un poderoso concepto que ayuda a un analista a comprender la forma en que un sistema deberá comportarse. Le ayuda a obtener los requerimientos desde el punto de vista del usuario. Es necesario aprender a visualizar los conceptos del caso de uso.

La vista de los casos de uso captura el comportamiento de un sistema, de un subsistema, o de una clase, tal como se muestra a un usuario exterior. Reparte la funcionalidad del sistema en transacciones significativas para los actores-usuarios ideales de un sistema. Las piezas de funcionalidad interactiva se llaman casos de uso. Un caso de uso describe una interacción con los actores como secuencia de mensajes entre el sistema y uno o más actores.

CASOS DE USO UML

ASOCIACION ENTRE CASOS DE USO

•         Permiten identificar similitudes entre casos de uso y tomar ventaja de ellas

•         UML provee tres tipos de asociaciones entre casos de uso

–        <<includes>>

–        <<extends>>

–        <<generalizes>>

Asociación <<includes>>

•         El caso “incluido” ocurre SIEMPRE que también ocurre el que lo incluye.

•         El caso “incluido” puede ser utilizado por varios casos de uso

Asociación <<entends>>

•         Esta asociación “aumenta” el comportamiento del caso que se extiende.

•         Se usan para cursos alternativos o situaciones de excepción. Por ejemplo, podría existir ya en funcionamiento el caso Registrar alumno a curso, y necesitar modificarse para agregar una excepción cuando el alumno es atleta, en vez de alterarlo se agrega la funcionalidad como un nuevo caso de uso.

Herencia entre actores <<generalizes>>

• La generalización de un actor A a un actor B indica que el actor B puede invocar los mismos casos de uso que el actor A.

Una instancia de administrador  puede invocar instancias de Renta Video y Administración Videos.  Una instancia de Cajero puede invocar únicamente Renta Video



FORO "UML"

¿Qué es UML?

El lenguaje unificado de modelado o UML (Unified Modelillg úlIIguage) es el sucesor de la oleada de métodos de análisis y diseño orientados a objetos (OOA&D) que surgió a finales de la década de 1980 y principios de la siguiente. El UML unifica, sobre todo, los métodos de 800ch, Rumbaugh (OMT) y Jacobson, pero su alcance llegará a ser mucho más amplio. En estos momentos el UML está en pleno proceso de estandarización con el OMG (Object Mallagemell' Group o Grupo de administración de objetos) y estoy seguro de que se convertirá en el lenguaje de modelado estándar del futuro.

Decimos, pues, que el UML es un lenguaje de modelado, y no un método. La mayor parte de los métodos consisten, al menos en principio, en un lenguaje y en un proceso para modelar. El lenguaje de modelado es la notación (principalmente gráfica) de que se valen los métodos para expresar los diseños. El proceso es la orientación que nos dan sobre los pasos a seguir para hacer el diseño.

Diagramas UML

Un diagrama es la representación gráfica de un conjunto de elementos con sus relaciones. En concreto, un diagrama ofrece una vista del sistema a modelar. Para poder representar correctamente un sistema, UML ofrece una amplia variedad de diagramas para visualizar el sistema desde varias perspectivas. UML incluye los siguientes diagramas:

Diagrama de casos de uso.

Diagrama de clases.

Diagrama de objetos.

Diagrama de secuencia.

Diagrama de colaboración

Diagramas de estado

Diagrama de actividades.

Diagrama de componentes.

Diagrama de despliegue.