UNIDAD II

ANÁLISIS Y DISEÑO DE SISTEMAS

MODELO DE PROCESO DE
DATOS Y ORIENTACION A
OBJETOS
Modelo y estructurado de datos
Unidad II: Análisis y Diseño de sistemas

En el proceso de análisis y diseño de un sistema, es necesario observar, recolectar e interpretar

información para decidir la dirección a tomar en el proyecto. Dicha información tiene diversas
naturalezas:

Problemas en la organización: Investigar el comportamiento de los empleados y escuchar opiniones

de fuentes externas son valiosas herramientas para detectar problemas. Al reaccionar a los problemas
en la organización, el analista de sistemas desempeña los roles de consultor, experto de soporte y
agente de cambio.

Identificación de las necesidades: El analista primero define los problemas y objetivos en el sistema.
Éstos forman la base para determinar qué debe lograr el sistema. Las cuestiones referentes a los
posibles problemas que se podrían presentar son la situación actual y los objetivos planteados son la
situación deseada.

Ejemplos de preguntas que podrían aplicarse para poder identificar las necesidades:

a) ¿Cuáles son los propósitos de la empresa?

b) ¿Es una empresa con o sin fines de lucro?
c) ¿Planea la compañía crecer o expandirse?
d) ¿Cuál es la postura de la empresa (cultura) en cuanto a la tecnología?
e) ¿Cuál es el presupuesto que la empresa tiene asignado para la TI?
f) ¿El personal de la empresa tiene la experiencia requerida?

Planteamiento del problema: Contiene los requerimientos, lo que se debe lograr, junto con las
posibles soluciones y las restricciones que limitan el desarrollo del sistema. Los requerimientos
pueden incluir seguridad, capacidad de uso, requerimientos gubernamentales, etc.

Estudio de viabilidad: La evaluación de la viabilidad es efectiva para descartar proyectos

inconsistentes con los objetivos de la empresa, que requieran una capacidad técnica imposible o que
no tengan ninguna recompensa económica. Aunque es minucioso, el estudio de la viabilidad es algo
que vale la pena ya que ahorra tiempo y dinero a las empresas y a los analistas de sistemas. Para que
el analista pueda recomendar que se continúe con el desarrollo de un proyecto, éste debe mostrar que
es viable en las tres siguientes formas: técnica, económica y operacional.

Viabilidad técnica: El analista debe averiguar si es posible desarrollar el nuevo sistema

teniendo en cuenta los recursos técnicos actuales. Si esto no pudiera ser así, ¿se puede actualizar o
complementar el sistema de tal forma que pueda cumplir con lo que se requiere? Si no es posible
actualizar los sistemas existentes, la siguiente pregunta sería si existe o no la tecnología que cumpla
con las especificaciones técnicas. Al mismo tiempo, el analista puede preguntar si la organización
cuenta con el personal informático calificado para lograr los objetivos. De no ser así, la pregunta es
si pueden o no contratar programadores, expertos o demás personal adicional necesarios, o si tal vez
puedan contratar personal tercerizado que se haga cargo del proyecto. En todo caso, se podría
investigar si hay o no paquetes de software disponibles que puedan lograr sus objetivos.
 Viabilidad económica: La viabilidad económica es el análisis que se debe realizar
posteriormente a la viabilidad técnica. Los recursos básicos que se deben considerar son el tiempo
del analista y el tiempo de su equipo de análisis de sistema, el costo de realizar un estudio de sistemas
completo, el costo del tiempo del empleado de la empresa, el costo estimado del hardware y el costo
estimado del software o del desarrollo de software que se pretende llevar a cabo, y además el costo
de las posibles soluciones vistas en el análisis de viabilidad técnica.

Viabilidad operacional: Una vez evaluados la factibilidad técnica y económica, se debe

evaluar la viabilidad operacional que implica a los recursos humanos disponibles para el proyecto
como así también a la actividad de pronosticar si el sistema funcionará y será utilizado. Se debe tener
en cuenta que si los usuarios están muy acostumbrados con el sistema actual, no identifican problema,
puede ocurrir que no quieran involucrase en el proceso de solicitar un nuevo sistema, y habrá mucha
resistencia a la implementación del nuevo sistema, pero en cambio sí son los mismos usuarios quienes
han expresado la necesidad de un nuevo sistema que sustituya al vigente, a los efectos de que le sea
más eficiente y accesible, hay más probabilidades de que el sistema solicitado llegue a utilizarse.

Diagrama de flujo de datos (DFD)

Esta es una herramienta que proporciona un panorama como una red de procesos funcionales,
lo cual genera una conexión como una red de datos. El diagrama de flujo de datos tiene los siguientes
sinónimos:
 Carta de burbujas
 DFD
 Diagrama de burbujas
 Modelo de Procesos
 Diagrama de flujo de trabajo
 Modelo de función

Se utilizaron por primera vez en la ingeniería de software para el estudio del diseño de
sistemas. Hasta hoy día los DFD continúan siendo utilizados por los ingenieros de software que
trabajan en la implantación de modelos de los requerimientos del usuario para un futuro desarrollo de
software.
Los DFD no sólo se pueden utilizar para modelar sistemas de proceso de información, sino
también como manera de modelar organizaciones enteras, es decir, se lo puede utilizar también como
herramienta para la planeación estratégica y de negocios.
Los DFD representan a su vez una notación, para modelar sistemas de tiempo real (es decir,
flujos de control y procesos de control). Generalmente no se ocupa sólo de los sistemas dirigidos a
los negocios, sino que también a una variedad de sistemas científicos y de ingeniería.
Estructura de un DFD

El DFD se compone de los siguientes elementos:

Proceso: Sinónimos comunes son burbuja, función o transformación. El proceso muestra una parte
del sistema que transforma los datos de entradas en salidas. Según el gráfico descrito, algunos
analistas prefieren usar óvalo o un rectángulo con esquinas redondeadas, y otros prefieren usar un
rectángulo. Las diferencias entre estas tres formas son básicamente estéticas, aunque es importante
usar la misma forma de manera consistente para representar todos los procesos del sistema.

El proceso se nombra o describe con una sola palabra, frase u oración sencilla. Por medio del
nombre se describe lo que hace. Es importante recalcar que un buen nombre de proceso, generalmente
consiste en una frase verbo-objeto tal como GENERAR ENTRADA u OBTENER IMPUESTO.
En algunas ocasiones describe quién o qué está efectuando.
Flujo: Representado por una flecha, se usa para describir el movimiento o paquete de información
desde una parte del sistema a otra, los mismos representan datos en movimiento.
Estos datos pueden consistir en: bits, caracteres, mensajes y los diversos otros tipos de
información como lo que la computadora puede operar.
Los flujos por lo general se nombran, y el nombre representa el paquete de datos que se mueve
a lo largo del flujo.
Los datos del flujo podrían dirigirse hacia otros componentes, como lo son: a un almacén o a
un terminador y en caso de que el diagrama tratase de un modelado de Sistema en Tiempo real,
entonces el flujo podría estar dirigiéndose hacia otro proceso.

Existen tres tipos de flujo:

a) Flujo de diálogo o doble cabeza: indica empaquetado de datos de dos extremos (pregunta
y respuesta), haciendo uso de un solo flujo. En el caso de flujo de diálogo, ambos extremos del flujo
deben nombrarse.

b) Flujo Divergente: es cuando un solo flujo puede dividirse en otros varios flujos. El flujo
divergente, significa que se están mandando duplicados de paquetes de datos a diferentes partes del
sistema, o se lo puede utilizar también para representar la división de un conjunto de datos
individuales, donde cada uno de los éstos paquetes se está enviando a diferentes partes del sistema.
 c) Flujo convergente: varios paquetes de datos se unen para formar un solo agregado de
datos. Provienen los paquetes de datos de diversos orígenes y se agrupan para ir a un solo destino.

Almacén: Se utiliza para representar una colección de datos en reposo, gráficamente se tiene como
dos líneas paralelas, o una caja con un cuadro demarcado a la izquierda. La forma de escribir el
nombre de los almacenes, es el plural del nombre de los flujos que se utilizan para presentar a los
datos que entran y salen de él, y por lo general se escribe todo en mayúscula.

Los datos que registra un almacén representan los datos de todo lo

que queremos registrar, como ser datos personales, datos de artículos, pedidos de un cliente, por
mencionar alguno de los ejemplos. Los almacenes se conectan por flujos a los procesos, donde se
puede tener un flujo desde un almacén, y otro flujo en dirección al almacén que salen de algún
proceso.
En ocasiones se podría utilizar flujos sin etiquetarse, principalmente cuando los datos que
salen o entran contienen todos los valores que el almacén debe registrar como datos. Un flujo sin
etiqueta se representa como una lectura o un acceso a la información del almacén, por lo tanto se
podría afirmar que se recupera del almacén un solo paquete de datos.

Según sea el sentido que tenga el flujo hacia o desde el almacén, el mismo podría tener los
siguientes significados:

 Se están guardando uno o más datos en el almacén.

 Uno o más datos del almacén requieren ser borrados.
 Uno o más datos del almacén se están extrayendo.
 Uno o más datos del almacén se están modificando o cambiando.

Un aspecto que se debe de tener en cuenta es que los flujos transportan datos que sólo el
almacén es capaz de guardar, es por esto que un flujo conectado a un almacén CLIENTES, sólo puede
transportar información relacionada a los clientes, y cuyos campos de valores se van a tener en cuenta
en una posible tabla de la base de datos, pues cada almacén representa a una tabla en la BD.
Terminador: Se lo representa con un rectángulo. Son entidades externas con las cuales el sistema se
comunica. Este podría consistir en una persona, grupo de personas, una organización externa, un
determinado departamento de la empresa, también podría ser la representación de un sistema externo
al que se está modelando, y desde donde se querría capturar datos.
En ocasiones, es el propio usuario quien representaría a un terminador, pues tendría la
necesidad de suministrar al sistema determinados datos, de tal modo a que sean transformados en
información, esa información representa un conjunto de datos asociados visibles en el monitor del
computador, o de modo impreso, en papel que se obtiene de la impresora. Cuando el usuario se
considera parte del sistema, ayuda a identificar los terminadores relevantes, es por ello, que el
departamento de contabilidad y el departamento de finanzas son terminadores con los cuales se
comunica el sistema.

Las reglas a seguir para graficar un DFD adecuado son:

 Se debe escoger nombres fáciles de recordar y que vayan en relación directa con el sistema,
tanto para los procesos, flujos, almacenes y terminadores.
 Se debe enumerar los procesos.
 El DFD se debe rehacer las veces que sea conveniente de tal modo a que refleje exactamente
el funcionamiento del sistema que será plasmado en un proyecto de software.
 La representación de los datos que se transportan de un lugar a otro por medio de los flujos
deberían de ser consistentes, es por ello que se debería de evitar procesos o flujos sin etiquetar,
burbujas que tienen entradas, pero no salidas (sumideros infinitos), o burbujas que tienen
salidas sin tener entradas (generadores espontáneos).

DFD por niveles

Si el sistema es complejo y tiene docenas o cientos de funciones que se precisan sean

representados por medio del diagrama, para éste propósito se debería de desglosar el DFD en niveles,
de modo a que cada nivel proporcione el detalle de las funciones del nivel anterior.

Diagrama de contexto: También llamado DFD de primer nivel, consta sólo de una burbuja, el cual
representa al sistema como un todo; los flujos de datos representan a la interfaz entre el sistema y los
terminadores externos.

Diagrama cero (o nivel 1): Representa a las funciones de más alto nivel, cada proceso a partir de
éste primer nivel deben estar enumerados para que puedan ser referenciados en la subdivisión de
niveles.

Diagrama por niveles: Representan a la subdivisión de los procesos del diagrama cero, es así que la
burbuja 2 del diagrama 0, se lo podría dividir dependiendo de su complejidad, en 2.1, 2.2, 2.3, y así
sucesivamente.
Cuando surja la necesidad de volver a subdividir el nivel 2, debido a que el sistema es muy
complejo, entonces podríamos tener un tercer nivel: 2.2.1, 2.2.2…
Si un proceso 2.2 tiene un nombre de “CALCULAR IMPUESTO DE VENTA”, entonces al
diagrama que surge de la división del éste proceso, se lo debe llamar como: “Proceso o Figura 2.2:
CALCULAR IMPUESTO DE VENTA”.
Ejemplo de un DFD. Contexto: Sistema de gestión bibliotecario

Para la gestión de préstamos, el socio presenta el carnet de socio de la biblioteca y realiza el

pedido de préstamo correspondiente. Una vez entregados el carnet y realizado el pedido, el sistema
comprobará primeramente los datos y aceptará la petición de los libros solicitados siempre que el
libro se encuentre disponible para el préstamo, es decir, cuando haya ejemplares disponibles. Si se
acepta la petición, se decrementa el número de unidades de los libros de la biblioteca y se registra el
préstamo. Para las Devoluciones de libro, un socio no puede realizar más peticiones hasta que no
haya efectuado todas las devoluciones de la petición anterior. El socio para hacer la petición, necesita
el carnet, que no se le entrega hasta que no haya devuelto todos los libros. Cuando un socio realice
una devolución, el sistema actualizará el stock de libros y comprobará la fecha de devolución de cada
ejemplar, y en el caso de que la devolución se haga fuera del tiempo establecido, se aplicará una
sanción o multa por cada ejemplar y los días de retraso en la devolución. En este caso, la sanción se
emite cuando el socio entrega el último libro. El bibliotecario se encarga de las altas y bajas de los
libros de la biblioteca.

Observación: Si bien el orden de visualización es a partir del Diagrama de Contexto, éste no

es el primer diagrama que se resuelve, pues es muy difícil identificar todos los flujos y procesos
necesarios para la representación de las funciones del sistema en su totalidad, es por ello que se lo
resuelve al final, o al menos luego de la elaboración del diagrama 0 o Nv. 1.

Diagrama de contexto (resuelto al final, luego de los otros diagramas)

Diagrama 0 o Nivel 1

De
éste diagrama, es preciso descomponer el proceso 2, para poder presentar las operaciones que
implican la gestión de devoluciones, además se crea un nuevo almacén en el proceso. Las flechas
reciben y envían datos a los terminadores.

Diagrama Nivel 2 (del proceso 2: GESTIONAR DEVOLUCIONES)

Diccionario de datos

El diccionario de datos es un listado organizado alfabéticamente de todos los datos

correspondientes al sistema, con definiciones claras para que tanto el usuario como el analista tengan
un manejo común del significado de todas las entradas, salidas, componentes de almacenes y cálculos
intermedios.

En el DD se registran:

 El significado de los flujos y almacenes.

 Contenido de los flujos de datos, que se mueven a lo largo de los flujos, por ejemplo el
domicilio de un cliente, el cual puede descomponerse a su vez otras unidades más.
 Descripción del contenido de los almacenes.
 Identifica los valores y unidades de información en los flujos de datos y en los almacenes de
datos.
 Los detalles de las relaciones entre almacenes que se tendrán en el diagrama entidad-relación
(DER).

En el DD se utilizan diversos símbolos:

Símbolo Significado
= Se interpreta / se compone de:
+ Concatena datos
() Representa datos optativos
{} Cantidad, se usa para indicar que un dato requiere de un número o cantidad (ej.
número de artículos)
[] Alternativas de datos, de las cuales debe escogerse una
** Delimita comentarios - *Esto sería un comentario*
@ Identifica un campo clave (key)
| Separa las alternativas (símbolo de OR)

Ejemplo de DD:
nombre cliente = nombre + (segundo nombre) + apellido
peso paciente = nombre paciente + edad + peso
sexo = *valores [M | F]*
domicilio del cliente = [domicilio particular + domicilio laboral] +
(domicilio opcional)
pedido cliente = nombre del cliente + dirección + {articulo}

En la iteración de {articulo} se está haciendo referencia a que un determinado cliente podría

estar pidiendo 0 o más artículos, también se podría especificar límite inferior o superior, tal como:
pedido cliente = nombre del cliente + dirección + 1{articulo} 10
Esto indica un mínimo de uno y un máximo de diez.
De esta forma, otras limitaciones de ejemplo serían:

ejemplo = 1{b} *mínimo uno sin límite superior*

ejemplo = {b} 10 *sin mínimo (0), máximo diez*
ejemplo = {b} *sin mínimo ni máximo*

Con respecto a las alternativas, las opciones que se tengan se encierran entre corchete, y se
separan las alternativas con una barra vertical. Ejemplo:

sexo = [Femenino | Masculino]

tipo de cliente = [Gobierno | Industrial | Educativo | Otro]

Otro elemento adicional que se tiene dentro de Diccionario de Datos es el alias, pero no es
muy utilizado, porque cuando se trata de modelar proyectos grandes podría atraer confusión. Es así
que cuando se tiene por ejemplo diversos grupos de usuarios en diferentes dependencias o
ubicaciones, se desea utilizar diferentes nombres para referirse a lo mismo, por tanto podríamos
utilizar el vocablo de comprador para referirnos a cliente, y en el Diccionario de Datos, lo podríamos
representar de la siguiente manera:

Comprador = *alias de cliente*

El Diccionario de Datos, así como el Diccionario que se conoce, debe estar ordenado
alfabéticamente en la documentación del modelado del sistema.

Observemos nuevamente el diagrama cero del ejemplo bibliotecario, y a continuación el

diccionario de datos generado a partir del mismo:
altas/bajas libros = {libros}
*se ingresan todos los libros que salen como parte de un préstamo o ingresan
como parte de una devolución*

devolución libros = código préstamo + fecha de préstamo + código de libro

+ fecha de devolución + {libro}

FICHAS PRÉSTAMO = @código fichas préstamo + pedido libros

LIBROS DISPONIBLES = @libros disponibles + código libro + {libros} +

editorial + edición + año publicación + costo de compra

Pedido libros = código cliente + descripción pedido + {libro} + autor

Sanción = código devolución + fecha préstamo + fecha devolución + días de

atraso + monto sanción

En ésta presentación del Diccionario de Datos, aparecen los almacenes, como se verá, los
mismos por lo general se escriben en mayúscula y en plural. Sólo en la representación de almacenes
se utiliza el símbolo @ para indicar cuál es el campo clave (key).
Notemos como en el caso de Sanción (la cual no es almacén), no se usa @ en el código de
devolución.
Especificación funcional del proceso

La especificación de proceso representa la descripción de los eventos que ocurren en un

determinado proceso que corresponde a una burbuja primitiva, son los procesos de más bajo nivel del
DFD si es que el DFD tiene subdivisión de procesos.
En caso de no contar con subdivisión, la especificación de proceso debe realizarse de cada
proceso que se tiene en el Diagrama Cero. Básicamente, Edward Yourdon define que la especificación
de proceso sirve para indicar que es lo que se debe hacer a los efectos de transformar los datos de
entrada en salida.
Existen varias herramientas para realizar la especificación de proceso, tales como:

 Lenguaje estructurado
 Pre/post condiciones
 Tablas de decisiones
 Diagramas de flujo
 Diagrama de Nassi/Shneiderman

La selección de una de las herramientas debe ser siempre y cuando satisfaga los siguientes
requerimientos:

1. La especificación de proceso debe expresarse de una manera que pueda ser interpretada
tanto por el usuario como por el analista de sistema. Si el usuario no llega a comprender lo descrito,
difícilmente podrían llegar a un acuerdo.

2. El proceso debe especificarse de una forma que pueda ser comunicada a un amplio público.
Se entiende que el Analista es quién habitualmente escribe la especificación de proceso. Por lo general
se tiene un público bastante heterogéneo de usuarios, administradores, auditores, entre otros, que se
encargará de leer e interpretar.

Un aspecto importante a considerar es que una buena herramienta de especificación no debe

imponer decisiones de diseño o implantación de manera forzada. En determinadas ocasiones el
analista querrá imponer la forma de cómo van a ir generando los pasos en el proceso, pero sin
embargo, del usuario es de quien depende la política que se debe implantar en cada burbuja del DFD.

Las herramientas para especificación de proceso en detalle son:

Lenguaje estructurado: Generalmente en inglés, pero se puede usar igualmente el lenguaje local
preferico. Se trata de una estructura de pseudocódigo, pero más flexible y fácil de ser interpretada por
un usuario no informático.
También se lo conoce con nombres como PDL (Program Design Languaje) y PSL (Problem
Specification Language).
Tiene como propósito buscar un balance entre la precisión del lenguaje formal de
programación y la informalidad o legibilidad del lenguaje cotidiano.
 Los verbos que podrían escogerse de entre un grupo pequeño de verbos, son:

LEER, CONSEGUIR/OBTENER, PONER, ENCONTRAR, SUMAR, RESTAR, MULTIPLICAR,

DIVIDIR, CALCULAR, BORRAR

Entre las formas de plantear el Lenguaje Estructurado en español, por ejemplo hay:

a) Hacer mientras → Fin hacer (Do while → End Do)

total-diario = 0
HACER MIENTRAS haya más pedidos en PEDIDOS con fecha-de-pedido = hoy
LEER el el siguiente PEDIDO en PEDIDOS con fecha-de-pedido = hoy
MOSTRAR a Contabilidad número de pedido, nombre-del-cliente y
cantidad-total, total-diario = total-diario + cantidad total
FIN HACER

MOSTRAR a Contabilidad total-diario

b) Si → Fin si (If → end if)

SI el cliente vive en "New York"

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

o bien

SI edad-cliente es mayor que 65

fijar cuota a cuota-tercera-edad
SINO
fijar cuota a cuota-regular
FIN SI

c) Caso (Case)

HACER CASO
CASO edad-cliente < 13
fijar cuota a cuota-menores
CASO edad-cliente >= 13 y edad-cliente < 20
fijar cuota a cuota-adolescentes
CASO edad-cliente >=20 y edad-cliente < 65
fijar cuota a cuota-adultos
OTRO
fijar cuota a cuota-tercera-edad
FIN CASO
Pre/post condiciones: Las pre/post condiciones son una manera práctica de describir la función que
debe realizar cada proceso, utilizando sólo parte de la estructura de un algoritmo o procedimiento.

Por tanto, ésta forma de representar un proceso es útil cuando:

 El usuario tiene su forma de interpretar la representación de un algoritmo o procedimiento,

que no sea necesariamente la estructura del lenguaje estructurado.
 El analista es consciente de que existen muchos algoritmos distintos que podrían utilizarse.
 El programador tiene suficiente conocimiento sobre algoritmos por tanto no le importa mucho
acerca de los detalles de la estructura de datos que se debería de ejecutar dentro de la
especificación del proceso.

ESPECIFICACIÓN DE PROCESO: CALCULAR IMPUESTO SOBRE VENTAS

Precondición 1
Ocurre DATOS-VENTA con TIPO-ITEM que corresponde con CATEGORIA-ITEM en
CATEGORIAS-IMPUESTO

Postcondición 1
IMPUESTO-SOBRE-VENTAse hace igual a MONTO-VENTA * IMPUESTO

Precondición 2
Ocurre DATOS-VENTA con TIPO-ITEM que no concuerda con CATEGORIA-ITEM en
CATEGORIAS-IMPUESTO

Postcondición 2
Se genera MENSAJE-ERROR

Existen dos partes principales de los cuales se compone la especificación de proceso:

Precondiciones y Postcondiciones.
Las precondiciones describen todos los eventos que deben darse antes de que el proceso se
ejecute. En las precondiciones se leen todas las entradas de datos (que son los flujos), se analizan para
determinar qué acción o acciones se deberían de ejecutar.
Las postcondiciones describen lo que debe suceder cuando el proceso haya concluido, las
salidas que el proceso generará o producirá, las relaciones que existen entre los valores de salida y
los valores de entrada, así también las relaciones que tiene los valores de salida, con los valores de
uno o varios elementos del almacén. También se tienen en cuenta los cambios que se hayan dado en
los almacenes: tales como nuevos artículos añadidos, artículos existentes que se hayan modificado, o
artículos existentes que se hayan eliminado.

Las Pre/Post condiciones constan de dos partes, la primera trata de las condiciones y acciones
que deberían de ejecutarse cuando se cumple la condición que se desea obtener (o sea una operación
o transacción exitosa), y la segunda parte trata de las condiciones y acciones que pudieran arrojar un
determinado error, o se despliega un mensaje de que lo que se busca no está disponible. En la
descripción de la especificación, los flujos se representan con los nombres en minúscula, mientras
que los procesos se representan en mayúscula y en plural. Es la misma forma de identificación que la
del Lenguaje Estructurado.
Tablas de decisión: Existen situaciones donde ni el lenguaje estructurado ni las pre/post condiciones
son adecuadas para escribir especificaciones de proceso. Esto ocurre sobre todo cuando el proceso
debe de producir alguna salida o realizar alguna acción basada en decisiones complejas.
Se utiliza cuando se tenga que analizar varios valores de entrada de manera simultánea, ya
que expresándolo con los dos métodos anteriores se obtendría un material muy extenso y complejo.

1 2 3 4 5 6 7 8
Edad >=20 S S S S N N N N
Sexo M M F F M M F F
Peso >=100 S N S N S N S N
Medicamente 1 X X X
Medicamento 2 X X
Medicamento 3 X X X
Sin medicamento X X

Para éste caso propuesto de especificación de proceso, se requiere evaluar datos booleanos,
que en una tabla es más representativa. En el ejemplo, S y N indican sí o no, siendo valores booleanos
TRUE y FALSE respectivamente.
Cuando el analista entrega la tabla al diseñador/programador, esto genera una libertad en
cuanto a la elección de términos o estrategias de formas de ser implantados. A las tablas de decisiones,
se los conoce también como una herramienta de modelado de sistemas sin especificación de
procedimiento, ya que por medio de la tabla no se específica ningún algoritmo de procedimiento
específico para realizar las acciones que se requieran.

Otras herramientas de especificación de proceso que prácticamente no se utilizan, pero que

Edward Yourdon propone para su utilización son:

Gráficas y diagramas: Si con las herramientas anteriormente mencionadas no se puede expresar una
especificación de proceso, entonces, se podría utilizar una gráfica o diagrama. Lo más común es que
el usuario mismo ya traiga consigo el gráfico que quisiera que el sistema lo realice. Ejemplos de
gráficos serían reportes mensuales, censos, tablas de encuestas, estadísticas de clientela y productos,
etc.

Lenguaje narrativo: Es la descripción más coloquial posible – sin reglas, restricciones o formatos,
lo que permite ser fácilmente interpretada, pero también extensa. Sin embargo, no es una herramienta
recomendable para escribir especificaciones de proceso, por los siguientes motivos:

 Un vocabulario no restringido, lo que hace a que ciertos términos no estén incluidos en el

Diccionario de Datos, y que su significado, no quede claro.
 Las acciones alternativas, son representadas de manera ambigua, más aún si las mismas se
encuentran anidadas.
 No se puede tener estructuras por bloques como lo requiere un ciclo de bucle o una
condicional.
Diagramas de flujo: Los diagramas de flujo se utilizan para describir la lógica detallada por medio
de una simbología estandarizada y estructurada.
La limitación que se tiene con esta herramienta es que en caso de que las funciones que sean
representadas en un proceso sean muy extensas, el gráfico del diagrama abarcaría varias páginas,
complicando la interpretación.

Diagrama de Nassi-Shneiderman: Resulta ambiguo para la representación de procesos que sean lo

suficientemente extensos, pues requiere de una gran cantidad de espacio.
Diagrama Entidad Relación (DER)

El DER resalta las relaciones entre almacenes de datos en el DFD que de otra forma se
hubieran visto sólo en la especificación de proceso. Gráficamente, se lo representa en forma de
rectángulos, el cual corresponde a un almacén de datos en un DFD, y puede verse que hay relaciones
(conexiones) que normalmente no se aprecian en un DFD.
Esto se debe a que el DFD representa a las funciones que el sistema efectúa, no así a los datos
que deben almacenarse.
Se compone de:

 Tipos de objetos
 Relaciones
 Indicadores asociativos de tipo de objeto
 Indicadores de supertipo/subtipo

El tipo de objeto está representado por un rectángulo, y tiene un nombre único con el que se
diferencia uno de otro, cada uno de ellos tiene un importante papel dentro del sistema que se
construye.
Los datos que debe almacenar cada tipo de objeto deben ser únicos, si se tiene un tipo de
objeto Cliente, y dentro de él se almacenan dos nombres de clientes iguales que se refieren a la misma
persona, entonces el objeto tipo de cliente, no cumple con su razón de ser, la cual es almacenar datos
sin duplicarse.
Cada tipo de objeto se declara, porque sin su existencia el sistema no podría operar, o no
podría dar los resultados que se está esperando. Cada uno debe de contener uno o más datos referente
al tiempo de dato que se describe, si definimos un tipo de objeto de nombre CLIENTE, entonces
debemos pensar en que debemos de registrar el nombre, domicilio, límite de crédito, número de
teléfono, etc. Los tipos de objetos pueden representar algo tangible como personas, ciudades u
objetos; o algo intangible, tales como horarios, planes, estrategias, etc.

Los objetos se conectan mediante relaciones, que representan un conjunto de conexiones. La

descripción del motivo que los relaciona, se escribe dentro un rombo, tal como se observa en la
siguiente figura:

La relación
representa un conjunto de conexiones, es una asociación entre cero o más ocurrencias de un objeto,
y cero o más ocurrencias del otro. Es así que la figura indica que un CLIENTE, puede comprar entre
1, 2, 3... a n artículos. También se puede tener más de una relación entre dos objetos, es así que vemos
las relaciones entre PACIENTE y un MÉDICO, cada vez que el médico trata al paciente, le cobra con
un recibo.
Otra situación que se podría presentar, es que se podría tener múltiples relaciones entre
múltiples objetos.
Tipos de relaciones

Las relaciones entre los tipos de objetos, son multidireccionales, lo cual significa que puede
leerse en cualquier dirección, y por defecto no muestran la cardinalidad, es decir no muestra el número
de objetos que participan en la relación.
Como notación alternativa, se pudiera mostrar tanto la cardinalidad como la ordinalidad, de
los números de elementos que se asocian uno objeto con otro.

Ejemplo de relación uno a

varios (1 → n)

En éste tipo de relación, un lado del objeto se relaciona con varios elementos del otro objeto
con el cual interactúa, es así que un cliente puede tener varios artículos, pero un artículo, corresponde
a un solo cliente.

En la relación uno a uno (1 → 1), solamente un elemento de un objeto se asocia con otro
objeto individual. Es así que podríamos tener una relación de uno a uno entre un objeto Ciudadano y
otro objeto de nombre Pasaporte: Un Ciudadano sólo puede tener un Pasaporte, y el Pasaporte sólo
puede corresponder a un Ciudadano. Las formas de representar, se observan en las siguientes figuras:

Ejemplo de relación uno a uno

 En la relación varios a varios (n → n), un lado del objeto se asocia con varios elementos del
otro objeto, y la misma situación se presenta de manera inversa.
Como ejemplo podríamos tener que un Artículo puede estar contenido en varias facturas
diferentes, y una Factura, puede contener a varios Artículos. Al tener una relación de varios a varios,
se crea una tabla intermedia o tabla transaccional (tabla detalles), producto de las dos relaciones.
Cuando se incorpora la tabla intermedia, surgen dos relaciones de uno a varios. Su
representación gráfica podría darse de la siguiente manera:

Ejemplo de relación varios a varios

La tabla intermedia podría ser llamada, concatenando los nombres de las dos tablas que lo
genera o dando un nombre significativo que describa a la relación.
Al conjunto de relaciones entre varias tablas, donde se podría aplicar uno, dos o los tres tipos
de relaciones, es lo que se conoce como Diagrama Entidad Relación, DER.
Diagrama de transición de Estados (DTE)

El diagrama de transición de estados enfatiza el comportamiento dependiente del tiempo del

sistema.
Hasta hace poco, los modelos del comportamiento dependiente del tiempo del sistema
importaban sólo para una categoría especial de sistemas, conocidos como sistemas de tiempo-real.
Como ejemplo de estos sistemas se tiene el control de procesos, sistemas de conmutación telefónica,
sistemas de captura de datos de alta velocidad y sistema de control y mando militares. Estos tipos de
sistemas manejan fuentes externas de datos de alta velocidad, y deben proporcionar alguna respuesta
y datos de salida de manera suficientemente rápida como para enviar al ambiente externo que lo
rodea.
Para los sistemas de gestión empresarial, ésta herramienta no ha sido lo suficientemente
importante, pues el sistema podría detenerse en un momento dado si el mismo se encuentra ocupado
respondiendo a las peticiones de otras transacciones.
Hoy en día, ya nos encontramos con grandes y complejos sistemas de negocio que tiene
incorporado funcionalidades de comportamiento dependiente del tiempo, tales como el intercambio
de información de un sistema dado a altas velocidades con otros sistemas vía redes de comunicación,
de los cuales pueden surgir temas de comportamiento dependiente del tiempo, en los aspectos de
sincronización de datos, autenticación y seguridad.

Se compone de estados. Cada rectángulo representa un estado en el que se puede encontrar el

sistema, y define un conjunto de circunstancias o atributos que caracterizan a una persona o cosa en
un tiempo determinado, como ejemplo de estados se podrían tener:

 Esperar a que el usuario ingrese su contraseña

 Mezclar sustancias químicas
 Arrancar el motor industrial
 Mezclar los ingredientes
 Aguardar en reposo

Luego los estados se unen con flechas, las cuales indican el orden en que se puede cambiar de
estado.

Estos ejemplos demuestran a que el sistema está esperando a que algo ocurra. Cada estado
representa la acción de una determinada tarea y es dependiente del tiempo, por el hecho de que
depende del estado anterior.
 La figura muestra que el sistema puede ir del estado 1 al estado 2, también estando en el estado
2, puede ir al estado 3 o regresar al 1, sin embargo de acuerdo con el DTE, el sistema no puede ir
directamente del estado 1 al 3.
El estado inicial por lo general es el que se dibuja en la parte superior del diagrama, aunque
esto no es obligatorio. Asimismo, el estado final suele ser el que se dibuja en la parte inferior, pero
tampoco es obligatorio.
Lo que identifica a un estado como estado final, es la ausencia de una determinada flecha que
salga de él (por lo tanto, la figura del ejemplo no nos muestra un estado final). En el DTE se puede
tener un solo estado inicial; sin embargo, puede tener múltiples estados finales. Los diversos estados
finales son excluyentes, lo cual significa que sólo uno de ellos puede ocurrir durante la ejecución del
sistema.
Los cambios de estados ocurren de manera instantánea, es decir, no se requiere un tiempo
considerable como para que el sistema cambie de un estado a otro, los cambios tardan microsegundos,
se debe asegurar que suceda lo suficientemente rápido como para que el sistema opere.

Condiciones y acciones

Las condiciones son las que causan el cambio de estado, y las acciones son las decisiones que
el sistema toma cuando cambia de estado.

Una condición es un acontecimiento en el ambiente externo, en el cual es el sistema tiene la

capacidad de detectarlo - podría será una señal, un interruptor o la llegada de un paquete de datos, eso
posibilita a que el sistema cambie de un estado X a un estado Y.
Como resultado del cambio del estado, el sistema hará una o más acciones, como ser: la de
producir una salida, desplegar una señal en el computador, llevar a cabo un cálculo, etc. En un
sistema complejo, puede haber docenas de estados distintos del sistema; ponerlos todos en un mismo
diagrama resultaría difícil, por tanto se podría realizar diagramas particionados de la misma forma de
que como se hace con el DFD.

Bibliografía

Yourdon, Edward: “Análisis Estructurado Moderno”. Prentice Hall. México, 1989.