UNIDAD 3: ARQUITECTURAS DE SOFTWARE
3.1 DESCOMPOSICIN MODULAR
Capacidad de empleo de componentes modulares. Si un mtodo de diseo
permite ensamblar los componentes de diseo (reusables) existentes en un
sistema nuevo, producir una solucin modular que no inventa nada ya inventado.
Capacidad de comprensin modular. Si un mdulo se puede comprender como
una unidad autnoma (sin referencias a otros mdulos) ser ms fcil de construir
y de cambiar.
Continuidad modular. Si pequeos cambios en los requisitos del sistema provocan
cambios en los mdulos individuales, en vez de cambios generalizados en el
sistema, se minimizar el impacto de los efectos secundarios de los cambios.
Proteccin modular. Si dentro de un mdulo se produce una condicin aberrante y
sus efectos se limitan a ese mdulo, se minimizar el impacto de los efectos
secundarios inducidos por los errores.
Finalmente, es importante destacar que un sistema se puede disear
modularmente, incluso aunque su implementacin deba ser monoltica. 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 mnimos que sean (por ejemplo, subrutinas, procedimientos). En
tales situaciones el software podr y deber disearse con modularidad como
filosofa predominante.
El cdigo se puede desarrollar en lnea. Aunque el cdigo fuente del programa
puede no tener un aspecto modular a primera vista, se ha mantenido la filosofa y
el programa proporcionar los beneficios de un sistema modular.
El diseo modular propone dividir el sistema en partes diferenciadas y definir sus
interfaces. sus ventajas: claridad, reduccin de costos y reutilizacin.
Los pasos a seguir son:
1. Identificar los mdulos
2. Describir cada mdulo
3. Describir las relaciones entre mdulos
Una descomposicin modular debe poseer ciertas cualidades mnimas para que
se pueda considerar suficiente validad.
1. Independencia funcional
2. Acoplamiento
3. Cohesin
4. Comprensibilidad
5. Adaptabilidad
3.2 PATRONES DE DISEO
Un patrn de diseo es: una solucin estndar para un problema comn de
programacin
una tcnica para flexibilizar el cdigo hacindolo satisfacer ciertos criterios
un proyecto o estructura de implementacin que logra una finalidad
determinada
un lenguaje de programacin de alto nivel
una manera ms prctica de describir ciertos aspectos de la organizacin
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 diseo que ya conocen.
A cada diseo de proyecto le sigue el problema que trata de resolver, la solucin
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 patrn
utilizar. Lo normal es, como observar a menudo en la ciencia computacional y en
otros campos, buscar el balance entre flexibilidad y rendimiento.
Encapsulacin (ocultacin de datos):
Problema: los campos externos pueden ser manipulados directamente a partir del
cdigo externo, lo que conduce a violaciones del invariante de representacin o a
dependencias indeseables que impiden modificaciones en la implementacin.
Solucin: esconda algunos componentes, permitiendo slo 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
mtodos).
Esta repeticin es tediosa, propensa a errores y un quebradero de cabeza
durante el mantenimiento.
3.3 ARQUITECTURA DE DOMINIO ESPECFICO
Existen dos modelos de dominio especfico:
Modelos genricos que son abstracciones de varios sistemas reales.
Modelos de referencia que son modelos abstractos y describen a una
clase mayor de sistemas.
1.
Modelo genrico: flujo de datos de un compilador
2.
Modelo de referencia: la arquitectura OSI
El reto para el diseo es disear el software y hardware para proporcionar
caractersticas 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 genricos 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 distincin entre servidores y clientes, y el sistema
puede ser visto como un conjunto de objetos que interaccionan cuya localizacin
es irrelevante. No hay distincin entre un proveedor de servicios y el usuario de
estos servicios. Ambas arquitecturas se usan ampliamente en la industria, pero la
distribucin de las aplicaciones generalmente tiene lugar dentro de una nica
organizacin. La distribucin soportada es, por lo tanto, intraorganizacional.
Tambin se pueden tomar dos tipos ms de arquitecturas distribuidas que son ms
adecuadas para la distribucin interorganizacional: arquitectura de sistemas peerto-peer (p2p) y arquitecturas orientadas a servicios.
Los sistemas peer-to-peer han sido usados principalmente para sistemas
personales, pero estn comenzando a usarse para aplicaciones de empresa. Los
componentes en un sistema distribuido pueden implementarse en diferentes
lenguajes de programacin y pueden ejecutarse en tipos de procesadores
completamente diferentes. Los modelos de datos, la representacin de la
informacin y los protocolos de comunicacin 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 trmino 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
computacin distribuida. El middleware es un software de propsito general que
normalmente se compra como un componente comercial ms que escribirse
especialmente por los desarrolladores de la aplicacin. Ejemplos de middleware
son software para gestionar comunicaciones con bases de datos, administradores
de transacciones, convertidores de datos y controladores de comunicacin. Los
sistemas distribuidos se desarrollan normalmente utilizando una aproximacin
orientada a objetos.
Estos sistemas estn 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 caractersticas; por
lo tanto, son abstracciones naturales para los componentes de sistemas
distribuidos.
