Actividad 3.

Patrones de arquitectura de software

Para esta actividad es importante tener presente los trminos estudiados durante esta unidad, ya que tiene la
finalidad de identificar los principales patrones de arquitectura de software y distinguir de manera personal sus
principales caractersticas, haciendo una descripcin de estos elementos. Por ello presta atencin a lo que a
continuacin se te solicita:

Instrucciones:
1. Identifica y describe qu es un patrn de arquitectura.

Los patrones de arquitectura dan una clara descripcin de los componentes del sistema y las relaciones que
se tienen un patrn de arquitectura, deber entenderse como una gua que ofrecen solucin a determinados
problemas ya conocidos, respecto a problemticas fundadas en la ingeniera de software. Tambin expresa
de manera clara la relacin que hay entre los componentes de una solucin basada en software y su esquema
de organizacin estructural, incluyendo todos los subsistemas y acciones que deber realizar cada uno de
ellos, adems de la manera correcta de comunicar el resultado de esas acciones entre los mismos
componentes, entre vistas o con otros sistemas externos. Sirven tambin para describir las restricciones que
tienen los mdulos que comprendern al sistema.
Cabe aclarar que la utilizacin de patrones de arquitectura no es en s la arquitectura completa, solo dan una
descripcin de la organizacin de sus componentes y relaciones que carecen de sentido de representacin de
detalles en la comunicacin de datos
La calidad en el desarrollo de software se ve beneficiada de manera muy importante con los patrones
arquitectnicos, pues dentro de ellos, por definicin, se resuelven muchos problemas de rendimiento, de
comunicacin, de transacciones, entre otros.

NOTA: Los ADLs y los patrones arquitectnicos son complementarios.

2. Redacta una lista de manera tabular para cada patrn de arquitectura, incluyendo sus principales caractersticas.

Patron de arquitectura Caractersticas





Programacin por capas
Es una arquitectura cliente- servir en el que el objetivo primordial es la
separacin de la lgica de negocios de la lgica de diseo.
La ventaja principal de este estilo es que el desarrollo se puede llevar a cabo
en varios niveles y, en caso de que sobrevenga algn cambio, slo se ataca al
nivel requerido sin tener que revisar entre cdigo mezclado.
Adems, permite distribuir el trabajo de creacin de una aplicacin por
niveles; de este modo, cada grupo de trabajo est totalmente abstrado del
resto de niveles, de forma que basta con conocer la API que existe entre
niveles.
En el diseo de sistemas informticos actual se suelen usar las arquitecturas
multinivel o Programacin por capas. En dichas arquitecturas a cada nivel se
le confa una misin simple, lo que permite el diseo de arquitecturas
escalables (que pueden ampliarse con facilidad en caso de que las
necesidades aumenten).
El diseo ms utilizado actualmente es el diseo en tres niveles (o en tres
capas)

DRS_U1_A3_THRG



















Peer-to-peer

Seis caractersticas deseables de las redes P2P:
Escalabilidad. Las redes P2P tienen un alcance mundial con cientos de millones de
usuarios potenciales. En general, lo deseable es que cuantos ms nodos estn
conectados a una red P2P, mejor ser su funcionamiento. As, cuando los nodos
llegan y comparten sus propios recursos, los recursos totales del sistema aumentan.
Esto es diferente en una arquitectura del modo servidor-cliente con un sistema fijo
de servidores, en los cuales la adicin de clientes podra significar una transferencia
de datos ms lenta para todos los usuarios. Algunos autores advierten que, si
proliferan mucho este tipo de redes, cliente-servidor, podran llegar a su fin, ya que
a cada una de estas redes se conectarn muy pocos usuarios.
Robustez. La naturaleza distribuida de las redes peer-to-peer tambin incrementa
la robustez en caso de haber fallos en la rplica excesiva de los datos hacia mltiples
destinos, y -en sistemas P2P puros- permitiendo a los peers encontrar la
informacin sin hacer peticiones a ningn servidor centralizado de indexado. En el
ltimo caso, no hay ningn punto singular de falla en el sistema.
Descentralizacin. Estas redes por definicin son descentralizadas y todos los
nodos son iguales. No existen nodos con funciones especiales, y por tanto ningn
nodo es imprescindible para el funcionamiento de la red. En realidad, algunas redes
comnmente llamadas P2P no cumplen esta caracterstica, como Napster,
eDonkey, o BitTorrent.
Distribucin de costes entre los usuarios. Se comparten o donan recursos a
cambio de recursos. Segn la aplicacin de la red, los recursos pueden ser archivos,
ancho de banda, ciclos de proceso o almacenamiento de disco.
Anonimato. Es deseable que en estas redes quede annimo el autor de un
contenido, el editor, el lector, el servidor que lo alberga y la peticin para
encontrarlo, siempre que as lo necesiten los usuarios. Muchas veces el derecho al
anonimato y los derechos de autor son incompatibles entre s, y la industria propone
mecanismos como el DRM para limitar ambos.
Seguridad. Es una de las caractersticas deseables de las redes P2P menos
implementada. Los objetivos de un P2P seguro seran identificar y evitar los nodos
maliciosos, evitar el contenido infectado, evitar el espionaje de las comunicaciones
entre nodos, creacin de grupos seguros de nodos dentro de la red, proteccin de
los recursos de la red... La mayor parte de los nodos an estn bajo investigacin,
pero los mecanismos ms prometedores son: cifrado multiclave, cajas de arena,
gestin de derechos de autor (la industria define qu puede hacer el usuario; por
ejemplo, la segunda vez que se oye la cancin se apaga), reputacin (permitir
acceso slo a los conocidos), comunicaciones seguras, comentarios sobre los
ficheros, etc.












Arquitectura dirigida por eventos
Este patrn arquitectnico puede ser aplicado por el diseo e
implementacin de aplicaciones y sistemas que transmitan eventos entre
componentes software que estn emparejados libremente y servicios. Un
sistema dirigido por eventos est compuesto tpicamente de emisores de
eventos (o agentes) y consumidores de eventos (o "sink" en ingls). Los
consumidores tienen la responsabilidad de llevar a cabo una reaccin tan
pronto como el evento est presente. La reaccin puede o no puede ser
completamente proporcionada por el consumidor en s mismo. Por ejemplo,
el consumidor debe tener solamente la responsabilidad de filtrar,
transformar y reenviar el evento a otro componente o debe proporcionar
una reaccin propia a algn evento.
Construir aplicaciones y sistemas alrededor de una arquitectura dirigida por
eventos permite a estas aplicaciones y sistemas ser construidos de una
manera que facilita un mayor grado de reaccin, debido a que los sistemas
dirigidos por eventos estn, por el diseo, ms normalizados para entornos
no predecibles y asncronos.
La arquitectura dirigida por eventos puede complementar la arquitectura
orientada a servicios (SOA) porque los servicios pueden ser activados por
disparadores que se encuentran en eventos entrantes. Este paradigma es
particularmente til cuando el consumidor no proporciona algn contenedor
ejecutivo propio.
Arquitectura de Pizarra La arquitectura e software en pizarra es un modelo arquitectnico
de software habitualmente utilizado en sistemas expertos, sistemas
multiagente y, en general, sistemas basados en el conocimiento
Este consta de mltiples elementos funcionales, denominados agentes, y
un instrumento de control denominado pizarra.
Los agentes suelen estar especializados en una tarea concreta o elemental.
Todos ellos cooperan para alcanzar una meta comn, si bien, sus objetivos
individuales no estn aparentemente coordinados.
El comportamiento bsico de cualquier agente consiste en examinar la
pizarra, realizar su tarea y escribir sus conclusiones en la misma pizarra. De
esta manera, otro agente puede trabajar sobre los resultados generados por
otro.
La computacin termina cuando se alcanza alguna condicin deseada entre
los resultados escritos en la pizarra.
La pizarra tiene un doble papel. Por una parte, coordina a los distintos
agentes y, por otra, facilita su intercomunicacin. El estado inicial de la
pizarra es una descripcin del problema que resolver y el estado final ser la
solucin del problema.
Los resultados generados por los agentes deben responder a un lenguaje y
semntica comn. En general, se suelen utilizar formalismos lgicos o
matemticos, tales como expresiones lgicas de primer orden..
Modelo- vista- controlador Es un patrn de arquitectura de software que separa los datos y la lgica de
negocio de una aplicacin de la interfaz de usuario y el mdulo encargado
de gestionar los eventos y las comunicaciones. Para ello MVC propone la
construccin de tres componentes distintos que son el modelo, la vista y
el controlador, es decir, por un lado define componentes para la
representacin de la informacin, y por otro lado para la interaccin del
usuario. Este patrn de arquitectura de software se basa en las ideas de
reutilizacin de cdigo y la separacin de conceptos, caractersticas que
buscan facilitar la tarea de desarrollo de aplicaciones y su posterior
mantenimiento
Fuentes de consulta:
http://es.wikipedia.org/wiki/Patrones_de_arquitectura

3. En un archivo de texto, coloca los elementos solicitados en los puntos 1 y 2.
4. Guarda la actividad con el nombre DRS_U1_A3_XXYZ. Sustituye las XX por las dos primeras letras de tu
primer nombre, la Y por la inicial de tuprimer apellido y la Z por la inicial de tu segundo apellido.
5. Ingresa al apartado de Tareas.
6. Enva el archivo a tu Facilitador(a) para recibir retroalimentacin.