TEMA 2

MODELADO DEL ANÁLISIS

2.1 CONCEPTOS Y PRINCIPIOS DE ANÁLISIS

Durante las dos pasadas décadas, se han desarrollado un gran número de métodos de modelado. Los
investigadores han identificado los problemas del análisis y sus causas y han desarrollado varias
notaciones de modelado y sus correspondientes conjuntos de heurísticas para solucionarlos. Cada
método de análisis tiene su punto de vista. Sin embargo, todos los métodos de análisis se relacionan
por un conjunto de principios operativos:
1. Debe representarse y entenderse el dominio de información de un problema.
2. Deben definirse las funciones que debe realizar el software.
3. Debe representarse el comportamiento del software (como consecuencia de acontecimientos
externos).
4. Deben dividirse los modelos que representan información, función y comportamiento de manera que
se descubran los detalles por capas (o jerárquicamente).
5. El proceso de análisis debería ir desde la información esencial hasta el detalle de la implementación.

Además de los principios operativos de análisis mencionados anteriormente, se detallan un conjunto

de principios directrices para la ingeniería de requisitos:
 Entender el problema antes de empezar a crear el modelo de análisis.
 Desarrollar prototipos que permitan al usuario entender cómo será la interacción hombre-
máquina.
 Registrar el origen y la razón de cada requisito
 Usar múltiples planteamientos de requisitos
 Dar prioridad a los requisitos

Los modelos creados durante el análisis de requisitos desempeñan unos papeles muy importantes:
 El modelo ayuda al analista a entender la información, la función y el comportamiento del
sistema, haciendo por tanto más fácil y sistemática la tarea de análisis de requisitos.
 El modelo se convierte en el punto de mira para la revisión y por tanto la clave para
determinar si se ha completado, su consistencia yla precisión de la especificación.
 El modelo se convierte en el fundamento para el diseño, proporcionando al diseñador una
representación esencial del software que pueda trasladarse al contexto de la
implementación.

2.2. GESTION DE REQUISITOS PARA EL DESARROLLO DEL SOFTWARE.

Identificación de Requisitos para el Software:

Antes de que los requisitos puedan ser analizados, modelados o especificados, deben ser recogidos a
través de un proceso de obtención. Un cliente tiene un problema que pretende sea resuelto con una
solución basada en computadora. Un desarrollador responde a la solicitud de ayuda del cliente. En ese
momento se está estableciendo una comunicación.
La técnica más usada para la obtención de requisitos es la entrevista.

20

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)

 Análisis.
El análisis de los requisitos es una tarea de ingeniería del software que cubre el hueco entre la
definición del software a nivel sistema y el diseño del software (Fig.1). El análisis de requisitos permite
al ingeniero de sistemas especificar las características operacionales del software (función, datos y
rendimientos), indica la interfaz del software con otros elementos del sistema y establece las
restricciones que debe cumplir el software.

El análisis de requisitos del software puede dividirse en cinco áreas de esfuerzo:

(1) reconocimiento del problema,
(2) evaluación y síntesis,
(3) modelado,
(4) especificación y
(5) revisión.
Inicialmente, el analista estudia la Especificación del Sistema (si existe alguna) y el Plan del
Proyecto de Software.

Ingeniería
de
sistemas
Análisis
de
de
requisitos Diseño
del
Software

Por ejemplo, un mayorista de automóviles necesita un sistema de control de inventario. El analista

averigua que los problemas del sistema manual que se emplea actualmente son:
(1) incapacidad de obtener rápidamente el estado de un componente;
(2) dos o tres días de media para actualizar un archivo a base de tarjetas;
(3) múltiples órdenes repetidas para el mismo vendedor debido a que no hay manera de asociar a los
vendedores con los componentes, etc. Una vez que se han identificado los problemas, el analista
determina qué información va a producir el nuevo sistema y qué información se le proporcionará al
sistema.

Especificación de requisitos.7
La especificación es un documento que define de forma completa, precisa y verificable, los requisitos,
el diseño, el comportamiento u otras características de un sistema o componente de un sistema.
La especificación de requisitos del software se puede definir como la documentación de los requisitos
esenciales del software y de sus interfaces externos. Debe tener dos características fundamentales:
1. Debe incluir información cierta, es decir, coherente con las necesidades reales del
usuario que se desean satisfacer.
2. Debe comunicar dicha información de forma eficaz, es decir, de tal manera que se
pueda comprender perfectamente.

7
Extracto tomado de Análisis y diseño de aplicaciones informáticas de Gestión. Mario Piattini.

21

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)

 Características de una buena especificación de requisitos del software:
1. No ambigua
2. Completa
3. Fácil de verificar
4. Consistente
5. Clasificada por importancia o estabilidad
6. Fácil de modificar
7. Fácil identificación del origen y de las consecuencias de cada requisito
8. De fácil utilización durante la fase de explotación y mantenimiento.

Uno de los aspectos más importantes de la especificación de requisitos es el de las interfaces externas
del software, tanto por su influencia en la facilidad de uso del software como por ser lo que más
fácilmente percibe el usuario y donde más influyen sus preferencias.
Las interfaces con el exterior coinciden con lo que tradicionalmente se ha llamado las entradas y las
salidas del sistema. En el caso del análisis estructurado se pueden identificar fácilmente sólo con
fijarse en los flujos que entran y salen del sistema en el diagrama de contexto.

La acción de modelar los requerimientos da como resultado uno o más de los siguientes tipos de
modelo:
 Modelos basados en el escenario de los requerimientos desde el punto de vista de distintos
“actores” del sistema.
 Modelos de datos, que ilustran el dominio de información del problema.
 Modelos orientados a clases, que representan clases orientadas a objetos (atributos y
operaciones) y la manera en que las clases colaboran para cumplir con los requerimientos del
sistema.
 Modelos orientados al flujo, que representan los elementos funcionales del sistema y la manera
como transforman los datos a medida que se avanza a través del sistema.
 Modelos de comportamiento, que ilustran el modo en el que se comparte el software como
consecuencia de eventos externos.

2.3. CREACIÓN DE PROTOTIPOS

Un prototipo es una versión preliminar, intencionalmente incompleta o reducida de un sistema. Los

prototipos son estrategias aplicadas a la mayoría de actividades del proceso de software, las cuales
pueden estar relacionadas con aspectos técnicos, funcionales, eficiencia o interfaces de usuario.

El propósito de los prototipos es buscar de manera preliminar información necesaria para ayudar
en la toma de decisiones. Se puede pensar en un prototipo como un medio para la especificación
de requisitos o un enlace de comunicación entre el usuario final y el diseñador.

El análisis hay que hacerlo independientemente del paradigma de ingeniería del software que se
aplique. Sin embargo, la forma que toma este análisis varía. En algunos casos es posible aplicar los
principios operativos del análisis y obtener un modelo de software del que se pueda desarrollar un
diseño. En otras situaciones, se realizan recopilaciones de requisitos, se aplican los principios del
análisis y se construye un modelo del software a fabricar (prototipo) para que lo valore el cliente y
el desarrollador.

Finalmente, hay circunstancias que requieren la construcción de un prototipo al comienzo del

análisis, ya que el modelo es el único medio a través del cual se pueden obtener eficazmente los
requisitos. El modelo evoluciona después hacia la producción del software.

22

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)

 2.4. MODELADO DE DATOS, DE FLUJO DE INFORMACION Y COMPORTAMIENTO.

2.4.1. MODELADO DE DATOS

Si los requerimientos del software incluyen la necesidad de crear, ampliar o hacer interfaz con una
base de datos, o si deben construirse y manipularse estructuras de datos complejas, el equipo del
software tal vez elija crear un modelo de datos como parte del modelado general de los
requerimientos.
Un modelo de datos es un lenguaje orientado a describir una Base de Datos. Típicamente un modelo
de datos permite describir:
 Las estructuras de datos de la base: El tipo de los datos que hay en la base y la forma en que
se relacionan.
 Las restricciones de integridad: Un conjunto de condiciones que deben cumplir los datos para
reflejar correctamente la realidad deseada.
 Operaciones de manipulación de los datos: típicamente, operaciones de agregado, borrado,
modificación y recuperación de los datos de la base.

El modelado de datos responde a una serie de preguntas específicas importantes para cualquier
aplicación de procesamiento de datos. ¿Cuáles son los objetos de datos primarios que va a procesar el
sistema?, ¿Cuál es la composición de cada objeto de datos y qué atributos describe el objeto?, ¿Dónde
residen actualmente los objetos? ¿Cuál es la relación entre los objetos y los procesos que los
transforman?
Para responder estas preguntas, los métodos de modelado de datos hacen uso del Diagrama de
Entidad-Relación (DER). Permite que un ingeniero del software identifique objetos de datos y sus
relaciones mediante una notación gráfica. En el contexto del análisis estructurado, el DER define todos
los datos que se introducen, se almacenan, se transforman y se producen dentro de una aplicación.
El DER es específicamente útil para aplicaciones en donde los datos son complejos.

Simbología

Representa una Entidad

Ejemplo de DER
Representa una Relación

Representa un Atributo

Conecta los Símbolos

23

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)

 Ejemplo: Representación tabular de objetos de datos

No. Fecha
Nombre Dirección
Nacionalidad Titulo
Fecha Nac.

M M 1 EDITORIAL
AUTOR N OBRA Edita
Escrbe

Nombre

2.4.2. MODELADO DE FLUJO DE INFORMACIÓN

La información se transforma a medida que fluye por un sistema basado en computadora. El sistema
acepta entradas en una gran variedad de formas; aplica elementos de hardware, software y humanos
para transformar la entrada en salida, y produce salida en una gran variedad de formas. La entrada
puede ser una señal de control transmitida por un controlador, una serie de números escritos por un
enlace de una red o un archivo voluminoso de datos recuperado de un almacenamiento secundario.
La transformación puede ser, desde una sencilla comparación lógica, hasta un complejo algoritmo
numérico o un mecanismo de reglas de un sistema experto.
El análisis estructurado es una técnica del modelado del flujo y del contenido de la información. La
representación del modelado de flujo de datos puede hacerse a través de un Diagrama de Flujo de
Datos.

El modelado del flujo de datos es una actividad fundamental del análisis estructurado.
El modelado orientado al flujo da una indicación de la forma en la que las funciones de procesamiento
transforman los objetos de datos.
Aunque algunos ingenieros de software perciben el modelado orientado al flujo como una técnica
obsoleta, sigue
Fabricante Modelo Número de serie Carrocería Color Propietario
siendo una de las
Lexus LS400 AB123… Sedán Blanco RSP
Chevy Corvette X456… Deportivo Rojo CCD notaciones más
BMW 75Oil XZ765… Cupé Blanco LJL usadas
Ford Taurus Q12A45… Sedán Azul BLF actualmente para
hacer el análisis de los requerimientos.

Los diagramas de flujo de datos se utilizan para complementar los diagramas UML y amplían la
perspectiva de los requerimientos y del flujo del sistema.

El diagrama de flujo de datos (DFD) es una técnica que representa el flujo de la información y las
transformaciones que se aplican a los datos al moverse desde la entrada hasta la salida; ya que
adopta un punto de vista del tipo entrada-proceso-salida para el sistema.

Se puede usar el diagrama de flujo de datos para representar un sistema o un software a cualquier
nivel de abstracción. De hecho, los DFD’s pueden ser divididos en niveles que representen un mayor
flujo de información y un mayor detalle funcional. Por consiguiente, el DFD proporciona un mecanismo
para el modelado funcional, así como el modelado del flujo de información.

24

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)

 Un DFD de nivel 0, también denominado modelo fundamental del sistema o modelo de contexto,
representa al elemento de software completo como una sola burbuja con datos de entrada y de salida
representados por flechas de entrada y de salida, respectivamente. Al dividir el DFD de nivel 0 para
mostrar más detalles, es cuando empezamos a crear los DFD’s por niveles.

Ward y Mellor amplían la notación básica del análisis estructurado para que se adapte a las siguientes
demandas impuestas por los sistemas de tiempo real:
 Flujo de información que es recogido o producido de forma continúa en el tiempo.
 Información de control que pasa por el sistema y el procesamiento de control asociado.
 Ocurrencias múltiples de la misma transformación que se encuentran a menudo en situaciones
de multitarea.
 Estados del sistema y mecanismos que producen transición de estados en el sistema.

EJEMPLO
A continuación se presenta un DFD en varios niveles para un sistema de
control de pedidos.

NIVEL DE CONTEXTO

25

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)

 26

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)

 2.4.3 MODELADO DEL COMPORTAMIENTO

El modelado del comportamiento es uno de los principios fundamentales de todos los métodos de
análisis de requisitos. El modelo de comportamiento indica la forma en la que responderá el software a
eventos o estímulos externos.

Para generar el modelo deben seguirse los pasos siguientes:

1. Evaluar todos los casos de uso para entender por completo la secuencia de interacción dentro
del sistema.
2. Identificar los eventos que conducen la secuencia de interacción y que entienden el modo en el
que éstos se relacionan con objetos específicos.
3. Crear una secuencia para cada caso de uso.
4. Construir un diagrama de estado para el sistema.
5. Revisar el modelo de comportamiento para verificar la exactitud y consistencia.

El diagrama de transición de estados (DTE) representa el comportamiento de un sistema que muestra

los estados y los sucesos que hacen que el sistema cambie su estado.
Otros tipos de representación del comportamiento son los llamados Diagramas de secuencia.

2.5 MECANISMOS DEL ANÁLISIS ESTRUCTURADO Y DICCIONARIO DE DATOS

El modelo de análisis acompaña representaciones de objetos de datos, funciones y control. En cada

representación los objetos de datos y/o elementos de control juegan un papel importante.

Por consiguiente, es necesario proporcionar un enfoque organizado para representar las características
de cada objeto de datos y elemento de control. Esto se realiza con el diccionario de datos. Se ha
propuesto el diccionario de datos como gramática casi formal para describir el contenido de los objetos
definidos durante el análisis estructurado.

El diccionario de datos es un listado organizado de todos los elementos de datos que son pertinentes
para el sistema, con definiciones precisas y rigurosas que permiten que el usuario y el analista del
sistema tengan una misma comprensión de las entradas, salidas, de los componentes de los
almacenes y también de los cálculos intermedios.

DICCIONARIO DE DATOS

El formato del diccionario varía entre las distintas herramientas, la mayoría contiene la siguiente
información:

 Nombre: el nombre principal del elemento de datos o de control, del almacén de datos, o de
una entidad externa.
 Alias: otros nombres usados para la primera entrada.
 Dónde se usa y cómo se usa: un listado de los procesos que usan el elemento de datos o
de control y cómo lo usan (por ejemplo, como entrada al proceso, como salida del proceso,
como almacén de datos, como entidad externa).
 Descripción del contenido: el contenido representado mediante una notación.
 Información adicional: otra información sobre los tipos de datos, los valores implícitos (si se
conocen), las restricciones o limitaciones, etc.

27

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)

 CONSTRUCCIÓN DE UN DICCIONARIO DE DATOS.
Como primer paso en la construcción de un diccionario de datos se debe listar todas las entidades,
flujos de datos, procesos y almacenes de todos los diagramas de un DFD propuesto.

El siguiente paso es describir las estructuras de datos que componen cada uno de ellos.
Por último, se describen los datos que componen las estructuras.

Existen muchos esquemas de notación comunes utilizados por el analista de sistemas. El que se
muestra a continuación es de los más comunes y utiliza varios símbolos sencillos:
= está compuesto de
+ y
() optativo (puede estar presente o ausente)
{} iteración
[] seleccionar una de varias alternativas
** comentario
@ identificador (campo clave) para un almacén
| separa opciones alternativas en la construcción.
Definiciones:

La definición de un dato se introduce con el símbolo “=”. En este contexto, el “=” se lee: “se define
como”, o “se compone de”, o “significa”.

A = B+C (A se define como B y C).

Por ejemplo, podemos definir:
nombre = título de cortesía + nombre + (segundo nombre) + apellido paterno + apellido materno
título de cortesía = [Sr. | Srta. | Sra. | Dr. | Profesor ]
nombre = {caracter legal}
apellido paterno = {caracter legal}
apellido materno = {caracter legal}
Datos opcionales, son los que pueden estar o no presentes en un dato compuesto. Por ejemplo, el
nombre del cliente pudiera no incluir el segundo nombre, el domicilio de un cliente pudiera incluir o no
información secundaria, como el número de departamento.

Domicilio de cliente = (domicilio de envío)+(domicilio para cuenta)

Significa que el domicilio pudiera consistir en sólo un domicilio de envío o bien sólo un domicilio para
enviar cuentas o ninguno de los dos.
Esta última posibilidad es dudosa. Es mucho más probable que el usuario quiera decir que el domicilio
debe consistir en uno u otro o ambos. Esto se representa así:
Domicilio del cliente = [domicilio de envío | domicilio para cuentas | domicilio de envío +domicilio para
cuentas]

Si se quiere que exista siempre domicilio de envío y que domicilio para cuentas sea opcional se
representa así:
Domicilio del cliente = domicilio de envío + (domicilio para cuentas)

28

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)

 La notación de iteración se usa para indicar la ocurrencia repetida de un componente de un dato. Se
lee como “cero o más ocurrencias de “.

Solicitud = nombre del cliente + domicilio de envío + {artículo}

Significa que la solicitud siempre debe contener un nombre de cliente, un domicilio de envío y también
cero o más ocurrencias de un artículo. También podemos especificar los límites superior e inferior de la
iteración, que debe haber por lo menos uno y se permitirán cuando menos 10; esto puede indicarse
así: Solicitud = nombre del cliente + domicilio de envío + 1{artículo}10.
Se puede especificar sólo uno de los límites y es correcto.

Selección
La notación de selección indica que un dato consiste en exactamente un elemento de entre un
conjunto de opciones alternativas. Las opciones se encierran entre corchetes y se separan por la barra
vertical |.

Sexo = [femenino | masculino]

Tipo de cliente = [gobierno | industria | Universidad | otro]
Es importante asegurarse de cubrir todas las posibilidades.

Alias: es una alternativa de nombre para un dato. Esto es una ocurrencia común cuando se trata con
diversos grupos de usuarios en diferentes departamentos o ubicaciones geográficas, que insisten en
utilizar distintos nombres para decir lo mismo.
El alias se incluye en el diccionario de datos para que esté completo y se relaciona con el nombre
primario u oficial del dato.

Comprador = * alias de cliente *

Cuando diseñamos un Diccionario de Datos, debemos adoptar un formato particular para la descripción
de sus elementos.
Lo que se debe describir en el Diccionario de Datos además de su estructura de datos, será cada uno
de los elementos que forman un DFD.

Ejemplos de llenado de un Diccionario de Datos:

29

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)

 30

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)

 BIBLIOGRAFÍA
 Ingeniería de software. Un enfoque práctico. Roger S. Pressman - VII Edición.
 Ingeniería de Software. Ian Sommerville. 7ª. Edición.
 Análisis y Diseño de Sistemas. Kendall y Kendall. 3ª. Edición

31

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)