Arquitecturas
de software
En
los inicios de la informática, la programación se
consideraba un arte y se desarrollaba como tal, debido a la dificultad que entrañaba para la mayoría de las personas, pero
con el tiempo se han ido descubriendo y desarrollando formas y guías generales,
con base a las cuales se puedan resolver los problemas. A estas, se les ha
denominado Arquitectura de Software, porque, a semejanza de los planos de un
edificio o construcción, estas indican la estructura, funcionamiento e
interacción entre las partes del software.
En
el libro "An introduction to Software Architecture", David Garlan y
Mary Shaw definen que la 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 especificación de la estructura global del sistema es
un nuevo tipo de problema".
Componentes e interacciones
Componentes
La arquitectura de software se compone por:
- clientes y servidores.
- bases de datos.
- filtos.
- niveles en sistemas jerárquico.
Interacciones
Entre los componentes de la arquitectura de software existe un conjunto de interacciones entre las que sobresalen :
- llamadas a procedimientos.
- comportamiento de variables.
- protocolos cliente servidor.
- transmición asíncrona de eventos.
3.1
Descomposición modular
Descomposición modular
Capacidad de empleo de componentes modulares.
Si un método de diseño permite ensamblar los componentes de diseño (reusables)
existentes en un sistema nuevo, producirá una solución modular que no inventa
nada ya inventado.
Capacidad de comprensión modular. Si un módulo se puede comprender como una unidad autónoma (sin referencias a otros módulos) será más fácil de construir y de cambiar.
Continuidad modular. Si pequeños cambios en los requisitos del sistema provocan cambios en los módulos individuales, en vez de cambios generalizados en el sistema, se minimizará el impacto de los efectos secundarios de los cambios.
Protección modular. Si dentro de un módulo se produce una condición aberrante y sus efectos se limitan a ese módulo, se minimizará el impacto de los efectos secundarios inducidos por los errores.
Finalmente, es importante destacar que un sistema se puede diseñar modularmente, incluso aunque su implementación deba ser «monolítica». Existen situaciones (por ejemplo, software en tiempo real, software empotrado) en donde no es admisible que los subprogramas introduzcan sobrecargas de memoria y de velocidad por mínimos que sean (por ejemplo, subrutinas, procedimientos). En tales situaciones el software podrá y deberá diseñarse con modularidad como filosofía predominante.
El código se puede desarrollar «en línea». Aunque el código fuente del programa puede no tener un aspecto modular a primera vista, se ha mantenido la filosofía y el programa proporcionará los beneficios de un sistema modular.
Capacidad de comprensión modular. Si un módulo se puede comprender como una unidad autónoma (sin referencias a otros módulos) será más fácil de construir y de cambiar.
Continuidad modular. Si pequeños cambios en los requisitos del sistema provocan cambios en los módulos individuales, en vez de cambios generalizados en el sistema, se minimizará el impacto de los efectos secundarios de los cambios.
Protección modular. Si dentro de un módulo se produce una condición aberrante y sus efectos se limitan a ese módulo, se minimizará el impacto de los efectos secundarios inducidos por los errores.
Finalmente, es importante destacar que un sistema se puede diseñar modularmente, incluso aunque su implementación deba ser «monolítica». Existen situaciones (por ejemplo, software en tiempo real, software empotrado) en donde no es admisible que los subprogramas introduzcan sobrecargas de memoria y de velocidad por mínimos que sean (por ejemplo, subrutinas, procedimientos). En tales situaciones el software podrá y deberá diseñarse con modularidad como filosofía predominante.
El código se puede desarrollar «en línea». Aunque el código fuente del programa puede no tener un aspecto modular a primera vista, se ha mantenido la filosofía y el programa proporcionará los beneficios de un sistema modular.
El diseño modular propone dividir el sistema
en partes diferenciadas y definir sus interfaces. sus ventajas: claridad,
reducción de costos y reutilización.
Los pasos a seguir son:
1. Identificar los módulos
2. Describir cada módulo
3. Describir las relaciones entre módulos
Una descomposición modular debe poseer ciertas cualidades mínimas para que se pueda considerar suficiente validad.
1. Independencia funcional
2. Acoplamiento
3. Cohesión
4. Comprensibilidad
5. Adaptabilidad
Los pasos a seguir son:
1. Identificar los módulos
2. Describir cada módulo
3. Describir las relaciones entre módulos
Una descomposición modular debe poseer ciertas cualidades mínimas para que se pueda considerar suficiente validad.
1. Independencia funcional
2. Acoplamiento
3. Cohesión
4. Comprensibilidad
5. Adaptabilidad
El diseño modular es una metodología
de desarrollo de programas complejos, que utiliza la filosofía TOP-DOWN,
conocida también como diseño descendente o refinamiento por pasos sucesivos; o
comúnmente conocido por los programadores como “Divide y Vencerás”; puesto que
enfrenta un problema desde lo abstracto (TOP) hacia lo particular (DOWN).
Esta técnica consiste en dividir el problema en un conjunto de subproblemas, y estos a su vez en otros de mayor facilidad de trabajo; generando los Módulos Funcionales.
La descomposición modular contribuye a las características deseables para la programación estructurada; y que permite resolver cada módulo de forma independiente y, si no se sabe resolver alguno de ellos, puede asignársele un nombre y pasar al desarrollo de otro módulo y, más adelante retomar el módulo incompleto para darle solución al obtener mayor conocimiento sobre dicho proceso, es decir, la solución del problema no se detiene por falta de conocimiento de algún proceso en particular.
Esta técnica consiste en dividir el problema en un conjunto de subproblemas, y estos a su vez en otros de mayor facilidad de trabajo; generando los Módulos Funcionales.
La descomposición modular contribuye a las características deseables para la programación estructurada; y que permite resolver cada módulo de forma independiente y, si no se sabe resolver alguno de ellos, puede asignársele un nombre y pasar al desarrollo de otro módulo y, más adelante retomar el módulo incompleto para darle solución al obtener mayor conocimiento sobre dicho proceso, es decir, la solución del problema no se detiene por falta de conocimiento de algún proceso en particular.
3.2 Patrones de Diseño
“Los patrones de diseño
son el esqueleto de las soluciones a problemas comunes en el desarrollo de
software.”
En otras palabras,
brindan una solución ya probada y documentada a problemas de desarrollo de
software que están sujetos a contextos similares. Debemos tener presente los
siguientes elementos de un patrón: su nombre, el problema (cuando aplicar un
patrón), la solución (descripción abstracta del problema) y las consecuencias
(costos y beneficios).
Grande fue mi sorpresa
al averiguar que existen varios patrones de diseño popularmente conocidos, los
cuales se clasifican como se muestra a continuación:
·
Patrones Creacionales: Inicialización y configuración de
objetos.
·
Patrones Estructurales: Separan la interfaz de la
implementación. Se ocupan de cómo las clases y objetos se agrupan, para formar
estructuras más grandes.
·
Patrones de Comportamiento: Más que describir objetos o clases,
describen la comunicación entre ellos.
Objetivos de
los patrones
Los patrones de diseño
pretenden:
- Proporcionar catálogos de elementos reusables en el diseño de
sistemas software.
- Evitar la reiteración en la búsqueda de soluciones a problemas ya
conocidos y solucionados anteriormente.
- Formalizar un vocabulario común entre diseñadores.
- Estandarizar el modo en que se realiza el diseño.
- Facilitar el aprendizaje de las nuevas generaciones de diseñadores
condensando conocimiento ya existente.
Asimismo, no pretenden:
- Imponer ciertas alternativas de diseño frente a otras.
- Eliminar la creatividad inherente al proceso de diseño.
No es obligatorio utilizar los
patrones, solo es aconsejable en el caso de tener el mismo problema o similar
que soluciona el patrón, siempre teniendo en cuenta que en un caso particular
puede no ser aplicable. "Abusar o forzar el uso de los patrones puede ser
un error".
Categorías
de patrones
Según la escala o nivel de
abstracción:
- Patrones
de arquitectura: Aquellos que expresan
un esquema organizativo estructural fundamental para sistemas de software.
- Patrones de diseño: Aquellos que expresan
esquemas para definir estructuras de diseño (o sus relaciones) con las que
construir sistemas de software.
- Dialectos: Patrones de bajo nivel
específicos para un lenguaje de programación o entorno concreto.
Además, también es importante
reseñar el concepto de "antipatrón de
diseño", que con forma semejante a la de un patrón, intenta
prevenir contra errores comunes de diseño en el software. La idea de los
antipatrones es dar a conocer los problemas que acarrean ciertos diseños muy
frecuentes, para intentar evitar que diferentes sistemas acaben una y otra vez
en el mismo callejón sin salida por haber cometido los mismos errores.
Además de los patrones ya
vistos actualmente existen otros patrones como el siguiente:
- Interacción: Son patrones que nos
permiten el diseño de interfaces web.
Estructuras
o plantillas de patrones
Para describir un patrón se
usan plantillas más o menos estandarizadas, de forma que se expresen
uniformemente y puedan constituir efectivamente un medio de comunicación
uniforme entre diseñadores. Varios autores eminentes en esta área han propuesto
plantillas ligeramente distintas, si bien la mayoría definen los mismos
conceptos básicos.
La plantilla más común es la
utilizada precisamente por el GoF y consta de
los siguientes apartados:
- Nombre del patrón: nombre estándar del
patrón por el cual será reconocido en la comunidad (normalmente se
expresan en inglés).
- Clasificación del patrón: creacional, estructural
o de comportamiento.
- Intención: ¿Qué problema pretende
resolver el patrón?
- También conocido como: Otros nombres de uso
común para el patrón.
- Motivación: Escenario de ejemplo
para la aplicación del patrón.
- Aplicabilidad: Usos comunes y
criterios de aplicabilidad del patrón.
- Estructura: Diagramas de clases
oportunos para describir las clases que intervienen en el patrón.
- Participantes: Enumeración y
descripción de las entidades abstractas (y sus roles) que participan en el
patrón.
- Colaboraciones: Explicación de las
interrelaciones que se dan entre los participantes.
- Consecuencias: Consecuencias positivas
y negativas en el diseño derivadas de la aplicación del patrón.
- Implementación: Técnicas o comentarios
oportunos de cara a la implementación del patrón.
- Código de ejemplo: Código fuente ejemplo
de implementación del patrón.
- Usos conocidos: Ejemplos de sistemas
reales que usan el patrón.
- Patrones relacionados: Referencias cruzadas
con otros patrones.
3.3 Arquitectura de dominio
específico
El reto para el diseño es
diseñar el software y hardware para proporcionar características deseables a
los sistemas distribuidos y, al mismo tiempo, minimizar los problemas propios a
estos sistemas. Es necesario comprender las ventajas y desventajas de las
diferentes arquitecturas de sistemas distribuidos. Aquí se tratan dos tipos
genéricos de arquitecturas de sistemas distribuidos: Arquitectura
cliente-servidor.
En este caso el sistema
puede ser visto como un conjunto de servicios que se proporcionan a los
clientes que hacen uso de dichos servicios. Los servidores y los clientes se
tratan de forma diferente en estos sistemas.
Arquitecturas de objetos distribuidos. Para esta arquitectura no hay distinción entre 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. Ambas arquitecturas se usan ampliamente en la industria, pero la distribución de las aplicaciones generalmente tiene lugar dentro de una única organización.
Arquitecturas de objetos distribuidos. Para esta arquitectura no hay distinción entre 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. Ambas arquitecturas se usan ampliamente en la industria, pero la distribución de las aplicaciones generalmente tiene lugar dentro de una única organización.
La distribución soportada
es, por lo tanto, intraorganizacional. También se pueden tomar dos tipos más de
arquitecturas distribuidas que son más adecuadas para la distribución interorganizacional:
arquitectura de sistemas peer-to-peer (p2p) y arquitecturas orientadas a
servicios. Los sistemas peer-to-peer han sido usados principalmente para
sistemas personales, pero están comenzando a usarse para aplicaciones de
empresa.
Son modelos de arquitectura los cuales son específicos para algún dominio de aplicación.
Dos tipos de modelos de dominio específico son:
Modelos Genéricos. Estos son abstracciones de un número de sistemas reales y que encapsulan las características principales de estos sistemas.
Modelos de Referencia. Estos son más abstractos, son modelos idealistas. Proporcionan un significado de información con respecto a sistemas de clases y comparación de diversas arquitecturas.
MODELOS GENÉRICOS (1)
Un modelo de Compilador es un ejemplo conocido a través de otros modelos que existen en dominios de aplicaciones especializadas:
• Analizador Léxico
• Tabla de Símbolos
• Analizador de Sintáxis
• Analizador Semántico
• Generador/Optimizador de Código
• Un modelo de compilador genérico puede ser organizado de acuerdo a diversos modelos de arquitectura.
ARQUITECTURAS DE REFERENCIA
Los modelos de referencias son derivados del estudio del dominio de una aplicación, en lugar del estudio de sistemas existentes.
Pueden ser utilizados como una base para… la implementación de un sistema o para comparar sistemas diversos.
Actúan como un estándar, contra el cual los sistemas que pueden ser evaluados.
El modelo OSI es un modelo en capas para sistemas de comunicación, y además, es un modelo de referencia.
La arquitectura de software es la responsable de la derivación de un modelo de sistema estructural, un modelo de control y un modelo de descomposición en subsistemas.
Los sistemas grandes rara vez conforman un modelo simple de arquitectura.
Los modelos de estructuración de un sistema incluyen modelos repositorios, los modelos cliente-servidor y los modelos de máquina abstracta.
Los modelos de control incluyen control centralizado y modelos manejadores de eventos.Los modelos de descomposición modular incluyen los modelos orientados aobjetos y los modelos de flujo de datos.
3.4 Diseño de software de
arquitectura multiprocesador
Un sistema multiproceso o
multitarea es aquel que permite ejecutar varios procesos de forma concurrente,
la razon es porque actualmente la mayoria de las cpu´s solo pueden ejecutar un
proceso cada vez. La unica forma de que se ejecuten de forma simultanea varios
procesos es tener varias cpu´s ya sea en una maquina o en varias en un sistema
distribuido.
La ventaja de un sistema multiproceso recide en la operacion llamada cambio de contexto y consiste en quitar a un proceso de la cpu, ejecutar otro proceso y volver a colocar el primero sin que se entere de nada.
El multiproceso no es dificil de entender : mas procesadores significa mas potencia computacional.
Un conjunto de tareas puede ser completado mas rapidamente si hay varias unidades de proceso ejecutandolas en paralelo.
VENTAJAS
La ventaja de un sistema multiproceso recide en la operacion llamada cambio de contexto y consiste en quitar a un proceso de la cpu, ejecutar otro proceso y volver a colocar el primero sin que se entere de nada.
El multiproceso no es dificil de entender : mas procesadores significa mas potencia computacional.
Un conjunto de tareas puede ser completado mas rapidamente si hay varias unidades de proceso ejecutandolas en paralelo.
VENTAJAS
Es economica
Las computadoras paralelas son inherentes escalables permitiendo
actualizarlas para adecuarse a la necesidad
DESVENTAJAS
Puede ser limitante fisica, existen factores que limitan la velocidad maxima de un procesador independiente del factor economico
Las barreras fisicas infranqueables tales como la velocidad de la luz, efectos de tamaño, la capacidad.
3.5 Diseño de software de
arquitectura cliente-servidor
El modelo arquitectónico
cliente-servidor es un modelo de sistema en el que dicho sistema organiza como
un conjunto de servicios y servidores
asociados, más unos clientes que acceden y usan los servicios.
El modelo arquitectónico cliente-servidor es un modelo de
sistema en el que dicho sistema organiza como un conjunto de servicios y servidores asociados, más unos clientes
que acceden y usan los servicios.
a arquitectura
cliente-servidor es un modelo de aplicación distribuida en el que las
tareas se reparten entre los proveedores de recursos o servicios,
llamados servidores, y los demandantes,
llamados clientes. Un cliente realiza peticiones a
otro programa, el servidor, quien le da respuesta. Esta
idea también se puede aplicar a programas que se ejecutan sobre una sola
computadora, aunque 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.
La separación entre cliente y servidor es una separación de tipo lógico, donde el
servidor no se ejecuta necesariamente sobre una sola máquina ni es
necesariamente un sólo programa. Los tipos específicos de servidores incluyen los servidores web, los servidores de archivo, los servidores del
correo, etc. Mientras que sus propósitos varían de unos servicios a otros, la
arquitectura básica seguirá siendo la misma.
Una disposición muy común son
los sistemas multicapa en los que el servidor se descompone en
diferentes programas que pueden ser ejecutados por diferentes computadoras aumentando así el grado de distribución del
sistema.
La arquitectura
cliente-servidor sustituye a la arquitectura monolítica en
la que no hay distribución, tanto a nivel físico como a nivel lógico.
La red cliente-servidor es
aquella red de comunicaciones en la que todos los clientes están conectados a
un servidor, en el que se centralizan los diversos recursos y aplicaciones con
que se cuenta; y que los pone a disposición de los clientes cada vez que estos
son solicitados. Esto significa que todas las gestiones que se realizan se
concentran en el servidor, de manera que en él se disponen los requerimientos
provenientes de los clientes que tienen prioridad, los archivos que son de uso
público y los que son de uso restringido, los archivos que son de sólo lectura
y los que, por el contrario, pueden ser modificados, etc. Este tipo de red
puede utilizarse conjuntamente en caso de que se este utilizando en una red
mixta.
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
contratar un servicio de redes, se debe tener en cuenta la velocidad de
conexión que le otorga al cliente y el tipo de cable que utiliza , por
ejemplo : cable de cobre ronda entre 1 ms y 50 ms.
Al receptor de la
solicitud enviada por el 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
Prácticamente todo los grandes sistemas
informáticos son en la actualidad sistemas 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 máquina. Obviamente,
la ingeniería de sistemas distribuidos tiene mucho en común con la ingeniería
de cualquier otro software, pero existen cuestiones específicas que deben
tenerse en cuenta cuando se diseña este tipo de sistemas.
Se identifican las siguientes ventajas del uso de una aproximación distribuida para el desarrolo de sistemas:
Se identifican las siguientes ventajas del uso de una aproximación distribuida para el desarrolo de sistemas:
1. Compartición de
recursos. Un sistema distribuido permite compartir recursos hardware y software
– como dicos, impresoras, ficheros y compiladores – que se asocian con
computadoras de una red.
2. Apertura. Los sistemas
distribuidos son normalmente sistemas abiertos, lo que significa que se diseñan
sobre protocolos estándar que permiten combinar equipamiento y software de
diferentes vendedores.
3. Concurrencia. En un sistema
distribuido, varios procesos pueden operar al mismo tiempo sobre diferentes
computadoras de la red. Estos procesos pueden (aunque no necesariamente)
comunicarse con otros durante su funcionamiento normal.
4. Escalabilidad. Al menos en
principio, los sistemas distribuidos son escalables en tanto que la capacidad
del sistema puede incrementarse añadiendo nuevos recursos para cubrir nuevas
demandas sobre el sistema. En la práctica, la red que una las computadoras
individuales del sistema puede limitar la escalabilidad del sistema. Si se
añaden muchas computadoras nuevas, entonces la capacidad de la red puede
resultar inadecuada.
5. Tolerancia a defectos. La disponibilidad
de varias computadoras y el potencial para reproducir información significa que
los sistemas distribuidos pueden ser tolerantes a algunos fallos de
funcionamiento del hardware y del sofware. En la mayoría de los sistemas
distribuidos, se puede proporcionar un servicio degradado cuando ocurren fallos
de funcionamiento; una completa pérdida de servicio sólo ocurre cuando existe
un fallo de funcionamiento en la red.
Para sistemas organizacionales a gran escala, estas ventajas significan que los sistemas distribuidos han reemplazado ampliamente a los sistemas heredados centralizados que fueron desarrollados en los años 80 y 90. Sin embargo, comparados con sistemas que se ejecutan sobre un único procesador o un clúster de procesadores, los sistemas distribuidos tienen varias desventajas:
1. Complejidad. Los sistemas
distribuidos son más complejos que los sistemas centralizados. Esto hace más
difícil comprender sus propiedades emergentes y probar estos sistemas. Por
ejemplo, en vez de que el rendimiento del sistema dependa de la velocidad de
ejcución de un procesador, depende del ancho de banda y de la velocidad de los
procesadores de la red. Mover los recursos de una parte del sistema a otra puede
afectar de forma radical al rendimiento del sistema.
2. Seguridad. Puede accederse al
sistema desde varias computadoras diferentes, y el tráfico en la red puede
estar sujeto a escuchas indeseadas. Esto hace más difícil el asegurar que la
integridad de los datos en el sistema se mantenga y que los servicios del
sistema no se degraden por ataques de denegación de servicio.
3. Manejabilidad. Las computadoras en
un sistema pueden ser de diferentes tipos y pueden ejecutar versiones
diferentes de sistemas operativos. Los defectos en una máquina pueden
propagarse a otras máquinas con consecuencias inesperadas. Esto significa que
se requiere más esfuerzo para gestionar y mantener el funcionamiento del
sistema.
4. Impredecibilidad. Como todos los
usuarios de la WWW saben, los sistemas distribuidos tienen una respuesta
impredecible. La respuesta depende de la carga total en el sistema, de su
organización y de la carga de la red. Como todos ellos pueden cambiar con mucha
rapidez, el tiempo requerido para responder a una petición de usuario puede
variar drásticamente de una petición a otra.
El reto para el diseño es diseñar el software y hardware para proporcionar características deseables a los sistemas distribuidos y, al mismo tiempo, minimizar los problemas inherentes a estos sistemas. Para hacer eso, se necesita comprender las ventajas y desventajas de las diferentes arquitecturas de sistemas distribuidos. Aquí se tratan dos tipos genéricos de arquitecruras de sistemas distribuidos:
1. Arquitectura
cliente-servidor. En esta aproximación, el sistema puede ser visto como un conjunto de
servicio que se proporcionan a los clientes que hacen uso de dichos servicios.
Los servidores y los clientes se tratan de forma diferente en estos sistemas.
2. Arquitecturas de
objetos distribuidos. En este caso, no hay distinción entre 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.
Ambas arquitecturas se usan ampliamente en la industria, pero la distribución de las aplicaciones generalmente tiene lugar dentro de una única organización. La distribución soportada es, por lo tanto, intraorganizacional. Aquí también se plantean dos tipos más de arquitecturas distribuidas que son más adecuadas para la distribución interorganizacional: arquitectura de sistemas peer-to-peer (p2p) y arquitecturas orientadas a servicios.
Los componentes en un sistema distribuido pueden implementarse en diferentes lenguajes de programación y pueden ejecutarse en tipos de procesadores completamente diferentes. Los modelos de datos, la representación de la información y los protocolos de comunicación pueden ser todos diferentes. Un sistema distribuido, por lo tanto, requiere software que pueda gestionar estas partes distintas, y asegurar que dichas partes se puedan comunicar e intercambiar datos. El término middleware se usa par hacer referencia a ese software; se sitúa en medio de los diferentes componentes distribuidos del sistema
El middleware es un software de propóstio general que normalmente se compra como un componente comercial más que escribirse especialmente por los desarrolladores de la aplicación. Ejemplos de middleware son software para gestionar comunicaciones con bases de datos, administradores de transacciones, convertidores de datos y controladores de comuniación.
Los sistemas distribuidos se desarrollan normalmente utilizando una aproximación orientada a objetos. Estos sistemas están formados por partes independientes pobremente integradas, cada una de las cuales pueden interaccionar directamente con los usuario o con otras partes del sistema. Algunas partes del sistema pueden tener que responder a eventos independientes. Los objetos software reflejan estas características; por lo tanto, son abstracciones naturales para los componenetes de sistemas distribuidos.
3.7 Diseño de software de
arquitectura de tiempo real
El software de
tiempo real esta 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.
La computadora digital se ha convertido en una maquina omnipresente en al vida diaria de todos nosotros. Las computadoras nos permiten ver juegos, así como contar el tiempo, optimizar el gasto de gasolina de nuestras ultimas generaciones de coches y programar a nuestros aparatos.
Todas estas interacciones con las computadoras sean útiles o intrusivas son ejemplos de computación de tiempo real. La computadora esta controlando algo que interactua con la realidad sobre una base de tiempo de hecho, el tiempo es la esencia de la interacción.
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.
Durante muchos años, los principales consumidores de sistemas de tiempo real eran militares. Sin embargo, hoy la significativa reducción del coste del hardware ha hecho posible para la mayoría de las compañías, proporcionar sistemas (y productos) de tiempo real para diversas aplicaciones, que incluyen control de procesos, automatización industrial, investigación medica y científica, gráficos de computadoras, comunicaciones locales y de largo alcance, sistemas aeroespaciales, prueba asistida por computadora y un vasto abanico de instrumentación industrial.
Consideraciones Sobre los Sistemas
Como cualquier sistema basado en computadora, un sistema de tiempo real debe integrar hardware, software, hombres y elementos de una base de datos, par conseguir adecuadamente un conjunto de requisitos funcionales y de rendimiento.
El problema para los sistemas de tiempo real es realzar la asignación importante como la función, pero las decisiones de asignación relativas al rendimiento son frecuentemente difíciles de hacer con seguridad.
¿Puede un algoritmo de procesamiento cumplir varias ligaduras de tiempo o debe construirse un hardware especial para hacer el trabajo?
¿Puede un sistema operativo cumplir nuestras necesidades para un manejo eficiente de interrupciones multitareas y comunicaciones, o especificado, acoplado con el software propuesto, cumplir los criterios de rendimiento? Estas y otras muchas preguntas deben ser respondidas por el ingeniero de sistemas de tiempo real
La computadora digital se ha convertido en una maquina omnipresente en al vida diaria de todos nosotros. Las computadoras nos permiten ver juegos, así como contar el tiempo, optimizar el gasto de gasolina de nuestras ultimas generaciones de coches y programar a nuestros aparatos.
Todas estas interacciones con las computadoras sean útiles o intrusivas son ejemplos de computación de tiempo real. La computadora esta controlando algo que interactua con la realidad sobre una base de tiempo de hecho, el tiempo es la esencia de la interacción.
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.
Durante muchos años, los principales consumidores de sistemas de tiempo real eran militares. Sin embargo, hoy la significativa reducción del coste del hardware ha hecho posible para la mayoría de las compañías, proporcionar sistemas (y productos) de tiempo real para diversas aplicaciones, que incluyen control de procesos, automatización industrial, investigación medica y científica, gráficos de computadoras, comunicaciones locales y de largo alcance, sistemas aeroespaciales, prueba asistida por computadora y un vasto abanico de instrumentación industrial.
Consideraciones Sobre los Sistemas
Como cualquier sistema basado en computadora, un sistema de tiempo real debe integrar hardware, software, hombres y elementos de una base de datos, par conseguir adecuadamente un conjunto de requisitos funcionales y de rendimiento.
El problema para los sistemas de tiempo real es realzar la asignación importante como la función, pero las decisiones de asignación relativas al rendimiento son frecuentemente difíciles de hacer con seguridad.
¿Puede un algoritmo de procesamiento cumplir varias ligaduras de tiempo o debe construirse un hardware especial para hacer el trabajo?
¿Puede un sistema operativo cumplir nuestras necesidades para un manejo eficiente de interrupciones multitareas y comunicaciones, o especificado, acoplado con el software propuesto, cumplir los criterios de rendimiento? Estas y otras muchas preguntas deben ser respondidas por el ingeniero de sistemas de tiempo real
