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

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


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


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


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


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


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


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


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


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


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.


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


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


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


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


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


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



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



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



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


Estructura de la especificación Estándar IEEE Std. 830 [IEEE, 1998]

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.

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

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:

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


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


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


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


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


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


Opciones de configuración

Lista de objetos3D a almacenar

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

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


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


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



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



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



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


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


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


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


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


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


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


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


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


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


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


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


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


Casos de uso … (5) Ejemplos de relaciones

Unidad 3



Ejemplo: sistema de reservaciones de vuelo [Weitzenfeld, 2005]

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: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



Plantillas


Unidad 3

[Weitzenfeld, 2004] [Durán, 2000]


Ejemplo:

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 .

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

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

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

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.

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


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


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


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


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


Diagramas de secuencias … (3) Diagrama de secuencias Crear Registro del caso de uso Registrar usuario.

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.

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.

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 parala clase persona

Unidad 3


Diagramas de estados … (4) Estados compuestos

Reducen la complejidad Se da origen a superestados y subestados

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

Unidad 3



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



El siguiente ejemplo muestra el diagrama de estado inicial de un sistema que ofrece un menú de acciones a realizar.

Unidad 3


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

Documents

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