Scribd Logo
Cargar

¡Te damos la bienvenida a Scribd!

  • 8 vistas

    Uml: Casos de Uso Y Diagrama de Casos de Uso: Fundamentos de Ingeniería de Software

    Cargado por

    Hyemir Genderson

    Copyright:

    © All Rights Reserved
    Descargue como PPT, PDF, TXT o lea en línea desde Scribd

    Uml: Casos de Uso Y Diagrama de Casos de Uso: Fundamentos de Ingeniería de Software

    Cargado por

    Hyemir Genderson
    8 vistas31 páginas

    Título original

    4767212

    Derechos de autor

    © © All Rights Reserved

    Formatos disponibles

    PPT, PDF, TXT o lea en línea desde Scribd

    ¿Le pareció útil este documento?

    ¿Este contenido es inapropiado?

    Copyright:

    © All Rights Reserved
    Descargue como PPT, PDF, TXT o lea en línea desde Scribd
    Descargar como ppt, pdf o txt
    8 vistas31 páginas

    Uml: Casos de Uso Y Diagrama de Casos de Uso: Fundamentos de Ingeniería de Software

    Cargado por

    Hyemir Genderson

    Copyright:

    © All Rights Reserved
    Descargue como PPT, PDF, TXT o lea en línea desde Scribd
    Descargar como ppt, pdf o txt
    Está en la página 1de 31

    FUNDAMENTOS DE INGENIERÍA DE SOFTWARE

    UML: CASOS DE USO Y DIAGRAMA


    DE CASOS DE USO
    Docente:
    Norka Pareles
    UML
    Unified Modeling Language

     Lenguaje Estándar para:


    – Visualizar
    – Especificar
    – Construir
    – Documentar los planos del software

    Indican como crear y leer modelos bien formados pero no nos dicen
    qué modelos se deben crear ni cuándo se los deberían crear

    Ir a Casos de uso
    UML es un lenguaje para visualizar

    • La distancia entre pensar en una implementación y transformarla en código es casi


    cero.
    • En algunos casos: Lo que piensas lo codificas.

    • Algunas cosas se modelan mejor textualmente; otras se modelas mejor de forma


    gráfica

    • UML es algo más que un simple montón de símbolos gráficos.


    UML es un lenguaje para especificar
    • Significa construir modelos precisos, no ambiguos y completos

    • UML cubre todas las decisiones de análisis, diseño e implementación

    UML es un lenguaje para construir


    • No es un lenguaje de programación

    • Pero sus modelos pueden conectarse a una gran variedad de lenguajes de


    programación
    UML es un lenguaje para documentar

    • UML cubre la documentación de la arquitectura de un sistema y todos sus detalles

    • Proporciona un lenguaje:

     Expresar requisitos y pruebas

     Modelar actividades de planificación de proyectos y gestión


    de versiones
    CASOS DE USO

    Qué es un caso de uso?


    Para que sirven los casos de uso?
    Cómo se representan?
    Cómo se debe crear un caso de uso?
    Flujo de eventos
    Model
    Relaciones
    Diagramas de caso de uso
    Use case 1

    Actor 2
    Use case 2

    Use case 3
    Use Case 2
    Specification
    QUÉ ES UN CASO DE USO?

     Describen una interacción típica entre un usuario (actores) y un sistema de


    cómputo.

     Es una técnica para capturar información de cómo un sistema o negocio trabaja


    actualmente, o de cómo se desea que trabaje

     Produce algo de valor para algún actor como el cálculo de algún resultado

     Describe qué hace un sistema pero no especifica cómo lo hace

     El caso de uso capta alguna función visible para el usuario.


     El caso de uso puede ser pequeño o grande.
     El caso de uso logra un objetivo discreto para el usuario.

     Un caso de uso debe ser simple, claro y conciso


    PARA QUE SIRVEN LOS CASOS DE USO?

     Para capturar el comportamiento deseado del sistema sin tener que


    especificar como se implementa ese comportamiento

     Como medio de comprensión del sistema para desarrolladores,


    usuarios finales y expertos del dominio

     Ayudan a validar la arquitectura y a verificar el sistema en el


    transcurso del desarrollo de este
    CÓMO SE REPRESENTAN?
    Un caso de uso se representa en UML como un óvalo:

    Nombre del Caso de Uso

    En UML, un actor se representa como monigote

    Actor
    ACTORES

     Representa un conjunto de roles que los usuarios de los casos de uso juegan al
    interactuar con éstos

     Representa un rol que es jugado por una persona, un dispositivo hardware u otro
    sistema que interactúe con nuestro sistema

     Se puede definir categorías generales de actores (como cliente) y especializarlos


    (como ClienteComercial) a través de relaciones de generalización
    actor

    Cliente

    generalización

    Cliente actor
    Comercial
     Un actor y un caso de uso se pueden comunicar a través de una asociación en
    donde cada uno de ellos pueden enviar y recibir mensaje.
    FLUJO DE EVENTOS

     Cómo y cuándo empieza y acaba el caso de uso

     Cuándo interactúan con los actores y que objetos se intercambian

     Conviene separa el flujo principal de uno alternativo


    Ejemplo:

    VALIDACIÓN DE USUARIO
    FLUJO DE EVENTO PRINCIPAL:

    el caso de uso comienza cuando se pide al cliente un número de identificación


    personal (cédula), el cliente introduce la cédula, luego acepta con enter, el sistema lo
    comprueba para su validación, si la cédula es válida el sistema acepta la entrada y
    acaba el caso de uso.

    FLUJO DE EVENTO EXCEPCIONAL:

    - El cliente puede cancelar su transacción en cualquier momento con el botón


    cancelar, reiniciando el caso de uso, no se efectúa ningún cambio a la cuenta del
    cliente .
    - El cliente puede borrar la cédula en cualquier momento antes de introducirlo y
    volver a teclear una nueva cédula
    - El cliente introduce un cédula inválida el caso de uso vuelve a empezar, si se lo
    realiza tres veces se cancela la transacción.
    Cómo identificar los casos de uso?
    Cómo se debe crear un caso de uso?

     Tras localizar los actores, procede el describirlos


     especificar describiendo un flujo de eventos
     Los actores sólo pueden conectar a los casos de uso a través de
    asociaciones

     Generalmente hay pocos actores asociados a cada Caso de Uso


     Preguntas clave:
    – ¿cuáles son las tareas del actor?
    – ¿qué información crea, guarda, modifica, destruye o lee el actor?
    – ¿debe el actor notificar al sistema los cambios externos?
    – ¿debe el sistema informar al actor de los cambios internos?
     La descripción del Caso de Uso comprende:
    – el inicio: cuándo y qué actor lo produce?
    – el fin: cuándo se produce y qué valor devuelve?
    – la interacción actor-caso de uso: qué mensajes intercambian
    ambos?
    objetivo del caso de uso: ¿qué intenta el caso de uso?
    cronología y origen de las informaciones
    repeticiones de comportamiento: ¿qué operaciones son
    iteradas?
    situaciones opcionales: ¿qué ejecuciones alternativas se
    presentan en el caso de uso?
    Puntos claves del ejemplo:
     Las precondiciones son los hechos que se han de cumplir para que el flujo de
    evento se pueda llevar a cabo.
     Flujo de eventos Normal, que corresponde a la ejecución normal y exitosa del caso
    de uso
     Los flujos alternativos son los que nos permiten indicar qué es lo que hace el
    sistema en los casos menos frecuentes e inesperados.
     las poscondiciones son los hechos que se ha de cumplir si el flujo de eventos
    normal se ha ejecutado correctamente.
    Ejemplo: escribir un mensaje en un foro
    RELACIONES

    Para extraer el comportamiento de los casos de uso en los que se incluye y poniendo ese
    comportamiento en otros casos de uso que lo extiende

    Tipos:
    - GENERALIZACIÓN
    - EXTENSIÓN
    - INCLUSIÓN
    GENERALIZACIÓN

     El caso hijo hereda el comportamiento y significado de caso de uso


    padre
     El hijo puede añadir o redefinir el comportamiento del padre
     El Caso de Uso fuente hereda la especificación del Caso de Uso
    destino

    Caso de uso destino

    Caso de uso origen


    INCLUSIÓN

    – Un caso base de uso base incorpora expolisitamente el


    comportamiento de otro caso de uso en el lugar especificado en el
    caso base.
    – Se usa para evitar describir el mismo flujo de eventos repetidas
    veces, poniendo comportamiento común en un caso de uso aparte
    – Se representa como una dependencia estereotipada con
    <<include>>
    <<include>>

    Caso de uso destino


    REPRESENTACIÓN:

    Caso de uso origen

    EJEMPLO:
    Buscando datos de
    producto

    <<include>>
    <<include>>

    Ingresando pedido Obtener reporte


    De Ventas por
    producto
    Empleado de Gerente
    ventas
    EXTENSIÓN

     Significa que un caso de uso base incorpora implícitamente el comportamiento de otro caso
    de uso en el lugar especificado indirectamente por el caso de uso que extiende al base
     Se usa esta relación cuando se tiene un caso de uso que es similar a otro, pero que hace
    un poco más.

    <<extends>>

    Caso de uso
    destino
    Caso de uso
    origen
    Ejemplo:

    Realizar <<extend>> Realizar llamada


    Llamada telefónica Con conferencia

    Red relación de extensión


    telefónica
    <<extend>>
    Recibir llamada Recibir llamada
    Actores
    telefónica adicional

    Casos de uso

    Usar agenda
    frontera del sistema
    Usuario

    Teléfono móvil
     Ejemplo de todas las relaciones :

    <<extends>>
    Giro por Internet

    Cliente

    <<includes>>
    Giro

    Identificación
    DIAGRAMAS DE CASO DE USO

    En UML, cada caso de uso debe tener al menos un actor. Esta forma de ver el
    sistema nos ayuda a concebirlo como un todo.

     Un diagrama de casos de uso es un diagrama que muestra un conjunto de


    casos de uso, actores y sus relaciones.
     Son importantes para modelar el comportamiento de un sistema.
     Normalmente los casos de uso contienen:

    – Casos de Uso
    – Actores
    – Relaciones de dependencia, generalización y asociación.
    DIAGRAMAS DE CASO DE USO

     Cubren principalmente el comportamiento del sistema.

     Es un tipo especial de diagrama, por su contenido particular.

     Se emplean para modelar la vista de casos de uso estática.(comportamiento, servicios


    externos).

     Para modelar el contenido de un sistema

     Dibujar una línea alrededor de todo el sistema, los actores quedarán fuera del sistema e
    interactúan con el, se especificara los actores y el significado de los roles.

     Para modelar los requisitos de un sistema

     Especificar que debería hacer el sistema, independientemente de cómo se haga, se especificará


    el comportamiento deseado del sistema.

     Permite ver el sistema entero como una caja negra.


    Técnicas comunes del modelado

     Elementos dentro y fuera, son responsables del comportamiento que esperan los elementos
    externos..
     Los elementos externos que interactúan con el sistema constituyen su contexto, es decir el
    entorno en que reside el sistema.
     Modelar el contexto de un sistema
    – Identificar actores en torno del sistema.
    – Grupos que necesitan ayuda del sistema,
    – Grupos necesarios para ejecutar las funciones del sistema.
    – Grupos que interactúan con el hardware o software.
    – Grupos que realizan funciones secundarias de administración y mantenimiento.
     Organizar los actores similares en jerarquía de generalización/especificación
     Proporcionar un estereotipo para cada actor.
     Introducir los actores en un diagrama de CU y especificar las vías de comunicación .
    Antes Después
    Ejemplo de: DIAGRAMAS DE CASO DE USO

    Realizar
    Transacción
    Con tarjeta

    Comercio
    Procesar factura
    Del cliente

    Cliente
    Ajustar
    transacciones

    Gestionar cuenta
    Del cliente
    Cliente Cliente Entidad
    individual corporativo Financiera
    1. http://www.ingenierosoftware.com/analisisydiseno/casosdeuso.php
    2. http://www-gris.det.uvigo.es/~avilas/UML/node25.html
    3. Libro de UML: EL LENGUAJE UNIFICADO DE MODELADO, Booch,
    Jacobson, Rumdaugh, pag 190- 223

    También podría gustarte