Universidad Nacional de Asuncin

Facultad Politcnica - Villarrica

Ingeniera de Software II
Lic. Lilian Demattei

Arquitectura de Software Julio 2016

 OBJETIVOS

Historia del la Arquitectura de Desarrollo de Software.

Introduccin a la Arquitectura de Software

Tipos de Arquitecturas.

Paradigmas de Desarrollo de software.

Aplicacin de Arquitectura en el Desarrollo de Software

Web.

Licenciatura en Ciencias Informticas IS 2 FP - UNA

Historia del la Arquitectura de
Desarrollo de Software.
 Historia de la Arquitectura de DS
1968: Edsger Dijkstra
1969: P.I. Sharp formula
1970: Diseo Estructurado
1972 - 1976: David Parnas
1975: Brooks
Arquitectura como la
especificacin completa de la IU.
Arquitectura (Qu?) vs.
Implementacin (Cmo?)
Estructura antes de programar.
Niveles de Abstraccin.
Diseo Conceptual Niklaus Wirth
Arquitectura del Software.
Especificaciones: Funcionales +
Diseo + Forma.
Modelos de desarrollo de software.
Salen de cascada a modelos
Orgnicos, Evolutivos y Cclicos.
Mdulos y Ocultamiento de
Informacin.
Estructuras de software y Familias
de Programas.
Bsqueda de Calidad del Software.
Decisiones de Diseo Tempranas.
 Historia de la Arquitectura de DS
1960 (Simula) TADs y Clases, Smalltalk
1980s: POO Teora: Modelar el Dominio del problema e
implementarlo en un lenguaje POO.

Arquitectura del Software anlogo a la

1992: Perry & Wolf
1990s: Apogeo de la AS
2000: Roy Fielding
Modelo REST: Tecnologas Web
y Modelo Orientado a Servicios.
IEEE Std 1471.
2000s: Lneas de Productos y
Metodologas de DS basada en
La Arquitectura.
construccin de edificios. Bases de la
AS (Elementos, Forma, Razn).
Herramientas CASE.
1996 - Paul Clements: Componentes.
1995 Patrones de Diseo. B4.
Estilos arquitectnicos (ADLs)
Vistas Arquitectnicas. Modelo
propuestos:
4+1.
TOGAF.
RM/ODP.
IEEE.
Introduccin a la Arquitectura
de Software
 Introduccin a la AS
Definicin: (Clements 1996): La AS es, a grandes
rasgos, una vista del sistema que incluye los
componentes principales del mismo, la conducta de
esos componentes segn se la percibe desde el resto
del sistema y las formas en que los componentes
interactan y se coordinan para alcanzar la misin del
sistema. La vista arquitectnica es una vista abstracta,
aportando el ms alto nivel de comprensin y la
supresin o diferimiento del detalle inherente a la mayor
parte de las abstracciones.
Definicin: (IEEE Std 1471): La Arquitectura de
Software es la organizacin fundamental de un sistema
encarnada en sus componentes, las relaciones entre
ellos y el ambiente y los principios que orientan su
diseo y evolucin
 Puntos de vista de la AS
Modelos estructurales: componentes, conexiones
entre ellos , la configuracin, estilo, restricciones,
semntica, anlisis, propiedades, racionalizaciones,
requerimientos, necesidades de los participantes,
(ADLs).
Modelos de framework: refieren a dominios o clases
de problemas especficos.
Modelos dinmicos: Enfatizan la cualidad conductual
de los sistemas.
Modelos de proceso: programacin de procesos para
derivar arquitecturas.
Modelos funcionales: conjunto de componentes
funcionales, organizados en capas que proporcionan
servicios hacia arriba
Segn: Shaw y David Garlan [SG95]
 Conceptos de AS
Estilos: Concepto descriptivo, define una
forma de organizacin. Ej. flujo de datos, las peer-
to-peer, las de invocacin implcita, las jerrquicas, las centradas en
datos o las de intrprete-mquina virtual.
Lenguajes de Descripcin
Arquitectnica ADLs.
Frameworks y Vistas: Es una estructura
de soporte definida en la cual otro
proyecto de software puede ser
organizado y desarrollado.
 Conceptos de AS
Principales Frameworks y Vistas

Zachman TOGAF 4+1 [BRJ99] POSA Microsoft

(Niveles) (Arquitecturas) (Vistas) (Vistas) (Vistas) (Vistas)

Scope Negocios [Text] Lgica Diseo Lgica

Empresa Datos Proceso Proceso Proceso Conceptual

Sistema lgico Aplicacin Fsica Impleme Fsica Fsica

ntacin
Tecnologa Tecnologa Desarrollo Despliegu Desarroll .
e o
Representacin . Casos de Casos de .
uso uso

Funcionamiento . . . . .
 Conceptos de AS Clasificacin de Vistas segn
Jamers Rumbaugh, Ivar Jacobson, Grady Booch
rea Vista Diagramas Conceptos principales

Estructural Vista esttica Diagrama de clases Clase, asociacin, generalizacin,

Vista de casos de Diagramas de casos de dependencia, realizacin, interfaz
uso uso Caso de uso, actor, asociacin,
Vista de Diagrama de extensin, inclusin, generalizacin
implementacin componentes de casos de uso
Vista de despliegue Diagrama de Componente, interfaz, dependencia,
despliegue realizacin
Nodo, componente, dependencia,
localizacin
Dinmica Vista de mquinas Diagrama de estados Estado, evento, transicin, accin
de estados Diagrama de actividad Estado, actividad, transicin de
Vista de actividad Diagrama de secuencia terminacin, divisin, unin
Vista de interaccin Diagrama de Interaccin, objeto, mensaje, activacin
colaboracin Colaboracin, interaccin, rol de
colaboracin, mensaje

Gestin del Vista de gestin del Diagrama de clases Paquete, subsistema, modelo
modelo modelo
 Conceptos de AS
Procesos y Metodologas: Relacionadas a las
vistas dinmicas. Mtodos Pesados (CMM) vs.
Mtodos giles (XP,FDD,etc.).
Abstraccin: consiste en extraer las
propiedades esenciales, o identificar los
aspectos importantes, o examinar
selectivamente ciertos aspectos de un
problema, posponiendo o ignorando los detalles
menos sustanciales, distractivos o irrelevantes.
Escenarios (Guin o Libreto): casos de uso
(secuencias de responsabilidades) y casos de
cambio (modificaciones propuestas al sistema)..
Investigacin y Evolucin en AS
David Garlan y Dewayne Perry : en su
introduccin al volumen de abril de 1995 de IEEE
Transactions on Software Engineering dedicado a la AS
Lenguajes de descripcin de arquitecturas.
Fundamentos formales de la AS (bases matemticas,
caracterizaciones formales de propiedades extra-funcionales
tales como mantenibilidad, teoras de la interconexin, etctera).
Tcnicas de anlisis arquitectnicas.
Mtodos de desarrollo basados en arquitectura.
Recuperacin y reutilizacin de arquitectura.
Codificacin y gua arquitectnica.
Herramientas y ambientes de diseo arquitectnico.
Estudios de casos
 Investigacin y Evolucin en AS
Paul Clements [Cle96b] (Reusabilidad): define cinco temas
fundamentales en torno de los cuales se agrupa la disciplina.
1. Diseo o seleccin de la arquitectura: Cmo crear o seleccionar una
arquitectura en base de requerimientos funcionales, de rendimiento o de
calidad.
2. Representacin de la arquitectura: Cmo comunicar una arquitectura.
Este problema se ha manifestado como el problema de la representacin de
arquitecturas utilizando recursos lingsticos, pero el problema tambin
incluye la seleccin del conjunto de informacin a ser comunicada.
3. Evaluacin y anlisis de la arquitectura: Cmo analizar una arquitectura
para predecir cualidades del sistema en que se manifiesta. Un problema
semejante es cmo comparar y escoger entre diversas arquitecturas en
competencia.
4. Desarrollo y evolucin basados en arquitectura: Cmo construir y
mantener un sistema dada una representacin de la cual se cree que es la
arquitectura que resolver el problema correspondiente.
5. Recuperacin de la arquitectura: Cmo hacer que un sistema legacy
evolucione cuando los cambios afectan su estructura; para los sistemas de
los que se carezca de documentacin confiable, esto involucra primero una
arqueologa arquitectnica que extraiga su arquitectura.
 Arquitectura vs. Diseo
Taylor y Medvidovic [TM00]: sealan que la literatura
actual mantiene en un estado ambiguo la relacin entre
ambos campos, albergando diferentes interpretaciones
y posturas:
1. Una postura afirma que arquitectura y diseo son lo mismo.
2. Otra, en cambio, alega que la arquitectura se encuentra en un
nivel de abstraccin por encima del diseo, o es simplemente
otro paso (un artefacto) en el proceso de desarrollo de
software.
3. Una tercera establece que la arquitectura es algo nuevo y en
alguna medida diferente del diseo (pero de qu manera y en
qu medida se dejan sin especificar).
La arquitectura y el diseo sirven al mismo propsito.
Sin embargo, el foco de la AS en la estructura del
sistema y en las interconexiones la distingue del diseo
de software tradicional
Tipos de Arquitecturas

Estilos ms relevantes de
desarrollo de software
 Estilos de Flujo de datos (EFD)
Esta familia de estilos enfatiza
la reutilizacin y la
modificabilidad. Es apropiada
para sistemas que
implementan
transformaciones de datos en
pasos sucesivos. Ejemplares
de la misma seran las
arquitecturas de tubera- Ej. Unix, Compiladores, XML
filtros y las de proceso Rfaga SAX, SGBD, Workflow.

secuencial en lote.
 Caractersticas del Estilo EFD
El estilo se debe usar cuando:
Se puede especificar la secuencia de un nmero conocido de
pasos.
No se requiere esperar la respuesta asincrnica de cada paso.
Se busca que todos los componentes situados corriente abajo
sean capaces de inspeccionar y actuar sobre los datos que
vienen de corriente arriba (pero no viceversa).
Ventajas:
Es simple de entender e implementar. Es posible implementar
procesos complejos con editores grficos de lneas de tuberas
o con comandos de lnea.
Fuerza un procesamiento secuencial.
Es fcil de envolver (wrap) en una transaccin atmica.
Los filtros se pueden empaquetar, y hacer paralelos o
distribuidos.
 Caractersticas del Estilo EFD
Desventajas:
El patrn puede resultar demasiado simplista, especialmente
para orquestacin de servicios que podran ramificar la
ejecucin de la lgica de negocios de formas complicadas.
No maneja con demasiada eficiencia construcciones
condicionales, bucles y otras lgicas de control de flujo.
Agregar un paso suplementario afecta la performance de cada
ejecucin de la tubera.
Una desventaja adicional referida en la literatura sobre estilos
concierne a que eventualmente pueden llegar a requerirse
buffers de tamao indefinido, por ejemplo en las tuberas de
clasificacin de datos.
El estilo no es apto para manejar situaciones interactivas,
sobre todo cuando se requieren actualizaciones incrementales
de la representacin en pantalla.
La independencia de los filtros implica que es muy posible la
duplicacin de funciones de preparacin que son efectuadas
por otros filtros (por ejemplo, el control de correccin de un
objeto de fecha).
 Ejemplo del Estilo Tubera- Filtro
en una Aplicacin Web
La aplicacin tpica del estilo es un procesamiento
clsico de datos: el cliente hace un requerimiento; el
requerimiento se valida; un Web Service toma el objeto
de la base de datos; se lo convierte a HTML; se efecta
la representacin en pantalla.
Order Processing Pipeline proporciona la secuencia
de pasos necesaria para procesar las compras en un
sitio de Web. En la primera etapa, se obtiene la
informacin del producto de la base de datos de
catlogo; en la siguiente, se procesa la direccin del
comprador; otra etapa resuelve la modalidad de pago;
una etapa ulterior confecciona la factura y otra ms
realiza el envo del pedido. Cada etapa de la tarea
representa una categora de trabajo.
Estilos Centrados en Datos (ECD)
Esta familia de estilos enfatiza la
integrabilidad de los datos. Se estima
apropiada para sistemas que se
fundan en acceso y actualizacin de
datos en estructuras de
almacenamiento. Sub-estilos
caractersticos de la familia seran los
repositorios, las bases de datos, las
arquitecturas basadas en hipertextos
y las arquitecturas de pizarra.
 ECD Pizarra o Repositorio
En esta arquitectura hay dos componentes principales:
una estructura de datos que representa el estado actual
y una coleccin de componentes independientes que
operan sobre l [SG96]. En base a esta distincin se
han definidos dos subcategoras principales del estilo:
Si los tipos de transacciones en el flujo de entrada definen los
procesos a ejecutar, el repositorio puede ser una base de datos
tradicional (implcitamente no cliente-servidor).
Si el estado actual de la estructura de datos dispara los
procesos a ejecutar, el repositorio es lo que se llama una pizarra
pura o un tablero de control.

Ej. reconocimiento de patrones,

reconocimiento de habla, Algunos
Compiladores que usan TS, AST .
Programacin gentica, evolutiva.
Uso del ECD en aplicaciones Web
No existe literatura profusa al respecto.
Se espera que con los Agentes Inteligentes se
obtengan resultados al respecto. Ej. STI
Se puede entender hacia una aplicacin que
necesite hacer los siguiente:
Fuentes de conocimiento, necesarias para resolver el
problema.
Una pizarra que representa el estado actual de la
resolucin del problema.
Una estrategia, que regula el orden en que operan
las fuentes.
Estilos de Llamada y Retorno ELR
Esta familia de estilos enfatiza la
modificabilidad y la escalabilidad. Son los
estilos ms generalizados en sistemas en
gran escala. Miembros de la familia son
las arquitecturas de programa principal y
subrutina, los sistemas basados en
llamadas a procedimientos remotos, los
sistemas orientados a objeto y los
sistemas jerrquicos en capas.
 ELR- Modelo Vista Controlador
MVC
Paradigma Interfaz Base de
Datos.
Problemas:
La interfaz suele cambiar, o
acostumbra depender de distintas
clases de dispositivos (clientes
ricos, browsers, PDAs);
La programacin de interfaces de El patrn conocido como
HTML, adems, requiere Modelo-Vista-Controlador (MVC)
habilidades muy distintas de la separa el modelado del:
programacin de lgica de
negocios. - Dominio,
- La presentacin y
Otro problema es que las
aplicaciones tienden a incorporar - Las acciones basadas en datos
lgica de negocios que van ms ingresados por el usuario en tres
all de la transmisin de datos. clases diferentes
 Caractersticas del MVC
Modelo. El modelo administra el
comportamiento y los datos del dominio de
aplicacin, responde a requerimientos de
informacin sobre su estado (usualmente
formulados desde la vista) y responde a
instrucciones de cambiar el estado
(habitualmente desde el controlador).
Vista. Maneja la visualizacin de la informacin.
Controlador. Interpreta las acciones del ratn y
el teclado, informando al modelo y/o a la vista
para que cambien segn resulte apropiado.
 Ventajas y desventajas del MVC
Ventajas:
Soporte de vistas mltiples. Dado que la vista se halla
separada del modelo y no hay dependencia directa del modelo
con respecto a la vista.
Adaptacin al cambio. Los requerimientos de interfaz de
usuario tienden a cambiar con mayor rapidez que las reglas de
negocios.
Desventajas:
Complejidad. El patrn introduce nuevos niveles de indireccin
y por lo tanto aumenta ligeramente la complejidad de la
solucin. Tambin se profundiza la orientacin a eventos del
cdigo de la interfaz de usuario, que puede llegar a ser difcil de
depurar.
Costo de actualizaciones frecuentes. Desacoplar el modelo
de la vista no significa que los desarrolladores del modelo
puedan ignorar la naturaleza de las vistas.
 Uso del MVC en una Aplicacin
Web
En aplicaciones de Web, por otra parte, la
separacin entre la vista (el browser) y el
controlador (los componentes del lado del
servidor que manejan los requerimientos
de HTTP) est mucho ms taxativamente
definida.
Ejemplo Carrito de Compras.
Estilos de Orientacin a Objetos
Los componentes de este
estilo arquitectnico son los
objetos tambin
considerados originalmente
como instancias de tipos
abstractos de datos,
aunque ahora diramos
clases.
Los objetos son ejemplos
de un tipo de componentes
que algunos llaman gestor
porque es responsable de
preservar la integridad de
un recurso, es decir la
representacin. Los objetos
interactan a travs de
invocaciones de funciones y
procedimientos.
 ECR Arquitectura Orientadas a
Objetos
Hay dos aspectos importantes en
relacin con este estilo:
1. un objeto es responsable de preservar la
integridad de su representacin
(normalmente, manteniendo algn
invariante de la misma) y
2. la representacin permanece oculta
respecto de los dems objetos
 Caractersticas de la Arquitectura OO
Los componentes del estilo se basan en principios OO:
encapsulamiento, herencia y polimorfismo. Son asimismo las
unidades de modelado, diseo e implementacin, y los objetos y
sus interacciones son el centro de las incumbencias en el diseo de
la arquitectura y en la estructura de la aplicacin.
Las interfaces estn separadas de las implementaciones. En
general la distribucin de objetos es transparente, y en el estado de
arte de la tecnologa apenas importa si los objetos son locales o
remotos. El mejor ejemplo de OO para sistemas distribuidos es
Common Object Request Broker Architecture (CORBA), en la cual
las interfaces se definen mediante Interface Description Language
(IDL); un Object Request Broker media las interacciones entre
objetos clientes y objetos servidores en ambientes distribuidos.
En cuanto a las restricciones, puede admitirse o no que una
interfaz pueda ser implementada por mltiples clases.
En tanto componentes, los objetos interactan a travs de
invocaciones de funciones y procedimientos. Hay muchas variantes
del estilo; algunos sistemas, por ejemplo, admiten que los objetos
sean tareas concurrentes; otros permiten que los objetos posean
mltiples interfaces.
 Ventajas y Desventajas de A00
Slo se sealan las ms obvias. Entre las cualidades:
Se puede modificar la implementacin de un objeto sin afectar a
sus clientes.
Es posible descomponer problemas en colecciones de agentes
en interaccin.
Un objeto es ante todo una entidad reutilizable en el entorno de
desarrollo.
Entre las limitaciones, el principal problema del estilo
Para poder interactuar con otro objeto a travs de una
invocacin de procedimiento, se debe conocer su identidad.. La
consecuencia inmediata de esta caracterstica es que cuando se
modifica un objeto (por ejemplo, se cambia el nombre de un
mtodo, o el tipo de dato de algn argumento de invocacin) se
deben modificar tambin todos los objetos que lo invocan.
Tambin se presentan problemas de efectos colaterales en
cascada: si A usa B y C tambin lo usa, el efecto de C sobre B
puede afectar a A.
 Uso de AOO en una aplicacin
Web
Ejemplo de Creacin de Clases y Objetos
en la aplicacin de ejemplo del curso.
 Estilos en Capas EC
Los sistemas o arquitecturas en capas
constituyen uno de los estilos que aparecen con
mayor frecuencia mencionados como categoras
mayores del catlogo, o, por el contrario, como
una de las posibles encarnaciones de algn
estilo ms envolvente.
En [GS94] Garlan y Shaw definen el estilo en
capas como una organizacin jerrquica tal que
cada capa proporciona servicios a la capa
inmediatamente superior y se sirve de las
prestaciones que le brinda la inmediatamente
inferior. (ms de 100 patrones o variantes de
este estilo).
EC Arquitectura Cliente / Servidor
Un componente
servidor, que ofrece
ciertos servicios,
escucha que algn otro
componente requiera
uno; un componente
cliente solicita ese
servicio al servidor a
travs de un conector.
El servidor ejecuta el
requerimiento (o lo
rechaza) y devuelve
una respuesta.
Modelo de Tres capas Microsoft DNA
Ventajas de los Modelos en Capas
El estilo soporta un diseo basado en niveles de
abstraccin crecientes, lo cual a su vez permite a los
implementadores la particin de un problema complejo
en una secuencia de pasos incrementales.
El estilo admite muy naturalmente optimizaciones y
refinamientos.
Proporciona amplia reutilizacin. Al igual que los tipos
de datos abstractos, se pueden utilizar diferentes
implementaciones o versiones de una misma capa en la
medida que soporten las mismas interfaces de cara a
las capas adyacentes. Esto conduce a la posibilidad de
definir interfaces de capa estndar, a partir de las cuales
se pueden construir extensiones o prestaciones
especficas.
 Desventajas de los Modelos en
Capas
Muchos problemas no admiten un buen mapeo en una
estructura jerrquica. Incluso cuando un sistema se
puede establecer lgicamente en capas,
consideraciones de performance pueden requerir
acoplamientos especficos entre capas de alto y bajo
nivel.
A veces es tambin extremadamente difcil encontrar el
nivel de abstraccin correcto; por ejemplo, la
comunidad de comunicacin ha encontrado complejo
mapear los protocolos existentes en el framework ISO.
Los cambios en las capas de bajo nivel tienden a
filtrarse hacia las de alto nivel, en especial si se utiliza
una modalidad relajada; tambin se admite que la
arquitectura en capas ayuda a controlar y encapsular
aplicaciones complejas, pero complica no siempre
razonablemente las aplicaciones simples
Uso Arquitectura en Capas en una
Aplicacin Web.
Ejemplo de tres capas (Ej. e-Commerce):
Interfaz: Corresponde a las pginas Web que
presentan la informacin a los usuarios. Enva los
requerimientos a la lgica para obtener una
respuesta.
Lgica: Representa los componentes del negocio
(clases y objetos) que resuelven el tratamiento de la
informacin.
Fsica: Acceden a las diferentes fuentes de datos
consultando y modificando, dependiendo de los
requerimientos de la lgica.
 Estilo CBSE (Ingeniera del
Software Basado en Componentes)
Arquitecturas Basadas en Componentes:
un componente de software, es una unidad de
composicin con interfaces especificadas
contractualmente y dependencias del contexto
explcitas.
Que sea una unidad de composicin y no de
construccin quiere decir que no es preciso
confeccionarla: se puede comprar hecha, o se puede
producir en casa para que otras aplicaciones de la
empresa la utilicen en sus propias composiciones.
Ejemplos: CORBA Component Model (CCM),
JavaBeans y Enterprise JavaBeans en J2EE y lo que
alternativamente se llam OLE, COM, ActiveX y COM+,
y luego .NET.
 Uso de AOC en una aplicacin
Web
El framework de .NET permite construir
componentes avanzados e interoperar
componentes y servicios a nivel de la
tecnologa COM+ 1.5, no como prestacin
legacy, sino en el contexto mayor
(estilsticamente mixto) de servicios de
componentes.
Ejemplo: Controles de Usuario.
Componentes del S.O.
 Estilo de Cdigo Mvil ECM
Esta familia de estilos enfatiza la
portabilidad. Ejemplos de la misma son los
intrpretes, los sistemas basados en
reglas y los procesadores de lenguaje de
comando. Fuera de las mquinas virtuales
y los intrpretes, los otros miembros del
conjunto han sido rara vez estudiados
desde el punto de vista estilstico
ECM Arquitectura de Mquina Virtual
La arquitectura de mquinas virtuales se ha llamado
tambin intrpretes basados en tablas. De hecho,
todo intrprete involucra una mquina virtual
implementada en software. Se puede decir que un
intrprete incluye un seudo-programa a interpretar y
una mquina de interpretacin. El seudo-programa a
su vez incluye el programa mismo y el anlogo que
hace el intrprete de su estado de ejecucin (o registro
de activacin). La mquina de interpretacin incluye
tanto la definicin del intrprete como el estado actual
de su ejecucin. De este modo, un intrprete posee por
lo general cuatro componentes:
1. Una mquina de interpretacin que lleva a cabo la tarea,
2. Una memoria que contiene el seudo-cdigo a interpretar,
3. Una representacin del estado de control de la mquina de
interpretacin, y
4. Una representacin del estado actual del programa que se
simula.
 Ejemplos de Implementaciones de
Mquinas Virtuales
Numerosos lenguajes y ambientes de scripting utilizan mquinas
virtuales: Perl, Javascript, Windows Script Host (WSH), Python,
PHP, Pascal. WSH, por ejemplo, tolera programacin en casi
cualquier lenguaje de scripting que se atenga a ciertas
especificaciones simples.
En la nueva estrategia arquitectnica de Microsoft la mquina virtual
por excelencia guarda relacin con el Common Language Runtime,
acaso unas de las dos piezas esenciales del framework .NET (la
otra es la biblioteca de clases). El CLR admite, en efecto, diversos
paradigmas puros y templados: programacin funcional (Lisp,
Scheme, F#, Haskell), programacin imperativa orientada a objetos
(C#, J#, C++, Python) y estructurada en bloques (Oberon),
ambientes de objetos puros (Smallscript / Smalltalk), programacin
lgica declarativa (Prolog, P#), diseo basado en contratos (Eiffel),
modelado matemtico (Fortran), scripting interpretado (Perl), meta-
programacin (SML, Mondrian), programacin cercana a la
semntica de negocios (Cobol), programacin centrada en reportes
(Visual ASNA RPG), adems de todos los matices y composiciones
heterogneas a que haya lugar
 Estilos Heterogneos - EH
Se incluye en este grupo formas compuestas o
indciles a la clasificacin en las categoras
habituales. Tipos:
Sistemas de Control de Procesos: . El objetivo de
un sistema de esta clase es mantener ciertos valores
dentro de ciertos rangos especificados, llamados
puntos fijos o valores de calibracin.
Arquitecturas Basadas en Atributos: Los estilos
basados en atributos incluyen atributos de calidad
especficos que declaran el comportamiento de los
componentes en interaccin.
Estilos Peer to Peer: Consiste por lo general en
procesos independientes o entidades que se
comunican a travs de mensajes.
Arquitecturas Basadas en Recursos:
Representational State Transfer o REST.
 EH Arquitecturas Basadas en
Eventos
Las arquitecturas basadas en eventos se han llamado
tambin de invocacin implcita. Otros nombres
propuestos para el mismo estilo han sido integracin
reactiva o difusin (broadcast) selectiva. Por supuesto
que existen estrategias de programacin basadas en
eventos, sobre todo referidas a interfaces de usuario, y
hay adems eventos en los modelos de objetos y
componentes, pero no es a eso a lo que se refiere
primariamente el estilo, aunque esa variedad no est del
todo excluida. Es implementado con el patrn
Observer, un trmino que se hizo popular en Smalltalk a
principios de los ochenta; en el mundo de Java se le
conoce como modelo de delegacin de eventos.
 EH Arquitectura Orientadas a Servicios
Slo recientemente estas arquitecturas que los
conocedores llaman SOA han recibido tratamiento
intensivo en el campo de exploracin de los estilos. Al
mismo tiempo se percibe una tendencia a promoverlas
de un sub-estilo propio de las configuraciones
distribuidas que antes eran a un estilo en plenitud.
Este predominio no se funda en la idea de servicios en
general, comunicados de cualquier manera, sino que
ms especficamente va de la mano de la expansin de
los Web services basados en XML, en los cuales los
formatos de intercambio se basan en XML 1.0
Namespaces y el protocolo de eleccin es SOAP.
SOAP significa un formato de mensajes que es XML,
comunicado sobre un transporte que por defecto es
HTTP, pero que puede ser tambin HTTPs, SMTP, FTP,
IIOP, MQ o casi cualquier otro, o puede incluir
prestaciones sofisticadas de ltima generacin como
WS-Routing, WS-Attachment, WS-Referral, etctera.
 Web Services como tendencia de
programacin Web
Un Web service es un sistema de software
diseado para soportar interaccin mquina-a-
mquina sobre una red. Posee una interfaz
descripta en un formato procesable por mquina
(especficamente WSDL). Otros sistemas
interactan con el Web service de una manera
prescripta por su descripcin utilizando
mensajes SOAP, tpicamente transportados
usando HTTP con una serializacin en XML en
conjuncin con otros estndares relacionados a
la Web. (Parte del Modelo C/S)
Caractersticas de las arquitecturas
orientadas a servicios
Un servicio es una entidad de software que encapsula
funcionalidad de negocios y proporciona dicha
funcionalidad a otras entidades a travs de interfaces
pblicas bien definidas.
Los componentes del estilo (o sea los servicios) estn
dbilmente acoplados. El servicio puede recibir
requerimientos de cualquier origen. La funcionalidad del
servicio se puede ampliar o modificar sin rendir cuentas
a quienes lo requieran. Los servicios son las unidades
de implementacin, diseo e implementacin.
Los componentes que requieran un servicio pueden
descubrirlo y utilizarlo dinmicamente mediante UDDI y
sus estndares sucesores. En general (aunque hay
alternativas) no se mantiene persistencia de estado y
tampoco se pretende que un servicio recuerde nada
entre un requerimiento y el siguiente.
 Bibliografa

Introduccin a la Arquitectura de Software. Carlos

Billy Reynoso. Universidad de Buenos aires.
Estilos y Patrones en la Estrategia de Arquitectura
de Microsoft. Versin 1.0 Marzo de 2004. Carlos
Reynoso Nicols Kicillof. Universidad de Buenos aires.
Blog de Arquitecturas,
http://homepage.mac.com/imaz/iblog/C612772037/index
.html. Consultado 12 Sept 2008.
Video MVC VsNET.
http://www.hanselman.com/silverlight/ScottHaAtAltNetCo
nf/.

Licenciatura en Ciencias Informticas IS 2 FP - UNA

 Licenciatura en Ciencias Informticas IS 2 FP - UNA

Licenciatura en Ciencias Informticas IS 1 FP - UNA