Ingenier

1
Ingeniería de Software

• Unidad 3
• Análisis de requerimientos del software

2
Contenido
Unidad 3
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

• 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

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
3
Técnicas de recolección de información
Unidad 3

• 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.

4
Técnicas de recolección de información (2)
Unidad 3

• 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.

5
Técnicas convencionales
Unidad 3

• 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.

6
Técnicas convencionales (2)
Unidad 3

• 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).

7
Técnicas convencionales (3)
Unidad 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.

8
Desarrollo conjunto de aplicaciones
Unidad 3

• 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.

9
Desarrollo conjunto de aplicaciones (2)
Unidad 3

• 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.

10
Prototipado
Unidad 3

• 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

11
Prototipado (2)
Unidad 3

• 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.

12
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

13
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.

14
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

15
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.

16
Especificación de los requerimientos del software
Unidad 3

• 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.

17
Características de la especificación
Unidad 3

• 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

18
Características de la especificación (2)
Unidad 3

• 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.

19
Características de la especificación (3)
Unidad 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.

20
Características de la especificación (4)
Unidad 3

• 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

21
Características de la especificación (5)
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.

22
Características de la especificación (6)
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.

23
Características de la especificación (7)
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.

24
Estructura de la especificación
Unidad 3

• Estándar IEEE Std. 830 IEEE, 1998

25
Estructura de la especificación (2)
Unidad 3

• 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.

26
Métodos estructurados
Unidad 3

• 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

27
Diagramas de flujo de datos
Unidad 3

• Los DFD se utilizan para realizar el modelo
  funcional del sistema
• La simbología (notación) Yourdon/De Marco es la
  siguiente

Transformaciones o procesos (funciones, cálculo,
selección)
Información de entrada
Datos intermedios
Terminadores (Fuentes o Destinos)(personas,
entidades)
Datos intermedios
Datos intermedios
Información de salida
Flujo de datos
Flujos de información (inputs-outputs)
Información de entrada
Información de salida
Ficheros o depósitos temporales de información
(base de datos, clasificador, etc.)
Entrada en Almacenamiento
Salida del Almacenamiento
D ALMACÉN DE DATOS
D1 ALMACENAMIENTO
28
Diagramas de flujo de datos (2)
Unidad 3

• 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

29
Diagramas de flujo de datos (3)
Unidad 3
P Validar código postal

• Reglas (ejemplos)

Flechas divergentes
Código postal
Flujos de datos interactivos
P Validar teléfono
Dirección del cliente
Pago
Teléfono
P Aceptar Pago
P Analizar Petición de crédito
Autorización de crédito
Denegación de crédito
Calle
Solicitud de crédito
P Validar Calle
Recibo

• Cuando un flujo o más de uno entran a un proceso
  quiere decir que
• El proceso pide el flujo de datos?
• El proceso necesita todos los flujos que entran?
• La respuesta es No se sabe y no importa!!
• Los aspectos procedurales no se manifiestan en
  los DFD
• Si tales aspectos son realmente importantes se
  deben incluir en las miniespecificiaciones

30
Diagramas de flujo de datos (4)
Unidad 3

• Jerarquía de DFDs
• 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.

31
Diagramas de flujo de datos (5)
Unidad 3
DFD de contexto

• Ejemplo
• El Software de graficación 3D debe permitir al
  usuario procesar sentencias de texto para la
  edición de objetos geométricos. Tener la
  capacidad de procesar comandos vía componentes
  gráficos para realizar diversas tareas. Un
  elemento muy importante en el sistema es un
  almacén de objetos 3D, del cuál se pueden
  recuperar objetos previamente editados y,
  obviamente, se pueden almacenar nuevos objetos.
  También es importante contar con un archivo de
  configuración del sistema. Al cambiar la
  configuración del sistema o editar objetos se
  debe actualizar la visualización de lo presentado
  en pantalla. Es importante que tanto para los
  comandos como para las sentencias se emitan
  mensajes de error o confirmación según
  corresponda.

DFD nivel 1
Sentencias
Mensajes
Archivo de configuración del sistema
Datos de configuración
Información 3D
Datos de configuración
Opciones de configuración
Comandos
Lista de Objetos 3D Activos
Objetos 3D recuperados
Lista de Objetos 3D
Datos de configuración
Vista Actualizada
Almacén de objetos 3D
32
Diagramas de flujo de datos (6)
Unidad 3
DFD del proceso 1 (nivel 2)

• Ejemplo (continuación)
• Para procesar una sentencia primero se debe
  validar, si es válida se procede a su ejecución y
  en caso de no serlo se debe emitir el
  correspondiente mensaje de error.
• En lo que respecta a los comandos, se tienen
  peticiones para mostrar una lista de objetos 3D
  en edición (activos), para cargar un objeto 3D
  almacenado, almacenar objetos 3D activos y para
  mostrar el menú de configuración.

Sentencia Válida
Información 3D
Sentencias
Mensaje de error
Mensaje de confirmación
DFD del proceso 2 (nivel 2)
Petición de lista de objetos 3D
Información 3D
Objetos 3D modificados
Lista de objetos 3D activos
Objeto 3D
Petición de carga de objetos 3D
Objetos 3D recuperados
Comandos
Petición de Almacenar objetos 3D
Lista de objetos 3D a almacenar
Archivo de configuración del sistema
Petición de configuración
Opciones de configuración
33
Diagramas de flujo de datos (7)
Unidad 3

• Ampliaciones para sistemas de tiempo real Ward y
  Mellor, 1985
• La notación básica es adaptada para las
  siguientes demandas impuestas por los sistemas de
  tiempo real
• Flujo de información que es recogido o producido
  de forma continua en el tiempo
• Información de control que pasa por el sistema y
  el procesamiento de control asociado

Flujo de datos continuo
Cantidad de voltaje requerido
Tren de pulsos
Flujo de control
Activación del ajuste
Velocidad deseada
P
Orden del operador
Indicador de inicio del control
Proceso de control
34
Diccionario de datos
Unidad 3

• 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.

35
Diccionario de datos (2)
Unidad 3

• 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

36
Diccionario de datos (3)
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.

37
Diccionario de datos (4)
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
• _at_ identificador de campo clave en almacén
• Ejemplos
• Etiqueta 1caracter8 solo letras
• Persona _at_nss nombre apellidos nprof
  nalum
• (edad)

38
Diccionario de datos (5)
Unidad 3

• Ejemplo DD

Nombre Comandos Sinónimos Eventos de
interfaz Tipo Flujo de datos Composición
Petición-de-Lista-de-Objetos3D
Petición-de-Carga-de-Objetos3D
Petición-de-Almacenar-Objetos3D
Petición-de-Configuración Observaciones Las
peticiones son iniciadas mediante un elemento de
la Interfaz que pudiera ser un botón o un
elemento del menú
Nombre Objeto activo Sinónimos Objeto 3D Tipo
Elemento de datos Composición _at_idobj nombre
color (textura) tipo 1vérticeN Observacion
es Todos los objetos activos y no activos deben
tener la misma composición
39
Especificación de procesos
Unidad 3

• 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

40
Especificación de procesos (2)
Unidad 3

• 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ó.

41
Especificación de procesos (3)
Unidad 3

• Lenguaje estructurado
• Algunos consejos útiles son
• Restringir la especificación de proceso a no más
  de una página de texto, de ocuparse más de una
  página el proceso debe descomponerse en otro
  nivel más.
• No más de tres niveles de anidamiento en las
  estructuras selectivas y/o repetitivas.
• Utilizar sangría apropiada para los anidamientos
• Ejemplo

COMIENZA Objeto 3D ninguno Recuperar todos los
Objetos 3D del Almacén de objetos 3D SI hay
Objetos 3D recuperados Crear una Ventana de
listado con el identificador y nombre de
cada uno de los Objetos 3D recuperados
Permitir buscar y seleccionar uno de ellos.
Al seleccionar un Objeto 3D de la lista hacer
Objeto 3D Objeto 3D seleccionado y mostrar
la vista preliminar del Objeto 3D SINO
Mostrar Menaje gráfico Cero Objetos 3D
recuperados EVIAR Objeto 3D TERMINA
Objeto 3D
Petición de carga de objetos 3D
Objetos 3D recuperados
42
Especificación de procesos (4)
Unidad 3

• 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.

43
Revisión de la especificación estructurada
Unidad 3

• Realizada la especificación estructurada (formada
  por el conjunto de DFDs, 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.

44
Revisión de la especificación estructurada (2)
Unidad 3

• 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.

45
Introducción a los métodos orientados a objetos
Unidad 3

• 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

46
Casos de uso
Unidad 3
Inicio

• Un primer diagrama utilizado en la elaboración de
  modelos de negocios, dentro del workflow de los
  requisitos, es el caso de uso.
• Un caso de uso modela la interacción entre el
  sistema de información y los usuarios de éste.
• Un diagrama de casos de uso es un conjunto de
  casos de uso, donde cada uno de ellos describe
  una forma particular de usar el sistema.

Obtener una comprensión inicial del dominio
Construir un modelo inicial de negocios
Preparar un conjunto inicial de requisitos
Los requisitos son Satisfactorios?
Sí
Fin
No
Obtener una comprensión más profunda del dominio
Refinar el modelo de negocios
Refinar el conjunto de requisitos
Diagrama del workflow de los requisitos Schach,
2004
47
Casos de uso (2)
Unidad 3

• 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).

48
Casos de uso (3)
Unidad 3

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

Delimitación del sistema según los actores
Casos de uso que muestran la relación con los
actores
49
Casos de uso (4)
Unidad 3

• 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.

50
Casos de uso (5)
Unidad 3

• Ejemplos de relaciones

51
Casos de uso (6)
Unidad 3

• Ejemplo sistema de reservaciones de vuelo
  Weitzenfeld, 2005

52
Casos de uso (7)
Unidad 3

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

53
Casos de uso (8)
Unidad 3

• Plantillas

Weitzenfeld, 2004
Durán, 2000
54
Casos de uso (9)
Unidad 3

• Ejemplo

55
Modelo de clases
Unidad 3

• 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 .

56
Modelo de clases (2)
Unidad 3

• 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
57
Modelo de clases (3)
Unidad 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
58
Modelo de clases (4)
Unidad 3

• 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

59
Modelo de clases (5)
Unidad 3

• En UML las clases se describen por medio del
  diagrama de clases.
• La notación para una clase es una caja
  rectangular, que contiene el nombre de la clase.
• La notación general para un objeto se extiende
  mediante el nombre de la clase subrayado seguido
  del nombre del objeto.

Notación para una clase
Notación para las clases Persona y Universidad
Nombre de la clase
Persona
Universidad
Notación para un objeto Pancho Villa que incluye
el nombre de la clase
Notación para un objeto que Incluye el nombre de
la clase
Pancho Villa Persona
Nombre del objeto Nombre de la clase
60
Modelo de clases (6)
Unidad 3

• 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.
61
Modelo de clases (7)
Unidad 3
Notación para una clase con estereotipo

• 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.

ltltEstereotipogtgt Nombre de la clase
Extensiones de UML para representar estereotipos
Entidad
Borde
Control
62
Diagramas de secuencias
Unidad 3

• 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

63
Diagramas de secuencias (2)
Unidad 3

• 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.

64
Diagramas de secuencias (3)
Unidad 3

• Diagrama de secuencias Crear Registro del caso de
  uso Registrar usuario.

65
Diagramas de estados
Unidad 3

• 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.

66
Diagramas de estados (2)
Unidad 3

• 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 gener