arquitecturas de software
TRANSCRIPT
INGENIERIA EN SISTEMAS COMPUTACIONALES
INGENIERIA DE SOFTWARE
UNIDAD III
TEMA: ARQUITECTURA DE SOFTWARE(cliente-servidor, sistemas distribuidos, multiprocesador, tiempo real) Y
ARQUITECTURA DE HARDWARE
ISC GIL SANTANA ESPARZA, MCA
S501
08-11-2016
INTEGRANTES DEL EQUIPO:
HERNANDEZ MEDINA JOSUE
SOSA MEJIA ANEL VERONICA
VIZCAINO NUÑEZ JOSE ALFONSO
Fecha de entrega: 14/11/2016
INTRODUCCION
En la siguiente investigación se hablará acerca de las arquitecturas de software,
Las comunicaciones entre computadoras se rigen básicamente por arquitecturas
de software como lo son la arquitectura cliente-servidor, la arquitectura
multiprocesador, la arquitectura en tiempo real, y la arquitectura de objetos
distribuidos.
Un sistema distribuido es un sistema en el que el procesamiento de información se
distribuye sobre varias computadoras en vez de estar confinado en una única
maquina.
El objetivo de esta investigación es estudiar los modelos de arquitectura de
software para sistemas distribuidos.
lo que se plasmara en el siguiente trabajo es la forma de Conocer las arquitecturas
que son importantes y utilizadas en el ámbito de enviar y recibir información,
primero comenzamos con la arquitectura cliente-servidor su funcionamiento es
sencillo: se tiene una máquina cliente, que requiere un servicio de una máquina
servidor, y éste realiza la función para la que está programado (nótese que no
tienen que tratarse de máquinas diferentes; es decir, una computadora por sí sola
puede ser ambos cliente y servidor dependiendo del software de configuración).
Enseguida tenemos la arquitectura de objetos distribuidos en este caso no hay
distinción en tres servidores y clientes, y el sistema puede ser visto como un
conjunto de objetos que interaccionan cuya localización es irrelevante. No hay
distinción entre un proveedor de servicios y el usuario de estos servicios.
También se incluirá la arquitectura multiprocesador el modelo más simple de un
sistema distribuido ya que el sistema de software esta domado por varios
procesos que pueden o no ejecutarse sobre procesadores diferentes, estos
sistemas recogen información, toman decisiones usando esa información y envían
señales a los actuadores que modifican el entorno del sistema, otra de las
arquitecturas de esta investigación es la 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. A lo largo de este documento se detallaran los temas expuestos
anteriormente.
ARQUITECTURA DE SOFTWARELa arquitectura del software de un programa o sistema de cómputo es la
estructura o estructuras del sistema, lo que comprende a los componentes del
software, sus propiedades externas visibles y las relaciones entre ellos.
La arquitectura no es el software operativo. Es una representación que permite:
1) Analizar la efectividad del diseño para cumplir los requerimientos
establecidos,
2) Considerar alternativas arquitectónicas en una etapa en la que hacer
cambios al diseño todavía es relativamente fácil
3) Reducir los riesgos asociados con la construcción del software.
Esta definición pone el énfasis en el papel de los componentes del software en
cualquier representación arquitectónica. En el contexto del diseño de la
arquitectura, un componente del software puede ser algo tan simple como un
módulo de programa o una clase orientada a objeto, pero también puede
ampliarse para que incluya bases de datos y “middleware” que permitan la
configuración de una red de clientes y servidores. Las propiedades de los
componentes son aquellas características necesarias para entender cómo
interactúan unos componentes con otros. En el nivel arquitectónico, no se
especifican las propiedades internas. Las relaciones entre los componentes
pueden ser tan simples como una invocación de procedimiento de un módulo a
otro o tan complejos como un protocolo de acceso a una base de datos.
La arquitectura de software es de especial importancia ya que la manera en que
se estructura un sistema tiene un impacto directo sobre la capacidad de este para
satisfacer lo que se conoce como los atributos de calidad del sistema. Ejemplos de
atributos de calidad son el desempeño, que tiene que ver con el tiempo de
respuesta del sistema a las peticiones que se le hacen, la usabilidad, que tiene
que ver con qué tan sencillo les resulta a los usuarios realizar operaciones con el
sistema, o bien la modificabilidad, que tiene que ver con qué tan simple resulta
introducir cambios en el sistema.
Una arquitectura de software se selecciona y diseña con base en objetivos
(requerimientos) y restricciones. Los objetivos son aquellos prefijados para el
sistema de información, pero no solamente los de tipo funcional, también otros
objetivos como la mantenibilidad, auditabilidad, flexibilidad e interacción con otros
sistemas de información. Las restricciones son aquellas limitaciones derivadas de
las tecnologías disponibles para implementar sistemas de información. Unas
arquitecturas son más recomendables de implementar con ciertas tecnologías
mientras que otras tecnologías no son aptas para determinadas arquitecturas. Por
ejemplo, no es viable emplear una arquitectura de software de tres capas para
implementar sistemas en tiempo real.
Generalmente, no es necesario inventar una nueva arquitectura de software para
cada sistema de información. Lo habitual es adoptar una arquitectura conocida en
función de sus ventajas e inconvenientes para cada caso en concreto. Así, las
arquitecturas más universales son:
Cliente-Servidor
Sistemas distribuidos
Multiprocesador
Tiempo real
MODELO CLIENTE-SERVIDOR
El modelo arquitectónico cliente servidor es un modelo de sistema en el que dicho
sistema se organiza como un conjunto de servicios y servidores asociados, más
unos clientes que accede y usan los servicios. Los principales componentes de
este modelo son:
1.- Un conjunto de servidores que ofrecen servicios a otros subsistemas. Ejemplos
son servidores de impresoras que ofrecen servicios de impresión.
2.- Un conjunto de clientes que llaman a los servicios ofrecidos por los servidores.
Estos normalmente son subsistemas en sí mismos, Puede haber varias instancias
de un programa cliente ejecutándose concurrentemente.
3.- Una red que permite a los clientes acceder a estos servicios. Esto no es
estrictamente necesario ya que los clientes y los servidores podrían ejecutarse
sobre una única máquina. En la práctica, Sin embargo, la mayoría de los sistemas
cliente-servidor se implementan como sistemas distribuidos.
Los clientes pueden conocer los nombres de los servidores disponibles y los
servicios que estos proporcionan, Sin embargo los servidores no necesitan
conoces la identidad de los clientes o cuantos clientes tienen. Los clientes
acceden a los servicios proporcionados por un servidor a través de llamadas a
procedimientos remotos usando un protocolo de petición –respuesta tal como el
protocolo http usado en la www.
Básicamente un cliente realza una petición a un servidor y espera hasta que
recibe una respuesta.
figura1. La arquitectura de un sistema de biblioteca de películas y fotografías
En el sistema de la figura 1 varios servidores gestionan y visualizan diferentes
tipos de dispositivos. Las secuencias de video necesitan ser trasmitidas
rápidamente y en sincronía pero con una resolución relativamente baja. Etas
pueden comprimirse en un almacén para que el servidor de video pueda gestionar
la compresión y descompresión de video en diferentes formatos. Sin embargo, las
fotografías deben mantenerse con una alta resolución, por lo que es adecuado
mantenerlas en un servidor separado.
La ventaja más importante del modelo cliente-servidor es que es una arquitectura
distribuida. Se puede hacer uso efectivo de los sistemas en red con muchos
procesadores distribuidos. Es fácil añadir un nuevo servidor e integrarlo con el
resto del sistema o actualizar los servidores de forma transparente sin afectar al
resto del sistema.
En una arquitectura cliente-servidor, una aplicación se modela como un conjunto
se servicio proporcionados por los servidores y un conjunto de clientes que usan
esos servicio (orfali y harckey.1998).
Los clientes necesitan conocer que servidores están disponibles, pero
normalmente no conocen la existencia de otros clientes. Clientes y servidores son
procesos, diferentes, como se muestra en la figura 3, que representa un modelo
lógico de una arquitectura distribuida cliente-servidor.
figura3. Computadoras en una red cliente-servidor
Varios procesos servidores pueden ejecutarse sobre un único procesador; por lo
tanto, no hay necesariamente una correspondencia entre procesos y procesadores
en el sistema. Cuando hacemos referencia a clientes y servidores, nos referimos a
los procesos lógicos en vez de a las computadoras físicas sobre las que se
ejecutan.
figura2. Un sistema cliente-servidor
El diseño de sistemas cliente-servidor debería reflejar la estructura lógica de la
aplicación que se está desarrollando. Una forma de ver una aplicación se ilustra
en la figura 4, que muestra una aplicación estructurada en tres capas. La capa de
presentación está relacionada con la presentación de la información al usuario y
con toda la interacción con él.
Fig.4.- Capas de las aplicaciones
La capa de procesamiento del procesamiento de la aplicación está relacionada
con la implementación de la lógica de la aplicación, y la capa de gestión de datos
está relacionada con todas las operaciones sobre la base de datos. En los
sistemas centralizados, estas capa s no es necesario que estén claramente
separadas. Sin embargo, cuando se está diseñando un sistema distribuido debería
hacerse una clara distinción entre ellas, de forma que sea posible cada distribuir
cada capa sobre una computadora existente.
La arquitectura cliente servidor más simple se denomina arquitectura cliente
servidor en dos capas, en la que una ampliación se organiza como un servidor(o
múltiples servidores idénticos) y un conjunto de clientes. Como se muestra en la
figura 5, las arquitecturas cliente servidor de dos capas pueden ser de dos tipos:
fig.5 Clientes ligeros y ricos
Modelo cliente ligero: Es un modelo cliente ligero, todo el procesamiento de las
aplicaciones y la gestión de los datos se lleva a cabro en el servidor. El cliente
simplemente es responsable de la capa de presentación del software.
Modelo de cliente rico: En este modelo, el servidor solamente es responsable de
la gestión de los datos. El software del cliente implementa la lógica de la aplicación
y las interacciones con el usuario del sistema.
Una gran desventaja del modelo de cliente ligero es que ubica una elevada carga
de procesamiento en el servidor como en la red. El servidor es responsable de
todos los cálculos, y esto puede implicar la generación de un tráfico significativo en
la red entre el cliente y el servidor. Los dispositivos de computación modernos
disponen de una gran cantidad de potencia de procesamiento, la cual es bastante
poco usada en la aproximación de cliente ligero.
El modelo de cliente rico hace uso de esta potencia de procesamiento disponible
y distribuye tanto el procesamiento de la lógica de la aplicación como la
presentación al cliente. El servidor es esencialmente un servidor de transacciones
que gestiona todas las transacciones de la base de datos. Un ejemplo de este tipo
de arquitectura es la de los sistemas bancarios ATM, en donde cada ATM es un
cliente y el servicio es un mainframe que procesa la cuenta del cliente de datos. El
hardware de los cajeros automáticos realiza una gran cantidad de procesamiento
relacionado con el cliente y asociado a la transacción.
Sistema distribuido ATM figura 6.
Aun que el modelo de cliente rico no distribuye el procesamiento de forma más
efectiva que un modelo cliente ligero, la gestión del sistema es más compleja. La
funcionalidad de la aplicación se expande entre varias computadoras. Como la
aplicación software tiene que ser modificada, esto implica la reinstalación en cada
cliente. Esto puede significar un coste importante si hay cientos de clientes en el
sistema.
El problema con una aproximación cliente-servidor de dos capas es que las tres
capas lógicas –presentación, procesamiento de la aplicación y gestión de los
datos- deben asociarse con dos computadoras al cliente u el servidor. Aquí puede
haber problemas con la escalabilidad y rendimiento si se elige el modelo de cliente
ligero, o problemas con la gestión del sistema si se usa el modelo de cliente rico.
Para evitar estos problemas, una aproximación alternativa es usar una
arquitectura cliente.-servidor de tres capas. (fig.7)
fig.7 Arquitectura cliente-servidor en tres capas
En esta arquitectura, la presentación, el procesamiento de la aplicación y la
gestión de los datos son procesos lógicamente separados que se ejecutan sobre
los procesadores diferentes.
Un sistema bancario por Internet (fig.8) es un ejemplo de una arquitectura cliente
servidor de tres capas. La base de datos de clientes del banco (usualmente
ubicada sobre una computadora mainframe) proporciona servicios de gestión de
datos; un servidor web proporciona los servicios de aplicación tales como
facilidades para transferir el efectivo, generar estados de cuenta, pagar facturas, y
así sucesivamente; y la propia computadora del usuario con un navegador de
internet es el cliente. El sistema es escalable debido a que es relativamente fácil
añadir nuevos servidores web a medida que el número de clientes crece.
Fig. La arquitectura de distribución de un sistema bancario en internet
El uso de una arquitectura de tres capas en este caso permite optimizar la
transferencia de información entre el servidor web y el servidor de base de datos.
Las comunicaciones entre estos sistemas pueden usar protocolos de
comunicación de bajo nivel muy rápidos.
Para manejar la recuperación de información de la base de datos se utiliza un
middleware eficiente que soporte consultas a la base de datos en SQL.
ARQUITECTURA MULTIPROCESADOR
La arquitectura de software de un sistema de programa o computación es la
estructura de las estructuras del sistema, la cual comprende los componentes del
software, las propiedades de esos componentes visibles externamente, y las
relaciones entre ellos. Actualmente los productos de software han marcado una
gran diferencia ya que existen muchos productos que son similares sin embargo
la calidad no es tan efectiva. En el presente trabajo se desarrollara lo que es el
diseño y arquitectura de productos de software.
Por otra parte se destacaran sus características principales para el desarrollo de
un nuevo software como la descomposición modular así como el diseño de
software de arquitectura de multiprocesador que se encuentra dentro de las
arquitecturas de dominio específico.
La ventaja de un sistema multiproceso reside en la operación llamada cambio de
contexto. Esta operación consiste en quitar a un proceso de la CPU, ejecutar otro
proceso y volver a colocar el primero sin que se entere de nada. Los hilos que se
ejecutan comparten ciertos recursos como el espacio del mensaje, la cual
permite simplificar el diseño de una aplicación que debe llevar a cabo distintas
funciones simultáneamente.
El modelo más simple de un sistema distribuido es un sistema multiprocesador en
el que el sistema de software está formado por varios procesos que pueden o no
necesariamente ejecutarse sobre procesadores diferentes. Este modelo es común
en sistemas grandes de tiempo real.
Estos sistemas recogen información toman decisiones usando esta información y
envían señales a los actuadores que modifican el entorno del sistema.
Lógicamente, los procesos relacionados con la recopilación de información, toma
de decisiones y control de actuadores podrían ejecutarse todos ellos sobre un
único procesador bajo el control de un planificador (scheduler) que decide que
procesos se asignan a cada procesador.
Un ejemplo de este tipo de sistemas se muestra en la figura 1. Este es un modelo
simplificado de sistema de control de tráfico. Un conjunto de sensores distribuidos
recogen información sobre el flujo de tráfico y la procesan localmente antes de
enviarla a una sala de control. Los operadores toman decisiones usando esta
información y dan instrucciones a un proceso de control de diversas luces de
tráfico. En este ejemplo, hay varios procesos lógicos para gestionar los sensores,
la sala de control y los semáforos. Estos procesos lógicos pueden ser procesos
individuales o un grupo de procesos. En este ejemplo, se ejecutan sobre
procesadores diferentes.
Figura 1. Sistema multiprocesador de control de trafico.
Los sistemas software compuestos de multiples procesos no son necesariamente
sistemas distribuidos. Si se dispone de más de un procesador, entonces se puede
implementar la distribución, pero los diseñad0res del sistema no siempre
consideran forzosamente cuestiones de distribución durante el proceso del diseño.
La aproximación del diseño para este tipo de sistemas es esencialmente la misma
para sistemas en tiempo real.
ARQUITECTURA DE OBJETOS DISTRIBUIDOS
En el modelo cliente-servidor de un sistema distribuido, los clientes y los
servidores son diferentes. Los clientes reciben servicios de los servidores y no de
otros clientes; los servidores pueden actuar como clientes recibiendo de otros
servidores, pero sin solicitar servicios de clientes; los clientes deben conocer como
contactar con cada uno de estos servidores.
Este modelo funciona bien para muchos tipos de aplicaciones. Sin embargo, limita
la flexibilidad de los diseñadores del sistema ya que ellos deben decidir donde se
proporciona cada servicio. También deben planificar escalabilidad y proporcionar
algún medio para distribuir la carga sobre los servidores cuando mas clientes se
añadan al sistema.
Una aproximación más general al diseño de sistemas distribuidos es eliminar la
distinción entre cliente y servidor y diseñar la arquitectura del sistema como una
arquitectura del sistema como una arquitectura de objetos distribuidos. En una
arquitectura de objetos distribuidos (fig.o1), los componentes fundamentales del
sistema son objetos que proporcionan una interfaz a un conjunto de servicios que
ellos suministran. Otros objetos realizan llamadas a estos servicios sin hacer
ninguna distinción lógica entre un cliente (el receptor de un servicio) y un servidor (
el proveedor de un servicio).
Los objetos pueden distribuirse a través de varias computadoras en una red y
comunicarse a través de middleware. A este middleware s elo denomina
intermediario de peticiones de objetos. Su misión es proporcionar una interfaz
transparente entre los objetos. Proporciona un conjunto de servicios que permiten
la comunicación entre los objetos y que estos sean añadidos y eliminados del
sistema.
Las ventajas del modelo distribuidos son:
Permite al diseñador del sistema retrasar decisiones sobre donde y como
deberían propocionarse los servicios. Los objetos que proporcionan
servicios pueden ejecutarse sobre cualquier nodo de la red . Por lo tanto , la
distinción entre los modelos de cliente rico y ligero es irrelevante, ya que no
hay necesidad de decidir con antelación donde se situa la lógica de
aplicación de los objetos.
Es una arquitectura de sistema muy abierta que permite añadir nuevos
recursos si es necesario. Como se indica en la siguiente sección, se han
desarrollado e implementado estándares de comunicación de objetos que
permiten escribir objetos en diferentes lenguajes de programación para
comunicarse y proporcionar servicios entre ellos.
El sistema es flexible y escalable. Se pueden crear diferentes instancias del
sistema proporcionando los mismos servicios por objetos diferentes o por
objetos reproducidos para hacer frente a las diferentes cargas del sistema.
Puede añadirse nuevos objetos a medida que la carga del sistema se
incrementa sin afectar el resto de los objetos del sistema.
Si es necesario, es posible reconfigurar el sistema de forma dinámica
mediante la migración de objetos a través de la red. Esto puede ser
importante donde haya fluctuación en los patrones de demanda de
servicios. Un objeto que proporciona servicios puede migrar al mismo
procesador que los objetos que demandan los servicios, en lo que mejora el
rendimiento del sistema
Una arquitectura de objetos distribuidos puede ser usada como un modelo lógico
que permita estructurar y organizar el sistema. En este caso se debe pensar en
cómo proporcionar funcionalidades de la aplicación únicamente en términos de
servicios y combinaciones de servicios. A continuación se debe identificar como
proporcionar estos servicios utilizando varios objetos distribuidos. En este nivel ,
los objetos que se diseñan son normalmente de grano grueso que proporcionan
servicios específicos del dominio. Por ejemplo en una aplicación de venta al por
menos, puede haber objetos de negocio relacionados con el control de
existencias, comunicaciones con el cliente , pedidos de productos y otros. Por
supuesto, este modelo lógico puede llevarse a cabro como un modelo de
implementación.
De forma alternativa, se puede usar una aproximación de objetos distribuidos para
implementar sistemas cliente-servidor, pero tanto los clientes como los servidores
se implementan como objetos distribuidos que se comunican a través de un bus
de software. Esto hace posible realizar cambios en el sistema de forma sencilla,
por ejemplo, desde un sistema de dos capas a un sistema multicapa. En este
caso, el servidor o el cliente puede no implementarse como un único objeto
distribuido si no que puede estar compuesto por objetos mas pequeños que
proporcionan servicios especializados.
Un ejemplo de un tipo de sistema en el que una arquitectura de objetos
distribuidos podría ser adecuada es un sistema de minería de datos que busca
relaciones entre los datos almacenados en varias bases de datos (figura o2). Un
ejemplo de aplicación de minería de datos podría ser un negocio de venta al por
menos que tuviese , por ejemplo , tiendas de comestibles y tiendas de ferretería, y
quisiera encontrar las relaciones entre compras de diversos tipos de comestibles y
de ferretería. Por ejemplo , la gente que quiera comprar comida para bebe también
puede comprar un tipo concreto de papel para las paredes . Con este
conocimiento, la empresa podría entonces ofrecer ofertas especificas a los
clientes de comida para bebe combinables con otras.
En este ejemplo cada base de datos puede encapsularse como un objeto
distribuido con una interfaz que proporciona acceso de solo lectura a sus datos.
Los objetos integradores se ocupan cada uno de ellos de tipos específicos de
relaciones, y recogen información desde todas las bases de datos para intentar
deducir dichas relaciones. Podría haber un objeto integrador que se ocupara de
las variaciones de ventas de comestibles de temporada y otro que se ocupara de
las relaciones entre los diferentes tipos de comestibles.
Los objetos visualizadores interaccionar con los objetos integradores para producir
una visualización o un informe de las relaciones descubiertas. Debido a que se
manejan grandes volúmenes de datos, los objetos visualizadores usaran
normalmente representaciones graficas de las relaciones que hayan descubierto.
Una arquitectura de objetos distribuidos es adecuada para este tipo de aplicación
en lugar de una aplicación cliente-servidor por tres razones:
1.- A diferencia de un sistema bancario ATM(por ejemplo), el modelo lógico del
sistema no es el de provisión de servicios en el que se pueden distinguir servicios
de gestión de datos.
2.- Se pueden añadir bases de datos al sistema sin mayor problema. Cada base
de datos es simplemente otro objeto distribuido. Los objetos de bases de datos
pueden proporcionar una interfaz simplificada que controle el acceso a los datos.
Las bases de datos a las que se puede acceder pueden residir en diferentes
maquinas.
3.-Permite explorar nuevos tipos de relaciones añadiendo nuevos objetos
integradores. Las partes del negocio que estén interesadas en relaciones
especificas pueden extender el sistema añadiendo objetos integradores que
operen sobre sus computadoras sin requerir conocimiento de ningún otro
integrador que se use en cualquier otra parte del sistema.
La principal desventaja de las arquitecturas de objetos distribuidos es que son
mucho más complejas de diseñar que los sistemas cliente-servidor. Los sistemas
cliente-servidor parecen ser la forma más natural de concebir a los sistemas.
Estos reflejan muchas transacciones humanas en las que la gente solicita y recibe
servicios de otra gente especializada en proporcionar dichos servicios. Es más
difícil pensar en una provisión de servicios generales, y todavía no tenemos una
gran experiencia en el diseño y desarrollo de objetos de negocio de grano grueso.
ARQUITECTURA DE TIEMPO REALLa arquitectura de software de tiempo real está muy acoplada 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 conexiones de tiempo y fiabilidad. Debido a que estas
conexiones son muy rigurosas, los sistemas de tiempo real están frecuentemente
dedicados a una única aplicación.
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.
Una forma de ver un sistema de tiempo real es como un sistema de
estímulo/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). 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.
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
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.
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.
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 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 estímulo, directa o indirectamente. Provoca la generación de
eventos.
ARQUITECTURA DE HARDWARELa arquitectura de hardware es el diseño conceptual y la estructura operacional
fundamental de un sistema de computadora, es decir, son todas las partes
tangibles de toda computadora. Un computador desde la perspectiva del
hardware, está constituido por una serie de dispositivos cada uno con un conjunto
de tareas definidas. Los dispositivos de un computador se dividen según la tarea
que realizan en: dispositivos de entrada, salida, comunicaciones, almacenamiento
y cómputo.
CONCLUSIONPara concluir con esta investigación cabe destacar que hasta este punto se
conocen las ventajas y desventajas de las arquitecturas de software, cada
arquitectura tiene sus características especiales para lo que es recomendable
escoger una que se adapte a su sistema informático, los modelos principales de
arquitecturas de sistemas distribuidos son la arquitectura cliente-servidor Este
Modelo consiste básicamente en un cliente que realiza peticiones a otro programa
que le da respuesta. El servidor es un proveedor de servicios, El cliente es
un consumidor de servicios. Cliente y Servidor Interactúan por un mecanismo de
pasaje de mensajes: Pedido de servicio y Respuesta y sistemas de objetos
distribuidos este sistema puede ser visto como un conjunto de objetos que
interaccionan cuya localización es irrelevante. Aunque también existen la
arquitectura multiprocesador el sistema de software esta domado por varios
procesos que pueden o no ejecutarse sobre procesadores diferentes, estos
sistemas recogen información, toman decisiones usando esa información y envían
señales a los actuadores que modifican el entorno del sistema y tiempo real 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, es conveniente saber cada característica
ventaja y desventaja de cada arquitectura para poder así tomar una buena
decisión a la hora de implementar la arquitectura elegida.
REFERENCIAS Sommerville, Ian. Ingenieria del software. Pearson Educacion, S.A. España
.