UNIV-E RSIDAD .

DE BUENOS AIRES

·..¡

Secretaria de Publicaciones
E-mail: publk_cece@argcntina.com
 Autoridades del CECE
Presidente: Emiliano Yacobitti Agradecimientos ................................................................... :........................................ 9
Editorial ECONOMIZARTE Prólogo................................................................................ :........................................ 15
Director de administración y gestión: Leonardo Bugliani Capítulo 1: conceptos generales sobre el tema....................................................... 21'
Coordinadores editoriales: Hebe Mariel Dato - Matías Reck Introducción .................................................................................................... 2j
ÁLea imprenta: Fabián Zaldivar
La importancia de utilizar modelos.............................................................. 2&
Colaboradora: Mariana Paula Rodriguez Sebcdio El modelado estructurado y el orientado a objetos................................... 27
Diseño d·e tapa: Amalia Gonzalez La diferencia entre modelo y herramientas................................................. 28'
El ciclo de vida de los sistemas ..................................................................... 2~
© 2001, Ernesto Cbinkes Capítulo 2: el modelo de datos ................................................................................. 33
© 2001, Editorial Economizarte Los elementos del m odelo de datos ...................,......................................... 35
La gormalización.,. .................... ,...................................................................... 43
Córdoba 2122, PB (Sector rotonda) / . .•·"' · · Capítulo 3: el modelo funcional................................................................................ 55
(1120) Ciudad autónoma de Buenos Aires/ Argentina El diagrama de flujo de datos - DFD.......................................................... 5,
Tel.: (54 11) 4374-4448 (int. 6563) • . Características y aclaraciones sobre la utilización del diagrama ............... 60
E-mail: editoria@econ.uba.ar Metodología para la construcción del modelo ............................................ 6J
Capítulo 4: explicando los conceptos del modelado a través de un caso........... ~
1.S.B.N. Nº 987-9372-37•9
Características del caso................................................................................... 8
Queda hecho el depósito que marca la ley 11.723
Capítulo 5: aplicación práctica de casos................................................................ 103
1' edición, Marzo 2001 Caso 1: empresa productora (Picapiedras SA) .......................................... 105
Caso 2: gestión de expedientes .en una institución educativa
Impreso en Argentina - Printed in J\rgentine (Universidad de Aprendetodo) ..................................................................... 113
Caso 3: administración de organismo de investigación universitaria .... 125
Caso 4: empresa organizadora de eventos (Maja/da SA.) ...................... 137
Caso 5: distribuidora de libros (Simpson SA.) ...........................:.............. 148
Caso 6: service de equipos eléctricos (Máquinas Útiles)........................... 161
Ediciones del Centro de Estudiantes de la Facultad de Ciencias Económicas, Caso 7: Local bailable (Bolichito Bai/adQT) ................................................... 171
Universidad de Buenos Aires.
Capítulo 6: casos para resolver............................................................................... 183
Caso a: instituto de salud............................................................................. 185
Ninguna parte de esta publicación, incluido el diseño de cubierta puede ser reproducida, Caso b: taller mecánico ....................................................'............................ 186
almacenada o transmitida en manera alguna ni por ningún medio, ya sea electrónico, Caso c: venta y logística de distribución de helados........ :....................... 187
mecánico, óptico de grabación o de fotocopia sin permiso previo del Editor. Caso d: administración de proyectos de una consultora........................ 188
Caso e: ~~tració n de una biblio teca................................................. 189
Bibliografia.......... :..'..-..,............................................................................................... 193

Emt1to Chinkt1

j
l
CAPÍTULO 1: CONCEPTOS GENERALES SOBRE EL TEMA
Capít11/o 1: ronceptof Iobn el tema

CAPÍTULO 1: CONCEPTOS GENERALES SOBRE EL TEMA

Introducción
Un modelo es una representación simplificada de la realidad. Cuando se realiza
un modelo es por que se necesita contar co n una construcción formal de la
realidad que nos permita estudiar determinados aspectos de la misma.

Modelos de uso común en la vida cotidiana son, por ejemplo, los mapas que se
utilizan para representar la divisió n política o los accesos viales de distintas
regiones geográficas; o los planos de edificios para representar la distribución
de las áreas y sectores del mismo. De igual modo lós modelos que se estudiarán
en este texto tienen el objetivo de representar distintos puntos y caractccisticas
de los sistemas de información.

E m,s/o Chinh s

Mo{klado d, ,illema¡ d, información
En el párrafo anterior se mencionó que la realidad representada es simplificada,
e~to se debe por un lado, a la imposibilidad de formalizar los infinitos aspectos
que tiene la realidad, y en segundo lugar, debido a que es deseable que
solamente sean algunos aspectos los que se representen, ya que esto permite
resaltar determinadas caracteristicas, en pos de ocultar otras.
El objetivo par~ el que se utilizará el modelo es lo que determina el tipo de
modelo que se debe construir, ya que estos objetivos son los que rigen los
aspectos que el modelo debe considerar y resaltar.
En este texto se tratarán sólo algunos de los modelos que se utilizan para el
estudio de los sistemas de información. En particular se verán dos tipos de
[ modelos: el modelo de datos y el modelo funcional.
El modelo de dato permite representar los datos, y las relaciones entre éstos,
que un sistema de información necesita almacena.e; Un sistema de información
necesita guardar datos (y sus relaciones), debido a que debe satisfacer las
necesidades de información, construyendo la misma a partir de la recuperación
de los datos que se guardaron en distintos momentos del tiempo.
El modelo funcion~ permite representar cuáles son las funciones o procesoa
que el sistem de información necesita realizar para satisfacer las necesidades de
la organización, y cómo circulan los datos a través del sistema.
Este texto esta dirigido a estudiantes y profesionales de distintas disciplinas que
necesiten entender el modelado de los sistemas de información, o como
bibliografia introductoria para los estudiantes de carreras de sistemas. Se ha
pretendido ofrecer un respaldo bibliográfico que cubra las necesidades de estos
estudiantes y/ o profesionales, y por ello se han priorizado los siguientes
aspectos:
'✓ Dar los lineamientos básicos sobre el modelado de sistemas. Si bien se
1
tratan en forma pertinente y completa, no se profundizan aspectos
avanzados que podrían dificultar el conocimiento básico que se pretende, ya
que requerirían de más tiempo y dedicación para su asimilación.
Em,1/0 Chink,1
{;gpíiulo f: ,on,fj/01 ,obre el lema
✓ Explicar en un mismo texto los distintos aspectos del modelad~ de los
sistemas de información (modelado de datos y modelado funaonal) y
permitir de esta forma al lector, tener una visión integral y consistente de
estos modelos.
✓ Comprender los temas a través de su utilización en casos concretos,
logrando de esta forma reafirmar los conceptos a travé_s.de la resolución
integral de casos.
En capítulos posteriores se explicarán cada uno de estos modelos en particular.
Relacionado con el modelo de dato se describirán cada uno de los elemento
que es necesario definir cuando se lo construye, y como utilizar el Diagr~ de
Entidad Relación para formalizar distintos aspectos a través de una herrarruenta
gráfica. Con respecto al ~od~~ funcio~\ se explicará_cómo puede c_onstruirse
el mismo a parttr de la utilizaaon del DJJ1grama de FluJO de Dato , as1 como las
funciones que cumplen otras herramientas como son el diccionario de datos y
las herramientas de especificación de procesos.
Esta obra está pensada en dos partes, si bien no se han demarcado
explícitamente, una primera netamente conceptual donde se e~plican todos los
elementos que son necesarios conocer para entender y construu: los mod~~os, y
una segunda parte donde se aplicarán los conceptos a través de la resoluaon de
casos prácticos, como forma de asegurar la. asimilación de dichos conceptos.
Tratar el modelado a través de casos que se corresponden con representaciones
de distintas organizaciones tiene como intención permitir al lector
complementar la comprensión de los sistemas de informació~ en las
organizaciones, y aprender, cómo se utilizan y aplican las herrarruentas de
modelado.
Antes de comenzar a explicar los temas detallado"s precedentemente, se hará
mención de algunos cónq:ptos que merecen tenerse en cuenta.
Ern,1/0 Chinlw
----------------:G
 "M "'o"'de.,,laaed."'-o-"'dee...,µ..,·¡.,,te,,,m,.as!....!d.,,_
t ..,,
inll'fo11..,rme,,a""p"'·q!!...
n _ __ _ _ __ __
La importancia de utilizar modelos
La utilización de modelos para el estudio y la construcción de sistemas de
información tiene un papel crucial debido a que permite acentuar las
propiedades criticas del sistema y desacentuar las menos importantes. Es to es lo .
que lo hace una herramienta de comunicación muy importan te, que pemúte
una mejor comprensión de los sistemas que se encuentran bajo estudio.
El modelo, como herramienta de comunicación, permite a las persQnas que :
interactúan con los sistemas (analistas/diseñadores, programadores, ·usuarios ·
operativos, decisores, etc.) estudiarlos, analizando sus propiedades y pÍanteando
dudas, sugerencias y modificaciones. / . · ···'
En resumen, podemos destacar que los modelos sirven para:
✓ Concentrarse en las caracteristicas más relevantes del sistema.
✓ Verificar que aquéllos que deben desarrollar el sistema comprendan
correctamente cuáles son las necesidades que este debe satisfacer. Pero
también deben servir para que los usuarios o quienes sean los responsables,
acepten las definiciones y caracteristicas que propogan.
✓ Entender y consensuar cambios y correcciones en los requerimientos del
sistema.
El uso de modelos permite ahorrar tiempo y dinero, ya que trabajar con un
modelo, y rralizar modificaciones, o incluso deshacer y volver a hacer, es
menos costoso y riesgoso que realizarlo luego de construido todo el sistema.
Cuanto más complejo es un sistema más importante es trabajar con modelos. ·
Los analistas de sistemas, así como cualquier otra persona que deba analizar un
sistema, tienen dificultad para tratar complejidades. Todos los seres humanos
tenemos dificultades para tratar problemáticas complejas desde la abstracción,
es por ello que necesitamos formalizar los principales aspectos del problema a
estudiar, para poder dividirla en partes e ir analizando cada una de estas en
p~ticular. Pero a pesar de subdividirse en partes es importante no perder de
vista el problema a resolver en forma integral. Es por ello que un buen modelo
EJ
_ _ _ _ _ __ _ _ _ •
debe permitir analizar un problema desde lo general hacia lo particular, es decir
permitir analizar "las particularidades de los árboles sin perder de vista el
bosque".
2 f>~ hi~MAS
El modelado estructurado y el orientado a objetos
Los modelos que actualmente se estudian y utilizan en el modelado de sistemas
pueden clasificarse bajo -dos paradigmas distintos. Por un lado, los que se
circunscriben bajo la denominación del modelado estructurado, y por el otro,
los que obedecen al paradigma de la orientación a ·objetos.-
En este texto se utilizan herramientas y conceptos, que deben definirse dentro
del paradigma del modelado estructurado, por más que se han desarrollado
desde una visión más rica y evolucionada, si lo comparamos con respecto al
modelado estructurado "clásico". En algunos aspectos se han tomado
características de la orientación a objetos, que ya han incorporado distintos
autores, como es el caso de Eduard Yourdon, formando un paradigma de
; modelado estructurado "moderno"; y en otros simplemente se han realizando
i adaptaciones surgidas como fruto de la experiencia del autor de esta obra.
El análisis y diseño orientado a objetos (OOA&D), ha surgido como una forma
de dar continuidad a la programación orientada a objetos (OOP). Primero
surgieron los lenguajes de programación que trajeron importantes beneficios en
la construcción de los programas de software, que si bien surgieron en el
ámbito académico en la década del '70, tuvieron sus primeros usos en el mundo
real a fines de los '80 y principios de los '90. Luego de algunos años, y en la
medida que se comenzaba a popularizar su uso, surgieron distintos autores que
proponían la utilización de nuevas herramientas y procesos para la realizaciói,i
de modelos que fueran compatibles con dicha programación. D ichos lenguajes
y métodos fueron evolucionando hasta que aproximadamente en el ario 1997
los tres principales referentes de este paradigma (Booch, Jacobson, y
Rumbaugh) se pusieron de acuerdo en un lenguaje unificado de modelado
orientado a objetos conocido bajo la denominación UML.
En la actualidad; ·s.i bien el modelado orientado a objeto~ ha logrado cierta
madurez, y por ló tanto, creo que es una opción muy interesante para la
Ernt1/o Chinlw
Ernesto Chinkts
ca

Mndelado de IÍitema, de ,nf11T111atión
realización de modelos durante la construcción del software (sobre todo si se ,
realizará con un lenguaje de programación orientado a objetos), dichos modelos
no permiten captar tan fielmente la realidad que esta obra quiere resaltar: los
sistemas de información. En la diferencia que existe entre el software y el
sistema de información es donde reside la principal causa de porque en este
texto h emos usado el modelado estrucrurado de sistemas.
Los modelos del paradigma estructurado penniten formalizar, a través de los
mismos, los distintos componentes de un sistema de información (procesos,
datos que circulan, datos que deben guardarse, actores que interactuan con el ·
sistema proveyendo datos o requiriendo información) y como funcionan todos ·
ellos como integrantes de un todo: el sistema; permitiendo filtrar la esencia del -
sistema de información, respecto de la tecnología que se utilice para su
implantación.
Podría entrar en más detalles sobre las diferencias, semejanzas, beneficios y 1
desventajas que, según mi entender, existen entre ambos paradigmas de ·
modelado, pero creo que no es el ámbito, ya que lo único que haría es
confundir al lector que se inicia en el modelado de sistemas. Por lo tanto sólo
me resta agregar que para quien le interese explorar en el modelado orientado a
objetos le recomiendo comenzar por los libros referentes a UML que menciono
al final de esta obra en la sección de bibliografía.
Por último, más allá de estas aclaraciones, cabe comentar que no importa a este
autor dejar una clasificación estricta de a que paradigma pertenecen los
modelos, sino explicar como y por que son útiles los mismos.
La diferencia entre modelo y herramientas
En el desarrollo de este texto se utiliza en reiteradas oportunidades los términos ;
"modelo" y "diagrama" (Diagrama de En tidad Relación-DER y Diagrama de
Flujo de Datos- DFD). Es por ello que parece prudente explicar la diferencia
que existe entre los mismos, debido a que son muchas veces confundidos y
tratados com o sinónimos, inclusive en la bibliografía especializada.
Erne.slo Cbinh,
y,pí111/o 1: ronqploI sobrt ,l ltma
El modelo es una representación de la realidad. El diagrama es una herramienta
gráfica.
El modelo es una representación simplificada de la realidad, que debe cumplir
determinados requisitos y características en pos de lograr los objetivos buscados
con su manipulación. El diagrama, en cambio, es una herramienta gráfica que
podrá utilizarse para ia ·construcción del modelo. ·
Debido a la relación que existe por la utilización de dia¡i,unas para la
construcción de modelos, es donde surgen las confusionés entre los ténuinos.
Para terminar de ejemplificar, y relacionado con los temas que se verán, el
modelo de datos es la representación de la realidad que el sistema de
información necesita almacenar y el Diagrama de Entidad Relación (DER.) es
una herramienta gráfica que se utilizará para su construcción y que ;erminará
luego siendo parte integrante del modelo final.
El ciclo de vida de los sistemas
En los sistemas existe lo que se llama el ciclo de vida, que contempla las
distintas etapas por las que pasa un sistema de información desde su
concepción hasta que deja de usarse.
La clasificación de las etapas, si bien varían según los aspectos que distintos
autores prefieren priorizar, pueden nombrarse de la siguiente manera:
✓ Análisis
Es la etapa en la cual deben especificarse las distintas necesidades que el
sistema de información debe cubrir.
✓ QiJeii (Concwtual y: Fwco')I
En esta etapa debe uedu formalizada la o las alt~tivas de sohici6n 9't
permitan satisl'acu as oeces1 a planteadas en el análisis. Esta etapa
puede clasificarse entre diseño concegtu~ donde se definen los •:=,e-=-,=-
refett os. .a las necesidades de informaciát, y el &ico,fdoode se
foimalizan.Jos aspectos referidos a e o · plementarlo través de
. erram1entas; so are, hardware, r~cursosñumanos te.
Emulo Chin)w
 Modelado dt Tiiltmas tk información

1
También podrán usarse en otras etapas y para otros fines, pero los
✓ Codificación mencionados son los de mayor relevancia.
En la codificación deben transformarse b s especificaciones del diseño en
código que pueda ser interpretado, y por lo tanto ejecutado; por l<>f
recursos que se hayan definido en d diseño fisi o.
Etapas en las que ÚJs modeÚJs tienen mcryor importancia
✓ Implementación
En esta etapa che quedar operativo d sistema, es decir, realizar todas las · Permite
entcnclcr el
tareas que sean necesarias para que el sis tema quede en uso. Algunas de
Para represeota.r sistema que se
dichas tareas son la instalación, prueba, capacitación, conversión, te. como es y debe modificar
fu11cion2 el
✓ Evolución o mantenimiento sistema 2ctual.
Una vez que el sistema {e enc1;.~tra implantado se inicia una etapa donde
se deben incorporar cprreccioncs, mejoras y adaptaciones que permiten ,
que el sistema vaya evolucionado según las necesidades de la organización. · Implementación Evolución o
Mantenimiento
No se explicarán en extensión cada una de las etapas debido a que no es el
objetivo del presente texto. Pero sí parece importante su mención, debido a que
la utilización de los modelos se inserta :·n diversos momentos del ciclo de vida, .
y por lo tanto, es importante tener nooón del proceso global para entender su
uso en determinados momentos en particular.

Estos modelos se utilizan principalmente en las etapas de Análisis, Diseño y

Evolución o mantenimiento.

En el análisis, si es que se realizará en el mismo un relevamiento del sistema ·

actual ~o q~e en algunos casos puede denominarse diagnóstico), se utilizará
para representar como es y funciona el sistema existente.

En el ºseñ permitirá tq>!eleDtllr en aistintu fonnas y niveles de detalle__quf

caractcdsticas deberá cumplir el nuevo sistentfque se propone, y de esta forma ·
poder comunicul<i a distintas personas ue interactúan en el desarro rj del ·
nuevo sistema, como pueden se.r usuarios y progr~dore~

En la etapa de evolución o mantenimiento irve para entender las caracteósticas

dd sistema que es necesario adaptar.

Emulo Chinlw
Emulo Chinlw
 CAPÍTULO 3: EL MODELO FUNCIONAL

I .•-"
I

iif

1
i
1
y¡,1111JtJ .,. .., ...., - • .... ____ _

CAPÍTULO 3: EL MODELO FUNCIONAL

El modelo funcional es una representación que permite formalizar las funciones

que realiza un sistema y cómo transitan los datos por el mismo. Asimismo,
permite entender cómo se realizan dichas funciones.

Para la construcción del modelo funcional es necesario conocer algunas

. herramientas que se utilizan como son el DFD (Diagrama de Flujo de Datos),
el diccionario de datos y las herramientas de especificación de procesos como
las tablas de decisión, los árboles de decisión o el lenguaje estructurado.

E l diagrama de flujo d e datos - DFD

El Diagrama de: Flujo de Datos, conocido como DFD, es una herramienta
gráfica que sirve: para construir modelos de sistemas. Se utiliza principalmente:
para la representación de sistemas de información, pero es una herramienta que:
puede ser de mucha utilidad para representar cualquier sistema en general.

Para realizar los DFD se: cuenta con cuatro elementos. Los elementos son el
proceso, el almacén, el flujo de datos y el terminador.

ELEMENTOS DEL DFD

Procuo
Se grafica a través de un círculo, y permite representar cada una de las
funciones que realiza el sistema. El proceso representa la transformación de
datos que ingresan en datos que salen.

o
EmutoChin.éu
~
Modelado de 1i[1tma1 de útformación
[;gpítulo 3: d modelo funcional

Jiflmaceil
afclal, y permite representar los
ara su utilizadón os_tericl por
otro proceso. Ejemplifica ndo los elementos recién descriptos, y tomando nuevamente el caso
de modelar parcialmente un sistema que realiza la facturación de una em presa,
una parte de un DFD que conforme el modelo funcional de dicho sistema
podría verse como se muestra a continuación.

/
I Ejemplo de D FD
Flujo de datos
Se grafica a través de una linea con punta de flecha, y permite representar
CLIENTE
los datos que circulan entre los distintos componentes del sistema. La
punta e flecha permite indicar la dirección en que el flujo realiza la
circulación. E l flujo de datos, al igual que el almacén, es una estructura e
datos. Mien tras que en el primero de los casos es una estructura de datos
que representa su circulación desde un origen hacia un destino, en el
segundo representan una estructura que permanece guardada. 4-Factura

Deudas por
. . - - - +fíenle

Terminador
Se grafica a través de un cuadracjp y permit e representar a los proveedores
o requeridores de datos del sistema. Los terminadores son personas, áre
funcionales o entidades que se encuentran fuera del alcance del sistema
pero que interesa su representación debido a que interactúan con él.

Aquí se observa corno el D FD permite representar que el cliente es quien

provee los datos correspondientes al pedido y es por ello que ,e representa un
flujo llamado "1-Pedido" que con la punta de flecha indica la dirección del flujo
(del clieñte al proceso "1-Facturru:").
2El alcance de un sistema son sus linútes, es decir, que funciones abarca. Más adelantes
cuando se estudie el modelo ambiental se verá con mayor profundidad.

lill Emulo Chinku

Emulo Chinlw
- -- - -- -.. . .G

A partir de dichos datos, el sistema debe realizar una factura que se entregará al
cliente y guardar datos respecto a la venta y a la deuda que contrajo el cliente.
Todas estas acciones las deberá realizar el proceso "1-Facturar", que corno se
ve en el diagrama tiene corno en trada los datos recibidos por el flujo de datos
"!-Pedido" y generará los flujos de salida "2-Venta", "3-Cuenta corriente
factura", y "4-Factura" que se encargarán de actualizar almacenes en los dos
primeros casos, y de brindar información en el último.
Por otro lado existe otro terrninadorr el área de Cobranzas, que necesita un
informe de las deudas que tienen los distintos clientes, para lo cual existe un
proceso que torna datos del almacén "DEUDA" (a través def flujo "5_-Deudas
por cliente'') y obtiene como salida la información requerida ("6-Informe
deuda").
..,.
__
I ✓ El nombre de los procesos debe indicar una acción que realiza el sistema,
I Características y aclaraciones sobre la utilización del
diagram a
En este apartado se analizarán algunos aspectos que deben tenerse en cuenta
cuando se utilizan cada uno de los elementos que componen los diagramas de
fl-1jo de datos, advirtiendo los errores más comunes que pueden llegar a
cometerse.
FLUJOS DE DATOS
_ O~~
, Los flujos de datos que salen desde un almacén, con dirección_hacia el
- ➔ · , proceso, no m odifican el contenido del almacén. Cuan do se modifican los
;::. 9~ datos de un almacén (ingreso, modificación o eliminación de los datos del
~ almacén) debe representarse a través de un fl ujo cuya dirección es desde un
proceso hacia el almacén.
E n el ejemplo, el flujo "3-Cuenta cor.ciente factura" Actualiza el almacén
DEUDA, en tanto que el flujo "5-Deuda por cliente" NO actualiza el
almacén, sino que está consultando datos del mismo.
✓ El nombre que se use en los flujos de datos debe corresponderse con una
semántica que represente una estructura de datos. NO acciones.
Emulo Chinlw
[;gpítu/tJ J: el modekl fim&iona/
j
l· El flujo de datos " 1-Pedido" está indicando una estructura de datos que
representa los datos que deben ingresarse al sistema respecto de un pedido
¡ que realiza un ·cliente. Por el contrario estaría MAL si se le hubiese
llamado " 1-Realiza pedido", ya que estaría denotando una acción del
cliente y no un flujo de datos.
✓ Por otro lado puede ser recomendable incorporar en el nombre de los
flujos un número que permita identificar a los mismos más rápidamente. El
número NO indica una secuencia, sino que cumple el único objetivo de
ser un código de identificación del mismo.
PROCESOS
que por lo general es una transformación de los flujos de entrada en los de
salida. Se compone por lo general de un verbo en infinitivo y de un sujeto,
por ejemplo "Generar informe deuda", salvo algunos casos donde el verbo
de por sí es muy concreto y no hace falta el sujeto, como por ejemplo
"Facturar".
✓ Los procesos siempre se acompañan de un número, que al igual que en los
flujos, NO indican una secuencia dé los procesos. Pero en este caso
además de servir como código de identificación de procesos permite
identificar el nivel del proceso. El nivel está relaciónado con la explosión
de los procesos, que se verá más adelante.
Es interesante detenernos un instante en analizar por que no tiene
sentido indicar la secuencialidad de los procesos. El motivo es que en los
modelos que se realizan con los DFD, los procesos pueden ser
asincrónicos. Es decir, que los procesos se pueden ir ejecutando sin una
secuencia preestablecida entre ellos. El proceso 1 (Facturar) no tiene que
realizarse siempre antes que el proceso 2 (Generar informe deuda). Es
decir, la ejecución de los mismos no tiene ninguna dependencia
cronulógica. entre sí.
Ef1/lJto O,inlus

Modelado tk .risttmaJ dt in{gm,q,'ión
No tienen sentido procesos que sólo teng an flujos de entrada, 0
procesos que sólo tengan flujos de salida. Un proceso que sólo tiene
flujos de entrada sería un proceso que no da ningún resultado, po r lo cual
no tiene sentido que realic_e operaciones y transformaciones sobre los flujos
de entrada. Algo similar sucede con un proceso que no tiene flujos de
entrada, ya que la actividad que realiza un proceso es transformar los datos
que ingrc;.san en los datos que salen.
ALMACENES
✓ Los almacenes son pasivos, todo dato siempre es requerido o actualizado
por un proceso. Es decir, no tiene sentido alguno representar un almacén
que se conecta directamente con otro almacén o con un Terminador, ya
que toda acción que hace el sistema, como ser la consulta de daros o la
actualización de datos, debe rea lizarla un proceso.
✓ Los almacenes que se grafican en los DFD deben ser consistentes con las
entidades del modelo de datos del mismo sistema. Esto quiere decir que lo
que es un almacén en el DFD, debe ser una entidad en el modelo de datos.
H ay veces que puede no ser co nveniente representar almacenes hasta el
máximo de los detalles, donde cada entidad es un almacén, ya que el
aporte que hace al modelo funcional es menor que la complicación que
trae al diagrama el exceso de elemen tos. Es en estos casos en los que
pueden utilizarse las vistas. Una vista se gráfica igual que un almacén, pero
ésta incluyendo varios almacenes en un único elemento. Más adelante
volveremos sobre esto, ejemplificándolo.
✓ No tienen sentido los almacenes que sólo tienen flujos de entrada, o que
sólo tienen flujos de salida. Un almacén que sólo tiene entradas, es un
almacén que se actualiza pero que luego nunca se usa (por lo tanto pierde
su sentido); mientras que un almacén q ue sólo tiene salidas tampoco tiene
sentido, ya que no es posible que se consulte información que nunca puede
ser ingresada y actualizada.
Erntr/o Chinhs
y;p_ítulo J: el modelo limáonal
Cabe hacer una aclaración respecto de la aseveración an terior, y es que
puede tener sentido que un almacén tenga solo ingresos o solo egresos
cuando el DFD que se está analizando es una pacte de un DFD que
representa un sistema mayo r, y en este caso es la_otra parte del sistema la
que puede encargarse de actualizar o de consultar dicho almacén.
TERMINADORES
✓ Los renninadores NO se comunican entre sí, por lo tanto no tiene
sentido que exista un flujo de datos entre ellos, ya que dicha interacción
[J-{J6,
estaría fuera del alcance del sistema bajo estudio.
Es decir que no tendría sentido, en el eji:;mplo que presen tarnos
anteriormente, un flujo de datos entre el terminador CLIENTE y
CO BRANZAS. Esto no quiere decir que en la realidad de la organización
no exista comunicación entre ellos, sino lo que quiere decir es que no es
1. responsabilidad del sistem a dicha interacción, por que si lo fuese debiera
existir por lo menos algún proceso que realizara funciones al respecto.
✓ Los terminadores deben estar relacionados con quienes proveen o
l
.
requieren los datos en la realidad de la organización, y NO quien será e l
responsable de ing resar o recibir la información en el sistema.
En el ejemplo, quien da los datos referentes al pedido es el cliente, sin
importar si él los ingresará al sistema o si será un operador que este frente a
una computadora.
✓ NO deben usarse nombres de personas. Si el proveedor o el requeridor de
los datos es una persona, deben nombrarse los mismos con el cargo o
función que cumple la misma.
DFD POR NIVELES: EXPLOSIÓN DE PROCESOS
1
Se deben evitar los D iagrama de Flujo de Datos complejos y que por lo tanto
sean difíciles de analizar y entender. Es por ello que los mismos no deben
contener muchos-elt;mentos. P ara ésto se utiliza la nivelación.
Emtslo Chinhs
 ~□
DFD de nivel O
........l)Oft

Se llama nivelación a subdividir los DFD en distintos niveles que permitan ' •
estudiar los procesos desde lo general hacia lo particular. Esto se realiza a través
de la rúvelación descendente, también denominada explosión de procesos. Es
decir, a partir de un diagrama de flujo de datos de nivel superior (nivel O) que
contiene una cantidad n de procesos, se realizan otros DFD de nivel inferior a
este (nivel 1) que permiten explicar los subprocesos que se realizan en los
distintos procesos del DFD superior a éste. Luego, en la medida en que sea
necesario, se podrán explotar los distintos procesos de los DFD de rúvel 1, en
los DFD de nivel 2 que expliquen los subprocesos que los conforman. De igual
manera, se podrán seguir explotando procesos hasta el nivel que sea necesario
DFDde nivel 1 del1)!0CeS0 2
para explicar su funcionamiento.
. 1 ÓJ
~~~
~~
➔~
\'~
I
I

Flujo d
ALMACEN
X

o
ALMACEN
y

n 1 DFD de nivel 2 del Proceso 2.3

Flujo!

lujod

ALMACEN
y

Ernt1/o Chink,1

.
 o
1
2..
Morklado dt ¡iJtemM deinformación
Como puede observarse en el ejemplo, se utiliza la numeración de los procesos
para marcar la jerarquía de los mismos según el nivel en el que se encuentran.
Por ejemplo, el proceso 2.3.1 es un proceso de un DFD de nivel 2 que es un
subproceso del proceso 2.3- del DFD de nivel 1que a su vez es un subproceso
del proceso 2 del DFD de nivel O.
Ahora sí, es posible explicar las dos funciones que cumple la numeración de los
procesos en los DFD:
✓
t
Identificar unívocamente a cada uno de los procesos.
✓ Indícar la jerarquía del proceso dentro del modelo que se está graficando
con los DFD.
Como se aclaró anteriormente, la numeración NO indíca secuencia entre los
procesos.
Esca caracteóstica del Diagrama de A ujo de Datos es muy importante para el
modelo fu ncional que se obtiene como resultado, ya que se obtiene un modelo
que permite distintas visiones del sistema, y de esta forma poder analízarlo
de lo general a lo particular. Esto permite tener una primera visión de nivel
general, donde se pueden observar las principales fu nciones del sistema, y luego
profundizar en aquellos procesos que son de interés, y así seguir profundizando
hasta el nivel que se quiera llegar.
Es importante realízar algunas aclaraciones respecto a la nivelación de los DFD:
✓ No todos los procesos tienen igual can tidad de niveles. La cantidad de
niveles NO debe ser balanceada, es decir que un proceso podrá quedar
expresado sólo en el DFD de nivel O, y otro proceso puede ser necesario
explotarlo en un DFD de nivel 1, y a algunos de los procesos de este en
D FD de nivel 2, 3, etc.
✓ La cantidad de niveles están relaciónados con la complejidad del sistema.
El criterio que define la necesidad de explotar un proceso es la complejidad ,
de mismo. Es decir, si es posible y necesario subdividir el mismo en
Ernnto Chinlw
-
Caoít~lo J: ti modelo limcional
subprocesos para entenderlo mejor, o por el contrario ya es clara la función
que realiza el mismo.
✓ La cantidad de procesos por DFD se recomienda que no sea mayor a seis.
Este número por supuesto que es arbitrario, es simplemente para tener un
parámeqo a partir de cuando un D FD puede verse_como muy complejo e
inentendible: Por lo cual convendría subdividirlo en distintos niveles para
poder analizarlo con mayor claridad.
I
I
✓ Debe haber consistencia entre los niveles, y Jo·s flujos de un nivel deben
coincidir con los del nivel anterior. C(?mO se puede observar en el ejemplo
los flujos de entrada y salida _de un proceso que .es explotado deben existir
en el D FD de nivel inferior (Flujos c, h y d del proceso 2 están
representados en el DFD de nivel 1 del mismo).
✓ Los almacenes sólo deben graficarse en un DFD aiand.:> más de un
proceso hace uso del mismo, de lo contrario deberá mostrarse recién
cuando se explote el proceso que hace uso de éste.
La nivelación podrá entenderse mejor cuando incorporemos dicho concepto
dentro de la construcción de modelos. P or lo tanto, volveremos sobre dicho
concepto en la siguiente sección.
Metodología para la construcción del modelo
ALGUNAS CONSIDERACIONES PREVIAS
Antes de plantear la metodología para la construcción del modelo, es
importante realizar algunas aclaraciones sobre los distintos sistemas que es
posible modelar en el desarrollo. Como se planteó desde un principio, la
construcción de un modelo implica la representación de una realidad, es por
ello que primero de todo es importante tener claro qué realidad es la que
querernos representar.
Por lo tanto, h~emos mención aquí de dos posturas encontradas para el
desarrollo de sistemas. Una plantea realizar en primera instancia un modelo del
Ernulo Chinl:.,s
 [¿p_ífll/b ;: ti moaeio 111nao11a1
Modelado de 1iitemaJ de información

z._~ sistema actual (que es el sistema que se encuentra operativo), y luego realizar el
modelo del nuevo sistema que se va a desarrollar. La otra postura modela
~ O Q ~ directamente el nuevo sistema, sin realizar previamente el modelo del sistema
existente, ya que considera que no tiene sen tido perder tiempo realizando un
modelo para un sistema que se va a dejar de usar. Los lle9 torque lo componen son:
~ IB
dW,(
Al modelo resultante cuando se representa el sistema actual es conocido como .......,.......___,,_____ ___ del sistema1Debe ser un
el alance
C.:00 Modelo de Diagnóstico, al modelo que representa el nuevo sistema se lo párrafo o a lo sumo dos. Si bien por ser tan breve será una descripción
/wf!..\JO denomina Modelo Esencial. incompleta y en muchos aspectos ambigua, servirá como una primera
•~aón il ilcancc del sistemf
Los to¡; ~ tel lleo
Si bien en esta obra se tomará para resolver los casos prácticos la segunda de las ~ bjetivo_c_Qt!WÍCtarlo y reducir.las ambigüc
posturas (realizar directamente el modelo esen cial), es importante destacar que
todo lo aquí expresado paí:a la construcción del modelo funcional sirve para
modelar cualquier sistema/ Es por'ello que la consideración de si el sistema es el
actual o es el nuevo, sólo modificará cuál es la realidad que se va a representar.

Modelo de Modelo ilmiceiiei ya que sólo se graficarán si existen almacenes

Diaanóstico externos. íliilacenes externo son tlmacerrcs qire utilizan o tr<:i
Esencial
téiñf. En este texto no usaremos almacenes externos, por lo tanto los
Diagramas de contexto no tendrán almacenes.

CONSIH11CClóN l)Jij[,.MOOHW ,AMfilENYAj,

El Modelo Funcional de un sistema puede dividirse en dos submodelos: El
Modelo Ambiental y el Modelo de Comportamiento. El primero permite una·
visión general del sistema, mientras que el segundo especifica en detalle las
distintas funciones que debe cumplir. i\mbos submodelos están íntimamente
relacionados y deben ser consistentes entre sí.

É ntnlo Chinke1

EJ Entnfo Cbinh1
 (,g;ít11/o ): el modelo {¡mcional
.Modelado de tistemas de información

Ejemplo: diag rama de contexto experiencia que es más productivo realizarla con el formato que se presenta a
continuación:
TERMINADOR TERMINADOR
A e T ERMINADO"R ESCRl PCIÓN DEL LUJO
1-Flujo a 2-Fluo e
ACONTEGIMIENTO ENTRADA

; .~'
En esta tabla'.se d_eberán escribir todos los eventos que puedan ocurrir y ante
los cuales el sistema que está bajo estudio deberá dar respuesta.
Sistema ·1:. :.
3-Flujo d El nuaner, es un lclen!ificador uruvoco1fe cada acontecimiento.
' .
o es sólo en los
TERMINADOR 1 El
;.:¿.;;:;;;;;,;;~= :=..-;-:'1
B
4-Flujo b i
·f§i el event . ( ~ ~ _ )
~:,ilt .
~ i
LISTA. DIUCO ENTOS ;1 fflu~ e w es donde se referencia 8. o os flujos de. entrada que s
re @ nan e@ cliClio aconteC11DJefitl>, aquí se podrán los números de los flujos
que se utilizan en el diagrama de contexto.

os en los que el
1
.

"J
,,.,,,
'Fli
que
· · · a lo dicho en el flu·o de entrada, pero con los flujos
el ststml.a hacia los terminadores.

Más adelante se ejemplificarán a través de un caso cada uno de los elementos

recién enunciados.
Temporales (Intcmos Son aquellos en los ue el
CONSTRUCGÓN DEL MODELO DE COMPORTAMIENTO
su ocüfrcnc:ii ikoid es un determina
OlOIDffltO C I L ~ O. Una vez realizado el mo delo ambien tal, para construir el modelo de
comportamiento es recomendable la realización de un modelo intermedio,
llamado Modelo Preliminar . Luego a partir de dicho modelo preliminar se
construy!! el modelo de comportamiento final.

La lista de acontecimientos la expresaremos el}I =.,,_,.=-c= r · Si bien otros

~~
autores lo realizan con formatos distintos, hemos visto como fruto de la
. ~
~
EJ Emu lo Chinkt1
Emulo Chinlm

-

Modelado tú súlema.r tú in{ormatió11
Etapa 1: COflSIT11cción del modelo preliminar
Se grafican tantos procesos como acontecimientos existan en la lista de
acontecimientos. Cada proceso es la respuesta que debe dar el sistema ante la
ocurrencia de un acontecimiento. P'or lo tanto, quedará como resultado de esta
etapa un DFD que constará de un número de procesos igual al número de
acontecimientos que tenía la lista de acontec.im.iento ..
Se deben respetar los flujos y t~adores dd diaguma de contexto, y se
deben agregar los almacenes que utilicen los procesos, y los .flujos que conectC11
los procesos con los almacenes.
En este diagrama de flujo de datos, que grafica el modelo preliminar, los
I procesos no pueden comunicarse entre sí en forma directa, si lo hacen es a
I través de almacenes'.
G 8
roceso
--..~ 2
ALMACÉN
Es interesante anal.izar el porqué de esta regla: como ya se dijo anteriormente,
los acontec.im.ientos son asincrón.icos, es decir, que no existe una secuencia
cronológica en la ocurrencia de los mismos. Por otro lado, cada proceso que se '
representa en este DFD está dando respuesta a uno de dichos acontecimientos.
Entonces, el flujo de sal.ida de un proceso nunca podrá ser la entrada de otro
proceso, ya que el proceso al que estaóa ingresando comenzará a ejecutarse en
un momento del tiempo que seguramente diferirá con respecto al otro. Es por
ello que estos datos deberán guardarse en un almacé , para que puedan ser
usados por el otro proceso en el fi10mento que éste sea activado.
G---- - -- -- Emuto Chinlus
[;,g;_í/JI/Q J: et 111oiu111 1I1nao11aI
Cabe aclarar que en sistemas complejo el realizar un único DFD para
representar el modelo preliminar puede ser muy engorroso."En dichos casos se
puede parcializar el diagrama subdividiéndolo en par_tes. En los casos que se
tratarán en este libro, por tratarse de sistemas no complej~ , será posible
representar todo el modelo preliminar a través de un único diagrama.
Etapa 2: ronslr11cció11 del modelo ltrrninaáo
El modelo de comportamiento final, llamado también modelo terminado, estará
conformado por distintos · DFD qué se encontrarán organizados
¡etirquicamente a través de la explosión de procesos. Por lo tanto, existirá un
DFD de nivel <J que mostrará una visión general del comportamiento del
sisterni , que podría explicarse coino el resultado de 'haber explotado el único
proceso que contiene el diagrama de contexto.
Existirán también una cantidad de DFD de nivel , que mostrarán en forma
particular el comportamiento de distintos procesos 't¡ue se representaron en el
DFD de nivel O. Como máximo existirá un DFD por cada uno de los procesos
del DFD de nivel O. De igual manera podrá contener el modelo otros DFD de
nivel 2, 3, etc. de acuerdo a la necesidad que exista de explicar en detalle el
comportamiento de los procesos que aparezcan en los DFD de nivel superior.
Para construir el modelo de comportamiento final, partiendo del modelo
preliminar, es necesario realizar dos tareas:
a) Nivelación ascendente.
b) Nivelación descendente.
a) N ivelación ascendente:
Permite obtener el DFD de "nivel O por medio de agrupar los procesos del DVI)
del modelo preliminar. Esta nivelación se realiza seleccionado procesos que
sean homogéneos funcionalmenti: para que conformen un único proceso l!e
índole mas general. Es por ello que se llama nivelación ascendente, debido a
Emulo Chink,s

Modelado tk µIlemaJ ik ieformaCÍIÍn
que es el proceso mvcrso a la explosión de procesos llamada nivdación
descendente.
De esta forma se obtiene uo DFD con menor cantidad de procesos, y que
describe las funciones del ~stema de manera más general que el DFD d
modelo p r e ~ . 11lte scní el DFD de nivel O del modelo terminado.
Para decidir cuáles son los procesos que se d eben seleccionar y agrupar, es
necesario analizar entre los distintos procesos cuales de ellos realizan funcione
que se encuentran relacionadas (a esto se denomina homogeneidad funciona~ .
Una forma que muchas veces se utiliza para detectarlo es analizar la utilizacién
que los procesos hacen de los almacenes y utilizar la técnica de ocultarlo . Se
dice que se ocultan los almacenes, a que si se agrupan todos los procesos que
hacen uso de un almacén, este no tendrá que mos trarse en dicho DFD debido a
la ca.racteóstica vista coo anterioridad, donde sólo debe graftcarse un almacén
en el diagrama cuando hacen uso de él más de un proceso del DFD. Por lo
tanto, recién deberá mostrarse cuando se explote ese proceso.
b) Nivelación descendente:
Una vez qu se obtuvo el DFD de nivel O, comienza la nivelación descendente,
representando el comportamiento de los procesos en DFD particulare que
permiten estudiar las sub funciones que realizan. ! sta nivdación se realiza a
través de la explosión de proceso Como ya _se mencionó anteriormente, la
jerarquía de niveles no debe ser balanceada, es decir no todos los procesos del
nivel O scnín explotados hasta los mismos niveles de DFIJ!I
Una pregunta común, que hacen muchas personas cuando se les explica esta
metodología de nivdación (ascendente y descendente), es para qué tomarse el
trabajo de agrupar procesos (nivelación ascendente), si en el paso siguiente se
vuelven a subdividir (nivelación descendente). La respuesta es, que si bien se
vuelven a subdividir, ésta vez &e tcaliza de manen estructurad , de forma tal
que permitirá atí~er el comportamiento desde una visión general pudiendo
individualizar las distintas visiones particulares que se requieran
Emnl• Chinhs
~;---------
~-------,,,,__-
9fj2!JJ!lo J: el motklo funcional
p a terminar de entenderlo, es posible realizar una analogía coo los map!ts, o
c;~ planos de edificios, o cualquier otra representación de la realidad que se
tilicen en nuestras vidas en forma cotidiana. Tomemos por eiemplo un mapa:
u_ ueremos encontrar una calle que se encuentra en la ciudad de Merlo, en la
S1 q . . , .
. vincia de San Luis de la República Argenana, pomero sera converuente
protud.iar un mapa de toda la República que permita encontrar la u bº1caaon
. ' de 1a
es . ., al L ,
provincia de San Luis con respecto a .nu_estra ub1c~~on acru . ue~o sera
ven.iente tomar un mapa de la provmaa de San Luis para saber como se
con · di " dd
llega a la Ciudad de Merlo, y finalmente deberemos us~ un mapa e a c1u a I .....
de Merlo, que nos permita analizar las calles de la nusma para encontrar la 1
dirección buscada. Imaginemos ahora otra opción, donde se in ten tara ~ar-con
la calle buscándola eo un único mapa que ruviese todas las calles de las d.isnntas
ciudades de la República Argentina; seguramente sería imposible encontrarla.
· A.Jgo similar sucede si intentamos ana!izar el co~portamiento de un_~stema n
forma detallada, sin estructurarlo en d.ife.rentes ruveles de gene.ralizaaOA.
E) modelo de comportamiento se completa a través de o tras he~~ntas
descriptiva, adicionales a los DFD como son el diccionario de datos ! d.istmtas
herramientas de especificación de proceso (Leguaje estrucrurado, ,fablas_ de
decisión Árboles de decisión, etc.) No es objeto de este texto el profundizar
sobre es~s herramientas, y es por ello que en los casos que se resuelven aquí no
se utilizarán las mismas. Pe.ro igualmente creemos importante dar un:i
explicación general sobre las mismas, y sobre todo cómo se relacionan con los
DFD para completar el modelo.
EL DICCIONARIO DE DATOS
El diccionario de datos permite definir en detalle algunos aspectos que en los
diagramas se deben definir de manera general Por ejemplo se define~ cuáles
son los distintos datos que componen las estructuras de datos de los flu1os Y d e
los almacenes que se nombran en los DFD. Para explicarlo a través de un c~s?
concreto, tomaremos un flujo del ejempló de DFD que se utilizo
anteriormente: eo éste se nombraba un Flujo de datos "Pedido", es aquí en el
diccionario de datos donde se especificará cuál es la estructura que compone
dicho flujo de datos. E sto podría quedar expresado como sigue:
Ernu lo Chinhs G
~
 El árbol de decisión describe los distintos caminos por los que puede transitar
Pedido = NÑmero pedido + Código cliente + Nombre cliente + [Código producto el proceso y las distintas acciones a las que conducen cada uno de los mismos.
Dmripción prodNclo + Cantidad pedida + Precio unitario) Se muestra a continuación un ejemplo de su utilización.

Como puede verse, existe determinada simbología: el "=" y el "+" sirven para Importe Factura * 20 %
indicar los distintos elementos que componen u.na estructura. Los " (" '1' sirven
para indicar aquellos datos que son repetitivos. De igual forma se podrán
Mayorista \
Más de 1.000 < Contado--1-- - -- - - - - - - 1
Financiado - Importe Factura* 10 %
utilizar otros símbolos para indicar otras características de los elementos que ' unidades
componen el diccionario de datos.

Por lo tanto, el diccionario de datos es el lugar donde se debe definir aquellas Entre 100 y 999< Centado-- Importe Factura * 10 %
unidades
ambigüedades que dejan los diagramas. Es por ello que el diccionario de datos
Financiado - Importe Factura * 5 %
es el lugar donde también -se definen las estructuras de datos dd modelo de
datos Cuando el modelado se realiza a través de software, muchas veces este
0%

1
diccionario toma el nombre de 'ttpositorio de da tos, ; . .•·' .. ·
1
HERRAMIENTAS DE ESPECIFICACIÓN DE PROCESOS
L,s herramientas de especificación de procesos son aquéllas que sirven para La tabla de decisión especifica en una tabla concliciones y acciones; y
definir y registrar la lógica in terna de un proceso e indican cómo debe realizarse . combinando ambas se establecen reglas de decisión. Se mues tra a continuación
el mismo. Herramientas de este tipo son, entre otras, el árbol de decisión, la como quedaría esta especificación con el mismo ejemplo que se uso en el caso
tabla de decisión, y el lenguaje estructurado. · anterior pero para simplificarlo no hemos tomando en cuenta la cantidad de
' unidades vendidas.
J
••••
Estas herramientas también ayudan en la construcción del modelo funciona~ ,, · Reglas de decisión
integrándose en ést~ al especificar la lógica de los procesos que se definieron en 1
1

el últin10 nivel de los DFD.

Es un cliente mayorista s s N N
Para ejemplificarlo tomaremos uno de los procesos del ejemplo de DFD que Condiciones ---+ Es una venta contado s N s N
representa el proceso "!.Facturar", que utilizamos al comienzo de este capítulo. No realizar descuento. X
E se proceso seguramente podría ser explotado a través de un DFD de nivel Acciones _..,
Realizar descuento del 5% X
inferior donde contendría distintos subprocesos como "1.1.Identificar datos del
Realizar descuento del 10 % X
cliente", "1.2.rcgistrar productos", "1.3.calcular descuentos", etc. Para estos
Realizar descuento del 15 % X
procesos ya no tiene sentido dividirlos en subprocesos, sino que es necesario '
especificar cuál es la lógica que deben seguir los mismos. Mostramos a
continuación cómo quedaría la especificación del proceso "1 .3.calcular
El lenguaje estructurado, y en nuestro caso el castellano estructurado, es la
descuentos" si se usara un árbol de decisión, luego con una tabla de decisión y
herramienta de esp_ecjficación de procesos que se usa en la mayoría de los casos.
por último con el castellano estructurado.
Se usa una combioªción de las estructuras propias de la programación

Ernulo Chin/e,s

EJ Ernesto Chinhs
Moddadt, de JÍJtema¡ de información

estructurnda con el lenguaje natural (en nuestro caso el castellano). Veamos

cómo se expresaría el proceso calcular descuento.

Descuento= 0%
SI cliente = mayorista
SI forma de pago = contado
Descuento= 15%
SINO I
[ Descuento = 5% 1
FIN SI
SINO
SI forma de pago= contado
Descuento= 10%
[
FIN SI
FIN SI

No hemos explorado cada una de estas herramientas en profundidad, ya que no

es alcance de esta obra explicar las caracteóscicas ni la forma en que se usan,
simplemente quisimos ejemplificar que como parte del modelo funcional, para
los procesos que se crea conveniente, y cuando ya no tiene sentido explotar a
través de un DFD de nivel inferior, debe quedar formalizada la lógica interna
del mismo. Para ello debe seleccionarse cuál es la herramienta de especificación
de procesos más adecuada y con ella dejar registrada la misma. En la mayoría de
los casos es conveniente usar el castellano estructurado, pero pueden existir
ocasiones en donde sea más frucófero utilizar los árboles, las tablas de decisión,
o inclusive otras herramientas.

~ E mu lo Chinku ,,

m
 Q¡pí/11/o 4: explicando /u¡ concep/QI del modelado a lraviI de 11n caio

CAPÍTULO 4: EXPLICANDO LOS CONCEPTOS DEL

MODELADO A TRAVÉ_S DE UN CASO

Para complementar lo explicado hasta aquí, se enunciará un caso que permitirá

ir aplicando los distintos concep tos vistos. Así también permitirá complementar
]os mismos pro fundizando y ampliando algunos de ellos.

El caso trata sobce'un sistema para manejar la G estión operativa de una

empresa de~cada a la prestación de servicios en la industria de la recreación.
;:;,
1. ~

1
~ . } Características del caso
~

,' :.,.
.•·..
.·,
··.-
.·,
':,;~,1.
,.
La empresa Jurasiic Park:SA es la propietaria de un parque de recreación donde
el público visita animal,:s prehistóricos. Dicha empresa tiene un área (VISITAS
PREHISTÓRICAS) qu: se encarga de ofrecer visitas guiadas para escuelas.

1-
-~

,..-
:~
.}:
El área Visitas Prehistóricas vende a escuelas visitas guiadas al parque para sus
alumnos. Las escuelas deben realizar reservas telefónicas de las visitas que van a
realizar. Las mismas deben informar, en el momento de realizar la reserva, día,
hora, tipo de visita que realizarán y, la cantidad de alumnos que van a concurrir.
En caso que la escuela sea la primera vez que realiza una reserva se le piden su
domicilio y teléfono(s).

]11wiic Park SA. desea desarrollar un sistema informático que le ayude en un

eficiente desempeño y control del área mencionada.

Cuando las escuelas se presentan para realizar la visita, según la reserva realizada,
· la boletecia del parque se encarga de verificar que exista la reserva. y cobrarles el
importe correspondiente. El importe a cobrar a la E scuela por la Boletería es en
funció n de la cantidad real de alumnos que hayan concurpdo a la visita y del
arancel por alumno correspondiente al tipo de visita a realiz'ar.
1

Los guías,. para la~ distintas reservas que han realizado las escuelas, son asignados
por el supervisor de guías.

Ernuto Chi11/w
 ~ J #U. .V • • "'""t" ....... ,. ...v """ 1,v1u.cµw .J ue, ,nuuelQl.l.U Q ,ravts Ql un (OJO

Modelado dt 1Últ11111I tk infomzación

Por ejemplo, a partir del terminador Escuela se podría definir el acontecimiento

.Además, el supervisor de guías es el encargado de contratar nuevos guías cuando "Escuela realiza_una reserva". A partir de éste graficar en el Diagrama de
lo considere conveniente. Contexto un flu¡o llamado " Reserva" que son los datos que provee la escuela
cuando realiza una reserva.
El sistema debe permitir, además, que el R~sponsable de Recepción de Reservas,
consulte datos sobre reservas · especificas, ·ya que pueden existir reclamos, De esta manera se podrán ir definiendo los distintos aco ntecimientos ante los
felicitaciones o sugerencias, etc., sobre las mismas. Debe poder obtener quién fue cuales el sistema deberá dar respuesta, y se irán graficando los distintos flujos a
el guía (Código de guía, y Nombre de guía), el código y el nombre de la escuela, el través de los cuales los terminadores proveen datos o reciben información.
tipo de visita, el día y hora de la reserva, la cantidad de alumnos que concurrieron Cabe aclarar que luego habrá que agregar aquellos acontecimientos que sean
y cuál fue el arancel que se le cobró por alumno. temporarios y, que por lo tanto, no son consecuencia de ningún terminador en
particular.
El Responsable de Recepción de Reservas se encarga de decidir si, por ejemplo,
se crean nuevos tipos de visitas o se cambia el arancel de las mismas. En la tabla que utilizamos para definir los aconteCl!nJentos, se usan dos
columnas para referenciar los flujos del diagrama de contexto que se
I
I Ob1tT11acionu: encuentran relacionados con cada uno de los acontecimientos, por lo tanto en
✓ La empresa oferta a las escuelas distiu tos tipos de visitas. La escuela puede ellas habrá que ir referenciando los flujos que se grafican en el Diagrama de
elegir un solo tipo de visita por reserva. contexto. Esto nos permitirá asegurada consistencia entre ambos.
✓ El arancel por alumno depende del tipo de visita,,elegido.
A continuación vemos cómo quedaóa la lista de acontecimientos y el diagrama
✓ A cada reserva se le asigna solamente un guía. de contexto terminados.
✓ No se guardan escuelas que no hayan realizado reservas.
Lista de acontecimientos
RESOLUCIÓN
N° TERMINADOR DESCRIPCIÓN DEL FLUJO DE FLUJO DE
ACONTECIMIENTO ENTRADA
Modelo ambiental SALIDA
1 Escuela Realiza una reserva. 1
En primera instancia realizaremos el modelo ambiental. Para ello se definirán la
Lista de Acontecimientos y el Diagrama de Contexto. Una buena opción es ir 2 Escuela Se presenta para realizar la 2, 4 3
realizándolo de manera conjunta, asegurand0 la consistencia entre ambos. visita.
Luego redactaremos la declaración de propósito.
3 Supervisor de Asigna guía a reserva. 5
guías
Es consecuente definir, en primera instancia, los terminadores del Diagrama de ..·
Co ntexto (en este caso E scuela, Boleteáa, Supervisor de Guías, y Responsable 4 Responsable Consulta datos sobre una 6 6
de Recepción de Reservas) y a partir de allí comenzar a describir los distintos Recepción de reserva especifica.
acontecimientos que pueden realizar cada uno de éstos. Por cada Reservas
acontecimiento iremos graficando los correspondientes flujos que se
encuentran asociados.

Emulo Ch;nk11

EJ Emulo Ch;nle,1 ,

---------
 ,1 (;gJ!Jllh 4: explicando lo, co11cebto1 del modelado a /ravi1 de un ,a.ro
f;
Modelado de ril{emaJ de j,r{om,ación

Diagrama de contexto
5 Supervisor de Contrata nuevo guía. 7
guías
1-Reserva
6 Responsable Crea un nuevo tipo de visita. 8 4-Canl. alumnos
reales e BOLETERIA
Recepción de ESCUELA
- 2-Datos Reserva importe
Reservas escuela
..
7 Responsable Modifica el arancel de un 9
J :l.
R"ecepción de tipo de visita.
Reservas 7 ~ 7
,,. '
1'7
, ....
3-Reserva a cob<aI

Acontecimientos colaterales 6-Datos Reserva "'

Sistema
de
\ .
Escuela Cancela reserva.
seleccionada . manejo l<J 7Nuevo gula
... de
visitas
contratado
Supervisor de Da de b:ija a guía. 9-Arancel ~

por alumno 5-Guia asignado

guías
modificado ~

Escuela Informa cambios en sus ':l.

datos personales.
"
RESPONSABLE SUPERVISOR
RECEPCIÓN GUIAS
RESERVAS 8-Nuevo tipo
de visita

Al aplicar los conceptos a través de este caso incorporarnos una clasificación de

acontecimientos que no mencionamos anteriormente cuando se explicó el
tema. Son los ACONTECIMIENTOS COLATERALES. Éstos son
acontecimientos que si bien son necesarios para que el sistema esté completo,
no son relevantes en lo que es el entendimiento del sistema, y es por ello que si
bien los mencionamos en la: lista de acontecimientos, luego no se grafican en el
diagrama de contexto.

Emulo Chinkes
ca
EJ Emu lo Chi11/w ,
 ~u..-- .. ..~-r--.... ,•..., ,VJ wm.cµ1uJ Ut:I rnuueJtJao o lfOlltl ae 11n caJO

Modelado de siitemos rú información

reserva" que torna datos del terminador Escuela, a través del flujo "reserva" y

Declaración de propósito

Ahora sí redactaremos la declaración de propósito. Si bien por lo general se

presenta corno el primer elemento del Modelo ambiental, es conveniente que
.l :
;

~
\!.
~-

sea el último en su realización, ya que se está en mejores condiciones de
escribirlo si previamente se esruvo trabajando con la lista de acontecimientos y
el diagrama de contexto.
"El sistema debe permitir registrar las reservas que las escuelas realicen para
visitar el parque, y permitir la gestión de las visitas en lo que respecta a
controlar el ingreso de las visitas, relacionadas con el cobro, yJa asignación de
guías."
I .•~" .
Modelo de comportamiento preliminar I
Una vez construido el Modelo Ambiental, es posible cornen;zar la construcción
del modelo de comportamiento. Para ello, como se explicó anteriormente, se
pasará por una etapa iotennedia que es la construcción del modelo preliminar.
Este se compondrá de un DFD que tiene tantos procesos corno
acontecimientos se definieron en la Lista de Acontecimientos. En este· caso el
DFD que graficaremos para realizar nuestro modelo preliminar constar~ de 7
procesos (como ya se mencionó, no tomaremos en cuenta los acontec1ITUentos
'
.:.:
••·
realiza las reservas actualizando los almacenes "Escuela" (donde guarda los
datos de las escuelas que no habían hecho ninguna reserva anteriormente) y
"Reserva" (guarda todos los datos de la reserva realizada), a través de los flujos
de datos ''Datos particulares escuela" y · "Reserva registrada"
respectivamente.
j .:
» ,;. De igual manera se deben ir incorporando cada uno de los 7 procesos que dan
) ' . -r....
f, respuesta a los Y acontecimientos que se encuentran en la lista. Dichos procesos
se irán relacionando entre sí a través de los almacenes de uso compartido. Cabe
,. recordar que en este DFD, del modelo preliminar, no puede darse que un
proceso se conecte con otro a través de un flujo de datos, por ello si existe
' alguna relación entre ellos siempre será a través de uif almacén mediante.
Una opción a considerar en el uso de almacenes es la utilización de las Vistas.
Las vistas nos permiten agrupar varios almacenes en uno, y de esta forma
simplificar el diagrama. En el diagrama que se presenta a continuación se ha
•, utilizado una vista en ESCUELA, que representa a los almacenes ESCUELA Y
_., TELÉFONO ESCUELA. Como puede apreciarse en este ejemplo las vistas
son para agrupar almacenes que si bien desde el punto del modelo de datos
deben estar separados, desde el punto de vista funcional podría considerarse
1: que es una misma entidad.

colaterales).
··1~ -·
. . Cuando se utilizan vistas es necesario que exista una aclaración en el diagrama
::. que de cuenta de dicha situación, de lo contrario existirán inconsistencias con
Para construir el mismo debernos ir trabajando uno a uno con los las entidades definidas en el modelo de datos.

-
¡
acontecimientos de la lista, graficando en el DFD los procesos que les dan .t&·
respuesta. A continuación vemos cómo quedaría el modelo preliminar del caso que
estamos analizando.
Debemos entonces graficar en el DFD, a raíz de analizar cada acontecimiento,
el terminador y el o los flujos de datos relacionados con el mismo, que ya
existían en el Diagrama de contexto, y luego agregar el o los almacenes que
utilice el proceso. Por supuesto que habrá que graficar también los flujos ~~e
sean necesarios para representar que datos se guardan o consultan en relaaon
con estos almacenes.

Por ejemplo si tomamos el acontecimiento Nº 1, donde una escuela realiza una

reserva, debernos graficar en el DFD un proceso que podría llamarse "realizar
Ernesto Chin/u;
Emulo Chinhs
 CtJMt11/o 4: qp/i(ando lo1 ron(ej//01 del modelado a traviJ de 11n (OJO
Ñota: El almacén V ESCUELA es una vis ta de los almacenes ESCUELA Y
TELÉFONO ESCUELA.

Modelo de comportamiento final

Una vez que se encuentra realizado el modelo preliminar podemos realizar el
DFD de ni_v¡:l O de nuestro modelo de comp~rtamiento final. Para ello
debemos realizar la nivelación ascendente agrupan10 procesos.
i .•·" .
Por ejemplo, es posible agrupar los procesos " !./Realizar reserva", "3. Asignar
guía" y el "5. Registrar contratación guía" ert un· único proceso genérico
denominado "1. Realizar y preparar reserva". Por supuesto que el resultado
obtenido en el DFD de nivel O, debe ser consistente con los flujos existentes en
el DFD del modelo preliminar, y fundamentalmente con el Diagrama de
Contexto, ya que estamos representando el DFD de nivel O:que debe ser visto
como el resultado de explotar el único proceso que existe en el Diagrama de
Contexto. De igual manera es necesario ir agrupando el re, to de los procesos
según sea pertinente.

L uego de realizar la nivelación ascendente del modelo preliminar, podría

quedarnos un D FD de nivel O del modelo de comportamiento final como el
que se mues tra.

"'':-' Glen
z
e: c e
j,"ll
~
,o
en~
e: ¡¡;
ii> o
:u

Emulo Chink.,1
 Q!pít,,/a 4: t>fPlicando /tJ1 co1utpto1 tul motulado a lravi1 tu Jtn caso

.. .o-
2: ..
~
2:
5! ..
Una vez definido el DFD de nivel O hay que comenzar a realizar la rúvelación
~ ., 8 descendente. Es decir, explo tar los distintos procesos que ameriten ser
a: a: ..
w representados funcionalmente por dentro.
f-
w
..J
oa,
g~ En el ejemplo que estamos analizando esto quedaría de la siguiente manera.
E &.
:, E
~ ·;
.. .,
e:.,

<./~ !!
a~
., "
LI;';
~ a:

.~"
5
w
::,
~ u
::, (/)
l!)
..
2: ..
., "O e:
w
>

.. :i
., ~~
a: .!? ....,o
·¡¡
., e:
"5 -s e ~l .,2:.2'.,
t? g_ .,., "'e:
o
.,> ~ -!! a: - ...,-
z"
"
"'"O

/ ~ (/)
.,
~~~
N

- .. 9 :e ,:
.. "
.. ....
j¡; ~ 2:
!:! ~
ii a. .,
! .,
a: >- a. a:

...,
2:
.,.,
a¡:
~ .~ ..
o
"O
e:
!!
51 .g
.,., CII
¡;; g~
a:
., .."'
"5
z!!l ~
e:
..:. 8
o ...o -
o
l!)
.;,

1
w
Cl 5
w
Ñ

a:
o
(/)

::, 5
a:(/)
u
@ (/)
w
w~
n.::,
Íill!> Ernnto Chinlus
 Modelado de 11stema1 de infonnación

RESERVA
NÚMERO RESERVA
De ser necesario podrían seguir explotándose aquellos procesos de los
CÓDIGO ESCUELA
diagramas de nivel 1 a través de diagramas de flujos de datos de nivel 2, y así DIARESERVA
sucesivamen te. Es importante volver a remarcar que no necesariamente debe HORA RESERVA
ser balanceado, es decir, en este ejemplo dio la casualidad que se avanzó con CANTIDAD DE ALUMNOS
ambos procesos hasta el núsmo nivel, pero podría pasar que por ejemplo se CÓDIGO TIPO VISITA
DESCRIPCIÓN TIPO VISITA
realizará un DFD de nivel 2 sólo para el subproceso "2.4 Registrar y actualizar ARANCELACTUAL PORALUMNO
tipo de visita". CÓDIGO GUÍA
NOMBRE GUÍA
Nota: los flujos que se agregan a partir del modelo final se numerarán a partir CANTIDAD ALUMNOS REALES
del 1.000. . ARANCEL COBRADO

Modelo de datos
Al igual que se ejemplificó a través del caso de j¡¡ empresa ]11ra.uik Park SA., lo
I DOMICILIO ESCUELA
I explicado respecto al modelo funcional, se utilizará el mismo caso para hacer lo
propio con el modelo de datos. Por lo tanto, debemos analizar qué entidades,
atributos, relaciones, etc. son necesarias en este sistema.
Lo impoi:tante de analizarlo con el núsmo caso, es que pernúte observar como
el modelo de datos resultante debe ser consistente con el modelo funcional
obtenido.
Estructura de datos
ESCUELA
CÓDIGO ESCUELA
NOMBRE ESCUELA
NÚMERO TELÉFONO ESCUELA
Cabe aclarar que si se comienza a partir de más de una entidad, es importante
analizar si dichas entidades se encuentran relaciónadas, y tener en cuenta que
deben existir atributos que permitan establecer dicha relación. En este caso
existe una relación entre las dos entidades ya que las reservas son realizadas por
las escuelas, y para que exista dicha relación es necesario que en la entidad
RESERVA exista el atributo Código escuel.1.

Para elegir las distintas entidades que debe incluir el modelo de datos, y cuáles A partir de aquí se debe analizar si se encuentran en primera forma normal.
son sus atributos, es necesario estudiar la realidad que necesita guardar el Para ello se definirá la clave primaria (que identificaremos subrayando el o los
sistema. Es decir cuáles son las personas, cosas y/o hechos que el sistema atributos que la componen), y se eliminarán los grupos repetitivos.
necesita almacenar, y de cada una de ellas que características. Por supuesto que
las mismas deben quedar estructuradas en forma eficiente, para lo cual debe Sólo existe un grupo repetitivo, que se encuentra en la entidad ESCUELA con
utilizarse la normalización, quedando expresadas en tercera forma normal. · el atributo Número teléfono escuela, y por ello es necesario eliminar dicho
atributo de la entidad y crear una nueva entidad llamada IBLÉFONO
Para realizarlo se puede comenzar por agrupar todos los atributos en una o más ESCUELA.
entidades que sean las principales. Cua1ido se explicó el tema se comenzó
agrupando todos los atributos en una única entidad. En este caso podríamos
comenzar por la entidad RESERVA o comenzar por tomar más de una entidad
como principales, por ejemplo las entidades RESERVA y ESCUELA.

EJ Emulo Chink.,1
Emuto Chinleu
ca
 [;gpít11k! 5: qplicación práctica de caros

CAPÍTULO 5: APLICACIÓN PRÁCTICA DE CASOS

Caso 1:

Empresa productora (Picapiedras S.~)

La empresa Picapiedra1 SA. se dedica a la fabricacii:Ín ·d e carpetas. Para la
producción de las mismas, la empresa utiliza .las materias primas que tiene en
existencia.

Pedro, gerente de producción, es quien se encarga de realizar las compras de

materias pi:imas a los proveedores. Por lo tanto, requie;e un sistema que le
permita, cuando él lo requierá, obtener un listado con las materias primas cuyo
stock se encuentran por debajo del stock crítico (determi:1ado para cada una de
las materias primas), obteniendo además de cada una de ellas el precio de su
última compra, código y descripción.

Pedro es quien determina cuál es el stock critico de cada una de las materias
primas. Además, es quien determina cuáles son los productos que produce la
empresa, y cuáles y qué cantidades de materias primas los componen.

Los operarios de la planta, Pablo y Bety, son los encargados de ingresar cuáles
son las cantidades de cada uno de los productos que se han producido en el día.
Dichos datos los informan al final de cada día. Sobre la base de esos datos se
realiza la actualización del stock de las materias primas.

· Cuando se reciben las materias primas que envían los proveedores, se realiza el
·..,_ ingreso de sus cantidades para actualizar el stock de las mismas.

Obm1J(Jcionu:
✓ Una misma materia prima puede ser usada en más de un producto.
✓ Los product_C?S se eí\cuentran codificados.

Ernmo Chink,1

--------ª
Modtlado dt sistemas d, infom,ación

✓ Los datos que ingresan Bety y Pablo son las carpetas producidas y sus
Acontecimientos colaterales
cantidades. Esta información es necesaria para la a,ctualización del stock de
materias primas. Geren te de Modifica stock crítico de
Producción materia prima.
RESOLUGÓN
Gerente de Modifica composición de
MODELO AMBIENTAL Producción productos.
"
Declaración de propósito
Diagrama de contexto
El objetivo del sistema es administrar el stock de materias pri.mas.
1-Stock critico
Lista de acontecimi_f ntos
OPERARIO
2-Producto a fabricar
N° TERMINADgR · •"bESCRIPCJÓN DEL FLUJO DE FLUJO DE
: ACONTECIMIENTO ENTRADA SALIDA
1 Gerente de Determina stock critico 1
Producción de materia prima.
2 Gerente de Determina productos a 2
Producción fabrica':.
3 Gerente de Detera u.na composición 3 3-Composición
Producto
Producción de productos.
4 - Cantidad
4 Operario Informa cantidad 4 Producida

producida. 6-MP por debajo

5 stock critico
Proveedor Envía materias prima. 5
6 Gerente de Consulta materias 6 6 ' - - - -----=-s-~M~a~te~ria----iPROVEEDOR
Producción primas por debajo de Prima entregada
stock critico.

Emt1/o Chink.tJ

EJ Emulo ChinktI
 o
!
UJ
Q.
Modelo de comportamiento final
o

DFDDENIVELO
§::,
o 3-Composidón
o u
~ f-----"'..........f),I GERENTE/ _, 2-Producio a fabócar
DE I
a:
oa.. PROO~ION
Q.
::¡

-Stock critico

6-MP por debajo

stock critico

'-------- - - - -......~ 7-Stock critico M

MATERtA PRIMA

ea..
,¡,

actualizado
X produción

.,,.. MPPORPRODUCTO <'l---.......J

~t
-::¡'.. .,..
-e e
m E
"C
.,,a..
OPERARIO . - - - - -- - - --I PROVEEOOR
L-------->~M,.,....,at-en~
3
prima entregada

z a:
-o o
UJ u o
!z g UJ
UJ
UJ o eia:
a:
UJ UJ
oa:
C) o Q. Q.
 [;gpft11/o 5: aplicación práctica de COJO!

DFD DENIVEL1 DELffiüa'SO 2- RF.GISIRARY ACIUAUZARPRODI..JCTa,

DFD DE NIVEL 1DELPRüa'SO 1 - ADM!NlSIRARMATERIA PRIMA
3-Composición
GERENTE Producto
1-Stock Critico GERENTE PRODUCCIÓ
. - - --'--"="--"-""'-'""------1 DE
PRODUCCIÓ

-Producto a fabricar 4-Materia

MP pordebaj
rima por•
tockcrftico
roducto
I .,
I
MATERIA PRIMA -.....,., MATERIA PRIMA
15-
""'M
" "P
: :-:
de- ,b-aJ,.0---i;,t
stock critico 9-MP por
producto

2-Stock MP POR PRODUCTO

PROVEEDO ctualizado

' - - - -- -- - -- -~ >:.!'.jPR~O2!D~U!!:Ci.!TQO. ---r13-~pPJ¡oducto

Modelo de datos
Estructura de datos
MATERIA PRIMA
CÓDIGO MATERIA PRIMA
OPERARIO 1------:-
4_-cc:-
;; an~tid~a~drl),f DESCRIPCIÓN MATERIA PRIMA
producida STOCK CRÍTICO MATERlA PRIMA
STOCK AOlJAL MATERIA PRIMA
PRECIO ÚLTIMA COMPRA MATERIA PRIMA

Ernmo Chinkt1
 CatJí/11/o 5: f!Plicatión práctica tÚ co,os

Modelado tÚ 1istema.r de informaci6n

Caso 2:
MÁT ERJA PRIMA POR PRODUCTO
CÓDIGO PRODUCTO
CÓDIGO MAJFJUA PRIMA Gestión de expedientes en una institución educativa
CANTIDAD MATERIA PRIMA (Universidad de Aprendetodo)
PRODUCTO La Universidad Aprendetodo es una institución de reconocido prestigio. En la
CÓDIGO PRODUCTO misma existen departamentos académicos que son los encargados de tratar las
DESÓUPCIÓN PRODUCTO I
distintas problemáticas, de naturaleza académica, que en ella surjan. A la cabeza I
D iagrama de entidad relación de cada departamento se encuentra un director.

Cotidianamente se reciben en de la universidad eexpedien tes por distintos

MATERIA requerimientos que son dirigidos a los directores de departamento.
MATERIA PRIMA
PRIMA POR Esta compuesto
PRODUCTO
PRODUCTO por Los expedientes tienen un número que los identifica unívocamente, que es
otorgadó por la universidad cuando el iniciador del expediente quiere dar
comienzo al mismo. El sistema debe informar al iniciado r el número de
expedien te. Quien lo inicia y presenta es el iniciador. Por lo tanto, el iniciador
informa su Nombre, Domicilio, Teléfono(s), Motivo del expedien te3,
Departamento al cual va dirigido, y fecha de inicio del expediente.
Dichos expedientes son entregados al departamento que corresponda para que
se encargue de su resolución, en lo que al mismo concierna.

Una vez que el departamento ha finalizado el tratamiento del expediente, lo

entrega al área que corresponda para hacer seguir el curso del expediente. A su
vez, cada área deberá redireccionar el mismo al área que corresponda, hasta que
el mismo quede resuelto.

· El departamento debe informar el tratamiento a darse (descripción), fecha de la

decisión, y área a la cual lo direcciona. L uego el mismo puede ir pasando por
distintas áreas, debiendo saberse en todo momento en cuál área se encuentra y
en qué fecha lo recibió. Cuando se concluye el tratamiento del expediente, debe

3Los motivos del expe~eote pueden ser, por ejemplo, el nombramiento de un docente,
una denuncia, remoció.n de un docente, pedido de equivalencias de _un alumno, etc.

Ernesto Chi11/ees

Ernu~ Chinku
 Y!Jil/11/o 5: qpk(ación práctica de ,a101
MotklaM tk µs/ema[ de infom,ación
informarse la fecha en que fue finalizado y la solución dada (descripción).
Lista de acontecimientos
Además debe notificarse al iniciador sobre la misma. N" TERMINADOR DESCRIPCIÓN DEL FLUJO DE FLUJO DE
El iniciador podrá requerir, en todo m omento, el estado de situación de su ACONTECIMIENTO ENTRADA SALIDA
expediente. 1 Iniciado r Presenta un 1 2
requerimiento.
Se le pide a Ud., que realice el análisis de un sistema de información que
permita a los departamentos gestionar los expedientes que recibe y su 2 Ditector de Revisa expedientes 3 3
seguimiento posterior por las distintas áreas. departamento sin tratar.

3 Director de Decide tratamiento 4

Obmwciones: departamento de expediente.
✓ Cabe aclarar que si el iniciador ya inició o tro trámite con :interioridad, no es
necesario que informe su nombre, domiálio, y teléfono'(s). Por otra parte, 4 Atea Revisa expedientes 5 5
se desea que los iniciadores se encuentren codificados. / ···' · derivados.
✓ Cada expediente se dirige a solamente un departamento académico. Y 5 Area Deriva expediente. 6
puede ser recibido una sola vez por cada área.
✓ Por cada uno de los movimientos del expediente entre las áreas debe 6 Area Resuelve 7 8
guardarse: área, fecha de recepción y actuación del área. expediente.
✓ Cada expediente tiene solamente un motivo. 7 Iniciador Requiere estado de 9 9
✓ Los departamentos se encuentran codificados, y es necesa•io tener situación de
registrado el nombre del director actual de cada departamento. expediente.
✓ Las áreas por las cuales se mueven los expedientes se encuentran
8 Arca Recibe el 10
codificadas.
✓ Cada expediente puede tener sólo una fecha de finalización y una solución
Expediente.
(descripción). 9 Universidad Crea un nuevo 11
✓ La universidad está evaluando reestructurar la organización de la misma departamento.
creando nuevos departamentos y áreas.
10 Universidad Crea un a nueva 12
RESOLUGÓN área.

Modelo ambiental
Declaración de propósito
El sistema debe permitir administrar y realizar el seguimiento de los expedientes
desde su inicio hasta finalización.

E mulo ChinluJ

EJ E mu lo Chinlu1
 Cqpitulo 5: qplicación práctica dt c0101
Morklado dt 1úttma1 dt información
Diagrama de contexto

Acontecimientos colaterales 8-Notificación 3-Expedientes

.ó
INICIADOR IRECTORDE
Universidad Cambia al director EPARTAMENTO
de un
departamento.

Iniciador Informa cambios en

sus datos
personales. 2-Número 4-Tratamiento
Sistema expediente
Universidad Cierra un de
1-Re uerimiento
departamento. manejo
de
Universidad Cierra un área. 1O-Expediente
expedientes
recibido
9-Estado
situación
expediente

7-Resolución
UNIVERSIDAD 12-Nuevo área
ÁREA
11-Nuevo
departamento

Emt1/o Chinlw
Ernt1to Chinkt1 - --------- ------18
Modelo de comportamiento final
DFD DENIVELÜ

9-Estado
INICIADOR situación

8-Notlficacón
Resolución

1-Requerimiento 7 • J?____
V INICIADOR
c-h 1•-D'-a;¡-to;;;s•runu,,.e,vv
21-Datos
iniciador
ÁREA

expediente
__,.__ _~_32-Motivo
MOTIVO expediente
3-Expediente
sin tratamiento
1
12-Expedlente 20-Datos
!-Tratamiento iniciado resolución
,xpediente

19-Derivación ?-Resolución
expediente expediente
4-Expediente
tratado 24-Datos
expediente

17, 22-Datos 11-Nuevo

expediente departamento

DIRECTOR DE DERIVACIÓN EXPEDIENTE 16,23Datos

DEPARTAMENT derivación expediente

Modelo de comportamiento preliminar

IHIC&AOOfl k
·=
l •fll-gueriml•nto

~
r....
)<AJMilhntU
n•• I>
06RECTOR DE
1DEPARTAMENT"O

UJJ•ditnll

AIIV,

~
kJ 12-,.._,,..,, .,... jlHV'Efll.SIOAO

N ota: E l almacén V IN ICIADOR es una vista de los alcoaccncs INICIADO R Y TELÉFONO INICIADOR.
 tJ
~
,,►
!I!
tl
i ~
DFD DENIVEL 1 DELPROCE9J 1- INTQI\RYREGISIRAREXPEDIENIE <
z !!' H!
ci
¡;

i 1-
if
8,, '!.;; ~

INICIADOR 1.005 - E>dstencia

ij ~
¡¡
Iniciador
~ ~- :
l 1
I
I
~
o
f
oz
,.~
V INICIADOR N
1
2
~ ~
ñ1

;1; ...
ii 1
12-Expediente
iniciado
MOTIVO 31-Motivo
¡ti
r
¡S
Q e
!~
~
expediente 'I' ,.~ ~
z 2
g
1
i
ü ~
i
EXPEDIENTE ¡¡

i H ~

13-Datos expedientes
1tf
15-0erivación
expediente área
3-Expedientes
sin tratamiento
o
fi
.. t

e
1
~
i::

DERIVACIÓN EXPEDIENTE ~ t:: ~

¡t
!!?
◄-Expediente
ratado ~ ~
o
!RECTOR DE
◄-Tratamiento EPARTAMENTO

:.E
.... 11
 Mod,lodo ~ JÍJ/emas de informoaón

Modelo de datos •;(":. !:,· o

.,.., _.,_.,. ~- 1-
z
Estructura de datos 1~. !1
w
::;¡
~
il.í
a:
·::...: a:
<
<(
EXPEDIENTE
NÚMERO EXPEDIENTE
~~-
...:.5!•·· f. a.
w
o
CÓDIGO INICIADOR
CÓDIGO MOTIVO o
CÓDIGO DEPARTAMENTO
FECHA lNICJO .. 'tJ
.s
~
TRATAMlENTO DIRECTOR ' o
:2
"'
.. ., o
w Q.
FECHA DECISIÓN
SOLUCIÓN FINAL
·¡:
i5
.,
w w
o
..
'O ,

-.,~
FECHA SOLUCIÓN FINAL 1-
z 'tJ
ozw
t-
-Z
., ,, w uw
I DERIVACION EXPEDIENTE o "' <-
I w >
- ºW
NÚMERO EXPEDIEN1E ~
X
a:
wx ~

CÓDIGOAREA w ow
fF.CHA RECEPCIÓN
ACruACIÓN ARE.A

INICIADOR
..
e.,
CÓDIGO INIClADOR
.,
~
NOMBRE INICIADOR ~

DOMICIJ..10 INICIADOR o
Q.

~
TELÉFONO INICIADOR a: '"
o Q.

CÓDIGO INICIADOR o o
'tJ
~
NÚMERO TELÉFONO INLCIADOR o '"
'ü
~ :E
DEPARTAMENTO "'
w
CÓDIGO DEPARTAMENTO Cl
-o
NOMBRE DEPARTAMENTO ·¡:¡
NOMBRE DIRECfOR .!!u
... IIJ
.,e:
ÁREA 'ti ¡::
o
l'l >
cóDIGOAREA 'ti
·.:, §
NOMBRE ÁREA d ~
u o a:
MOTIVO ~ - z o
CÓDIGO MOTIVO l'l ..ttºº~
DESCRIPCIÓN MOTTVO a
l'l
-'-º
w-
t- ~
~
~
Erntslo Chinkts o
 [;gpítulo 5: abÚ·cación práctica de caJoI

_Caso 3:

Administración de organismo de investigación universitaria

La Secretaría de Investigación y D octorado de la Universidad ha solicitado un
sistema informático que la ayude en su tarea de control y administración de los 1 ,J
1
investigadores que de ella dependen y los proyectos que realizan.

De la Secretaría dependen aproximadamente 150 investigadores, que se

encuentran repartidos en 54 Institutos. Cada investigador puede pertenecer a uno y
sólo uno de los institutos.

Todo investigador es nombrado y categorizado mediante una resolución expedida

~.., ,... ...
~
~:¼'.:- por la Universidad, la que es entregada a la secretaria. Existen distintas categorias

1[·
-~ ~
i!S:' ';,
de investigadores y todo investigador debe pertenecer a una.
Actualmente las categorías son:

1) Docente
" a) Titular
' b) Asociado
; c) Adjunto
.. d) Jefe de trabajos prácticos QTP)
e) Ayudante de primera
f) Ayudante de segunda
g) Visitan te

2) Becario
a) Estudiante
b) Graduado de iniciación
c) Graduado de perfeccionamiento
d) Ayudante de investigación

4 Po_siblemente la Universidad incorpore un nuevo instituto el año próximo.

Emulo Chinlw ________________,~

 {;gJ¡ít11/a 5: qplicación práclica dt ca101
Modelado dt MltmaJ dt infómradón s:~. ;
11,;;. },,
Proyecto actual:
La Universidad puede crear nuevas categorías si lo considera necesario. -~V.:•·
~-~~·i.. t· ✓ Título
Cada investigador propone un proyecto al cual se le asigna un número de
proyecto.
itt~:~ ✓
✓
Fecha iniciación
Fecba de finalización
✓ Resultado informe final
Cuando la secretaria aprueba el proyecto, le asigna una fecha de iniciación y una de
finalización. La aprobación dd proyecto y sus fecbas se deben comunicar al Proyectos anteriores:
investigador. .~

!· ✓ Título
Cuando finaliza el proyecto, la Secretaria evalúa los resultados del proyecto ✓ Fecha iniciación
(satisfactorio o no s~tisfactorio) e informa el resultado al in~f~tigador. ✓ Fecba de finalizagón
I .•.f · . ✓ Resultado informe final
La Secretaria debe poder consultar, en cualquier mor¡\ento, · respecto de un
investigador. Además quiere poder listar todos los investigadores identificando su nombre,
instituto, y categoría.
Datos personales:
Obmvacionu:
✓ Nombre ✓ El número de proyecto es único.
✓ Número de legajo ✓ Los proyectos son individuales,. es decir cada proyecto pertenece a un solo
✓ Teléfono/s investigador.
✓ Domicilio ✓ Un investigador sólo puede tener una categoría.
✓ Nacionalidad ✓ El número de legajo es único.
✓ Número de Documento ✓ En una resolución se puede· nombrar a varios investigadores.
✓ Estado civil
✓ Fecha de nacimiento RESOLUCIÓN
✓ Número de ia resolución de designación
Modelo ambiental
.Declaracion de propósito
E l objetivo dd sistema es permitir la administración de los investigadores
nombrados y la gestión y seguimiento de los proyectos presentados por los
mismos. ·

1
Emulo Chinku
Ernt1/D ClinMI

1
Modelado de fÍ[l(maI de información
:z:
· o e
z ~
F. ~ ~
Lista de acontecimientos ¡!! ;o
(/)
o'
N° T E RMINADOR DESCRIPCIÓN DE L FLUJO DE F LUJO DE t ~
o ..h ~
ACONTECIMI ENTO ENTRADA SAl.IDA ,...
n
!o <
z t')

1 Universidad Nombra a un 1 < ..

:,.
<
m
o

! '~ª
C/)

investigador mediante , .... o

ci
una resolución. 5". .o>

2 Secretaria Aprueba proyecto 2 3

....
G)
..
'?
,¡¡ ~
,go
o
;o
~~ ~
~-
~ ..o g_ .. l.i
presentado por
investigador.
o
~
~
ii :,
., e:
.
¡j ¡¡
z
>
10 O
DI ..
c.
!!
;:s
o
~
: ....
o "<
:,. (")
(")
i5
"'t
3 Secretaría Evalúa resultado del 4 5 § >
.... z ....
~
(1)

>
...
P·
m r
proyecto. ~-
¡¡
G")
o;o o
>
~-
;:s
o
4 Secretaría Consulta datos sobre 6 6 ..
p.
> 1::\
investigador. f ..n
't' "'t

lo "g- "a: -< -:; '(J

5 Secretaría Requiere información 7 7 t :,. -, ~ - "'0 N

~ " ..
.. -
.., < o

de investigadores.
..
p
n
p
;1~-;"
t: ~ o ags
o g_
. ...,
!l ~-6 i .. Q 6
.., "S!"' c.
..
DI

~
¡j
6 Universidad Crea un nuevo
instituto.
8
i i !!.6
:::J n
..,;o !l

[º~ o
-<
m
7 Universidad Crea una nueva 9 o
....
categoría. o

8 Investigador Propone proyecto. 10

1[9
Acontecimientos colaterales ~=º
6g.. ..a- >'-'

Universidad Elimina una categoóa.

~
..,
'?

..
.. ..
.., .
a oz
c.
!! ª...... ""
~~
~
tT
' ~
Universidad Elimina un instituto.
z< ~!
:, o.
o-
;o
".
.. z
u,
C/)
m
n
Informa modificación ;o
Investigador m :,

en sus datos
(/)
.... iª
8- ~
m
....
>
ci !l.
o-
;o
personales. > ;;-
o
o

Emesto Chinlw

]
 DFD DENIVEl.. 1 DELPROCESO 1-ADMINlSTRAR INVESilGAOORES
~
a: N
~
w
a:
o A

' --
W
-'(/);_ ___,N UNIVERSIDA
1· nves
nombrado-resol 15-Nueva
naciooelidad
., ,,
o
,,o!!! ~ o
.,::, tí.,
:g ._g"'
o
.,
t, ,,
o
- .,
111 .,
o>
., >,
a: o
,,tQ.
'--'2e.::3-c:.N:::8CIOl
Investigador
·= l::::•::clids=d-~IACIONALIDAD

' e
t--- • 14-Datos
o>,"'
,,
~ e Investigado,
ti;-
Q.
NOS ., 23-Nacionalida
I \? Investigador
I v
"'::, 4-Subcatogorfa 2-lnstituto

-i,;:r ,,e'""' o.,

., >, nvesligador 3-Catego<la

"' -o!!! tí l
r-----<..-2-,,7--0a-tos--V INVESTIGADOR
$ - .. E ;::
~
iñ
o G)
., , , >,
., .. o
01 01 ~
G>; 0.
1--- 1.000 - Categorfa
CATEGORIA
invesligadoíes
,, ~
O-Datos nueva
>
·'=/ tego,ia
NSTITUTO
6-
S-lnstituto
nvestigador

&-Datos
B o
o,,
B ,.._
., "'e
o .,
nstituto
eado
>: ~

~ o.. ..
' ., 21-Datos
d
o
u ~ º ' 7
-Datos
proyecto
investigador
o a:
"os
'"O
13
oo nvestigadores
&-Instituto 6-Datos
a ¡¡¡
a: ~ aeado Investigador
y proyectos
PROYECTO

fb.O w (/)
>
os z z~
i5 ::)
Modelo de comportamiento final
DFD DENIVELÜ

6-Datos
1-lnvestigador investigador SECRETAR!.
UNIVERSIDAD!
nombrado - resol.
7-Datos
investigadores

V INVESTIGADOR
'.-Proyecto
,probado
27, 22-Dato'
investigador -Resultado
,royecto

,-Nueva categoría
2 5-Nolificación

8-lnstituto 14-Datos
creado Administrar investigador Administrar 3-Notificación
investigadores proyectos

1O-Proyecto
presentado

,1-Datos
21 -Datos ,royecto
proyecto ,resentado
investigador L....-- ------ INVESTIGAOOI

DFD DENIVEL 1 DELPROCESO 2 -ADMINISIRARPROYECIDS

' '
\~

4-Resultado
proyecto
SECRETAR!,
9-Resultado
,royecto

PROYECTO

31-Datos
proyecto
presentado

kJ 17-20 Datos V INVESTIGADOR

investigador
proyecto

INVESTIGADOI
 [;gpítulo 5: aplicación práctica de ca.ros
Motklado de sistemas de i11fom1ación RESULTADO INFORME FINAL
NÚMERO LEGAJO INVESTIGADOR

Modelo de datos NACIONALIDAD

WDIGO NACIONALIDAD
Estructura de datos DESCRIPCIÓN NACIONALIDAD

INVESTIGADOR
NÚMERO LEGAJO INVESTIGADOR
NOMBRE INVESTIGADOR ·
DOMICILIO INVESTIGADOR
NÚMERO DOCUMENTO
ESTADO CIVIL
FECHA NACIMIENTO
NÚMERO RESOLUCIÓN DESIGNACIÓN
CÓDIGO INSTITIJTO
CÓDIGO SUBCATEGORÍA
CÓDIGO NACIONALIDADS

TELÉFONO INVESTIGADOR
NÚMERO LEGAJO
NÚMERO TELÉFONO INVESTIGADOR

INSTITtrrO
CÓDIGO INSTITUTO
NOMBRE INSTITUTO

CAT E GORÍA .
CÓDIGO CATEGORÍA
DESCRIPCIÓN CATEGORÍA

SUBCATE GORÍA
CÓDIGO SlJBCATEGORIA
DESCRIPCIÓN SUBCATEGORiA
CÓDIGO CATEGORÍA

PROYECTO
NÚMERO PROYECTO
TÍIUW
FECHA INICIACIÓN
FECHA FINALIZACIÓN

s En este caso no se ~onsidera la posibilidad que el investigador tenga d oble

nacionalidad.
Emulo Chinku

EJ Ernuto Chinlw
 {)r;ítulo 5: aplicarión práclira de rn101

t~ ~
,~:. 1.
Caso 4:
< o
li:
oC) <
ir ~ Empresa organizadora de eventos (Mafalda S.A.)
oC) :::;
,-... 1
~
8
11
1 11 w o La empresa Maja/da SA., se dediai a la realización de congresos, conferencias y
m
::) -o
.. 1-
u< ü
z<
cursos sobre nuevas tendencias teaiológicas. Debido a la gran cantidad de .,,.
V) :~
-o eventos que realiza y a la gran concurrencia que tienen los mismos, necesita un (
., e
1:: V)., =I= sistema que la ayude en la gestión de los mismos.

l La empresa tiene en su poder información sobre posibles asistentes a sus cursos

.,., (Nombre, Domicilio, Tdéfono(s), Profesión(es), y Temas de su interés). Dicha
"'o
(l_ información la obtiene d área de marketing respecto de los asistentes a cursos
anteriores, y a recolección de información que cotidianamente va obteniendo en
a: colegios pro fesionales, asociaciones, y promociones en las cercanías de otros
j 8< ~ congresos, conferencias, etc.
C) 11
OE ¡::
V)
11 Cuando la empresa está por realizar un evento, envía invitaciones a los posibles
w
~ >
?,;
asistentes. La sdección de los mismos la realiza d Responsable de la
Organización dd Evento según la(s) profesión(es) y los temas de interés que se
I= tienen almacenados de las personas. ·
.,e
8
C)
.,e
..
iii"
.o
.,e
1)
Aqudlas personas a las que les interese concucrir al evento, se deberán inscribir
hasta una semana :mtcs de la realización dd mismo. (Sólo- se podrá inscribir
.,
t: e ¡::
1-
personas hasta colmar la capacidad de asistentes del evento.)
(l_

-~ 2 2 a:
El día de realización del evento, cuando las personas llegan, se deben acreditar.
En este momento, se deberá verificar que dicha persona se encuentre inscripta en
o o el evento, y en cuyo caso se le debe emitir y entregar la tarjeta de ingreso.
tiw o~
~
¡:: ),,
ZC>
~¡:: Además, es de vital importancia para Felipe, el gei:ente genera~ poder obtener
V) o -WV)
~
a: ...Jw información sobre un evento. La información es Código y Nombre del evento,
~~
(l_

Tema, Cantidad de personas invitadas, cuántas de éstas se inscribieron, y cuántas

asistieron.-

Emttto Chinkt1
 Canítuh 5: at,.lzcación hródica d, ,wo1
Modelado dt rotem1u Je informació11 5 Gerente Requiere información 7 7
De igual manera es de sumo interés para Guille, Encargado de atención al general sobre un even to
cliente, poder saber para una persona determinada a qué eventos fue invitada y particular.
en qué fecha, en cuáles se inscribió y en qué fecha, y a cuáles asistió.
6 E ncargado de Requiere información 8 8
atención al sobre una persona
Observaciones:
cliente determinada.
✓ Una persona puede tener más de un tema de interés, dichos ternas son una
lista de ternas que la empresa ha catalogado, la cual puede ir variando en el 7 Responsable Organiza un evento. 9
tiempo. El responsable de atención al cliente es el encargado de la Organización
actualización de los mismos. Evento -
✓ Un evento tiene un solo tema asociado. El terna pertenece a la lista de
8 Encargado de Incorpora un nuevo 10
ternas de interés que la empresa ha catalogado.
atención al terna a la lista de
✓ Los eventos duran como máximo un día.
cliente temas.
I
RESOLUCIÓN I
Acontecimientos colaterales
Modelo Ambiental
Responsable Modifica da tos del
Declaración de propósito organización evento.
evento
El propósito del sistema es gestionar la organización de eventos y tl segumiento
de los mismos. Persona Cancela-inscripción
al evento.

Lista d e acontecimientos Responsable Cancela evento a

organización realizarse.
N° TERMINADOR DESCRIPCIÓN DEL F LUJO DE FLUJO DE evento
ACONTECIMIENTO ENTRADA SALIDA
1 Encargado de Incorpora una
1 .kea de Obtiene información
atención al nueva profesión a la
marketing sobre posibles
cliente lista de profesiones.
asistentes.

2 Responsable Selecciona invitados a 2 3

Organización un evento.
Evento

3 Persona Se inscribe al evento. 4

4 Persona Se acredita al evento. 5 6

Ernuto Chlnkt1

EJ Ernt1lo ChinktI
 Diagrama de contexto
1-Datos posible
ESPONSABLE
ÁREA 2-Selección RGANIZACIÓN
MARKETING Invitados ENTO

9-Evento nuevo
Sistema
de
GERENTE
Gestión
GENERAL 7-Datos sobre
de
evento 4-lnscripción
Eventos
5-Acreditaclón

ENCARGAD 10-Tema 6-Tarjeta

ATENCIÓN incorporado PERSONA
3-lnvitación
CLIENTE 8-Datos sobre
persona

Modelo de comportamiento final

DFDDENIVELÜ

-
1.a.tm pmitil

-i--
,___ ,'TO

. . _.....

""""""'
.,..s,.,¡_

,........., '"°"" -
,,,"""""
.............
~-
-- -
L..- - ---t>F'ERSCN'.PCA&91T'O 1ns;;;:.r,mu11

,.,,..,.,,...,_ """'°""

-,
 :.

º""',. o,an
0,.,-,U OlU9A3:§

VNOSll3d

--~"-'I
UljlP~~l:
OJ.N311

I NQIOVZINV0~1
318VSNOdS3

'YNOS~d/\

e , -1•1•
I Oll!Q·L.

0pelfAU1-'t

W,31 L--{> OJ.N3113 >,K)d VNOS~3d

"""
U91••10Jd-t
3.1N3n:,J • '.,.,_,nv,. •11J1111n
NQION31V e !IOd I0lSO• ONU.3 >4~~
OCMlWON3 V3"Y

OlN31\31IVZ!.NVD'tlO- '[. OS.3:X)<L:I'I.3:CT '[.1ID\IN3G Gi[Q

Modelo de comportamiento preliminar

9- EvenlO nuavo
AREA
MÁRKETING

b "·-- I> PROFESION

24-Proful6n
~ 1&-Persona al

ENC,.RGAOO kl-+----1>(
ATENCtON
:1tado
CLle.NT~
eventos persona

-
10-Nuevo tema
2&-0alos
persona

EVENTO

t1•0ato••~
ewito
:,n,rcfid
'•nionu por
1n10
PERSONA

rte~

TEMA
7-01101 sobre evento

Nota: El almacén V PERSONA es una vista que incluye los almacenes PERSONA, TELÉFONO PERSONA,
PROFESIÓN PERSONA Y TEMA DE INTERÉS PERSONA.
o l> m ,,m
~
,.. --1 z
mmo ;u
!Í Qz ;ul> en
mo!j? o (,,Jítulo 5: qplicación práctica de casos
ZO ~ ~
j
....
Modelo de datos
1q;
n
Estructura d e d atos
h ~
; PERSONA
'f
i ..
a. ~
~
CÓDIGO PERSONA
¡¡; NOMBRE PERSONA
Q. f,PELLI.00 PERSONA
N /OOMTCILJO PERSONA
' ;

~
PROFESIÓN PERSONA
CÓDIGO PERSONA
CÓDIGO PROFESIÓN
TELÉFONO PERSONA
5· ~
córnGOPI~
~6
g !t .. 9.~ NÚMERO J ELÉFONO PERSONA
.. :¡¡ ?§
. 1
<
.. ~ EVENTO
~ ó
m
<
m ,,~ CÓP)GO EVENTO
o ~ NOMBRE EVENTO
! ~
o
..
o
:, m
;u
2' CÓDIGO TEMA

1
en FECHA EVENTO
o CAPAClDAD DE ASISTENTES
z
,,
l>

o
;u
TEMA DE INTERÉS
o-<
~ CóQIGOTEMA

..ª
~11p . m
!Í
o
DESCRIPCIÓN TEMA
TEMA DE INfERÉS PERSONA

G"lCl
~~
mm
~ r~ 1 CÓDIGO PERSONA
CÓDIGO TEMA DE INTERES
PERSONA POR EVENTO
,.. !Í
m CÓDIGO EVENTO
CÓDIGO PERSONA
FECHA INVITACIÓN
FECHA INSCRIPCIÓN
ACREDITACIÓN
PROFESIÓN
CÓDIGO- PROFESIÓN
DESCRIPCIÓN PROFESIÓN

Enrt1l0 Chinh1
a
 .
'

Diagtama de entidad relación

TELÉFONO
PERSONA

Fue invitada
o inscripta PERSONA
PROFESIÓN
PERSONA POR EVENTO
PERSONA
EV ENTO
Tn~"ci81°rfs o
invitados

iene preferencia

·rata sobn

TEMA
DE Esta Interesada
PROFESIÓN TEMA
INTERÉS
PERSONA
 Modelado de sislemaJ de información

Caso 5:

Distribuidora de libros (Simpso_11; S.A.)

La empresa Simp1on SA. se dedica a la edición y comercialización de libros.
I
Los libros son vendidos directamente al lector, nunca a librerías. Para lo cual
tiene un plantel de unos 50 vendedores que se encargan de visitar a los posibles
clientes en sus casas y lugares de trabajo.

Las personas a las cuales se visita y vende deben ser empleados de empresas u
organismos con los cuales la empresa haya fumado un acuerdo. El acuerdo
establece que las empresas u organismos descuentan del sueldo del empleado el
importe de la venta, y pagan la suma de todos éstos mensualmente (menos un
porcentaje) a Simp1on SA.

Dichas empresas u organismos deben entregar un listado con los datos de

todos sus empleados (Legajo, Nombre, Teléfono(s), D omicilio). Todos los
meses deben informar sobre los nuevos empleados contratados, y los que ya no
trabajan más.

El gerente de ventas, Homero Simpson, requiere un sistema que le ayude en la

asignación a sus vendedores de personas para visitar, así como en el
seguimiento de dichas visitas.

Homero desea que el sistema posea ingresados todos los empleados que
trabajan en las distintas empresas u organismos. Una vez por semana desea
poder consultar y, sobre la base de esto, asignar a cada vendedor personas para
visitar (aproximadamente 50 visitas) duran te dicha semana, emitiendo una ficha
por cada persona que se le asigna (ver Ficha). Dicha ficha se entrega al
vendedor-para que realice la visita.

Emulo Cbink,s
 Cg¡,ílltlo 5: apli.ración práctica d, ,osos

Ejemplo de ficha que sale del sistema:

VENDEDOR: código: 20 / Nombre: Bart

PERSONA:
' J
Nombre: Smithers Pedro
Legajo: 100511
Empresa: cóaigo: 50 r nombre: P lanta Atómica S.A.
Teléfono particular: 4855-5452
Domicilio particular: Av. Los Andes ·45 5º "B"
Teléfono empresa: 4664-2554
I
., Domicilio empresa: Av. San Martín 5544
1
VISITA:
Semana asignada:
Desde el: 01/06/1999
Hasta el: 07/06/1999

Fecha visita: ..:__/_/_

Respuesta: 1) Venta o
2) Volver otro día o
3) No interesa el producto o
4) No visitó o

Al finalizar la semana se ingresan al sistema: la fecha en que el vendedor realizó

la visita y la respuesta que se obtuvo de la misma. Esto se realiza sobre la base
de lo que el vendedor completó en la ficha durante la visita.

Homero desea obtener, cuando él lo' solicite, un detalle de lo sucedido con las
visitas asignadas..a un vendedor determinado en un período de tiempo (ver
Listado).

Erntsto'Chinlus
 Ct:rpítulo 5: aplicarió11 práctica de caro1
Modelado de ¡Íftenra1 de infornraéión Obrervacioner:
Ho~ero es el encargado, además, de tomar nuevos vendedores cuan do élki ✓ Todos los empleados de las empresas tienen legajo. Los números de legajos
considere converuente. También esta considerando incorporar nuevos tipos de pueden repetirse entre empleados de distintas empresas, pero NUNCA
respuesta a la ficha del vendedor. dentro de una misma.
✓ Las empresas tienen la misma dirección y teléfono(s) pata todo s los
Ejemplo Listado: empleados que en ella trabajan. .
✓ - Las posibles respuestas que pueden tener las visitas están codificadas,
Lirtado de viritar por vendedor entre 01/05/1999 y 15/05/1999: existiendo más que las cuatro que s.~ muesífan en la ficha del ejemplo.
✓ Una misma persona puede ser a~ignada -~ ás de una vez, y a un vendedor
VENDEDOR: código: 20 / nombre: Bart distinto cada vez; pero NUNCA puede ser asignada más de una vez en una
misma semana de asignación.
RESPUESTA: código: l / Descripción: Venta
RESOLUCIÓN
Fecha visita Le!!aio Empresa (códii?o - nombre)
01/05/ 1999 95045
Modelo ambiental
50 - Planta Atómica S.A.
05/05/1999 100511 50 - Planta Atómica S.A. Declaración de propósito
06/ 05/ 1999 215 2 - Gas N atural SRL
..... El objetivo del sistema es permitir la organización, asignación y seguimiento de
visitas.
1Total de visitas: 15
List a de acontecimie nto s

N° TERMINADOR DESCRIPCIÓN DEL FLUJO DE FLUJO DE

RESPUESTA: código: 2 / D escripción: Volver otro día ACONTECIMIENTO ENTRADA SALIDA
1 Empresa Firma acuerdo. 1
Cliente
Fecha visita Le o - nombre
2 Empresa Informa alta y bajas de 2
02/05/1999 2 - Gas N atural SRL
Cliente empleados.
15/ 05/ 1999 5 - Ener 'a Eléctrica S.A
3 G erente de Asigna personas a 3 4
Ventas vendedores para visitar
1Total de visitas: 5 durante la semana.

4 Vendedor Realiza la visita. 5

iTOTAL VISITAS: 20
5 Gerente de . Solicita detalle de visitas 6 6
Ventas realizadas.
-
Emulo Chinku [fil
Er,mto Chink,1
 <.. u Gl
't'
pm
_ ;:: t)
~m ~

6 Gerente de Contrata a un nuevo 7 • >

(/)
m
~
<
:.:
:
':!! :ll
;¡j~
t9
·~ m ?il
Ventas vendedor. 1
.. -·-- i
,15·
-;'

..
~
¡: ¡1
7 Gerente de Incorpora un nuevo tipo 8 •·i <
o
a.
= ~f .....
Ventas de respuesta a la ficha. ..a
<
i=
' ..g ~
.;

;
~ :·
.' a.
Acontecimientos colaterales
·r'·
Gerente de Da de baja a un
Ventas vendedor. • -!
,i:·
': t' ......
1

Empresa· Informa cambios en los

i
: datos personales de los
I .., empleados.
I <
Empresa Informa cambios en los ':!!
•. o
datos de la misma. o
§;o -<
...
1a
·~~
..
•·- !5º'1' ..
i~
~
~
:1 ::f ~ .. i-1 ."i 2'
.,1,-··
"O
o
;o
li'
..
o
~· ~
¡~
~

'f
~g-
.. ..g- -~ ?il
..:f,
IJI
"O
e
IJI
►
,..
<
~
!i,. '<

<
1
¡¡;
ii

EJ E rnuto Chinh1
 t,
< nm ~-
'"
::, ¡...._ _ _ _ _ _ _ _-, = 3
<D -o Cl,:j
E
~
o 5 . Y,
~~ r.,
6
IO
~ ~~ ~
., lX '-~--~---' ,.
e: r,
6f {D-4 (1)1\) o
O. 3r'r, - 3 c, CI
-1" o -3 °!:!.!!l. ¡;
~~ ---~ []
iil::: . [g
g
~
o
$ ~
.,i
~- cg ~
~g.~g-¡¡-
.. o- 3

: , "'fi--, -.J
zl
~{
~ - s;
~ ~
g-cn -o,
e:

~<
~
ci
en ~ Z ~
"O e: o
e '" ~
.. <
~o
~'{'
., $
"'.g:
o
[~
.,o. "'
"' < o. G"l
..=.
....

"'
(l)
CD
::,
éi'

,- -t~ --· . , ,.-~~~- .... ,';, ! . ':'· ,1,·t:· .. ,.,;·,...-~ .• --!" --: -
~tG..~:.~--J:~.'-. ~"r :.::-i,) .'!~.f
)"rJ .d~~::...~:..f~.~-¡l'~'..1L.;.i.~--'f·1,I -,..:: .- ~-
·,
~
~
· · ~J?~• ·••. il '•
~ ,, .,... ' . ~

r. - . . _

Modelo de comportamiento final

1-~Y
EMPRESA empleados
VENDEDOR
CLIENTE

15aios"empresa1 V EMPRE 22-Empresa de

la visita

14-0atos
,Altas empresa 23-T,po
Respuesta por
Visita
4-Ficha Visita

20-Datos
visitas
·-Nuevo vendedor realizadas
VISITA
3--Vlsitas
19-Resultado
asJ¡¡nadas
visita
~
vendedor
VENDEDOR 21-Vendedor
Visite
8-Nuevo llpo

GERENTE
DE ri--------------------¡¡-¡;¡;;¡;;-:------------ -----1
' 8-Visitas
VENTAS realizadas
 r -\

o"'
Q. ¡¡;
~ --= IIJ
:,
r.t)
UJ
.,,Q. w
::i e! f- r.t)
Cl.
r.t)
z <(
UJ f-
UJ
o:: o:: z
www
oCl. ~
(!)O>
¡:: o :G
.Q- =i
f-1 Q. "'
U) :t::::
~~@

i .,,

~~~
o ~
'l:I
A ~ill
:t::::

5~
~
<( 1
1'.l
.¡
i
"

~
i¡

s
1 1

.~~ ~-~
N
º•
¡¡j o::d

~~
C) , - - -r-,..1 N

Q
z
@
"O ª~
o2

~ ~
o ~

~ _:.,~ .. _ t

~::~
~
~- )'1.:-~· ."f'-<'

Modelo de comportamiento preliminar

EMPRESA
CLIENTE 1-Empreae y
empleado,•_ __ _ _ _ __

2-0■tos
empleados- O.Plantel
Altas y Bajas 1mpleados

12-01101
V EMPRESA ~------<l>i VENDEDOR
~i'!W~e■dos por

18-Empleados
sin asignar
-----~
l=-=-!>TIPO RESPUEST> 15-Tlpos de i
Respuesta

VE NDEDOR

'-Nuevo
1endedor
2o~oaio1
Visitas
reahza des

5-VisltH
GERENTE Realizadas
DE
VENTAS 3-VilitH
Asignadas

Nota: El almacén V EMPLEADO es una vista que incluye los almacenes EMPLEADO y TELÉFONO EMPLEADO.
FI ~lm ':lr;.n V ~MPR'J'.;'C::.A ,,..: .. n ... ,.;.,,-,.. ,..,.., ;... ..-1 ...... 1,...,• .. , ______ ,. c11,1nn r.C"" • . "T"'T""T , '- ,....,.... .. • - ..,... ,. .................. •

\.
 o<{
Modelo de datos z (/)
Ow
u. cr:
,w 0.
Estructura de datos ~ :¡¡
1-w
VENDEDOR
CÓDIGO VENDEDOR ..,
, NOMBRE VENDEDOR I
/
EMPLEADO
CÓDIGO EMPRESA
NÚMERO LEGAJO
NOMBRE EMPLEADO
iíiw ~
w
o:: ::::,
DOMICILIO PARTICULAR 0.
::; o 0.
w 2: ~
1- o::
TELÉFONO EMPLEADO
CÓDIGO EMPRESA
ill!.MERO LEGAJO
NÚMERO TELÉFONO EMPLEADO
..
-1'.r~ ,i :
e

"'"
EMPRESA
CÓDIGO EMPRESA
2
t
.. "'e
"'
E
NOMBRE EMPRESA o
DOMlCIUO EMPRESA

TELÉFONO EMPRESA
CÓDIGO EMPRESA
NÚMERO 1ELÉFONO EMPRESA o
~ ~
TIPO RESPUESTA ..J
0.
::;
..
'O
(/)
5
CÓDIGO TIPO RESPUESTA w _g¡
DESCRIPCIÓN TIPO RESPUESTA tii
i!!
., o
'O
w
VISITA "'
e
.,
.5!'
CÓDIGO EMPRF...sA "'"'
NÚMERO DE LEGAJO w
FECHA ASIGNACIÓN VISITA
FECHA VISITA o::
CÓDIGO VENDEDOR ºº
zO oo
CÓDIGO TIPO RESPUESTA ~.ili o
w
-~ ~ z
w-::l w
1- w >
 CAPÍTULO 6: CASOS PARA RESOLVER

Caso a: instituto de salud

El Instituto traumatológico Integral desea desarrollar un sistema que le permita

administrar la asignación de turnos a los pacientes. :

Cuando un paciente llama para solicitar un turno, Andrea, la recepcionista, debe

verificar si el paciente ya ha sido atendido. Si no fue atendido en el· instituto
anteriormente, le · solicita los siguientes datos personales: Número de
documento, Nombre y apellido, Fecha de_nacimiento, Domicilio, Teléfono,
Obra social a la que pertenece y Número de afiliad9.

I Cada vez que el paciente solicita un turno, Andrea, debe verificar que este
I disponible, en cuyo caso le asigna el turno informándole el número de turno
1
correspondiente.

Cuando el paciente concurre al instituto, debe presentar el carnet que lo

acredita y se debe emitir la orden de consulta donde figuran los datos que
quedaron registrados: nombre y obra social del paciente, nombre del medico,
fecha y hora del turno y se registra la hora en que llegó el paciente. Los médicos
dispondrán de una computadora, donde pueden consultar los pacientes que se
encuentran esperando. ·

Cuando el médico atiende al paciente debe completar en el turno el motivo de

la consulta, los síntomas y el tratamiento correspondiente.

Los médicos, además, deben poder consultar todos los tumos a los que haya
concurrido un paciente en particular, obteniendo los siguientes datos: fecha·de
consulta, motivo, síntomas, tratamiento y nombre y apellido del medico d_e cada
una de los mismos

Obseroaciones:
✓ Un turno es para un solo paciente, y es atendido por un solo médico.
✓ Lqs médicos se encuentran codificados.
✓ Las obras· sociales se encuentran codificadas.
✓ Cada paciente-:tiene una sola obra social.

Ernt1lo Chinkt1

Modelado de 1iit,mas de infomtaaón
Caso b: taller mecánico ,
El_ taller de reparación de automóvil_es_ "AlcAle" desea mejorar el servicio que
bnnda a s_us ~entes. Por_ello ha dectdido desarrollar un sistema que le permita
llevar la histona de sus clientes y de las reparaciones que ha efectuado sobre los
automóviles de los mismos.
Cuando un clien~e lleva su automóvil al taller para que Jo revisen, si es un nuevo
cliente se le realiza una ficha personal donde se registra su número de cliente
nombre y apellido, domicilio, e-mail, teléfonos y fecha de cumpleaños y ademá¡
se le realiza una ficha para el automóvil donde figuran patente, cliente al cual
pertenece, marca, modelo, año y color. Además, se le debe abrir una orden de
repara~ón donde se ingresa la fecha y hora de entrada del automóvil, patente y
el moavo por el cual lo lleva.
Cuand~ José, Miguel o Carlos, que son algunos de los mecánicos, _arreglan el
a_utomovil, deb~? complet~ _la orden de reparación informando, kilometraje,
llpo _de repara_cton, el mecaruco que realizó la misma y las observaciones que
considere pert:mentes.
Cu_ando el cliente retira el ~~tomóvil, se debe completar la fecha y hora de
salida en la orden de reparacton Antes de revisar cada automóvil, los mecánicos
deben consultar el sistema para saber.si el mismo ha sido reparado en el taller
con anterioridad y qué tipo de reparaciones se le hicieron.
Por otro lado, _Ramó~, el dueño del taller desea poder obtener por ejemplo el
nombre y apellido, telefonos y e-mail de los clientes que realizaron determinado
Upo de reparación por última vez hace mas de N días o meses.
Obmvadonu:
✓ Los tipos de reparación se encuentran codificados.
✓ Un cliente puede tener más de un automóvil, pero un automóvil pertenece
solo a un cliente.
✓ ~ada orden de _r_eparació~ puede tener más de un tipo de reparación, y cada
Upo de reparaaon es realizada por un solo mecánico.
El Emulo Chinhr
Capítulo 6: ra101 para molvtr
Caso c: venta y logística de distribución de helados
La heladería ''Pablito" desea abrir un nuevo punto de.venta a través de Internet.
Para ello necesita desarrollar un sistema que le permita automatizar la
operatoria de solicitud y entrega de pedidos.
Cuando un cliente ingrese a !_a.página principal del sitio de la heladería deberá:
I .•·""
✓ Poder consultar los gu{tos de ·helado disponibles y su composición.
✓Realizar pedidos (especificando cantidad y gustos de helado).
✓Cuando el cliente realice un pedido óbtendrá dt; inmediato un número de
pedido.
✓ Si no es un usuario registrado deberá ingresar previamente sus datos
especificando nombre, domicilio, teléfono, e-mail, fecha de cumpleaños.
✓ Verificar el estado de su pedido.
Por su parte, los operadores de nuevos clientes de la heladería deben verificar
su existencia y asignarles un número de cliente a los nuevos usuarios
registrados. (El cliente debe ser notificado de su número para que pueda
realizar el pedido.)
Los operadores de expedición son quienes ;e encargan de armar los pedidos y
asignarlos a un repartidor, para ello consultan la cantidad y gustos del pedido y
número, nombre y domicilio del cliente. Una vez armado el pedido y entregado
a un repartidor, ingresa en el sistema el código del repartidor y el horario de
expedición del pedido.
El Doctor Juan Pablo López, gerente de logística de la heladería, necesita que el
sistema le permita obtener la cantidad de pedidos y la cantidad de kilos de
helado que se solicitan por _día.
Por su parte, el Licenciado Javier Martínez, gerente comercia~ desea poder
obtener un listado de los clientes que hayan realizado más de 10 pedidos en el
último ~es," eiip.ecificando número de cliente, nombre y apellido, e-mail,
domicilio, fecha de _rumpleaños y la can tidad de pedidos realizados. _
Enruto Chi•hr

Modelado de1islemaJ dt información
Caso d: administración de proyectos de una consultora
Una Consultora de reconocido prestigio que asesora empresas en proyectos de
sistemas de información tiene interés por implementar un sistema de
información que satisfaga sus necesidades de información respecto de la
administración de los proyectos que lleva a cabo. Por lo tanto, debe quedar
registrado en el mismo la siguiente operatoria.
Cuando una empresa necesita de los servicios de la consultora, se realiza una
entrevista con el Director de Proyectos de la consultora, quien, luego de la
misma, asigna a uno o un grupo de consultores al nuevo proyecto,
especificando la fecha de comienzo, de finalización y el costo del proyecto.
En la entrevista, la-·eínpresa cliente debe informar las personas de su empresa
con las cual_~s deberá interactuar la consultora, indicando el nombre, apellido, y
cargo de las mismas. Las personas serán siempre las mismas por mas que la
empresa haya contratado a la consultora en más de w1 proyecto.
Una vez que los consultores son asignados al proyecto, el Coordinador de
Recursos se encarga de distribuir la cantidad de horas planificadas que deberá
trabajar cada consultor !especto del proyecto.
Ademá1, el Direcl/Jr dt P~ec/01 necuila podtr consultar en/rt otras .rmu:
l. Cuáles son los proyectos en los que se encuentra trabajando la consultora.
Por cada uno de los mismos necesita saber. código de proyecto,
descripción, fecha de inicio, fecha planificada de finalización, código y
razón social de la empresa cliente.
2. Cuáles son los distintos consultores que trabajan o trabajaron en un
proyecto determinado (indicando por cada uno código de consultor,
nombre y apellido del consultor, cantidad de horas planificadas asignadas).
3. Cuáles son las personas, de una empresa clienta en particular, con las cuales
se debe contactar (código, nombre, apellido, y cargo de las distintas
personas).
Ernulo ChinJ:,1
Capítulo 6: CaJOJ para molwr
Caso e: administración de una biblioteca
La biblioteca de una universidad ha decidido hacer una rcingenierfa de su
sistema de prestamos.
Para solicitar libros, los usuarios deben estar registrados. Si el usuario no
esta registrado, debe informar su número de documento, nombre,
apellido, domicilio, y teléfono/s para registrarse.
Cuando el usuario necesita un libro, puede consultar en una terminal de
autoconsulta si el libro esta disponible (esto es cuando existe por lo menos un
ejemplar del título buscado), y en que número de estantería se encuentra. Una
vez que obtiene el o los libros de la estantería: debe presentarse ante un
bibliotecario, presentando el o los libros y su documento para solicitar el
préstamo. El bibliotecario, luego de ingresar los datos del usuario y de los libros
(número de documento e ISBN7 de cada uno de los libros), le otorga el
préstamo. El préstamo quedará·registrado, y se le asigna al mismo un número
de préstamo.
El usuario solicita los libros por Wla cantidad x de días (la cantidad total de días,
sumando los distintos libros, no debe superar los 20). Luego cuando los
devuelve, se contrula· las fechas, y si no lo devuelve en término queda
inhabilitado (el usuario) para solicitar otro )µ,ro por una cantidad de días igual al
doble de los que se excedió, y por lo tanto queda registrado en el sistema la
fecha hasta la cual el usuario estará inhabilitado. Al usuario se le imprime nn
comprobante de penalización donde se le informa: número de préstamo y fecha
de préstamo por el cual fue penalizado, y cantidad de días que se atrasó.
Cada vez que el sector de compras adquiere un nuevo título se debe ingresar al
sistema indicando su ISBN, título, autor/ es, editorial, edición, resumen.
Cuando lo que se adquiere es un ejemplar de un título ya existente, lo que se
debe es aumentar la cantidad de ejemplares.
1 El ISBN, Intemational Standard Book Number, es un número que identifica
unívocamente los libros (es un ISBN por título, no por ejemplar).
Ernuto Chinw
Modelado tÍI Ji.Jtemas tÍI infoT111ación

Obmvacionu:
✓ Los títulos se identifican unívocamente por d ISBN.
✓ Solo se podrá otorgar un préstamo si d usuario no está inhabilitado en
dicha fecha.
✓ Los autores y las editoriales se encuentran codificados.
✓ Un usuario puede solicitar más de un libro por préstamo.

I ..•-'
I

Emulo Chink11