1. Universidad Nacional Experimental
de los Llanos Ocidentales Ezequiel Zamora
UNELLEZ- Barinas
Arquitectura del
software
Bachilleres:
21.168.736 Caro José
19.193.035 Díaz Nohely
Barinas, Enero 2014

2. Breve historia de la arquitectura de software: Sus inicios y fundamentos.
Aunque el término arquitectura de software, tal y como lo concebimos ahora, aparece en 1992 con
el trabajo de Perry y Wolf, sus antecedentes se remontan al menos hasta finales de la década de los
sesenta. En 1968, Dijkstra habla de una estructuración correcta de los sistemas de software, aunque
no la llama arquitectura como tal. Posteriormente, en 1969, P. I. Sharp, comentando las ideas de
Dijkstra, ya usa el término arquitectura de software al mencionar que quizá luego se hable de “la
escuela de arquitectura de software de Dijkstra”, y al mismo tiempo lamentar que la industria de ese
tiempo preste muy poca atención a ésta.
Durante la década de los setentas el concepto de arquitectura deambuló por el aire sin una semántica
clara y carente de una expresión pragmática. En esta misma década, el diseño estructurado dio pie a
la independencia entre el diseño y la implementación. Los trabajos de Parnas sobre técnicas de
modularización en decisiones de diseño y familias de programas, fueron, sin duda, aportaciones
esenciales y permanentes.
Rompiendo esquemas y acaparando la atención en la década de los ochentas, aparece el paradigma
de la orientación a objetos. En esta década aparecen dos trabajos importantes de Mary Shaw, que
retoman las abstracciones de alto nivel: “Técnicas de abstracción en lenguajes modernos de
programación” y “Los sistemas de gran escala requieren de abstracciones de alto nivel”.
Hacia finales de los ochenta y principios de los noventa, comienza a gestarse de manera más clara la
idea de que las aplicaciones tienen una morfología, una estructura. El trabajo de Perry y Wolf de
1992 es el punto de partida para lo que hoy conocemos como arquitectura de software. Por un lado,
son los primeros que proponen un modelo para la arquitectura de software; este modelo contempla a
la arquitectura formada por tres componentes: elementos, forma y razón. Los elementos pueden ser
de procesamiento, datos o conexión; la forma se define de acuerdo a las propiedades , y a las
relaciones entre los elementos; la razón se contempla en términos de restricciones del sistema, que
se derivan de los requerimientos del sistema.
Perry y Wolf profetizaron que: “la década de los noventas, creemos, será la década de la
arquitectura de software”, lo cual se convirtió en realidad. A lo largo de esa década, salieron a la luz
varios trabajos con propuestas relevantes, entre ellas, la programación basada en componentes, el
surgimiento de los patrones y estilos, el modelo de 4+1 vistas, y lenguajes de descripción de
arquitecturas (ADL) entre otras.
En la segunda mitad de los noventa aparecen los primeros libros de texto dedicados a la arquitectura
de software. El año 2000 cierra esta década con dos trabajos clave: el modelo REST propuesto en la
tesis de Roy Fielding que pone la atención en Internet y los modelos orientados a servicios; y el
trabajo de la IEEE, que genera una versión definitiva de la recomendación IEEE std 1471-2000.

3. También en este año se abren nuevas perspectivas para la arquitectura de software, aparecen las
estrategias orientadas a líneas de productos y se procura insertar la arquitectura de software dentro
del ciclo de vida, obligando a redefinir las metodologías referentes a él en términos de arquitectura.
Actualmente hay una cierta efervescencia alrededor de desarrollos centrados en arquitectura,
métodos de análisis y diseño de arquitecturas (dentro del ciclo de vida), análisis de arquitecturas de
software basados en escenarios, modelos de evaluación de arquitecturas de software y modelos
orientados por la arquitectura entre algunos otros tópicos.
Definición de los conceptos fundamentales:
Estilos: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.
Sucintamente descriptos, los estilos conjugan elementos (o “componentes”, como se los llama
aquí), conectores, configuraciones y restricciones. Al estipular los conectores como elemento de
juicio de primera clase, el concepto de estilo, incidentalmente, se sitúa en un orden de discurso y de
método que el modelado orientado a objetos en general y UML en particular no cubren
satisfactoriamente. La descripción de un estilo se puede formular en lenguaje natural o en
diagramas, pero lo mejor es hacerlo en un lenguaje de descripción arquitectónica o en lenguajes
formales de especificación.
A diferencia de los patrones de diseños, que son centenares, los estilos se ordenan en seis
o siete clases fundamentales y unos veinte ejemplares, como máximo. Es digno de
señalarse el empeño por subsumir todas las formas existentes de aplicaciones en un
conjunto de dimensiones tan modestas. Las arquitecturas complejas o compuestas
resultan del agregado o la composición de estilos más básicos. Algunos estilos típicos son
las arquitecturas basadas en flujo de datos, las peer-to-peer, las de invocación implícita,
las jerárquicas, las centradas en datos o las de intérprete-máquina virtual.
Lenguajes de descripción de arquitecturas: 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.
Los ADL son bien conocidos en los estudios universitarios de AS, pero muy pocos
arquitectos de industria parecen conocerlos y son menos aún quienes los utilizan como
instrumento en el diseño arquitectónico de sus proyectos. Hay unos veinte ADL de

4. primera magnitud y tal vez unos cuarenta o cincuenta propuestos en ponencias que no
han resistido el paso del tiempo o que no han encontrado su camino en el mercado. Se
han analizado esos lenguajes descriptivos en un documento aparte, en el cual se invita
asimismo a su discusión.
Frameworks y Vistas:Los frameworksson una estructura conceptual y tecnológica de soporte
definido, normalmente con artefactos o módulos de software concretos, que puede servir de base
para la organización y desarrollo de software. Típicamente, puede incluir soporte de programas,
bibliotecas, y un lenguaje interpretado, entre otras herramientas, para así ayudar a desarrollar y unir
los diferentes componentes de un proyecto.
Representa una arquitectura de software que modela las relaciones generales de las entidades del
dominio, y provee una estructura y una especial metodología de trabajo, la cual extiende o utiliza
las aplicaciones del dominio.
Las vistas, Al final, a este miembro de la familia le corresponde dibujar, o expresar la última forma
de los datos: la interfaz gráfica que interactúa con el usuario final del programa (GUI). Después de
todo, a este miembro le toca evidenciar la información obtenida hasta hacerla llegar al controlador.
Solo (e inicialmente), nos espera demostrar la información.
Procesos y metodología:
Proceso;.Hace alusión a los marcos de trabajo las cuales son representados por vistas. Por ejemplo: las
vistas estáticas se corresponden con las perspectivas particulares de los diferentes participantes y las
vistas dinámicas tienen que ver con etapas del proceso, el ciclo de vida o metodología
caracterizadas en requerimientos, análisis, diseño, implementación e integración.
Metodología.Hace referencia a un frameworkque es usado para estructurar, planear y controlar el proceso
de desarrollo en sistemas de información: RUP, RAD, RSD, ARIS, PERA, CIMOSA, GRAI,
GERAM, CMM. En el campo de a AS la dominante es el Modelo de Madurez de la Capacidad
(CMM).
Abstraccion: La idea de abstracción forma parte de lo que acaso sea la pieza conceptual más
importante de la AS, el concepto de estilo; un estilo se identifica a grandes rasgos o ,como se dice
habitualmente, en un estilo “menos es más”. La misma idea prevalece en todos los conceptos y
procedimientos que se consideran arquitectónicos. Para Len Bass,
Paul Clements y Rick Kazman [BCK98], si una decisión debe posponerse hasta el momento de
tratar las cosas a un bajo nivel, no se trata de una decisión de arquitectura.
Clements y Northrop [CN96] sostienen que el trabajo de Garlan y Shaw sobre los estilos
arquitectónicos nos enseña que aunque los programas pueden combinarse de maneras prácticamente
infinitas, hay mucho que ganar si nos restringimos a un conjunto relativamente pequeño de
elecciones cuando se trata de cooperación e interacción. Las ventajas incluyen mejor reutilización,
mejores análisis, menor tiempo se selección y mayor interoperabilidad. “Menos es más” figura, de

5. hecho, en el título y en los contenidos de numerosos papers de la profesión [MB02] [CN96].
Conceptos como el de estilo, o marcos como MSF, revelan su naturaleza arquitectónica en su
abstracción y en su generalidad.
Escenarios: Esta es una noción arquitectónica importante y se encuentra en la base de muchos de los
métodos de diseño y desarrollo basados en arquitectura, como ALMA, SAAM y ATAM.
Hay que ser precavidos y advertir desde el comienzo que lo que habitualmente se traduce como
“escenario” no es estrictamente lo que en lengua castellana se designa como tal; la traducción
correcta debería ser más bien “guión” o “libreto”. La traducción literal del término no hace más que
aportar confusión. Desde Kruchten en adelante, se reconoce que los escenarios se dividen en dos
categorías: casos de uso (secuencias de responsabilidades) y casos de cambio (modificaciones
propuestas al sistema). Los escenarios han sido básicamente técnicas que se implementan en la
elicitación de los requerimientos, particularmente en relación a los operadores de sistemas.
Típicamente, la técnica comienza instrumentando sesiones de brainstorming. También se han
utilizado escenarios como método para comparar alternativas de diseño. Los escenarios describen
una utilización anticipada o deseada del sistema, y típicamente se expresan en una frase; Kazman,
Abowd, Bass y Clements proponen también llamarlos viñetas
Campos de la arquitectura del 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, por lo que conviene aunque más no sea enumerar algunos de sus campos y
sus focos. Una semblanza semejante (de la que aquí se proporciona sólo un rudimento)
dudosamente debería ser estática. 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. Pero esa sincronicidad estructuralista no pudo sostenerse. Por el contrario, daría la
impresión que, a medida que pasa el tiempo, la
AS tiende a redefinir todos y cada uno de los aspectos de la disciplina madre, la ingeniería de
software, sólo que a un mayor nivel de abstracción y agregando una nueva dimensión reflexiva en
lo que concierne a la fundamentación formal del proceso.
Hay unas pocas caracterizaciones (y mucha actividad de copiado y pegado) en torno de las áreas
que componen el territorio. David Garlan y Dewayne Perry, en su introducción al volumen de abril
de 1995 de IEEE Transactionson Software Engineering dedicado a la
AS, en el cual se delinean las áreas de investigación más promisorias, enumeran las siguientes:
Lenguajes de descripción de arquitecturas
Fundamentos formales de la AS (bases matemáticas, caracterizaciones formales de propiedades
extra-funcionales tales como mantenibilidad, teorías de la interconexión, etcétera).
Técnicas de análisis arquitectónicas
Métodos de desarrollo basados en arquitectura
Recuperación y reutilización de arquitectura
Codificación y guía arquitectónica

6. Herramientas y ambientes de diseño arquitectónico
Estudios de casos
Modalidades y tendencias en la arquitectura de software:
Arquitectura como etapa de ingeniería y diseño orientada a objetos: Esta perspectiva concierne a
decisiones sobre organización, selección de elementos estructurales, comportamiento, composición
y estilo arquitectónicos susceptibles de ser descritas a través de las cinco vistas clásicas del modelo
4+1 de Kruchten (UML y Rational). Rumbaugh, Jacobson, Book, Larman, Kruchten, entre otros..
Arquitectura estructural: Basada en un modelo estático de estilos, ADLs y vistas. La representan los
académicos de la Universidad Carnegie Mellon de Pittsbugh: Shaw, Clements, Garlan, Allen,
Abowd, Ockerbloom. En ella se reconocen tres modalidades en cuanto a formalización:
–Descripción verbales o diagramas de caja (los más informales)
–Los que se sirven de ADLs (intermedios), y
–Los que utilizan lenguajes formales de especificación como CHAM y Z (los más exigentes)
Estructuralismo arquitectónico radical: Formada por un grupo europeo con una actitud
confrontativa con UML. Tiene al menos dos tendencias: Una excluye el modelado OO para AS y
otra integra metamodelos y estereotipos correctivos de UML
Arquitectura basada en patrones: No está rígidamente vinculada con el modelado UML, ni a las
metodologías de CMM. El diseño consiste en identificar y articular patrones preexistentes, que se
definen en forma parecida a los estilos de arquitectura.
Arquitectura procesual: Intenta establecer modelos de ciclo de vida y técnicas de elicitación de
requerimientos, brainstorming, diseño, análisis, selección de alternativas, validación, comparación,
estimación de calidad y justificación económica específicas para la arquitectura de software. La
documentación se encuentra en SEI, pero no se mezcla con CMM.
Arquitectura basada en escenarios:Es la corriente más nueva. Se trata de un movimiento
predominantemente europeo, con centro en Holanda. Recupera el nexo de la AS con los
requerimientos y la funcionalidad del sistema, el cual es, ocasionalmente borroso en la arquitectura
estructural clásica. En esta corriente suele utilizarse diagramas de casos de uso UML como
herramienta informal u ocasional, dado que los casos de uso son uno de los escenarios posibles. Los
casos de uso no están orientados a objeto.
Diferencias entre arquitectura y diseño:
Literalmente se dice que es lo mismo, pero yendo más profundo el diseño es una parte de la
arquitectura, por eso se dice que ambas tienen el mismo propósito, la arquitectura de software en la
estructura del sistema y en las interconexiones se diferencia del diseño, en otras palabras el diseño
son todos los componentes en detalle, mientras que la arquitectura muestra como estos componentes
se interconectan entre si formando su estructura.

7. La arquitectura se encarga de: Selección de tecnologías Requerimientos no funcionales Manejo de
riesgos, etc. y el Diseño se encarga de: Los requerimientos funcionales Diseño detallado de
componentes, etc.
Repositorios y relevancia de la arquitectura del software:
Un repositorio, depósito o archivo es un sitio centralizado donde se almacena y mantiene
información digital, habitualmente bases de datos o archivos informáticos
Existen unos cuantos repositorios de información arquitectónica, cuyas direcciones son más o
menos permanentes. El más importante hoy en día parece ser el del Software EngineeringInstitute
en la Universidad Carnegie Mellon de Pittsburgh, Pennsylvan
(http://www.sei.cmu.edu/ata/ata_init.html). El sitio del SEI incluye abundante literatura académica
y todas las especificaciones o recomendaciones metodológicas.
Las páginas de cabecera de la estrategia de arquitectura de Microsoft se hallan en
http://msdn.microsoft.com/architecture/. Las páginas de Patterns&Practices están en
http://www.microsoft.com/resources/practices/completelist.asp. La estrategia arquitectónica misma
se encuentra delineada en un documento de Michael Platt en
http://msdn.microsoft.com/architecture/overview/default.aspx?pull=/library/enus/
dnea/html/eaarchover.asp.
Numerosas editoriales, universidades, consorcios y centros de investigación incluyen
vínculos ligados a la AS. Muy seguramente los lectores podrán suministrar otros sitios de
referencia importantes.
Las relevancia : Aunque todavía no se ha constituido un repositorio uniformizado de estudios de
casos en base al cual se pueda extraer una conclusión responsable, la AS ha resultado instrumental
en un número respetable de escenarios reduciendo costos, evitando errores, encontrando fallas,
implementando sistemas de misión crítica. Cada uno de los documentos que describen lenguajes de
descripción arquitectónica, por ejemplo, subraya su utilización exitosa en proyectos de gran
envergadura requeridos por organizaciones de gobierno o por grandes empresas. Aún cuando aquí y
allá se señalen dificultades ocasionales, nadie duda de la necesidad de una visión arquitectónica.
Las virtudes de la arquitectura del software son:
Comunicación mutua
Decisiones tempranas
Restricciones constructivas
Reutilización, o abstracción transferible de un sistema.
Evolución
Análisis
Administración
Definiciones de estilo
Los estilos sólo se manifiestan en arquitectura teórica descriptiva de alto nivel deabstracción; los
patrones, por todas partes. Los partidarios de los estilos se definen desde el inicio como arquitectos;

8. los que se agrupan en torno de los patrones se confunden a veces con ingenieros y diseñadores,
cuando no con programadores con conciencia sistemática o lo que alguna vez se llamó analistas de
software. El primer grupo ha abundado en taxonomías internas de los estilos y en reflexión teórica;
el segundo se ha mantenido, en general, refractario al impulso taxonómico, llevado por una actitud
resueltamente empírica. Ambos, con mayor o menor plenitud y autoconciencia, participan del
campo abarcativo de la arquitectura de software. Los estilos se encuentran en el centro de la
arquitectura y constituyen buena parte de su sustancia. Los patrones de arquitectura están
claramente dentro de la disciplina arquitectónica, solapándose con los estilos, mientras que los
patrones de diseño se encuentran más bien en la periferia, si es
que no decididamente afuera.
Según esa definición, estilos y arquitectura nacen en el mismo momento. Con una sola excepción
(documentada en el párrafo siguiente) no he podido encontrar referencias a la palabra estilos
anteriores a 1992. Todavía en julio de ese año Robert Allen y David Garlan [AG92] de la
Universidad de Carnegie Mellon se refieren a “paradigmas de arquitectura” y “estructuras de
sistemas”, mencionando entre ellos lo que luego sería el familiar estilo tubería-filtros, los modelos
de pizarra y los de flujo de datos. Con nombres idénticos, esos paradigmas pasarían a llamarse
estilos un mes más tarde en todos los textos de la misma escuela primero y en toda la arquitectura
de software después.
Inventario y descripción de los estilos arquitectónicos:
Los estilos que habrán de describirse a continuación no aspiran a ser todos los que se han propuesto,
sino apenas los más representativos y vigentes. De más está decir que, como se ha visto, la
agrupación de estilos y sub-estilos es susceptible de realizarse de múltiples formas, conforme a los
criterios que se apliquen en la constitución de los ejemplares. No se ha de rendir cuentas aquí por la
congruencia de la clasificación (nadie ha hecho lo propio con las suyas), porque cada vez que se la
ha revisado en modo outline, se cedió a la tentación de cambiar su estructura, la cual seguirá
sufriendo metamorfosis después de despachado el artículo. Se podrá apreciar que, en consonancia
con los usos de la especialidad, la caracterización de los estilos no constituye un reflejo
pormenorizado de los detalles de sus estructuras, sino una visión deliberadamente sucinta y genérica
que destaca sus valores esenciales y sus rasgos distintivos. Entre acumular pormenores que podrían
recabarse en otras fuentes y mantener el caudal descriptivo de cada estilo en una magnitud que
facilite su comparación rápida con los demás se ha escogido, Saussureanamente, lo segundo.
En cuanto a las formas de representación esquemática, se ha optado por reproducir el estilo gráfico
característico de la literatura principal del género, el cual es deliberadamente informal y
minimalista, en lugar de aplicar una notación formal o máselaborada. La notación se establecerá
entonces en términos de lo que Shaw y Clementsllaman “boxology” [SC96]. Huelga decir que la
descripción de los estilos puede hacerse también en términos de lenguajes descriptivos de
arquitectura (ADLs) y las respectivas notaciones de las herramientas que se asocian con ellos, según
puede verse en un estudio separado [Rey04b]. Resta anticipar que algunas especies de software
conspicuas en la práctica no aparecen en los catálogos usuales de estilo. La ausencia más notoria
concierne a los sistemas de workflow, que seguramente heredan el prejuicio ancestral de los
ingenieros y arquitectos más refinados en contra de los diagramas de flujo y las abstracciones
procesuales. Fred Brooks, por ejemplo, considera el diagrama de flujo como una abstracción muy
pobre de la estructura de un sistema [Bro75] [Bro86].
Estilos y patrones de arquitectura y diseño:

9. La dinámica incontenible de la producción de patrones en la práctica de la arquitectura desoftware,
su carácter entusiasta, cuando no militante, y la profusión de sus manifestaciones han atenuado la
idea de que los patrones de diseño constituyen sólo uno de los paradigmas, marcos o formas del
diseño arquitectónico, cada uno de los cuales posee una historia y una fundamentación distinta, y
presenta, como todas las cosas en este terreno, sus sesgos, sus beneficios y sus limitaciones. Todo el
mundo acepta que existen diversas clases de patrones: de análisis, de arquitectura (divididos en
progresivamente estructurales, sistemas distribuidos, sistemas interactivos, sistemas adaptables), de
diseño (conductuales, creacionales, estructurales), de organización o proceso, de programación y los
llamados idiomas, entre otros. Cada autor que escribe sobre el asunto agrega una clase diferente, y
los estándares en vigencia no hacen ningún esfuerzo para poner un límite a la proliferación de
variedades y ejemplares. Como sea, concentrémonos inicialmente en los patrones de diseño.
Un patrón de diseño, obviamente, debe encajar por un lado con otros tipos de patrones imaginables
y por el otro con la teoría, la práctica y los marcos que en general rigen el diseño. ¿Cuáles son las
grandes estrategias de diseño, si puede saberse? Una vez más, cuando llega el momento de disponer
en un mapa las estrategias, los marcos de referencia o los paradigmas de diseño disponibles se
encuentra multitud de propuestas clasificatorias que a veces no coinciden siquiera en la
identificación de la disciplina en que se formulan. De todas maneras, estimo que es razonable
pensar que las estrategias mayores de diseño pueden subsumirse en un conjunto relativamente
manejable de cuatro o cinco tipos, uno de los cuales es, precisamente, el diseño orientado por
patrones. Estas estrategias no necesariamente son excluyentes y antagónicas, pero se encuentran
bastante bien delimitadas en la literatura usual [Tek00].