Arquitectura de tecnologa de la informacin (ellos inician primero)

Mensajera electrnica y tecnologa de trabajo en grupo

El correo electrnico ha crecido! Ya no es slo una forma para comunicarse con mayor eficacia,
los sistemas de informacin estn siendo diseados para incorporar directamente la tecnologa. Por
ejemplo, Microsoft Exchange Server y Lotus Notes de IBM permiten la construccin de formas
electrnicas inteligentes que pueden integrarse en cualquier aplicacin. Los servicios bsicos de
mensajera tambin pueden integrarse en aplicaciones.
Por ejemplo, cualquier empleado va una forma basada en el correo electrnico podra iniciar
solicitudes de viaje. El sistema toma los datos suministrados en la forma y sigue reglas predefinidas
para dirigir automticamente la peticin a las personas que toman las decisiones apropiadas. Por
ejemplo, las solicitudes de viaje de menor costo podran dirigirse directamente a un ejecutivo del
negocio. Las peticiones ms caras podran dirigirse primero a un director de departamento para su
aprobacin y luego a un ejecutivo del negocio. Por ltimo, las formas aprobadas pueden ingresarse
de manera automtica al sistema de informacin apropiado de procesamiento de reembolsos para su
procesamiento normal. Y en cada paso, el sistema de mensajera informa del avance por medio del
correo electrnico al empleado que hizo la solicitud. Un DFD fsico que inclua una implantacin
de mensaje por correo electrnico se present anteriormente.

El intercambio electrnico de datos

Los negocios que operan en muchas ubicaciones y los negocios que buscan un intercambio ms
eficiente de transacciones y datos con otros negocios a menudo utilizan el intercambio electrnico
de datos. El intercambio electrnico de datos (EDI, por sus siglas en ingls) es el flujo electrnico
estandarizado de transacciones de negocios o datos entre negocios. Por lo comn, muchos negocios
deben comprometerse a un formato de datos estndar para hacer factible el intercambio
electrnico de datos.
Con el EDI, un negocio puede eliminar su dependencia de los documentos de papel y del correo.
Por ejemplo, la mayora de las universidades ahora aceptan puntuaciones de pruebas de SAT o ACT
va el EDI de los centros nacionales de prueba. Esto se ha hecho posible porque los servicios
escolares de la universidad han accedido a un formato estndar para estas puntuaciones de pruebas.

Las imgenes y el intercambio de documentos

Otra tecnologa emergente de E/S se basa en las imgenes y el intercambio de documentos. Esto es similar al
intercambio electrnico de datos, excepto que se transmiten y se reciben las imgenes reales de las formas
y los datos. Es particularmente til para aplicaciones en las cuales se requieren imgenes de formas o grficos.
Por ejemplo, la industria de seguros ha progresado a grandes pasos en la transmisin, almacenaje y uso de
imgenes recuperadas por medios electrnicos. Otras aplicaciones de imgenes combinan datos con cuadros o
grficas. Por ejemplo, una aplicacin policiaca puede almacenar, transmitir y recibir imgenes fotogrficas y
huellas digitales

Middleware La mayor parte de las anteriores secciones se centraban en entradas y salidas: la interfaz del
usuario. Pero muchos diseos de sistema requieren flujos de datos fsicos de proceso a proceso.

Anteriormente en este captulo describimos diversos escenarios de cmputo cliente/servidor y de redes que en
forma automtica incluyen flujos de datos de proceso a proceso porque las computadoras clientes y los
servidores deben hablar entre s. Las computadoras hacen esto a travs del middleware. El middleware es la
utilera de software que permite la comunicacin entre procesadores diferentes en un sistema. Puede
incorporarse en los sistemas operativos respectivos o aadirse a travs de productos de middleware
comprados. Los productos de middleware permiten a los programadores ignorar los protocolos de
comunicacin subyacentes. Se dice que el middleware es la diagonal de cliente/servidor. Hay tres clases
de middleware que casualmente corresponden a las tres capas de nuestro marco de sistemas distribuidos:
lgica de presentacin, lgica de la aplicacin y lgica de manipulacin de datos:

El middleware de presentacin le permite a un programador construir componentes de la interfaz de usuario

que pueden hablar con los navegadores de Internet o una GUI de escritorio. Por ejemplo, el HTTP permite
que el programador se comunique con un navegador de Red a travs de una Interfaz de Programador de
Aplicaciones (API, por sus siglas en ingls) estndar.

El middleware de aplicacin permite que dos procesos escritos por programadores

para procesadores diferentes se comuniquen entre s del modo que sea ms conveniente para la aplicacin
completa. El middleware de aplicacin es esencial para el desarrollo de aplicaciones multicapas. Los ejemplos
de middleware de aplicacin son numerosos: las llamadas a procedimiento remoto (RPCs), las colas de
mensajes y los corredores de peticin de objetos.

El middleware de la base de datos permite que un programador enve los comandos de

SQL al motor de la base de datos para su procesamiento a travs de un API estndar.
Otros tipos comunes de middleware son ODBC (Object Database Connectivity, Conectividad Abierta de la
Base de Datos) y JDBC (Javabean Database Connectivity, Conectividad de la Base de Datos tipo Java), los
cuales automticamente traducen los comandos de SQL de un servidor de base de datos para usarse en otro
servidor de bases de datos (por ejemplo, Oracle para el SQL Server, o viceversa). En un diagrama de flujo de
datos fsicos, el middleware puede dibujarse especificando el nombre de la clase del middleware en el flujo de
datos fsicos (por ejemplo, ODBC).
> Arquitecturas de proceso: el ambiente de desarrollo de software
La arquitectura de proceso de una aplicacin se define en trminos de los lenguajes y las
herramientas de software que se usarn para desarrollar la lgica de los negocios y los
programas de aplicacin para ese proceso. Por lo comn, esto se expresa como un men
de elecciones, porque los ambientes diferentes de desarrollo de software son adecuados
para aplicaciones diferentes. Un ambiente de desarrollo de software (SDE, por sus siglas en ingls) es un
lenguaje y un juego de herramientas para la construccin de aplicaciones de sistemas de informacin. Una
forma de clasificar los SDE es de acuerdo con el
tipo de arquitectura de cmputo cliente/servidor o de red que soportan.
SDE para la presentacin de cmputo centralizado y distribuido
No hace mucho tiempo, el ambiente de desarrollo del software para el cmputo centralizado fue muy sim
ple. Consista de lo siguiente:
Un editor y un compilador, generalmente COBOL, para escribir programas.
Un monitor de transaccin, generalmente CICS, para manejar cualesquiera pantallas
terminales y transacciones en lnea.
Un sistema de administracin de archivos, tal como el VSAM, o un sistema de administracin de base de
datos, como DB2, para manejar los datos almacenados. Eso era todo! Ya que todas estas herramientas se
ejecutaban en el mainframe, slo que el sistema operativo de la computadora (la mayora de las veces, MVS)
era crtico. La computadora personal llev muchas nuevas herramientas de desarrollo de COBOL a
la mainframe. Un COBOL SDE basado en PC como el Workbench de COBOL de Micro Focus
proporcion al programador unas herramientas de prueba y de correccin de errores y editores ms poderosos
a nivel de la estacin de trabajo. Un programador podra hacer mucho del trabajo de desarrollo en ese nivel y
luego cargara el cdigo en la computadora central para la prueba, el afinado del desempeo y el sistema en
produccin. Con frecuencia, el SDE podra estar en interfaz con una herramienta CASE y un generador de
cdigo para aprovechar los modelos de proceso desarrollados durante el anlisis de los sistemas.
Finalmente, los SDE suministraron las herramientas para desarrollar sistemas cliente/servidor de presentacin
distribuida. Por ejemplo, el Dialog Manager de Micro Focus suministr a los usuarios del COBOL
Workbench herramientas para construir interfaces de usuario basadas en Windows que pudieran colaborar con
los monitores de transaccin CICS y los programas de COBOL del mainframe.

SDE para cliente/servidor de dos capas M

Actualmente el SDE tpico para aplicaciones de dos capas de cliente /servidor (tambin llamado de datos
distribuidos) consta de un lenguaje de programacin basado en el cliente con conectividad incorporada de
SQL para uno o ms motores del servidor de bases de datos. Los ejemplos de SDE de dos capas de
cliente/servidor incluyen PowerBuilder de Sybase y Delphi de Borland (versin de cliente/servidor). Por lo
comn, estos SDE proveen lo siguiente:
El desarrollo rpido de aplicaciones (RAD, por sus siglas en ingls) para construir rpidamente la interfaz
grfica del usuario que se replicar y se ejecutar en todas las PC del cliente.

La generacin automtica del cdigo de la plantilla para la GUI antes citada y los eventos asociados de
sistema (tales como un clic del ratn o del teclado, etc.) que usa el GUI. El programador slo tiene que aadir
el cdigo para la lgica del negocio.

Un lenguaje de programacin que se compila para copia y ejecucin en las PC clientes.

La conectividad (en el lenguaje ya citado) para diversos motores relacionales de bases de datos y la
interoperabilidad con esos motores. La interoperabilidad se logra
incluyendo rdenes de bases de datos de SQL (por ejemplo, crear, leer, actualizar,
suprimir y ordenar registros) que sern enviadas al motor de la base de datos para
su ejecucin en el servidor.

Un ambiente artificial para probar y depurar el cdigo para el cliente.

Un ambiente de pruebas del sistema que ayuda al programador a desarrollar, mantener y correr un guin de
prueba reusable de datos, acciones y eventos del usuario contra los programas compilados para asegurar que
los cambios de cdigo no introduzcan problemas nuevos o imprevistos.

Un ambiente de generacin de reportes para simplificar la creacin de nuevos reportes de usuarios finales de
una base de datos remota.

Un sistema de ayuda para las PC clientes.

Actualmente, la mayor parte de estas herramientas vienen incorporadas en el SDE,

pero han surgido vendedores independientes de herramienta de software que producen herramientas sustitutas
que a menudo suministran todava mayor funcionalidad y/o
productividad que las provistas en el SDE bsico. Para aprender ms acerca de estas herramientas accesorias,
busque en Internet el Programmers Paradise (Paraso de los Programadores), un portal de Web de
herramientas de desarrollo de software.
Parte de la lgica del proceso de cualquier aplicacin de dos capas de cliente/servidor puede descargarse en el
servidor de la base de datos en forma de procedimientos almacenados. En este caso, los procedimientos
almacenados se escriben en un superconjunto (una extensin) del lenguaje SQL. Estos procedimientos son
luego llamados desde el cliente para su ejecucin en el servidor. Diferentes expertos parecen amar u odiar
los procedimientos almacenados. Desde el punto de vista positivo, puede hacerse que los procedimientos
almacenados constrian mejor la integridad de los datos en las tablas de bases de datos.
Son reusables y verificables. Desde el punto de vista negativo, dificultan la distincin entre las capas de
aplicacin y de manipulacin de datos de nuestro marco; son lgica de aplicacin que se ejecuta en los
servidores de bases de datos. Muchos diseadores prefieren una estrategia de diseo ms consistente llamada
de distribucin en capas limpias (clean layering). La distribucin en capas limpias requiere que la
presentacin, la aplicacin y las capas de datos de una aplicacin estn fsicamente separadas. Se dice que la
estratificacin limpia permite que los componentes de cada capa se revisen y amplen sin afectar a
otras capas del sistema

SDE para cliente/servidor de multicapas

El actual estado del arte en el desarrollo de aplicacin de la empresa ocurre en los SDE para las arquitecturas
de cliente/servidor de tres capas (y ms all). A diferencia de las aplicaciones de dos capas, las aplicaciones
en n capas deben soportar ms de 100 usuarios con tiempo de respuesta de transaccin y procesamiento
parecidas a los de una mainframe, con bases de datos de 100 gigabytes o mayores. Mientras que los SDE de
dos capas antes descritos estn tratando de expandirse en este mercado, una clase diferente de SDE lo domina
hoy. Por lo comn, los SDE de esta clase deben proveer todas las capacidades tpicamente asociadas con los
SDE de dos capas, adems de lo siguiente:

Soporte para plataformas heterogneas de computacin, tanto al cliente como al

servidor.

Generacin de cdigo y programacin tanto para los clientes como para los servidores.

Un gran nfasis en la reusabilidad usando marcos de aplicacin de software, plantillas, componentes y

objetos.

Herramientas integradas de miniportafolios para anlisis y diseo que interacten

con los generadores y editores de cdigo.

Herramientas que ayudan a los analistas y programadores a separar los componentes

de aplicacin entre los clientes y los servidores.

Las herramientas que ayudan a los desarrolladores a implantar y manejar la aplicacin terminada para los
clientes y los servidores. Generalmente esto incluye las herramientas de administracin de seguridad.

La habilidad para escalar en forma automtica la aplicacin a plataformas mayores y

diferentes, de clientes y servidores.

La administracin de la aplicacin y control de nuevas versiones del software.

Los ejemplos de SDE de cliente/servidor de n capas incluyen a Dinasty de Dinasty y
VisualAge de IBM (una familia de productos). Otra vez, un gran nmero de vendedores
independientes de herramienta de software estn construyendo herramientas complementarias y sustitutas
para estos SDE.
SDE para cliente/servidor en Internet e intranet
Estn surgiendo herramientas de desarrollo de aplicacin rpida para permitir aplicaciones de cliente/servidor
en Internet y en intranet. La mayora de estos lenguajes se construyen alrededor de un eje de cuatro
tecnologas estndar:
HTML (Hypertext Markup Language), el lenguaje que se usa para construir la mayor parte del contenido y de
los hiperenlaces de las pginas de Internet y de intranet.
XML (Extensible Markup Language), un lenguaje extensible para transportar datos y sus caractersticas a
travs de la Red.
CGI (Computer Gateway Interface), un estndar para publicar componentes, construcciones y enlaces
grficos de la Red Mundial.
Java, un lenguaje de programacin de uso general para crear servlets, applets y programas independientes de
la plataforma, que pueden ejecutarse desde adentro de la mquina virtual de Java (Java Virtual Machina) de
un navegador.
Los ejemplos de SDE especficos de Java incluyen a WebSphere de IBM y Jbuilder de Borland. Estos SDE
pueden crear aplicaciones de Internet, intranet y aplicaciones que no sean de Internet/intranet. Virtualmente
todos los SDE existentes de dos capas y de n-capas tambin estn evolucionando para soportar HTML, XML,
CGI y Java.

Estrategias de arquitecturas de aplicacin para el diseo de sistemas

Al margen de cmo se llamen, todos los sistemas de informacin tienen una arquitectura de
aplicacin. Las diferentes organizaciones aplican estrategias diferentes para determinar la
arquitectura de aplicacin que usan. Clasifiquemos brevemente los dos enfoques ms
comunes.
> La estrategia de arquitectura de aplicacin empresarial
En la estrategia de arquitectura de aplicacin empresarial, la organizacin desarrolla una arquitectura de
tecnologa de la informacin que abarque a toda la empresa para ser se guiada en todos los proyectos
subsiguientes de desarrollo de sistemas de informacin. Esta arquitectura de tecnologa de la informacin
define lo siguiente:
La red, los datos, la interfaz y las tecnologas de procesamiento y herramientas de desarrollo aprobados
(incluyendo hardware y software, y clientes y servidores).
Una estrategia para integrar los sistemas y las tecnologas heredadas en la arquitectura de aplicacin.
Un proceso permanente para revisar continuamente la arquitectura de aplicacin en cuanto a su actualidad y
conveniencia.
Un proceso continuo para investigar tecnologas emergentes y hacer recomendaciones para su inclusin en
la arquitectura de aplicacin.
Un proceso para analizar peticiones de desviaciones de la arquitectura de aplicacin aprobada.

Una arquitectura de aplicacin inicial generalmente es desarrollada como un proyecto

separado o como parte de un proyecto estratgico de planeacin de sistemas de
informacin. El mantenimiento en curso de la arquitectura de aplicacin se asigna por lo
regular a un grupo permanente de investigacin de tecnologa de la informacin o a un
comit de arquitectura de aplicacin de la empresa.
Con posterioridad a la aprobacin de la arquitectura de aplicacin, se espera que cada
proyecto de desarrollo de sistemas de informacin use o escoja tecnologas basadas en esa
arquitectura. En la mayora de casos, esto simplifica mucho la fase de arquitectura de una
metodologa de desarrollo de sistemas. Usted slo selecciona entre las tecnologas
aprobadas segn las reglas o los lineamientos de la arquitectura.
Por supuesto, aun si una tecnologa es aprobada en la arquitectura de aplicacin, est
sujeta a un anlisis de factibilidad, tal como se describe en la siguiente seccin.
> La estrategia tctica de arquitectura de aplicacin
A falta de una arquitectura de aplicacin que abarque a toda la empresa, cada proyecto debe definir su propia
arquitectura para el sistema de informacin que se est desarrollando. No obstante puede existir algn tipo de
grupo de tecnologa de la informacin de investigacin y de despliegue.
Aun cuando la arquitectura de aplicacin propuesta para cualquier sistema de informacin nuevo puede ser
influida por las tecnologas existentes, los desarrolladores por lo regular tienen algo ms de libertad para
elegir nuevas tecnologas. Por supuesto, la decisin final debe ser defendida y aprobada como factible. La
factibilidad de la tecnologa de la informacin generalmente incluye los siguientes aspectos:

Factibilidad tcnica. Ya sea una medida de madurez de una tecnologa, una medida de conveniencia de la
tecnologa para la aplicacin que se est diseando, o una medida de la capacidad de la tecnologa para
trabajar con otras tecnologas.

Factibilidad operacional. Es una medida de qu tan cmodos estn la administracin del negocio y los
usuarios con la tecnologa y qu tan cmodos estn los gerentes de tecnologa y el personal de soporte con la
tecnologa.

Factibilidad econmica. sta es una medida de si la tecnologa es costeable o no y si es eficiente con base en
costos, lo que implica que los beneficios sobrepasan a los costos.
Los criterios de factibilidad y las tcnicas para medirlos fueron cubiertos en el captulo 9.

Modelando la arquitectura de aplicacin de un sistema de informacin

El uso de DFD lgicos para modelar requerimientos de proceso es una prctica bastante
aceptada. Sin embargo, la transicin de los DFD lgicos orientados al anlisis a los DFD
fsicos orientados al diseo ha sido histricamente algo misteriosa y oscura. Deseamos un
diseo general de alto nivel que pueda servir como una arquitectura de aplicacin para
el sistema y un diseo general para los procesos que constituyen el sistema. Al mismo
tiempo, no queremos quedar atrapados en un ejercicio contraproducente de modelado
que desacelere nuestro progreso en el diseo de sistemas y el rpido desarrollo de la
aplicacin. Dicho de manera simple, queremos un plano que nos gue a travs del diseo
detallado y la construccin. El plano identificar las unidades de diseo para la
especificacin detallada o el desarrollo rpido, lo que sea ms productivo en nuestro
proyecto.
> Dibujo de diagramas de flujo de datos fsicos
La mecnica para dibujar los DFD fsicos es idntica a la de los DFD lgicos. Las reglas de
exactitud son tambin idnticas. Un diseo aceptable resulta en:
Un sistema que trabaja.

Un sistema que cumple con los requerimientos del usuario (especificado en los DFD
lgicos).

Un sistema que proporciona un desempeo adecuado (en procesamiento y tiempo

de respuesta).

Un sistema que incluye suficientes controles internos (para eliminar los errores humanos y de la
computadora, asegurar la integridad y la seguridad de los datos y satisfacer las restricciones de auditora).

Un sistema que es ajustable a los requerimientos que siempre cambian y a las ampliaciones.
Podramos desarrollar a un DFD fsico individual para el sistema entero o un conjunto de DFD fsicos para el
sistema objetivo. Nuestra metodologa sugiere lo siguiente:

Deber desarrollarse un diagrama de flujo de datos fsicos para la arquitectura de red. Cada proceso en este
diagrama es un procesador fsico (cliente o servidor) en el sistema. Cada servidor es su propio procesador; sin
embargo, es imprctico mostrar a cada cliente. En lugar de eso, cada clase de clientes (por ejemplo, una orden
para ingresar un dependiente) est representado como un procesador individual.

Para cada procesador en el modelo anterior deber desarrollarse un diagrama de flujo de datos fsicos para
mostrar los eventos de cada procesos (vea el captulo 8) que sern asignados a ese procesador. Es posible que
usted elegira duplicar algunos de eventos de procesos en procesadores mltiples. Por ejemplo, las rdenes
pueden procesarse en los servidores y clientes de cada regin.
Para todos con excepcin de los eventos de procesos ms simples, debern factorizarse en unidades de
diseo y modelarse como un diagrama de flujo de datos fsicos individual. Una unidad de diseo es una
coleccin autocontenida de procesos, almacenamientos de datos y flujos de datos que comparten atributos de
diseo similares. Una unidad de diseo sirve como un subconjunto del sistema total cuyas
entradas, salidas, archivos y bases de datos y programas pueden ser diseados, construidos, y la unidad
probada como un subsistema individual.
Un ejemplo sera un conjunto de procesos (uno o ms) para ser diseados como un programa individual.
Luego la unidad de diseo podra asignarse a un solo programador (o un equipo) quien (el cual) puede
trabajar independientemente de otros programadores y equipos sin afectar adversamente el trabajo de los otros
programadores. Las unidades implantadas luego seran ensambladas en el sistema de aplicacin final. Las
unidades de diseo tambin pueden ser priorizadas para implantar las versiones de un sistema.

> Los prerrequisitos

Formulemos la tabla para describir los prerrequisitos para crear DFD fsicos. Se incluyen:
Un modelo de datos lgicos (el diagrama de entidad relacin creado en el captulo 7).
Los modelos de procesos lgicos (los diagramas de flujo de datos creados en el captulo 8).
Detalles del repositorio para todo lo citado antes.
Dados estos modelos y estos detalles podemos distribuir datos y procesos para crear
un diseo general. Su diseo general normalmente estar restringido por uno o ms de
los siguientes:
Los estndares de la arquitectura que predeterminaron la eleccin de los sistemas de
administracin de base de datos, la topologa y la tecnologa de la red, interfaz(es) de usuario(s), y/o los
mtodos de procesamiento.
Objetivos del proyecto que se definieron al inicio y se refinaron a todo lo largo del
anlisis de los sistemas.

La factibilidad de la tecnologa y los mtodos escogidos y deseados. (Las tcnicas del anlisis de factibilidad
se estudiaron en el captulo 9.)
Dentro de las limitantes de estas restricciones pueden aplicarse las tcnicas resultantes.
> La arquitectura de red
El primer DFD fsico que debe dibujarse es el DFD de la arquitectura de red. Una arquitectura de red DFD es
un diagrama de flujo de datos fsicos que asigna procesadores (clientes y servidores) y dispositivos (por
ejemplo, las mquinas y los autmatas) a una red y establece: 1) la conectividad entre los clientes y los
servidores, y 2) dnde los usuarios interactuarn con los procesadores (generalmente slo los clientes).
Para identificar los procesadores y sus ubicaciones, el desarrollador utiliza dos recursos:
Si existe una arquitectura de tecnologa de la informacin de la empresa, esa arquitectura probablemente
especifica la visin del cliente/servidor que deber lograrse.
Deber solicitarse el consejo de gerentes de red competentes y/o especialistas para
determinar qu est en su lugar, qu es posible y qu impacto puede ejercer el sistema sobre la red de
computadoras.
La arquitectura de red DFD (vea la figura 11.11) necesita estar etiquetada para mostrar la informacin que es
diferente de los DFD normales. Estos no muestran flujos de datos

FIGURA 11.11 DFD de arquitectura de red

por s mismos. En lugar de eso, muestran carreteras sobre las cuales los flujos de datos pueden viajar en
ambas direcciones. Tambin, los DFD de topologa de red indican lo siguiente:
Los servidores y sus ubicaciones fsicas. Los servidores no siempre estn localizados en los sitios indicados
en un diagrama de conectividad de la ubicacin. El acceso del personal de la red a los servidores
generalmente est en discusin. Algunas tareas de administracin de red pueden lograrse remotamente y
algunas tareas requieren acceso directo.
Los clientes y sus ubicaciones fsicas. En este caso, el diagrama de conectividad de las ubicaciones es til
para identificar grupos de usuarios similares (por ejemplo, DEPENDIENTES QUE RECIBEN RDENES,
REPRESENTANTES DE VENTAS, etc.) quienes recibirn similares servicios de clientes. Un procesador
individual debera representar al grupo entero en una ubicacin individual. El mismo grupo puede replicarse
en ubicaciones mltiples. Por ejemplo, usted esperara que cada REGIN DE VENTAS tenga tipos similares
de empleados.
Las especificaciones del procesador. Las descripciones del repositorio de procesadores pueden usarse para
definir especificaciones del procesador como RAM, capacidad de disco duro y despliegue.
Los protocolos de transporte. Las conexiones estn etiquetadas con los protocolos de
transporte (por ejemplo, TCP/IP) y otros parmetros fsicos pertinentes.

La topologa de la red DFD puede usarse ya sea para disear una red de computadoras o documentar el diseo
de una red de computadoras existente. En uno u otro caso, la red est siendo modelada a fin de que despus le
podamos asignar los procesos de sistemas de informacin, los almacenamientos de datos y los flujos de datos
a los servidores en la red.
> Distribucin de datos y asignaciones de tecnologa
El siguiente paso es distribuir los almacenamientos de datos a los procesadores de la red.
Los almacenamientos de datos lgicos requeridos ya conocen del anlisis de sistemas:
como almacenamientos de datos en los DFD lgicos (captulo 8) o como entidades en los ERD lgicos
(captulo 7). Slo necesitamos determinar dnde se guardar fsicamente cada uno y cmo se implantarn.
Para distribuir los datos y asignar sus mtodos de implantacin, los desarrolladores utilizan tres recursos:

Si estn disponibles, las matrices de distribucin de datos del anlisis de sistemas (captulos 7 y 8) modelan
las necesidades de datos en las ubicaciones de negocios a partir de una perspectiva independiente de la
tecnologa.

Si existe una arquitectura de tecnologa de informacin empresarial, esa arquitectura tal vez especifica la
visin de la base de datos y las tecnologas que debern ser buscadas.

Deber solicitarse el consejo de administradores de datos y de bases de datos para determinar lo que est en
su lugar, lo que es posible y qu impacto puede tener la base de datos en el sistema global.

Las opciones de distribucin se describieron anteriormente en el captulo y se resumen como sigue:

Almacene todos los datos en un solo servidor. En este caso deber denominarse la base de datos (consistente
en tablas mltiples), y esa base de datos denominada y su mtodo de implantacin (por ejemplo, Oracle:
dbmemberServices), deber aadirse al DFD fsico y deber estar conectada al procesador apropiado.

Almacene tablas especficas en servidores diferentes. En este caso, y por claridad, deberemos registrar cada
tabla como un almacenamiento de datos en el DFD fsico y conectar cada uno al servidor correcto.

Almacene subconjuntos de tablas especficas en servidores diferentes. En este caso registramos las tablas tal
como antes, excepto que indicamos cules tablas son subconjuntos del conjunto total de registros. Por
ejemplo, la etiqueta DB2: TABLA DE RDENES (REG SUBSET) sealara que un subconjunto de todas las rdenes de
una regin se almacena en una tabla DB2 de bases de datos.

Reproduzca (duplique) las tablas especficas o los subconjuntos en servidores diferentes. En este caso, los
almacenamientos de datos replicados se muestran en el DFD
FIGURA 11.12 Distribucin de datos y asignaciones de tecnologa para SoundStage
fsico. Una copia de cualquier tabla replicada se designa como el MASTER y todas las dems copias se
designan como COPIA o REPLICADO.
Por qu distribuir el almacenamiento de datos? Hay muchas posibles razones. Primera, algunas instancias de
datos son slo de inters local. Segunda, el desempeo a menudo puede mejorarse situando subconjuntos de
datos en ubicaciones mltiples. Finalmente, es necesario localizar algunos datos para asignar custodia de esos
datos. La distribucin de datos y las asignaciones de tecnologa para el estudio de caso SoundStage
se muestran en la figura 11.12.
Las decisiones de distribucin de datos pueden ser muy complejas; por lo comn, las decisiones son guiadas
por profesionales de datos y de bases de datos y se ensean en los cursos y libros de texto de administracin
de datos. En este libro queremos considerar slo cmo documentar la particin y las decisiones de
duplicacin.
> Distribucin de procesos y asignaciones de tecnologa
Los procesos de sistemas de informacin ahora pueden asignarse a los procesadores como sigue:
Para los sistemas cliente/servidor de dos capas, todos los diagramas de eventos lgicos (captulo 5) se
asignan al cliente.
Para los sistemas cliente/servidor de tres capas y de red, usted debe examinar de cerca el diagrama original
de flujo de datos de cada evento (detallado). Usted necesita determinar cules de los procesos originales
debern asignarse al cliente y cules debern asignarse a un servidor de aplicacin. En general, la captura y
edicin de datos se asignan a los clientes mientras otra lgica del negocio se asigna a los servidores. Si usted
reparte los diferentes aspectos de un DFD lgico entre los distintos servidores y clientes, deber dibujar DFD
fsicos separados para las porciones en cada cliente y el servidor.

Despus de la particin, cada DFD fsico corresponde a una unidad de diseo para un evento de negocios
dado. (Los eventos de negocios, o los casos de uso, se discutieron en el captulo 6.) Para cada una de estas
unidades de diseo, usted debe asignar un mtodo de implantacin, el SDE que se usar para implantar ese
proceso. Usted tambin debe asignar los mtodos de implantacin a los flujos de datos.
FIGURA 11.13 Un DFD fsico para un evento
FIGURA 11.14 La frontera persona/mquina

El Sistema de servicios a los miembros de SoundStage ser implantado con una arquitectura de
cliente/servidor multicapas y de cmputo de redes. En la figura 11.13 se muestra un DFD de muestra para un
evento que debe asignarse a un cliente. Observe que se muestran los almacenamientos de datos aun cuando
sabemos que han sido repartidos a un servidor de la base de datos. Esto es para el beneficio de los
programadores que deben implantar el DFD.
> Los lmites entre persona/mquina
El ltimo paso del diseo de proceso es separar cualquier porcin de los DFD fsicos que representan
procesos manuales no computarizados. Algunas veces a esto se le llama establecer el lmite (frontera) entre
persona/mquina. Establecer una frontera de persona/mquina no es difcil, pero no es tan simple como usted
podra pensar en un inicio. La dificultad surge cuando la frontera persona/mquina atraviesa un proceso
lgico; en otras palabras, parte del proceso debe ser manual y parte del proceso debe ser computarizado.
Esta situacin es comn en los DFD lgicos porque se dibujan sin tomar en cuenta las alternativas de
implantacin.
La figura 11.14 aade la frontera persona/mquina a un DFD fsico. Observe que nuestra frontera atraviesa
varios procesos, incluyendo el proceso de VERIFICAR EL CRDITO DEL MIEMBRO. La solucin para este proceso
requiere dos pasos:

1. Las porciones del proceso manual se apartan como una unidad de diseo separada (vea la figura 11.15).
Todos estos procesos son completamente manuales. Las interfaces de las unidades de diseo manual con los
procesos computarizados (en la figura 11.14) se dibujan como agentes externos. Por ltimo, los procesos
manuales en la unidad de diseo deben describir claramente a las personas que tendrn que realizarlos.

2. Si es necesario, los procesos en el diagrama original debern ser renombrados para reflejar slo la porcin
computarizada. (En la prctica, los procesos fueron ya denominados de ese modo.)

FIGURA 11.15 Unidad de diseo manual