03 casos deuso

  • 1,211 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,211
On Slideshare
0
From Embeds
0
Number of Embeds
6

Actions

Shares
Downloads
18
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • La saeta indica flujo de información o el estímulo de inicio

Transcript

  • 1. Desarrollo de software orientado a objetos Unidad 3: Casos de Uso
  • 2. Agenda  Actores y casos de uso del Sistema  Especificación de casos de uso  Organización del modelo de casos de Uso
  • 3. Actores y casos de uso
  • 4. Casos de Uso y Procesos de Negocios EMPRESA ¿Cuáles son los procesos de negocios? SISTEMA ARTEFACTOS Casos de Uso del Negocio Análisis de requerimientos Casos de Uso
  • 5. Modelo de Casos de Uso  Un modelo de casos de uso describe las funciones a desarrollarse en el sistema y a los actores que las utilizan.  Es usado en los workflows de requerimientos, análisis y diseño y prueba. Objetivo: Comunicar la funcionalidad y el comportamiento al cliente y al usuario
  • 6. Workflows y Casos de Uso
  • 7. Casos de uso y Actores Actor representa cualquier cosa que interactúa con el sistema (humano, SW o HW). Ejemplo: Cajero Caso de Uso secuencia de acciones que obtienen resultados de valor para un actor Proceso del sistema
  • 8. Actores y ámbito del sistema Sistema Bancario Cliente Sistema ATM Cajero Bancario ¿Límites del Sistema?
  • 9. Definiendo los límites del sistema Usuarios Otros Sistemas Nuevo Sistema Sistema Heredado Mantención Comunicaciones Reportes
  • 10. Casos de Uso • El análisis de los casos de uso incluye entender el dominio de los procesos y el medio externo ¿Cuáles son los actores que participan en los procesos?
  • 11. Casos de Uso Error común ... Representar pasos Los casos de uso describen los procesos a automatizar.
  • 12. Actores  No son parte del sistema, son roles de un usuario.  Puede intercambiar información con el sistema (actor directo).  Puede ser un recipiente pasivo de información (actor indirecto).  Puede representar a un humano, una máquina o un SW.
  • 13. ¿Cómo encontrar los actores? Preguntas de ayuda  ¿Quién está interesado en cierto requerimiento (se beneficia o se ve afectado)?  ¿Dónde en la organización es usado el sistema?  ¿Quiénes usan, eliminan o suministran información?  ¿Quién usa una determinada función?
  • 14. ¿Cómo encontrar los actores?  ¿Quién soporta y mantiene el sistema?  ¿Usa el sistema un recurso externo?  ¿Cuáles actores necesita el caso de uso?  ¿Un actor juega diferentes roles? o ¿Varios actores juegan el mismo rol (generalización /especialización)?
  • 15. Instancias de Actores Iván se comporta como Actor del Sistema Inserte Tarjeta 1 4 7 * 2 5 8 0 3 6 9 # Tomás se comporta como Actor del Sistema Modelo de Caso de Uso Actor Caso de Uso
  • 16. Un usuario puede desempeñar el rol de varios actores…… Jimmy es Operador Insert card 1 4 7 * 2 5 8 0 3 6 9 # Jimmy Operador Jimmy también es Cliente Cliente
  • 17. Dos actores pueden realizar idénticas tareas Iván es un cliente Inserte Tarjeta 1 4 7 * 2 5 8 0 3 6 9 # Jimmy es un operador Usuario • Tanto el cliente como el operador pueden efectuar transacciones en un cajero automático • El cliente y el operador son usuarios del cajero automático. • El usuario puede efectuar transacciones en un cajero automático Cliente Usuario Operador Efectuar Transacciones
  • 18. Identificación de los casos de uso  Método basado en los Actores.  Método basado en Eventos.  Análisis del modelo de casos de uso del negocio (business modeling).  Análisis de Requerimientos.
  • 19. Método basado en los Actores  Se relacionan los actores vinculados con un sistema o empresa.  Para cada actor, se identifican los procesos que ellos inician o en los que participan.
  • 20. Método basado en los Actores Preguntas clave:  ¿Cuáles son las tareas de este actor?  ¿Qué objetivos concretos necesita alcanzar un actor?  ¿Puede el actor crear, almacenar, remover o leer información en el sistema?  El actor, ¿necesita estar informado acerca de las ocurrencias del sistema?
  • 21. Método basado en Eventos  Se identifican los eventos externos a los que un sistema debe responder.  Se relacionan los eventos con los actores y con los casos de uso.  Es útil para este método establecer una tabla de eventos.
  • 22. Tabla de Eventos Evento Entrada Se requiere Datos del registrar a un Cliente cliente Se requiere registrar una Venta Se requiere emitir un EECC Fuente Salida Destino Comprobante de Venta Cliente Estado de Cuenta Cliente Vendedor Datos de la Cajero Venta
  • 23. Análisis del modelo de casos de uso del negocio  Exploración de los diagramas
  • 24. Análisis del modelo de casos de uso del negocio  Transición natural (AS IS)
  • 25. Análisis del modelo de negocio  Transición natural (AS IS)
  • 26. Análisis del modelo de negocio  Análisis del diagrama de actividades GV : BA-Gerente Ventas AV : BW -Asistente Ventas Solicita revisión de l ista de precios Consulta información del mercado Si Define productos para la venta Hay nuevos productos? No No Es campaña SI Aprueba? No Busca productos a ofertar P1 : BE-Producto Si Remite Nueva Lista a T iendas Realiza ajuste de precios de productos y ofertas Envia lista a Gerente de Ventas PO : BE-Precio
  • 27. Análisis del modelo de negocio  Transición con mejora de procesos
  • 28. Análisis del modelo de negocio  Transición de los objetos de negocio
  • 29. Análisis del modelo de negocio  Redefinición de los procesos (TO BE)
  • 30. Matriz de actividades y requerimientos  Al identificar los requerimientos se pueden enlazar con los casos de uso (fase 2) Caso de uso de negocio Actividades Responsable Requerimientos Caso de uso Actor
  • 31. “Trazabilidad”: Enlace de requerimientos y casos de uso Característica del Sistema Caso de Uso Documento de Visión PR10:La máquina de reciclado deberá permitir que se agreguen nuevos tipos de botella. [UC4: “Agregue nuevo Tipo de Botella”] Para agregar nuevos tipos de botella se debe activar el modo “aprendizaje” e insertar 5 ejemplos... Verifique que los requerimientos de menor nivel, sean consistentes con los requerimientos estratégicos.
  • 32. Especificación de casos de uso
  • 33. Especificación de Casos de Uso  La especificación de un caso de uso es el documento narrativo que describe la secuencia de eventos que realiza un actor (agente externo) para completar un proceso, a través del uso de un sistema.
  • 34. Tipos de Casos de Uso  Primario: Representan los casos mas importantes y comunes. Ej.: Alquiler de libros  Secundario: Representan procesos menores o raros. Ej.: Alquiler entre bibliotecas.  Opcional: Representan que pueden no abordarse. Ej.: Remate de libros
  • 35. Niveles de especificación de casos de uso  Existen tres niveles de especificación de casos de uso dependiendo del nivel de identificación y desarrollo de los mismos.  De Alto Nivel  Esencial  Real
  • 36. Casos de uso de Alto Nivel  Describe el caso de uso muy brevemente, resumiendo la esencia del mismo en breves enunciados.  Son útiles durante el examen inicial de los requerimientos y del proyecto.  No influyen de manera determinante en las decisiones de diseño.
  • 37. Casos de uso de Alto Nivel Caso de Uso Realizar Préstamo Actores Socio (indirecto, iniciador) Bibliotecario (directo) Tipo Primario Descripción Un socio elige los recursos de biblioteca que desea solicitar en préstamo, luego el bibliotecario los registra como “prestados” y el socio se los lleva por un plazo determinado. Requerimientos R1, R2 Referencias
  • 38. Especificación Esencial  La especificación esencial de un caso de uso es el documento narrativo que describe la secuencia de eventos que realiza un actor (agente externo) para completar un proceso, a través del uso de un sistema.
  • 39. Escenario de un Caso de Uso  Un escenario es una instancia de un caso de uso, en donde se dan un conjunto de factores.  Cada cada de uso tiene un conjunto de escenarios clasificados en:  Primarios o de flujo de eventos normal (describen cómo trabaja usualmente el sistema).  Alternativos, se producen de acuerdo a excepciones con el escenario primario.
  • 40. Casos de uso esenciales  Entonces…muestran más detalle que uno de alto nivel.  Tiene una sección destinada al flujo normal de los eventos que los describe paso a paso.  Tiene muchas secciones destinadas a describir los flujos alternativos.  Se identifican las pre y post condiciones.  Se asocian los requerimientos especiales (No funcionales).
  • 41. Casos de Uso y flujo de eventos  Un caso de uso describe “que hace” un sistema, pero no identifica “cómo”.  Un flujo de eventos describe el cómo (parcialmente) al interior de un caso de uso.  Cuando se modela, es importante que se conserve la separación de la vista interna y externa.
  • 42. Caso de uso esencial: Encabezado Nombre Realizar Préstamo de Libros Actores Socio (Indirecto e iniciador) Bibliotecario (Directo) Tipo Primario y Esencial Propósito Capturar un préstamo y sus condiciones de devolución. Descripción Un socio elige los libros que desea llevarse en préstamo. El bibliotecario registra los libros y consigna su fecha de devolución. El socio se lleva los libros aceptando las condiciones que se le han indicado Requerimientos: R1, R2 Anexos: A1, A2 Referencias
  • 43. Caso de uso esencial: Flujo normal de eventos Acción del actor Respuesta del sistema 1. Comienza cuando el socio selecciona libros en calidad de préstamo y se identifica como socio 2. El bibliotecario registra al 3. socio y los libros solicitados por el socio Valida al socio y determina la fecha de devolución de los libros. 4. El bibliotecario termina el registro del préstamo. Muestra aviso de registro del préstamo OK 6. El socio se lleva los libros solicitados. 5.
  • 44. Caso de uso esencial: Flujo alternativo de eventos Acción del actor Respuesta del sistema En el punto 2 del flujo normal 2. El bibliotecario registra al 3. socio y los libros solicitados por el socio 4. El bibliotecario avisa al socio que debe regularizar su situación y finaliza el préstamo. Valida que el socio no existe o está con deudas
  • 45. Pre y Post Condiciones  Describen los cambios de estado del sistema cuando se ejecuta un caso de uso. Pueden ayudar a identificar las clases....después
  • 46. Pre Condiciones  Son suposiciones sobre el estado del sistema al iniciarse una operación.  Cosas que son importantes probar en el SW en algún momento de la ejecución.  Cosas que no serán sometidas a pruebas pero de las cuáles depende el éxito de la operación.
  • 47. Post Condiciones  Describen el estado de un sistema luego de ejecutarse un caso de uso.  No se refieren a las acciones a realizar en un futuro inmediato.  Se redactan con verbos en pasado. Cambios (en pretérito) de estado
  • 48. Post Condiciones  Categorías de PostCondiciones:  Creación y eliminación de objetos  Modificación de atributos  Asociaciones formadas y canceladas
  • 49. Ejemplo de Pre y Post-Condiciones  Pre-Condiciones:  Se deben reconocer los ejemplares de libros por código  El sistema debe conocer el tiempo de devolución estándar por tipo de socio.  Post-Condiciones:  Se creó un objeto préstamo.  Se asociaron ejemplares de libros al préstamo.  Se asoció un socio al préstamo
  • 50. Requerimientos Especiales  En esta sección del caso de uso se asocian los requerimientos no funcionales de mayor impacto sobre el caso de uso.
  • 51. Organización del modelo de casos de uso
  • 52. Diagramas de casos de uso  Representa un conjunto de casos de uso para un sistema, los actores y la relación entre casos de uso y Actores  Similar a un Diagrama de Contexto
  • 53. Diagrama de casos de uso BIBLIOTECA Reservar Libros Bibliotecario Realizar Préstamo Devolver Libros Socio
  • 54. Priorizar Casos de Uso Se puede hacer sobre la base de la experiencia...  Seleccionar los que influyan profundamente en la arquitectura básica, dando soporte al dominio y a las capas de servicio de alto nivel o  Escoger los que presenten el máximo riesgo, funciones urgentes o complejas en las primeras iteraciones.
  • 55. Priorizar Casos de Uso Seleccionar....  Los que requieran investigación a fondo o nueva tecnología.  Aquellos que representen procesos primarios o la línea de negocio.  Los que apoyen directamente el aumento de ingresos o la reducción de costos.
  • 56. Priorizar casos de uso Sobre la base de ponderaciones...  Se definen valores a los atributos de los requerimientos.  Se aplican pesos a los diferentes valores de los atributos.  Se calcula el peso total de cada requerimiento.  Se priorizan los requerimientos de mayor peso total.
  • 57. Priorizar casos de uso  Debe haber un caso de uso de inicio o arranque  Un caso de uso puede abordarse en varias iteraciones incrementando su funcionalidad.
  • 58. Organización del modelo de casos de uso  Tareas:  Establecer relaciones de "inclusión" entre los casos de uso.  Establecer relaciones de "extensión" entre los casos de uso.  Establecer las "generalizaciones" entre los casos de uso.  Establecer las "generalizaciones" entre los actores.  Evaluar los resultados.
  • 59. Relación de Generalización  La generalización entre casos de uso es como la generalización entre clases.  En concreto, significa que el caso de uso “hijo” adiciona o antepone el comportamiento del caso de uso “padre”
  • 60. Relación de Inclusión  Significa que un caso de uso base incorpora explícitamente el comportamiento de otro caso de uso.  Se usan para evitar describir el mismo flujo de eventos varias veces.  También se usan para ocultar funcionalidad.  Es esencialmente un ejemplo de delegación.
  • 61. Relación de Extensión  Significa que existe un caso de uso base que implícitamente incorpora el comportamiento de otro caso de uso.  El caso de uso base puede desarrollarse normalmente, pero ante ciertas condiciones sus operaciones pueden extenderse al comportamiento de otro caso de uso.  Las casos de uso de extensión se pueden encontrar en los flujos alternativos de eventos significativos.
  • 62. Ejemplos de relaciones Programar Ordenes «extensión» Colocar Ordenes urgentes «inclusión» Efectuar seguimiento de Ordenes «inclusión» Validar password Validar Usuario generalización Escaneo de Fotochecks
  • 63. Uso de Paquetes  Los paquetes se usan para agrupar casos de uso de acuerdo a grandes procesos o gestiones.  Los paquetes deben guardar relación con la estructura del menú de la aplicación y los casos de uso con las funciones/opciones del mismo.
  • 64. Uso de Paquetes  Un primer diagrama debe organizar los grandes procesos en paquetes.  Cada paquete se puede descomponer en otro paquete o en casos de uso.  En un diagrama de paquetes no debe haber casos de uso.  La única relación entre paquetes es la dependencia.  La organización de paquetes en los casos de uso debe ser similar a la forma como se organiza el menú de la aplicación.
  • 65. Uso de paquetes Gestión de Pedidos Gestión de Ventas Gestión de Cobranza
  • 66. Conclusiones  El modelo de casos de uso sirve como herramienta de comunicación con los usuarios y otros expertos.  Permite organizar los requerimientos del sistema.  Permite identificar interacciones de los actores con el sistema.  Permite identificar interfaces.  Permite planificar iteraciones.  Permite establecer el plan de pruebas del sistema.