INSTITUTO TECNOLGICO LATINOAMERICANO

ARQUITECTURA DE SOFTWARE

ALUMNO: EDER SANTIAGO DANIEL

MAESTRA EN TECNOLOGAS DE LA INFORMACIN

CATEDRTICO: MTRO. PORFIRIO ESPEJEL FLORES

MINERAL DE LA REFORMA, HIDALGO. 30 de enero de 2015.

Contenido
INTRODUCCIN ................................................................................................................. 3
Qu es la arquitectura de software? .......................................................................... 3
MAPA MENTAL DIFERENCIA ENTRE INGENIERA DE SOFTWARE VS.
ARQUITECTURA DE SOFTWARE. ................................................................................. 4
ENSAYO DEL DOCUMENTO DE IEEE .......................................................................... 5
Introduccin ...................................................................................................................... 5
Descripcin ....................................................................................................................... 5
Descripcin arquitectnica en contexto. ...................................................................... 6
Actividades arquitectnicas en el ciclo de vida. ......................................................... 7
Arquitectura de sistemas individuales. ......................................................................... 7
Arquitectura iterativa para sistemas evolutivos. ............................................ 7
Arquitectura de sistemas existentes. .................................................................. 8
Evaluacin arquitectnica. ....................................................................................... 8
Conclusin ...................................................................................................................... 8
MAPA MENTAL DE LAS COMPETENCIAS DE UN ARQUITECTO DE
SOFTWARE. ........................................................................................................................ 9
CUADRO SINPTICO DE LA TAXONOMA DE LA ARQUITECTURA DE
SOFTWARE. ...................................................................................................................... 10
EJEMPLIFICACIN MEDIANTE CASOS REALES DE LOS ESTILOS DE
ARQUITECTURA DE SOFTWARE. DOCUMENTAR BIEN Y CON
REFERENCIAS. ................................................................................................................ 11
Client-Server Style .................................................................................................... 11
Tubos y filtros ............................................................................................................. 13
Estilo Orientado a Objetos (Componentes) ..................................................... 22

INTRODUCCIN

En el mbito del software cada vez es ms comn escuchar el trmino

arquitectura de software, y encontrar oportunidades de empleo para arquitectos
de software. Aun as, este concepto tiende a ser malentendido y la falta de
comprensin al respecto de sus principios frecuentemente repercute de manera
negativa en la construccin de sistemas de software.

El concepto de arquitectura de software se refiere a la estructuracin del sistema

que, idealmente, se crea en etapas tempranas del desarrollo. Esta estructuracin
representa un diseo de alto nivel del sistema que tiene dos propsitos primarios:
satisfacer los atributos de calidad (desempeo, seguridad, modificabilidad), y
servir como gua en el desarrollo. Al igual que en la ingeniera civil, las decisiones
crticas relativas al diseo general de un sistema de software complejo deben de
hacerse desde un principio. El no crear este diseo desde etapas tempranas del
desarrollo puede limitar severamente el que el producto final satisfaga las
necesidades de los clientes. Adems, el costo de las correcciones relacionadas
con problemas en la arquitectura es muy elevado. Es as que la arquitectura de
software juega un papel fundamental dentro del desarrollo.

Qu es la arquitectura de software?
Antes de elaborar sobre el tema, es conveniente definir el concepto ya que hoy en
da el trmino de arquitectura se usa para referirse a varios aspectos relacionados
con las TI. De acuerdo al Software Engineering Institute (SEI), la Arquitectura de
Software se refiere a las estructuras de un sistema, compuestas de elementos
con propiedades visibles de forma externa y las relaciones que existen entre
ellos.

MAPA MENTAL DIFERENCIA ENTRE INGENIERA DE SOFTWARE VS. ARQUITECTURA DE SOFTWARE.

Una arquitectura de software se

selecciona y disea con base en
objetivos (requerimientos) y
restricciones.

Estudia los principios y las

metodologas de desarrollo
de software.

Se responsabiliza de
controlar y dirigir el
proceso de desarrollo del
software.

Arquitectura
de Software
Ingeniera de
Software

Determina que tareas deben

realizarse desde la captura de
requisitos hasta las pruebas e
implantacin.

Define las tcticas a emplear

en cada caso para conseguir
alinearse con los objetivos del
negocio.

Es la responsable de reflejar
las estrategias
empresariales en los
proyectos desde el mbito
puramente tcnico.

Diferencias entre
Ingeniera del Software y
Arquitectura del Software.

Es la organizacin o
estructura del
programa
Aplica el conocimiento cientfico al
diseo y construccin de software y
toda la documentacin requerida
para desarrollar, operar y
mantenerlo.

ENSAYO DEL DOCUMENTO DE IEEE

IEEE Recommended Practice for
Architectural Description of
Software-Intensive Systems
Introduccin
En la actualidad los conceptos de arquitectura no han sido definidos, ni aplicados
en el ciclo de vida de sistemas de software. A pesar de la significante actividad
industrial y de investigacin que hay esta rea, no hay un framewrok para codificar
el pensamiento arquitectnico. Para ello se cre la IEEE Architecture Planning
Group; con el propsito de facilitar la comunicacin de la arquitectura en el siclo de
vida del SoftWare para brindar beneficios de calidad a travs de una
estandarizacin de elementos y prcticas para la descripcin arquitectnica en el
desarrollo de Software
IEEE 1471 es un Estndar IEEE (Estndar de IEEE) que nos permite describir la
arquitectura de un sistema intensivo por el software, tambin conocido como la
arquitectura del software.
Descripcin
IEEE 1471 es el nombre corto para un estndar formalmente conocido como
ANSI/IEEE 1471-2000, Recomendado la Prctica para la Descripcin de la
Arquitectura de Sistemas intensivos por el Software.
Esta prctica recomendada aborda la descripcin arquitectnica de sistemas en el
desarrollo de software. Definiendo como un sistema de software intensivo a
cualquier sistema donde el software contribuye esencialmente para el diseo,
construccin, implementacin y evolucin del sistema en conjunto.
Teniendo como alcance aquellos productos de desarrollo de sistemas que
capturan informacin arquitectnica, incluyendo las siguientes descripciones
arquitectnicas:
a) Expresin del sistema y su evolucin
b) Comunicacin entre los accionistas del sistema
c) Evaluacin y comparacin de arquitecturas en una manera consecuente
d) Planificacin, direccin y ejecucin de las actividades de desarrollo del
sistema

e) Expresin de las caractersticas persistentes y principios de apoyo de un

sistema para dirigir cambio aceptable
f) Verificacin de la conformidad de la realizacin del sistema con una
descripcin arquitectnica
g) Grabacin de contribuciones al bagaje de conocimientos de arquitectura de
sistemas intensiva por el software
Segn el Glosario Estndar IEEE de la Terminologa de Ingeniera del software las
definiciones siguientes se usan:
arquitecto: La persona, equipo u organizacin responsable de disear
arquitectura de sistemas.
descripcin arquitectnica (d. C.): Una coleccin de productos para
documentar una arquitectura.
arquitectura: La organizacin fundamental de un sistema encarnado en sus
componentes, sus relaciones el uno al otro, y al ambiente y los principios
que dirigen su diseo y evolucin.
diseo: Las actividades de definicin, documentacin, mantenimiento,
mejoramiento y certificacin de realizacin apropiada de una arquitectura.
sistema: Una coleccin de componentes organizados para llevar a cabo una
funcin especfica o juego de funciones. El trmino sistema cerca
aplicaciones individuales, sistemas en el sentido tradicional, subsistemas,
sistemas de sistemas, lneas de productos, familias del producto,
empresas enteras y otras agregaciones del inters.
accionista del sistema: Un individuo, equipo u organizacin (o clases de
eso) con intereses a, o preocupaciones con relacin a, un sistema.
visin: Una representacin de un sistema entero desde el punto de vista de
un juego relacionado de preocupaciones.
punto de vista: Una especificacin de las convenciones para construir y
usar una visin. Un modelo o plantilla de la cual desarrollar visiones
individuales estableciendo los objetivos y auditorio para una visin y las
tcnicas para su creacin y anlisis.
Descripcin arquitectnica en contexto.
A continuacin se tratan trminos que sern importantes en todo el artculo.
Sistema: Se refiere a aplicaciones individuales, subsistemas, sistemas dentro de
sistemas, etc.

Contexto: Se refiere a todo lo que en cierta manera puede afectar al sistema, ya

sea poltico, de desarrollo, operacional, etc.
Stakeholder: Se refiere a todo aquel relacionado con el proyecto.
Preocupacin: Son aquellos intereses que pertenecen a cualquier aspecto del
sistema que afectan a uno o ms Stakeholders.
Misin: La misin de cada sistema es su propsito, el fin ltimo para el cual ha
sido creado.
Vista: Las vistas constituyen la descripcin arquitectnica y se usan para expresar
el sistema con respecto a un punto de vista en particular.
Una descripcin arquitectnica selecciona algunos puntos de vista (vistas)
dependiendo a qu tipo de Stakeholder valla dirigida.
Stakeholders y sus roles. A continuacin se presentan diferentes roles que puede
tener un Stakeholder.

Cliente
Usuario
Arquitecto
Desarrolladores
Evaluadores

Actividades arquitectnicas en el ciclo de vida.

La arquitectura contribuye no solo al desarrollo del sistema, sino tambin en la
operacin y en el mantenimiento del mismo. Uno de los intereses de la
arquitectura es desarrollar conceptos del sistema de manera factible y
satisfactoria. Tambin contribuye en la parte de descripcin detallada de
requerimientos e interfaces.
Arquitectura de sistemas individuales.
En los casos en que el usuario y el que adquiere el sistema son el mismo individuo
la arquitectura se lleva a cabo de acuerdo a la visin de ese clientecomprador, las
metas del sistema y las necesidades del Stakeholder. Los Stakeholders
principales son el clientecomprador y los desarrolladores.
Arquitectura iterativa para sistemas evolutivos.
En este tipo de escenario la arquitectura, el sistema y los Stakeholders
coevolucionan. Esto se refiere a que en un principio la arquitectura del sistema
satisface las necesidades particulares de los stakeholders, pero conforme pasa el
tiempo, van aumentando estas necesidades al igual que la tecnologa, la

arquitectura y el sistema tambin deben evolucionar para satisfacer los nuevos

requerimientos. Para estos sistemas, la descripcin arquitectnica se usa para la
evaluacin y desarrollo del sistema. Al ser este un proceso iterativo le da la
capacidad al sistema de ser flexible y adaptable.
Arquitectura de sistemas existentes.
Esto sucede cuando el sistema ha sido desarrollado sin una descripcin
arquitectnica, o cuando el arquitecto tiene que abandonar el proyecto por algn
motivo. Para poder tener una descripcin arquitectnica en estos casos se hace
uso de la ingeniera en reversa. Es necesario tener esta descripcin
arquitectnica, con el fin de hacer mantenimiento y desarrollo de nuevas versiones
del mismo sistema.
Evaluacin arquitectnica.
El propsito de esta evaluacin es determinar la calidad de la descripcin
arquitectnica, y predecir la calidad del sistema que cuyas arquitecturas hacen
parte de la descripcin arquitectnica. La calidad se mide por qu tan satisfechos
quedan los requerimientos de los stakeholders a los que se les ha hecho el
sistema.
Conclusin
La Arquitectura de Software, se basa en el desarrollo de los lenguajes de
descripcin arquitectnicos, la formulacin de metodologas y los patrones de
diseo.
El arquitecto de software tiene entre sus tareas fundamentales, el diseo o
seleccin de la arquitectura, su representacin, evaluacin y anlisis. Por lo que
se puede avalar el establecimiento de la AS como disciplina cientfica, sin lugar a
duda.
Sin embargo, a pesar de poseer ya un campo del conocimiento delimitado, la
Arquitectura de Software se encuentra, reconocidamente, en una etapa an
formativa. Sus tericos no se encuentran todava en condiciones de asegurar que
con las herramientas, propiedades y modelos definidos se pueda realizar un
software de la ms alta calidad posible. Por el contrario, los mejores entre los
arquitectos consideran que su disciplina es tentativa y que se encuentra en estado
de flujo. Pero aunque lo que resta por hacer es formidable, con lo que se lleva
hecho ya hay un enorme repertorio de ideas, experiencias e instrumentos que
ayudan a pensar de qu manera, aqu y ahora, se pueden mejorar las prcticas.

MAPA MENTAL DE LAS COMPETENCIAS DE UN ARQUITECTO DE SOFTWARE.

CUADRO SINPTICO DE LA TAXONOMA DE LA ARQUITECTURA DE SOFTWARE.

EJEMPLIFICACIN MEDIANTE CASOS REALES DE LOS ESTILOS DE

ARQUITECTURA DE SOFTWARE.
DOCUMENTAR BIEN Y CON
REFERENCIAS.
Client-Server Style
En el estilo Client-Server el patrn de interaccin se basa en componentes clientes
que requieren servicios de componentes server, la comunicacin es establecida e
iniciada por los componentes cliente, el requerimiento de un servicio es de un
cliente vinculado con la provisin de ese servicio por un server

Elementos
Los Servers proveen un conjunto de servicios a travs de una o ms
interfaces
Los Clientes consumen cero o ms servicios de los servers
El vnculo se establece entre el request role del conector y el puerto
del cliente, y el reply role y el puerto del server
Existe uno o ms servers en los sistemas dentro de este estilo

Especializacin
Como posibles topologas podemos agrupar de acuerdo a la forma
en que los clients y servers se comunican estableciendo una
jerarqua
Los sistemas n-tier establecen como n-1 niveles de comunicacin
entre servers existen en la jerarqua, siendo el estmulo inicial
generado por el cliente
Se puede establecer limitaciones en la cantidad de clientes que se
conectan a un server
Servidor:
Pasivo (esclavo).
Espera peticiones.

 Cuando recibe una peticin, la procesa y enva respuesta.

Puede conservar o no el estado de la comunicacin.
Los servidores no conocen ni el nmero ni las identidades de los clientes.

Cliente:
Activo (maestro).
Los clientes conocen las identidades de los servidores.
Enva peticiones.
Espera hasta que llega la respuesta.

Ejemplo

Modelo Cliente-Servidor en el sistema MexVox.

En la implementacin del sistema, nosotros utilizamos esta arquitectura en la

misma computadora, convirtiendo a MexVox en cliente y al reconocedor en
servidor. Esto porque MexVox no permite trabajar directamente con las
herramientas del ActiveX que son con las que implementamos el reconocedor.

Al entrar al sistema MexVox, ste hace un llamado al reconocedor y mediante ste

llamado se hace la conexin, luego cuando el usuario requiere del reconocedor,
presiona una tecla que es la peticin desde el MexVox al reconocedor. Con esto el
reconocedor entiende que lo estn llamando y tiene disponible el servicio de
reconocer lo que el usuario hable. Hace el proceso de reconocimiento y regresa al
MexVox el comando reconocido. Cuando el usuario presiona nuevamente la tecla,
MexVox enva una peticin al Sistema MexVox Enva la peticin de activar
reconocedor Lee palabra reconocida Reconoce lo que el usuario habla Enva
palabra reconocida Reconocedor 9 reconocedor de que est dormido (es decir
que no reconozca) hasta que se le llame nuevamente.

Tubos y filtros
Proporciona una estructura para sistemas que procesan un flujo de datos.
Cada paso de procesamiento es encapsulado en un componente filtro.
Los datos son pasados mediante tubos entre filtros adyacentes.

 La

recombinacin

de filtros permite la construccin

de

sistemas

relacionados.
Ejemplo
Suponga que se ha definido un nuevo lenguaje de programacin llamado Mocha
(Modular Object Computation with Hypothetical Algorithms). La tarea es construir
un compilador portable para este lenguaje. Para soportar existentes y futuras
plataformas de hardware se defini un lenguaje intermedio denominado AuLait
(Another Universal Language for Intermediate Translation) que corre en una
mquina virtual Cup (Concurrent Uniform Processor). El intrprete AuLait simula
Cup en software. Un backend traducir el cdigo AuLait en instrucciones de
mquina del procesador especfico para mejorar el rendimiento.

Problema
Imagine que construye un sistema que debe procesar o transformar un flujo de
datos de entrada.
La implementacin como un nico componente no es factible por las
siguientes razones:
El sistema tiene que ser construido por varios desarrolladores.
La tarea del sistema se descompone naturalmente en varias etapas
de procesamiento.
Los requerimientos pueden cambiar.

 Pensando en construir un sistema flexible que permita intercambiar o

reordenar los pasos de procesamiento, se consideran las siguientes
fuerzas:
Futuras

ampliaciones

deben

ser

posibles

intercambiando

recombinando pasos de procesamiento, an por los usuarios.

Es ms fcil reutilizar pequeos pasos de procesamiento.
Pasos de procesamiento no adyacentes no comparten informacin.
Existen diferentes fuentes de datos de entrada.
Fuerzas (cont):
Debe ser posible presentar o almacenar los resultados finales de
varias formas.
El almacenamiento explcito de resultados intermedios,

para

procesamientos adicionales, en carpetas ocasiona errores si est a

cargo de los usuarios.
Puede querer ejecutar los pasos en paralelo o casi paralelamente.

La factibilidad de la separacin de los pasos de procesamiento depende del

dominio y el problema a resolver. Esta separacin no da resultados en sistemas
interactivos o manejados por eventos.

Solucin

El patrn de arquitectura Pipes and Filters divide la tarea de un sistema en

varios pasos de procesamiento secuenciales.

Estos pasos estn conectados por el flujo de datos a travs del sistema los
datos de salida de un paso son la entrada del paso siguiente. Cada paso de
procesamiento es implementado por un componente filter.

Un filter consume y entrega datos incrementalmente en contraste debe

consumir toda su entrada antes de producir cualquier salida para lograr baja
latencia y permitir procesamiento paralelo real.

La entrada al sistema es proporcionada por una fuente de datos como un

archivo de texto. La salida va a un sumidero de datos como un archivo, una
terminal, un programa de animacin, etc.

La fuente de datos, los filtros y el sumidero de datos estn conectados

secuencialmente por pipes.

Cada pipe implementa el flujo de datos entre pasos de procesamiento

adyacentes.

La secuencia de filters combinados por pipes es llamada un pipeline de

procesamiento.

Estructura

Filter
Los componentes filter son las unidades de procesamiento del pipeline. Un filter:
Enriquece los datos de entrada computando y adicionando informacin.
Refina los datos concentrando o extrayendo informacin.
Transforma los datos de entrada entregando los datos en alguna otra
representacin.

 Una implementacin concreta puede combinar cualquiera de los tres principios

anteriores.
La actividad de un filtro puede ser disparada por:
Filtros pasivos
Los elementos posteriores de un pipeline que halan los datos de salida
del filtro.
Los elementos anteriores del pipeline que empujan los datos de salida al
filtro.
Filtros activos
La forma ms comn es que el filter est activo en un ciclo, halando su
entrada y empujando la salida al pipeline.

Pipes
Los pipes denotan las conexiones entre los filtros, entre la fuente de datos y el
primer filtro, y entre el ltimo filtro y el sumidero.
Si dos componentes activos estn unidos, el pipe los sincroniza con un buffer
FIFO. Si la actividad es controlada por uno de los filtros adyacentes, el pipe puede
ser implementado por una llamada directa del componente activo al pasivo. Sin
embargo, las llamadas directas hacen ms difcil la recombinacin.

Fuentes de datos
Las fuentes de datos representan la entrada al sistema, y proporcionan una
secuencia de valores de la misma estructura o tipo.
La fuente de datos de un pipeline puede empujar los datos activamente a la
primera etapa de procesamiento o proporcionar los datos pasivamente cuando el
filtro los hala.

Sumideros de datos
Los sumideros de datos recolectan los resultados del final del pipeline.
Un sumidero activo hala los resultados de la etapa de procesamiento
precedente.

 Un sumidero pasivo permite al filtro precedente empujar o escribir los

resultados en l.

Dinmica

Escenario 1. La fuente de datos empuja los datos.

Escenario 2. El sumidero hala los datos.

Escenario 3. Mezcla de push/pull, en la que el segundo filtro inicia el pipeline.

Escenario 4. Todos los filtros estn activos en un ciclo y cada uno en su propio hilo
de control.

Implementacin
La implementacin de la arquitectura Pipes and Filters es sencilla. Se puede usar
un servicio como colas de mensaje o pipes de UNIX para conexin a las tuberas,
u otras opciones como llamadas directas.
1. Divida la tarea del sistema en una secuencia de pasos. Cada paso debe
depender nicamente de los resultados del paso anterior.
2. Defina el formato de los datos a pasar en cada tubo. Si se define un formato
uniforme se logra la mayor flexibilidad haciendo fcil la recombinacin de
filtros.
3. Decida cmo implementar cada conexin pipe. Esta decisin determina
cuando implementar los filtros como componentes activos o pasivos. La
forma ms fcil es una llamada directa entre filtros adyacentes, pero hace
difcil el recombinar o reusar los filtros. La solucin ms flexible es usar un
mecanismo que sincronice filtros adyacentes.
4. Disee e implemente los filtros. Tenga en cuenta la tarea que debe realizar
as como los pipes adyacentes.

Los filtros activos se pueden implementar como procesos o como

hilos en el programa.

El costo de un cambio de contexto entre procesos, y la necesidad de

copiar los datos entre espacios de direcciones, pueden afectar

notablemente el rendimiento; tenga en cuenta el tamao del buffer

de los pipes como un parmetro adicional.

Se puede lograr mayor flexibilidad con componentes filter activos

pequeos con el costo de muchos cambios de contexto y
transferencias de datos.

Use la lnea de comandos o un entorno global para pasar

parmetros.

5. Disee el mecanismo de manejo de errores. Como los componentes del

pipeline no comparten estado global, el manejo de errores es difcil de
abordar y con frecuencia es negligente. Por lo menos, debe ser posible
detectar los errores (stderr).
6. Configure el pipeline de procesamiento. Se puede usar el programa
principal para configurar el pipeline y comenzar el procesamiento. O se
puede proporcionar un shell u otra facilidad para configurar los
componentes del filtro.

Variantes
Sistemas de pipelines tee and join. Filtros de una nica entrada y una nica
salida del patrn Pipes and Filters se puede modificar para permitir filtros con ms
de una entrada y ms de una salida. Lo que permite que el procesamiento sea
como un grafo dirigido que puede contener ciclos de retroalimentacin.
El comando tee de UNIX permite escribir a la salida estndar o a un archivo
simultneamente.
Usos conocidos
UNIX. Populariz el paradigma de Pipes and Filters.
Los shells de comandos y la disponibilidad de muchos programas filtro hacen
esta aproximacin al desarrollo de sistemas popular.

 Como un sistema para desarrolladores de software, tareas frecuentes como la

compilacin de un programa y la creacin de la documentacin son hechas por
pipelines en sistemas UNIX.
CMS Pipelines. Estensin al sistema operativo de mainframes IBM para soportar
arquitecturas Pipes and Filters. La implementacin sigue las convenciones de
CMS, y define un record como el tipo de dato bsico que puede ser pasado entre
pipes, en lugar de un byte o carcter ASCII.

Ventajas
No requieren archivos intermedios. Calcular resultados usando programas
separados es posible sin pipes: almacenando los resultados intermedios en
archivos.
Flexibilidad intercambiando filters. Los filters tienen una interfaz que permite que
sean fcilmente intercambiados en el procesamiento de un pipeline.
Flexibilidad por recombinacin.
Reuso de componentes filter.
Prototipado rpido de pipelines. Una vez que se ha implementado la funcin
principal con un pipeline se puede optimizar incrementalmente.
Eficiencia por procesamiento en paralelo. Es posible ejecutar componentes filter
en paralelo en un sistema multiprocesador o en una red. Si cada filter en un
pipeline consume y produce datos incrementalmente pueden ejecutar sus
funciones en paralelo.

Desventajas
Compartir informacin de estado es costoso e inflexible. Si en las etapas de
procesamiento necesita compartir una gran cantidad de datos globales, la
aplicacin del patrn resulta ser ineficiente.
La eficiencia por el paralelismo es frecuentemente una ilusin.

 Sobrecarga por transformacin de datos. Manejo de errores.

Estilo Orientado a Objetos (Componentes)

Los componentes de un sistema encapsulan los datos y las operaciones que se
deben realizar para manipular los datos. La comunicacin y la coordinacin entre
componentes se consiguen a travs del paso de mensaje. La representacin de
los datos y sus operaciones primitivas asociadas son encapsuladas en un tipo de
dato abstracto u objeto.
Caractersticas
En este estilo los componentes son los objetos, o instancias de tipos de datos
abstractos.
Estos objetos son de un tipo de componente denominado manager porque es
responsable por preservar la integridad de un recurso.
Los objetos interactan a travs de invocaciones a procedimientos y funciones.
Aspectos importantes
Un objeto es responsable de preservar la integridad de su representacin
(usualmente manteniendo algn invariante).
La representacin se oculta a otros objetos.
Ventajas
Como un objeto oculta su representacin a sus clientes, es posible cambiar su
implementacin sin modificar los clientes: modificabilidad.
La integracin de un conjunto de rutinas de acceso con los datos que manipulan
permite a los diseadores descomponer los problemas en colecciones de agentes
que interactan.
Desventajas
Para que un objeto interacte con otro (mediante la invocacin a un
procedimiento) debe conocer la identidad del otro objeto. Luego, cuando la
identidad de un objeto cambie es necesario modificar todas las invocaciones a tal
objeto.
Se pueden presentar efectos laterales: si los objetos A y C usan al objeto B,
entonces los efectos de C en B lucen como efectos laterales no esperados en A, y
viceversa.

Bibliografa
Pattern-Oriented Software Architecture: A System of Patterns, F. Buschmann,
R. Meunier, H. Rohnert, P. Sommerlad, M. Stal. John Wiley & Sons, 1996.
Software Architecture Perspective on an Emerging
discipline M. Shaw, D. Garlan Ed. Prentice Hall.
Software Architecture in Practice (2nd Edition) L. Bass, P. Clements, R.
Kazman Ed. Addison Wesley
Arquitecturas de SW: http://lml.ls.fi.upm.es/~jjmoreno/sbc/arquitecturas_sw.ppt
Servicios

Avanzados

Multimedia

http://www.lcc.uma.es/~av/misConfs/p1arquitecturas.ppt

Basados

en

Componentes: