3.5 Diseño de software de Cliente – Servidor
Esta arquitectura consiste
básicamente en un cliente que realiza peticiones a otro programa (el servidor)
que le da respuesta. Aunque esta idea se puede aplicar a programas que se
ejecutan sobre una sola computadora es más ventajosa en un sistema operativo
multiusuario distribuido a través de una red de computadoras.
En esta arquitectura la
capacidad de proceso está repartida entre los clientes y los servidores, aunque
son más importantes las ventajas de tipo organizativo debidas a la
centralización de la gestión de la información y la separación de
responsabilidades, lo que facilita y clarifica el diseño del sistema.
Este modelo es un prototipo de sistemas distribuidos que
muestra como los datos y el procesamiento se distribuye a lo largo de varios
procesadores. Es una forma de dividir las responsabilidades de un sistema de
información separando la interfaz del usuario de la gestión de la información.
El funcionamiento básico de este modelo consiste en que un programa cliente
realiza peticiones a un programa servidor, y espera hasta que el servidor de
respuesta. Características de un cliente En la arquitectura C/S el remitente de
una solicitud es conocido como cliente. Sus características son: • Es quien
inicia solicitudes o peticiones, tienen por tanto un papel activo en la
comunicación (dispositivo maestro o amo). • Espera y recibe las respuestas del
servidor. • Por lo general, puede conectase a varios servidores a la vez. •
Normalmente interactúa directamente con los usuarios finales mediante una
interfaz gráfica de usuario.
Características de un servidor En los sistemas C/S el
receptor de la solicitud enviada por cliente se conoce como servidor. Sus
características son: • Al iniciarse esperan a que lleguen las solicitudes de
los clientes, desempeñan entonces un papel pasivo en la comunicación
(dispositivo esclavo). • Tras la recepción de una solicitud, la procesan y luego
envían la respuesta al cliente. • Por lo general, aceptan conexiones desde un
gran número de clientes (en ciertos casos el número máximo de peticiones puede
estar limitado). • No es frecuente que interactúen directamente con los
usuarios finales.
Ventajas • Centralización del
control: Los accesos, recursos y la integridad de los datos son controlados por
el servidor de forma que un programa cliente defectuoso o no autorizado no
pueda dañar el sistema. • Escalabilidad: Se puede aumentar la capacidad de clientes
y servidores por separado. • Fácil mantenimiento
Desventajas • La
congestión del tráfico (a mayor número de clientes, más problemas para el
servidor). • El software y el hardware de un servidor son generalmente muy
determinantes. Un hardware regular de un ordenador personal puede no poder
servir a cierta cantidad de clientes. Normalmente se necesita software y
hardware específico, sobre todo en el lado del servidor, para satisfacer el
trabajo. Por supuesto, esto aumentará el costo
Características
- · En la arquitectura C/S el remitente de una solicitud es conocido como cliente. Sus características son:
- · Es quien inicia solicitudes o peticiones, tienen por tanto un papel activo en la comunicación (dispositivo maestro o amo).
- · Espera y recibe las respuestas del servidor. Por lo general, puede conectarse a varios servidores a la vez.
Normalmente interactúa
directamente con los usuarios finales mediante una interfaz gráfica de usuario.
- · Al receptor de la solicitud enviada por cliente se conoce como servidor. Sus características son:
- · Al iniciarse esperan a que lleguen las solicitudes de los clientes, desempeñan entonces un papel pasivo en la comunicación (dispositivo esclavo).
- · Tras la recepción de una solicitud, la procesan y luego envían la respuesta al cliente.
- · Por lo general, aceptan conexiones desde un gran número de clientes (en ciertos casos el número máximo de peticiones puede estar limitado).
- · No es frecuente que interactúen directamente con los usuarios finales.
3.6 Diseño de software de arquitectura
distribuida
Un sistema
distribuido se define como una colección de computadores autónomos conectados
por una red, y con el software distribuido adecuado para que el sistema sea
visto por los usuarios como una única entidad capaz de proporcionar facilidades
de computación.
Los sistemas
distribuidos se implementan en diversas plataformas hardware, desde unas pocas
estaciones de trabajo conectadas por una red de área local, hasta Internet, una
colección de redes de área local y de área extensa interconectados, que en
lazan millones de ordenadores.
Las
aplicaciones de los sistemas distribuidos varían desde la provisión de
capacidad de cómputo a grupos de usuarios, hasta sistemas bancarios,
comunicaciones multimedia y abarcan prácticamente todas las aplicaciones
comerciales y técnicas de los ordenadores. Los requisitos de dichas
aplicaciones incluyen un alto nivel de fiabilidad, seguridad contra
interferencias externas y privacidad de la información que el sistema mantiene.
Un sistema distribuido es un
sistema de información en el cual las funciones se reparten por áreas de
trabajo diferentes que trabajan de forma coordinada para asumir los objetivos
que la organización asigna a ese sistema de información.
Elementos de un sistema
Distribuido
En él se integran.
La plataforma de
proceso. Una vez diseñado el sistema, es el elemento encargado de
proporcionar los recursos físicos y el software de base para ejecutarlo.
Esta formado por los Mainframe, PC’s, PDA’s, teléfonos, etc… Los
elementos de la conectividad. Son los encargados se proporcionar el
transporte para comunicar e integrar los elementos de la plataforma de
proceso. Son básicamente las redes y las comunicaciones. El
almacenamiento de datos, formado por los datos en si y los gestores donde se
localizan. Los elementos de software donde se incluyen las aplicaciones, los
servicios que ayudan a crearlas y las interfícies que ayudan a usarlas.
En este componente se integran las
arquitecturas posibles para crearlas: centralizada, Batch, transaccional,
cliente / servidor basado en sistema operativo, cliente / servidor basada
en Internet y aplicaciones Web Internet. A lo largo de
la exposición pondremos especial cuidado en presentar las características
y posibilidades las tres últimas. Sistemas de seguridad.
Finalmente, debe realizarse la gestión del sistema como un conjunto
integrado y coordinado a través de los recursos de dirección y
administración. La gestión del sistema debe permitir la coexistencia de
varios centros de gestión diferentes. Parte fundamental del sistema de
gestión es el cuadro de mandos. Hay dos cuadros de mandos
diferentes: El cuadro de mandos de seguimiento de los objetivos de
negocio pensado para proporcionar información automática a los gestores
de como la realidad se mueve respecto a las previsiones de los objetivos
de negocio en “tiempo real”. El cuadro de mandos de explotación
desde donde se centraliza y coordina toda la administración, supervisión y
explotación del sistema.
Características
- · Compartición de Recursos
- · Apertura (opennesss)
- · Concurrencia
- · Escalabilidad
- · Tolerancia a Fallos
- · Transparencia
3.7 Diseño de software de arquitectura de
tiempo real arquitectura
El software
de tiempo real está muy acoplado con el mundo externo, esto es, el software de
tiempo real debe responder al ámbito del problema en un tiempo dictado por el
ámbito del problema. Debido a que el software de tiempo real debe operar bajo
restricciones de rendimiento muy rigurosas, el diseño del software esta
conducido frecuentemente, tanto por la arquitectura del hardware como por la
del software, por las características del sistema operativo, por los requisitos
de la aplicación y tanto por los extras del lenguaje de programación como
prospectos de diseño.
Los sistemas
de tiempo real generan alguna acción en respuesta a sucesos externos. Para
realizar esta función, ejecutan una adquisición y control de datos a alta
velocidad bajo varias ligaduras de tiempo y fiabilidad. Debido a que estas
ligaduras son muy rigurosas, los sistemas de tiempo real están frecuentemente
dedicados a una única aplicación.
Globalmente,
un sistema de tiempo real enfrenta al ingeniero de sistemas con difíciles
decisiones sobre el software. Una vez que el elemento software ha sido
asignado, se establecen los requisitos detallados del software y debe
desarrollarse un diseño fundamental de software.
Entre los
muchos aspectos relativos al diseño de tiempo real están: la coordinación entre
las tareas de tiempo real, el procesamiento de interrupciones del sistema, el
manejo de E/S para asegurar que no se pierden datos, la especificación de las
ligaduras de tiempo externas e internas del sistema y el asegurar la precisión
de su base de datos.
Cada diseño
de tiempo real relativo al software debe ser aplicado en el contexto del
rendimiento de sistema. En la mayoría de los casos, el rendimiento de un
sistema de tiempo real se mide con una o más características relativas al
tiempo, pero también se utilizan otras medidas, tales como la tolerancia al
fallo. Algunos sistemas de tiempo real se han diseñado para aplicaciones en las
que solo el tiempo de repuesta o la trasferencia de datos es crítica.
Las computadoras se utilizan
para controlar una amplia variedad de sistemas desde maquinas domesticas
sencillas hasta plantas enteras de fabricación. Estas computadoras interactúan
directamente con dispositivos hardware. El software de dichos sistemas es
software de tiempo real embebido que debe reaccionar a eventos generados por el
hardware y emitir señales de control como respuesta a estos eventos. Está
embebido en sistemas hardware maquina y debe responder, en tiempo real, a
eventos del entorno del sistema.
Los sistemas de tiempo real
embebidos son diferentes de otros tipos de sistemas de software. Su correcto
funcionamiento depende de que el sistema responda a los eventos dentro de un
corto intervalo de tiempo. Se puede definir un sistema de tiempo real como
sigue:
Un sistema de tiempo real es
un sistema software cuyo correcto funcionamiento depende de los resultados
producidos por el mismo y del instante del tiempo en el que se producen estos
resultados. Un sistema de tiempo real blando (soft) es un sistema cuyo
funcionamiento se degrada si los resultados no se producen de acuerdo con los
requerimientos temporales especificados. Un sistema de tiempo real duro (hard)
es un sistema cuyo funcionamiento es incorrecto si los resultados no se
producen de acuerdo con la especificación temporal.
Una respuesta a tiempo es un
factor importante en todos los sistemas embebidos, pero en algunos casos, no
necesita una respuesta rápida. Por ejemplo, el sistema de bombeo de insulina es
un sistema embebido. Sin embargo, aunque se necesita comprobar el nivel de
glucosa a intervalos periódicos no es necesario responder muy rápidamente a los
eventos externos.
Una forma de ver un sistema
de tiempo real es como un sistema de estimulo/respuesta. Dando un determinado
estimulo de entrada, el sistema debe producir la correspondiente salida. Se
puede, por lo tanto, definir el comportamiento de un sistema de tiempo real
haciendo una lista de los estímulos recibidos por el sistema, las respuestas
asociadas y el tiempo en que dichas respuestas deben producirse.
Los estímulos pueden
pertenecer a dos clases:
Estímulos periódicos.
Ocurren a intervalos de tiempo predecibles. Por ejemplo, si el sistema debe
examinar un sensor cada 50 milisegundos y realizar una acción (respuesta)
dependiendo del valor de ese sensor (estímulo).
Estímulos aperiódicos. Ocurren de forma regular. Normalmente son provocados
utilizando el mecanismo de interrupciones de la computadora. Un ejemplo de
dicho estímulo podría ser una interrupción para indicar que una transferencia
de E/S se ha completado y que los datos están disponibles en el búfer.
Los estímulos periódicos en
un sistema de tiempo real son generados normalmente por sensores asociados al
sistema. Estos proporcionan información sobre el estado del entorno del
sistema. Las respuestas son dirigidas a un conjunto de actuadores que controlan
algún equipo como una bomba, que influye en el entorno del sistema.
Los
estímulos aperiódicos pueden generarse por actuadores o por sensores. A menudo
indican alguna condición excepcional como un fallo en el hardware, que debe ser
manejado por el sistema. Este modelo sensor-sistema actuador de un sistema de
tiempo real embebido se ilustra en la figura 2.2.
Un sistema de tiempo real
tiene que responder a estímulos que ocurren en diferentes instantes de tiempo.
Por lo tanto, se tiene que organizar su arquitectura para que, tan pronto como
se reciba un estímulo, el control sea transferido al manejador adecuado. Esto
no es práctico en programas secuenciales. Por consiguiente, los sistemas de
tiempo real se diseñan como un conjunto de procesos concurrentes que cooperan
entre sí. Con el objetivo de soportar la gestión de estos procesos, la
plataforma de ejecución para la mayoría de los sistemas de tiempo real incluye
un sistema operativo de tiempo real. Las facilidades que proporciona este
sistema operativo son accedidas a través del sistema de soporten tiempo
de ejecución (run-time system) para el lenguaje de programación de tiempo real
utilizado.
La generalidad de este
modelo estímulo-respuesta de un sistema de tiempo real conduce a un modelo
arquitectónico genérico abstracto en el que hay tres tipos de procesos.
Para cada tipo de sensor, hay un proceso de gestión del sensor; los procesos computacionales
calculan la respuesta requerida para el estimulo recibido por el sistema; los
procesos de control de actuadores controlan el funcionamiento del actuador.
Este modelo permite recoger rápidamente los datos desde el sensor (antes de que
la siguiente entrada esté disponible) y permite que su procesamiento y la
respuesta asociada al actuador se realicen más tarde.
La arquitectura genérica
puede instanciarse a varias arquitecturas de aplicaciones diferentes que
amplían el conjunto de arquitecturas. Las arquitecturas de aplicaciones
de tiempo real son instancias de la arquitectura conducida por eventos en la
cual el estimulo, directa o indirectamente. Provoca la generación de eventos.
Los lenguajes de
programación desarrollados para sistemas de tiempo real tienen que incluir
facilidades para acceder al hardware del sistema, y debería ser posible
predecir la duración de operaciones particulares realizadas en estos
leguajes.los sistemas de tiempo real duros todavía se programan algunas veces
en ensamblador para que puedan cumplirse los estrechos plazos de tiempo
(deadline). Los lenguajes a nivel de sistemas como C, que permiten generar
código eficiente también se utilizan en general.
La ventaja de utilizar un
lenguaje de programación de sistemas de bajo nivel como C es que permite el
desarrollo de programas muy eficientes. Sin embargo, estos lenguajes no
incluyen construcciones para soportar la concurrencia o la gestión de recursos
compartidos. Estas se implementan atreves de llamadas al sistema operativo de tiempo
real que no pueden ser comprobados por el compilador, de forma que los errores
de programación son más probables. Los programas son también más a menudo más
difícil de comprender debido a que las características de tiempo real no
están explicitas en el programa.
