1 Capitulo 4. Obtención de RequerimientosUsando UML, Patrones y Java Ingeniería de Software Orientada a objetos Nadie está exento de cometer errores. Lo importante es aprender de ellos. (Karl Popper)
2 Lección: Buscar primero la funcionalidad y después definir los objetos¿Qué es esto? Pregunta: ¿Cómo cortar el césped? Lección: Buscar primero la funcionalidad y después definir los objetos
3 ¿En dónde estamos? Tres maneras para lidiar con la complejidad:Abstracción. Descomposición (Técnica: Divide y vencerás). Herencia (Técnica: estratificación). Dos maneras de tratar con la descomposición: Descomposición: Orientada a objetos y funcional. La descomposición funcional conduce a un código inmanejable. Dependiendo del propósito del sistema, se pueden encontrar diferentes objetos. ¿Cuál es el mejor método? Empezar por la descripción de la funcionalidad (Modelo de casos de uso ). Luego seguir encontrando objetos (Modelo de objetos). ¿Qué actividades y modelos necesitamos? Esto nos lleva al ciclo de vida del software que utilizamos en clase. La identificación de los objetos y la definición de los límites del sistema están fuertemente entrelazados entre sí.
4 Definición del ciclo de vida del SoftwareConjunto de actividades y sus relaciones, cada una de las cuales soporta el desarrollo de sistema software. Preguntas típicas del ciclo de vida: ¿Qué actividades puedo seleccionar para un proyecto software? ¿Qué dependencia hay entre las actividades ? ¿Cómo debo programar las actividades? ¿Cuál es el resultado de una actividad ?
5 Ejemplo: Selección de las actividades de ciclo de vida del software para un proyecto específicoUn hacker sólo conoce una actividad: Implementación Actividades del ciclo de vida del software Obtención de requerimientos Análisis Diseño del Sistema Diseño de Objetos Implementación Pruebas Cada actividad produce uno o mas modelos
6 Actividades del ciclo de vida del softwareObtención de requerimientos Análisis de requerimientos Diseño del sistema Diseño de objetos Implemen- tación Pruebas Implementado por Verificado por Expresado en términos de Estructurado por Realizado por clase... ? clase.... ? Objetos del dominio de la aplicación Modelo casos de uso Objetos del dominio de la solución Subsistemas Código Fuente Casos de prueba
7 Para establecer los requerimientos: Identificar el sistemaEl desarrollo de un sistema no sólo se hace tomando una foto de una escena (dominio) Dos preguntas que son respondidas en el proceso de requerimientos ¿Cómo podemos identificar el propósito de un sistema? Para definir los límites: ¿Qué hay dentro y fuera del sistema? El proceso de requerimientos consta de dos actividades Obtención de requerimientos: Definición del sistema en términos entendidos por el cliente (“Descripción del problema”) Análisis de requerimientos: Especificación técnica del sistema en términos entendidos por el desarrollador (“Especificación del problema”) La identificación de objetos y la definición de los límites del sistema están fuertemente entrelazados entre sí.
8 Definir los límites del sistema es con frecuencia difícilQué observa aquí? Otra cuestión interesante de encontrar objetos es definir cuales objetos están dentro del dominio de aplicación y los que están fuera de él. A veces te ayuda a conseguir una comprensión más clara de todo el sistema. Mire la figura de esta diapositiva. ¿Qué muestra? ¿Un montón de puntos blancos y negro? ¿Dado que le dirá que contiene un sistema (que es un modelo de objeto pueden encontrarse) Cómo empezaría con buscando objetos? Vuelta a la diapositiva. Gírelo boca abajo. Mire el "dominio del problema" desde todos los ángulos. Y de repente puede experimentar lo que yo llamaría la "experiencia de gestalt". Verá el dominio de aplicación. Ahora no hay ninguna receta para encontrarlo. Puede encontrar un objeto muy bajo nivel, tales como una oreja o usted podría encontrar un objeto de alto nivel como la forma de un perro. De hecho, si mira atentamente encontrará un perro dálmata. Una vez que entiendes que buscas en un perro, un lote de los píxeles negros y blancos en la cifra total no forman parte de su s...
9 Productos del proceso de requisitos (Diagrama de actividades)Análisis de Requerimientos Especificación del sistema: Modelo Modelo de análisis: Modelo Generación del enunciado del problema Obtención de Enunciado del problema
10 Obtención de RequerimientosNo es una actividad fácil Requiere colaboración de personas con diferentes conocimientos Usuarios con conocimientos del dominio de aplicación. Desarrolladores con conocimiento del dominio de solución (de diseño e implementación). Cerrar la brecha entre el usuario y desarrollador : Escenarios: Ejemplo del uso del sistema en términos de una serie de interacciones entre el usuario y el sistema. Casos de uso: Abstracción que describe una clase de escenarios.
11 Especificación del sistema vs. Modelo de análisisAmbos modelos se centran en los requerimientos desde la vista del usuario del sistema. La especificación de sistema: usa lenguaje natural (derivado del enunciado del problema). El modelo de análisis utiliza la notación formal o semiformal (por ejemplo, un lenguaje gráfico como UML). El punto de partida es el enunciado del problema.
12 Enunciado del problemaEl enunciado del problema es desarrollado por el cliente como una descripción del problema que abordará el sistema. Un buen enunciado del problema describe: Situación actual. La funcionalidad del nuevo sistema que debe apoyar. El entorno en el cual se desarrollará el sistema. Resultados esperados por el cliente. Fechas de entrega. Un conjunto de criterios de aceptación.
13 Elementos del enunciado del problemaSituación actual: el problema a resolver Descripción de uno o más escenarios Requerimientos: Funcionales o no funcionales Restricciones (“seudorrequerimientos”) Agenda del proyecto Hitos importantes que involucran la interacción con el cliente, incluyendo la fecha límite para la entrega del sistema Objetivo del ambiente El entorno en el que el sistema de entrega tiene que realizar un conjunto específico de pruebas del sistema Criterio de aceptación del cliente Criterios para las pruebas del sistema
14 Situación actual: El problema a resolverHay un problema en la situación actual Ejemplos: El tiempo de respuesta al jugar cartas es demasiado lento. ¿Qué ha cambiado? ¿Por qué se puede resolver el problema ahora? Ha habido un cambio en el dominio de aplicación o en el dominio de la solución. Cambio en el dominio de aplicación Una nueva función (proceso de negocio) se introduce en el negocio. Ejemplo: Podemos jugar juegos altamente interactivos con gente remota. Cambio en el dominio de la solución Ha aparecido una nueva solución tecnológica. Ejemplo: Internet permite la creación de comunidades virtuales.
15 Caso ARENA: El problemaInternet ha hecho posible las comunidades virtuales Grupos de personas que comparten intereses comunes, pero que nunca se han conocido en persona. Estas comunidades virtuales pueden ser de corta duración (como: personas en una sala de chat o un juego multijugador) o de larga duración (como: suscriptores a una lista de correo). Muchos juegos multijugador ahora incluyen soporte para comunidades virtuales. Los Jugadores pueden recibir noticias sobre actualizaciones del juego, nuevos niveles de juegos, anunciar y organizar partidos, y comparar puntajes.
16 Caso ARENA: El problemaActualmente cada compañía de juegos desarrolla ese apoyo a la comunidad en cada juego individual. Cada compañía usa diferentes infraestructuras y conceptos, y ofrece diferentes niveles de soporte. Esta inconsistencia y redundancia conduce a los siguientes problemas: Curva de aprendizaje alta para unirse a una nueva comunidad de jugadores. Las compañías de juegos deben desarrollar el soporte desde el inicio. Los anunciantes necesitan colocarse en contacto con cada comunidad individual por separado.
17 Caso ARENA: Los objetivosProporcionar una infraestructura genérica para el funcionamiento de una ARENA para: Soporte a las comunidades virtuales de juego. Registro de nuevos juegos. Registro de nuevos jugadores. Organizar torneos. Hacer un seguimiento de los puntajes de los jugadores. Proporcionar un marco de referencia para los organizadores del evento para: Personalizar el número y secuencia de partidos y la acumulación de puntos de valoración de expertos.
18 Caso ARENA: Los objetivosProporcionar un marco de referencia para los desarrolladores de juegos para: El desarrollo de nuevos juegos o para la adaptación de los juegos existentes en el marco de referencia de ARENA. Proporcionar una infraestructura para los anunciantes.
19 Tipos de requerimientosRequerimientos Funcionales: Describen las interacciones entre el sistema y su entorno, independiente de la implementación Un operador de ARENA debe ser capaz de definir un nuevo juego. Requerimientos no funcionales: Describen aspectos del sistema visibles para el usuario, que no están directamente relacionados con el comportamiento funcional del sistema. El tiempo de respuesta debe ser inferior a 1 segundo. El servidor de ARENA debe estar disponible las 24 horas del día. Restricciones (“Seudorrequerimientos"): Son impuestas por el cliente o el entorno en el cual opera el sistema El lenguaje de implementación debe ser Java. ARENA debe permitir interactuar dinámicamente a los juegos existentes con los proporcionados por otros desarrolladores de juegos.
20 ¿Qué no debe ir en los requerimientos?La estructura del sistema, la tecnología de implementación. La metodología de desarrollo. El ambiente de desarrollo. El Lenguaje de implementación. Reutilización. Lo ideal es que ninguno de los anteriores estén limitados por lo que diga el cliente .
21 Validación de RequerimientosLa validación de requerimientos es un paso crítico en el proceso de desarrollo, generalmente después de la ingeniería de requerimientos o el análisis de requerimientos. También en la entrega (la prueba de aceptación cliente). Criterios de validación de requerimientos: Corrección: Los requerimientos representan la visión del cliente. Suficiencia: Son descritos todos los escenarios posibles en los cuales el sistema puede ser utilizado, incluyendo el comportamiento excepcional por el usuario o el sistema.
22 Validación de RequerimientosConsistencia: Hay requerimientos funcionales o no funcionales que se contradicen entre sí. Realismo: Los requerimientos pueden ser implementados y entregados Trazabilidad: Cada función del sistema puede ser rastreada a un correspondiente conjunto de requerimientos funcionales Problema con la validación de requerimientos: Los requerimientos pueden cambiar muy rápido durante la obtención de requerimientos.
23 Validación de RequerimientosHerramientas de soporte para la administración de requerimientos: Almacenamiento de requerimientos en un repositorio compartido. Proporcionar acceso multiusuario. Creación automática de un documento de especificación del sistema desde el repositorio. Permitir el control de cambios. Proporcionar la trazabilidad a lo largo del ciclo de vida del proyecto.
24 Tipos de obtención de requerimientosIngeniería Greenfield El desarrollo comienza desde cero, no existe ningún sistema previo, los requerimientos son extraídos de los usuarios finales y el cliente. Se activa por las necesidades del usuario Ejemplo: Desarrollar un juego desde cero: Asteroides. Reingeniería Rediseño y/o reimplementación de un sistema existente utilizando nueva tecnología. Desencadenada por el habilitador de tecnología. Ejemplo: Reingeniería de un juego.
25 Tipos de obtención de requerimientosIngeniería de interfaces Proporcionar los servicios de un sistema existente en un nuevo entorno. Desencadenado por el habilitador de tecnología o nuevas necesidades del mercado. Ejemplo: Nueva Interfaz para un juego existente (Bumpers)
26 Escenarios “Es una descripción narrativa de lo que la gente hace y experimenta cuando trata de utilizar sistemas y aplicaciones de computadora” [M. Carrol, Diseño basado en escenarios , Wiley, 1995] Es una descripción concreta, centrada e informal de UNA SOLA característica del sistema desde el punto de vista de los actores. Los escenarios pueden tener usos diferentes durante el ciclo de vida del software Obtención de requerimientos: Escenario tal como es, Escenario visionario. Prueba de aceptación del cliente: Escenario de evaluación. Desarrollo del sistema: Escenario de entrenamiento.
27 Tipos de escenarios Escenario visionario: Escenario de evaluación:Escenario tal como es: Usado en la descripción de una situación actual. Generalmente usado en proyectos de reingeniería. El usuario describe el sistema. Escenario visionario: Usado para describir un sistema futuro. Generalmente es usado en Ingeniería Greenfield y en reingeniería de proyectos. No puede ser realizada a menudo por el usuario o el desarrollador solo. Escenario de evaluación: Las tareas del usuario por las cuales se va a evaluar el sistema. Escenario de entrenamiento: Instrucciones paso a paso que guían al usuario novato a través de un sistema desarrollado.
28 ¿Cómo identificar escenarios?No espere que el cliente sea claro si el sistema no existe (Ingeniería Greenfield). No espere que la información esté, incluso si el sistema existe. Abordar desde un enfoque dialéctico (ingeniería evolutiva, incremental). Usted ayuda al cliente a formular los requerimientos. El cliente le ayuda a comprender los requerimientos. Los requerimientos evolucionan mientras que los escenarios están siendo desarrollados.
29 Heurísticos para identificar escenariosPreguntas orientadoras: ¿Cuáles son las principales tareas que el sistema necesita para funcionar? ¿Qué datos del actor creará, almacenará, modificará, eliminará o adicionará al sistema? ¿Qué cambios externos se necesita que conozca el sistema? ¿Qué cambios o eventos necesita el actor que le informe el sistema? Observación de tareas si el sistema ya existe (Ingeniería de interfaz o reingeniería de procesos) Pida hablar con el usuario final, no sólo con el cliente. Espere resistencia y trate de superarla.
30 Ejemplo: Sistema de manejo de accidentes¿Qué hay que hacer para denunciar un incidente de un “gato en un árbol"? ¿Qué hay que hacer si una persona reporta una “bodega en llamas”? ¿Quién está involucrado en el reporte de un incidente? ¿Qué hace el sistema si no hay carros de policía disponibles?, ¿Si el carro del policía tiene un accidente en el camino hacia el incidente de “gato en un árbol" ? ¿Qué necesito hacer si el “gato en un árbol" se convierte en una “abuela que ha caído de una escalera"? ¿Puede el sistema soportar un reporte de incidente simultáneo “bodega en llamas?”
31 Ejemplo de escenario: Bodega en llamasRoberto, conduciendo por la calle principal en su patrulla, observa que sale humo saliendo de una bodega. Su compañera, Alicia reporta la emergencia desde el carro. Alicia introduce la dirección del edificio, una breve descripción de su ubicación (es decir, esquina noroeste) y un nivel de emergencia. Además de un carro de bomberos, solicita varias ambulancias en la escena dado que la zona parece estar algo atareada. Ella confirma su entrada y espera una respuesta. Juan, el distribuidor, es alertado de la emergencia mediante un sonido en su estación de trabajo. Revisa la información presentada por Alicia y da el acuse de recibo del reporte. Él asigna un carro de bomberos y dos ambulancia para el sitio del incidente y envía una hora estimada de llegada (ETA) a Alicia. Alicia recibe el acuse de recibo y la ETA.
32 Observaciones acerca del escenario “Bodega en llamas”Escenario Concreto Describe una única instancia para informar de un incidente de fuego. No menciona todas las posibles situaciones en las que puede un incendio ser reportado. Actores participantes Roberto, Alicia y Juan
33 Siguiente paso: …formulados los escenariosEncontrar todos los escenario que especifiquen todas las instancias posibles de cómo reportar un incendio para definir casos de uso Describir cada caso de uso con mayor detalle Actores participantes Describa las condiciones de entrada Describa el flujo de eventos Describa las condiciones de salida Describa las excepciones Describa los requerimientos especiales (Restricciones, Requerimientos no funcionales).
34 Casos de uso Un caso de uso es un flujo de eventos dentro del sistema que incluye una interacción con los actores. Este es iniciado por un actor. Cada caso de uso tiene un nombre. Cada caso de uso tiene una condición final . Notación Gráfica: Son óvalos que contienen el nombre del caso de uso. ReportarEmergencia Modelo de casos de uso: Es el conjunto de todos los casos de uso que especifican la funcionalidad completa del sistema.
35 Ejemplo: Caso de uso para el manejo de incidentesReportarEmergencia OficialCampo Despachador AbrirIncidente AsingarRecursos <
36 Heurística: ¿Cómo encuentro los casos de uso?Seleccione una franja vertical del sistema (un escenario). Discútalo en detalle con el usuario para comprender su estilo preferido de interacción. Seleccione un segmento horizontal (muchos escenarios) para definir el alcance del sistema. Discutir el alcance con el usuario. Utilizar prototipos ilustrativos (maquetas) como apoyo visual Averigüe sobre que lo que el usuario hace Observación de tareas (Correcto) Cuestionarios (INCORRECTO)
37 Ejemplo de caso de uso Nombre caso de uso: ReportarEmergenciaActores participantes: Oficial de campo (Roberto y Alicia, en el escenario). Despachador (Juan, en el escenario). Excepciones: El OficialCampo es notificado de inmediato si se pierde la conexión entre su terminal y la central. El Despachador es notificado inmediatamente si la conexión entre cualquier OficialCampo registrado y la central se pierde. Flujo de eventos: (ver la siguiente diapositiva) Requerimientos especiales: El acuse de recibo del reporte del OficialCampo debe darse en menos de 30 segundos. La respuesta llega a más tardar 30 segundos después de que ha sido enviada por el despachador.
38 Ejemplo de caso de uso El OficialCampo activa la función de “ReportarEmergencia" desde su terminal. FRIEND responde presentando un formulario al oficial. El OficialCampo diligencia el formulario, seleccionando el nivel de emergencia, tipo, ubicación y una breve descripción de la situación. El OficialCampo también puede describir las posibles respuestas a la situación de emergencia. Una vez completado el formulario, el OficialCampo envía el formulario, en ese momento, el Despachador es notificado.
39 Ejemplo de caso de uso El Despachador revisa la información presentada y crea un incidente en la base de datos llamando al caso de uso de AbrirIncidente. El Despachador selecciona una respuesta y da el acuse recibo al reporte de emergencia. El OficialCampo recibe el acuse de recibo y la respuesta seleccionada.
40 Otro caso de uso: Asignar un recursoActores: Supervisor de campo: Este es el oficial en el sitio de emergencia. Asignador de recursos: El asignador de recursos es responsable por el compromiso y la liberación de los recursos administrados por el sistema FRIEND. Despachador: El despachador entra, actualiza y elimina los incidentes de emergencia, las acciones y las solicitudes en el sistema. El despachador también cierra incidentes de emergencia.. Oficial de campo: Reporta accidentes desde el campo.
41 Otro caso de uso: Asignar un recursoNombre del caso: AsignarRecursos Actores participantes: OficialDeCampo (Roberto y Alicia en el Escenario) Despachador (Juan en el escenario) Asignador de Recursos Supervisor de Campo Condiciones de entrada El asignador de recursos ha seleccionado un recurso disponible. El recurso no está asignado actualmente
42 Otro caso de uso: Asignar un recursoFlujo de eventos El asignador de recursos selecciona un incidente de emergencia. El recurso es asignado al incidente de emergencia. Condiciones de salida El caso de uso termina cuando el recurso es asignado. El recurso seleccionado ya no está disponible para cualquier otro incidente de emergencia o solicitudes de recursos. Requerimientos especiales El Supervisor de Campo es responsable de la administración de los recursos.
43 Pasos a seguir cuando se formulan casos de usoPrimer paso: nombre del caso de uso Nombre de caso de uso : ReportarEmergencia Segundo paso: Identificar actores Generalice los nombres concretos (“Roberto”) a los actores participantes (“OficialDeCampo”) Actores Participantes: OficialCampo (Roberto y Alicia en el escenario) Despachador (Juan en el escenario) Tercer paso: Concéntrese en el flujo de eventos Use lenguaje natural e informal.
44 Relaciones entre casos de usoUn modelo de caso de uso se compone de: los casos de uso y sus relaciones (asociaciones entre casos de uso). Tipos de relaciones importantes de casos de uso: incluye, extiende, Generalización Incluye Un caso de uso utiliza a otro (descomposición funcional). Extiende Un caso de uso se extiende a otro caso de uso. Generalización Un caso de uso tiene diferentes especializaciones.
45 <
46 <
47 Relación <
48 Asociación de generalización de casos de usoProblema: Usted tiene un comportamiento común entre casos de uso y quiere que esto sea un hecho. Solución: La Asociación de generalización entre factores de casos de uso común comportamiento. Los casos de uso de niño heredan el comportamiento y significado del padre caso de uso y agregar o reemplazar algún comportamiento. Ejemplo: Consideremos el caso de uso "ValidarUsuario", responsable de verificar la identidad del usuario. El cliente puede requerir dos ejecuciones: “ValidarContraseña" y “ValidarHuellaDigital” ValidarUsuario ValidarContraseña ValidarHuellaDigital Caso de uso padre hijo
49 De casos de uso a objetosNivel Superior del Caso de uso Nivel 2 - Casos de uso Operaciones Ay B son llamados objetos participantes Nivel 2 Nivel 1 Nivel2 Nivel3 Nivel4 A B Nivel 3 - Casos de uso
50 Los casos de uso se pueden usar para mas de un objetoNivel 2 Nivel 1 Nivel2 Nivel3 Nivel4 A B Nivel Superior del Caso de uso Nivel 2 - Casos de uso Nivel 3 - Casos de uso Operaciones Objetos Participantes
51 Cómo especificar un caso de uso (Resumen)Nombre del caso de uso Actores Descripción de los actores involucrados en el caso de uso Condiciones de entrada “Este caso de uso inicia cuando…” Flujo de eventos Formulario libre, lenguaje natural e informal Condición de salida “El caso de uso finaliza cuando…” Excepciones Describa que pasa cuando las cosas van mal Requermientos especiales Requerimientos no funcionales, restricciones
52 Resumen El proceso de requerimientos consta de: obtención de requerimientos y análisis de requerimientos. La actividad de obtención de requerimientos es diferente para: Ingeniería de Greenfield, reingeniería de procesos, ingeniería de interfaces Escenarios: Excelente manera de establecer comunicación con el cliente. Diferentes tipos de escenarios : Escenario tal como es, visionario, evaluación y pruebas. Casos de uso: Abstracción de escenarios.
53 Resumen La descomposición funcional pura no es conveniente:Lleva a un código interminable La identificación pura de objetos no es conveniente: Podría conducir a definir objetos, atributos y/o métodos incorrectos. La clave de un análisis exitoso es: Empezar con los casos de uso y después encontrar los objetos. Si alguien pregunta “¿Qué es esto?”, no contestar de inmediato, observar el usuario final o volver a la pregunta "¿para qué se utiliza?”.