UNIDAD
3: ARQUITECTURAS DE SOFTWARE
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.
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
- Un patrón de diseño es: una solución estándar para un problema común de programación
- una técnica para flexibilizar el código haciéndolo satisfacer ciertos criterios
- un proyecto o estructura de implementación que logra una finalidad determinada
- un lenguaje de programación de alto nivel
- una manera más práctica de describir ciertos aspectos de la organización de un programa
- Conexiones entre componentes de programas
- La forma de un diagrama de objeto o de un modelo de objeto.
Ejemplos:
Les vamos a presentar algunos ejemplos de
patrones de diseño que ya conocen. A cada diseño de proyecto le sigue el
problema que trata de resolver, la solución que aporta y las posibles
desventajas asociadas. Un desarrollador debe buscar un equilibrio entre las
ventajas y las desventajas a la hora de decidir que patrón utilizar. Lo normal
es, como observará a menudo en la ciencia computacional y en otros campos,
buscar el balance entre flexibilidad y rendimiento.
Encapsulación (ocultación de datos):
Problema: los campos externos
pueden ser manipulados directamente a partir del código externo, lo que conduce a violaciones
del invariante de representación o a
dependencias indeseables que impiden modificaciones en la implementación.
Solución: esconda algunos
componentes, permitiendo sólo accesos estilizados al objeto.
Desventajas: la interfaz no
puede, eficientemente, facilitar todas las operaciones deseadas. El acceso indirecto puede reducir el
rendimiento.
Subclase (herencia):
Problema: abstracciones
similares poseen miembros similares (campos y métodos).
Esta repetición es tediosa, propensa a
errores y un quebradero de cabeza durante
el mantenimiento.
Existen dos modelos de dominio
específico:
- Modelos genéricos que son abstracciones de varios sistemas reales.
- Modelos de referencia que son modelos abstractos y describen a una clase mayor de sistemas.
- Modelo genérico: flujo de datos de un compilador
- Modelo de referencia: la arquitectura OSI
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.
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. 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 para hacer
referencia a ese software; se ubica en medio de los diferentes componentes
distribuidos del sistema. Bernstein (Bernstein, 1996) resume los tipos de
middleware disponibles para soportar computación distribuida. El middleware es
un software de propósito 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 comunicació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 puede
interaccionar directamente con los usuarios 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 componentes de sistemas distribuidos.
Un sistema multiproceso o multitarea
es aquel que permite ejecutar varios procesos de forma concurrente, la razón es
porque actualmente la mayoría de las cpu´s solo pueden ejecutar un proceso cada
vez. La única 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
reside en la operación 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 difícil de entender:
más procesadores significa más potencia computacional.
Un conjunto de tareas puede ser
completado más rápidamente si hay varias unidades de proceso ejecutándolas en
paralelo.
VENTAJAS
·
Es económica
Las computadoras paralelas son inherentes escalables
permitiendo actualizarlas para adecuarse a la necesidad
DESVENTAJAS
·
Puede ser limitante física, existen factores que limitan la velocidad máxima
de un procesador independiente del factor económico
Las barreras físicas infranqueables
tales como la velocidad de la luz, efectos de tamaño, la capacidad.
Modelo Cliente / Servidor:
Este modelo es un prototipo de
sistemas distribuidos que muestra como los datos y el procesamiento se
distribuyen a lo largo de varios procesadores. Es una forma de dividir las
responsabilidades de un sistema de información separando la interfaz del
usuario de la gestión de la información. El funcionamiento básico de este
modelo consiste en que un programa cliente realiza peticiones a un programa
servidor, y espera hasta que el servidor de respuesta.
Características de un cliente: En la
arquitectura C/S el remitente de una solicitud es conocido como cliente.
Sus características son:
- Es quien inicia solicitudes o peticiones, tienen por tanto un papel activo en la comunicación (dispositivo maestro o amo).
- Espera y recibe las respuestas del servidor.
- Por lo general, puede conectase a varios servidores a la vez.
- Normalmente interactúa directamente con los usuarios finales mediante una interfaz gráfica de usuario.
Características de un servidor En los
sistemas C/S el receptor de la solicitud enviada por cliente se conoce como
servidor.
Sus características son:
- Al iniciarse esperan a que lleguen las solicitudes de los clientes, desempeñan entonces un papel pasivo en la comunicación (dispositivo esclavo).
- Tras la recepción de una solicitud, la procesan y luego envían la respuesta al cliente.
- Por lo general, aceptan conexiones desde un gran número de clientes (en ciertos casos el número máximo de peticiones puede estar limitado)
- No es frecuente que interactúen directamente con los usuarios finales.
Ventajas:
- Centralización del control: Los accesos, recursos y la integridad de los datos son controlados por el servidor de forma que un programa cliente defectuoso o no autorizado no pueda dañar el sistema.
- Escalabilidad: Se puede aumentar la capacidad de clientes y servidores por separado.
- Fácil mantenimiento
Desventajas:
- La congestión del tráfico (a mayor número de clientes, más problemas para el servidor).
- El software y el hardware de un servidor son generalmente muy determinantes. Un hardware regular de un ordenador personal puede no poder servir a cierta cantidad de clientes. Normalmente se necesita software y hardware específico, sobre todo en el lado del servidor, para satisfacer el trabajo. Por supuesto, esto aumentará el costo
Un
sistema distribuido es un sistema de información en el cual las funciones se reparten
por áreas de trabajo diferentes que trabajan de forma coordinada para asumir
los objetivos que la organización asigna a ese sistema de información.
Elementos
de un sistema distribuido:
En
él se integran.
La plataforma de proceso. Una vez diseñado el
sistema, es el elemento encargado de
proporcionar los recursos físicos y el software de base para ejecutarlo. Está formado por los Mainframe,
PC’s, PDA’s, teléfonos, etc… Los
elementos de la conectividad. Son los
encargados se proporcionar el transporte
para comunicar e integrar los elementos de la plataforma de proceso. Son básicamente las redes y las
comunicaciones. El almacenamiento de datos, formado por los datos en si y los
gestores donde
Se
localizan. Los elementos de software donde se incluyen las aplicaciones, los
servicios
Que
ayudan a crearlas y las interfaces que
ayudan a usarlas. En este componente se
integran las arquitecturas posibles para crearlas: centralizada, Batch, transaccional, cliente / servidor
basado en sistema operativo, cliente /
servidor basada en Internet
y aplicaciones Web Internet. A lo largo de la exposición pondremos especial cuidado en
presentar las características y
posibilidades las tres últimas.
Sistemas de seguridad.
Finalmente, debe realizarse la gestión del sistema como un conjunto
integrado y coordinado a través de los
recursos de dirección y administración. La gestión del sistema debe permitir la coexistencia de
varios centros de gestión diferentes. Parte fundamental del sistema de gestión es
el cuadro de mandos. Hay dos cuadros de mandos diferentes: El cuadro de mandos de seguimiento de los
objetivos de negocio pensado para
proporcionar información automática a los gestores de como la realidad se mueve respecto a las
previsiones de los objetivos de negocio en “tiempo real”. El
cuadro de mandos de explotación desde donde se centraliza y coordina
toda la administración, supervisión y explotación del sistema.
3.7 DISEÑO DE SOFTWARE DE TIEMPO
REAL
Las computadoras se utilizan para controlar
una amplia variedad de sistemas desde maquinas domesticas sencillas hasta
plantas enteras de fabricación. Estas computadoras interactúan directamente con
dispositivos hardware. El software de dichos sistemas es software de tiempo
real embebido que debe reaccionar a eventos generados por el hardware y emitir
señales de control como respuesta a estos eventos. Está embebido en sistemas
hardware máquina y debe responder, en tiempo real, a eventos del entorno del
sistema.
Los sistemas de tiempo real embebidos son
diferentes de otros tipos de sistemas de software. Su correcto funcionamiento
depende de que el sistema responda a los eventos dentro de un corto intervalo
de tiempo. Se puede definir un sistema de tiempo real como sigue:
Un sistema de tiempo real es un sistema
software cuyo correcto funcionamiento depende de los resultados producidos por
el mismo y del instante del tiempo en el que se producen estos resultados. Un
sistema de tiempo real blando (soft) es un sistema cuyo funcionamiento se
degrada si los resultados no se producen de acuerdo con los requerimientos
temporales especificados. Un sistema de tiempo real duro (hard) es un sistema
cuyo funcionamiento es incorrecto si los resultados no se producen de acuerdo
con la especificación temporal.
Una respuesta a tiempo es un factor
importante en todos los sistemas embebidos, pero en algunos casos, no necesita
una respuesta rápida. Por ejemplo, el sistema de bombeo de insulina es un
sistema embebido. Sin embargo, aunque se necesita comprobar el nivel de glucosa
a intervalos periódicos no es necesario responder muy rápidamente a los eventos
externos.
Una forma de ver un sistema de tiempo real es
como un sistema de 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).
Estímulos aperiódicos. Ocurren de
forma regular. Normalmente son provocados utilizando el mecanismo de
interrupciones de la computadora. Un ejemplo de dicho estímulo podría ser una
interrupción para indicar que una transferencia de E/S se ha completado y que
los datos están disponibles en el búfer.
Los estímulos periódicos en un sistema de
tiempo real son generados normalmente por sensores asociados al sistema. Estos
proporcionan información sobre el estado del entorno del sistema. Las
respuestas son dirigidas a un conjunto de actuadores que controlan algún equipo
como una bomba, que influye en el entorno del sistema. Los estímulos
aperiódicos pueden generarse por actuadores o por sensores. A menudo indican
alguna condición excepcional como un fallo en el hardware, que debe ser
manejado por el sistema. Este modelo sensor-sistema actuador de un sistema de
tiempo real embebido.
Un sistema de tiempo real tiene que responder
a estímulos que ocurren en diferentes instantes de tiempo. Por lo tanto, se
tiene que organizar su arquitectura para que, tan pronto como se reciba un
estímulo, el control sea transferido al manejador adecuado. Esto no es práctico
en programas secuenciales. Por consiguiente, los sistemas de tiempo real se diseñan
como un conjunto de procesos concurrentes que cooperan entre sí. Con el
objetivo de soportar la gestión de estos procesos, la plataforma de ejecución
para la mayoría de los sistemas de tiempo real incluye un sistema operativo de
tiempo real. Las facilidades que proporciona este sistema operativo son
accedidas a través del sistema de soporten tiempo de ejecución (run-time
system) para el lenguaje de programación de tiempo real utilizado.
La generalidad de este modelo
estímulo-respuesta de un sistema de tiempo real conduce a un modelo
arquitectónico genérico abstracto en el que hay tres tipos de procesos.
Para cada tipo de sensor, hay un proceso de gestión del sensor; los procesos computacionales
calculan la respuesta requerida para el estímulo recibido por el sistema; los
procesos de control de actuadores controlan el funcionamiento del actuador.
Este modelo permite recoger rápidamente los datos desde el sensor (antes de que
la siguiente entrada esté disponible) y permite que su procesamiento y la
respuesta asociada al actuador se realicen más tarde.
La arquitectura genérica puede instanciarse a
varias arquitecturas de aplicaciones diferentes que amplían el conjunto
de arquitecturas. Las arquitecturas de aplicaciones de tiempo real son
instancias de la arquitectura conducida por eventos en la cual el estimulo,
directa o indirectamente. Provoca la generación de eventos.
Los lenguajes de programación desarrollados
para sistemas de tiempo real tienen que incluir facilidades para acceder al
hardware del sistema, y debería ser posible predecir la duración de operaciones
particulares realizadas en estos leguajes. Los sistemas de tiempo real duros
todavía se programan algunas veces en ensamblador para que puedan cumplirse los
estrechos plazos de tiempo (deadline). Los lenguajes a nivel de sistemas como
C, que permiten generar código eficiente también se utilizan en general.
La ventaja de utilizar un lenguaje de
programación de sistemas de bajo nivel como C es que permite el desarrollo de
programas muy eficientes. Sin embargo, estos lenguajes no incluyen
construcciones para soportar la concurrencia o la gestión de recursos
compartidos. Estas se implementan atreves de llamadas al sistema operativo de tiempo
real que no pueden ser comprobados por el compilador, de forma que los errores
de programación son más probables. Los programas son también más a menudo más
difícil de comprender debido a que las características de tiempo real no
están explicitas en el programa.
ESPERO QUE LA INFORMACION QUE AQUÍ SE
PRESENTA LES SEA DE GRAN UTILIDAD PARA
SUS INVESTIGACIONES
REALIZADO POR: JOSE LUIS VITE PEREZ
