INTRODUCCION

Este documento constituye una introducción sumaria a la Arquitectura de Software, con el propósito puntual de brindar
una visión de conjunto lo más estructurada posible para luego establecer el papel de esta disciplina emergente en
relación con la estrategia arquitectónica de Microsoft, sus herramientas y sus patrones de diseño.

LISTA DE REFERENCIA

Carlos B. Reynoso. (2004). Introducción a la Arquitectura de Software. Universidad de Buenos Aires: Versión 1.0.
Recuperado de https://postparaprogramadores.com/libro-sobre-arquitectura-de-softwares/ 28 de Marzo 2018.

TABLA DE CONTENIDO

1. Historia de la Arquitectura de Software

CONCLUSIONES

Esta presentación de Arquitectura de Software es un claro indicador del hecho de que la arquitectura de software no ha
sabido comunicar su propia función mediadora entre el requerimiento por un lado y el diseño y la implementación por
el otro. La presente estudio de historia que se le ha hecho a la Arquitectura de Software ha procurado describir
herramientas disponibles para el desempeño de esa función. La idea no ha sido examinar productos concretos de estas
Arquitecturas, sino referir problemáticas formales involucradas en esa clase de representación.
 1. Historia de la Arquitectura de Software

Todavía no se ha escrito una historia aceptable de la AS. Desde que Mary Shaw o David Garlan reseñaran escuetamente
la prehistoria de la especialidad a principios de los 90, los mismos párrafos han sido reutilizados una y otra vez en la
literatura, sin mayor exploración de las fuentes referidas en la reseña primaria y con prisa por ir al grano, que
usualmente no es de carácter histórico.

Situar las inflexiones de la breve historia de la AS en un contexto temporal, asimismo, ayudará a comprender mejor
cuáles son sus contribuciones perdurables y cuáles sus manifestaciones contingentes al espíritu de los tiempos y a las
modas tecnológicas que se han ido sucediendo. Si bien la AS acostumbra remontar sus antecedentes al menos hasta la
década de 1960, su historia no ha sido tan continua como la del campo más amplio en el que se inscribe, la ingeniería de
software [Pfl02] [Pre01]. Después de las tempranas inspiraciones del legendario Edsger Dijkstra, de David Parnas y de
Fred Brooks, la AS quedó en estado de vida latente durante unos cuantos años, hasta comenzar su expansión explosiva
con los manifiestos de Dewayne Perry de AT&T Bell Laboratories de New Jersey y Alexander Wolf de la Universidad de
Colorado [PW92]. Puede decirse que Perry y Wolf fundaron la disciplina, y su llamamiento fue respondido en primera
instancia por los miembros de lo que podría llamarse la escuela estructuralista de Carnegie Mellon: David Garlan, Mary
Shaw, Paul Clements, Robert Allen.

Cada vez que se narra la historia de la arquitectura de software, se reconoce que en un principio, hacia 1968, Edsger
Dijkstra, de la Universidad Tecnológica de Eindhoven en Holanda y Premio Turing 1972, propuso que se establezca una
estructuración correcta de los sistemas de software antes de lanzarse a programar, escribiendo código de cualquier
manera [Dij68a]. Dijkstra, quien sostenía que las ciencias de la computación eran una rama aplicada de las matemáticas
y sugería seguir pasos formales para descomponer problemas mayores, fue uno de los introductores de la noción de
sistemas operativos organizados en capas que se comunican sólo con las capas adyacentes y que se superponen “como
capas de cebolla”. Inventó o ayudó a precisar además docenas de conceptos: el algoritmo del camino más corto, los
stacks, los vectores, los semáforos, los abrazos mortales. De sus ensayos arranca la tradición de hacer referencia a
“niveles de abstracción” que ha sido tan común en la arquitectura subsiguiente. Aunque Dijkstra no utiliza el término
arquitectura para describir el diseño conceptual del software, sus conceptos sientan las bases para lo que luego
expresarían Niklaus Wirth [Wir71] como stepwise refinement y DeRemer y Kron [DK76] como programming-in-the large
(o programación en grande), ideas que poco a poco irían decantando entre los ingenieros primero y los arquitectos
después.

En la década de 1980 se perfeccionaron las técnicas descriptivas y las notaciones formales, permitiéndonos razonar
mejor sobre los sistemas de software. Para la caracterización de lo que sucederá en la década siguiente ellos formulan
esta otra frase que ha quedado inscripta en la historia mayor de la especialidad: La década de 1990, creemos, será la
década de la arquitectura de software. Usamos el término “arquitectura” en contraste con “diseño”, para evocar
nociones de codificación, de abstracción, de estándares, de entrenamiento formal (de los arquitectos de software) y de
estilo. … Es tiempo de re-examinar el papel de la arquitectura de software en el contexto más amplio del proceso de
software y de su administración, así como señalar las nuevas técnicas que han sido adoptadas.

1.1. Conceptos fundamentales

“Más allá de que hoy existan numerosos conceptos en el plano detallado de las técnicas y metodologías, la AS se articula
alrededor de unos pocos conceptos y principios esenciales y unas pocas herramientas características.” (Carlos Billy
Reynoso, 2004, P. 245)
 1.2. Campos de la arquitectura de software

La AS es hoy en día un conjunto inmenso y heterogéneo de áreas de investigación teórica y de formulación práctica. La
AS comenzó siendo una abstracción descriptiva puntual que en los primeros años no investigó de manera sistemática ni
las relaciones que la vinculaban con los requerimientos previos, ni los pasos metodológicos a dar luego para comenzar a
componer el diseño.

Paul Clements [Cle96b] define cinco temas fundamentales en torno de los cuales se agrupa la disciplina:

 Diseño o selección de la arquitectura: Cómo crear o seleccionar una arquitectura en base de requerimientos
funcionales, de performance o de calidad.
 Representación de la arquitectura: Cómo comunicar una arquitectura. Este problema se ha manifestado como
el problema de la representación de arquitecturas utilizando recursos lingüísticos, pero el problema también
incluye la selección del conjunto de información a ser comunicada.
 Evaluación y análisis de la arquitectura: Cómo analizar una arquitectura para predecir cualidades del sistema en
que se manifiesta. Un problema semejante es cómo comparar y escoger entre diversas arquitecturas en
competencia.
 Desarrollo y evolución basados en arquitectura: Cómo construir y mantener un sistema dada una
representación de la cual se cree que es la arquitectura que resolverá el problema correspondiente.
 Recuperación de la arquitectura: Cómo hacer que un sistema legacy evolucione cuando los cambios afectan su
estructura; para los sistemas de los que se carezca de documentación confiable, esto involucra primero una
“arqueología arquitectónica” que extraiga su arquitectura

2. Estilos de Arquitectura

En el texto fundacional de la AS, Perry y Wolf establecen el razonamiento sobre estilos de arquitectura como uno de los
aspectos fundamentales de la disciplina. Un estilo es un concepto descriptivo que define una forma de articulación u
organización arquitectónica. El conjunto de los estilos cataloga las formas básicas posibles de estructuras de software,
mientras que las formas complejas se articulan mediante composición de los estilos fundamentales.

3. Lenguajes de descripción arquitectónica

Los lenguajes de descripción de arquitecturas, o ADLs, ocupan una parte importante del trabajo arquitectónico desde la
fundación de la disciplina. Se trata de un conjunto de propuestas de variado nivel de rigurosidad, casi todas ellas de
extracción académica, que fueron surgiendo desde comienzos de la década de 1990 hasta la actualidad, más o menos en
contemporaneidad con el proyecto de unificación de los lenguajes de modelado bajo la forma de UML. Los ADL difiere
sustancialmente de UML, que al menos en su versión 1.x se estima inadecuado en su capacidad para expresar
conectores en particular y en su modelo semántico en general para las clases de descripción y análisis que se requieren.
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.

4. ¿Arquitectura n-Tier o Arquitectura n-Layer?

Al parecer existe una confusión respecto al término aplicación n-capas cuando este se lleva al idioma español. El
problema principal es que en inglés se manejan dos conceptos a nivel de arquitectura:
 Aplicaciones n-Tier
 Aplicaciones n-Layer
Una arquitectura n-Tier se refiere a la distribución física de las capas, es decir donde corre el código y los procesos. Una
arquitectura n-Layer se refiere a la distribución lógica de las capas, es decir, como esta estructurado el código.

Una arquitectura n-Layer define simplemente como se organiza el código. Normalmente incluye una capa de
presentación, una capa de negocios, una capa de acceso a datos, una capa de entidades de negocio y una capa de datos
– repositorio de datos. El hecho de que se dividan las capas para organizar el código, no significa que las capas
obligatoriamente deban corren en diferentes máquinas o que deben estrictamente correr en una sola máquina o en un
único proceso.

La siguiente figura detalla una arquitectura n-Layer básica.

Como podemos ver en la figura, en una arquitectura n-layer las capas solamente interactúan con sus capas adyacentes
lo que permite abstraer funcionalidades de las capas superiores e inferiores. Por ejemplo, la capa de presentación no se
da cuenta que tipo de base de datos o que repositorio de datos se utiliza por que esta solamente se comunica con la
capa de negocios, y el repositorio de datos no se da cuenta en donde se esta utilizando o desplegando la información ya
que este interactúa con la capa de acceso a datos.

5. Arquitectura de 3 niveles (3-layer)

En una aplicación de 3 niveles, la funcionalidad se divide en 3 niveles:

Cliente

Servidor

Datos
Es importante destacar que el nivel del cliente se asigna a un departamento con tres equipos de desarrolladores front-
end:

JavaScript / HTML / CSS para aplicaciones web

Java para aplicaciones de Android

Objective C / Swift para aplicaciones de iOS

En la arquitectura de 3 niveles, los desarrolladores de aplicaciones para el usuario no ejecutan ningún código del lado del
servidor.

Los datos fluyen en secuencia de Cliente a Servidor a Base de datos y viceversa.

Hay algunas debilidades importantes con la arquitectura de 3 niveles. El desarrollo de la interfaz de usuario se mueve
lentamente a medida que los desarrolladores del lado del cliente tienen que detenerse y pedir a los desarrolladores del
lado del servidor que creen las API y las consultas de acceso a datos requeridas. Los desarrolladores del lado del servidor
se distraen del trabajo importante de la plataforma mientras que actualizan el código del lado del servidor para apoyar
el desarrollo del lado del cliente.

Es importante destacar que la arquitectura de 3 niveles se presta a la creación de aplicaciones monolíticas del lado del
servidor.