Your SlideShare is downloading. ×
  • Like
Unidad 4 Mad Modelado Analisis Casos De Uso
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Unidad 4 Mad Modelado Analisis Casos De Uso

  • 9,859 views
Published

Curso de Metodología de Análisis y Diseño - Cap 4

Curso de Metodología de Análisis y Diseño - Cap 4

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

Views

Total Views
9,859
On SlideShare
0
From Embeds
0
Number of Embeds
3

Actions

Shares
Downloads
312
Comments
2
Likes
3

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

Transcript

  • 1. Análisis y UML “ Fundamento de los Casos de Uso” Metodologías de Análisis y Diseño Unidad IV Sergio Sánchez Rios. Ingeniero en Informática – Licenciado en Informática
  • 2. UML: Fundamentos de los modelos de Caso de Uso Fueron presentados por primera vez por Jacobson a principios de los 90. Los casos de uso documentan el comportamiento del sistema (acción y reacción) desde el punto de vista del usuario. Como <<usuario>> se entiende cualquier cosa que ajena al sistema se desarrolla y que interactúa con el mismo (persona, sistema de información, dispositivos de hardware, etc.). El modelado de caso de uso ayuda con tres de los aspectos más difíciles del desarrollo: La captura de requisitos, La planificación de las iteraciones del desarrollo, La validación de los sistemas.
  • 3. UML: Fundamentos de los modelos de Caso de Uso Definición: Un caso de uso especifica un comportamiento deseado del sistema. Representan los requisitos funcionales del sistema. “ Un caso de uso especifica una secuencia de acciones, incluyendo variantes, que el sistema puede ejecutar y que produce un resultado observable de valor para un particular actor” . Describe que hace el sistema, no como lo hace.
  • 4. UML: Fundamentos de los modelos de Caso de Uso Un diagrama de caso de uso es relativamente fácil de comprender de forma intuitiva, incluso sin conocer la notación. Esto es una ventaja importante. Figura que representa al caso de uso. Un caso de uso individual representa un tipo de tarea que tiene que soportar el sistema Los casos de uso también se describen en detalle, normalmente en texto. (Descripción de alto nivel, Formato expandido)
  • 5. UML: Fundamentos de los modelos de Caso de Uso Otro componente de los caso de uso es el Actor , normalmente aparece con el símbolo de un muñeco, representa un tipo de usuario del sistema. Notación UML Un actor es una entidad externa del sistema que de alguna manera estimula el sistema con eventos de entrada o espera una respuesta del sistema.
  • 6. UML: Fundamentos de los modelos de Caso de Uso
    • Los actores suelen ser los roles representados por las personas, como también cualquier tipo de sistema. Ejemplo:
      • Roles: Cliente, Cajero, Alumno, Profesor.
      • Sistemas de Computo.
      • Aparatos electrónicos o mecánicos.
      • El tiempo puede ser un actor (“procesos iniciados por el sistema”)
    La misma persona física puede desempeñar varios roles distintos.
  • 7. UML: Fundamentos de los modelos de Caso de Uso Ejemplo: Hay una línea que conecta un actor con un caso de uso si el actor interactúa con el sistema para realizar parte de la tarea. (Comunicación sencilla).
  • 8. UML: Actores en Detalle Beneficiarios : Cada caso de uso tiene que representar una tarea, que se le requiere al sistema que soporte. Normalmente esto significa que el caso de uso tiene valor para al menos uno de los actores. Al actor para el que un caso de uso tiene valor se le llama beneficiario del caso de uso . Por esta razón los desarrolladores tienen que conocer quién necesita un caso de uso (Actor Primario) y quien esta implicado en él sin obtener ningún beneficio (Actor Secundario). Identificar los actores: los usuarios humanos potenciales de un sistema, tienden a ser relativamente fáciles de identificar. Para desarrollar un modelo de caso de uso se necesita identificar los roles que estos humanos pueden desempeñar.
  • 9. UML: Actores en Detalle
    • Actores no humanos: la situación con los actores no humanos tiende a ser menos clara, principalmente debido a que es menos claro qué se debería considerar como un sistema externo o dispositivo.
    • La solución es pragmática: se hace lo que parece que va a ser más útil, y distintas personas tienen visiones diferentes. Incluso si esta claro lo que es un sistema externo o dispositivo, nace una pregunta qué cosa debería aparecer en un caso de uso. Fowler y Scott, resumen diciendo que se pueden mostrar las interacciones con sistemas externos:
        • Siempre.
        • Cuando es el otro sistema o dispositivo el que inicia el contacto.
        • Cuando es el otro sistema o dispositivo el obtiene algo del contacto.
  • 10. UML: Propiedades de los casos de uso
    • Son iniciados por un actor con un objetivo en mente y es completado con éxito cuando el sistema lo satisface.
    • Pueden incluir secuencias alternativas que llevan al éxito y fracaso en la consecución del objetivo.
    • El sistema es considerado como una “caja negra” y las interacciones se perciben desde fuera.
    • El conjunto completo de casos de uso especifica todas las posibles formas de usar el sistema, esto es el comportamiento requerido .
  • 11. UML: Escenarios y Casos de Uso Un caso de uso describe un conjunto de secuencias de interacciones o escenarios: flujo principal y flujo alternativos o excepcionales . Un escenario es una instancia de un caso de uso.
  • 12. UML: Ejemplo Sist. Punto de Venta Comprar producto Log In Pagar producto Inicializar Terminar Agregar usuarios Cajero Cliente Sist. Adm. Gerente Agregar nuevos usuarios Sistema administrador Iniciar Terminar Gerente Comprar productos Paga productos Cliente Log in Dar vuelto Cajero Caso de uso Actor
  • 13. UML: Formato para Casos de Uso
    • Descripción en lenguaje natural, respetando el dominio del problema.
    • Formatos:
      • Formato de Alto nivel : describen muy clara y concisamente un proceso.
      • Formato expandido : describe un proceso en mayor detalle, concentrándose en el curso de los eventos: describen los detalles de la interacción entre el sistema y sus actores.
  • 14. UML: Formato para Casos de Uso
    • Descripción del formato de alto nivel
      • Caso de Uso : Nombre del Caso de Uso
      • Actores : Lista de Actores (agentes externos)
      • Tipo : Primario (Representa un proceso común e importante), Secundario (representa un proceso menor o raro), Opcional (representa un proceso que no debe abordarse necesariamente)
      • Descripción : Resumen de los eventos involucrados en el caso de uso.
  • 15. UML: Formato para Casos de Uso Descripción del formato de alto nivel Ejemplo: Primario Tipo: Un cliente llega a la caja registradora con los artículos que comprará. El Cajero registra los artículos y recibe el pago, el cual debe ser autorizado. Al terminar la operación, el Cliente se marcha con los artículos comprados. Descripción: Cliente, Cajero Actores: Comprar productos Caso de uso:
  • 16. UML: Formato para Casos de Uso
    • Descripción formato Expandido
    • Primera Sección:
      • Caso de Uso : Nombre del Caso de Uso.
      • Actores : Lista de Actores (agentes externos), en el cuál se indica quien inicia el caso de uso.
      • Propósito : Intención del caso de uso.
      • Precondición : Descripción de las condiciones que deben satisfacerse antes de dar inicio al caso de uso. No se prueban en el caso de uso se asumen que son verdaderas.
  • 17. UML: Formato para Casos de Uso
    • Descripción formato Expandido
    • Primera Sección:
      • Resumen: Repetición de la descripción de alto nivel.
      • Tipo : 1.- Primario, secundario u opcional. 2.- Esencial (caso de uso expandido libre de aspectos tecnológicos y detalle de implementación (diseño, interfaz usuario, etc.), Real (caso de uso expandido que describe concretamente el proceso a partir de su diseño concreto actual, sujeto a las tecnologías especificas de entrada.
  • 18. UML: Formato para Casos de Uso
    • Descripción formato Expandido
    • Primera Sección:
      • Referencia Cruzada: casos de uso y funciones relacionadas con el sistema.
    • Segunda Sección: Curso normal de eventos (Escenario principal de éxito y pasos).
      • Detalle de la conversación iterativa entre los actores y el sistema.
      • Se explica la secuencia genérica más común no las situaciones alternativas.
  • 19. UML: Formato para Casos de Uso Descripción formato Expandido Segunda Sección: Formato Dos columnas Descripción numerada de las respuestas del sistema Acciones numeradas de los actores Responsabilidad del Sistema (Respuesta del Sistema) Acción del Actor
  • 20. UML: Formato para Casos de Uso
    • Descripción formato Expandido
    • Ultima Sección: Curso alternativo de eventos
      • Describe las opciones o excepciones más importantes que pudiesen presentarse en el curso normal de eventos. Si son muy complejas pueden convertirse en otro caso de uso o sección.
  • 21. UML: Formato para Casos de Uso Descripción formato expandido Ejemplo: Funciones: R1.1, R1.2, R1.3, R1.7, R2.1 Referencias Cruzadas: Primario y esencial Tipo: Un cliente llega a la caja registradora con los artículos que comprará. El Cajero registra los artículos y recibe el pago, el cual debe ser autorizado. Al terminar la operación, el Cliente se marcha con los artículos comprados. Resumen: Capturar una venta y su pago en efectivo. Propósito: Cliente (iniciador), Cajero Actores: Comprar productos Caso de uso:
  • 22. UML: Formato para Casos de Uso Descripción formato expandido Ejemplo: Segunda Sección 12.- El cliente se marcha con los artículos comprados 11.- Registra venta concluida 10.- El cajero deposita el efectivo recibido y extrae el cambio 9.- Muestra al cliente la diferencia, emite recibo 8.- El cajero registra la cantidad de efectivo recibido 7.- El cliente efectúa el pago en efectivo (el efectivo ofrecido probablemente es mayor que la venta) 6.- El cajero indica el total al cliente 5.- Calcula y presenta el total de la venta 4.- Al terminar de introducir el producto. El cajero indica que se concluya la captura de productos 3.- Determina el precio del producto e incorpora a la transacción actual la información correspondiente. Se presenta la descripción y el precio actual del producto. 2.- El cajero registra la identificación de cada producto. Si hay varios productos de una categoría, se puede introducir la cantidad 1.- Comienza cuando el cliente llega a una caja con productos que desea comprar. Respuesta del sistema Acción de los actores
  • 23. UML: Formato para Casos de Uso
    • Descripción formato expandido
    • Ejemplo: Ultima Sección Casos Alternativos
      • Línea 2: Introducción del identificador invalido. Indicar Error.
      • Línea 7: El cliente no tenia suficiente dinero. Cancelar Venta.
  • 24. UML: Formato para Casos de Uso Otros formatos Formato de una línea para eventos. Nota: No existe el formato ideal. Algunos prefieren un a columna otros dos. Quitan y agregan secciones. Sin embargo esto no es importante, la clave está en escribir el curso normal de eventos y los curso alternativos en alguna forma.
  • 25. UML: Limite del Sistema Opcionalmente, puede haber una caja en un diagrama de casos de uso, alrededor de los casos de uso, etiquetado con el nombre del sistema. La caja representa el limite del sistema. Puede ser útil cuando se modelan sistemas complejos con muchos subsistemas.
  • 26. UML: Utilización de los casos de uso
    • Para la captura de requisitos
    • Los casos de uso pueden ayudar con la captura de requisitos, proporcionando una forma estructurada de abordarlos:
      • Identificar los actores.
      • Para cada actor averiguar:
          • Lo que necesita del sistema , es decir, qué casos de uso hay que tienen valor para ellos.
          • Cualquier otra interacción que espera tener con el sistema, esto es, en qué casos de uso podría formar parte para el beneficio de otro.
  • 27. UML: Utilización de los casos de uso
    • Casos de uso a través del desarrollo
    • Planificación : antes de realizar una estimación coherente y planificar el proceso para todo el proyecto, se necesita tener una lista con todos los caso de uso del sistema, junto con:
      • Una buena idea de lo que significa cada caso de uso.
      • Un entendimiento de quien quiere cada uno y cuanto.
      • El conocimiento de que casos de uso tienen mas riesgos.
      • Un plan de cuanto llevaría implementar cada caso de uso.
    Un aspecto básico es que no se debería planificar la entrega del sistema en una suma de tiempo inferior a la suma de los tiempos para el desarrollo de cada caso de uso.
  • 28. UML: Utilización de los casos de uso Casos de uso a través del desarrollo Aspectos políticos: entregar primero los casos de uso más prioritarios, para mostrar que el sistema genera aportes. Aspectos Técnicos: entra en conflicto con los anteriores, hay que implementar primero los casos de uso más riesgosos, para abordar los riesgos cuando sea posible. Validación del sistema: Cada caso de uso describe un requisito del sistema por lo que un diseño correcto permite que se ejecuta cada caso de uso: es decir realizar cada caso de uso. Una técnica y obvia para validar el diseño de un sistema es tomar de uno en uno los casos de uso y comprobar que el sistema permite ejecutar dicho caso de uso.
  • 29. UML: Ejercicios Realice los siguientes ejercicios para practicar los conceptos aprendidos. Ejercicios
  • 30. UML: Relación entre casos de uso Casos de Uso para la reutilización El caso más vital es cuando se puede sacar factor común del comportamiento de dos o más casos de uso originales. También cuando se descubre que se puede implementar parte de uno de los casos de uso utilizando un componente. Ejemplo: Tomar prestada copia y ampliar préstamo. Actor Ampliar Préstamo Tomar Prestada Copia de libro Comprobar para Reserva <<include>> <<include>>
  • 31. UML: Relación entre casos de uso Casos de Uso para la reutilización Destacar que la flecha va desde el caso de uso <<usuario>> hacia el caso de uso <<usado>>, y se etiqueta con <<include>>, para representar que el caso de uso origen incluye el caso de uso destino Actor Ampliar Préstamo Tomar Prestada Copia de libro Comprobar para Reserva <<include>> <<include>>
  • 32. UML: Relación entre casos de uso Casos de Uso para la reutilización El caso de uso origen depende del caso de uso destino, pero el caso de uso destino no depende del caso de uso origen. Cuando una instancia del caso de uso <<llega al lugar>> donde el comportamiento de otro caso de uso debe ser incluido, ejecuta todo el comportamiento descrito por el caso de uso incluido y luego continua de acuerdo a su caso de uso original.
  • 33. UML: Relación entre casos de uso
    • Casos de Uso para la reutilización
    • Ventajas:
      • Es una manera conveniente de almacenar la decisión de que se va a utilizar un componente, o de evitar almacenar la información en más de una descripción detallada del caso de uso.
      • Sacar factores de partes de la descripción del caso de uso, puede hacer que las descripciones de los casos de uso sean más cortas y fáciles de comprender.
      • Puede ser una manera de descubrir una posible reutilización de un componente.
  • 34. UML: Relación entre casos de uso
    • Casos de Uso para la reutilización
    • Desventajas:
      • Hay un serio riesgo de que la búsqueda de la reutilización en el modelo de caso de uso orientados a la funcionalidad, se vuelva atrás hacia un estilo de diseño de descomposición funcional de arriba hacia abajo.
      • La incorporación de un caso de uso <<include>> es difícil de leer por alguien que no esta acostumbrado a UML.
  • 35. UML: Relación entre casos de uso
    • Casos de Uso para la reutilización
    • Resumen: Considere la utilización de <<include>> entre casos de uso:
      • Para mostrar cómo el sistema puede utilizar un componente que ya existe.
      • Para mostrar la funcionalidad común entre casos de uso.
      • Para documentar el hecho de que el proyecto ha desarrollado un nuevo componente reutilizable.
  • 36. UML: Relación entre casos de uso Separación del comportamiento variable <<extend>> Si un caso de uso incorpora dos o más escenarios con diferencias significativas, esto es, se podría mostrar como un caso de uso principal y uno o más casos secundarios. Cuando se realiza esto es un problema de juicio, ya que siempre se pueden mostrar casos variables en un caso de uso. Ejemplo: Tomar prestada copia de libro. Actor Tomar Prestada Copia de libro Rechazar Préstamo <<extend>>
  • 37. UML: Relación entre casos de uso Separación del comportamiento variable <<extend>> Se utiliza la flecha <<extends>> desde el caso de uso menos central al central. La flecha va desde el caso excepcional al caso normal. La precondición debe hacer referencia al caso de uso extendido Actor Tomar Prestada Copia de libro Rechazar Préstamo <<extends>>
  • 38. UML: Relación entre casos de uso Generalización (herencia) Dos actores, o dos casos de uso, pueden estar relacionados por medio de la generalización. Ejemplo: generalización actores PrestatarioLibro PrestatarioRevistas
  • 39. UML: Relación entre casos de uso Generalización (herencia) Cuando los casos de uso están relacionados a través de una generalización la idea es mostrar una tarea y una versión especializada de la misma. Pagar en Efectivo Pagar con Cheque Pagar
  • 40. UML: Relación entre casos de uso Una regla básica es que si se quiere describir comportamiento extra posiblemente se requiera <<extends>>, mientras que si lo que se quiere es una etiqueta para una versión especializada de una tarea completa, probablemente se quiera generalización.
  • 41. UML: Pasos para la especificación de los casos de uso
    • Identificar las funciones del sistema, identifique los actores y casos de uso.
    • Describa todos los casos de uso de alto nivel.
    • Dibuje un diagrama de caso de uso.
    • Escriba el formato esencial expandido de los casos de uso más importantes para lograr una mayor comprensión de la complejidad y las dimensiones del problema, posponga los demás para la etapa de análisis.
    • Posponga, la descripción de los casos de usos reales hasta la fase de diseño.
  • 42. UML: ¿Por qué casos de Uso? “ Ofrecen un medio sistemático e intuitivo para capturar los requisitos funcionales, centrándose en el valor añadido para el usuario”. Dirigen todo el proceso de desarrollo puesto que la mayoría de las actividades (planificación, análisis, diseño, validación, test, ..) se realizan a partir de los casos de uso. Mecanismo importante para soportar “trazabilidad” entre modelos.
  • 43. UML: Recomendaciones ERROR COMÚN: no identificar como casos de uso las tareas que lanza el propio sistema. “ Anular reservas pasadas quince días” No incluir casos de uso de las operaciones CRUD sobre un objeto de negocios (consultas, borrado, actualización, registros): excepto si se trata de operaciones relevantes para el sistema, como “registrar clientes” en un sistema de ventas por Internet. Cuidado con el empleo de la relación <<include>> NO HACER UNA DESCOMPOSICIÓN FUNCIONAL!!!
  • 44. UML: Recomendaciones Escribir casos de uso independientes de la interfaz o de detalles de implementación, escribirlos a nivel esencial. Hay que comprobar que los casos de uso incluyen toda la funcionalidad del sistema. Los casos de uso sólo consideran los requisitos funcionales del proyecto, hay que añadir los no funcionales.
  • 45. Bibliografía
    • Guía del Tópico:
    • Software Engineering 6a. ed.– Ian Sommerville – Pearson Education – 2000. (Cap. 6)
    • Ingeniería de Software Teoría y Práctica – Shari Lawrence Pfleeger – Pearson Education – 2002.
    • Utilización de UML en ingeniería del software con objetos y componentes – Perdita Stevens & Rob Pooley – Addison Wesley – 2002.
    • UML y Patrones una introducción al análisis y diseño orientados a objeto y al proceso unificado – Craig Larman – Prentice Hall - 2002.