UNIDAD
III ARQUITECTURAS DE SOFTWARE
INTRODUCCIÓN
Antes de
desarrollar los temas tenemos que definir lo que significa la
arquitectura. 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.
DISEÑO Y ARQUITECTURA
DE PRODUCTOS DE SOFTWARE
El diseño del
software se encuentra en el núcleo técnico de la ingeniería del software y se
aplica independientemente del modelo de diseño de software que se utilice. Una
vez que se analizan y especifican los requisitos del software.
3.1 DESCOMPOSICION MODULAR
Descomposición modular.
El principal objetivo de la descomposición modula es de
componer los problemas difíciles en problemas sencillos
de tal manera sería mas eficiente el desarrollo del sistema. La
descomposición modular se enfoca en reutilizar código,
además debido a esta descomposición cada módulo es desarrollado con un fin
específico, de esta manera los futuros programadores comprenderán
fácilmente la función de cada módulo.
Un ejemplo de la descomposición se puede observar
en la figura1.
Figura1. Cabe resaltar los módulos, que son la muestra de la
descomposición modular del primer modulo
Las características de los módulos son:
Tamaño pequeño
Independencia modular
Abstracción
Encapsulamiento
Mientras que los objetivos de la Descomposición Modular son:
Descomponer los problemas complejos en problemas más sencillos
Reutilizar el código
Facilitar la lectura de los programa
El diseño modular propone dividir el sistema en
partes diferenciadas y definir sus interfaces. Las ventajas serían: la
claridad, reducción de costos y reutilización.
3.2 PATRONES DE DISEÑO
Los patrones de diseño son la base para la
búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos
referentes al diseño de interacción o interfaces.
Un patrón de diseño resulta ser una solución a un
problema de diseño. Para que una solución sea considerada un patrón debe poseer
ciertas características. Una de ellas es que debe haber comprobado su efectividad
resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reutilizable,
lo que significa que es aplicable a diferentes problemas de diseño en distintas
circunstancias.
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.
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.
3.3 ARQUITECTURA DE DOMINIO ESPECÍFICO
Para el desarrollo de software existen diversas arquitecturas de
dominio específico. Que serían: Diseño de software de arquitectura
multiprocesador, diseño de software distribuido, diseño de software
distribuido en tiempo real y diseño de software cliente/servidor
Existen dos modelos de dominio
específico:
• 1. Modelos genéricos que son
abstracciones de varios sistemas reales.
• 2. 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, un multiprocesador es aquel que cuenta
con dos o más microprocesadores.
Un sistema multiproceso o multitarea es aquel que permite que se
ejecuten varios procesos de forma concurrente. Cabe recalcar que a única
forma de que se ejecuten de forma simultánea varios procesadores es tener
varias CPU’s (ya sea en una maquina en o en varias, en un sistema
distribuido).
El multiproceso no es más que un conjunto de tareas que pueden ser
completadas rápidamente si hay varias unidades de proceso ejecutándolas.
Para el desarrollo de estos procesos se ocupan modelos de programación
concurrente y paralela:
Los objetivos de la programación paralela, son:
Reducir el tiempo de cómputo.
Reducir la complejidad del algoritmo,
Aprovechar al máximo la capacidad de las computadoras multiproceso.
Existen diferentes tipos de programación:
Multihilo: El cual permite a una aplicación realizar varias tareas
concurrentemente. Los distintos hilos que se ejecutan comparten una serie de
recursos.
Figura 2. Se puede observar la existencia de múltiples
procesadores.
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.
3.5 DISEÑO DE SOFTWARE DE CLIENTE – SERVIDOR
La
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.
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. Esta centralización también facilita
la tarea de poner al día datos u otros recursos (mejor que en las redes P2P)..
Escalabilidad:
se puede aumentar la capacidad de clientes y servidores por separado. Cualquier
elemento puede ser aumentado (o mejorado) en cualquier momento, o se pueden
añadir nuevos nodos a la red (clientes y/o servidores).
Fácil
mantenimiento: al estar distribuidas las funciones y responsabilidades entre
varios ordenadores independientes, es posible reemplazar, reparar, actualizar,
o incluso trasladar un servidor, mientras que sus clientes no se verán
afectados por ese cambio (o se afectarán mínimamente). Esta independencia de
los cambios también se conoce como encapsulación.
Existen
tecnologías, suficientemente desarrolladas, diseñadas para el paradigma de C/S
que aseguran la seguridad en las transacciones, la amigabilidad de la interfaz,
y la facilidad de empleo.
Desventajas:
La congestión del tráfico ha sido siempre un problema en el paradigma de C/S.
Cuando una gran cantidad de clientes envían peticiones simultaneas al mismo
servidor, puede ser que cause muchos problemas para éste (a mayor número de
clientes, más problemas para el servidor). Al contrario, en las redes P2P como
cada nodo en la red hace también de servidor, cuanto más nodos hay, mejor es el
ancho de banda que se tiene.
El
paradigma de C/S clásico no tiene la robustez de una red P2P. Cuando un
servidor está caído, las peticiones de los clientes no pueden ser satisfechas.
En la mayor parte de redes P2P, los recursos están generalmente distribuidos en
varios nodos de la red. Aunque algunos salgan o abandonen la descarga; otros
pueden todavía acabar de descargar consiguiendo datos del resto de los nodos en
la red.
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 coste.
El
cliente no dispone de los recursos que puedan existir en el servidor. Por
ejemplo, si la aplicación es una Web, no podemos escribir en el disco duro del
cliente o imprimir directamente sobre las impresoras sin sacar antes la ventana
previa de impresión de los navegadores.
3.6 DISEÑO DE SOFTWARE DE ARQUITECTURA
DISTRIBUIDA
INTRODUCCIÓN
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 desarrollo de sistemas:
1.Compartición
de recursos. Un sistema distribuido permite compartir recursos hardware y
software – como discos, 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 ejecució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 arquitecturas
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, intra organizacional. Aquí también se
plantean dos tipos más de arquitecturas distribuidas que son más adecuadas para
la distribución inter organizacional: 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 para hacer referencia a ese software; se
sitúa en medio de los diferentes componentes distribuidos del sistema.
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 pueden 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.
3.7 DISEÑO DE SOFTWARE DE
ARQUITECTURA DE TIEMPO REAL ARQUITECTURA
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.
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.
