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

.