Ingeniería de Software

Presentación del tema: "Ingeniería de Software"— Transcripción de la presentación:

1 Ingeniería de Software
Unidad 3 Análisis de requerimientos del software

2 Contenido Técnicas de recolección de información
Unidad 3 Contenido Técnicas de recolección de información Técnicas convencionales Desarrollo conjunto de aplicaciones Prototipado Identificación de los requerimientos Especificación de requerimientos del software (estándar IEEE ) Características de la especificación Estructura de la especificación Métodos estructurados Diagramas de flujo de datos (DFD) Diccionario de datos (DD) Especificación de procesos Revisión de la especificación estructurada Introducción a los métodos orientados a objetos Casos de uso Modelo de clases Diagramas de interacción Diagramas de estados Diagramas de actividad Validación de los requerimientos “Sé que ustedes piensan que comprendieron lo que creen que dije, pero no estoy seguro de que se hayan dado cuenta que lo que escucharon no es lo que quise decir” [Hayakawa] “No dije que no lo dije. Dije que no dije lo que dije. Quiero dejar eso muy en claro” [Romeney] “Yo no la uso, la manejo” [Fox] Ingeniería de software

3 Técnicas de recolección de información
Unidad 3 Técnicas de recolección de información Surgen como un medio para mejorar la comunicación entre usuarios/clientes y los desarrolladores de software. Por un lado los desarrolladores normalmente no conocen todos los detalles del trabajo de la empresa. Por otro lado los usuarios no saben qué información es necesaria o relevante para el desarrollo de una aplicación. Se sugieren cinco pasos para analizar las necesidades de los usuarios: Identificar las fuentes de información y planificar las actividades de investigación. Realizar las preguntas apropiadas para comprender las necesidades. Analizar la información para profundizar en aspectos poco claros. Confirmar con los usuarios lo que se considera comprendido. Sinterizar los requisitos en un documento de especificación apropiado. Ingeniería de software

4 Técnicas de recolección de información … (2)
Unidad 3 Técnicas de recolección de información … (2) Existen diversas técnicas utilizadas para la recolección de información. Dentro de las que se pueden considerar como convencionales están: Entrevistas La técnica más empleada, requiere de preparación por parte del analista. Observación Se analiza en in situ cómo funciona lo que se quiere informatizar. Estudio de la documentación Casi todas las organizaciones tienen documentos que describen su funcionamiento. Cuestionarios Útiles para recolectar información concisa de un gran número de personas en poco tiempo. Tormenta de ideas Se puede identificar un primer conjunto de requisitos en aquellos casos en los que no están muy claras todas las necesidades que hay que cubrir. En una primera fase se sugieren todo tipo de ideas, en una segunda se validan y detalla cada propuesta. Entre otras técnicas están: Desarrollo conjunto de aplicaciones (JAD) Involucra al usuario en el proyecto para que trabaje conjuntamente con el analista. Prototipado Consiste en la construcción de modelos (maquetas) del sistema que el cliente evalúa para determinar si cumple con sus necesidades. Ingeniería de software

5 Técnicas convencionales
Unidad 3 Técnicas convencionales La entrevista Se puede definir como un intento sistemático de recoger información de otra persona a través de la comunicación interpersonal que se lleva acabo por medio de una conversación estructurada. Debe quedar claro que no basta con hacer preguntas para obtener toda la información necesaria. Es muy importante la forma en que se plantea la conversación y la relación que se establece en la entrevista. Ingeniería de software

6 Técnicas convencionales … (2)
Unidad 3 Técnicas convencionales … (2) La entrevista … Las cualidades que preferiblemente tiene que poseer el entrevistador son: Imparcial Ponderado Buen oyente, capaz de escuchar activamente (mostrando interés), adaptándose y manteniéndose al ritmo de la conversación. Cierto grado de habilidad en el trato Cordialidad y accesibilidad Paciencia Flexibilidad para tratar con una gran variedad de persona, con personalidades distintas y diferentes grados de formación y autoridad, así como con situaciones organizativas y personales. Preparación Durante esta etapa el entrevistador debe documentarse e investigar la situación de la organización, identificar las personas a las que se debe entrevistar (establecer algún orden). Otro aspecto importante es establecer el objetivo y el contenido de la entrevista, así como el lugar y la hora en que se va a desarrollar (en ocasiones se puede enviar un cuestionario previo al entrevistado). Ingeniería de software

7 Técnicas convencionales … (3)
Unidad 3 Técnicas convencionales … (3) La entrevista … Realización (Es conveniente seguir un protocolo) Apertura Se debería comenzar por presentarse e informar al entrevistado sobre la razón de la entrevista, qué se espera de él, cómo se utilizará la información, la mecánica de las preguntas, etc. Desarrollo Es recomendable no más de dos horas. Realizar preguntas abiertas, sobre todo en los primeros momentos para después pasar a otras más directas y cerradas. Una pregunta abierta no se responde con un simple “si” o “no”. Utilizar palabras y frases apropiadas. Asentir y muestras de escucha (la comunicación no son solo palabras). Repetir las respuestas dadas (moderadamente). Las pausas ejercen presión sobre el entrevistado para que hable (aplicar con mucha precaución). Lo ideal es que el 20% del tiempo hable el entrevistador, el resto el entrevistado. Tomar nota de los puntos esenciales (alguien más puede escribirlo todo). Término Se termina recapitulando la entrevista, agradeciendo su esfuerzo al entrevistado y emplazándole a una nueva cita si fuera necesaria. Se debe convencer al entrevistado de que se le ha entendido. Ingeniería de software

8 Desarrollo conjunto de aplicaciones
Unidad 3 Desarrollo conjunto de aplicaciones El JAD es una técnica para promover la cooperación y el trabajo en equipo entre usuarios y analistas. Es una alternativa a las entrevistas que consiste en un conjunto de reuniones (Workshop) con una duración total de dos a cuatro días en las que participan varios usuarios junto con los analistas. La idea es aprovechar la dinámica de grupos, toda clase de ayudas visuales de comunicación y comprensión de soluciones, un proceso de trabajo sistemático y organizado y una filosofía de documentación “Lo que ves es lo que obtienes”. Las razones que sirven de base al JAD son: Se gasta mucho tiempo en las entrevistas Preparación, desarrollo y sobre todo análisis de la información que proveen distintos entrevistados, más aún cuando caen en contradicciones. Es más difícil de apreciar posibles errores en la especificación Por lo regular solo un analista revisa el documento. En JAD todos pueden hacerlo. Promueve una participación más profunda de los usuarios en el proyecto El usuario adquiere un cierto grado de propiedad en el sistema que se construye. Ingeniería de software

9 Desarrollo conjunto de aplicaciones … (2)
Unidad 3 Desarrollo conjunto de aplicaciones … (2) El proceso típico de JAD consta de tres fases Adaptación o preparación Selección de los participantes. Lo más representativo posible de 8 a 12 de distintos niveles y áreas. Recabar una cierta información sobre el sistema a construir. Revisar documentación, entrevistas informales, etc. Organizar la reunión. De preferencia no en la empresa, fecha, ayudas audiovisuales, agenda, redactar documento de trabajo, etc. Sesión JAD Consiste en diversas reuniones bien estructuradas y organizadas partiendo del documento de trabajo. Durante la reunión se creara la especificación de requisitos. Al final de la reunión se deberá contar con un documento de especificación aprobado por todos los presentes. El jefe del JAD deberá conseguir que la reunión sea productiva y mantener el orden. Documentación Aún cuando el documento final de la sesión debería estar terminado, siempre es necesario redactar y documentar detalles, pasar a limpio, dar formato adecuado al texto o dibujos, etc. Ingeniería de software

10 Unidad 3 Prototipado Consiste en la elaboración de un modelo o maqueta del sistema que se construye para evaluar mejor los requisitos que se desea que se cumplan. Es útil cuando El área de aplicación no está bien definida, bien por su dificultad, bien por su falta de tradición en su informatización. El coste del rechazo de la aplicación por los usuario, por no cumplir sus expectativas, es muy alto. Es necesario evaluar previamente el impacto del sistema en los usuarios y en la organización. En general, para el análisis de necesidades es un medio que permite resolver ciertas cuestiones relacionadas con los usuarios como: “No se exactamente que es lo que quiero, pero lo sabré cuando lo vea”. “No se si lo quiero hasta que vea uno” Ingeniería de software

11 Unidad 3 Prototipado … (2) Se consideran tres tipos principales de prototipos, en frecuencia de uso son: Prototipo de la interfaz de usuario Para asegurarse de que está bien diseñada, que satisface las necesidades de quienes deben de usarla. En su nivel más sencillo pueden ser bosquejos en papel, en un nivel más sofisticado de autenticas simulaciones de la interfaz. Prototipado funcional Está relacionado con un ciclo de vida de varias iteraciones. En este caso, el prototipo supone una primera versión del sistema con funcionalidad limitada. A medida que se comprueba si las funciones implementadas son apropiadas, se corrigen, refinan o se añaden otras nuevas, hasta llegar al final. Modelos de rendimiento Para evaluar el posible rendimiento de un diseño técnico, especialmente en aplicaciones críticas. Estos modelos tienen un carácter puramente técnico y, por tanto, no son aplicables al trabajo de análisis de requisitos. Ingeniería de software

12 Identificación de los requerimientos

13 Especificación de los requerimientos del software
Unidad 3 Especificación de los requerimientos del software La ERS se puede definir como la documentación de los requisitos esenciales (funciones, rendimiento, diseño, restricciones y atributos) del software y de sus interfaces externos [IEEE, 1990]. La especificación debe abordar la descripción de lo que hay que desarrollar, no el cómo, el cuándo, etc. se desarrolla el software. Ello implica Describir correctamente todos los requisitos del software, pero sin incluir requisitos innecesarios (por ejemplo, aquellas funciones que no ha pedido explícitamente o implícitamente el usuario. No escribir ningún detalle del diseño del software, de su verificación o de la dirección del proyecto, excepto las restricciones impuestas al diseño que influyen en los requisitos. En definitiva se trata de especificar lo que el usuario desea sin considerar cómo se va a solucionar, aunque la ERS sí puede limitar la variedad de soluciones de diseño aceptables. Ingeniería de software

14 Características de la especificación
Unidad 3 Características de la especificación No ambigua Completa Fácil de verificar Consistente (coherente) Clasificada por importancia o estabilidad Fácil de modificar Fácil de identificación del origen y de las consecuencias de cada requisito De fácil utilización durante la fase de explotación y de mantenimiento Ingeniería de software

15 Características de la especificación … (2)
Unidad 3 Características de la especificación … (2) No ambigua Un requisito ambiguo se presta a distintas interpretaciones. Por lo regular los requisitos se describen en lenguaje natural, lo que implica un riesgo de ambigüedad. Ejemplo: “Todos los registros de un fichero serán controlados mediante un bloque de control de registro” Se quiso decir que: Un bloque controla todos los registros del fichero Cada registro tiene su propio bloque Se controla cada registro mediante un bloque, pero un bloque puede controlar más de un registro. Cada característica del producto final debe ser descrito utilizando un término único, es decir, tiene una única interpretación. Ingeniería de software

16 Características de la especificación … (3)
Unidad 3 Características de la especificación … (3) Completa Incluye todos los requisitos significativos del software, ya sean relativos a la funcionalidad, ejecución, imperativos de diseño, atributos de calidad o a interfaces externas. Define la respuesta del software a todas las posibles clases de datos de entrada y en todas las posible situaciones. Está conforme con cualquier estándar de especificación que se deba cumplir (si una sección no aplica mínimo se pone “no aplicable”). Están etiquetadas y referenciadas en el texto todas las figuras, tablas y diagramas. También deben estar definidos todos los términos y unidades de medida. En ocasiones es válido usar la frase “Por determinar” Si algunas condiciones aún no se determinan para que una situación sea resuelta (ej. Formatos de reporte). Si se tiene dependencia de algo que esta por publicarse oficialmente. Ingeniería de software

17 Características de la especificación … (4)
Unidad 3 Características de la especificación … (4) Fácil de verificar Si y solo si cualquier requisito al que se haga referencia se puede verificar fácilmente, es decir, existe algún procedimiento finito y efectivo para que una persona o máquina lo compruebe. En caso de no contar con un método para determinar si un requisito en concreto se satisface, entonces este debe ser eliminado. Consistente Si y solo si ningún requisito contradice o entra en conflicto con otro. Se pueden presentar tres tipos de conflicto: Dos o más requisitos pueden describir el mismo objeto real pero utilizan términos distintos para designarlo. Las características de los objetos reales pueden estar en conflicto. Un requisito establece que un objeto debe ser verde otro azul Puede haber conflicto lógico o temporal entre dos acciones determinadas. Un requisito establece que han de sumarse dos entradas otro que han de sumarse Ingeniería de software

18 Características de la especificación … (5)
Unidad 3 Características de la especificación … (5) Clasificada por orden de importancia o estabilidad El orden de los requisitos debe obedecer a su importancia para la aplicación o en función de su estabilidad, es decir, su resistencia a la volatilidad. Fácil de modificar Lo es si su estructura y estilo permiten que cualquier cambio necesario de requisitos se puede hacer fácil, completo y consistentemente, lo cual implica: Tener una organización coherente y manejable, con una tabla de contenidos, un índice y referencias cruzadas. No ser redundante. Un requisito solo aparece en un solo lugar. Ingeniería de software

19 Características de la especificación … (6)
Unidad 3 Características de la especificación … (6) Facilidad para identificar el origen y las consecuencias de cada requisito Establecer un origen claro para cada uno de los requisitos y hacer referencias a éstos en desarrollo o incrementos futuros de la documentación. Se recomiendan dos tipos de referencias: Hacia atrás (documentos previos). Hacia delante (documentos originados de los requisitos). Hay que darle un identificador a cada requisito. Cuando el código y los documentos son modificados, es esencial poder comprobar el conjunto total de requisitos que pueden verse afectados por tales modificaciones. Ingeniería de software

20 Características de la especificación … (7)
Unidad 3 Características de la especificación … (7) Facilidad de utilización en la fase de explotación y mantenimiento Está característica es importante sobre todo por dos razones Si quien hace el mantenimiento no estuvo involucrado en el desarrollo del producto de software y se requieren cambios más profundos que simplemente código y diseño detallado. Gran parte de los conocimientos y de la información necesaria para el mantenimiento se dan por supuestos durante el desarrollo, sin embargo suelen estar ausentes durante el mantenimiento. Si no se entiende la razón del origen de una función es prácticamente imposible desarrollar el mantenimiento. Ingeniería de software

21 Estructura de la especificación
Unidad 3 Estructura de la especificación Estándar IEEE Std. 830 [IEEE, 1998] Ingeniería de software

22 Estructura de la especificación … (2)
Unidad 3 Estructura de la especificación … (2) Existen otras formas de estructurar una Especificación [Sommerville, 1995] Introducción. Describe la necesidad de crear el sistema y cuales son sus objetivos. Glosario. Define los términos técnicos usados. Modelos del Sistema. Define los modelos que muestran los componentes del sistema y las relaciones entre ellos. Definición de Requerimientos Funcionales. Define los servicios que serán proporcionados. Definición de Requerimientos No-funcionales. Definir las limitantes del sistema y el proceso de desarrollo. Evolución del Sistema. Definir las suposiciones fundamentales en las cuales el sistema se basa y se anticipan los cambios. Especificación de Requerimientos. Especificación detallada de los requerimientos funcionales del sistema. Apéndices. Descripción de la plataforma de Hardware del Sistema. Requerimientos de la base de Datos (quizá como un modelo ER) Índice. Ingeniería de software

23 Métodos estructurados
Unidad 3 Métodos estructurados Algunas características Son métodos clave en el desarrollo estructurado o convencional Facilitan el flujo de información durante el desarrollo del sistema Entre el análisis y el diseño Entre usuarios y analistas Son sencillos y fáciles de aprender, aparecieron a finales de los 70s y desde entonces han tenido una amplia difusión. Principal mente se utilizan: Diagramas de flujo de datos (DFD) Diccionario de datos (DD) Especificación de procesos Ingeniería de software

24 Diagramas de flujo de datos
Unidad 3 Diagramas de flujo de datos Los DFD se utilizan para realizar el modelo funcional del sistema La simbología (notación) Yourdon/De Marco es la siguiente: P Proceso Transformaciones o procesos (funciones, cálculo, selección) Entidad Externa Información de entrada 1 Proceso Datos intermedios Entidad Externa Terminadores (Fuentes o Destinos) (personas, entidades) 3 Proceso Entidad Externa Datos intermedios Datos intermedios Flujo de datos Flujos de información (inputs-outputs) 2 Proceso 4 Proceso Información de salida Información de entrada Información de salida Ficheros o depósitos temporales de información (base de datos, clasificador, etc.) Entidad Externa Entrada en Almacenamiento Salida del Almacenamiento D ALMACÉN DE DATOS Entidad Externa D1 ALMACENAMIENTO Ingeniería de software

25 Diagramas de flujo de datos … (2)
Unidad 3 Diagramas de flujo de datos … (2) Reglas básicas Procesos Solo se usan para transformaciones (cálculos), filtros (verificaciones) y distribución (menú). Nombres únicos y significativos (verbo + objeto, ej. Aceptar pago). Flujos Toda flecha debe estar etiquetada Pueden representar uno o más datos (son datos y por tanto hay que nombrarlos como datos). En los flujos de datos interactivos se puede utilizar la doble flecha. Solo los procesos separan flujos, sin embargo se puede considerar desmenuzar la información que llega a distintos procesos por legibilidad (flechas divergentes). Un flujo que entra a un proceso no puede salir intacto. Almacenes de datos Nombres únicos, significativos y concisos Si sale un flujo del almacén Puede no llevar etiqueta si se refiere a un paquete (registro) completo. Lleva etiqueta con el mismo nombre del almacén si se refiere a uno o más registros. Lleva etiqueta con diferente nombre del almacén si se refiere a uno o más componentes (atributos) de un registro El nombre debe ser congruente con el modelo E-R Entidades externas Por lo regular solo aparecen en un primer nivel de DFD Ingeniería de software

26 Diagramas de flujo de datos … (3)
Unidad 3 Diagramas de flujo de datos … (3) P Validar código postal Reglas … (ejemplos) Flechas divergentes Código postal Flujos de datos interactivos P Validar teléfono Dirección del cliente Pago Teléfono P Aceptar Pago Autorización de crédito P Analizar Petición de crédito Denegación de crédito Calle Solicitud de crédito P Validar Calle Recibo Cuando un flujo o más de uno entran a un proceso quiere decir que: ¿El proceso pide el flujo de datos? ¿El proceso necesita todos los flujos que entran? La respuesta es “No se sabe y no importa!!” Los aspectos procedurales no se manifiestan en los DFD Si tales aspectos son realmente importantes se deben incluir en las miniespecificiaciones Ingeniería de software

27 Diagramas de flujo de datos … (4)
Unidad 3 Diagramas de flujo de datos … (4) Jerarquía de DFD’s El primer DFD de la jerarquía es el de nivel 0, también llamado diagrama de contexto. Representa al elemento de software completo como un solo macroproceso con datos de entrada y datos de salida provenientes desde y hacia las entidades externas. El siguiente nivel en la jerarquía es el de nivel 1 Por lo regular se compone de más de tres (5 o 6) procesos (numerados) interconectados por flujos. Cada uno de los procesos de este nivel representa una subfunción del sistema general (diagrama de contexto). Los siguientes niveles son una refinación del nivel anterior. Cada proceso tiene asociado un número único que lo identifica en función de su situación jerárquica. Se debe mantener la continuidad de los flujos en la jerarquía, es decir, la entrada y la salida de cada refinamiento debe ser la misma (balanceo). Un flujo puede ser separado en sus componentes en el siguiente refinamiento. El refinamiento termina con procesos primitivos, los cuales pueden ser llevados a una miniespecificación. Ingeniería de software

28 Diagramas de flujo de datos … (5)
Unidad 3 Diagramas de flujo de datos … (5) DFD de contexto Usuario Pantalla Sistema de Graficación 3D Sentencias Comandos Mensajes Vistas Ejemplo: El Software de graficación 3D debe permitir al usuario procesar sentencias de texto para la edición de objetos geométricos. Tener la capacidad de procesar comandos vía componentes gráficos para realizar diversas tareas. Un elemento muy importante en el sistema es un almacén de objetos 3D, del cuál se pueden recuperar objetos previamente editados y, obviamente, se pueden almacenar nuevos objetos. También es importante contar con un archivo de configuración del sistema. Al cambiar la configuración del sistema o editar objetos se debe actualizar la visualización de lo presentado en pantalla. Es importante que tanto para los comandos como para las sentencias se emitan mensajes de error o confirmación según corresponda. DFD nivel 1 1 Procesar Sentencias Sentencias Mensajes Archivo de configuración del sistema Información 3D Datos de configuración Datos de configuración 2 Procesar Comandos Opciones de configuración 3 Configurar Sistema Comandos Objetos 3D recuperados Lista de Objetos 3D Activos Lista de Objetos 3D Datos de configuración 4 Recuperar Objetos 3D 5 Almacenar Objetos 3D 6 Actualizar Visualización Vista Actualizada Ingeniería de software Almacén de objetos 3D

29 Diagramas de flujo de datos … (6)
Unidad 3 Diagramas de flujo de datos … (6) DFD del proceso 1 (nivel 2) Ejemplo … (continuación) Para procesar una sentencia primero se debe validar, si es válida se procede a su ejecución y en caso de no serlo se debe emitir el correspondiente mensaje de error. En lo que respecta a los comandos, se tienen peticiones para: mostrar una lista de objetos 3D en edición (activos), para cargar un objeto 3D almacenado, almacenar objetos 3D activos y para mostrar el menú de configuración. 1.1 Validar Sentencia Sentencia Válida 1.2 ejecutar Sentencia Sentencias Información 3D Mensaje de error Mensaje de confirmación DFD del proceso 2 (nivel 2) Petición de lista de objetos 3D 2.1 Mostrar lista de objetos 3D activos Información 3D Objetos 3D modificados 2.5 Actualizar lista objetos 3D activos Lista de objetos 3D activos Petición de carga de objetos 3D 2.2 Cargar un objeto 3D almacenado Objeto 3D Objetos 3D recuperados Comandos Petición de Almacenar objetos 3D 2.3 Mostrar pantalla para almacenar Lista de objetos 3D a almacenar Archivo de configuración del sistema 2.4 Mostrar menú de configuración Petición de configuración Ingeniería de software Opciones de configuración

30 Diagramas de flujo de datos … (7)
Unidad 3 Diagramas de flujo de datos … (7) Ampliaciones para sistemas de tiempo real [Ward y Mellor, 1985] La notación básica es adaptada para las siguientes demandas impuestas por los sistemas de tiempo real: Flujo de información que es recogido o producido de forma continua en el tiempo Información de control que pasa por el sistema y el procesamiento de control asociado Flujo de datos continuo P Ajustar velocidad Cantidad de voltaje requerido Tren de pulsos Flujo de control Velocidad deseada Activación del ajuste P P Mover el robot P Controlar velocidad Orden del operador Indicador de inicio del control Proceso de control Ingeniería de software

31 Unidad 3 Diccionario de datos Es la información relevante relacionada con cada uno de los datos identificados durante el análisis. Los objetivos del Diccionario de datos (DD) son: Generar un glosario de términos Establecer una metodología estándar Proporcionar referencias cruzadas Proporcionar un control centralizado para los cambios Son candidatos potenciales a aparecer en el DD Flujos de datos Almacenes Procesos Entidades externas Y cualquier cosa que el analista considere conveniente. Ingeniería de software

32 Diccionario de datos … (2)
Unidad 3 Diccionario de datos … (2) Información requerida para cada elemento del DD Nombre Tipo de elemento Breve descripción Sinónimos Observaciones Además, cuando se requiera, de: Frecuencias y fechas, volúmenes, referencias, cuellos de botella, valores mínimos y máximos, rangos de valores permitidos y clase, miniespecificaciones para procesos, referencias cruzadas, usuarios afectados, y cualquier información que se considere de interés. La implementación del DD puede realizarse Manualmente En un procesador de textos Utilizando una BD Ingeniería de software

33 Diccionario de datos … (3)
Unidad 3 Diccionario de datos … (3) Descomposición top-down de datos A = B + C B = B1 + B2 C = C1 + C2 + C3 Por ejemplo la descomposición se puede dar en: Almacenes en archivos, archivos en registros. Flujos en subflujos. Estructuras de datos en datos elementales. Ingeniería de software

34 Diccionario de datos … (4)
Unidad 3 Diccionario de datos … (4) El diccionario de datos utiliza un conjunto de operadores = es equivalente a + y [ ] , | o exclusivo (solo una de las opciones) 1{ }N iteraciones entre 1 y N veces ( ) opcional * … * comentarios @ identificador de campo clave en almacén Ejemplos: Etiqueta = 1{caracter}8 *solo letras* Persona + nombre + apellidos + [n°prof | n°alum ] + (edad) Ingeniería de software

35 Diccionario de datos … (5)
Unidad 3 Diccionario de datos … (5) Ejemplo DD Nombre: Comandos Sinónimos: Eventos de interfaz Tipo: Flujo de datos Composición: [ Petición-de-Lista-de-Objetos3D | Petición-de-Carga-de-Objetos3D | Petición-de-Almacenar-Objetos3D | Petición-de-Configuración] Observaciones: *Las peticiones son iniciadas mediante un elemento de la Interfaz que pudiera ser un botón o un elemento del menú* Nombre: Objeto activo Sinónimos: Objeto 3D Tipo: Elemento de datos + nombre + color + (textura) + tipo + 1{vértice}N Observaciones: *Todos los objetos activos y no activos deben tener la misma composición* Ingeniería de software

36 Especificación de procesos
Unidad 3 Especificación de procesos La especificación del proceso (mini-especificación o EP) es la descripción de lo que sucede en cada proceso primitivo del nivel más bajo de un DFD. Su propósito es describir lo que se debe hacer para transformar las entradas en salidas desde el enfoque del usuario. Algunas de las herramientas principales para la especificación de procesos son: Lenguaje estructurado Tablas de decisión Pre y post condiciones Ingeniería de software

37 Especificación de procesos … (2)
Unidad 3 Especificación de procesos … (2) Lenguaje estructurado Es un subconjunto del idioma (español, inglés, etc.) con importantes restricciones sobre el tipo de frases que pueden utilizarse y la manera en que puedan juntarse dichas frases. Se debe utilizar: Verbos imperativos (dividir, calcular, validar, fijar, etc.) Términos utilizados en el DD Palabras reservadas (preferentemente en mayúsculas) Sintaxis de programación estructurada Estructuras secuenciales Estructuras de selección Estructuras de repetición Desventaja El analista puede caer en una especificación demasiado compleja para ser entendida y verificada por el usuario, de ser así la especificación falló. Ingeniería de software

38 Especificación de procesos … (3)
Unidad 3 Especificación de procesos … (3) Lenguaje estructurado … Algunos consejos útiles son: Restringir la especificación de proceso a no más de una página de texto, de ocuparse más de una página el proceso debe descomponerse en otro nivel más. No más de tres niveles de anidamiento en las estructuras selectivas y/o repetitivas. Utilizar sangría apropiada para los anidamientos Ejemplo: COMIENZA Objeto 3D = ninguno Recuperar todos los Objetos 3D del Almacén de objetos 3D SI hay Objetos 3D recuperados Crear una Ventana de listado con el identificador y nombre de cada uno de los Objetos 3D recuperados Permitir buscar y seleccionar uno de ellos. Al seleccionar un Objeto 3D de la lista hacer Objeto 3D = Objeto 3D seleccionado y mostrar la vista preliminar del Objeto 3D SINO Mostrar Menaje gráfico “Cero Objetos 3D recuperados” EVIAR Objeto 3D TERMINA Petición de carga de objetos 3D 2.2 Cargar un objeto 3D almacenado Objeto 3D Objetos 3D recuperados Ingeniería de software

39 Especificación de procesos … (4)
Unidad 3 Especificación de procesos … (4) Tablas de decisión Se utilizan cuando el proceso debe producir alguna salida o tomar alguna acción basada en decisiones complejas. Principalmente útiles cuando las decisiones se basan en diversas variables distintas y dichas variables pueden tomar diversos valores. Pre y Post condiciones Son útiles cuando el analista está razonablemente seguro de que existen muchos algoritmos distintos que podrían utilizarse. Las pre - condiciones describen todas las cosas que deben darse antes de que el proceso pueda comenzar a ejecutarse. Las post- condiciones describen lo que debe darse cuando el proceso ha concluido. Ingeniería de software

40 Revisión de la especificación estructurada
Unidad 3 Revisión de la especificación estructurada Realizada la especificación estructurada (formada por el conjunto de DFD’s, el DD y las EP) se debe revisar. Se deben tomar como base cuatro aspectos: Compleción Si los modelos de la EE son completos. Integridad Si no existen contradicciones ni inconsistencias entre los distintos modelos. Exactitud Si los modelos cumplen con los requisitos del usuario Calidad El estilo, la legibilidad y la facilidad de mantenimiento de los modelos producidos. Ingeniería de software

41 Revisión de la especificación estructurada … (2)
Unidad 3 Revisión de la especificación estructurada … (2) Una técnica empleada en la revisión es la lista de comprobación. Se trata de una lista de preguntas sencillas con dos tipos de respuestas posibles, sí o no. Ingeniería de software

42 Métodos orientados a objetos
Unidad 3 Métodos orientados a objetos De los diferentes enfoques para el desarrollo orientado a objetos el Proceso Unificado (UP) es el mayor uso. Los modelos creados en los diferentes workflow del UP utilizan la notación UML. En el UP el análisis de los requisitos del software parte del workflow de requisitos y concluye con el workflow del análisis. La técnica utilizada en el workflow de los requisitos, y en general de la mayor parte de las metodologías orientadas al objeto es: Casos de uso El workflow del análisis hace uso de otros modelos UML Modelo de clases Diagramas de interacción Diagramas de estados Diagramas de actividad Ingeniería de software

43 Unidad 3 Casos de uso Inicio Un primer diagrama utilizado en la elaboración de modelos de negocios, dentro del workflow de los requisitos, es el caso de uso. Un caso de uso modela la interacción entre el sistema de información y los usuarios de éste. Un diagrama de casos de uso es un conjunto de casos de uso, donde cada uno de ellos describe una forma particular de usar el sistema. Obtener una comprensión inicial del dominio Construir un modelo inicial de negocios Preparar un conjunto inicial de requisitos ¿Los requisitos son Satisfactorios? Sí Fin No Obtener una comprensión más profunda del dominio Refinar el modelo de negocios Refinar el conjunto de requisitos Ingeniería de software Diagrama del workflow de los requisitos [Schach, 2004]

44 Unidad 3 Casos de uso … (2) Los casos de uso son ideas simples y prácticas que no requieren muchas habilidades tecnológicas para ser utilizadas. Por el contrario, si se volvieran muy complejas se perdería su utilidad. En esencia un modelo de caso de uso se puede visualizar como un grafo con dos tipos de nodos: Actores Representa cualquier cosa que intercambia información con el sistema, por lo que se encuentra fuera de éste. Caso de uso Constituye un flujo completo de eventos, que especifican la interacción que toma lugar entre el actor y el sistema desde el punto de vista del usuario (cliente). Ingeniería de software

45 Casos de uso que muestran la relación con los actores
Unidad 3 Casos de uso … (3) Actores Más que simplemente representar usuarios, representan cierta función que una persona realiza. Además representan cualquier entidad externa que intercambia información con el sistema Personas físicas Sistemas externos Bases de datos Para especificar los actores de un sistema, se dibuja un diagrama correspondiente a la delimitación del sistema, la cual representa al sistema como “caja negra” y a los actores como entidades externas a ésta. Casos de uso Después de haber definido a los actores del sistema, se establece la funcionalidad propia del sistema por medio de casos de uso. Se puede ver cada caso de uso como si representara un estado en el sistema, donde un estímulo enviado entre un actor y el sistema ocasiona una transición entre estados. Delimitación del sistema según los actores Casos de uso que muestran la relación con los actores Ingeniería de software

46 Unidad 3 Casos de uso … (4) Las relaciones entre actores y casos de usos pueden ser de tres tipos Extiende Especifica como un caso de uso puede insertarse en otro para extender la funcionalidad. La extensión representa un conjunto adicional de pasos sobre lo que en otros casos se resuelve en un solo paso. Incluye Especifica que una sección de un caso de uso es parte obligatoria de otro caso de uso. Representa la relación que se da cuando un caso de uso incluye el comportamiento de otro caso de uso. Generalización Permite representar la especialización de un caso de uso, aunque también puede utilizarse para especializar actores. Apoya la reutilización de los casos de uso y da origen a casos de uso abstractos y casos de uso concretos. Ingeniería de software

47 Casos de uso … (5) Ejemplos de relaciones Unidad 3
Ingeniería de software

48 Unidad 3 Casos de uso … (6) Ejemplo: sistema de reservaciones de vuelo [Weitzenfeld, 2005] Ingeniería de software

49 Unidad 3 Casos de uso … (7) La construcción del modelo de casos de uso es un proceso iterativo en el que se recomiendan seguir estos pasos: Identificar casos: Identificar límites del sistema y actores Utilizar técnicas de observación y entrevistas Identificar los casos de uso analizando el comportamiento de cada actor Se sugieren resolver preguntas como: ¿Cuáles son las principales tareas de cada actor? ¿Escribe/lee/modifica el actor alguna información del sistema? Descripción y estructuración de casos: Descripción completa de cada caso Debe ser concebida desde el punto de vista de un actor determinado. No debe ser pequeña. Estructurar los casos detectando sus relaciones (incluye, extiende y generalización) Las relaciones incluye suelen resultar de secuencias comunes de diferentes formas de uso, mientras que las extiende suelen resultar al introducir nuevas secuencias. Documentar el diagrama de casos Parte fundamental del modelo de casos de uso. Se documentan de forma textual (utilizando lenguaje natural en base a una plantilla). Ingeniería de software

50 Casos de uso … (8) Plantillas [Weitzenfeld, 2004] [Durán, 2000]
Unidad 3 Casos de uso … (8) Plantillas [Weitzenfeld, 2004] [Durán, 2000] Ingeniería de software

51 Unidad 3 Casos de uso … (9) Ejemplo: Ingeniería de software

52 Unidad 3 Modelo de clases Un punto clave en el paradigma orientado a objetos es el workflow del análisis ya que en éste es cuando se extraen las clases. En un primer paso se trata de definir un modelo de clases común, del dominio del problema, tanto para los analistas como para el cliente. Sin embargo, la identificación de clases y objetos es una tarea complicada en la que se debe tener especial cuidado, se debe garantizar que se esta hablando de lo mismo . Ingeniería de software

53 Unidad 3 Modelo de clases … (2) Un concepto importante en la identificación de las clases son las Abstracciones clave Son clases u objetos que forman parte del domino del problema Primero se buscan Dependiendo de las características del dominio del problema y con apoyo de los expertos en tal dominio. Si es posible se inventan nuevas abstracciones posiblemente útiles en el diseño o implementación. Es recomendable seguir escenarios para guiar el proceso de identificación Después se refinan Identificar las clases según estereotipos en Borde Entidad Control Las clases y objetos deben estar en un nivel de abstracción adecuado: ni demasiado alto, ni demasiado bajo Ingeniería de software

54 Unidad 3 Modelo de clases … (3) Búsqueda e identificación de clases y objetos del dominio del problema Las clases y objetos se obtienen principalmente de un documento textual que describa el sistema y apoyándose en el modelo de casos de uso. Se recomienda hacer lo siguiente: Identificar clases candidatas explicitas o implícitas Selección y clasificación de clases en: relevantes, redundantes, imprecisas, irrelevantes, clases que resultan atributos, pantallas, operaciones, actores o el sistema completo. Identificar asociaciones Identificar los atributos Construir el diccionario de clases La clasificación es el medio por el cual ordenamos el conocimiento Ingeniería de software

55 Unidad 3 Modelo de clases … (4) Consideraciones para identificar las clases candidatas Subrayar todos los sustantivos en la descripción del problema. Identificar entidades físicas al igual que las conceptuales No tratar de diferenciar entre clases y atributos Añadir aquellas clases que se identifique de forma implícita según el conocimiento que se tenga del área. No tomar en cuenta conceptos como herencia o polimorfismo. En resumen, todos lo sospechoso de ser una clase candidata será una clase candidata. Consideraciones para seleccionar las clases relevantes Todas las clases deben tener sentido en el área de aplicación, la relevancia del problema debe ser el único criterio para la selección. Los nombres de las clases no deben ser ambiguos ni en plural. En esta fase aún no se debe considerar asociación, agregación o herencia. Ante la duda, la clase se conserva, posteriormente puede ser eliminada. Eliminar clases irrelevantes con cuidado en función del contexto. Clarificar clases imprecisas. Eliminar clases que pueden ser atributos más que clases Suprimir clases que correspondan a actores del sistema Agregar clases implícitas Ingeniería de software

56 Nombre del objeto: Nombre de la clase
Unidad 3 Modelo de clases … (5) En UML las clases se describen por medio del diagrama de clases. La notación para una clase es una caja rectangular, que contiene el nombre de la clase. La notación general para un objeto se extiende mediante el nombre de la clase subrayado seguido del nombre del objeto. Notación para una clase Notación para las clases Persona y Universidad Nombre de la clase Persona Universidad Notación para un objeto que Incluye el nombre de la clase Notación para un objeto Pancho Villa que incluye el nombre de la clase Nombre del objeto: Nombre de la clase Pancho Villa: Persona Ingeniería de software

57 Unidad 3 Modelo de clases … (6) En un diagrama de clases expresado en UML es posible modelar: Atributos Atributos básicos Atributos derivados Restricciones para atributos Métodos Ligas y asociación Asociaciones reflexivas Multiplicidad Rol Restricciones Atributos y operaciones Ensamblados Composición Agregación Generalización y herencia Módulos Estereotipos Diagrama de clases para Personas trabajando en Compañías [Weitzenfeld, 2004]. Ingeniería de software

58 Modelo de clases … (7) Clases con estereotipos
Unidad 3 Modelo de clases … (7) Clases con estereotipos El tipo de funcionalidad o “la razón de ser” de un objeto dentro de una arquitectura se conoce como su estereotipo. El modelo del análisis se basa en tres estereotipos: Entidad Para los objetos que guardan información sobre el estado interno del sistema a corto y largo plazo. Corresponden al dominio del problema, ej. Clase forma. Borde Para objetos que implementan interfaces con el mundo externo, correspondientes a todos los actores. Ej. Interfaces de usuario o pantallas. Control Para objetos que implementan el comportamiento o control de la lógica de los casos de uso, especificando cuándo y cómo el sistema cambia de estado. Modelan la funcionalidad que no se asocia naturalmente al objeto, ej. Clase manejador principal. Notación para una clase con estereotipo <<Estereotipo>> Nombre de la clase Extensiones de UML para representar estereotipos Entidad Borde Control Ingeniería de software

59 Diagramas de secuencias
Unidad 3 Diagramas de secuencias Identificadas las clases, hay que describir la interacción entre ellas para modelar la funcionalidad del sistema. Los diagramas de secuencias (interacción o de eventos) se utilizan para describir la interacción o eventos enviados entre los objetos resultantes del análisis. Estos diagramas, a diferencia de los diagramas de clase, describen los aspectos dinámicos de un sistema, por tal motivo se utiliza la notación extendida para objetos. Características del diagrama: Cada objeto es representado con una línea vertical, correspondiente al eje del tiempo. El tiempo avanza hacia abajo. Muestra los eventos, en el tiempo, enviados de un objeto a otro. Se utilizan barras gruesas sobre los ejes para denotar actividad en el objeto. El orden y la distancia entre los objetos no importa Lo importante son las consecuencias del envío de un evento Ingeniería de software

60 Diagramas de secuencias … (2)
Unidad 3 Diagramas de secuencias … (2) En el siguiente diagrama las barras gruesas corresponden a actividades del objeto, denominadas por a, mientras que las flechas corresponden a eventos, denominados por e. Un evento se dibuja como una flecha horizontal que comienza en la barra del objeto que lo envía y termina en la barra del objeto que lo recibe. Las actividades se inician por el arribo de eventos y el tiempo que duran es solo relevante para resaltar eventos posteriores originados durante esa actividad. Ingeniería de software

61 Diagramas de secuencias … (3)
Unidad 3 Diagramas de secuencias … (3) Diagrama de secuencias Crear Registro del caso de uso Registrar usuario. Ingeniería de software

62 Unidad 3 Diagramas de estados Se utilizan para tener una perspectiva de control, no solo funcional y de datos, del sistema. Modelan el comportamiento de un objeto ante la aparición de un conjunto de eventos. El comportamiento es representado como un conjunto de secuencias de estados que puede tomar un objeto ante la respuesta de eventos durante su ciclo de vida. Cuando sucede un evento se realiza una determinada actividad, dependiendo del estado del objeto. Ingeniería de software

63 Diagramas de estados … (2)
Unidad 3 Diagramas de estados … (2) Elementos del diagrama Estados Condición o situación durante el ciclo de vida de un objeto en el que satisface alguna condición, realiza alguna actividad o espera algún evento. Estados compuestos Permiten la generalización y agregación de estados para simplificar los diagramas. Transiciones Es una relación entre dos estados que indica que un objeto en el primer estado realizará ciertas acciones y entrará en el segundo estado cuando suceda un conjunto de eventos y se cumplan un conjunto de condiciones especificadas. Eventos Es la aparición de un suceso que puede disparar una transición. Ingeniería de software

64 Diagramas de estados … (3)
Unidad 3 Diagramas de estados … (3) Un estado se define por: Nombre Cadena de texto que distingue el estado de otros estados. Transiciones internas Suceden dentro del estado sin que suponga un cambio del estado del mismo. Dentro del estado se describen las acciones internas o actividades que se realizan cuando un elemento está en el estado, (entrada, proceso o salida). Subestados La estructura anidada de un estado, incluyendo los subestados disjuntos o concurrentes. Eventos diferidos Es una lista de eventos que no es manejada en este estado, dichos eventos son encolados para que los maneje otro objeto en otro estado. Se tienen dos estados especiales Estado inicial Lugar de comienzo por defecto para la máquina de estados Estado final Representa el fin de la ejecución de la máquina de estado Diagrama de estados para la clase persona Ingeniería de software

65 Diagramas de estados … (4)
Unidad 3 Diagramas de estados … (4) Estados compuestos Reducen la complejidad Se da origen a superestados y subestados Ingeniería de software

66 Diagramas de estados … (5)
Unidad 3 Diagramas de estados … (5) Para definir una transición es necesario Un estado de partida Es el estado afectado por la transición. Un evento de disparo Es un evento cuya recepción por el objeto en el estado de partida le permite disparar si se cumple una cierta condición de guarda Condición de guarda Es una expresión booleana que se evalúa cuando se dispara la transición ante la aparición de un evento de disparo. Si la condición se cumple, la transición se dispara, y si no el evento se pierde. La existencia de esta condición es opcional. Acción Es una operación atómica ejecutable que puede actuar directamente sobre el objeto u otros objetos visibles al objeto en cuestión. Estado destino El estado que está activo después de la activación de la transición Ingeniería de software

67 Diagramas de estados … (6)
Unidad 3 Diagramas de estados … (6) Tipos de eventos Evento de cambio Un evento de cambio surge cuando se satisface una condición, normalmente descrita por una expresión booleana. Ejemplo: when (stock_producto > 0) el evento sucede cuando la expresión es verdadera. Esta condición no es una condición de guarda. Evento de señal Recepción de una señal explicita de un objeto a otro. Se refleja por la signatura del evento como un disparo en una transición. Evento de tiempo Paso de cierto periodo de tiempo. Se utiliza una expresión temporal. Ej. After(10 segundos). Ingeniería de software

68 Diagramas de estados … (7)
Unidad 3 Diagramas de estados … (7) El siguiente ejemplo muestra el diagrama de estado inicial de un sistema que ofrece un menú de acciones a realizar. Ingeniería de software

69 Diagramas de actividad
Es una variante de la máquina de estado donde los estados representan la ejecución de actividades o tareas y las transiciones sólo se disparan cuando éstas finalizan. Se puede ver como una especialización del diagrama de estados pero organizado respecto de las acciones. Las actividades se enlazan por transiciones automáticas. Cuando una actividad termina se desencadena el paso a la siguiente actividad.

70 Diagramas de actividad … (2)
Componentes Estado de acción Representa una tarea con una acción de entrada y como mínimo una transición de salida. Estado de subactividad Representa un nuevo diagrama de actividad. Permite anidamientos para mejorar la legibilidad. Decisiones Se utilizan conjuntamente con las condiciones de guarda para indicar transiciones diferentes. Separadores Organizan el diagrama en función de responsabilidades Condiciones de guarda Expresiones booleanas asociadas a las transiciones. Barras de sincronismo Se utilizan para representar el sincronismo de actividades que se pueden utilizar en paralelo Transiciones Reflejan el camino de cambio de estado o separador a un nuevo estado o separador. Estados de inicio y final El estado de inicio siempre es obligatorio, no así el estado final

71 Diagramas de actividad … (3)
Ejemplos: