Fuente: http://www.masingenieros.com/wp-content/uploads/2013/10/19338503_xl.

jpg
 1. Diccionario de Datos

Fuente:http://www.stdmultiopcion.es/wp-content/uploads/2014/04/Gesti%C3%B3n.jpg

i. Definición de diccionario de datos

El diccionario de datos es una versión especializada de los diccionarios que se utilizan

como referencias en la vida cotidiana. El diccionario de datos es una obra de consulta de
información sobre los datos (es decir, metadatos); es compilado por los analistas de
sistemas para guiarse a través del análisis y diseño. Como documento, el diccionario de
datos recopila y coordina términos de datos específicos, además de confirmar lo que
significa cada término para distintas personas en la organización. Los diagramas de
flujo de datos son un excelente punto de partida para recolectar entradas para el
diccionario de datos.
Una razón importante para tener un diccionario es con el fin de mantener limpios los
datos; es decir, para conservarlos consistentes. Si usted almacena datos sobre el sexo de
un hombre como “M” en un registro, “Masculino” en un segundo registro y como el
número “1” en un tercer registro, los datos no están “limpios”. En este aspecto el
diccionario de datos le será muy útil.
Según definición de Edward Yourdon tenemos que:
El diccionario de datos de frases casi se autodefine. El diccionario de datos es un listado
organizado de todos los datos pertinentes del sistema, con definiciones precisas y
rigurosas para que tanto el usuario como el analista tengan un entendimiento común de

Prof. Cynthia Rivas Aquino

 todas las entradas, salidas, componentes de almacenes y cálculos intermedios. El
diccionario de datos define los datos haciendo lo siguiente:
 Describe el significado de los flujos y almacenes que se muestran en el DFD.
 Describe la composición de agregados de paquetes de datos que se mueven a lo
largo de los flujos, es decir, paquetes complejos (por ejemplo el domicilio de un
3
cliente), que pueden descomponerse en unidades elementales (como ciudad, estado y
código postal).
 Describen la composición de los paquetes de datos en los almacenes.
 Especifica los valores y unidades relevamientos de piezas elementales de la
información en los flujos de datos y en los almacenes de datos.
 Describe los detalles de las relaciones entre almacenes que se enfatizan en un
diagrama de entidad-relación.
Para describir la composición de los elementos de datos en una forma narrativa.
Necesitamos una notación concisa y compacta, así como un diccionario normal tiene
notación compacta y concisa para definir el significado de las palabras ordinarias.

ii. Necesidad de comprender el diccionario de datos

En la actualidad, muchos sistemas de administración de bases de datos vienen
equipados con un diccionario de datos automatizado. Estos diccionarios pueden ser
elaborados o simples. Algunos diccionarios de datos computarizados clasifican de
manera automática los elementos de datos al momento de llevar a cabo la
programación; otros simplemente proveen una plantilla en la que se pide a la persona
que llena el diccionario clasificar todas las entradas de una manera uniforme.
A pesar de la existencia de los diccionarios de datos automatizados, las cuestiones que
siguen siendo pertinentes para el analista de sistemas durante el esfuerzo de sistemas
son comprender qué datos componen un diccionario de datos, las convenciones
utilizadas en los diccionarios de datos y la forma en que se desarrolla un diccionario de
datos. Al comprender el proceso de compilar un diccionario de datos, el analista de
sistemas puede conceptualizar con más facilidad el sistema y la forma en que funciona.
Además de proveer documentación y eliminar la redundancia, podemos usar el
diccionario de datos para:
1. Validar la integridad y precisión del diagrama de flujo de datos.
2. Proveer un punto de partida para desarrollar pantallas e informes.
3. Determinar el contenido de los datos almacenados en archivos.
4. Desarrollar la lógica para los procesos del diagrama de flujo de datos.

Prof. Cynthia Rivas Aquino

iii. Descripción de las estructuras de datos

Existen muchos esquemas de notaciones comunes utilizadas por el analista de sistemas.

El que se muestra a continuación es de los más comunes y utiliza varios símbolos
sencillos.
1. Un signo de igual (=) significa “está compuesto de”. 4

2. Un signo positivo (+) significa “y”.

3. Las llaves { } Iteración: indican elementos repetitivos, también conocidos como
grupos repetitivos o tablas repetitivas.
Puede haber un elemento repetitivo o varios de ellos en el grupo. El grupo repetitivo
puede tener
condiciones, como un número fijo de repeticiones, o límites superiores e inferiores para
el número de
repeticiones.
4. Los corchetes [ ] representan una situación del tipo cualquiera/o. Puede estar presente
cualquier
elemento u otro, pero no ambos. Los elementos que se enlistan entre corchetes son
mutuamente excluyentes. Seleccionar una de varias alternativas.
5. Los paréntesis ( ) representan un elemento opcional. Los elementos opcionales se
pueden dejar en blanco en las pantallas de entrada de datos y pueden contener espacios
o ceros para los campos numéricos en las
estructuras de archivos.
6. | Separa opciones alternativas en la construcción.
7. ** Comentarios.

Como pueden apreciarse, los símbolos parecen algo matemáticos y pudiera preocuparse
porque sea demasiado complicado de entender. Sin embargo, como veremos pronto, la
notación es bastante fácil de leer. La experiencia de miles de proyectos de
procesamiento de datos y varias decenas de miles de usuarios nos han demostrado que
la notación, además, es bastante entendible para casi todos los usuarios si se presenta de
manera correcta.

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 simplemente “significa”. Por ello, la
notación.
A=B+C
Puede leerse de las siguientes maneras:
 Cuando digamos A, queremos decir una B y una C
 A se compone de B y C
 A se define como B y C

Prof. Cynthia Rivas Aquino

Para definir por completo un dato, nuestra definición debe incluir lo siguiente.
 El significado del dato dentro del contexto de la aplicación de este usuario. Por
lo común se ofrece como comentarios utilizando la notación “**”
 La composición de dato, si se compone de partes elementales con significado.
 Los valores que puede tomar el dato, si es un dato elemental que no puede
descomponerse más. 5

Asi, si estamos construyendo un sistema médico que siga la evolución de los pacientes,
podrían definirse los términos peso y estatura de la siguiente manera:

Peso = *pero del paciente al ser admitido al hospital*

*unidades: kilogramos; gama 1-200*
Estatura = *estatura del paciente al ser admitido al hospital*
*unidades: centímetros; escala: 20-200*
Nótese que hemos descrito las unidades relevantes y la escala relevante entre un par de
caracteres “*”. Repetimos que esto es un convenio de notación que muchas
organizaciones encuentran adecuado, pero que puede cambiarse de ser necesario.

Datos opcionales: un dato opcional, como la frase implica, es aquel que puede estar o
no presente en un dato compuesto. Existen muchos ejemplos de datos opcionales en
sistemas de información.
 El nombre de un cliente pudiera no incluir un segundo nombre.
 El domicilio de un cliente pudiera incluir o no información secundaria, como el
número de departamento.
 El pedido de un cliente pudiera contener el domicilio al que se tiene que mandar
la cuenta, el domicilio al que hay que hacer el envío, o ambos.
Las situaciones de este tipo deben verificarse con cuidado con el usuario y deben
documentarse precisamente en el diccionario de datos.

Iteración: La notación iteración se usa para indicar la ocurrencia repetida de un

componente de un dato. Se lee como “cero o más ocurrencias de”. Asi, la notación:
Solicitud = nombre del cliente + domicilio de envío + {articulo}

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. Asi, pudiéramos estar tratando
con un cliente que pide un artículo, o dos, o algún comprador compulsivo que decide
ordenar 397 artículos diferentes.
En muchas situaciones reales, el usuario querrá especificar los límites inferior y superior
de la iteración. Tal vez, en el ejemplo anterior, el usuario señale que no tiene sentido
que un cliente haga un pedio de cero artículos; debe haber por lo menos uno. Podría
también especificarse un límite superior; quizá, se permitirán cuando más de 10
artículos. Puede indicarse esto de la siguiente forma:

Prof. Cynthia Rivas Aquino

Solicitud = nombre del cliente + domicilio de envío + 1{articulo} 10

Es correcto especificar solo el límite inferior, sol el límite superior, ambos, o ninguno.
Asi que se permite cualquiera de las siguientes:
A= 1{b}
A= {b} 10
A= 1{b} 10 6
A= {b}

Selección: la notación de selección indica que un dato consiste en exactamente un

elemento de entre un conjunto de operaciones alternativas. Las opciones se encierran en
corchetes “[“y”]”, y se separan por una barra vertical “|”. Como ejemplos típicos tenemos.

Sexo = [Femenino | Masculino]

Tipo de cliente = [Gobierno | Industria | Universidad | Otro]

Es importante revisar las opciones de selección con el usuario para asegurarse de cubrir
todas las posibilidades. En el último ejemplo, el usuario pudiera tender a concentrar su
atención en los clientes “gobierno”, “industria”, “universidad”, y podrías requerir un
recordatorio de que existen clientes de la categoría de “Ninguno de los anteriores”.

Alias: un alias como el término implica, 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 (y a veces con diferentes nacionalidades o
idiomas), que insisten en utilizar nombre para decir lo mismo. El alias se incluye en el
diccionario de datos para que este completo, y se relaciona con el nombre primario u
oficial del dato. Por ejemplo:

Comprador = *alias del cliente*

Nótese que la definición de comprador no muestra su composición (es decir, no muestra

que consiste en nombre, domicilio, número telefónico, etc.). Todos estos detalles deben
darse solo para el nombre primario del dato, para minimizar la redundancia en el
modelo.
Aun cuando el diccionario de datos relaciona correctamente los alias con el nombre
primario de los datos, debe evitarse el uso de alias hasta donde sea posible.
Eso se debe a que los nombres de datos se suelen ver primero, y son más visibles para
todos los usuarios en los DFDs, en donde pudiera no ser tan obvio que comprador y
cliente sean alias. Es mejor, de ser posible, lograr que todos los usuarios se pongan de
acuerdo en un solo nombre.

Prof. Cynthia Rivas Aquino

La figura 8.4 es un ejemplo de la estructura de datos para agregar el pedido de un
cliente. Cada pantalla CLIENTE NUEVO consiste en las entradas que se encuentran del
lado derecho de los signos de igual. Algunas de las entradas son elementos, pero otras,
como NOMBRE DEL CLIENTE, DIRECCIÓN y TELÉFONO, son grupos de
elementos o registros estructurales. Por ejemplo, NOMBRE DEL CLIENTE está
compuesto por PRIMER NOMBRE, INICIAL SEGUNDO NOMBRE y APELLIDO
PATERNO. Hay que definir cada registro estructural de una manera más detallada hasta 7
que todo el conjunto se descomponga en sus elementos básicos. Cabe mencionar que,
después de la definición para la pantalla PEDIDO DEL CLIENTE, están las
definiciones para cada registro estructural. Incluso un campo tan simple como
NÚMERO TELEFÓNICO se define como una estructura para que el código de área se
pueda procesar por separado.

Prof. Cynthia Rivas Aquino

Los registros estructurales y elementos que se utilizan en muchos sistemas reciben un
nombre específico que no es del sistema como calle, ciudad y código postal, lo cual no
refleja el área funcional en la que se utilizan.
Este método permite al analista definir estos registros una vez y usarlos en muchas
aplicaciones. Por ejemplo, una ciudad puede ser la ciudad de un cliente, un proveedor o
un empleado. Observe el uso de los paréntesis para indicar que (INICIAL SEGUNDO
8
NOMBRE), (DEPARTAMENTO) y (EXPANSIÓN CP) son información opcional de
PEDIDO (pero no más de uno). Para indicar la condición O hay que encerrar las
opciones en corchetes y separarlas con el símbolo.

Definición de los flujos de datos

Hay que describir primero los flujos de datos para todas las entradas y salidas, ya que
por lo general representan la interfaz humana; después, los flujos de datos que entran y
salen de los almacenes de datos. Para describir los detalles de cada flujo de datos
usamos elementos (a los que algunas veces se les denomina campos), una estructura de
datos o un grupo de elementos.
Las entradas y salidas del sistema se determinan a partir de las entrevistas, de observar a
los usuarios y analizar los documentos además de otros sistemas existentes.
Podemos sintetizar la información que se captura para cada flujo de datos mediante el
uso de un formulario que contenga la siguiente información:
1. ID, un número de identificación opcional. Algunas veces el ID se codifica mediante
un esquema para identificar al sistema y la aplicación en el mismo.
2. Un nombre descriptivo único para este flujo de datos. Este nombre es el texto que
debe aparecer en el diagrama y se debe referenciar en todas las descripciones que
utilicen el flujo de datos.
3. Una descripción general del flujo de datos.
4. El origen del flujo de datos. Este origen puede ser una entidad externa, un proceso o
un flujo de datos que provenga de un almacén de datos.
5. El destino del flujo de datos (los mismos elementos enlistados bajo el origen).
6. El nombre de la estructura de datos que describe a los elementos que se encuentran en
este flujo de datos.
Para un flujo de datos simple, podrían ser uno o varios elementos.
7. Un área para comentarios adicionales y anotaciones sobre el flujo de datos.
El cuadro más abajo es un ejemplo de la descripción del flujo de datos que representa la
pantalla utilizada para agregar un nuevo PEDIDO DEL CLIENTE y para actualizar los
archivos de clientes y artículos. Cabe mencionar que la entidad externa CLIENTE es el
origen y que PROCESO 1 es el destino, que provee un vínculo de vuelta al diagrama de
flujo de datos. La descripción detallada del flujo de datos podría aparecer en este
formulario, o se podría representar como una estructura de datos.

Prof. Cynthia Rivas Aquino

Hay que describir primero los flujos de datos para todas las entradas y salidas, ya que
por lo general representan la interfaz humana; después, los flujos de datos intermedios y
los flujos de datos que entran y salen de los almacenes de datos. Para describir los
detalles de cada flujo de datos usamos elementos (a los que algunas veces se les
denomina campos), una estructura de datos o un grupo de elementos.
Podemos describir un flujo de datos simple mediante el uso de un solo elemento, como 9

el número de cliente que utiliza un programa de consulta para buscar el correspondiente

registro de cliente.

Ejemplo de estructura de datos para agregar pedido de un cliente.

Descripción de flujos de datos
ID
Nombre Pedido de cliente
Descripción Contiene la información del pedido de un cliente y se utiliza
para actualizar el archivo maestro del cliente y al archivo de
artículos; además se usa para producir un registro de pedido.
Origen Cliente
Destino Proceso 1
Estructura de datos que Información del pedido.
viaja con el flujo
Comentarios. Información del registro de pedido para un pedido de cliente.
El pedido se puede recibir a través de web, por correo
electrónico o fax. También es posible que el cliente llame por
teléfono directamente al departamento de procesamiento de
pedidos.

Almacenes de datos
Todos los elementos base deben estar guardados en el sistema. Se crean almacenes de
datos para cada entidad de datos distinta que se piense guardar. Es decir, cuando se
agrupan los elementos base del flujo de datos para formar un registro estructural, se crea
un almacén de datos para cada registro estructural único.
Como tal vez un flujo de datos muestre sólo parte de los datos colectivos que contenga
un registro estructural, tal vez tenga que examinar muchas estructuras de flujo de datos
para obtener una descripción completa de un almacén de datos.
La figura 8.9 es el formulario común que se utiliza para describir un almacén de datos.
La información que se incluye en el formulario es la siguiente:

Prof. Cynthia Rivas Aquino

 1. El ID del almacén de datos. A menudo el ID es una entrada obligatoria para evitar
que el analista guarde información redundante. Un ejemplo sería D1 para el ARCHIVO
MAESTRO DE CLIENTES.
2. El nombre del almacén de datos, que es descriptivo y único.
3. Un alias para la tabla, como ARCHIVO MAESTRO DE CONSUMIDORES para el
ARCHIVO MAESTRO DE CLIENTES.
10
4. Una descripción corta del almacén de datos.
5. El número máximo y promedio de registros en el archivo, así como el crecimiento
por año. Esta información ayuda al analista a predecir la cantidad de espacio en disco
requerida para la aplicación; además es necesario para planear la adquisición de
hardware.

Descripción de Almacén de datos:

ID D1
Nombre BD Cursos
Descripción Almacena todos los datos de cursos.
Narrativa
Contenido Código_de_curso + Nombre_de_curso + estado de curso +
cantidad de horas
Flujos de entrada Consultar disponibilidad de curso.
Flujos de salida: Consultar disponibilidad de curso.
Total de registro 45000

iv. Creación del diccionario de datos

Las entradas en el diccionario de datos se pueden crear después de haber completado el
diagrama de flujo de datos, o construir a medida que éste se desarrolle. El uso de la
notación algebraica y registros estructurales permite al analista desarrollar el diccionario
de datos y los diagramas de flujo de datos mediante una metodología arriba-abajo. Por
ejemplo, el analista puede crear un flujo de datos Diagrama 0 después de las primeras
entrevistas y al mismo tiempo crear las entradas preliminares en el diccionario de datos.
Por lo general estas entradas consisten en los nombres de los flujos de datos que se
encuentran en el diagrama de flujo de datos y sus correspondientes estructuras de datos.
Después de realizar varias entrevistas adicionales con los usuarios para aprender sobre
los detalles del sistema y las formas en que interactúan con él, el analista expandirá el
diagrama de flujo de datos y creará los diagramas de nivel inferior. Después hay que
modificar el diccionario de datos para incluir los nuevos registros estructurales y los
elementos que se hayan deducido de entrevistas posteriores, de la observación y del
análisis de los documentos.
Cada nivel de un diagrama de flujo de datos debe usar datos apropiados. El Diagrama 0
debe incluir sólo formularios, pantallas, informes y registros. A medida que se crean los

Prof. Cynthia Rivas Aquino

 diagramas de nivel inferior, el flujo de datos que entra y sale de los procesos se vuelve
cada vez más detallado, incluyendo los registros estructurales y los elementos.
La figura más abajo muestra un nivel del diagrama de flujo de datos y las
correspondientes entradas en el diccionario de datos para producir el cheque de nómina
de un empleado. El proceso 5, que se encuentra en el Diagrama 1, es una vista general
de la producción de un CHEQUE DE NÓMINA DE EMPLEADO. La correspondiente
11
entrada en el diccionario de datos para REGISTRO DE EMPLEADO muestra el
NÚMERO DE EMPLEADO y cuatro registros estructurales, la vista de los datos que se
obtuvieron en las primeras etapas del análisis. De manera similar, REGISTRO DE
ARCHIVO DE TIEMPO y CHEQUE DE NÓMINA DE EMPLEADO también se
definen como una serie de estructuras.
Ejemplo:

v. Uso del diccionario de datos.

El diccionario de datos ideal es automatizado, interactivo, en línea y evolutivo. A

medida que el analista de sistemas aprende sobre los sistemas de la organización, se
agregan elementos de datos al diccionario de datos. Por otra parte, el diccionario de
datos no es un fin en sí mismo y nunca deberá serlo. Para evitar desviarse con la
construcción de un diccionario de datos completo, el analista de sistemas debe
considerarlo como una actividad paralela al análisis y diseño de sistemas.
Para que tenga el máximo poder, el diccionario de datos debe enlazarse en varios
programas de sistemas, de manera que cuando se actualice o elimine un elemento del

Prof. Cynthia Rivas Aquino

diccionario de datos, se actualice o elimine automáticamente de la base de datos. El
diccionario de datos se convierte simplemente en una curiosidad histórica si no se
mantiene actualizado.
La estructura de datos y los elementos para un almacén de datos se utilizan comúnmente
para generar el correspondiente código fuente en lenguaje de computadora, el cual se
incorpora a su vez en los programas de computadora. Podemos utilizar el diccionario de
12
datos junto con el diagrama de flujo de datos para analizar el diseño del sistema,
detectar fallas y áreas que necesiten aclaración.
Si se empieza en las primeras etapas de las fases de análisis y diseño, el diccionario de
datos nos puede ahorrar muchas horas. Éste es la única fuente común en la organización
para responder preguntas y resolver disputas sobre cualquier aspecto de la definición de
datos. Un diccionario de datos actualizado puede constituir un excelente marco de
referencia para los esfuerzos de mantenimiento en sistemas con los que no estemos
familiarizados. Los diccionarios de datos automatizados pueden servir como referencias
tanto para las personas como para los programas.

Diagramas Entidad/Relación

El diagrama de entidad-relación también conocido como DER, o diagrama E – R, es un

modelo de red que describe con un alto nivel de abstracción la distribución de datos
almacenados en un sistema. Es muy diferente del DFD, que modela las funciones que
lleva a cabo un sistema.
¿Por qué podríamos estar interesados en modelar los datos de un sistema?
Primeramente, porque las estructuras de datos y las relaciones pueden ser tan complejas
que se deseara enfatizarlas y examinarlas independientemente del proceso que se llevara
a cabo. De hecho, esto se da sobre todo si mostramos el modelo del sistema a los
usuarios ejecutivos de mayor nivel de una organización (por ejemplo el vicepresidente o
los gerentes de departamento, quienes podían no estar interesados en los detalles
funcionales cotidianos del sistema). Tales usuarios a menudo se preocupan más por los
datos: ¿Qué datos requerimos para manejar nuestro negocio? ¿Quién los tiene? ¿Quién
tiene acceso a ellos?
Algunas de estas preguntas, por ejemplo, la tenencia o acceso a los datos, pudieran ser
responsabilidad de un grupo dedicado dentro de la organización. A menudo, el grupo de
administración de datos es responsable de administrar y controlar la información
esencial de un negocio; cuando se comience a construir un nuevo sistema de
información se requerirá hablar con estas personas para poder coordinar la información
del sistema con el modelo global, corporativo, de información.
El DER es una herramienta útil para llevar a cabo esta conversación.
A menudo existe otro grupo dentro de la administración con un nombre similar: el
grupo de administración de base de datos. Se suele localizar dentro del departamento de
proceso de datos (mientras que el de administración de datos no necesariamente está
ahí), y su labor es asegurar que las base de datos computarizadas se organicen,
administren y controlen de manera eficiente. Asi que suele ser el equipo de
implantación responsable de tomar el modelo esencial y traducirlo a un diseño de base
de datos eficaz para algún sistema de base de datos. El DER es una herramienta efectiva
de modelado para comunicarse con el grupo de administración de base de datos.

Prof. Cynthia Rivas Aquino

Basándose en la información presentada por el DER, el grupo de administración de base
de datos puede ver el tipo de claves o índices o apuntadores que se necesitaran para
llegar de manera eficiente a los registros de las bases de datos.
Para el analista, el DER representa un gran beneficio también: enfatiza las relaciones
entre almacenes de datos en el DFD que de otra forma se hubieran visto solo en las
especificaciones de proceso. Por ejemplo, un DER típico se muestra en las figura más
13
abajo, cada una de las cajas rectangulares corresponde a un almacén de datos en un
DFD y puede verse que hay relaciones que normalmente no se aprecian en un DFD. Eso
se debe a que el DFD enfoca la atención del lector a las funciones que el sistema
efectúa, no a los datos que ocupa.
Considere un caso extremo: ¿Qué tal si no se están realizando funciones?
¿Qué tal si el propósito del sistema que está construyendo no es hacer algo, sino
meramente ser el recipiente de una gran cantidad de información interesante? Tal
sistema pudiera llamarse sistema de consulta, o sistema de apoyo a decisiones. En tal
tipo de sistema, pudiéramos concentrarnos por completo en el modelo de datos, y ni
siquiera preocuparnos por construir el modelo de DFD, que está orientado a las
funciones. Desde luego, esto es claramente una situación rara: la mayoría de los
sistemas si efectúan funciones; a menudo, encontramos que construir primeramente el
modelo de datos hace más fácil descubrir cuáles son las funciones requeridas.

DER típico

REPRESENTANTE DE
VENTAS

CLIENTE PEDIDO
COMPRA

LIBRO IMPRESIONES IMPRESORA

Componentes de un DER
Hay cuatro componentes principales en un diagrama de entidad – relación.
1. Entidades
2. Relaciones
3. Cardinalidad
4. Atributos

Prof. Cynthia Rivas Aquino

Entidades
Cualquier objeto o evento sobre el que alguien decida recolectar datos es una entidad.
También puede ser una persona, lugar o cosa (por ejemplo, un vendedor, una ciudad o
un producto). Una entidad puede ser también un evento o unidad de tiempo, como la
descompostura de una máquina, una venta, un mes o un año.
Representa una colección o conjunto de objetos (cosas) del mundo real cuyos miembros
14
individuales (o instancias) tienen las siguientes características:
 Cada una puede identificarse de manera única por algún medio. Existe alguna
forma de diferenciar entre instancias individuales al tipo de objeto. Por ejemplo, si se
tiene un tipo de objeto conocido como CLIENTE, debemos ser capaces de distinguir
uno de otro (tal vez por un número de cuenta, apellido, o por su número de seguro
social). Si todos los clientes son iguales si hay un negocio en el que son solo entes sin
cara y sin nombre que entra a la tienda a comprar cosas) entonces CLIENTE no sería un
tipo de objeto con significado.
 Cada uno juega un papel necesario en el sistema que se construye. Es decir, para
que el tipo de objeto sea legítimo, debe poder decirse que el sistema no puede operar sin
tener acceso a esos miembros. Si se está construyendo un sistema de ingreso de pedidos
para la tienda, por ejemplo, se pudiera pensar que, además de los clientes, la tienda tiene
mozos, cada uno de los cuales se identifica de manera individual por su nombre. A
pesar de que los mozos juegan un papel útil en la tienda, el sistema de ingreso de
pedidos puede funcionar felizmente sin ellos, por tanto, no merecen un papel como tipo
de objeto en el modelo de sistema. Obviamente eso es algo que debe verificarse con los
usuarios al construir el modelo.
 Cada uno puede describirse por uno o más datos. Es decir, un CLIENTE puede
describirse por medio de datos tales como nombre, domicilio, límite de crédito y
número telefónico. Muchos textos sobre bases de datos describen esto como “asignar
datos a un tipo de objeto”. Nótese que los atributos deben aplicarse a cada instancia de
tipo de objeto; por ejemplo, cada cliente debe tener nombre, domicilio, límite de crédito,
número telefónico, etc.
En muchos de los sistemas que desarrolle, los tipos de objetos serán la representación en
el sistema de algo material del mundo real. Esto significa que los clientes, artículos de
inventario, empleados, partes manufacturadas, etc., son objetos típicos. El objeto es el
algo material del mundo real, el tipo de objeto es su representación en el sistema. Sin
embargo, un objeto también pudiera ser algo no material: por ejemplo, horarios, planes,
estándares, estrategias y mapas.
Dado que a menudo las personas son tipos de objetos en un sistema, debe tenerse otra
cosa en mente: una persona (o para el caso, cualquier cosa material) pudiera ser diversos
tipos de objetos distintos en distintos modelos de datos, o incluso en un mismo modelo.
Juan Pérez, por ejemplo, puede ser EMPLEADO en un modelo de datos y CLIETNE en
otro. También pudiera ser EMPLEADO y CLIENTE dentro del mismo modelo.
Nótese que en todos los ejemplos de un objeto se ha usado un sustantivo singular (por
ejemplo, empleado, cliente). Eso no es necesario, pero es un convenio útil, como
veremos existe una correspondencia entre objetos en el DER y almacenes de DFD; así,
si existe un objeto CLIENTE en el DER, debe haber un almacén de CLIENTES en el
DFD.
EJEMPLO: Un tipo de objeto.

Prof. Cynthia Rivas Aquino

 CLIENTE

Relaciones
Los objetos se conectan entre sí mediante relaciones. Una relación representa un 15

conjunto de conexiones entre objetos, y se representa por medio de un rombo.

En la imagen pueden ver una relación sencilla entre dos o más objetos.

CLIENTE ARTICULO
COMPRA
S

Es importante reconocer que la relación representa un conjunto de conexiones. Cada

instancia de la relación representa una asociación entre cero o más ocurrencias de un
objeto y cero o más ocurrencias del otro. Asi, en la figura más de ejemplo la relación
etiquetada como COMPRAS puede contener las siguientes instancias individuales:
 instancia 1: el cliente 1 compra el articulo 1
 instancia 2: el cliente 2 compra los artículos 2 y 3
 instancia 3: el cliente 3 compra el articulo 4
 instancia 4: el cliente 4 compra los artículos 5, 6 y 7
 instancia 5: el cliente 5 no compra ningún articulo
 instancia 6: los clientes 6 y 7 compran el articulo 8
 instancia 7: los clientes 8, 9 y 10 compran los artículos 9, 10 y 11.
 Etc.
Como puede verse, entonces, una relación puede concretar dos o más instancias del
mismo objeto.
Nótese la relación representa algo que debe ser recordado por el sistema: algo que no
pudo haberse calculado ni derivado mecánicamente. Asi, el modelo de ejemplo indica
que existe alguna razón relacionada con el usuario para recodar el hecho de que el
cliente compra el articulo1, etc. Y la relación también indica que no existe nada a priori
que hubiera permitido determinar que el cliente 1 compro el articulo 1 y nada más.
Nótese también que pude existir más de una relación entre dos objetos. La figura
RELACION MULTIPLE ENTRE OBJETOS muestra dos relaciones entre un
PACIENTE y un MEDICO. A primera vista, pudiera pensarse que eso es rebuscar lo
obvio: cada vez que el medico trata a un paciente, le cobra mediante un recibo. Pero el
ejemplo sugiere que la situación puede ser distinta; pudiera resultar, por ejemplo, que
existan diversas instancias de “tratamiento” entre un médico y el mismo paciente (es
decir, un tratamiento inicial, tratamientos de seguimiento, etc.). El ejemplo implica que
la relación de recibos está completamente separada de la relación de tratamiento: tal vez
a algunos pacientes se les dan recibos solo por su primer tratamiento, mientras que a
otros se les dan para cada tratamiento y a otros jamás se les dan.

Prof. Cynthia Rivas Aquino

Una situación más común es ver múltiples relaciones entre múltiples objetos.
Con un diagrama complejo la relación y sus tipos deben leerse como una unidad. La
relación se puede describir desde la perspectiva de cualquiera de los tipos de objetos
participantes, y todas esas perspectivas son válidas. De hecho, el conjunto de todos estos
puntos de vista es el que describe completamente la relación.
En algunos casos puede haber relaciones entre diferentes instancias de un mismo tipo
16
de objeto. Por ejemplo, imagine un sistema que se está desarrollando para una
universidad, en el cual CURSO, ESTUDIANTE y PROFESOR son tipos de objetos. La
mayoría de las relaciones de interés serán entre instancias de diferentes tipos de objetos
(por ejemplo, las relaciones “se inscribe en”, “imparte”, etc.), sin embargo, pudiera
requerirse modelar la relación “es prerrequisito para” entre una instancia de CURSO y
otra.
Ejemplo de relaciones múltiples entre objetos

TRATAMIENTO

MEDICO PACIENTE

EXTENDER RECIBO

Cardinalidad
Como vimos las relaciones entre el diagrama de E-R con multi-direccionales; pueden
leerse siguiendo cualquier dirección. Además, vimos que los diagramas de E-R no
muestran cardinalidad; es decir, no muestran el número de objetos que participan en la
relación. Eso es consciente y deliberado: se prefiere dejar tales detalles en el diccionario
de datos.
Dado un conjunto de relaciones binarias y los conjuntos de entidades A y B, la
correspondencia de cardinalidades puede ser:

 Uno a Uno: (1:1) Un registro de una entidad A se relaciona con solo un registro
en una entidad B. (ejemplo dos entidades, profesor y departamento, con llaves
primarias, codigo_profesor y jefe_depto respectivamente, un profesor solo puede ser
jefe de un departamento y un departamento solo puede tener un jefe).

Prof. Cynthia Rivas Aquino

 17

 Uno a varios: (1:N) Un registro en una entidad en A se relaciona con cero o

muchos registros en una entidad B. Pero los registros de B solamente se relacionan con
un registro en A. (ejemplo: dos entidades, vendedor y ventas, con llaves primarias,
codigo_vendedor y venta, respectivamente, un vendedor puede tener muchas ventas
pero una venta solo puede tener un vendedor).

 Varios a Uno: (N:1) Una entidad en A se relaciona exclusivamente con una

entidad en B. Pero una entidad en B se puede relacionar con 0 o muchas entidades en A
(ejemplo empleado-centro de trabajo).

 Varios a Varios: (N:M) Una entidad en A se puede relacionar con 0 o con

muchas entidades en B y viceversa (ejemplo asociaciones-ciudadanos, donde muchos
ciudadanos pueden pertenecer a una misma asociación, y cada ciudadano puede
pertenecer a muchas asociaciones distintas).

Prof. Cynthia Rivas Aquino

 18

Etiquetas de Cardinalidad de las relaciones

El tipo de cardinalidad se representa mediante una etiqueta en el exterior de la relación,

respectivamente: "1:1", "1:N" y "N:M". Otra forma de expresar la cardinalidad es
situando un símbolo cerca de la línea que conecta una entidad con una relación:

 "0" si cada instancia de la entidad no está obligada a participar en la relación.

 "1" si toda instancia de la entidad está obligada a participar en la relación y,
además, solamente participa una vez.
 "N" , "M", "*" o también una sola línea sin flecha direccional, si cada instancia
de la entidad no está obligada a participar en la relación y puede hacerlo cualquier
número de veces.
Ejemplos de relaciones que expresan cardinalidad:

 Un policía (entidad) tiene (relación) un arma (entidad) siempre y cuando no

realice funciones de oficina, pudiendo entonces tenerla o no asignada. Es una relación
0:1.
 Cada esposo (entidad) está casado (relación) con una única esposa (entidad) y
viceversa. Es una relación 1:1.

Ejemplos de representación de Cardinalidad.

 Un cliente (entidad) puede comprar (relación) varios servicios (entidad) y un

servicio puede ser comprado por varios clientes distintos. Es una relación N:M.
Para distinguir las cardinalidades de las relaciones se dibuja líneas con y sin dirección.

Prof. Cynthia Rivas Aquino

En el ejemplo puede verse que el conjunto de relaciones cliente-cuenta es muchas a
muchas (al carecer de dirección, las líneas).

19

 Si el conjunto de relaciones cliente-cuenta fuera una a muchas, de cliente a

cuenta, entonces la conexión cliente tendría una flecha que apuntaría al conjunto de
entidades clientes como lo muestra el siguiente gráfico.

 De manera similar, si el conjunto de relaciones cliente-cuenta fuera muchas a

una de cliente a cuenta, entonces la conexión cliente-cuenta tendía una flecha que
apuntaría al conjunto de entidades cuenta.

 Por último, si el conjunto de relaciones cliente-cuenta fuera una a una, entonces

la conexión cliente-cuenta tendría dos flechas, una apuntando al conjunto de entidades
cuenta y otra al conjunto de entidades clientes.

Prof. Cynthia Rivas Aquino

 20

Atributos: Características o propiedades asociadas al conjunto de entidades o

relaciones y que toman valor en una entidad en particular. Ejemplo: nombre, cédula,
teléfono. Los posibles valores puede tomar un atributo para un conjunto de entidades se
denomina dominio.
En un modelo entidad relación los atributos forma parte importante para que las
entidades se puedan relacionar entre ellas, ya que a través de los atributos
identificadores o conocidos como claves se puede establecer la relación entre las
entidades. El atributo es un tipo de datos que tiene la entidad, este tipo de dato define las
características de la entidad, y así podemos saber cómo se compone la entidad y cuál es
su esencia como tal. Los atributos entonces define las propiedades y características de la
entidad; podemos decir por ejemplo un automóvil es una entidad que posee los
siguientes atributos: marca, es el tipo de dato que define el atributo, Toyota que viene
hacer la marca, es valor que asume el atributo cuando establece una característica de la
marca del automóvil, y así podemos decir de color; es el atributo que define otra
característica del automóvil y rojo el valor que el atributo tomo como una propiedad del
automóvil, podemos decir que hay varios automóviles de la misma marca y color, pero
describiendo las características del automóvil nos dirá que existe solo un tipo de
automóvil y que no existe otro igual dentro de la entidad. La entidad en el modelo
entidad relación se representa por medio de un círculo que rodea a una palabra y que
está conectada a la entidad, de acuerdo al tipo de atributo esta representación puede
variar.
Ejemplos de Diagrama de atributos. Atributos nombre, calle, documento y ciudad son
atributos, propiedades o características de la entidad “cliente”.

1. Especificación de Procesos

Define que debe hacerse para transformar entradas en salidas. Es una descripción
detallada de la política de negocios del usuario que cada burbuja lleva a cabo. La

Prof. Cynthia Rivas Aquino

especificación del proceso es la descripción de qué es lo que sucede en cada proceso
primitivo en el nivel más bajo del DFD.
Existe una variedad de herramientas que podemos utilizar para producir una
especificación de proceso: tablas de decisiones, lenguaje estructurado (español, inglés,
etc.), pre/post condiciones, diagramas de flujo, diagrama de Nassi/Shneiderman, etc. A
pesar d que la mayoría de los analistas están a favor del lenguaje estructurado, debe
21
recordar qué se puede cualquier método mientras satisfaga dos requerimientos cruciales:
 La especificación del proceso debe expresarse de una manera que puedan
verificar tanto el usuario como el analista. Precisamente por esta razón se evita el
lenguaje narrativo como herramienta de especificación: es notoriamente ambiguo, sobre
todo si describe acciones alternativas (decisiones) y acciones repetitivas (ciclos). Por
naturaleza, también tiende a causar gran confusión cuando expresa condiciones
booleanas compuestas (esto es, combinaciones de los operadores booleanos AND, OR y
NOT) (y, o, no, respectivamente).
 El proceso debe especificarse en una forma que pueda ser comunicada
efectivamente al público amplio que esté involucrado. A pesar de que el analista es
típicamente quien escribe la especificación del proceso, habitualmente será un público
bastante diverso de usuarios, administradores, auditores, persona de control de calidad y
otros, el que leerá la especificación de proceso. Una especificación pudiera expresarse
tal vez como cálculo de predicados, o en Pascal, o en un enfoque de diagramación
formal como USE-IT de Higher Order Software, pero de nada sirven esas
especificaciones si la comunidad usuaria se rehúsa a verlas. Lo mismo pudiera suceder
con las tablas de decisiones, con el lenguaje estructurado o con otras herramientas; en
gran medida esto es función de la personalidad, antecedentes y humor de los usuarios
con lo que trate.
Como se mencionó anteriormente, la mayoría de los analistas usan el lenguaje
estructurado como método favorito para escribir especificaciones de proceso. Tal vez
sea más importante señalar que la mayoría de los analistas y de las organizaciones
utilizan una misma herramienta para escribir todas las especificaciones. En esta sección
nos concentraremos en realizar representaciones por medio del lenguaje estructurado.

Lenguaje estructurado
El lenguaje estructurado, como el nombre indica, es “lenguaje español (o ingles u otro)
con estructura”. Es decir, es un subconjunto de todo el idioma con importantes
restricciones sobre el tipo de frases que pueden utilizarse y la manera en que pueden
juntarse dichas frases. También se conoce con nombres como PDL (siglas en ingles de
lenguaje de diseño de programas) y PSL (lenguaje de planteamiento o especificación de
problemas). Su propósito es hacer un balance razonable entre la precisión del lenguaje
formal de programación y la informalidad y legibilidad del lenguaje cotidiano.
Una frase en lenguaje estructurado puede consistir en una ecuación algebraica, por
ejemplo:
X = (Y*Z)/(Q+14)
O en una sencilla frase imperativa que consista en un verbo y un objeto. Nótese que esta
frase no tiene el punto y coma que termina una instrucción en muchos lenguajes de
programación; puede o no terminar con un punto (“.”), dependiendo de sus gustos en
esta materia. Además, note que las frases que describen los cálculos pueden usarse con

Prof. Cynthia Rivas Aquino

prefijos de los verbos CACULAR, AÑADIR, FIJAR, etc., por lo que se pudo haber
escrito el ejemplo anterior así:
CALCULAR X = (Y*Z)/(Q+14)
Y también se tienen cálculos expresados en lenguaje como los siguientes:
FIJAR IMPUESTO A 13
MULTIPLICAR PRECIO UNITARIO POR CANTIDAD 22

DIVIDIR GANANCIAS ACTUALES ENTRE PERDIDAS ACTUALES

Los verbos deben escogerse de entre un pequeño grupo de verbos orientados a la acción
tales como:
CONSEGUIR (o ACEPTAR o LEER)
PONER (o MOSTRAR o ESCRIBIR)
ENCONTRAR (o BUSCAR o LOCALIZAR)
SUMAR
RESTAR
MULTIPLICAR
DIVIDIR
CALCULAR
BORRAR
ENCONTRAR
VALIDAR
MOVER
REEMPLAZAR
FIJAR
ORDENAR

En muchas organizaciones se llega a la conclusión de que entre 40 y 50 verbos son

suficientes para describir cualquier política dentro de una especificación de proceso.
Los objetos (el tema de las frases imperativas sencillas) deben consistir solo en datos
que se han definido en el diccionario o ser términos locales. Los términos individual;
solo son conocidos, relevantes y con significado dentro de dicha especificación de
proceso. Un ejemplo típico de término local es un cálculo intermedio, que se utiliza para
producir una salida final de proceso. Por ejemplo, la especificación de proceso en
lenguaje estructurado que se muestra a continuación examina una serie de registros de
pedidos en el almacén PEDIDOS, para calcular un total diario:
Total diario = 0
HACER MIENTRAS haya más pedidos en PEDIDOS con fecha-de-pedido = fecha de
hoy
LEER el siguiente PEDIDO en PEDIDOS con fecha-de-pedido = fecha de hoy
MOSTRAR a Contabilidad numero-de-pedido, nombre-del-cliente y cantidad-total.
Total-diario = total-diario + cantidad-total
FIN HACER

Prof. Cynthia Rivas Aquino

MOSTRAR a Contabilidad total-diario

Finalmente, el lenguaje estructurado permite que se combinen frases en unas cuantas

formas limitadas que se toman de las construcciones acostumbradas de la programación
estructurada.
La construcción SI-ENTONCES-OTRO se utiliza para describir frases alternativas que 23
se deben realizar según el resultado de la decisión binaria. La construcción SI-
ENTONCES-OTRO puede tomar cualquiera de las formas siguientes:

SI condición-1
Frase-1
FIN SI

O bien
SI condición-1
Frase-1
OTRO
Frase-2
FIN SI

De esta forma, el analista puede escribir;

SI el cliente vive en Nueva York

Añadir cliente a PROSPECTOS-DE-MERCADO
FIN SI

O bien

SI edad-del-cliente es mayor que 65

Fijar cuota a cuota-ancianos
OTRO
Finar cuota a cuota-normal
FIN SI

La construcción CASO se utiliza para describir frases alternativas que se efectuaran

basándose en los resultados de una decisión multivaluada (en contraste con la decisión
binaria que tiene lugar con la construcción SI-ENTONCES). La construcción CASO
toma la forma general.

Prof. Cynthia Rivas Aquino

HACER CASO
CASO variable = valor-1
Frase-1
.
.
. 24

CASO variable = valor-n

Frase-n
OTRO
Frase n+1
FIN CASO

Por lo que analista puede escribir

HACER CASO
CASO edad-del-cliente <13
Fijar cuota a cuota-niños
CASO edad-del-cliente <12 y edad-del-cliente<20
Fijar cuota a cuota-adolescente
CASO edad-del-cliente <19 y edad-del-cliente<65
Fijar cuota a cuota-adultos
CASO edad-del-cliente <13
Fijar cuota a cuota-niños
OTRO
Fijar cuota a cuota-ancianos
FIN CASO

O, como otro ejemplo, considere la siguiente porción de una especificación de proceso en

lenguaje estructurado:
HACER CASO
CASO estado =”NY”
Fijar impuesto-de-venta a 0.0825
CASO estado =”NJ”
Fijar impuesto-de-venta a 0.07
CASO estado =”CA”
Fijar impuesto-de-venta a 0.05
OTRO
Fijar impuesto-de-venta a 0
FIN CASO

Prof. Cynthia Rivas Aquino

Nótese que la cláusula OTRO suele usarse para abarcar situaciones que el usuario se
olvida de especificar y por las que el analista se olvida de pregunta, a menudo llevara a
discusiones entre el usuario y el analista que de otra manera no sucedieran sino hasta
después de puesto en operación el sistema. Considere el siguiente ejemplo:
HACER CASO
CASO forma-de-pago = “efectivo”
25
Fijar descuento a 0.05
CASO forma-de-pago = “tarjeta-de-crédito”
Fijar descuento a 0.01
OTRO
Fijar descuento a 0
FIN CASO
El usuario podría cuestionar esta especificación del proceso y preguntar porque el
analista incluyo el OTRO; el analista pudiera responder preguntado acerca de pagos con
cheque, cheques de viajero, monedas de oro o intercambio.

La construcción HACER MIENTRAS se usa para describir una frase que deberá
llevarse a cabo repetitivamente hasta que alguna condición booleana se haga verdadera.
Toma la forma general:

HACER MIENTRAS condición-1

Frase-1
FIN HACER

La prueba (en el ejemplo anterior, la “condición-1”) se hace antes de que se ejecute la

frase-1, por lo cual, si la condición no se satisface, es posible que la frase-1 se ejecute
cero veces.
Por ejemplo, el analista puede escribir:

HACER MIENTRAS haya más artículos en el pedido-del-cliente

Precio-extendido = precio-unitario*cantidad-de-unidades
FIN HACER

Muchas organizaciones incluyen otra estructura que ejecuta una frase especificada por
lo menos una vez antes de hacer una prueba para ver si debe repetirse. Esta variante,
usualmente conocida como la construcción REPITE-HASTA, tiene la siguiente forma:

REPITE
Frase-1
HASTA condición-1

Prof. Cynthia Rivas Aquino

Se puede construir frases compuestas a partir de combinaciones de frases sencillas y las
estructuras sencillas que se presentaron anteriormente, de acuerdo con las siguientes
reglas:
1. Una secuencia lineal sencilla equivale (estructuralmente) a una frase sencilla.
Asi que la secuencia
Frase-1
26
Frase-2
.
.
.
.
Frase-n
Es estructuralmente equivalente a una frase sencilla única y puede ser sustituida
dondequiera que se espere una frase sencilla. Eso permite construir estructuras como lo
siguiente:
SI condición-1
Frase-1
Frase-2
OTRO
Frase-3
Frase-4
Frase-5
FIN SI

O bien

HACER MIENTRAS condición-1

Frase-1
Frase-2
Frase-3
FIN HACER

2. Una construcción SI-ENTONCES-OTRO sencilla se considera

estructuralmente equivalente a una frase única sencilla. Esto permite que las estructuras
SI-ENTONCES-OTRO se aniden dentro de otras estructuras iguales, o dentro de
estructuras HACER-MIENTRAS, o dentro de estructuras CASO. Por ejemplo:
SI condición-1
Frase-1
SI condición-2
Frase-2
Frase-3

Prof. Cynthia Rivas Aquino

 OTRO
Frase-4
Frase-5
FIN SI
Frase-6
OTRO 27

Frase-7
SI condición-3
Frase-8
FIN SI
Frase-9
FIN SI

3. Una estructura HACER-MIENTRAS sencilla se considera estructuralmente

equivalente a una frase sencilla. Esto permite que las estructuras HACER MIENTRAS
se aniden dentro de otras estructuras iguales, o dentro de estructuras SI-ENTONCES-
OTRO, o dentro de estructuras CASO.
Asi, se puede tener una especificación en lenguaje estructurado de la siguiente
naturaleza:

Gran-total = 0
HACER-MIENTRAS haya más pedidos que procesar
Total-de-pedidos = 0
LEER el siguiente pedido de PEDIDOS
HACER MIENTRAS haya más artículos en el pedido
Total-de-pedidos = tota-de-pedidos + numero-de-articulos
FIN HACER
MOSTRAR numero-de-pedido, total-de-pedidos
Gran-total = gran-total + total-de-pedidos
FIN HACER
MOSTRAR gran-total

4. Una estructura sencilla CASO se considera estructuralmente equivalente a una

frase única sencilla. Esto permite que las estructuras CASO se aniden dentro de otras
iguales, dentro de estructuras SI-ENTONCES-OTRO o dentro de estructuras
HACER-MIENTRAS.

Como puede verse, esto permite construir arbitrariamente descripciones complejas de

políticas de negocios, que a la vez mantienen un control estricto sobre el vocabulario,
organización y estructura de la descripción. Sin embargo, esta complejidad es también
la principal desventaja del lenguaje estructurado: si el analista compone una

Prof. Cynthia Rivas Aquino

 especificación de proceso demasiado compleja para ser entendida y verificada por el
usuario, entonces fallo. Esto usualmente se puede evitar mediante las siguientes reglas:

2. Balanceo de Modelos
i. Definición, Caracterización e Importancia del balanceo de modelo de datos 28
Hemos examinados diversas herramientas de modelado para el análisis de sistemas.
 Diagrama de flujos de datos.
 Diccionario de datos.
 Especificaciones de proceso
 Diagrama de entidad relación.
Cada una de estas herramientas, como hemos visto, se enfoca en un aspecto crítico del
sistema a modelar. Es importancia tener esto en mente, pues significa que quien lee el
modelo también se está enfocando en un aspecto crítico, es decir, el aspecto al cual la
herramienta de modelado está atrayendo su atención. Dado que el sistema tiene tantos
de complejidad, se desea que el diagrama de flujo de datos enfoque la atención del
lector en las funciones del sistema, sin permitir que las relaciones entre datos distraigan
su atención; se desea que el diagrama de entidad-relación enfoque la atención en las
relaciones entre datos, sin permitir distracción por las características funcionales.
Examinaremos varios aspectos importantes del balanceo:
 Balanceo del diagrama de flujo de datos y el diccionario de datos.
 Balanceo del diagrama de flujo de datos y las especificaciones de proceso.
 Balanceo de las especificaciones de proceso y el diccionario de datos.
 Balanceo del DER con el DFD y las especificaciones de proceso.
 Balanceo del DER con el DFD y el diccionario de datos.

Balanceo del DFD y el DD

Las reglas del balanceo del diagrama de flujo de datos y el diccionario de datos son las
siguientes:
 Cada flujo de datos (es decir, cada flecha del DFD) y cada almacén de datos
deben estar definidos en el diccionario de datos. Si falta la definición en el diccionario,
el flujo o el almacén se considera indefinido.
 De manera inversa, cada dato y almacén que se define en el diccionario de datos
debe aparecer en alguna parte del DFD. Di no aparece, dicho dato o almacén es un
“fantasma”, es decir, algo definido pero no se “usa” en el sistema. Esto puede suceder si
los datos se definieron para que correspondieran con una versión temprana del DFD; el
peligro que se corre es que el DFD pueda cambiarse (es decir, un flujo o un almacén
pudiera eliminarse) sin un cambio correspondiente en el diccionario de datos.
Esto significa, desde luego, que el analista debe revisar tanto el DFD como el
diccionario cuidadosamente para asegurarse de que estén balanceados. No importa cual
modelo se examine primero, aunque muchos analistas empiezan con el DFD para
asegurar que todos los datos estén definidos en el diccionario de datos. Como todas las

Prof. Cynthia Rivas Aquino

demás actividades de balanceo es una labor tediosa y que se presta para tener un apoyo
automatizado.

Balanceo del diagrama de flujo de datos y las especificaciones de proceso

Las reglas para el balanceo del DFD y EP, son:
 Cada burbuja del DFD debe asociarse con un DFD de nivel inferior o con una 29
especificación de proceso, pero no ambos. Si el DFD muestra una burbuja que se
identifica como 1.4.2, entonces debe existir ya sea una figura correspondiente
identificada como 1.4.2, cuyas burbujas se identifiquen como 1.4.2.1, 1.4.2.2, etc., o
bien la especificación estructurada debe contener una especificación de proceso para la
burbuja 1.4.2. si bien ambas existen, el modelo es innecesario y peligrosamente
redundante.
 Cada especificación de proceso debe tener una burbuja de nivel superior
asociada en el DFD. Dado que la especificación de proceso requiere de mucho trabajo,
podrías pensarse que es altamente improbable que existan especificaciones de proceso
“vagabundas” rondando por el sistema. Pero puede suceder: la especificación del
proceso pudiera haberse escrito para una versión preliminar del DFD, tras lo cual es
proceso de revisión pudo eliminar algunas de las burbujas del DFD.
 Las entradas y salidas deben coincidir. El DFD, muestra flujos de entrada y
salida para cada burbuja, al igual que las conexiones con los almacenes. Eso debe ser
evidente en las especificación de proceso también: así, se puede esperar una declaración
READ (o GET, o INPUT o ACCEPT, o algún verbo similar) correspondiente a cada
flujo de entrada, y WRITE (o PUT o DISPLAY, etc) para cada flujo de salida.
Observe que estos comentarios se aplican específicamente a las burbujas de proceso.

Balanceo entre las especificaciones de proceso con el DFD y el DD

Las reglas para balancear las especificaciones de proceso con el diagrama de flujo de
datos y el diccionario de datos son las siguientes; Cada referencia de un dato en la
especificación de proceso (típicamente, un sustantivo) debe satisfacer una de las
siguientes reglas.

· Coincide con el nombre de un flujo de datos o almacén conectado a la burbuja descrita

por la especificación de proceso, o

· Es un término local, definido explícitamente en la especificación de proceso, o

· Aparece como componente en una entrante del diccionario de datos para un flujo o
almacén conectado con la burbuja. Así, los datos X y Y aparecen en la especificación de
proceso, pero no aparecen como flujo de datos conectado en el DFD que se muestra en
la figura siguiente. Sin embargo, el diccionario de datos, indica que X y Y son
componentes de Z: y en la figura vemos que Z es en efecto un flujo de datos conectado
a la burbuja, por lo que concluimos que el modelo está balanceado.

Prof. Cynthia Rivas Aquino

Balanceo del diccionario de datos con el DFD y las especificaciones del proceso

Puede verse que el diccionario de datos es consistente con el resto del modelo si
obedece la siguiente regla:

Cada entrada del diccionario de datos debe tener referencia en una especificación de
proceso, un DFD, u otro diccionario de datos. 30

Esto supone, desde luego, que se está modelando el comportamiento esencial de un

sistema del diccionario de datos complejo y exhaustivo de una implantación existente de
un sistema puede contener algunos datos, que ya no se usan.

También se podría argumentar, que el diccionario de datos se planee de forma tal que
permita una expansión futura; es decir, que contenga elementos que no se cumplen hoy
pero que pudieran ser útiles en un futuro. Un buen ejemplo de esto es un diccionario de
datos con elementos que puedan ser útiles para consultas ad hoc (En sentido amplio, ad
hoc puede traducirse como «específico» o «específicamente», o «especial,
especializado»). El equipo del proyecto, tal vez en conjunción con el usuario, debe
determinar si este tipo de modelo no balanceado es lo apropiado. Sin embargo, es
importante por lo menos estar enterada de tales decisiones deliberadas.

Balanceo del DER con el DFD y las especificaciones de proceso

El diagrama de entidad-relación, presentaba una visión muy distinta del sistema de la

del DFD. Sin embargo, existen algunas relaciones que deben darse para que el sistema
global sea completo, correcto y consistente.

· Cada almacén del DFD debe corresponder con un tipo de objeto; una acción o una
combinación de un tipo de objeto y una relación (es decir el tipo asociativo de objeto)
en el DER. Si en el DFD existe un almacén que no aparece en el DER, algo anda mal; y
si hay un objeto o relación en el DER que no aparece en el DFD, algo anda mal.

· Los nombres de objetos en el DER y los nombres de almacenes de datos en el DFD

deben coincidir.

· Las entradas del diccionario de datos deben aplicarse tanto al modelo de DFD como al
de DER. Así, la entrada del diccionario de datos para el ejemplo anterior debe incluir
definiciones tanto para el objeto del DER como para el almacén del DFU. Esto lleva a
una definición de diccionario de datos como la siguiente:

CLENTES = {CLIENTE}
CLIENTE = nombre + domicilio + número-telefónico +...

Las entradas del diccionario de datos para la forma singular (por ejemplo, CLIENTE)
deben proporcionar el significado y composición de una sola instancia del conjunto de

Prof. Cynthia Rivas Aquino

objetos a los que se refiere (en singular) en el DER, y (en plural) en el almacén del
DFD. Las entradas del diccionario para la forma plural (por ejemplo: CLIENTES)
proporcionan significado a la composición de un conjunto de instancias.

De manera similar, hay reglas que aseguran que el DER sea consistente con la porción
de la especificación de proceso del modelo orientado a las funciones (tenga en mente
que las especificaciones de proceso son las componentes detallados del modelo cuya 31
"encarnación" gráfica es el DFD). Las reglas son que el conjunto combinado de todas
las especificaciones de proceso deben, en su totalidad.

· Crear y eliminar instancias de cada tipo de objeto y relación que se muestra en el DER.
Esto puede entenderse viendo el DFD de la figura siguiente y como se sabe, el almacén
CLIENTES corresponde al objeto CLIENTE. Algo debe ser capaz de crear y eliminar
instancias de un cliente, lo cual significa que alguna burbuja en el DFD debe tener un
flujo de datos conectado con el almacén CLIENTES. Pero el trabajo mismo de escribir
el almacén (es decir, crear o. eliminar una instancia del objeto CLIENTE relacionado en
el DER) debe darse dentro de la burbuja, lo cual significa que debe documentarse en la
especificación de proceso asociada con ella.

Alguna burbuja del DFD define valores para cada dato asignado a cada instancia de
cada tipo de objeto, y algún proceso del DFD usa (o lee) valores de cada dato.

Prof. Cynthia Rivas Aquino

 Bibliografía
 YOURDON, E. 1993. ANÁLISIS ESTRUCTURADO MODERNO. 1ra.
32
Edición. México. Prentice-Hall Hispanoamericana, S.A.
 KENDALL, KENNETH E. Y KENDALL, JULIE E. 2011. Análisis y diseño
de sistemas. Octava edición- México, PEARSON EDUCACIÓN

Prof. Cynthia Rivas Aquino