• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Diagrama de casos de uso
 

Diagrama de casos de uso

on

  • 4,171 views

Diagrama de casos de uso UML

Diagrama de casos de uso UML

Statistics

Views

Total Views
4,171
Views on SlideShare
4,142
Embed Views
29

Actions

Likes
2
Downloads
124
Comments
0

2 Embeds 29

http://cursos.unipanamericana.edu.co 15
http://danisantiago.com 14

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Diagrama de casos de uso Diagrama de casos de uso Document Transcript

    • UML – Diagrama de casos de usoDaniel Santiago Diagrama de casos de uso Introducción 2 Casos de uso 2 Actor 2 Escenario 2 Relación de comunicación 3 Diagrama de casos de uso 3 Relaciones entre los casos de uso: relación de inclusión 4 Relaciones entre los casos de uso: relación de extensión 4 Especialización y generalización de los casos de uso 5 Representación textual de los casos de uso 5 1
    • UML – Diagrama de casos de usoDaniel SantiagoIntroducciónLos casos de uso se usan para describir los requisitos funcionales del sistema que se deseadiseñar.En los diagramas de casos de uso se muestran los requisitos funcionales deseados, los actores(usuarios del sistema) y las relaciones que unen a actores y funcionalidades.Casos de usoLos casos de uso describen en forma de acciones y reacciones el comportamiento del sistema,estudiado desde el punto de vista del usuario. Definen los límites del sistema y sus relacionescon el entorno.Los casos de uso explicitan los requisitos funcionales del sistema relativos a uno de losobjetivos del usuario. Éstos se denominan también, de manera más precisa, casos de uso conobjetivo usuario.Por ejemplo, en un sistema que gestione las mercancías de una tienda, la compra de unproducto constituye un caso de uso.ActorUn usuario externo al sistema puede desempeñar diferentes funciones en relación con elsistema. Una pareja (usuario, función) constituye un actor específico designado en UMLúnicamente por el nombre de la función.La definición se extiende a los demás sistemas que interactúan con el sistema. Éstos formantantos actores como funciones desempeñadas.Se diferencian dos categorías de actores: Los actores primarios son los que inician el caso de uso. Los actores secundarios son los que participan en el caso de uso.Por ejemplo, en el ejemplo de una tienda informática, el actor primario es el comprador, y unactor secundario podría ser un sistema que reconoce la validez de la tarjeta de crédito delcomprador.EscenarioUn escenario es una instancia de un caso de uso en la cual se fijan todas las condicionesrelativas a los diferentes eventos.A un caso de uso determinado corresponden varios escenarios.Ejemplos de diferentes escenarios para el caso de uso “Llevarse libro” de una biblioteca serían: Escenario 1: Pedro se lleva el ejemplar “Los pilares de la tierra”. 2
    • UML – Diagrama de casos de usoDaniel Santiago Escenario 2: María intenta llevarse el ejemplar “Drácula” pero no puede ya que ha superado el límite de 3 préstamos simultáneos.Relación de comunicaciónLa relación que vincula a un actor con un caso de uso se denomina relación de comunicación.Esta relación da soporte a diferentes modelos de comunicación, por ejemplo: Los servicios que el sistema debe suministrar a cada uno de los actores del caso de uso. Las informaciones del sistema que un actor puede introducir, consultar o modificar. Los cambios que intervienen en el entorno, de los cuales un actor informa al sistema. Los cambios que intervienen dentro del sistema, de los cuales el sistema informa a un actor.Diagrama de casos de usoEl diagrama de casos de uso muestra los casos de uso representados en forma de elipses y alos actores en forma de personajes. También indica las relaciones de comunicación que losvincula.El sistema que responde al caso de uso puede representarse mediante un rectángulo en cuyointerior aparece el caso.Ejemplo:Los actores secundarios se representan del mismo modo que los actores primarios. Muchasveces el sentido de la relación de comunicación entre los actores secundarios y el sistema seinvierte con respecto al sentido de la relación entre los actores primarios y el sistema. Enefecto, es el sistema y no el actor quien inicia la comunicación. 3
    • UML – Diagrama de casos de usoDaniel SantiagoRelaciones entre los casos de uso: relación de inclusiónLa relación de inclusión sirve para enriquecer un caso de uso con otro. El caso de uso incluidoexiste únicamente con ese propósito, ya que no responde a un objetivo de un actor primario.Estos casos de uso son subfunciones.La inclusión sirve para compartir una funcionalidad común entre varios casos de uso. Tambiénpuede emplearse para estructurar un caso de uso describiendo sus subfunciones.En el diagrama de casos de uso estas relaciones se representan mediante una flechadiscontinua acompañada del estereotipo <<include>>.Varios casos de uso pueden tener una relación de inclusión con un caso de uso en común, yaque varios casos de uso pueden tener una misma subfunción.Relaciones entre los casos de uso: relación de extensiónAl igual que la relación de inclusión, la relación de extensión enriquece un caso de usomediante un caso de uso subfunción. El enriquecimiento es análogo al de la relación deinclusión, no obstante, es opcional. 4
    • UML – Diagrama de casos de usoDaniel SantiagoComo ocurre con la inclusión, la extensión sirve para estructurar un caso de uso o paracompartir un caso de uso de subfunción.En el diagrama de casos de uso, esta relación se representa mediante una flecha discontinuaacompañada del estereotipo <<extend>>.Especialización y generalización de los casos de usoComo vimos en el diagrama de clases, también es posible especializar un caso de uso en otro.Obtenemos así un subcaso de uso.Al igual que ocurría con las clases, el subcaso hereda el comportamiento y las relaciones decomunicación, inclusión y extensión del supercaso de uso.Muchas veces el supercaso de uso es abstracto, es decir, corresponde a un comportamientoparcial completado en el subcaso de uso.En el diagrama de casos de uso la relación de especialización se representa mediante unaflecha de especialización idéntica a la que une las subclases con las superclases. El nombre delos casos de uso abstractos se escribe en cursiva, o se acompaña del estereotipo <<abstract>>.Los subcasos de uso tienen el mismo nivel que sus supercasos. Si el supercaso es unasubfunción, el subcaso también lo será. 5
    • UML – Diagrama de casos de usoDaniel SantiagoTambién puede existir especialización en los actores del sistema.Representación textual de los casos de usoLa representación textual de los casos de uso no se especifica en UML, no obstante se utilizahabitualmente. Es una especificación en la que se usa el lenguaje natural del autor. Hay dostipos de especificaciones: la de alto nivel y la expandida. 6
    • UML – Diagrama de casos de usoDaniel SantiagoRepresentación de alto nivelSe trata de realizar una descripción breve de las acciones del caso de uso. Esta representacióntiene las siguientes partes: Caso de uso: nombre del caso de uso. Actores: lista de actores, iniciador. Propósito: objetivo del caso de uso. Resumen: Descripción breve de las actividades que se deben llevar a cabo. Tipo: 1 – Primario, secundario, opcional 2 – Real o esencial.Los tipos de caso de uso son los siguientes: Primario: estos casos de uso representan los procesos comunes más importantes. Secundario: representan procesos menores o raros. Opcionales: representan procesos que pueden no abordarse. Real: describe concretamente el proceso a partir de su diseño concreto actual, sujeto a las tecnologías específicas de entrada, salida, etc. Esencial: son casos expandidos que se expresan en forma teórica y que contiene poca tecnología y pocos detalles de implementación. Las decisiones de diseño se posponen y se abstraen de la realidad. Los casos de alto nivel siempre son de carácter esencial, debido a su brevedad y abstracción.Representación expandidaSe trata de realizar una descripción detallada de las acciones y los requisitos. Añade a laespecificación de alto nivel las siguientes partes: Referencias cruzadas: requisitos a los que hace referencia. Curso típico de acontecimientos: descripción detallada de la interacción (conversación) entre los actores y el sistema. Descripción de los acontecimientos paso a paso. Cursos alternativos: describe excepciones al curso típico.Ejemplo representación caso de usoEn este ejemplo vamos a especificar el software de un terminal de punto de venta (TPV). Es unsistema usado para registrar las ventas y gestionar pagos en supermercados y grandesalmacenes.Las funciones básicas del TPV serán las siguientes:REF # FunciónR1.1 Registrar la venta actual – los productos comprados.R1.2 Calcular el total de la venta actual, incluyendo impuestos y cálculo de “puntos de cliente”R1.3 Capturar la información de los productos comprados de un código de barras, usando un scanner o bien a partir de la entrada manual del código de barras.R1.4 Descontar las cantidades vendidas del stock, cuando la venta de confirme. 7
    • UML – Diagrama de casos de usoDaniel SantiagoR1.5 Guardar información sobre las ventas realizadas.R1.6 El cajero debe identificarse al iniciar una sesión con un identificador y una clave de acceso.R1.7 Mostrar la descripción y el precio de cada producto comprado.R2.1 Tratar los pagos de efectivo capturando la cantidad entregada por el cliente y calculando el cambio.R2.2 Tratar los pagos con tarjeta de crédito capturando el número de la tarjeta desde un lector de tarjetas o manualmente, pedir confirmación del pago al servicio de autorización de crédito (externo) con una conexión vía módem.R2.3 Registrar los pagos con tarjeta para que puedan ser facturados.Vamos a especificar el caso de uso “Comprar productos”: Caso de uso: Comprar productos Actores: Cliente (iniciador), Cajero Propósito: Capturar una venta y su pago en efectivo. El cajero registra los productos y gestiona el pago en efectivo. Al terminar, el cliente se va con los productos. Tipo: primario y esencial. Referencias cruzadas: R1.1, R1.2, R1.3, R1.7, R2.1 Curso típico de acontecimientos: Acciones de los actores Respuesta del sistema 8
    • UML – Diagrama de casos de usoDaniel Santiago 1. El caso de uso empieza cuando el cliente llega a la caja con sus productos para comprar. 2. El cajero indica el inicio de una nueva 3. Registro del inicio de una nueva venta venta. del TPV. 4. El cajero registra el identificador de cada 5. Determina el precio del producto y producto. Si hay más de una unidad del añade su información a la cuenta. producto el cajero puede introducir la cantidad. 6. Al terminar la entrada de productos el 7. Calcula y muestra el total de la cuenta. cajero lo indica. 8. El cajero le dice el total al cliente. 9. El cajero entrega una cantidad de dinero posiblemente más grande que el total de la cuenta. 10. El cajero indica el dinero que ha recibido. 11. Calcula y muestra el cambio al cliente. Imprime un recibo. 13. El cajero deposita el dinero recibido en la 12. Registra la venta que se acaba de caja y extrae el cambio. El cajero da el cambio hacer. y el recibo al cliente. 14. El cliente se va con los productos comprados. Cursos alternativos: Línea 4: se introduce un identificador de producto inexistente. Indicar error. Línea 9: el cliente no tiene suficiente dinero. Cancelar la venta. 9