UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS

TRABAJO INVESTIGATIVO ARQUITECTURTA DE SOFTWARE

ANALISIS DE SISTEMAS

PRESENTADO POR:

BRAIAN ESTIVEN ALVARADO RODRIGUEZ

CODIGO 20131078098

IVAN GUSTAVO PINZON AMADO

CODIGO 20111078089

EDISON ANDRES QUIJANO

CODIGO: 20131078045

PRESENTADO A:

JUAN CARLOS GUEVARA BOLAÑOS

BOGOTÁ D.C MAYO DE 2015

 2. INTRODUCCION

En los inicios de la informática, la programación se consideraba un arte y se

desarrollaba como tal, debido a la dificultad que entrañaba para la mayoría de las
personas, pero con el tiempo se han ido descubriendo y desarrollando formas y
guías generales, con base a las cuales se puedan resolver los problemas. A estas,
se les ha denominado Arquitectura de Software, porque, a semejanza de los
planos de un edificio o construcción, estas indican la estructura, funcionamiento e
interacción entre las partes del software. En el libro "An introduction to Software
Architecture", David Garlan y Mary Shaw definen que la Arquitectura es un nivel de
diseño que hace foco en aspectos "más allá de los algoritmos y estructuras de
datos de la computación; el diseño y especificación de la estructura global del
sistema es un nuevo tipo de problema".

En el ámbito del software cada vez es más común escuchar el término

“arquitectura de software”, y encontrar oportunidades de empleo para “arquitectos
de software”. Aun así, este concepto tiende a ser malentendido y la falta de
comprensión al respecto de sus principios frecuentemente repercute de manera
negativa en la construcción de sistemas de software.
3. ARQUITECTURA DE SOFTWARE

La arquitectura de software es un conjunto de patrones que proporcionan un

marco de referencia necesario para guiar la construcción de un software,
permitiendo a los programadores, analistas y todo el conjunto de desarrolladores
del software compartir una misma línea de trabajo y cubrir todos los objetivos y
restricciones de la aplicación. Es considerada el nivel más alto en el diseño de la
arquitectura de un sistema puesto que establecen la estructura, funcionamiento e
interacción entre las partes del software.
Algunos objetivos dentro de un esquema de Arquitectura de Software pueden ser:
el software debe ser mantenerle, esto es, fácilmente analizable, modificable,
corregible; también puede ser un objetivo el nivel de interacción con otros
sistemas informáticos, o su escalabilidad.
Estas Arquitecturas están definidas muchas veces por el tipo de tecnología a la
cual se enfrenta un programador o grupo de programadores, por lo cual algunos
tipos de arquitectura son más recomendables que otras para ciertas tecnologías.
Cada tarea de computación es asignada a una computadora, por lo cual una
Arquitectura determinada debe ser implementada físicamente y definir de forma
abstracta los componentes que tomarán arte en las tareas y sus interfaces
comunicativas.
Todo esto se desarrolla a "alto nivel", ensamblando elementos para lograr la
mayor funcionalidad posible siendo a la vez portable, logrando disponiblidad,
escalabilidad y confiabilidad.
Como ejemplos de Arquitecturas podemos citar las monolíticas (los grupos
funcionales del software están altamente acoplados entre sí), cliente-servidor (se
reparte la carga de cómputo en dos partes independientes), y la arquitectura de
tres niveles (la carga se divide entre tres partes: presentación, cálculo y
almacenamiento).
4. CARACTERÍSTICAS

La arquitectura de software forma la columna vertebral para construir un sistema

de software, es en gran medida responsable de permitir o no ciertos atributos de
calidad del sistema entre los que se destacan la confiabilidad y el rendimiento del
software. Además es un modelo abstracto reutilizable [1] que puede transferirse de
un sistema a otro y que representa un medio de comunicación y discusión entre
participantes del proyecto, permitiendo así la interacción e intercambio entre los
desarrolladores con el objetivo final de establecer el intercambio de conocimientos
y puntos de vista entre ellos.
Otras características
– Nivel del diseño de software donde se definen la estructura y propiedades
globales del sistema.
– Parte del diseño de software.
– Incluye sus componentes, las propiedades observables de dichos componentes
y las relaciones que se establecen entre ellos.
– Un aspecto crítico: Una arquitectura errónea puede llevar a problemas
incontables. 2 Arquitecturas Software
– Representación de alto nivel de la estructura del sistema describiendo las partes
que lo integran.
– Puede incluir los patrones que supervisan la composición de sus componentes y
las restricciones al aplicar los patrones.
– Trata aspectos del diseño y desarrollo que no pueden tratarse adecuadamente
dentro de los módulos que forman el sistema.
5. Nombre:
LA ARQUITECTURA CLIENTE-SERVIDOR 

5.1 Descripción
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.
Algunos ejemplos de aplicaciones computacionales que usen el modelo cliente-
servidor son el Correo electrónico, un Servidor de impresión y la World Wide Web

5.2 Reseña histórica

Arquitectura Cliente / Servidor Historia 1960: Se tenia mainframes y terminales de
caracteres orientada a comandos. 1970: Aplicaciones interactivas y
transaccionales. 1980: Aparición de las pc’s y redes de área local. 1990:
Combinación del poder de las mainframes y pcs: cliente/servidor tradicional. 2000:
Objetos distribuidos y web services.
Evolución de la arquitectura cliente servidor

 La era de la computadora central

"Desde sus inicios el modelo de administración de datos a través de
computadoras se basaba en el uso de terminales remotas, que se conectaban de
manera directa a una computadora central". Dicha computadora central se
encargaba de prestar servicios caracterizados por que cada servicio se prestaba
solo a un grupo exclusivo de usuarios.

 La era de las computadoras dedicadas

Esta es la era en la que cada servicio empleaba su propia computadora que
permitía que los usuarios de ese servicio se conectaran directamente. Esto es
consecuencia de la aparición de computadoras pequeñas, de fácil uso, más
baratas y más poderosas de las convencionales.

 La era de la conexión libre

Hace mas de 10 años que la computadoras escritorio aparecieron de manera
masiva. Esto permitió que parte apreciable de la carga de trabajo de cómputo
tanto en el ámbito de cálculo como en el ámbito de la presentación se lleven a
cabo desde el escritorio del usuario. En muchos de los casos el usuario obtiene la
información que necesita de alguna computadora de servicio. Estas computadoras
de escritorio se conectan a las computadoras de servicio empleando software que
permite la emulación de algún tipo de terminal. En otros de los casos se les
transfiere la información haciendo uso de recursos magnéticos o por trascripción.

 La era del cómputo a través de redes

Esta es la era que esta basada en el concepto de redes de computadoras, en la
que la información reside en una o varias computadoras, los usuarios de esta
información hacen uso de computadoras para laborar y todas ellas se encuentran
conectadas entre si. Esto brinda la posibilidad de que todos los usuarios puedan
acceder a la información de todas las computadoras y a la vez que los diversos
sistemas intercambien información.

La era de la arquitectura cliente servidor

"En esta arquitectura la computadora de cada uno de los usuarios, llamada cliente,
produce una demanda de información a cualquiera de las computadoras que
proporcionan información, conocidas como servidores"estos últimos responden a
la demanda del cliente que la produjo.
Los clientes y los servidores pueden estar conectados a una red local o una red
amplia, como la que se puede implementar en una empresa o a una red mundial
como lo es la Internet.
Bajo este modelo cada usuario tiene la libertad de obtener la información que
requiera en un momento dado proveniente de una o varias fuentes locales o
distantes y de procesarla como según le convenga. Los distintos servidores
también pueden intercambiar información dentro de esta arquitectura.
 5.3 ESTRUCTURA CLIENTE / SERVIDOR
La arquitectura cliente servido está compuesta por los siguientes elementos:
El Puesto de Trabajo o Cliente
Una Estación de trabajo o microcomputador (PC: Computador Personal)
conectado a una red, que le permite acceder y gestionar una serie de recursos» el
cual se perfila como un puesto de trabajo universal. Nos referimos a un
microcomputador conectado al sistema de información y en el que se realiza una
parte mayoritaria de los procesos.
Se trata de un fenómeno en el sector informático. Aquellos responsables
informáticos que se oponen a la utilización de los terminales no programables,
acaban siendo marginados por la presión de los usuarios.
Debemos destacar que el puesto de trabajo basado en un microcomputador
conectado a una red, favorece la flexibilidad y el dinamismo en las organizaciones.
Entre otras razones, porque permite modificar la ubicación de los puestos de
trabajo, dadas las ventajas de la red.

Los Servidores o Back-end

Una máquina que suministra una serie de servicios como Bases de
Datos, Archivos, Comunicaciones,...).
Los Servidores, según la especialización y los requerimientos de los servicios que
debe suministrar pueden ser:
 Mainframes
 Miniordenadores
 Especializados (Dispositivos de Red, Imagen, etc.)

Una característica a considerar es que los diferentes servicios, según el caso,

pueden ser suministrados por un único Servidor o por varios Servidores
especializados.
Las Comunicaciones
En sus dos vertientes:
 Infraestructura de redes
 Infraestructura de comunicaciones

Infraestructura de redes
Componentes Hardware y Software que garantizan la conexión física y la
transferencia de datos entre los distintos equipos de la red.

Infraestructura de comunicaciones
Componentes Hardware y Software que permiten la comunicación y su gestión,
entre los clientes y los servidores.
La arquitectura Cliente/Servidor es el resultado de la integración de dos culturas.
Por un lado, la del Mainframe que aporta capacidad de almacenamiento,
integridad y acceso a la información y, por el otro, la del computador que aporta
facilidad de uso (cultura de PC), bajo costo, presentación atractiva (aspecto lúdico)
y una amplia oferta en productos y aplicaciones.

5.4 CARACTERISTICAS DEL MODELO CLIENTE/SERVIDOR

En el modelo CLIENTE/SERVIDOR podemos encontrar las siguientes

características:

 El Cliente y el Servidor pueden actuar como una sola entidad y también

pueden actuar como entidades separadas, realizando actividades o tareas
independientes.
 Las funciones de Cliente y Servidor pueden estar en plataformas
separadas, o en la misma plataforma.
Para ver el gráfico seleccione la opción "Descargar" del menú superior
 3. Un servidor da servicio a múltiples clientes en forma concurrente.
 Cada plataforma puede ser escalable independientemente. Los cambios
realizados en las plataformas de los Clientes o de los Servidores, ya sean
por actualización o por reemplazo tecnológico, se realizan de una manera
transparente para el usuario final.
 La interrelación entre el hardware y el software están basados en una
infraestructura poderosa, de tal forma que el acceso a los recursos de la red
no muestra la complejidad de los diferentes tipos de formatos de datos y de
los protocolos.
 6. Un sistema de servidores realiza múltiples funciones al mismo tiempo
que presenta una imagen de un solo sistema a las estaciones
Clientes. Esto se logra combinando los recursos de cómputo que se
encuentran físicamente separados en un solo sistema lógico,
proporcionando de esta manera el servicio más efectivo para el usuario
final.
También es importante hacer notar que las funciones Cliente/Servidor
pueden ser dinámicas. Ejemplo, un servidor puede convertirse en cliente
cuando realiza la solicitud de servicios a otras plataformas dentro de la red.
Su capacidad para permitir integrar los equipos ya existentes en una
organización, dentro de una arquitectura informática descentralizada y
heterogénea.
 7. Además se constituye como el nexo de unión mas adecuado para
reconciliar los sistemas de información basados en mainframes o
minicomputadores, con aquellos otros sustentados en entornos informáticos
pequeños y estaciones de trabajo.
 8. Designa un modelo de construcción de sistemas informáticos
de carácter distribuido.
 Su representación típica es un centro de trabajo (PC), en donde el
usuario dispone de sus propias aplicaciones de oficina y sus propias
bases de datos, sin dependencia directa del sistema central de
información de la organización, al tiempo que puede acceder a los
  recursos de este host central y otros sistemas de la organización ponen
a su servicio.

En conclusión, Cliente/Servidor puede incluir múltiples plataformas, bases de

datos, redes y sistemas operativos. Estos pueden ser de distintos proveedores, en
arquitecturas propietarias y no propietarias y funcionando todos al mismo tiempo.
Por lo tanto, su implantación involucra diferentes tipos de estándares:
APPC, TCP/IP, OSI, NFS, DRDA corriendo sobre DOS, OS/2, Windows o
PC UNIX, en TokenRing, Ethernet, FDDI o medio coaxial, sólo por mencionar
algunas de las posibilidades.

6. Nombre:

DISEÑO DE SOFTWARE DISTRIBUIDO

6.1 Descripción

Sistema, cuyos componentes hardware y software, que están en ordenadores

conectados en red, se comunican y coordinan sus acciones mediante el paso de
mensajes, para el logro de un objetivo. 
Se establece la comunicación mediante un protocolo prefijado por un esquema
cliente-servidor
El procesamiento de la información es distribuido entre varias computadoras.
USOS Y APLICACIONES 
Redes de comunicación, Seguridad de los Datos, Colección de sistemas de
cómputo autónomos interconectados a través de una red y software de
comunicaciones, capaces de cooperar en la realización de una tarea común.
Este tipo de sistemas se desarrolló junto con las redes locales de alta velocidad a
principios de los 70’s.
Sistema de automatización de una fábrica donde el sistema distribuido controla
robots y máquinas en la línea de montaje. En un banco las sucursales con
conexiones externas pueden servir el acceso a una cuenta de usuario en otra
oficina como si fuera el banco de origen

6.2 Reseña histórica

El desarrollo de los sistemas distribuidos vino de la mano de las redes locales de
alta velocidad a principios de 1970. Más recientemente, la disponibilidad de
computadoras personales de altas prestaciones, estaciones de trabajo y
ordenadores servidores ha resultado en un mayor desplazamiento hacia los
sistemas distribuidos en detrimento de los ordenadores centralizados multiusuario.
Procesamiento central (Host).- Uno de los primeros modelos de ordenadores
interconectados, llamados centralizados, donde todo el procesamiento de la
organización se llevaba a cabo en una sola computadora, normalmente un
Mainframe, y los usuarios empleaban sencillos ordenadores personales.
 
Los problemas de este modelo son:

• Cuando la carga de procesamiento aumentaba se tenía que cambiar el hardware

del Mainframe, lo cual es más costoso que añadir más computadores personales
clientes o servidores que aumenten las capacidades.
 
• El otro problema que surgió son las modernas interfaces gráficas de usuario, las
cuales podían conllevar a un gran aumento de tráfico en los medios de
comunicación y por consiguiente podían colapsar.

6.3 Estructura
En él se integran.
La  plataforma de proceso. Una vez diseñado el sistema, es el elemento 
encargado de proporcionar los recursos físicos y el software de base para 
ejecutarlo. Está formado por los Mainframe, PC’s, PDA’s, teléfonos, etc…  Los
elementos de la  conectividad. Son los encargados se proporcionar el  transporte
para comunicar e integrar los elementos de la plataforma de proceso.  Son
básicamente las redes y las comunicaciones. El almacenamiento de datos,
formado por los datos en si y los gestores donde se localizan. Los elementos de
software donde se incluyen las aplicaciones, los servicios que ayudan a crearlas y
las  interfaces que ayudan a usarlas.

 En este  componente se integran las arquitecturas posibles para crearlas:

centralizada,  Batch, transaccional, cliente / servidor basado en sistema operativo,
cliente /  servidor basada en  Internet y  aplicaciones Web Internet.  A lo largo de
la  exposición pondremos especial cuidado en presentar las características y 
posibilidades las tres últimas.   Sistemas de seguridad.  Finalmente, debe
realizarse la gestión del sistema como un conjunto integrado  y coordinado a
través de los recursos de dirección y administración. La gestión  del sistema debe
permitir la coexistencia de varios centros de gestión diferentes.  Parte fundamental
del sistema de gestión es el  cuadro de mandos. Hay dos  cuadros de mandos
diferentes: El  cuadro de mandos de seguimiento de los objetivos de negocio 
pensado para proporcionar información automática a los gestores de como  la
realidad se mueve respecto a las previsiones de los objetivos de negocio en
“tiempo real”.  El  cuadro de mandos de explotación desde donde se centraliza y
coordina toda la administración, supervisión y explotación del sistema.

6.4 Funcionamiento
La arquitectura distribuida funciona sobre cinco enfoques.
6.4. 1. La Perspectiva de Negocios (Business Perspective). Describe como trabaja
la compañía. Incluye las relaciones con terceros y los planes de evolución desde
el estado actual al objetivo deseado. Son componentes clásicos de la perspectiva
de negocio: y Los procesos de negocio. y Los Manuales de Procedimientos. y
Objetivos a corto, medio y largo plazo. y Las estructuras organizativas y sus
condicionamientos. y Las funciones de negocio que se realizan. y Las relaciones
entre estos componentes. y Los organigramas de la empresa, etc. @EMG/10 -
Enric Martínez Gomàriz 8 La perspectiva de negocios puede expresarse mediante
la modelización de los procesos empresariales desarrollándolos mediante un
modelo de procesos, siguiendo un esquema como el de la figura de la derecha.
Los procesos se gestionan mediante Bussines Process Management (BPM). Entre
otros, los elementos a gestionar dentro de un proceso BPM son, entre otros: •
Mapas de procesos.
• Modelización de los procesos.
• Reglas de negocio.
• Modelo conceptual de datos.
• Integración de datos y procesos.
• Descripción de procesos dentro de un marco SOA.
• Diseño de los procesos dentro de aplicaciones distribuidas SOA..
• Mapa de eventos-respuestas.
• Análisis de afinidad y integraci ón de procesos ., etc..
6.4. 2. La Perspectiva de Aplicación (Aplication Perspective). Define las
aplicaciones de la empresa. Son componentes clásicos de la perspectiva de
aplicación: y Descripción de las aplicaciones existentes. y Descripción de los
servicios (en el sentido que introduciremos más adelante) disponibles, internos o
externos, y sobre los que se soportan los procesos de negocio. y Forma de
obtener esos servicios. y Planes para el desarrollo de nuevas aplicaciones y
reingeniería de las antiguas para alinearlas con los objetivos y retos de los
negocios.
 6.4.3. La Perspectiva de la Información (Information Perspective). Define que
necesita saber la organización para funcionar. Son componentes clásicos de la
perspectiva de información: Procesos Terceros Clientes Proveedores
Colaboradores Sistema Distribuido basado en servicios Sistema Distribuido
basado en servicios Procedimientos Recursos Humanos Calidad Cuadro de
mandos. Arquitectura para organizar los procesos de negocio. @EMG/10 - Enric
Martínez Gomàriz 9 y La descripción y contenido de los datos. y Diccionario de
conceptos donde se explican todos los términos utilizados en la información de la
aplicación. Por ejemplo, como se evalúa el seguimiento del presupuesto de ventas
o que se entiende por venta real. Observe que esta información pueden ser
atributos de más de una entidad u obtenerse como integración de varios de ellos.
y Los modelos de datos y las estructuras de las bases de datos. y Las políticas de
administración de datos. y Descripción de las diferentes visiones con que esos
datos se crean, manipulan y consultan por la organización. y Procesos de
Workflow de datos.
6.4. 4. La Perspectiva de Gestión (Management Perspective). Define los
condicionamientos de gestión y administración de toda la plataforma distribuida.
Aunque su contenido es muy amplio, son componentes clásicos de la perspectiva
de gestión: y Lugares donde existe administración informática. y
Condicionamientos organizativos. y Políticas de soporte a usuario. y Gestión de
adquisición de recursos. y Horarios de disponibilidad. y Políticas de medición y
análisis de rendimientos, etc.
6.4. 5. La Perspectiva Tecnológica (Techology Perspective). Propone el software
básico, el hardware, las redes y las comunicaciones que soportan el sistema
distribuido y por tanto a la organización. Son componentes clásicos de la
perspectiva tecnológica: y Hardware y software básico de los puestos clientes y de
los puestos servidores. y Estándares adoptados por la organización y Recursos de
impresión. y Ofimática. y PDA’s y telefonía móvil, etc…
6.4.6. Relación entre las perspectivas. @EMG/10 - Enric Martínez Gomàriz 10 La
integración y relación entre las perspectivas de la arquitectura de empresa se
muestra en la figura. Los puntos de entrada simbolizan los inputs externos por la
evolución de los objetivos de negocio y la tecnológica. Cuando el input es a través
de la arquitectura de negocio, los inputs funcionales y operativos para las nuevas
aplicaciones o los cambios de las actuales se generan desde allí. La flecha entre
las arquitecturas de aplicación y de gestión simboliza la instalación de nuevas
aplicaciones o cambios de las actuales que han de ser administradas y
gestionadas.

6.5. CARACTERÍSTICAS:
1.- Compartición de Recursos.- Un sistema informático es abierto si el sistema
puede ser extendido de diversas maneras. La apertura de los sistemas distribuidos
se determina primariamente por el grado hacia el que nuevos servicios de
compartición de recursos se pueden añadir sin perjudicar ni duplicar a los ya
existentes.

2.- Concurrencia.- Esta característica de los sistemas distribuidos permite que los
recursos disponibles en la red puedan ser utilizados simultáneamente por los
usuarios y/o agentes que interactúan en la red.

3.- Escalabilidad.- El sistema es escalable si conserva su efectividad al ocurrir un

incremento considerable en el número de recursos y en el número de usuarios.
 
4.- Tolerancia a Fallos.- Cada componente del sistema puede fallar
independientemente, con lo cual los demás pueden continuar ejecutando sus
acciones

7. Nombre
ARQUITECTURA EN CAPAS
7.1 Descripción
Los sistemas o arquitecturas en capas constituyen uno de los estilos que aparecen
con mayor frecuencia mencionados como categorías mayores del catálogo, o, por
el contrario, como una de las posibles encarnaciones de algún estilo más
envolvente. En [GS94] Garlan y Shaw definen el estilo en capas como una
organización jerárquica tal que cada capa proporciona servicios a la capa
inmediatamente superior y se sirve de las prestaciones que le brinda la
inmediatamente inferior. Instrumentan así una vieja idea de organización
estratigráfica que se remonta a las concepciones formuladas por el patriarca
Edsger Dijkstra en la década de 1960, largamente explotada en los años
subsiguientes. En algunos ejemplares, las capas internas están ocultas a todas las
demás, menos para las capas externas adyacentes, y excepto para funciones
puntuales de exportación; en estos sistemas, los componentes implementan
máquinas virtuales en alguna de las capas de la jerarquía. En otros sistemas, las
capas pueden ser sólo parcialmente opacas. En la práctica, las capas suelen ser
entidades complejas, compuestas de varios paquetes o subsistemas. El uso de
arquitecturas en capas, explícitas o implícitas, es frecuentísimo; solamente en
Pattern Almanac 2000 [Ris00] hay cerca de cien patrones que son variantes del
patrón básico de capas. Patrones de uso común relativos al estilo son Façade,
Adapter, Bridge y Strategy [Gof95] [MS04c]. 25 En un estilo en capas, los
conectores se definen mediante los protocolos que determinan las formas de la
interacción. Los diagramas de sistemas clásicos en capas dibujaban las capas en
adyacencia, sin conectores, flechas ni interfaces; en algunos casos se suele
representar la naturaleza jerárquica del sistema en forma de círculos concéntricos
[GS94: 11]. Las restricciones topológicas del estilo pueden incluir una limitación,
más o menos rigurosa, que exige a cada capa operar sólo con capas adyacentes,
y a los elementos de una capa entenderse sólo con otros elementos de la misma;
se supone que si esta exigencia se relaja, el estilo deja de ser puro y pierde algo
de su capacidad heurística [MS04c]; también se pierde, naturalmente, la
posibilidad de reemplazar de cuajo una capa sin afectar a las restantes, disminuye
la flexibilidad del conjunto y se complica su mantenimiento. Las formas más
rígidas no admiten ni siquiera pass-through: cada capa debe hacer algo, siempre.
En la literatura especializada hay multitud de argumentos a favor y en contra del
rigor de esta clase de prescripciones. A veces se argumenta que el cruce
superfluo de muchos niveles involucra eventuales degradaciones de performance;
pero muchas más veces se sacrifica la pureza de la arquitectura en capas
precisamente para mejorarla: colocando, por ejemplo, reglas de negocios en los
procedimientos almacenados de las bases de datos, o articulando instrucciones de
consulta en la capa de la interface del usuario.

7.2 Evolución de las capas

Como se menciona en el libro de Martin Fowler [MF02], la noción de capas

aparece en la década del noventa con las aplicaciones cliente - servidor, donde el
cliente generalmente, era la interfase gráfica más la lógica de negocio (o lógica de
dominio) y el servidor, era una base de datos relacional. Figura 1. Clientes
operando sobre una base de datos vía TCP-IP Apareció un problema con respecto
a la ubicación de la lógica de negocio, ya que la mayoría de los desarrolladores la
escribían en el cliente. A medida que la lógica crecía, el código se hacía
inmantenible. A esto se lo conoce como “Fat Clients” (Clientes Gordos). Otras
desventajas que podemos encontrar en este tipo de arquitecturas son [RRR03]:
• Implementar la seguridad es más difícil ya que los algoritmos y la lógica se
encuentran del lado del cliente.
• Aumenta los problemas de mantenimiento y actualización del sistema. •
Problemas con las versiones de los clientes (distintas versiones de la aplicación
cliente).
• Lógicas complicadas y complejas demandan clientes robustos y pesados. 27
Como una primera solución a algunos de estos problemas, se optó por colocar la
lógica de negocio en el servidor (reduciendo la complejidad en la distribución de
las aplicaciones), más específicamente como, stored procedures (procedimientos
almacenados) en la base de datos. Sin embargo estos tienen ciertas limitaciones
que mencionaremos a continuación. • Tienen baja performance en problemas
distintos que el tratamiento de los datos. Si bien, en un procedimiento almacenado
individual, la ejecución puede ser más rápida a su equivalente en código, éstos
pueden tener un efecto adverso en cuestiones de escalabilidad. Al estar
embebidos en la base de datos, dependen exclusivamente de la potencia del
servidor de base de datos. Es decir, si bien en algunos casos son más rápidos,
tienen riesgos severos de escalabilidad de CPU. Roland Bouman [INT34] [INT35].
Por otra parte, los SPs pueden ser muy performantes, en algunos casos, más que
las aplicaciones Java. Los problemas de performance y conflictos con otras
aplicaciones modernas pueden ser menores en el caso de arquitecturas como
J2EE.
• Afectan negativamente al rendimiento de otras aplicaciones que utilizan el mismo
servidor de base de datos [INT35].
• Dificulta la migración a sistemas de administración de bases de datos de otros
proveedores ya que cada motor de bases de datos tiene su propio lenguaje interno
de procedimientos almacenados, la mayoría de ellos propietarios [INT34] [INT35].
La mejor excusa para evitar los SPs es el hecho de que no están integrados en un
único ambiente OOP, y muchos de ellos (TRANSACT SQL por ejemplo) no son
orientados a objetos. Al mismo tiempo que ganaban en popularidad las
arquitecturas cliente-servidor, también comenzaba a aparecer la programación
orientada a objetos. Y ésta última fue la que tuvo la respuesta para evitar el
problema de la complejización excesiva de la lógica de negocio, creando 3 capas:
La capa de presentación para lo que respecta a interfase de usuario, la capa de
negocio para la lógica de dominio y la capa de acceso a los datos. 28 Luego con la
llegada de Internet, toda la gente repentinamente quiso que sus aplicaciones
cliente-servidor funcionaran con un navegador Web. Sin embargo, si toda la lógica
de dominio estaba del lado del cliente (rich clients, clientes ricos), ésta debía ser
desarrollada de nuevo para poder soportar clientes Web. Así las aplicaciones de 3
capas, comenzaron a ganar popularidad ya que la lógica se trasladaba al servidor.
En 1995, los sitios Web estaban programados puramente en HTML donde el
contenido de las páginas no sufría demasiadas actualizaciones, pero con el tiempo
fue ganando popularidad el lenguaje PHP, haciendo los sitios muchos más
dinámicos, cambiando la manera de interactuar de los usuarios con las paginas
Web. Es decir, dejaron de ser simples sitios informativos (con contenido estático)
para ser participativas. Aquí es donde nace el concepto de la WEB 2.0. Se puede
decir que es una vuelta a los “Fat Clients” (Clientes Gordos), si bien no son tan
“gordos” como antes, no son “Thin Clients” (Clientes Delgados) clásicos [BG].
Según el sitio de Internet [INT55], la Web 2.0 es la transición que se ha dado, de
aplicaciones tradicionales de escritorio hacia aplicaciones que funcionen a través
de la Web. Mediante toda esta evolución, surge lo que se conoce como AJAX
(Javascript Asincrónico y XML – Asynchronous Javascript and Xml), el cual
engloba varias tecnologías como ser XHTML-CSS, DOM (Document Object
Model, Modelo de Objetos de Documentos) y XML [BG]. En la actualidad la Web
2.0 implica ciertas tecnologías como ser [BG] [INT55]:
• Transformar software de escritorio hacia aplicaciones web.
• Respetar a los estándares de XHTML.
• Uso de hojas de estilo (CSS) • Sindicación de contenidos.
• Ajax
• Flash, Flex o Lazlo.
• Uso de Ruby on Rails u otra herramienta equivalente para programar páginas
dinámicas
7.3 Estructura
Como se menciona en el libro de Martin Fowler [MF02], existen 3 capas
principales:
• Capa de presentación.
• Capa de negocio.
• Capa de acceso a datos.
Esta separación, mencionada por Martin Fowler [MF02], está presente en la
mayoría de los desarrollos Web por capas. Esto no quiere decir que no tengamos
más capas, sino que la cantidad de las mismas va a depender del sistema a
desarrollar. Es decir, existen grandes variaciones en cuanto a la cantidad de capas
que se utilizan en los distintos desarrollos de aplicaciones Web. La mayoría de las
arquitecturas utilizan las siguientes 4 capas conceptuales [EE03].
La siguiente descripción de arquitectura en capas, se encuentra en el Capítulo 4
de [EE03]. Lo interesante de esta clasificación es que le otorga una entidad
específica a la Capa de Dominio (pone énfasis en la misma).
La interface de usuario
 Esta capa se encargará de resolver como exponer la lógica de negocio a través
de una interface. La interface más común es la Web. Por lo que se deberá tener
en cuenta los límites de la distribución de los objetos entre el browser (navegador)
- cliente - y el servidor web.
La capa de aplicación
Esta capa no contiene reglas de negocio. Será la encargada de coordinar y
delegar trabajo a los objetos de dominio de la capa subsiguiente. Muchas veces,
esta capa, no hace el trabajo de coordinar y delegar, sino que tiene lógica de
negocio incorporada, y esto conlleva a tener un Modelo de dominio anémico (será
ampliado en el apartado 1.6.3.2). [EE03]

La capa de dominio (o capa de modelo)

También conocida como “capa de negocio". Se encargará de exponer la lógica de
negocio a las capas de más alto nivel. Aquí encontraremos las reglas de negocio.
Esta capa es el corazón de la aplicación y en ella se representarán:
? Conceptos de negocio.
 Reglas de negocio.
 Información acerca de la situación del negocio.
La capa de infraestructura
Esta capa será la encargada de proporcionar las capacidades técnicas genéricas
que apoyan las capas más altas: 34 Provee la persistencia para el dominio. Ya
sea, cómo establecer la conexión, cómo acceder a la BD y finalizar la conexión.
Básicamente en una aplicación empresarial, las tecnologías de acceso son varias
y a continuación citaremos algunas de ellas:
• Vía JDBC que viene con la API de Java.
• Utilizando algún framework de O/R Mapping: Como Hibernate, JDO (Java Data
Object), TopLink, iBattis, OJB de Apache. Es decir, soportará la interacción entre
las capas por medio de un framework de arquitectura.
Como conclusión, algunos proyectos no tienen la distinción entre las capas de
interfase de usuario y aplicación. Otros tienen múltiples capas de infraestructura.
Pero lo importante es la separación de la capa de dominio que permitirá lo que se
conoce como MDA (Model Driven Design, Diseño Dirigido por el Modelo) [EE03].

7.4 funcionamiento
Principios Fundamentales.
Los siguientes son los principios fundamentales del estilo de arquitectura basado
en N-capas/3-capas:
• Es un estilo para definir el despliegue de las capas en una instalación.
• La arquitectura de N-capas está caracterizada por la descomposición funcional
de la aplicación, los componentes de servicio y su instalación distribuida.
Mejorando la escalabilidad, disponibilidad, administración, y utilización de
recursos.
• Cada capa es completamente independiente de las otras capas, excepto aquella
que esta inmediatamente debajo de ella. La capa n solo necesita saber cómo
manejar una solicitud de la capa n+1, como hacer la solicitud a la capa n-1 (si
existe) y cómo manejar el resultado de la petición.
• La arquitectura de N-capas tiene al menos tres capas separadas o partes, cada
una de ellas con su responsabilidad y está localizada en diferentes servidores.
• Una capa es desplegada en un nivel específico si más de un servicio o aplicación
está expuesto por esa capa.
Beneficios.
Los principales beneficios del estilo de arquitectura de N-capas/3-capas son:
• Mejoras en las posibilidades de mantenimiento. Debido a que cada capa es
independiente de la otra los cambios o actualizaciones pueden ser realizados sin
afectar la aplicación como un todo.
• Escalabilidad. Como las capas están basadas en diferentes maquinas, el
escalamiento de la aplicación hacia afuera es razonablemente sencillo.
• Flexibilidad. Como cada capa puede ser manejada y escalada de forma
independiente, la flexibilidad se incrementa.
• Disponibilidad. Las aplicaciones pueden aprovechar la arquitectura modular de
los sistemas habilitados usado componentes que escalan fácilmente lo que
incrementa la disponibilidad.

7.5 Características
Las características principales que se resaltan en esta arquitectura son.
• Abstracción. La arquitectura basada en capas abstrae la vista del modelo como
un todo mientras que provee suficiente detalle para entender las relaciones entre
capas.
• Encapsulamiento. El diseño no hace asunciones acerca de tipos de datos,
métodos, propiedades o implementación.
• Funcionalidad claramente definida. El diseño claramente define la separación
entre la funcionalidad de cada capa. Capas superiores como la capa de
presentación envía comandos a las capas inferiores como la capa de negocios y la
capa de datos y los datos fluyen hacia y desde las capas en cualquier sentido.
• Alta cohesión. Cada capa contiene funcionalidad directamente relacionas con la
tarea de dicha capa.
• Reutilizable. Las capas inferiores no tienen ninguna dependencia con las capas
superiores, permitiéndoles ser reutilizables en otros escenarios.
• Desacople. La comunicación entre las capas está basada en la abstracción lo
que provee un desacople entre las capas.
Beneficios
Los principales beneficios del estilo de arquitectura basado en capas son:
• Abstracción. Las capas permiten cambios que se realicen en un nivel abstracto.
Usted puede incrementar o disminuir el nivel de abstracción usado en cada capa
de la “pila” jerárquica.
• Aislamiento. El estilo de arquitectura de capas permite asilar los cambios en
tecnologías a ciertas capas para reducir el impacto en el sistema total.
• Rendimiento. Distribuir las capas entre múltiples sistemas (físicos) puede
incrementar la escalabilidad, la tolerancia a fallos y el rendimiento.
• Mejoras en Pruebas. La capacidad de realizar pruebas se beneficia de tener una
interfaces bien definidas para cada capa así como de la habilidad para cambiar a
diferentes implementaciones de las interfaces de cada capa.
• Independencia. El estilo de arquitectura basado en capas el requerimiento de
considerar el hardware y los problemas de instalación así como las dependencias
de interfaces externas.

8. Estilos Arquitectónicos
Indican: Los tipos de componentes y conectores involucrados. Patrones y
restricciones de interconexión o composición entre ellos:
Invariantes del estilo (restricciones)
Asociados a cada estilo hay una serie de propiedades que lo caracterizan,
determinando sus ventajas e inconvenientes, condicionando la elección de uno u
otro estilo.

8.1 Descripciones

Pipes and Filters (tuberías y filtros) Descripción

  Cada componente tiene un conjunto de entradas y un conjunto de salidas.
 Cada componente lee las entradas y las transforma en salidas.
 Restricciones: Los filtros deben ser independientes. No deben compartir
estado con otros filtros. Los filtros realizan la labor independientemente del
flujo de entrada.
 Especializaciones Pipelines Bounded pipes Typed pipes
Tipos Abstractos de Datos y OO Descripción
 Las representaciones de los datos y las operaciones están encapsulados
en un tipo abstracto de datos u objeto
 Los componentes son objetos
 Las invocaciones de métodos son los conectores
 Restricciones: Los objetos son responsables de la integridad de sus
representaciones Dicha representación es ocultada al resto de los objetos

Invocación Implícita Basada en Eventos Descripción

 En lugar de invocaciones de procedimientos explicitas o directas, un
componente anuncia uno o más eventos y otros componentes registran el
interés en un evento asociando un procedimiento a dicho evento.
 La ocurrencia de un evento causa la invocación “implicita” de
procedimientos en otros módulos.
 Los componentes son los módulos cuyas interfaces ofrecen un conjunto de
procedimientos y de eventos Los conectores incluyen llamadas a
procedimientos tradicionales así como el ligado de eventos con llamadas a
procedimientos
Sistemas en Capas Descripción
 Organizado jerárquicamente en capas, donde cada capa provee servicios a
la capa superior y es servido por la capa inferior
 Los componentes son cada una de las capas
 Los conectores son los protocolos de interacción entre las capas
 Restricciones: La interacción está limitada a las capas adyacentes

Sistemas basados en depósitos Descripción

 Existen dos tipos de componentes Una estructura central de datos
(representa el estado del proceso) Componentes independientes (operan
en función del depósito de datos)
  Las interacciones entre el repositorio y los demás componentes es
variable: La entrada de los datos es seleccionada por los componentes El
estado de los datos del repositorio selecciona el proceso a ejecutar
(pizarra)

Máquina virtual o intérprete Descripción

 Formado por cuatro componentes Un motor de simulación o interpretación
Una memoria que contiene el código a interpretar Una representación del
estado de la interpretación Una representación del estado del programa
que se está simulando

8.2 Ejemplo de estilos arquitectónicos

Pipes and Filters (tuberías y filtros)

9. Lenguajes de Descripción de Arquitecturas (LDAs)

Criterios de Definición de un LDAs se remontan a los lenguajes de interconexión
de módulos (MIL) de la década de1970, pero se han comenzado a desarrollar con
sus denominación actual a partir de 1992 o 1993.Definición:ADL-Lenguaje
descriptivo de modelado arquitectónico de software que se focaliza en la
estructura de alto nivel de la aplicación antes que en los detalles de
implementación de sus módulos concretos

9.1 Conceptos
Un LDA es un lenguaje o notación para describir una arquitectura software:
Descripción de componentes, conectores y enlaces entre ellos.
Herramientas para la verificación de la arquitectura y el prototipado rápido.
 Existen LDAs de propósito general y otros de dominio específico (DSLs)
 Requisitos
Composición
Debe describir el sistema como una composición de partes
Configuración
 Debe describir la arquitectura independientemente de los componentes
Abstracción
 Debe describir los roles abstractos que juegan los componentes
Reutilización
 Debe permitir reutilizar componentes, conectores, y arquitecturas
Heterogeneidad
 Debe permitir combinar descripciones heterogéneas
Análisis
 Debe permitir diversas formas de análisis de la arquitectura

9.2 Características
Principales características de los ADL’s
• Composición: que permiten la representación del sistema como la composición
de una serie de partes.
• Configuración y Abstracción: Mediante las cuales se describen los roles o
papeles abstractos que juegan los componentes dentro de la arquitectura.
• Flexibilidad: Ya que permiten la definición de nuevas formas de interacción entre
componentes.
• Reutilización: Pues permiten la reutilización tanto de los componentes como de la
propia arquitectura, Heterogeneidad ya que pueden combinar descripciones
heterogéneas.
• Análisis: Permiten diversas formas de análisis de la arquitectura y de los
sistemas desarrollados a partir de ella.

9.3 Descripción
 Lenguajes de descripción arquitectónica (ADLs) Los ADLs permiten modelar una
arquitectura mucho antes que se lleve a cabo la programación de las aplicaciones
que la componen, analizar su adecuación, determinar sus puntos críticos y
eventualmente simular su comportamiento.
•Aparecieron a principios de los 90´s •Lo integran un conjunto de propuestas,
ampliamente conocidas en el ámbito académico
•Se fundamentan en la incapacidad de expresar conectores en UML •Alrededor de
20 ADLs han sido reconocidos
•Son poco utilizados en la industria del software Ejemplos: AADL, Acme, Rapide,
LILEANA, etc.

10. Herramientas de validación arquitectónica

HERRAMIENTAS DE ANÁLISIS, DISEÑO Y EVALUACIÓN DE
ARQUITECTURAS DE SOFTWARE Kazman (1996) plantea que una
herramienta de análisis y diseño de arquitecturas de software debe cumplir
con ciertos requerimientos, entre los que se encuentran:
Debe ser capaz de describir cualquier arquitectura. En principio, debe
permitir la especificación gráfica de arquitecturas, de forma similar a como
se lleva a cabo en un equipo de desarrollo. Los esbozos gráficos de la
arquitectura se realizan para facilitar el diseño, la exploración y la
comunicación. Para lograr el mejor cumplimiento del objetivo, la
herramienta deberá hacer uso de los componentes y los conectores que el
equipo de desarrollo actualmente usa, más que el uso de un grupo
preestablecido por la herramienta. Debe ser capaz de añadir elementos
arquitectónicos de forma recursiva, y poder establecer asociaciones
semánticamente significativas con elementos en otros niveles de
abstracción. El cumplimiento de este requerimiento es crucial para soportar
el refinamiento iterativo y el análisis de arquitecturas, donde el análisis es
significativo a cualquier nivel de refinamiento. Por ejemplo, debería permitir
esbozar un nodo en la arquitectura bajo el nombre “base de datos”, y
permitir preguntas importantes de diseño, o ejecutar análisis de
desempeño, sin la necesidad de mayor descomposición del elemento
definido. Con el cumplimiento de este requerimiento, la herramienta debería
permitir el diseño y análisis arquitectónico en cualquier grado de resolución.
Por supuesto, a mayor grado de resolución, mejores deben ser las
respuestas a la hora de comparar varias alternativas.
Debe ser capaz de determinar la concordancia de interfaces entre
componentes, tanto dentro de la arquitectura que se está diseñando, como
con sistemas externos. De igual forma, debe estar en capacidad de
determinar la correspondencia de la arquitectura implementada con la
arquitectura diseñada.
Debe contar con la capacidad de realizar ingeniería de reverso.
Debe ser capaz de analizar arquitecturas con respecto a métricas.
Debe asistir al desarrollador en el diseño, tanto como una actividad
creativa, como una actividad de análisis.
En específico, se propone que debe soportar distintos métodos de diseño, y
los procesos que estos métodos implican. Debe funcionar como un
repositorio que contenga diseños, trozos de diseño, justificaciones de
diseño y escenarios. Como repositorio, debe permitir la búsqueda de una
arquitectura, la extracción de subconjuntos significativos de ésta, y también
permitir su actualización.
Debe proveer la generación de plantillas de código, para simplificar la
transición del diseño al código, contribuyendo así con la consistencia entre
ambos. De igual forma, debe proveer herramientas de modelaje de control
de datos y flujo, así como también modelaje de desempeño. El
planteamiento de Kazman (1996) no contempla aspectos de evaluación de
las arquitecturas de software diseñadas con una herramienta que cumpla
con los requerimientos mencionados. Por otro lado, considerando que la
calidad de un sistema de software está determinada en gran parte por su
arquitectura, resulta de particular interés extender el alcance de tal
herramienta, agregando la capacidad de evaluación del diseño generado.
54 La intención es entonces resaltar algunos de los elementos que aún
pueden añadírsele a una herramienta como la propuesta por Kazman
(1996), que derive en un ambiente que tenga otras capacidades no
consideradas aún. Entre ellas se encuentran:
Inclusión de nuevos elementos de descripción, tales como los ADL, vistas
arquitectónicas y distintas notaciones
Posibilidad de evaluar la calidad de la arquitectura diseñada en base a los
elementos de diseño utilizados
Ofrecer la posibilidad de soporte a los distintos métodos y técnicas de
evaluación de arquitecturas de software Para efectos de la evaluación,
resulta interesante conocer los distintos tipos de decisión que pueden ser
tomados a nivel de diseño, puesto que un ambiente de evaluación y análisis
debe estar en capacidad de soportar estos procesos (Kazman, 1996). A
nivel arquitectónico, Bredemeyer et al. (2002) establecen que los tópicos de
decisión con frecuencia son:
 Estilos y patrones arquitectónicos
Arquitecturas de referencia
Responsabilidades asociadas a los componentes Identificación de
interconexiones entre componentes
Comportamiento dinámico del sistema
Interfaces entre componentes y sus responsabilidades
Manejo de múltiples configuraciones para sistemas distribuidos o
concurrentes Este proceso de análisis y diseño de arquitecturas de software
presenta sobrecargas de recolección, manejo y presentación de la
información relevante a ellos. Esto resulta un impedimento sustancial para
las organizaciones que quieren adoptar una actitud más madura a su
práctica en el diseño de arquitecturas de software. Proveer una herramienta
que soporte estas prácticas es un primer paso de ayuda a extender su
adopción en la industria (Kazman, 1996). Es importante que el ambiente
esté en capacidad de asistir en el proceso de diseño para efecto de la toma
de decisiones, independientemente de la metodología y en el nivel en que
se encuentre el proceso de desarrollo (Bredemeyer et al., 2002).

Lista priorizada de los atributos de calidad requeridos

Una evaluación arquitectónica solo puede proceder si se conoce el criterio
de adecuabilidad. Es más, la obtención de los atributos de calidad
requeridos contra los cuales la arquitectura será juzgada, constituye la
mayor parte del trabajo. Pero ninguna arquitectura puede tener una lista
interminable de atributos de calidad, y por lo tanto, se utilizan métodos de
priorización consensuados.

Riesgos y no riesgos
Los riegos son decisiones arquitectónicas potencialmente problemáticas.
Los no riesgos son buenas decisiones, que confían en asunciones que
con frecuencia son implícitas en la arquitectura.

Documentar riesgos y no riesgos consiste en:

 Una decisión arquitectónica (o una decisión que no ha sido tomada)
 Una respuesta específica al atributo de calidad que esta siendo
tratado, junto con las consecuencias del nivel predecible de la
respuesta.
 Una base lógica por el efecto positivo o negativo que la decisión
tuvo en alcanzar el requerimiento del atributo de calidad.

Para que un no riesgo se mantenga como tal, las asunciones no deben

cambiar, o al menos si cambian, la designación como no riesgo debe ser
rejustificada.
¿Cuáles son los costos y beneficios de realizar una evaluación arquitectónica?
El mayor beneficio que brinda la evaluación de una arquitectura, es que
descubre los problemas que si se hubiesen dejado sin descubrir, habría
sido mucho más costoso corregirlos luego. En breve, una evaluación
produce una mejor arquitectura.

Algunos beneficios más que brinda la evaluación se presentan a

continuación.

Reúne a los stakeholders

En una evaluación arquitectónica es, comúnmente, la primera vez en que
la mayoría de los stakeholders se encuentran. Es más, es la primera vez
que el arquitecto se encuentra con ellos. Todos comparten un objetivo,
lograr un sistema exitoso.

Fuerza una articulación en las metas específicas de calidad

El rol del stakeholder es articular las metas de calidad que la arquitectura
debería alcanzar para ser considerada exitosa. Estas metas no siempre
son capturadas en algún documento de requerimientos.

Fuerza una explicación clara de la arquitectura

El arquitecto convoca a un grupo de personas, no en privado, para
explicarles la creación de la arquitectura, en detalle y sin ambigüedades.
El proyecto se ve beneficiado cuanto antes se realice esta explicación.

Mejora la calidad de la documentación de la arquitectura

Generalmente, la evaluación pide documentación que aún no esta
terminada, entonces se designa alguien del plantel a terminarla. Una vez
más, el proyecto se ve beneficiado porque se ingresa al desarrollo mejor
preparado al tener los documentos terminados.

Descubre oportunidades de reuso

Los stakeholders y el equipo de evaluación provienen de afuera del
proyecto de desarrollo, pero trabajan o están familiarizados con otros
proyectos. Por lo tanto, ambos están en una buena posición para detectar
componentes que pueden ser reusados en otros proyectos, o conocer
componentes que ya existen que pueden ser utilizados en el proyecto
actual.

Resultan mejoras en las arquitecturas

Las organizaciones que practican la evaluación arquitectónica como un
estándar de su proceso de desarrollo, reportan una mejora en la calidad
de las arquitecturas que son evaluadas. La evaluación de arquitecturas
 resulta en mejores arquitecturas no solo después de hecha, pero antes
también.

Los costos de la evaluación arquitectónica son todos costos de personal y

costos de oportunidad por aquel personal que participa de la evaluación en
vez de hacer otra cosa. Estos costos son sencillos de calcular (están
tabulados).

10.2 Descripción de funcionalidades

Software Architecture Analysis Method (SAAM)

Introducción
SAAM (Software Architecture Analysis Method) fue el primer método de
evaluación basado en escenarios que surgió.
El foco de este método es la modificabilidad.
Propósito
Los creadores de SAAM idearon un método para evaluar, por medio de
escenarios, los diferentes atributos de calidad que las arquitecturas de
software demandaban. En la práctica SAAM ha demostrado ser útil para
evaluar muchos atributos de calidad rápidamente, como portabilidad,
modificabilidad, extensibilidad, integrabilidad, así como el cubrimiento
funcional que tiene la arquitectura sobre los requerimientos del sistema. El
método también puede ser utilizado para evaluar aspectos más ligados con
la arquitectura como performance o confiabilidad. Sin embargo, existen
otros métodos como ATAM (Architecture Trade-off Analysis Method) que
exploran estos aspectos con más profundidad.

SAAM puede ser utilizado para evaluar una o múltiples arquitecturas. Si se

comparan dos o más se culmina el análisis con una tabla indicando las
fortalezas y debilidades de cada una en cada escenario. Si se evalúa una
sola, se culmina con un reporte señalando los componentes
computacionales donde la arquitectura no alcanza el nivel requerido. En
ningún caso se emite un valor absoluto acerca de la “calidad
arquitectónica”.
Contexto y escenarios de SAAM.
La mayoría de los atributos de calidad son demasiados complejos y
amorfos para ser evaluados simplemente. Consideremos dos ejemplos:
Supongamos que un sistema puede acomodarse a nuevas plataformas
computacionales, con el solo hecho de recompilarse, pero antes de la
recopilación, deben ser modificados manualmente una docena de archivos
y programas. ¿Nosotros decimos que el sistema es o no modificable?
Supongamos que un sistema posee una interfaz de usuario que se piensa
cuidadosamente para que los usuarios novatos puedan utilizarlo con un
mínimo de esfuerzo, pero esto implica que la utilización del sistema sea
muy tediosa para los usuario experimentados. ¿Nosotros decimos que el
sistema es o no usable?
El punto en los ejemplos anteriores, es que no existe aislamiento para
evaluar esos atributos de calidad. Dichos atributos sólo tienen sentido y
pueden ser evaluados dentro de un contexto. Un sistema es modificable (o
no) respecto a ciertas clases de cambios, es seguro (o no) respecto a
amenazas específicas, es usable (o no) respecto a ciertos tipos de
usuarios. Declaraciones como “el sistema es altamente mantenible”, no
tienen significado operacional. Deseamos validar enunciados sobre la
calidad del sistema a partir de una descripción arquitectónica, y no a través
de enunciados abstractos y en general, carentes de significado.
Esta noción de evaluación basada en el contexto, nos ha llevado a adoptar
a los escenarios como los medios descriptivos para especificar y evaluar
atributos de calidad.
Podemos definir un escenario como una breve descripción de la interacción
entre un interesado y el sistema. El interesado puede ser un cliente, usuario
final, desarrollador, empresa desarrolladora, administrador, inversor, etc.
Un escenario en particular sirve como representante para un grupo de
escenarios diferentes. Por ejemplo el escenario “Cambiar el color de fondo
de todas las ventanas a azul” es esencialmente equivalente a “cambiar las
decoración en todas las ventanas”. Entendemos por escenarios
equivalentes a aquellos que al “ejecutarse” ponen en juego los mismos
componentes y conectores de la arquitectura.
Los escenarios son clasificados en escenarios directos e indirectos. (Son
equivalentes en notación UML a casos de uso y casos de cambio)
Un escenario directo no requiere que el sistema sea modificado para
soportarlo (consideramos que el sistema es modificado cuando se cambia
la función asignada a un componente o se agrega un componente o
conector). Un escenario indirecto requiere que el sistema sea modificado
para soportarlo.
Cuando dos o más escenarios indirectos requieren cambios sobre la misma
entidad o componente, se dice que interactúan en dicho componente. En
este caso, los componentes afectados necesitan ser modificados o divididos
en subcomponentes para evitar la interacción de diferentes escenarios.
Podemos decir que a mayor interacción de escenarios, menor separación
de conceptos.
SAAM utiliza el agrupamiento de escenarios como criterio para evaluar la
arquitectura. Esto significa que si se agrupa un conjunto de escenarios por
ser similares y luego se observa que son equivalentes, la agrupación ha
sido exitosa, porque significa que la funcionalidad del sistema ha sido
modularizada adecuadamente. Por el contrario, si la agrupación de estos
escenarios similares, afecta diferentes componentes (no son equivalentes),
la arquitectura posiblemente debe ser corregida.
ATAM – Architecture Tradeoff Analysis Method
El Architecture Tradeoff Analysis Method (ATAM) obtiene su nombre no solo
porque nos dice cuan bien una arquitectura particular satisface las metas de
calidad, sino que también provee ideas de cómo esas metas de calidad
interactúan entre ellas, como realizan concesiones mutuas entre ellas.

Tener un método estructurado, permite hacer el análisis repetible y ayuda a

asegurar que las preguntas acerca de una arquitectura serán contestadas en
forma temprana, cuando es relativamente económico corregir problemas.

El ATAM también puede ser utilizado para analizar sistemas legados. Esta
necesidad nace cuando el sistema legado necesita ser modificado, integrado
con otro sistema, entre otras necesidades. Aplicar el ATAM incrementa el
entendimiento de los atributos de calidad del sistema legado.

Resumen de los pasos del ATAM

La parte principal del ATAM consiste de nueve pasos. Estos pasos se
dividen cuatro grupos:

 Presentación, donde la información es intercambiada.

 Investigación y análisis, donde se valoran los atributos claves de
calidad requeridos, uno a uno con las propuestas arquitectónicas.
 Pruebas, donde se revisan los resultados obtenidos contra las
necesidades relevantes de los stakeholders.
 Informes, donde se presentan los resultados del ATAM.

Presentación

1. Presentar el ATAM
El líder del equipo de evaluación describe el método a los participantes,
fija las expectativas y responde las preguntas que puedan surgir.

2. Presentar las pautas del negocio

Un representante del proyecto (por ejemplo, el director de proyecto o el
cliente del sistema) describe las metas del negocio que motivan el
esfuerzo de desarrollo y que se convertirán en las pautas primordiales
de la arquitectura (por ejemplo, alta disponibilidad o alta seguridad).

3. Presentar la arquitectura
El arquitecto describe la arquitectura, enfocándose en como esta sigue
las pautas del negocio.
Investigación y análisis

4. Identificar las propuestas arquitectónicas

Las propuestas arquitectónicas son identificadas por el arquitecto, pero
no son analizadas.

5. Generar el árbol de utilidad de los atributos de calidad

Los atributos de calidad que comprometen la utilidad del sistema
(performance, availability, entre otros) son obtenidos, especificados en
escenarios (con estímulos y respuestas) y priorizados.

6. Analizar las propuestas arquitectónicas

Basados en los escenarios de mayor prioridad identificados en el paso
5, las propuestas arquitectónicas que cumplen con estos escenarios,
son obtenidas y analizadas (por ejemplo, una propuesta arquitectónica
que logra una meta de performance, será objeto de un análisis de
performance).
Durante este paso los riesgos arquitectónicos, los no riesgos, los
sensitivity points y tradeoff points son identificados.

Pruebas

7. Lluvia de ideas y priorización de escenarios

Un gran conjunto de escenarios es obtenido por todos los stakeholders.
Este conjunto es priorizado mediante votación.

8. Analizar las propuestas arquitectónicas

En este paso se reitera las actividades del paso 6 utilizando el ranking
de escenarios del paso 7. Estos escenarios se consideran casos de
prueba para confirmar el análisis realizado hasta ahora. Este análisis
puede descubrir nuevas propuestas arquitectónicas, riesgos, no
riesgos, sensitivity points y tradeoff points, que son documentados.

Informes

9. Presentar los resultados

Basados en la información recogida durante el ATAM (propuestas,
escenarios, árbol de utilidad, riesgos, no riesgos, sensitivity points y
tradeoff points), el equipo de ATAM presenta los resultados a los
stakeholders.

A veces, se deben hacer modificaciones dinámicas al calendario para poder

acomodarse a la disponibilidad del personal o de la información
arquitectónica. A pesar que los pasos están numerados, sugiriendo
 linealidad, este no es un proceso en cascada estricto. De vez en cuando, un
evaluador podrá volver a pasos anteriores, saltar a un paso posterior, o
iterar entre pasos, según la necesidad. La importancia de los pasos esta
claramente delineada en las actividades involucradas en el ATAM, junto con
las salidas de estas actividades.

CONCLUSIONES

 La posibilidad de metodizar el proceso de diseño de un software les

permite, a diseñadores consagrados y potenciales, conocer enfoques que
pueden serles útiles en sus contextos. Esto no significa que esta propuesta
sea una fórmula inalterable sino que, al contrario, debe ser una guía
modificable y adaptable a las necesidades de sus usuarios, contenidos y
contexto.
 Los sistemas distribuidos abarcan una cantidad de aspectos considerables,
por lo cual su desarrollo implica mucha complejidad.
 Existen ciertos aspectos que requieren extremo cuidado al desarrollarse e
implantarse como el manejo de fallos, el control de la concurrencia, etc.
BIBLIOGRAFIA

http://babel.ls.fi.upm.es/~fred/sbc/arquitecturas_sw.pdf
http://www.ecured.cu/index.php/Arquitectura_de_software
http://www.ecured.cu/index.php/Arquitectura_de_software#Caracter.C3.ADsticas
http://faustovideos.blogspot.com/p/historia-cliente-servidor.html
http://www.fing.edu.uy/tecnoinf/mvd/cursos/ingsoft/material/teorico/is05-
ArquitecturaDeSoftware.pdf
http://www.fing.edu.uy/inco/cursos/tsi/TSI1/2010/teorico/01-Arquitectura-de-
software.pdf
http://es.slideshare.net/calderonperaza/disenando-sistemas-empleando-el-modelo-
de-capas-en-desarrollo-de-software
http://www.essi.upc.edu/~gomariz/index_archivos/IntroduccionSD-
EnricMartinez.pdf
http://www.monografias.com/trabajos16/sistemas-distribuidos/sistemas-
distribuidos.shtml#CARACT
https://radyel.wordpress.com/3/
http://es.slideshare.net/rogervillegas90/fundamentos-de-la-arquitectura-de-
software-30497462
http://es.slideshare.net/landeta_p/2-2-estilos-arquitectonicos
http://es.slideshare.net/bjjuarez/estilos-de-software