Ingeniería de Software
Unidad 3
Análisis de requerimientos del software
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 830-1993) 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
Unidad 3
Ingeniería de software
“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]
1. Lo que el director desea. 2. Como lo define el director deproyecto.
3. Como se diseña el Sistema.
4. Como lo desarrolla elprogramador.
5. Como se ha realizado lainstalación.
6. Lo que el usuario quería.
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.
Unidad 3
Ingeniería de software
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.
Unidad 3
Ingeniería de software
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.
Unidad 3
Ingeniería de software
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).
Unidad 3
Ingeniería de software
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.
Unidad 3
Ingeniería de software
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.
Unidad 3
Ingeniería de software
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.
Unidad 3
Ingeniería de software
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”
Unidad 3
Ingeniería de software
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.
Unidad 3
Ingeniería de software
Identificación de los requerimientos Antes de que los requisitos puedan ser analizados, modelados o
especificados, deben ser recopilados a través de un proceso de obtención.
Este proceso de obtención puede llevarse a cabo mediante una de las técnicas de recolección de información: Entrevista Observación Estudio de la documentación Cuestionarios Tormenta de ideas Desarrollo conjunto de aplicaciones Prototipado
Identificación de los requerimientos … (2)
En una primera fase se debe identificar: El problema a resolver en un nivel básico La solución que el cliente busca Los beneficios que el cliente espera Los participantes que tienen interés en construir el software Alternativas de solución
En fases posteriores se debe identificar: Cuál de las alternativas de solución el cliente considera idónea o
más completa El problema con un mayor nivel de profundidad Propiedades y comportamiento del sistema Las restricciones y alcances del sistema
Al identificar los requerimientos es de gran importancia corroborar con el cliente que lo que hemos entendido es lo que él quiere.
Identificación de los requerimientos … (3)
Tipos de requisitos a identificar Requisitos funcionales
Describen los servicios (funciones) que se esperan del sistema Ej:
El sistema aceptará pagos con VISA Requisitos no funcionales
Se trata de restricciones sobre los requisitos funcionales Ej:
El sistema aceptará pagos con VISA de forma segura y con un tiempo de respuesta no menor a 5 segundos
Distinguir entre requisitos funcionales y no funcionales depende del contexto de la solución.
Requisitos en Negativo Limitan el ámbito del sistema Dicen donde no se deben emplear recursos
Identificación de los requerimientos … (4)
Dado que la identificación de requisitos es una actividad más “humana” que técnica se pueden presentar algunos problemas: Los usuarios no encuentran la forma de describir
apropiadamente una cantidad considerable de sus tareas.
Mucha información importante a veces no se menciona.
En sistemas orientados a un número muy grande de personas se tienen que “intuir” algunos requisitos.
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.
Unidad 3
Ingeniería de software
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
Unidad 3
Ingeniería de software
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.
Unidad 3
Ingeniería de software
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.
Unidad 3
Ingeniería de software
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
Unidad 3
Ingeniería de software
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.
Unidad 3
Ingeniería de software
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.
Unidad 3
Ingeniería de software
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.
Unidad 3
Ingeniería de software
Estructura de la especificación Estándar IEEE Std. 830 [IEEE, 1998]
Unidad 3
Ingeniería de software
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.
Unidad 3
Ingeniería de software
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
Unidad 3
Ingeniería de software
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:
PProceso
Entidad Externa
D ALMACÉN DE DATOS
Flujo de datos
Transformaciones o procesos (funciones, cálculo, selección)
Terminadores (Fuentes o Destinos)(personas, entidades)
Flujos de información (inputs-outputs)
Ficheros o depósitos temporales de información (base de datos, clasificador, etc.)
1Proceso
Entidad Externa Información
de entrada
3Proceso
Datosintermedios
2Proceso
Entidad Externa
Informaciónde entrada
Datosintermedios
4Proceso
Datosintermedios
D1 ALMACENAMIENTO
Entrada enAlmacenamiento
Salida delAlmacenamiento
Entidad Externa
Entidad Externa
Informaciónde salida
Informaciónde salida
Unidad 3
Ingeniería de software
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 Nombres únicos, significativos y concisos Por lo regular solo aparecen en un primer nivel de DFD
Unidad 3
Ingeniería de software
Diagramas de flujo de datos … (3) Reglas … (ejemplos)
Flujos de datos interactivos
PAceptar
Pago
PAnalizarPetición
de crédito
Autorización de crédito
Solicitud decrédito
Pago
Recibo
Denegaciónde crédito
Flechas divergentes
Direccióndel cliente
Códigopostal
Teléfono
Calle
PValidar código
postal
PValidarteléfono
PValidarCalle
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
Unidad 3
Ingeniería de software
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.
Unidad 3
Ingeniería de software
Diagramas de flujo de datos … (5) 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.
Usuario Pantalla
Sistemade
Graficación3D
Sentencias
Comandos
Mensajes
Vistas
Sentencias
1
Procesar
Sentencias
Mensajes
Información 3D
2
Procesar
Comandos
Comandos
Archivo de configuracióndel sistemaDatos de
configuración
3
Configurar
Sistema
Datos de configuración
Opciones deconfiguración
4
Recuperar
Objetos 3D
Objetos 3Drecuperados
Almacén de objetos 3D
5
Almacenar
Objetos 3D
Lista deObjetos 3D
6
Actualizar
Visualización
Lista deObjetos 3D Activos Datos de
configuración
VistaActualizada
DFD de contexto
DFD nivel 1
Unidad 3
Ingeniería de software
Diagramas de flujo de datos … (6) 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.
DFD del proceso 1 (nivel 2)
1.1
Validar
Sentencia
Sentencias
Mensaje de error
SentenciaVálida
1.2
ejecutar
Sentencia
Mensaje de confirmación
Información 3D
DFD del proceso 2 (nivel 2)
2.1Mostrar listade objetos3D activos
2.2Cargar unobjeto 3D
almacenado
2.3
Mostrar pantalla para
almacenar
2.4
Mostrar menú de
configuración
2.5Actualizar
lista objetos3D activos
Archivo de configuracióndel sistema
Comandos
Petición delista deobjetos 3D
Petición de cargade objetos 3D
Petición de Almacenarobjetos 3D
Petición deconfiguración
Objeto 3D
Objetos 3Dmodificados
Información 3D
Lista de objetos3D activos
Objetos 3Drecuperados
Opciones de configuración
Lista de objetos3D a almacenar
Unidad 3
Ingeniería de software
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
PProceso
de control
Flujo de datoscontinuo
Flujo de control
P
Ajustar
velocidad
P
Controlar
velocidad
P
Mover
el robot
Orden del operador
Indicador de iniciodel control
Activación delajuste
Velocidaddeseada
Tren de pulsosCantidad devoltaje requerido
Unidad 3
Ingeniería de software
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.
Unidad 3
Ingeniería de software
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
Unidad 3
Ingeniería de software
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.
Unidad 3
Ingeniería de software
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 = @n°ss + nombre + apellidos + [n°prof | n°alum ]
+ (edad)
Unidad 3
Ingeniería de software
Diccionario de datos … (5)
Ejemplo DD
Nombre: ComandosSinónimos: Eventos de interfazTipo: Flujo de datosComposició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 activoSinónimos: Objeto 3DTipo: Elemento de datosComposición: @idobj + nombre + color + (textura) + tipo + 1{vértice}NObservaciones: *Todos los objetos activos y no activos deben tener la misma composición*
Unidad 3
Ingeniería de software
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
Unidad 3
Ingeniería de software
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ó.
Unidad 3
Ingeniería de software
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:
2.2Cargar unobjeto 3D
almacenado
Petición de cargade objetos 3D
Objeto 3D
Objetos 3Drecuperados
COMIENZAObjeto 3D = ningunoRecuperar todos los Objetos 3D del Almacén de objetos 3DSI 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 3DSINO Mostrar Menaje gráfico “Cero Objetos 3D recuperados”EVIAR Objeto 3DTERMINA
Unidad 3
Ingeniería de software
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.
Unidad 3
Ingeniería de software
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.
Unidad 3
Ingeniería de software
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.
Unidad 3
Ingeniería de software
Introducción a los 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
Unidad 3
Ingeniería de software
Casos de uso 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.
Inicio
Obtener una comprensión inicial del dominio
Construir un modelo inicial de negocios
Preparar un conjunto inicial de requisitos
¿Losrequisitos
son Satisfactorios?
SíFin
No
Refinar el modelo de negocios
Refinar el conjunto de requisitos
Obtener una comprensión más profunda del dominio
Diagrama del workflow de los requisitos [Schach, 2004]
Unidad 3
Ingeniería de software
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).
Unidad 3
Ingeniería de software
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 larelación con los actores
Unidad 3
Ingeniería de software
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.
Unidad 3
Ingeniería de software
Casos de uso … (5) Ejemplos de relaciones
Unidad 3
Ingeniería de software
Casos de uso … (6)
Ejemplo: sistema de reservaciones de vuelo [Weitzenfeld, 2005]
Unidad 3
Ingeniería de software
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:1. Identificar casos:
a. Identificar límites del sistema y actores• Utilizar técnicas de observación y entrevistas
b. 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?
2. Descripción y estructuración de casos:a. Descripción completa de cada caso
• Debe ser concebida desde el punto de vista de un actor determinado.• No debe ser pequeña.
b. 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.
c. 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).
Unidad 3
Ingeniería de software
Casos de uso … (8)
Plantillas
Ingeniería de software
Unidad 3
[Weitzenfeld, 2004] [Durán, 2000]
Casos de uso … (9)
Ejemplo:
Unidad 3
Ingeniería de software
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 .
Unidad 3
Ingeniería de software
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
Unidad 3
Ingeniería de software
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
Unidad 3
Ingeniería de software
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
Unidad 3
Ingeniería de software
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.
Nombre de la clase Persona Universidad
Notación para una clase Notación para las clases Persona y Universidad
Nombre del objeto: Nombre de la clase
Notación para un objeto queIncluye el nombre de la clase
Pancho Villa: Persona
Notación para un objeto Pancho Villaque incluye el nombre de la clase
Unidad 3
Ingeniería de software
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].
Unidad 3
Ingeniería de software
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.
<<Estereotipo>>Nombre de la clase
Notación para una clasecon estereotipo
Extensiones de UML pararepresentar estereotipos
Entidad
Borde
Control
Unidad 3
Ingeniería de software
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
Unidad 3
Ingeniería de software
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.
Unidad 3
Ingeniería de software
Diagramas de secuencias … (3) Diagrama de secuencias Crear Registro del caso de uso Registrar usuario.
Unidad 3
Ingeniería de software
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.
Unidad 3
Ingeniería de software
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.
Unidad 3
Ingeniería de software
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 parala clase persona
Unidad 3
Ingeniería de software
Diagramas de estados … (4) Estados compuestos
Reducen la complejidad Se da origen a superestados y subestados
Unidad 3
Ingeniería de software
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
Unidad 3
Ingeniería de software
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).
Unidad 3
Ingeniería de software
Diagramas de estados … (7)
El siguiente ejemplo muestra el diagrama de estado inicial de un sistema que ofrece un menú de acciones a realizar.
Unidad 3
Ingeniería de software
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.
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
Diagramas de actividad … (3)
Ejemplos:
Validación de los requerimientos
En esta etapa se establecen los requerimientos finales o completos que definirán el sistema que el cliente desea.
Su desarrollo es crítico ya que permite la detección de errores en los requerimientos.
Sin embargo es difícil demostrar que un conjunto de requerimientos cumple a la perfección con todas las necesidades del usuario.
Validación de los requerimientos … (2)
Para validar los requerimientos se pueden seguir diferentes técnicas: Revisiones de requerimientos
Técnica manual de revisión entre los clientes y desarrolladores
Ante omisiones o errores se renegocia una solución con el cliente
Construcción de prototipos Desarrollo de modelos en base a los requerimientos Pueden ser desechables o evolutivos
Generación de casos de prueba Consiste en diseñar pruebas que permitan verificar los
requisitos Si el caso de prueba no se puede diseñar redefinir
requerimientos
Validación de los requerimientos … (3)
La validación debe comprobar que los requisitos son: Consistentes Verificables Comprensibles Rastreables Adaptables
Top Related