Diagrama de casos de uso

Transcripción

1 Diagrama de casos de uso Se utiliza para capturar los requerimientos funcionales de un sistema, de tal forma que plasman las relaciones entre los usuarios y el sistema. Contenido Pasos de construcción de un diagrama de casos de uso... 2 el contexto del sistema... 2 actores potenciales... 2 casos de uso... 3 Elementos del diagrama de casos de uso... 3 Ejemplo de diagrama de casos de uso... 4 Detalle de casos de uso... 4

2 Pasos de construcción de un diagrama de casos de uso el contexto del proceso actores potenciales casos de uso el contexto del proceso Es necesario conocer las actividades, detalles y circunstancias que delimitan la frontera del proceso a modelar. Se consideran los siguientes elementos. Fuentes de información Personas dentro del proceso. Desarrolladores de sistemas similares. Clientes. Técnicas de recolección Encuestas Entrevistas Observación directa. Participación dentro del proceso. Brain storming, bluesky, user stories. actores potenciales Los actores son los roles que se encuentran dentro del interés del proceso, es decir que tienen alguna relación con las actividades a modelar. Se utiliza la información obtenida al identificar el contexto del proceso, usualmente se cuestiona: Qué o quién usará el sistema Quién obtiene u ofrece información Qué roles interactúan dentro del proceso 2 P á g i n a

3 casos de uso Un caso de uso es la descripción de un conjunto de acciones, incluyendo variaciones, que un sistema realiza para obtener u ofrecer un producto a un actor. Se utiliza la información obtenida al identificar el contexto del proceso, usualmente se reflexiona: Cómo es la forma u acción que un actor realiza. Qué funciones necesita o necesitará cada actor. Si el proceso o sistema almacena o recupera información. Qué actor dispara cierto comportamiento. Elementos del diagrama de casos de uso Los diagramas de casos de uso requieren de ciertos elementos gráficos, estos elementos se obtienen de los pasos de construcción. Paso Elemento Descripción Diseño contexto del sistema Frontera del sistema Delimita los elementos que se consideran internos y los elementos externos que interactúan con el sistema. actores potenciales Actor Representa un rol que interactúa con el sistema; no se debe de relacionar con una persona o puesto. actores potenciales Relaciones Dentro de los roles pueden declararse relaciones de extensibilidad. casos de uso casos de uso Casos de uso Relaciones Indica las acciones que se realizan dentro del sistema. Los casos de uso se pueden relacionar con asociaciones y dependencias. 3 P á g i n a

4 Ejemplo de diagrama de casos de uso Podemos considerar el siguiente escenario: El cliente (customer) revisa el catalogo y agrega los productos deseados al carrito de compras (shopping basket); cuando el cliente desea pagar, describe la información de envío y de tarjeta de crédito al vendedor y confirma la compra. En el proceso se revisa la autorización de la tarjeta de crédito y confirma la venta. Banco Sin embargo, tenemos que considerar algunos escenarios alternativos: Alternativas Autorización de crédito fallida Cliente frecuente, ya se tiene su información En esta situación el diagrama de casos de uso no puede representar estas alternativas, ya que no controla el flujo de información. Para poder representar las alternativas, es necesario indicarlos en el detalle los casos de uso. Detalle de casos de uso Para detallar los casos de uso podemos utilizar dos herramientas: la especificación textual y el diagrama de actividad 1. La especificación textual de los casos de uso consiste en escribir de forma clara los pasos que se realizan en la actividad. No existe algún estándar o formato para realizar ésta actividad, sin embargo la siguiente plantilla es ampliamente usada. Caso de uso: Nombre Id: Clave para identificar el caso de uso Actor principal: Actor que desencadena la acción. Actores: Actores relacionados en la actividad Estado, características o limitantes del sistema Pre condiciones: antes de iniciar el caso de uso. Flujo de eventos Los pasos claros que se tienen que realizar en el caso de uso; deben estar numerados. Post condiciones: El estado del sistema al momento de terminar el caso de uso. Si detallamos algunos casos de uso de nuestro ejemplo, podrían quedar así: 1 Serán revisados posteriormente. 4 P á g i n a

5 Caso de uso: Describir información crediticia Id: CU1 Actor principal: Cliente Cliente Actores: Vendedor El cliente ha agregado productos al carrito de Pre condiciones: compras y ha decidido pagar. Flujo de eventos 1. El cliente decide pagar los productos de su carrito de compras. 2. El vendedor le solicita los datos crediticios: tipo de tarjeta, número de tarjeta, nombre del titular, fecha de vencimiento, código de seguridad. 3. El cliente entrega la información solicitada El cliente puede cancelar la compra. 4. El vendedor confirma los datos con el cliente. 5. Fin Post condiciones: Se ha cancelado la compra. El vendedor tiene los datos crediticios del cliente y ha confirmado que sean tal como los indicó el cliente. Para remarcar los casos alternos, nosotros podemos detallar el siguiente caso de uso. Caso de uso: Verificar datos crediticios Id: CU2 Actor principal: Vendedor Cliente Actores: Vendedor Banco El vendedor tiene los datos crediticios del cliente y Pre condiciones: ha verificado que sean correctos. Flujo de eventos 1. El vendedor contacta al banco para confirmar los datos crediticios del cliente. 2. El banco confirma los datos crediticios del cliente Si el banco no confirma los datos crediticios del cliente Vendedor indica al cliente que existe un error en sus datos Pasamos a CU Fin. 3. El vendedor indica al cliente que sus datos crediticios son correctos. 4. Fin. Post condiciones: El banco ha confirmado los datos crediticios del cliente, ya es posible realizar transacciones de cobro. 5 P á g i n a

6 Es posible que al detallar un caso de uso se descubra que existen fallas en la detección de actores o casos de uso; esto no es ningún problema, recuerde que estamos en un proceso de iterativo para modelar un proceso. Modelado de requerimientos del sistema Un requerimiento es una característica de diseño, propiedad o acción que debe realizar el sistema. Nosotros contamos con los siguientes tipos de requerimientos: Funcionales Son declaraciones de los servicios que debe de ofrecer el sistema. Son declaraciones de lo que el sistema no debería de realizar. No funcionales Son restricciones de los servicios ofrecidos por el sistema. Restricciones de tiempo, proceso de desarrollo o estandares. Los requerimientos del sistema se pueden escribir o representar de varias formas; nosotros podemos hacer una lista de los requerimientos o utilizar un diagrama de casos de uso modificado. Dentro del listado o del diagrama es posible indicar requerimientos que sean desconocidos u ocultos al usuario, pero que sean de gran importancia para el funcionamiento namiento del sistema. Lista de requerimientos En la lista de requerimientos se enuncian las acciones que el sistema deberá realizar, permitir o ejecutar; debe seguir el siguiente formato: 1. El sistema nombre,, deberá de permitir el ingreso autentificado al sistema. 2. El sistema nombre,, deberá ser capaz de indicar el momento en el que el usuario se encuentre inactivo por un periodo de 10 minutos. 3. El sistema nombre,, deberá realizar reportes de frecuencia de errores. Al momento de terminar un modulo, incremento o finalizar el sistema, la lista nos servirá como una lista de verificación para determinar el grado de cumplimiento de nuestro sistema con el problema planteado. 6 P á g i n a

7 Diagrama de casos de uso Nosotros podemos utilizar el diagrama de casos de uso para indicar los requerimientos del sistema; aunque no se indiquen las relaciones se pueden determinar los actores y servicios que se deberán ofrecer. [nota de versión 1.0 Se debe cambiar imagen] 7 P á g i n a

8 Bibliografía Arlow, J., & Neustadt, I. (2002). UML and the unified process: Practical Object Oriented Analisis & Design. Great Britain: Addison Wesley. Booch, G., Rumbaugh, J., & Jacobson, I. (2005). The unified modeling language user guide. USA: Addison wesley. Fowler, M. (2003). UML distilled: A brief guide to the standard object modeling language. USA: Addison wesley. Grässle, P., Baumann, H., & Baumann, P. (2005). UML 2.0 in action: A project based tutorial. Great Britain: Packt Publishing. Sommerville, I. (2005). Ingeniería de software. Madrid: Pearson educación. 8 P á g i n a