El modelo de casos de uso. Ingeniería de la Programación

Transcripción

1 El modelo de casos de uso Ingeniería de la Programación Prácticas cas 1

2 Contenidos Introducción RF y RNF Introducción al modelo de RF de UML. Actores y Casos de Uso Modelo de casos de uso Diagrama de contexto y modelo inicial. Plantillas de especificación. Modelo estructurado. Relaciones entre actores y casos de uso Proceso de construcción del modelo de casos de uso Documento de Requisitos. 2

3 Objetivos Introducir los conceptos de requerimientos de usuario y del sistema. Describir los requisitos funcionales y los no funcionales. Explicar el modo de organizar los requerimientos en un documento de requerimientos. Qué tipo de requerimientos se incluyen en UML?. Tópicos descritos: Requerimientos funcionales y no funcionales. Requerimientos de usuario. Requerimientos del sistema. El documento de especificación de requisitos. 3

4 Introducción RF y RNF La ingeniería de requisitos describe el proceso de establecer los servicios que los clientes requieren de un sistema, las condiciones bajo las que funcionará o las condiciones que se aplican al proceso de desarrollo. Los requerimientos son las descripciones de los servicios del sistema, las condiciones de funcionamiento y las condiciones de desarrollo. 4

5 Introducción: qué es un requerimiento? e Puede ser tanto la descripción de alto nivel o muy detallada de un servicio, de una restricción del futuro sistema o del proceso de desarrollo. Los requerimientos tienen una función dual: Se pueden utilizar como base para solicitar ofertas de desarrollo; por tanto pueden estar sujetos a interpretación. Pueden ser la base del contrato de desarrollo; por tanto deben ser muy detallados. d 5

6 Tipos de requerimientos (usuario versus esussste sistema). Requerimientos de usuario Sentencias en lenguaje natural de los servicios que el sistema debe proporcionar junto a sus restricciones de operación. Escrito por clientes. Requerimientos del sistema. Un documento estructurado con una descripción detallada de la funcionalidad del sistema y de las restricciones de operación. Define qué debe ser implementado, de modo que puede ser parte de un contrato entre el cliente y el desarrollador. 6

7 Requerimientos funcionales y no funcionales (1) Requerimientos funcionales: Sentencias describiendo los servicios que el sistema debe proporcionar o cómo debe reaccionar frente a entradas proporcionadas. Dependiendo del caso también pueden describirse los tipos de usuarios del sistema. Ejemplo: Sistema de búsqueda de artículos científicos en BD. El usuario puede efectuar sus búsquedas en el conjunto inicial de bases de datos o bien seleccionar un subconjunto de las mismas. El sistema debe proporcionar un conjunto conveniente de visores de documentos para que los artículos puedan ser consultados en-línea. 7

8 Requerimientos funcionales y no funcionales (2) Requerimientos no funcionales (RNF): Los requerimientos no funcionales establecen cualidades o atributos que debe poseer el sistema. Expresan propiedades y restricciones sobre los servicios o funciones ofertadas por el sistema (como restricciones temporales), o sobre el proceso de desarrollo (estándares que deben cumplirse). Ejemplos de NFR: seguridad, usabilidad, fiabilidad. 8

9 Requerimientos funcionales y no funcionales (3) Algunas veces no hay una distinción clara entre RF y RNF ya que depende de la forma en la que se exprese el requerimiento. Ejemplo: El sistema debe garantizar que los datos se encuentran protegidos frente a accesos no autorizados. -> RNF. El sistema incluirá un procedimiento de autenticación donde d los usuarios proporcionaran un login y password. Únicamente los usuarios autenticados pueden acceder a los datos -> RF. 9

10 Clasificación de los requerimientos NFR Existen diversas taxonomías para clasificar los RNF. McCall & Matsumoto factores de calidad. ISO IEEE Std 830. VOLERE. D. Firesmith. I. Sommerville. 10

11 Clasificación de RNF Requerimientos del producto. Especifican que el producto deben comportarse de forma particular, por ej. velocidad de ejecución, fiabilidad, etc. Requerimientos de la organización. Requerimientos que son consecuencia de las políticas y procedimientos de la organización, por ej. estándares utilizados, requerimientos de implementación, etc. Requerimientos i externos. Requerimientos cuyo origen son factores externos al sistema y al proceso de desarrollo del mismo, por ej. requerimientos de interoperabilidad, legislación, etc. 11

12 Ejemplos: Requerimientos del proceso El proceso de desarrollo que va a utilizarse debe definirse de manera precisa y debe ser consistente con las normas ISO El sistema debe ser desarrollado y documentado utilizando la herramienta IBM-Telelogic Tau. Deben generarse informes cada 2 semanas indicando el avance en el desarrollo del sistema. 12

13 Ejemplos: Requerimientos externos La oficina de protección de datos debe certificar que todos los datos se almacenan y gestionan de acuerdo a la ley de protección de datos. El sistema no debe mostrar a los operadores del mismo ninguna información de los clientes, salvo el nombre y el número de cliente. 13

14 Introducción al modelo de RF de UML Introducidos por I. Jacobson en Objectory en Los casos de uso describen bajo la forma de acciones y reacciones el comportamiento de un sistema desde el punto de vista de los usuarios. Son descripciones de la funcionalidad del futuro sistema independientes de la implementación. Sirven para modelar los requisitos funcionales de un sistema software. 14

15 Introducción al modelo de RF de UML Por qué casos de uso? Fácilmente compresibles por clientesusuarios. Se utilizan como base para un desarrollo iterativo e incremental. Incorporados en la mayor parte de lo métodos de desarrollo OO de segunda generación. 15

16 Actores y Casos de Uso Los actores definen qué existe fuera del sistema Entorno del sistema Sistema Caso de uso Empleado Caso de uso Sistema Au torizaciones Caso de uso Comunicación Un actor puede ser una persona, un conjunto de personas, un sistema hardware, un sistema software o un reloj. 16

17 Actores Un actor representan un rol que puede desempeñar alguien o algo que necesita intercambiar información con el sistema. Cliente Bancario Una misma persona puede jugar varios roles al interactuar t con el sistema y un mismo rol puede corresponder con varias personas. 17

18 Casos de uso Un caso de uso describe una forma concreta de utilizar parte de la funcionalidad del sistema. La colección de todos los casos de uso describe toda la funcionalidad del sistema. Extracción de dinero del cajero Ingreso de dinero en el cajero Consulta de saldo 18

19 Caso de uso (definición) I. Jacobson propone p dos definiciones: Documento que describe una secuencia de eventos que realiza un actor (agente externo) que usa el sistema para llevar a cabo un proceso que tiene algún valor para el. Cada caso de uso está formado por una secuencia de eventos, iniciada por un actor, que describe la interacción que tiene lugar entre el actor y el sistema. 19

20 Caso de uso Características: Son iniciados por un actor (actor primario o principal). Pueden participar otros actores (secundarios) Poseen un nombre. Pueden contener condiciones de inicio (precondiciones) y condiciones de terminación (postcondiciones) La descripción del caso de uso contiene la secuencia de eventos (pasos del caso de uso). 20

21 Caso de uso (notación) La comunicación entre actores y casos de uso se muestra de la forma: Cliente Bancario Extracción de dinero del cajero 21

22 Modelo de casos de uso Notación gráfica con actores y casos de uso. Relaciones Entre actores: herencia. Entre actores y casos: asociación. Entre casos de uso: Usa, extiende (UML 1.3) Incluye, extiende, hereda de (UML 1.5) Incluye, extiende, hereda de (UML 2.0) Descripción: plantillas textuales para cada caso de uso. 22

23 Notación gráfica El modelo de casos de uso muestra gráficamente toda la funcionalidad del sistema. Alta Cliente extiende Buscar Cliente incluye Introducir Pedido extiende extiende Obtener Estado Pedido Pago en cuenta Pago con tarjeta Empleado incluye Buscar Pedido Cancelar Pedido incluye 23

24 Organización del modelo Estructurado en tres capas: Diagrama de contexto y modelo inicial. Representaciones gráficas. Plantillas de descripción. Representación textual. Modelo estructurado. Representación gráfica. 24

25 Diagrama de contexto. El diagrama de contexto muestra los límites del sistema y los actores (agentes externos) )que interactuarán con el mismo. Terminal Punto de Venta Empleado Cliente Proveedor Responsable de compras Director Comercial 25

26 Modelo inicial Contiene la agrupación jerárquica de los distintos casos de uso: Mediante paquetes UML (subsistemas). ste Biblioteca Préstamos Socios 26

27 Modelo inicial (2) O bien: Sistema de Pedidos Gestión Pedidos Gestión de Artículos Empleado Nuevo Pedido Cancelar Pedido Estado Pedido Nuevo Producto Borrar Producto Gestión de Clientes Administrador Borrar Pedido Buscar Pedidos Nuevo Cliente Buscar Cliente 27

28 Modelo inicial (3) Utilizando un árbol de descomposición funcional. Sistema de Pedidos Gestión Pedidos Gestión Artículos Gestión Clientes Nuevo Pedido Nuevo Producto Cancelar Pedido Borrar Producto Estado Pedido Borrar Pedido Buscar Pedidos 28

29 Plantillas de descripción Los casos de uso se describen utilizando plantillas en lenguaje natural. Habitualmente: Nombre del CU. Descripción. Actores (primario y secundarios) Precondiciones, Postcondiciones. Flujo de eventos. 29

30 Ejemplo TPV Para un terminal punto de venta: Un terminal punto de venta (TPV) es un sistema computerizado usado para registrar las ventas y gestionar pagos. Se usa en supermercados y en grandes almacenes. Incluye componentes hardware (como el ordenador y el escáner e del código de barras) as) y software para ejecutar el sistema. 30

31 Ejemplo TPV (2) Diagrama de contexto y modelo inicial Terminal Punto de Venta Iniciar Sesión Empleado Venta Productos Cliente Devolver productos Acabar Sesión Director Comercial Responsable de compras Compra proveedores Proveedor Hacer ofertas Fijar Precio 31

32 Ejemplo TPV (3) Variaciones sobre el ejercicio: Supermercado tradicional Iniciar Sesión Empleado Venta Productos Cliente Devolver productos Supermercado electrónico Venta Productos Devolver productos Cliente 32

33 Plantillas TPV Empleado Venta Productos Cliente Empleado Venta Productos Si únicamente se desea mostrar la interacción de los actores con el sistema informático. 33

34 Plantilla TPV Caso de uso Venta de Productos Actores Cliente (iniciador), Empleado Propósito Capturar una venta y su pago en efectivo Resumen Un cliente llega a la caja con productos para comprar. El empleado registra los productos y gestiona el pago en efectivo. Al acabar el cliente se va con los productos. Precondiciones El empleado se ha identificado en el sistema. Postcondiciones La venta se almacena en el sistema. Incluye - Extiende - Hereda de - 34

35 Plantilla TPV Intenciones de usuario Obligaciones del sistema 1. El caso de uso se inicia cuando un cliente llega a la caja con productos. 2. El empleado indica que 3. El sistema registra el comienza una nueva venta. inicio de una venta 4. Mientras queden artículos: El 5. El sistema determina el empleado introduce el código de precio del producto y añade cada producto y la cantidad la información a la cuenta. 6. El empleado indica el fin de la 7. El sistema calcula y venta muestra el total. 8. El empleado dice el total t al cliente. 9. El cliente entrega el importe 10. El empleado indica el dinero 11. El sistema calcula y que ha recibido muestra el cambio. Imprime un recibo y registra la venta. 12. El empleado deposita el dinero recibido en la caja, entrega el cambio y el recibo. 13. El cliente se va con los productos comprados../.. continua 35

36 Plantilla TPV Extensiones síncronas #1. Si en 4 se introduce un código de producto inexistente el sistema genera un mensaje de error. #2. Si en 9 el cliente no tiene dinero suficiente la venta se cancela. Extensiones asíncronas Ninguna Si únicamente se desea mostrar la interacción con el sistema informático, debe eliminarse la referencia al cliente dentro de la descripción anterior. 36

37 Plantilla TPV (caso de uso sistema) Caso de uso Venta de Productos Actores Empleado (iniciador) Propósito Capturar una venta y su pago en efectivo Resumen Un cliente llega a la caja con productos para comprar. El empleado registra los productos y gestiona el pago en efectivo. Al acabar el cliente se va con los productos. Precondiciones El empleado se ha identificado en el sistema. Postcondiciones La venta se almacena en el sistema. Incluye - Extiende - Hereda de - 37

38 Plantilla TPV (caso de uso sistema) Intenciones de usuario Obligaciones del sistema 1. El empleado indica que 2. El sistema registra el comienza una nueva venta. inicio de una venta 3. Mientras queden artículos: El 4. El sistema determina el empleado introduce el código de precio del producto y añade cada producto y la cantidad la información a la cuenta. 5. El empleado indica el fin de la 6. El sistema calcula y venta muestra el total. 7. El empleado indica el dinero 8. El sistema calcula y que ha recibido muestra el cambio. Imprime un recibo y registra la venta. Extensiones síncronas #1. Si en 3 se introduce un código de producto inexistente i t el sistema genera un mensaje de error. #2. En 7 el empleado puede cancelar la venta. Extensiones asíncronas Ninguna 38

39 Estilos de descripción: casos esenciales y reales Los casos de uso esenciales son independientes de la interfaz y de la tecnología. Caso de uso esencial (descripción muy abstracta) Caso de uso real/concreto (descripción muy detallada) 39

40 Casos esenciales y concretos Acción de Usuario Insertar Tarjeta Introducir PIN Pulsar tecla Pulsar tecla Introducir cantidad Pulsar tecla Recoger tarjeta Recoger Dinero Intenciones de Usuario Identificarse Elegir Recoger dinero Respuesta del Sistema Leer cinta magnética Solicitar PIN Verificar PIN Presentar menú de operación Presentar r menú de cuenta Preguntar cantidad Hacer eco de cantidad Devolver tarjeta Dispensar dinero Obtener Efectivo, Caso de uso esencial Responsabilidades Sistema Verificar identidad Ofrecer elecciones de menú Entregar dinero 40

41 Escenarios y Casos de Uso Un escenario es una descripción textual de una interacción particular entre los actores y el sistema. A un caso de uso le corresponden varios escenarios. Los escenarios básicos o principales no contienen situaciones de error. Los secundarios describen situaciones de error o alternativas ti de ejecución. 41

42 Modelo estructurado Contiene los actores y las relaciones entre los casos de uso (explicado después) CommonUseCases:CoffeeMachine <<usecase>> MakeCoffee <<usecase>> MakeTea :Customer <<include>> <<usecase>> TeaMaking Ejemplo tomado de Telelogic Tau

43 Modelo estructurado (2) Ejemplo de UML

44 Relaciones entre actores y casos de uso. Herencia entre actores: La relación de herencia entre actores indica que el actor descendiente puede jugar todos los roles del actor antecesor. Cliente Bancario Actor antecesor Cliente Corporativo Cliente Normal Actor descendiente 44

45 Herencia entre actores Puede activar todos los casos de uso del actor antecesor. Actor abstracto: Participa en el modelo pero no interactúa directamente con el sistema. 45

46 Relaciones entre casos de uso: incluye Inclusión: Un caso de uso A incluye a un caso de uso B, si una instancia de A puede realizar todos los eventos que aparecen descritos en B. <<include>> Bus car Socio Bibliotecario Baja Socio (from Use Case View) La instanciación de Baja Socio utiliza siempre el flujo de eventos de Buscar Socio 46

47 Inclusión de casos de uso En la descripción de A se incluye una referencia a B. Flujo de eventos del caso de uso A Flujo de eventos del caso de uso B 47

48 Relación de extensión Un caso de uso B extiende a un caso de uso A, si en la descripción de A figura una condición cuyo cumplimiento origina la ejecución del flujo de eventos de B. Evaluar Solicitud de Crédito <<extend>> Solicitar Información adicional al cliente 48

49 Relación de extensión (2) Una extensión equivale a una inclusión + una condición. ió Descripción del caso de uso A Condición Descripción del caso de uso B 49

50 Relación de extensión (3) Útil para: Partes opcionales de un caso de uso. Representar sub-cursos de eventos que se ejecutan bajo ciertas condiciones. 50

51 Relación de herencia Un caso de uso B se dice que especializa a un caso de uso A si el flujo de eventos asociado a B es un refinamiento del flujo de eventos asociado a A. Relación similar a la herencia OO. Permite separar un patrón de interacción genérico (caso padre) de un patrón de interacción más específico (caso descendiente). 51

52 Herencia (2) Ejemplo Enviar solicitud crédito Enviar solicitud de crédito personal Enviar solicitud de crédito empresarial 52

53 Relaciones entre casos de uso (1) Dado un conjunto de casos de uso no existe una única forma de representar las relaciones entre ellos. Diferencias entre inclusión y extensión: Una inclusión es equivalente a una extensión sin condiciones. El caso incluido siempre forma parte del caso que incluye. El caso que incluye no tiene sentido sin el incluido. 53

54 Relaciones entre casos de uso (2) Diferencias extensión y especialización: La extensión se utiliza para representar alternativas de ejecución que se llevan a cabo en algunas ocasiones. La especialización se utiliza para representar patrones genéricos de interacción que pueden especializarse en patrones más específicos o concretos. Habitualmente la extensión ( delegación ) se puede formular en términos de especialización, y a la inversa. 54

55 Proceso de construcción del modelo de casos de uso Para construir el modelo de casos de uso: Técnica descendente. Técnica ascendente. Descendente Ascendente Detectar actores Encontrar Casos de uso Organizar modelo de Casos de uso Generalizar escenarios Detallar Casos de uso Crear escenarios 55

56 Reglas para identificar actores Los usuarios pueden jugar varios roles cuando interactúan con el sistema. Un usuario se puede corresponder con varios actores. 56

57 Reglas para detectar actores Cualquier grupo o individuo que caiga en alguna de las siguientes categorías: Quién usará el sistema? ste Quién instalará el mismo? Quién hará labores de mantenimiento? Quién lo apagará? Qué otros sistemas se comunicarán con éste? Quién obtiene información? Quién proporciona información? 57

58 Reglas para identificar casos de uso Prestando atención a los actores: Cuáles son las tareas que los actores quieren que el sistema realice para ellos?. Podrá un actor crear, almacenar, cambiar o borrar datos del sistema?. Será necesario que un actor informe al sistema sobre cambios que han ocurrido en el exterior del mismo?. Será necesario que el actor sea informado sobre ciertas ocurrencias o cambios dentro del sistema?. 58

59 Reglas... Las respuestas a cada una de las preguntas anteriores representan flujos de eventos que identifican casos de uso candidatos. 59

60 Documento de Requerimientos Puede emplearse el estándar [IEEE Std ]. Con la siguiente estructura, que debe ser instanciada para cada proyecto. 60

61 Documento de Requerimientos RUP sugiere la siguiente adaptación de la plantilla anterior. Tabla de Contenidos 1. Introducción igual que antes. 2. Descripción General igual que antes. 3. Requerimientos Específicos 3.1 Modelo de Casos de uso Cada caso de uso agrupado eventualmente por actor. Cada Caso de uso descrito mediante una plantilla textual. 3.2 Requerimientos adicionales Cubre atributos del sistema, restricciones de diseño, eficiencia. Apéndices Índice 61

62 Ejemplo Desarrollo de un software para procesar ordenes de pedido para una compañía de ventas por correo. Ésta se encarga de vender productos comprados a diversos proveedores. Dos veces por año, la compañía publica un catalogo con sus productos, el cual es enviado a sus clientes y aotraspersonas interesadas. Los clientes compran productos enviando una lista de los mismos con la forma de pago. La empresa completa la orden y envía el pedido a la dirección correspondiente del cliente. El software de procesamiento de pedidos debe ser capaz de efectuar un seguimiento completo de una orden desde que ésta es recibida hasta que ésta es enviada. Los clientes pueden devolver artículos. Una interfaz electrónica, como la Web, puede ser apropiada para algunos clientes. La compañía utilizará diversas compañías de envío para atender los pedidos.! NO se incluyen todos los requisitos!! 62

63 Ejemplo (2) Identificación de los límites del sistema. Actores humanos: Cliente, Representante Cliente, Empleado Ventas, etc. Otros sistemas: Sistema de contabilidad, control de inventario, etc. 63

64 Ejemplo (3) Introducir Pedido Obtener Estado Pedido Cliente Enviar Catálogo Representante Cliente Cancelar Pedido Devolver Artículo Obtener Información de Producto Actualizar Cantidades Producto Inventario Pedidos listos para enviar Imprimir Etiquetas Envío Compañia de envios Recepción de género Cargar en cuenta Calcular Gastos Envio Empleado Sistema de Contabilidad 64

65 Ejemplo (4) Caso de Uso: Introducir Pedido Descripción: El caso de uso se ejecuta cada vez que un cliente/representante desea solicitar un pedido. Actor iniciador: Representante o cliente (a través del web) Actores secundarios: (A completar) Precondiciones: El cliente está dado de alta en el sistema. Poscondiciones: El pedido se almacena, marcándose como pendiente de enviar. 65

66 Ejemplo (4) Intenciones del Usuario 1. El Cliente/Representante selecciona Nuevo Pedido 3. El c/r introduce el nombre y la dirección Respuesta del Sistema 2. El sistema pregunta el nombre y la dirección del cliente. 4. El s. comprueba que existe. 66