UNIVERSIDAD MEXIQUENSE DEL BICENTENARIO 

UNIDAD DE ESTUDIOS SUPERIORES 

TEMASCALCINGO

LIC. EN INFORMÁTICA ADMINISTRATIVA Y FINANCIERA

ASIGNATURA:
DISEÑO DE SISTEMAS DISTRIBUIDOS

EXPOSICIÓN:
CAPA DE INTERFAZ DE USUARIO
CAPA DE MANEJO DE DATOS
CAPA DE PROCESAMIENTO DE DATOS

ALUMNOS:
DULCE MARÍA ROCHA SEGUNDO
IRMA SANTOS SERRANO
KEVIN GARDUÑO MAYA
LUIS FERNANDO ORTEGA DE LA CRUZ
LUIS ALFONSO HUITRON GARCÍA

DOCENTE:
MANUEL DEL MAZO CARBAJAL

GRUPO: 26LF181

22 DE ABRIL DE 2022
 UNIDAD 2   ARQUITECTURA DE APLICACIONES
DISTRIBUIDAS.

¿Qué es una arquitectura?

Es un nivel de diseño que hace foco en aspectos más allá de los algoritmos y
estructuras de datos de la computación, el diseño y especificaciones de la
estructura global del sistema es un nuevo tipo de problema, la forma que se
considera para formar algo.

¿Qué es una aplicación distribuida?

Es una aplicación con distintos componentes que se ejecutan separados,
normalmente en diferentes plataformas conectadas.

¿A qué se refiere la distribución?

La distribución se refiere a la construcción de software por partes, a las cuales le
son asignadas un conjunto específico de responsabilidades dentro de un sistema.
Esta distribución como bien enunciaba la definición formal, habla de que las partes
o componentes se encuentran en entornos separados, sin embargo, lo que tiene
implícito esta definición, es que para realizar esta separación física primero debe
tenerse clara la separación lógica de las partes de una aplicación, esto quiere
decir que programáticamente existe una forma de separar o agrupar los
componentes.
La separación física no es en todas la ocasiones en “maquinas diferentes” de
acuerdo a la arquitectura también puede ser la ubicación de un conjunto de
funcionalidades en archivos, rutas o montadas sobre tecnologías diferentes dentro
de la misma máquina.
Cuando hablamos de distribución lógica lo entenderemos como separación por
“capas”   y cuando hablemos de distribución física usaremos el término separación
en “niveles”.
“las capas dentro de una arquitectura son un conjunto de servicios especializados
que pueden ser accesibles por múltiples clientes y que deben ser fácilmente
reutilizables”.
Una capa puede contener muchos componentes, un mismo componente puede
ubicarse en varias capas de acuerdo a su naturaleza y a las consideraciones
explicitas de la arquitectura.

¿Qué es una arquitectura en ambiente distribuido?

Describe la estructura y la organización de los componentes del software, sus
propiedades y la conexión entre ellos para formar el sistema; la cantidad y la
granularidad de comunicación que se necesita para la interacción y los protocolos
de interfaz usada por la comunicación.
En una aplicación distribuida en n-capas los diferentes elementos que integran la
aplicación se agrupan de forma lógica según la funcionalidad que reciben o
suministran al o desde el resto de los elementos. Así, algunos elementos se
limitarán a recibir peticiones de datos mientras que otros interactuarán con el
usuario y su función será principalmente la de solicitar a otros elementos la
información que el usuario precisa.
Una vez agrupada la funcionalidad en capas lógicas es fácil relacionar unas con
otras. El usuario interactuará con la capa de presentación, solicitando datos o
desencadenando acciones. Las solicitudes serán atendidas por la capa de
negocios, que se encargará de su gestión o de la traducción necesaria para que la
capa de servidor realice la tarea solicitada. La capa de servidor debe proporcionar
datos los cuales se devolverán a la capa de negocios, la cual los gestionará o
transmitirá a la capa de presentación.
Esquema lógico de las capas en una aplicación distribuida
Es importante notar que el esquema que mostramos es un esquema lógico, no
físico. El modo de distribuir físicamente las capas (en diferentes ejecutables o
DLL, o en diferentes equipos) se corresponderá con el esquema lógico en todo o
en parte, pero no necesariamente existirá una correspondencia exacta entre la
distribución lógica de los elementos y su distribución física. La capa de negocios
podría residir en diferentes máquinas, por ejemplo, o las entidades de negocio y la
capa de servidor podrían formar parte de la misma DLL. 

2.1 CAPA DE INTERFAZ DE USUARIO

La capa de presentación o interfaz de usuario se refiere al mecanismo de

interacción del usuario con el sistema.
Es la que ve el usuario (también se la denomina "capa de usuario"), presenta el
sistema al usuario, le comunica la información y captura la información del usuario
en un mínimo de proceso (realiza un filtrado previo para comprobar que no hay
errores de formato). También es conocida como interfaz gráfica y debe tener la
característica de ser "amigable" (entendible y fácil de usar) para el usuario. Esta
capa se comunica únicamente con la capa de negocio.

Los tipos de interfaces de software más comunes son las aplicaciones de

ventanas y web. Los tipos de interfaces de hardware más comunes son el ratón, el
teclado, el micrófono, pantallas táctiles, dispositivos de imagen y audio.
Está formada por los formularios y los controles que se encuentran en los
formularios, capa con la que interactúan el usuario   y es responsable de obtener
datos de la capa siguiente, mostrarlos, validar entradas de datos, enviarlas a la
siguiente capa donde pueden dividirse en: presentación, código de interfaz de
usuario.
La capa de presentación o interface de usuario la constituye el software con el que
el usuario interactúa para operar con la aplicación. Es probablemente la parte más
trabajosa de la misma, ya que es muy frecuente que aplicaciones cuyas reglas de
negocio sean relativamente sencillas tengan en cambio un interfaz de usuario
complejo y vistoso que le proporcione al usuario una experiencia de manejo fácil y
agradable. Además, mientras que en la creación de reglas de negocio
normalmente sólo interviene un tipo de programación, preferentemente basada en
lenguajes, en la preparación del interfaz de usuario suelen mezclarse varias
disciplinas, como el diseño o la usabilidad.
Un error frecuente en la creación de los interfaces de usuario consiste en olvidar
que las reglas de negocio no se hallan en el interfaz, sino en los objetos
subyacentes que residen en las capas inferiores de la solución. La capa de
presentación no es más que un sistema de presentación y manejo de datos que se
obtienen y se actualizan con los objetos de negocio comunes para todas las
aplicaciones que los usan. Si se olvida este aspecto se puede caer en la tentación
de colocar reglas de negocio en el interfaz de usuario, imposibilitando la
reutilización de las mismas y complicando la distribución y despliegue de la
aplicación. Por lo tanto, una regla de oro a observar en toda aplicación distribuida
es que la capa de presentación ha de ser completamente independiente de las
reglas de negocio, y su función se limitará a la presentación y manejo de los datos
de la aplicación, que obtendrá mediante el uso de los objetos de la capa de
negocios comentados en la sección anterior.
Esto convierte a la capa de presentación en una mera fachada de los procesos
que son gestionados por la capa de negocios. Las capas de presentación suelen
ser “delgadas”, es decir, contienen pocas líneas de código, ya que su función
principal está cubierta por las características de los elementos “visuales” que las
componen. Una tendencia creciente es la separación entre diseño y código, ya
existente, por ejemplo, en las aplicaciones web dinámicas. 

2.2 CAPA DE MANEJO DE DATOS

La capa de negocios o de manejo de datos, es donde residen los programas que

se ejecutan, se reciben las peticiones del usuario y se envían las respuestas tras
el proceso. Se denomina también capa de negocio (e incluso de lógica del
negocio) porque es aquí donde se establecen todas las reglas que deben
cumplirse.
Esta capa se comunica con la capa de presentación, para recibir las solicitudes y
presentar los resultados, y con la capa de datos, para solicitar al gestor de base de
datos almacenar o recuperar datos de él. También se consideran aquí los
programas de aplicación.
División de la capa de manejo de datos
La capa de negocios representa el grueso de la lógica de funcionamiento de la
aplicación distribuida. En esta capa se sitúan las normas de acceso a datos, la
lógica de tratamiento de los mismos, y en general cualquier elemento de la
aplicación que pueda reutilizarse. El objetivo de la creación de esta capa
“intermedia” es aislar la capa de presentación de la capa de servidor, de forma que
las estructuras de datos subyacentes y la lógica que las utilizan sean
independientes de la capa de presentación. De esta forma, también, el
mantenimiento de las normas de negocio será más sencillo y, sobre todo, será
reutilizable desde cualquier capa de presentación, sea del tipo que sea.
A pesar de que se suele utilizar el nombre de capa de negocios para referenciar a
todos los elementos que componen esta capa intermedia de software, por lo
general la capa de negocios suele dividirse en dos tipos de elementos, atendiendo
a la función que desempeñan en la capa.
  * Lógica de negocios
Cuando las aplicaciones adquieren cierto volumen o las entidades implicadas
tienen cierta complejidad, la lógica de acceso a datos por sí sola no es suficiente
para encapsular convenientemente el acceso a las entidades de datos. En estos
casos será necesario añadir objetos más complejos que a su vez encapsulen los
objetos de acceso a datos y los expongan de forma más sencilla a las capas
superiores, facilitando su manejo.
Además, en las aplicaciones
distribuidas con cierto tamaño es frecuente encontrar reglas de negocio que no
tienen nada que ver con el acceso a datos, sino que constituyen mecanismos
aparte que de una forma o de otra es deseable extraer de la capa de presentación
para su reutilización o para que su mantenimiento sea sencillo.
Estas necesidades implican a menudo la creación de una capa adicional de lógica
que llamaremos lógica de negocios. Los elementos de la lógica de negocios ya no
se conectan a los orígenes de datos ni representan a las entidades de datos
subyacentes, sino que utilizan los objetos de acceso a datos y las entidades de
negocio, siendo pues una especie de “cliente” de la lógica de acceso a datos.
  * Lógica de acceso a datos
La lógica de acceso a datos incluye los elementos necesarios para que la
aplicación se conecte a orígenes de datos y recupere estructuras de datos que
serán utilizadas por el resto de la aplicación. En una aplicación distribuida, los
únicos elementos que se conectan a la base de datos son los objetos de acceso a
datos, y el resto de elementos de la aplicación se limitan a enlazar con estos
objetos para solicitar datos y enviar órdenes a los orígenes de datos.
Los motivos para encapsular todo el acceso a datos en la lógica de acceso a datos
son múltiples. En primer lugar, no será necesario distribuir la información de
conexión por todo el sistema, ya que el único punto desde el que se efectuará el
acceso directo a los orígenes de datos será el equipo en el que resida físicamente
la lógica de acceso a datos. Tampoco será necesario distribuir el software cliente
del
SGBD por diferentes máquinas, lo que facilita el mantenimiento y la instalación de
la aplicación.
Además, encapsular la lógica de acceso a datos permite que la aplicación sea
agnóstica respecto al origen de datos, es decir, puede realizar sus tareas sin tener
la necesidad de saber en qué SGBD concreto residen los datos, ni en qué punto
de la red se halla el servidor, lo que facilita la configuración del sistema. Este
sistema posibilita la utilización de varios SGBD en una aplicación o facilita la
migración de un SGBD a otro. También permite que la aplicación ignore la
estructura real de los orígenes de datos, ya que es la propia lógica de acceso a
datos la que expondrá las estructuras con las que trabajará la aplicación,
acomodándolas a las necesidades de la misma.
Otro factor importante es la reutilización. La separación de esta lógica permite
reutilizar los componentes de acceso a datos en diversas aplicaciones sin
necesidad de copiar el código y manteniendo la coherencia en el comportamiento
del acceso a datos en todas ellas.
A pesar de que otros elementos, como los que componen la lógica de negocios,
son opcionales, los elementos de lógica de acceso a datos deben estar presentes
en toda arquitectura distribuida que se diseñe, debido a las ventajas que aportan

2.3 CAPA DE PROCESAMIENTO DE DATOS

Es donde residen los datos y es la encargada de acceder a los mismos. Está

formada por uno o más gestores de bases de datos que realizan todo el
almacenamiento de datos, reciben solicitudes de almacenamiento o recuperación
de información desde la capa de negocio.

El acceso a datos se refiere al medio a través del cual podemos acceder y

manipular los datos persistentes de un sistema.
El almacenamiento de datos se refiere a la forma en que se encuentran guardados
dichos datos, por ejemplo, en archivos o bases de datos.
  * Servicios
En esta capa encontraremos los procesos de la aplicación que se encargan recibir
las peticiones de las capas superiores y, si es necesario, devolver los datos
solicitados. Esta función será desempeñada por un servicio.
Los servicios son procesos que se ejecutan en los equipos servidores y que se
mantienen a la escucha esperando que los procesos cliente les soliciten
funcionalidad o datos. Por lo general los servicios residen en equipos dedicados
cuya configuración y características físicas están especialmente diseñadas para
realizar esta función.
  * Servicios de base de datos
Los servicios de base de datos son los más frecuentes en las aplicaciones
distribuidas. Los SGBD como SQL Server u Oracle disponen de toda la
infraestructura de servicios necesarios para que los equipos cliente les realicen
peticiones y para responder a ellas. Se ejecutan como un servicio de forma
totalmente desatendida, se enlazan al protocolo de red para escuchar peticiones
de otros equipos, gestionan la concurrencia de las llamadas e incorporan
mecanismos de seguridad propios o integrables con el directorio activo.
Una de las características más importantes de los SGBD es que nos permiten
crear reglas de negocio. Estas reglas pueden invocarse remotamente desde los
clientes y se escriben en lenguajes propios del SGBD (Transact-SQL en el caso
de SQL Server, por ejemplo). Los SGBD compilan y ejecutan de la forma más
óptima posible estas reglas, de modo que su ejecución siempre es de alto
rendimiento
Casi todas las aplicaciones y servicios necesitan almacenar y obtener acceso a un
determinado tipo de datos. Por ejemplo, una aplicación comercial necesitaría
almacenar datos de productos, clientes y pedidos.
Al trabajar con datos debe determinar:
  * El almacén de datos que utiliza.
  * El diseño de los componentes utilizados para obtener acceso al almacén de
datos.
  * El formato de los datos pasados entre componentes y el modelo de
programación necesario para ello
La aplicación o servicio puede disponer de uno o varios orígenes de datos, los
cuales pueden ser de tipos diferentes. La lógica utilizada para obtener acceso a
los datos de un origen de datos se encapsulará en componentes lógicos de
acceso a datos que proporcionan los métodos necesarios para la consulta y
actualización de datos. Los datos con los que la lógica de la aplicación debe
trabajar están relacionados con entidades del mundo empresarial que forman
parte de la empresa. En determinados escenarios, puede disponer de
componentes personalizados que representan estas entidades, mientras que en
otros puede decidir trabajar con datos utilizando directamente conjuntos de datos
ADO.NET o documentos XML.
La mayoría de las aplicaciones utilizan una base de datos relacional como
almacén principal de los datos de la aplicación. También se puede utilizar el
almacén de Web Microsoft Exchange Server, bases de datos heredadas, el
sistema de archivos o servicios de administración de documentos.
Cuando la aplicación recupera datos de la base de datos, puede hacerlo utilizando
un formato de conjunto de datos DataReader. A continuación los datos se
transfieren entre las capas y los distintos niveles de la aplicación y, finalmente, uno
de los componentes los utilizará. Tal vez desee utilizar formatos de datos
diferentes para recuperar, pasar y utilizar datos; por ejemplo, puede utilizar los
datos de un conjunto de datos para llenar las propiedades de un objeto de entidad
personalizado. No obstante, debería intentar mantener una coherencia en cuanto
al tipo de formato utilizado, ya que mejorará probablemente el rendimiento y la
facilidad de mantenimiento de la aplicación para presentar sólo un conjunto
limitado de formatos, evitando así la necesidad de capas de traducción adicionales
y de familiarizarse con API diferentes.
En las siguientes secciones se describe la elección de almacenes de datos, el
diseño de los componentes lógicos de acceso a datos y las distintas posibilidades
disponibles de representación de datos.
Almacenes de datos
Entre los tipos de almacenes habituales se encuentran:
  * Bases de datos relacionales. Las bases de datos relacionales, como las bases
de datos SQL Server, proporcionan funcionalidad de administración de un gran
volumen de datos transaccionales de alto rendimiento con capacidades de
seguridad, operaciones y transformación de datos. Las bases de datos
relacionales también alojan instrucciones y funciones complejas de lógica de datos
en forma de almacenamientos almacenados que se pueden utilizar como un
entorno eficaz para los procesos empresariales con un gran volumen de datos.

  * Bases de datos de mensajería. Puede almacenar datos en el almacén Web de

Exchange Server, lo que resulta especialmente útil si la aplicación está centrada
en el grupo, el trabajo en grupo o mensajes y no desea basarse en otros
almacenes de datos que pueden necesitar que se administren de forma
independiente. Sin embargo, los almacenes de datos de mensajes suelen
presentar menores capacidades de rendimiento, escalabilidad, disponibilidad y
administración que los sistemas de administración de bases de datos relacionales
completas (RDBMS) y, por tanto, es relativamente no habitual que las aplicaciones
que utilicen el almacén de datos proporcionado por un producto de mensajería.

  * Sistema de archivos. Puede decidir almacenar los datos en sus propios

archivos en el sistema de archivos. Estos archivos pueden presentar su propio
formato o el formato XML con un esquema definido para los propósitos de la
aplicación.
Hay un gran número de otros almacenes (como bases de datos XML, servicios de
procesamiento analítico en línea y bases de datos de almacenamiento de datos,
entre otros) pero no son el objeto de análisis de esta guía.
  * Componentes lógicos de acceso a datos
Independientemente del almacén de datos utilizado, la aplicación o el servicio
utilizarán componentes lógicos de acceso a datos para obtener acceso a los
datos. Estos componentes abstraen la semántica del almacén de datos
subyacente y la tecnología de acceso a datos (como ADO.NET) y proporcionan
una interfaz simple de programación para la recuperación y realización de
operaciones con datos.
Los componentes lógicos de acceso a datos suelen implementar un patrón de
diseño sin estado que separa el procesamiento empresarial de la lógica de acceso
a datos. Cada uno de estos componentes suele proporcionar métodos para
realizar operaciones Create, Read, Update y Delete (CRUD) relacionadas con una
entidad empresarial determinada de la aplicación (por ejemplo, Order). Los
procesos empresariales pueden utilizar estos métodos. La interfaz de usuario
pueden utilizar las consultas específicas para procesar los datos de referencia
(como una lista de tipos de tarjetas de crédito válidos).
Cuando la aplicación contiene varios componentes lógicos de acceso a datos,
puede resultar útil utilizar un componente de ayuda de acceso a datos genéricos
para administrar las conexiones de las bases de datos, ejecutar comandos y
almacenar parámetros en caché, entre otros. Los componentes lógicos de acceso
a datos proporcionan la lógica necesaria para obtener acceso a datos
empresariales específicos, mientras que el componente de ayuda para el acceso a
datos centraliza el desarrollo de API de acceso a datos y la configuración de la
conexión a éstos, permitiendo de esta forma la reducción de código duplicado. Un
componente de ayuda de acceso a datos bien diseñado no debe repercutir
negativamente en el rendimiento y proporciona una ubicación central para el
ajuste y optimización del acceso a datos. Microsoft proporciona Data Access
Application Block para .NET, que se puede utilizar como un componente de ayuda
de acceso a datos genéricos en la aplicación al utilizar bases de datos SQL
Server.

  1. Los componentes lógicos de acceso a datos exponen métodos para insertar,

eliminar, actualizar y recuperar datos, incluyendo la provisión de funcionalidad de
paginación al recuperar grandes cantidades de datos.
  2. Puede utilizar un componente de ayuda de acceso a datos para centralizar la
administración de la conexión y todo el código relacionado con un origen de datos
específico.
  3. Se recomienda implementar las consultas y operaciones de datos como
procedimientos almacenados (si es compatible con el origen de datos) para
mejorar el rendimiento y la facilidad de mantenimiento.

  * Agentes de servicios.
Cuando un componente empresarial requiere el uso de la funcionalidad
proporcionada por un servicio externo, tal vez sea necesario hacer uso de código
para administrar la semántica de la comunicación con dicho servicio. Por ejemplo,
los componentes empresariales de la aplicación comercial descrita anteriormente
podrían utilizar un agente de servicios para administrar la comunicación con el
servicio de autorización de tarjetas de crédito y utilizar un segundo agente de
servicios para controlar las conversaciones con el servicio de mensajería. Los
agentes de servicios permiten aislar las idiosincrasias de las llamadas a varios
servicios desde la aplicación y pueden proporcionar servicios adicionales, como la
asignación básica del formato de los datos que expone el servicio al formato que
requiere la aplicación.
FUENTES DE INFORMACIÓN:

 http://arquitecturaaplicacionesdistribuidas.blogspot.com/
 http://arquitecturaaplicacionesdistribuidas.blogspot.com/2013/02/21-capa-
de-interfaz-de-usuario_22.html
 http://arquitecturaaplicacionesdistribuidas.blogspot.com/2013/02/22-capa-
de-manejo-de-datos_22.html
 http://arquitecturaaplicacionesdistribuidas.blogspot.com/2013/02/23-capa-
de-procesamiento-de-datos_22.html
 https://virtual.itca.edu.sv/Mediadores/stis/
35___diseo_de_la_interfaz_de_usuario.html
 http://arquitecturaaplicacionesdistribuidas.blogspot.com/2013/02/unidad-2-
arquitectura-de-aplicaciones_22.html