Ejemplo
0 recomendaciones2,451 vistas
Este documento describe los diagramas de casos de uso de negocio y sistema. Explica que los casos de uso describen el comportamiento de un sistema desde la perspectiva del usuario, permitiendo definir los límites del sistema y las relaciones entre el sistema y el entorno. También cubre la identificación y estructuración de casos de uso de negocio y sistema, así como su representación a través de diagramas. Finalmente, discute cómo identificar los casos de uso del sistema a partir del análisis de los procesos de negocio.
Ejemplo
- 1. Modelado del Negocio Diagramas de Casos de Uso del Negocio y del Sistema
- 2. Sumario Casos de uso Casos de uso del Negocio Casos de uso del Sistema
- 3. Casos de uso
- 4. Casos de uso Los Casos de Uso (Ivar Jacobson) describen, bajo la forma de acciones y reacciones, el comportamiento de un sistema desde el punto de vista del usuario. Permiten definir los límites del sistema y las relaciones entre el sistema y el entorno. Los Casos de Uso son descripciones de la funcionalidad del negocio/sistema independientes de la implementación.
- 5. Casos de uso Los Casos de Uso cubren la carencia existente en métodos previos (OMT, Booch) en cuanto a la determinación de requisitos. Los Casos de Uso particionan el conjunto de necesidades atendiendo a la categoría de usuarios que participan en el mismo. Están basado en el lenguaje natural, es decir, es accesible por los usuarios.
- 6. Casos de uso vs. DFD • Un CU es una función (servicio o transacción) atómica ofrecida por el sistema al entorno (actores). • Un proceso de un DFD puede ser detallado en un DFD hijo. Así, el concepto de “explosión de proceso” sólo se aplica a los DFDs.
- 7. Casos de uso vs. DFD • Un CU y un proceso modelan una pieza de funcionalidad del sistema, pero su especificación es diferente. En un CU interesa expresar la funcionalidad mediante la interacción actores – sistema. En un proceso la funcionalidad se expresa mediante la transformación que se hace de los flujos de entrada para producir flujos de salida. • Un CU en general no modela un particionamiento (o detalle) funcional interno del sistema pues se concibe desde la perspectiva de los actores, es decir una visión externa del sistema. Un DFD, según sea el nivel de detalle, puede mostrar descomposición funcional interna del sistema.
- 8. ¿En qué momento se usa los CU?
- 9. Casos de uso del Negocio
- 10. Modelo de Casos de Uso del Negocio • Describe los procesos de un negocio, vinculados al campo de acción, y cómo se benefician e interactúan los socios y clientes en estos procesos. Estereotipos Actor del Negocio Caso de Uso del Negocio
- 11. Casos de uso
- 12. Casos de uso
- 13. Casos de Uso del Negocio (CUN) Secuencia de acciones, realizadas en el negocio, que producen un resultado de valor observable para ciertos actores del negocio. Desde la perspectiva de un actor individual, define un flujo de trabajo completo que produce resultados deseados. Cliente Vender Pasaje asociación Envía y/o recibe mensajes
- 14. Identificación de los procesos del negocio (Clasificación) Servicio de comidaCliente Marketing Cliente potencial Experto en relaciones públicas ProveedorComprar suministros (Ejemplo: Restaurante)
- 15. Identificación de los procesos del negocio (Agrupamiento de actividades) Un grupo funcional que responde a un objetivo de la organización y que puede involucrar a varias áreas. Función Proceso de negocio Distribución • Recepción • Embarque Compras • Elección de proveedores • Pago a proveedores Personal • Cubrimiento de plantilla • Capacitación (Ejemplo: Empresa productora)
- 16. Identificación de los procesos del negocio (Objetivos) (Ejemplo: Empresa de servicio) “Satisfacer pedidos de los clientes” SubObjetivo 1 ... ... SubObjetivo n •Atender pedido de los clientes. •Solicitra insumo a los proveedores. Cliente Atender pedido Comprar suministrosProveedor
- 17. Casos de uso Los Casos de Uso (Ivar Jacobson) describen, bajo la forma de acciones y reacciones, el comportamiento de un sistema desde el punto de vista del usuario. Permiten definir los límites del sistema y las relaciones entre el sistema y el entorno. Los Casos de Uso son descripciones de la funcionalidad del negocio/sistema independientes de la implementación.
- 18. Consideraciones acerca de los CUN • Su nombre y descripción breve son claras y fáciles de comprender. • Cada caso de uso del negocio es completo desde la perspectiva de un actor externo. • Cada caso de uso del negocio normalmente se involucra con, al menos, un actor. • Es posible que un caso de uso de apoyo no interactúe con ningún actor.
- 19. Diagrama de CUN Diagrama que representa gráficamente a los procesos del negocio y su interacción con los actores del negocio. Gerente de Relaciones Públicas Cliente Servicio de comida Proveedor Comprar suministros Cliente potencial Marketing (Ejemplo:Restaurant)
- 20. Convenios en la representación del Diagrama de CUN • Un caso de uso puede asociarse con uno o más actores. • Un caso de uso se comunica con al menos un actor, sino hay error en el modelo, excepto cuando: • CU abstracto (puede tenerlas). • CU hijo en una relación de generalización/especialización si en el padre se describe toda la comunicación.
- 21. Navegabilidad en las relaciones de comunicación entre actores y CUN • Indica quién inicia la comunicación en la interacción y se muestra con una flecha. • Si la fecha apunta al CUN, inicia el actor. • Si la flecha apunta al actor, entonces inicia el CUN. • La relación en los dos sentidos se muestra sin saetas. • Por cada flecha de comunicación se asume un mensaje de retorno. Convenios en la representación del Diagrama de CUN
- 22. Casos de uso Los Casos de Uso cubren la carencia existente en métodos previos (OMT, Booch) en cuanto a la determinación de requisitos. Los Casos de Uso particionan el conjunto de necesidades atendiendo a la categoría de usuarios que participan en el mismo. Están basado en el lenguaje natural, es decir, es accesible por los usuarios.
- 23. Estructuración de los CUN • Identificar los comportamiento en CUN que necesitan considerarse como casos de uso abstractos (casos de uso que no se instancian por si solos y que describen comportamiento reutilizable y compartido). • Encontrar actores del negocio que definan roles compartidos por varios actores del negocio.
- 24. Estructuración de los CUN • Relación de inclusión • Relación de extensión • Relación de Generalización-especialización
- 25. Relación de inclusión <include> Una relación que especifica un comportamiento definido para el CU de inclusión que se inserta explícitamente dentro del comportamieto definido para el CU base. El workflow del proceso entero está en el caso de uso base y el (los) caso(s) de uso incluido(s).
- 26. Se justifica cuando: • Se puede reusar en otros CUN el comportamiento incluido en el caso de uso base, o • Simplifica la comprensión del caso de uso base. Relación de inclusión <include>
- 27. Casos de uso vs. DFD • Un CU es una función (servicio o transacción) atómica ofrecida por el sistema al entorno (actores). • Un proceso de un DFD puede ser detallado en un DFD hijo. Así, el concepto de “explosión de proceso” sólo se aplica a los DFDs.
- 28. Venta de producto <<include>> Verificar política de descuento Cliente PARTICIONAR Es un CU de apoyo que no se relaciona con actores Relación de inclusión <include>. (Ejemplo: Empresa de servicios)
- 29. Relación de extensión <extend> Una vez definido el workflow de un caso de uso del negocio, se puede encontrar alguna conducta opcional u optativa. Tiene sentido definir un nuevo CU cuando: Modelar un workflow complejo o un subflujo separado, que raramente ocurre u ocurre bajo ciertas condiciones. Flujos distintos que pueden ejecutarse en base a la selección del actor.
- 30. Pasajero Manejo Especial de Equipaje <<extend>> Check-In Individual Relación de extensión <extend>. SOLO PARAALGUNOS PASAJEROS HAY QUE IR AL COUNTER DE EQUIPAJE ESPECIAL (Ejemplo: Aduana)
- 31. Generalización - especialización Se usa para mostrar worksflows que comparten estructuras, propósito y comportamiento. Un caso de uso padre se puede especificar en uno o más casos de uso hijos que representan formularios más especificos del padre.
- 32. Se utiliza para: Para no tener que describir el mismo flujo varias veces, se puede colocar el comportamiento común en un CUN. Generalización - especialización Se puede afirmar que constituyen tipos de procesos. Generalmente tienen un comportamiento similar pero con diferencias sustanciales que provocan que sean considerados CUN diferentes. Se recomienda usar cuando:
- 33. Generalización – especialización. Realizar visitas Realizar Visitas a clientes potenciales Realizar visitas a clientes registrados Jefe zonal (Ejemplo: Vendedores ambulantes)
- 34. Casos de uso vs. DFD • Un CU y un proceso modelan una pieza de funcionalidad del sistema, pero su especificación es diferente. En un CU interesa expresar la funcionalidad mediante la interacción actores – sistema. En un proceso la funcionalidad se expresa mediante la transformación que se hace de los flujos de entrada para producir flujos de salida. • Un CU en general no modela un particionamiento (o detalle) funcional interno del sistema pues se concibe desde la perspectiva de los actores, es decir una visión externa del sistema. Un DFD, según sea el nivel de detalle, puede mostrar descomposición funcional interna del sistema.
- 35. Generalización entre Actores. Ejemplo (Ejemplo:Hospital) Cliente Despacharmedicamentos enfarmacia Administrador Hospitalización AsignarcamasAdministrador ConsultaExterna Asignarcitas
- 36. Realizaciones de CUN Muestran la manera en que colaboran los trabajadores y entidades de negocio para ejecutar el proceso. Se documentan con: Diagramas de actividad Descripción textual Diagramas de clases Diagramas de secuencia
- 37. • nombre del caso del uso del negocio • actores • propósito • resumen • flujo de trabajo - Básico (normal) - Curso Alterno • otras secciones • Prioridad • Mejoras Descripción textual de los Casos de Uso
- 38. Nombre Atender pedido Actores CLIENTE Propósito Analizar viabilidad del Pedido del Cliente y ordenar su producción. Resumen: El caso de uso se inicia cuando el Cliente envía una orden de pedido de productos. El proceso da curso al pedido, analizando la posibilidad de satisfacerlo. El caso de uso finaliza cuando se le comunica al cliente el resultado final del análisis de su pedido. CURSO NORMAL DE EVENTOS Acción del actor Respuesta del proceso de negocio 1. El Cliente envía una orden de pedido que incluye fecha de solicitud, datos del cliente y productos solicitados. 9. El Cliente recibe la comunicación del resultado final del análisis del pedido. 2.El Comercial recibe el pedido del cliente por teléfono o correo ordinario de la empresa. 3.El Comercial revisa el pedido, comienza su procesamiento, y lo envía al Jefe Técnico. 4.El Jefe Técnico analiza la viabilidad de cada producto pedido por separado: Si el producto pedido está en Catálogo, se acepta su fabricación. 5. El Jefe Técnico informa al Comercial la aceptación o rechazo de cada producto. Si el pedido o parte de éste es aceptado pasar a 6 Si el pedido es rechazado pasar a 8 6.El Jefe Técnico crea una orden de trabajo para cada producto del pedido, a partir de la plantilla de fabricación y las envían al Jefe de Producción, quedando pendiente su lanzamiento. 7. El Jefe de Producción planifica la producción de las órdenes de trabajo recibidas. 8. El Comercial informa al cliente. Cliente Atender pedido
- 39. ¿En qué momento se usa los CU?
- 40. Casos de uso del Sistema
- 41. Casos de uso del sistema Artefacto narrativo que describe, bajo la forma de acciones y reacciones, el comportamiento del sistema desde el punto de vista del usuario (Jacobson). Descripciones de la funcionalidad del sistema independientes de la implementación. Establece un acuerdo entre clientes y desarrolladores sobre las condiciones y posibilidades (requisitos) que debe cumplir el sistema.
- 42. Casos de uso del sistema Descripciones de la funcionalidad del sistema independientes de la implementación.
- 43. Es el proceso de averiguar, por lo general en circunstancias difíciles, lo que se debe construir. Los usuarios deben saber lo que quieren •Cada uno sabe lo que hace, pero ninguno tiene una visión global •No saben qué parte de su trabajo puede transformarse en software.. •No saben cómo puede hacerse más eficiente la operación en su conjunto. Definición de Requisitos
- 44. Requisito funcional “Una capacidad o condición que el sistema cumplirá” Requisitos Desarrolladores Clientes y Usuarios
- 45. (Funcional) • Objetivos y metas para un sistema. • Si están presentes Cliente satisfecho (No Funcional) • Implícitos al sistema. • Puede que el cliente no los declare, pero si no están se siente insatisfecho. (Funcional y no funcionales) • Características que van más allá de la expectativas del cliente. Clasificación de los requisitos funcionales
- 46. Identificación de requisitos funcionales a partir del modelo del negocio •Descripciones textuales. •Diagrama de clases del modelo de objetos del negocio. •Diagrama de actividades. Actividades que serán automatizadas
- 47. Atender proyecto nuevoProyectista (Ejemplo: Empresa constructora) Diagrama de casos de uso del negocio
- 49. Requisito funcional • Registrar características de un proyecto • Analizar viabilidad económica 1.1 Evaluar factibilidad económica 1.2 Registrar resultados de la evaluación. 3. Analizar viabilidad técnica 1.1 Evaluar factibilidad técnica 1.2 Registrar resultados de la evaluación. 4. Registrar aprobación/rechazo de un proyecto
- 50. No son parte del sistema Puede intercambiar información con el sistema. Puede ser un recipiente pasivo de información. Actores
- 51. Actores
- 52. Identificación de los CU del sistema a partir del modelo del negocio CASO DE USO = PROCESO QUE OBTIENE UN RESULTADO DE VALOR
- 53. • Decidir si el trabajador del negocio va a utilizar el sistema de información. • De ser así, identificar un actor en el modelo de casos de uso del sistema. • Para cada caso de uso del negocio en el que participe el trabajador del negocio, crear un caso de uso del sistema. • Repetir estos pasos para todos los trabajadores del negocio. Comenzar con los trabajadores del negocio. Para cada uno: ¿Cómo identificar los casos de uso del sistema?
- 54. Ejemplo Casos de uso Económico Evaluar un proyecto económicamente Evaluar un proyecto técnicamente Jefe de obra Aprobar/rechazar proyecto
- 55. Casos especiales: Manejo del tiempo En algunos sistemas se tienen actividades que se ejecutan periódicamente, como por ejemplo, el cálculo de intereses de los clientes de un banco se realizan todas la noches. Para modelar esto se puede realizar lo siguiente: Casos de uso Calcular intereses Reloj
- 56. Perfeccionar la definición de casos de uso CASOS MÚLTIPLES DE USO GENERALIZACIÓN/ ESPECIALIZACIÓN DE CASOS DE USO GENERALIZACIÓN/ ESPECIALIZACIÓN DE ACTORES
- 57. Se duplica comportamiento en otros CU. Un CU es complejo y largo, y su separación facilita que sean manejables y comprensibles. ¿Cuándo escribir un caso de uso independiente? Crear casos de uso independientes (Representar relaciones <<include>> o <<extend>> entre los casos de uso). Reescribir los casos de uso de las actividades ramificadas.
- 58. Ejemplo Relación de inclusión • Casos de uso que tienen una parte común en sus funcionalidades. Pagar un servicio por Internet Usuario Chequear pagos realizados Verificar permiso <<include>> <<include>>
- 59. Ejemplo Relación de inclusión • Se observa una relativa independencia en una parte del flujo de trabajo que se describe, aún cuando no se reutilice. De ese subproceso solo interesa el resultado. Pagar un servicio por Internet <<include>> Usuario Redefinir deuda pendiente
- 60. Ejemplo Relación de extensión • Comportamiento opcional. Analizar discrepancias <<extend>> Especialista del banco Enviar e-mail a superior <<extend>> Resolver discrepancia
- 61. Ejemplo Relación de extensión • Comportamiento que es ejecutado solamente bajo ciertas condiciones. Pagar un servicio por Internet <<extend>> Especialista del banco Buscar cuentas alternativas
- 62. Ejemplo Relación de extensión • Flujos distintos y diferentes que pueden ejecutarse sobre la base de la selección del actor. Chequear pagos realizados <<extend>> Usuario Reportar discrepancias
- 63. Ejemplo Casos de uso múltiples Verificar permiso Redefinir deuda Reportar incongruencias Usuario Pagar un servicio por internet <<include>> <<include>> <<extend>>
- 64. Ejemplo Generalización/Especialización entre casos de uso Pagar Pagar en efectivo Pagar con tarjeta de crédito Usuario
- 65. Colocar Llamada Colocar Llamada Local Colocar Llamada Larga Distancia Generalización/Especialización entre casos de uso
- 66. Colocar Llamada Local 1.La persona (caller) levanta el auricular 2.El sistema presenta el tono de discar 3.La persona disca un dígito 4.El sistema quita el tono de discar 5.La persona introduce el resto del número 6.El sistema analiza el número 7.El sistema encuentra la parte correspondiente 8.El sistema conecta las partes 9.Las partes se desconectan
- 67. Colocar Llamada de Larga Distancia 1.La persona (caller) levanta el auricular 2.El sistema presenta el tono de discar 3.La persona disca un dígito 4.El sistema quita el tono de discar 5.La persona introduce el resto del número 6.El sistema analiza el número 7.El sistema envía el número a otro sistema 8.El sistema conecta las líneas 9.Las partes se desconectan
- 68. Descripción del caso de uso Colocar Llamada Segmento No.1. Proceso inicial. 1. La persona que llama (caller) levanta el auricular. 2. El sistema presenta el tono de discar. 3. La persona que llama disca un dígito. 4. El sistema quita el tono de discar. 5. La persona que llama introduce el resto del número. 6. El sistema analiza el número. Segmento No.2. Proceso especializado de conexión. Segmento No.3. Desconexión. 1. Las partes se desconectan.
- 69. Descripción de caso de uso COLOCARLLAMADA LOCAL Segmento No.2. Proceso especializado de conexión. 1. El sistema encuentra la parte correspondiente. 2. El sistema conecta las partes. Descripción de caso de uso COLOCARLLAMADA DE LARGADISTANCIA Segmento No.2. Proceso especializado de conexión. 1. El sistema envía el número a otro sistema. 2. El sistema conecta las líneas.
- 70. Ejemplo Generalización/Especialización entre actores Chequear estado de una cuenta bancaria Consultor de cuentas Especialista del banco Usuario Chequear pagos realizados Analizar discrepancias
- 71. Descripción de los casos de uso en formato de alto nivel Caso de uso: <Nombre> Actores: <Nombre de los actores> Descripción: <Frases que describan las acciones indicando los actores involucrados, debe quedar claro cómo se inicia y termina el proceso y de que forma intervienen los actores> Referencias: <Listado de requerimientos y casos de uso asociados, indicando tipo de asociación (include o extend)>
- 72. Casos de uso del Negocio
- 73. Ejemplo Descripción de casos de uso Caso de uso: Aprobar/rechazar un proyecto Actores: Jefe de obra Descripción: El caso de uso se inicia cuando se han realizado las evaluaciones técnica y económica de una propuesta de un proyecto y el Jefe de obra debe valorar si se aprueba o no su ejecución. El sistema debe permitir ver los resultados de estas evaluaciones y permitir que se registre las conclusiones del Jefe de obra (aprobar/rechazar y alguna otra consideración que justifique su decisión, culminando la ejecución del caso de uso.
- 74. Ejemplo Descripción de casos de uso Referencias R4 Precondiciones Existan proyectos ya evaluados técnica y económicamente y estén pendientes de aprobación o rechazo Poscondiciones Se cambia el estado del proyecto a rechazado o aprobado y se asocian las causas que motivaron la decisión Requerimientos especiales -
- 75. • Cada forma en que los actores usan el negocio/sistema se representa con un caso de uso. • Los CU son fragmentos de funcionalidad que el negocio/sistema ofrece para aportar un resultado de valor para los actores. • Un CU especifica una secuencia de acciones que el negocio/sistema puede llevar a cabo interactuando con sus actores, incluyendo alternativas dentro de la secuencia. Resumiendo...
- 76. •Un caso de uso entrega un resultado que añade valor a un actor en concreto. Al actor iniciador Evita CU muy pequeños A usuarios individuales reales Evita CU muy grandes Resumiendo...
- 77. Modelo de Casos de Uso del Negocio • Describe los procesos de un negocio, vinculados al campo de acción, y cómo se benefician e interactúan los socios y clientes en estos procesos. Estereotipos Actor del Negocio Caso de Uso del Negocio
- 78. – Comunicación Actor C aso deU so – Inclusión – Extensión – Herencia Caso de Uso Origen C aso deU so Desti no <<include>> Caso de Uso Origen Caso deUso Destino <<extend>> Caso de UsoHijo Caso de Uso Padre Tipos de relaciones en los DCU Resumiendo...
- 79. Los casos de uso describen los procesos de principio a fin. Representar pasos como CU Error común en los CU Se nombran: Utilizando verbos fuertes en infinitivo. Imprimir Recibo Es un paso del proceso más amplio “Comprar Productos” Resumiendo...
- 80. Describir los cursos alternos dentro de los cursos normales Error común en los CU Se debe definir una subsección dentro de la sección de cursos alternos para cada curso alterno. Resumiendo...
- 81. Acción del actor 1 El usuario suministra su identificación 3 Actualiza los datos de la nueva factura 5 El usuario concluye la operación. Respuesta del sistema 2 Localiza la identificación del usuario. Si no existe el usuario, ejecutar caso de uso “Registrar Usuario”. 4 Registra los datos de la factura. Caso de uso: Actualizar Factura Presencia de curso alterno dentro del curso normal Resumiendo...
- 82. Describir de manera insuficiente el caso de uso en aras de “ganar tiempo” Error común en los CU Resumiendo...