PROCESO UNIFICADO CAPTURA DE REQUISITOS

Transcripción

1 PROCESO UNIFICADO CAPTURA DE REQUISITOS El proceso unificado de desarrollo, Ivar Jacobson, Grady Booch, James Rumbaugh, Ed. Addison Wesley, 1999 The unified software development process, Ivar Jacobson, Grady Booch, James Rumbaugh, Ed. Addison Wesley, 1999 Captura de requisitos Workflow Requisitos Concepción Elaboración Construcción Verificación Transición Análisis Diseño Implementación Prueba Iteración-es Inicial-es Iter. #1 Iter. #2 Iter. #3 Iter. #4 Iter. #5 Iter. #6 Iter. #7 (Adaptado de Jacobson, 1999) Ingeniería del software 2

2 Diagramas de casos de uso REQUISITOS Características que deben incluirse en un sistema o aplicación. Caso de uso: Descripción de un conjunto de secuencias de acciones que ejecuta un sistema produciendo un resultado de interés para un actor. Describen el comportamiento para cada actor Instancia de caso de uso Se lleva a cabo mediante colaboraciones de objetos Colaboración: Define las interacciones que han de producirse entre los objetos con el fin de que estos puedan desempeñar su papel. Ingeniería del software 3 Diagramas de casos de uso Elementos estructurales: Relaciones: Actor Caso de uso Colaboración Dependencia: relación semántica donde un cambio en el elemento independiente puede afectar a la semántica del elemento dependiente. Elemento dependiente Elemento independiente Ingeniería del software 4

3 Diagramas de casos de uso Relaciones Asociación: enlace que representa conexión entre objetos Actor Caso de uso Realización: relación semántica entre clasificadores, en la cual un clasificador especifica un contratao que otro clasificador se compromete a llevar a cabo. Caso de uso Colaboración Ingeniería del software 5 Captura de requisitos TAREA Enumerar requisitos candidatos Entender el contexto del sistema Capturar requisitos funcionales Capturar requisitos no funcionales PRODUCTOS (artifact) Lista de características Modelo de negocio o de dominio Modelo de casos de uso Prototipo IU Requisitos suplementarios o casos individuales Ingeniería del software 6

4 Captura de requisitos TAREA Enumerar requisitos candidatos Entender el contexto del sistema Capturar requisitos funcionales Capturar requisitos no funcionales PRODUCTOS (artifact) Lista de características Modelo de negocio o de dominio Modelo de casos de uso Prototipo IU Requisitos suplementarios o casos individuales Ingeniería del software 7 Captura de requisitos Modelo del dominio Qué es? Tipos de objetos (especificación o entrevistas) Cosas y eventos Diagramas de clases y glosario Desarrollar el modelo del dominio Técnicas de comunicación Solo contexto Usar el modelo del dominio Al describir los casos de uso Conceptos sugieren clases de análisis y diseño Ingeniería del software 8

5 Captura de requisitos Modelo de negocio Qué es? Procesos de negocio Cómo se realiza un proceso por un conjunto de trabajadores que usan unas entidades y unidades de trabajo Desarrollar el modelo de negocio Identificar casos de negocio y sus actores Desarrollar modelo de objetos de negocio con: trabajadores, entidades de negocio y unidades de trabajo Usar el modelo de negocio Un actor por trabajador Identificar sus papeles en distintos casos Ingeniería del software 9 Captura de requisitos TAREA Enumerar requisitos candidatos Entender el contexto del sistema Capturar requisitos funcionales Capturar requisitos no funcionales PRODUCTOS (artifact) Lista de características Modelo de negocio o de dominio Modelo de casos de uso Prototipo IU Requisitos suplementarios o casos individuales Ingeniería del software 10

6 Capturar requisitos funcionales Basado en casos de uso CU para el actor: forma de utilizar el sistema Objetivos: Capturar el comportamiento, sin especificar Comprensión común Validar arquitectura y sistema Ingeniería del software 11 Capturar requisitos funcionales 1. Identificar actores y casos de uso 2. Priorizar casos de uso 3. Detallar casos de uso 4. Prototipo de IU 5. Estructurar el modelo Ingeniería del software 12

7 Capturar requisitos funcionales 1. Identificar actores y casos de uso Para: Delimitar el sistema Actores y funcionalidad Glosario Pasos: Descubrir los actores Descubrir los casos de uso Describir brevemente cada caso de uso Describir el modelo de casos de uso Ingeniería del software 13 Ejemplo. Cajero automático Lista de requisitos candidatos FUNCIONES BÁSICAS R1. El usuario podrá consultar el saldo de su cuenta R2. Si el usuario intenta sacar una cantidad que supera el saldo de su cuenta, el cajero le avisará de que no es posible sacar esa cantidad R3. Si el usuario intenta sacar una cantidad que supera el límite diario, el cajero le avisará de que no es posible y volverá a solicitar una cantidad R4. El cliente del banco podrá hacer una transferencia a otra cuenta... REQUISITOS NO FUNCIONALES Fácil de usar Tiempo de respuesta inferior a 30 seg.... Ingeniería del software 14

8 Ejemplo. Cajero automático Casos de uso. Descripción inicial Caso de uso: Sacar dinero Actores: Cliente (iniciador) Tipo:?? Descripción: El caso de uso comienza con la identificación del usuario. El cliente usa el caso de uso para acceder a su cuenta. El caso de uso le devuelve el dinero solicitado, un aviso de que no tiene saldo o de que ha excedido el límite diario. Caso de uso: Consultar saldo Actores: Cliente Tipo:?? Descripción: El caso de uso comienza con la identificación del usuario. El usuario consulta el saldo de su cuenta. Ingeniería del software 15 Capturar requisitos funcionales 2. Priorizar los casos de uso Visión de la arquitectura Casos de uso a desarrollar en las primeras iteraciones Casos de uso significativos Ingeniería del software 16

9 Capturar requisitos funcionales 3. Detallar casos de uso Objetivo: flujo de sucesos (o eventos): Cómo comienza y termina el caso de uso Cómo interactúa con los actores Objetos que se intercambian Veremos: Cómo estructurar la descripción de un CU Qué incluir en una descripción de un CU Cómo formalizar la descripción del CU Antes... Ingeniería del software 17 Diagramas de estado Un diagrama de estados representa un elemento como una máquina de estados finita Un diagrama de estado, representa la vida de un único elemento Consta de: Estados, Transiciones, Eventos y Actividades Permite visualizar el comportamiento (dinámico) de un elemento Ingeniería del software 18

10 Diagramas de estado Elementos Estado: situación en la vida de un elemento durante la cual se satisface alguna condición, se realiza alguna actividad o se espera algún suceso Inicial, Intermedio, Final Transición: relación entre dos estados que indica que un elemento que esté en un primer estado realizará ciertas acciones y entrará en el segundo estado cuando se produzca un suceso especificado y se satisfacen las condiciones indicadas Suceso o evento: especificación de algún acontecimiento que ocupa espacio y tiempo. Es la aparición de un estímulo que puede disparar la transición de un estado a otro Ingeniería del software 19 Diagramas de estado E.Inicial Estado Estado E.Final Transición en el paro contratar en activo Estado perder empleo jubilarse jubilarse jubilado Suceso T. autom. Ingeniería del software 20

11 Diagramas de estado Actividad: ejecución no atómica en curso, dentro de una máquina de estados. Lo que se hace en el estado do: operación que toma un tiempo en el estado. Puede interrumpirse por un suceso, externo o interno, o terminar en transición automática Acción: computación atómica ejecutable que produce un cambio de estado del modelo o devuelve algún valor (deben ser operaciones de la clase) entry: instantáneamente a la entrada del estado exit: instantáneamente a la salida del estado eventos Ingeniería del software 21 Diagramas de estado La acción se considera instantánea Ejemplos: a Evento [condición] / acción b estado A entry: acción por entrar exit: acción por salir do: actividad mientras en estado Ingeniería del software 22

12 Capturar requisitos funcionales 3. Detallar casos de uso (cont.) Cómo estructurar un CU Camino básico: normal Alternativas: El actor puede elegir diferentes caminos Si está implicado más de un actor, las acciones de uno pueden influir el camino de otro El sistema detecta entradas erróneas Algunos recursos funcionan mal Gráficamente: diagrama de transición de estados Ingeniería del software 23 Capturar requisitos funcionales 3. Detallar casos de uso (cont.) Qué incluir (descripción textual) Estado inicial como precondición (condiciones previas) Cómo y cuándo comienza el caso de uso Orden de acciones (flujo de sucesos) Cómo y cuándo termina el caso de uso Estados finales como postcondiciones (cond. posteriores) Caminos no permitidos Descripción caminos alternativos (incluida o no con el c. básico) Interacción del sistema con los actores y cambios que producen Uso de objetos, valores y recursos del sistema Qué hace el sistema. Separar responsabilidades. el sistema... Requisitos especiales Validar los casos de uso Ingeniería del software 24

13 Capturar requisitos funcionales 3. Detallar casos de uso (cont.) Para casos de uso sencillos es suficiente texto Casos de uso complejos: necesitan estructuración y técnicas visuales Formalismos: diagramas de transición de estados actividad interacción Ingeniería del software 25 Diagramas de estado Diagrama de estados para un caso de uso: modificar datos alumno Pulsado Cancelar Pulsado modificar Datos en modificación Pulsado aceptar Datos comprobados [datos NoVálidos] Comprobando datos Datos comprobados [datos Válidos] Datos modificados Pulsado salir Ingeniería del software 26

14 Caso de uso Sacar dinero Flujo de eventos ACCIÓN DEL ACTOR 1. Este caso de uso empieza cuando un Cliente introduce una tarjeta en el cajero 3. Introduce la clave RESPUESTA DEL SISTEMA 2. Pide la clave de identificación 4. Comprueba la clave. 5. Presenta las opciones de operaciones disponibles 6. Selecciona la operación de Reintegro 8. Introduce la cantidad requerida 10. Recoge la tarjeta. 11. Recoge el recibo 12. Recoge el dinero y termina el caso de uso 7. Pide la cantidad a retirar. 9. Procesa la petición y da el dinero solicitado. Devuelve la tarjeta y genera un recibo Ingeniería del software 27 Caso de uso Sacar dinero Flujo de eventos ACCIÓN DEL ACTOR 1. Este caso de uso empieza cuando un Cliente introduce una tarjeta en el cajero 3. Introduce la clave RESPUESTA DEL SISTEMA 2. Pide la clave de identificación 4. Comprueba la clave. 5. Presenta las opciones de operaciones disponibles 6. Selecciona la operación de Reintegro 8. Introduce la cantidad requerida 10. Recoge la tarjeta. 11. Recoge el recibo 12. Recoge el dinero y termina el caso de uso 7. Pide la cantidad a retirar. 9. Procesa la petición y da el dinero solicitado. Devuelve la tarjeta y genera un recibo Ingeniería del software 28

15 Caso de uso Validar usuario Flujo de eventos ACCIÓN DEL ACTOR 1. Este caso de uso empieza cuando un Cliente introduce una tarjeta en el cajero 3. Introduce la clave RESPUESTA DEL SISTEMA 2. Pide la clave de identificación 4. Comprueba la clave 5. Si es válida presenta las opciones disponibles y se termina el caso de uso CAMINOS ALTERNATIVOS Evento 3. El cliente cancela la transacción Evento 4. La clave no es válida y se reinicia el caso de uso. Si ocurre tres veces se cancela la transacción y no se devuelve la tarjeta HAY QUE DEFINIR ESTOS DOS FLUJOS DE EVENTOS!! Ingeniería del software 29 Caso de uso Sacar dinero Flujo de eventos ACCIÓN DEL ACTOR 1. Este caso de uso empieza cuando se han presentado las opciones de operaciones disponibles. Selecciona la operación de Reintegro 3. Introduce la cantidad requerida RESPUESTA DEL SISTEMA 2. Pide la cantidad a retirar. 4. Procesa la petición y da el dinero solicitado. Devuelve la tarjeta y genera un recibo 5. Recoge la tarjeta. 6. Recoge el recibo 7. Recoge el dinero y termina el CU Ingeniería del software 30

16 Caso de uso Sacar dinero Flujo de eventos CAMINOS ALTERNATIVOS Evento 4: La cantidad solicitada supera el saldo. Se indica el error y se cancela la operación. Evento 4: La cantidad solicitada supera el límite diario. Se indica el error y se vuelve a pedir otra cantidad. Evento 4: En el cajero no hay dinero. HAY QUE DEFINIR ESTOS TRES FLUJOS DE EVENTOS!! Podríamos definir diagramas de estados Requisito no funcional asociado al caso de uso Sacar dinero: El tiempo de respuesta para un cliente debe ser <30 sg en el 90% de los casos Ingeniería del software 31 Caso de uso Validar usuario Flujo de eventos tarjeta_introducida Leyendo datos do: visualizar (login) Datos leídos/n=0 Validando clave do: validar (nºtarjeta, clave) exit: n=n+1 [ NO datos_correctos AND n<3 ] cancelar [ datos_correctos ] [ NO datos_correctos AND n=3 ]/tragar_tarjeta Ingeniería del software 32

17 Capturar requisitos funcionales 4. Prototipo de IU A partir de las descripciones de los casos de uso. Pasos: Diseño lógico: qué necesita cada actor de la interfaz para que se pueda ejecutar el caso de uso Descripción y construcción del prototipo ejecutable pero acciones nulas (validación y depuración) Ingeniería del software 33 Capturar requisitos funcionales 5. Estructurar el modelo de casos de uso Identificar funcionalidad compartida Generalizaciones Identificar funcionalidad adicional y opcional extend Identificar otras relaciones include Ingeniería del software 34

18 Diagramas de Casos de Uso Relaciones Generalización Caso de uso Caso de uso Usuario Administrador Identificar Usuario Identificar Adm Alta Usuario Baja Usuario Ingeniería del software 35 Diagramas de Casos de Uso Relaciones Inclusión Cliente Extensión Hacer transfer. Sacar dinero <<include>> <<include>> Consultar saldo Sacar dinero <<extend>> Recibo En papel Cliente Ingresar dinero <<extend>> Ingeniería del software 36

19 Ejemplo. Cajero automático Cliente del banco Empleado sucursal Sacar con visa Sacar dinero <<include>> Ingresar dinero <<include>> Transf. <<include>> Consultar saldo <<extends>> <<include>> Reponer<<include>> dinero <<include>> Recoger dinero Validar usuario Reparar <<include>> Encargado mantenimiento Ingeniería del software 37 Ejemplo. Cajero automático Validar usuario R2, R3,... Usuario Sacar dinero <<extends>> Sacar con visa Empleado sucursal Cliente del banco Transf. Consultar saldo Reponer dinero Recoger dinero Ingresar dinero R4,... R1 Ingeniería del software 38

20 Captura de requisitos TAREA Enumerar requisitos candidatos Entender el contexto del sistema Capturar requisitos funcionales Capturar requisitos no funcionales PRODUCTOS (artifact) Lista de características Modelo de negocio o de dominio Modelo de casos de uso Prototipo IU Requisitos suplementarios o casos individuales Ingeniería del software 39 Curso virtual Un sistema que ofrece cursos virtuales permite que tanto profesores como alumnos accedan al sistema. Existen una serie de operaciones comunes que ambos pueden realizar como son asistir al foro y comunicarse a través del chat. En cualquier caso, tanto profesores como alumnos deberán loguearse en el sistema antes de poder acceder al curso. Obligatoriamente, un alumno deberá haberse matriculado en el sistema para poder acceder a él. Así además los profesores podrán consultar los alumnos matriculados en cualquiera de los cursos. Los alumnos podrán modificar sus datos. Los profesores podrán colgar el material docente del curso a través de la aplicación. Los alumnos de este modo, podrán acceder a consultar las lecciones. Además asociado a cada lección podrán consultar la bibliografía asociada, descargarse los apuntes y realizar los tests asociados al temario. También podrán, opcionalmente, recomendar dichas lecciones a otros alumnos matriculados. Ingeniería del software 40

21 Ejemplo. Curso Virtual Identificar usuario Usar chat Usuario Cargar material Asistir al foro Profesor Recomendar Consultar alumnos <<extend>> <<extend>> Realizar test Alumno Mostrar lecciones Modificar datos alumno Matricularse <<extend>> <<extend>> Descargar apuntes Consultar bibliografía Ingeniería del software 41 Ejemplo. Punto de venta Lista de requisitos candidatos FUNCIONES BÁSICAS R1.1. Grabar la venta actual (productos comprados por el cliente) R1.2. Calcular el total de la venta actual incluidos los impuestos R1.3. Capturar información del producto usando el código de barras o tecleando el código del producto. R1.4. Reducir la cantidad en inventario cuando se realice la venta R1.5. Registrar ventas realizadas R1.6. El dependiente debe iniciar una sesión con identificador y clave para usar el sistema R1.7. Dar un mecanismo de almacenamiento R1.8. Dar mecanismos de comunicación con otros procesos y sistemas R1.9. Mostrar descripción y precio del producto almacenado NO FUNCIONAL 5 seg, color Ingeniería del software 42

22 Ejemplo. Punto de venta Lista de requisitos candidatos FUNCIONES DE PAGO R2.1. Manejar pagos en metálico, tomar cantidad ofrecida y calcular el cambio R2.2. Manejar pagos con tarjeta, capturar información de la tarjeta con un lector o manualmente y autorizar el pago vía modem. OTRAS FUNCIONES R3.1. Es necesario dar de alta dependientes nuevos en el puesto de venta y dar de baja aquellos que dejan el puesto de venta. R3.2. El puesto de venta es encendido y apagado cada día por el encargado de la sección, que comprueba que el puesto funciona correctamente y comprueba la fecha y la hora REQUISITOS NO FUNCIONALES Fácil de usar, Tiempo de respuesta corto, Plataforma, Precio al público Interfaz (gráfica, con colores, ventanas, facilitar navegación por teclado, ) Ingeniería del software 43 Ejemplo. Punto de venta Punto de venta R1.1, R1.2, R1.3, R1.7, R1.9, R2.1, R2.2, R2.3, R2.4 Comprar productos Iniciar sesión Cliente Dependiente Devolver productos Comenzar Cerrar Encargado Admin. Gestionar usuarios Ingeniería del software 44

23 Caso de uso Acceder al sistema ACCIÓN DEL ACTOR RESPUESTA DEL SISTEMA 1. El actor rellena los campos de DNI y clave (la clave se la dió la Universidad) en una pantalla que le ha presentado el sistema y pulsa sobre el botón enviar 2. El sistema comprueba que el formato de ambos campos es el adecuado; es decir, que el DNI es un string de 8 dígitos y que la clave es una secuencia de 4 dígitos 3. El sistema verifica que la clave tecleada se corresponde con el DNI tecleado; es decir, que la clave es la correcta para ese DNI. 4. El sistema verifica que la fecha actual es la que le corresponde al actor para matricularse. 5. El sistema comprueba que el actor no Caminos alternativos: adeuda ningún importe a la Universidad Evento 1: el actor cancela la operación Evento 2: existe error en el formato del DNI y/o de la clave Evento 3: existe error en la clave Evento 4: la fecha actual no es la asignada al actor para matricularse Ingeniería Evento 5: del el software actor es moroso 45 Caso de uso Acceder al sistema ejecutaraplicación / ejecuta {ejecuta.starttime > 5 and ejecuta.stoptime < 2} {ejecuta.numero_de_usuarios < 50} aqui Leer datos do/ visualizar (login) enviar( NIF, clave ) aqui clave incorrecta do/ visualizar (login.error.clave) Datos incorrectos do/ visualizar (login.error.datosincorrectos) [ clave incorrecta ] [ dia incorrecto ] clave incorrecta do/ visualizar (login.error.clave) [ datos incorrectos ] Validar datos do/ validadatos (NIF, clave) [ moroso ] [ datos correctos ] Moroso do/ visualizar (login.error.deudor) salir salir salir Ingeniería del software 46