Estrategias para la Definición de una Técnica de

Modelado para Arquitecturas de Referencia

Javier Pérez Villamizar1 y Juan Bernardo Quintero2

1
Universidad de Antioquia. Medellín, Colombia
javierperez@udea.edu.co
2
ABC-Flex Ltda. – Universidad EAFIT. Medellín, Colombia
jquinte1@eafit.edu.co

Resumen. Una arquitectura de referencia proporciona una plantilla de solución

probada para la arquitectura de software en un dominio particular, su utilización
posibilita a las empresas que desarrollan proyectos de software potenciar el
reuso de alto nivel desde etapas tempranas del proceso. La construcción de
modelos que representen total o parcialmente la arquitectura de referencia,
facilitaría su comprensión y potenciaría su difusión en los equipos de trabajo de
las empresas, aumentando la mantenibilidad de los productos de software que
se adhieran a dicha arquitectura. Este artículo presenta un marco de referencia
para optar por una de las técnicas que se puede llegar a utilizar para modelar
una arquitectura de referencia.

Palabras claves: Arquitectura de Software, Arquitectura de Referencia,

Desarrollo de Software Dirigido por Modelos (MDSD).

1 Introducción

Para iniciar un trabajo de esta índole es importante precisar las definiciones de los
principales conceptos implicados, como: arquitectura de software, arquitectura de
referencia, arquitectura de dominio y arquitectura generativa. Adicionalmente, es
fundamental aclarar la relación de estos términos con otros que suelen usarse en los
mismos contextos como Arquitectura Destino y Línea base de la Arquitectura.
 Arquitectura de software: Según Clements [1] se refiere a grandes rasgos, a una
vista del sistema que incluye los componentes principales del mismo, la conducta
de esos componentes según se le percibe desde el resto del sistema y las formas en
que los componentes interactúan y se coordinan para alcanzar la misión del
sistema.
Según la IEEE [2] una arquitectura de software es la organización fundamental
de un sistema encarnada en sus componentes, las relaciones entre ellos y el
ambiente y los principios que orientan su diseño y evolución.
Según Kruchten [3] la arquitectura de software tiene que ver con el diseño y la
implementación de estructuras de software de alto nivel. Es el resultado de
ensamblar un cierto número de elementos arquitectónicos de forma adecuada para
satisfacer la mayor funcionalidad y requerimientos de desempeño de un sistema,
2

así como requerimientos no funcionales, como la confiabilidad, escalabilidad,

portabilidad y disponibilidad.
 Arquitectura de referencia: Proporciona una plantilla de solución probada para la
arquitectura en un dominio particular, a la par que define un vocabulario común
con el que se puede discutir las detalles de implementación para un producto de
software. La arquitectura de referencia se ocupa de los problemas comúnmente
encontrados en los proyectos de software como la escalabilidad, la fiabilidad y la
seguridad.
La propuesta realizada en una tecnología específica como por ejemplo Java EE,
es una arquitectura de referencia por capas que ofrece una plantilla de solución
para muchos sistemas empresariales desarrollados en Java.
 Arquitectura de dominio: En la propuesta de MDSD [4] se precisa las
arquitecturas de referencia a partir del concepto de arquitectura de dominio que se
define como la agregación de tres conceptos: una Plataforma, un Lenguaje
Especifico de Dominio y sus correspondientes Transformaciones. Esta precisión
que se le da al concepto de arquitectura resulta de mucha utilidad para este trabajo,
por tal motivo esta definición se trabajará más ampliamente en este artículo.
 Arquitectura generativa: Es la especialización de una arquitectura de domino
dentro del contexto de Desarrollo de Software Dirigido por Modelos Centrado en
la Arquitectura (AC- MDSD) [4].
 Línea base de la arquitectura: El conjunto de los productos que retratan el estado
actual de la empresa, sus prácticas comerciales, y su infraestructura técnica,
comúnmente se refiere al ser “as is” de la arquitectura.
 Arquitectura destino: El conjunto de los productos que retratan el futuro o estado
final de la empresa, en general captura el pensamiento estratégico de la
organización y sus planes, comúnmente se refiere al deber ser “to be” de la
arquitectura.
Más que centrarse en la arquitectura como tal, este artículo tiene como propósito
enfocar su atención en las técnicas para el modelado de una arquitectura de referencia
de desarrollo de software, buscando apoyar a las empresas en la definición de la mejor
estrategia para modelarla, para tal propósito se organizó de la siguiente manera:
primero se muestra la importancia de los modelos en el proceso de desarrollo y en la
arquitectura de software en el capítulo 2, luego se presentan las perspectivas para la
definición de arquitecturas de referencia en el capítulo 3, posteriormente se definen
las técnicas para el modelado de arquitecturas de referencia en el capítulo 4, la
selección de una técnica de modelado de una arquitectura de referencia es tratada en
el capítulo 5, y finalmente se muestran las conclusiones y trabajos futuros en el
capítulo 6.

2 La importancia de los modelos en el proceso de desarrollo y en

la arquitectura de software

Los modelos cada vez toman más relevancia en el proceso de desarrollo de software,
según Bézivin [5] la construcción de software ha evolucionado de plantear que “todo
 3

es un objeto” a finales del siglo pasado, a proponer que “todo es un modelo” a

comienzos de este siglo.
Para definir los enfoques de modelado, se plantea un espectro de modelado en el
que se ilustran los estados por los que pasa una empresa o persona en un proceso de
adopción de un paradigma dirigido por modelos [6]:

Tabla 1. Espectro de modelado, extraído de [6]

Nombre
1 Solo código
2 Visualización de código
3 Ingeniería de ida y vuelta
4 Centrado en los modelos
5 Solo modelos
Descripción
Se desconocen los modelos
El código es el modelo
El código y el modelo coexisten
El modelo es el código
El código es invisible

Si visualizamos esta propuesta de clasificación a la luz de la curva de adopción

tecnológica o ciclo de vida de la adopción de tecnología [7], sobreponiendo cada
espectro dentro de cada uno de los grupos que se distinguen en el proceso de
adopción: relegados, mayoría tardía, mayoría temprana, adoptadores tempranos e
innovadores, podemos observar claramente el fenómeno que se viene presentando en
el desarrollo de software con la adopción de paradigmas de desarrollo basados en
modelos. Para ilustrar esta situación se presenta la figura 1.

Fig. 1. Fusión del espectro de modelos y de la curva de adopción tecnológica, adaptado de [6],
[7] y [8].

El reto lo constituye “cruzar el abismo” [8] (“Cross the Chasm”), para pasar de
estar en la mayoría temprana, a ser un innovador. Sin embargo cualquiera que sea el
espectro o grupo en el que nos encontremos en un momento determinado, el paso al
siguiente se dará solo a través de la adopción de técnicas de modelado y herramientas
que apoyen su integración dentro del proceso de desarrollo de software. Si los
4

modelos se presentan de tanta utilidad en la construcción de software, surge entonces

un interrogante: ¿Por qué no modelar la arquitectura de referencia?
“Una arquitectura de referencia es un recurso que contiene un conjunto coherente
de mejores prácticas arquitectónicas para su uso por todos los equipos de una
organización” [9]. Por tal motivo el modelo de una arquitectura de referencia podría
tener un número considerable de diagramas, por ejemplo plantillas para la
construcción de las diversas vistas de las propuestas arquitectónicas, como lo ilustra la
tabla 2 de marcos de referencia arquitectónicos.

Tabla 2. Marcos de referencia arquitectónicos, adaptado de [10]

Propuesta de Agrupación de
Vistas propuestas
arquitectura componentes en
Zachman Niveles Scope, Empresa, Sistema lógico, Tecnología, Representación,
Funcionamiento
TOGAF Arquitecturas Negocios, Datos, Aplicación, Tecnología
4+1 Vistas Diseño, Proceso, Implementación , Despliegue, Casos de uso
POSA Vistas Lógica, Proceso, Física, Desarrollo
Microsoft Vistas Lógica, Conceptual, Física

Teniendo en cuenta el volumen de elementos que se pueden modelar en una

arquitectura de referencia, nos centraremos en los que mayor potencial de reuso
ofrecen en etapas tempranas del proceso de desarrollo. En los proyectos de software,
las vistas físicas y de negocio suelen ser responsabilidad de un reducido grupo de
arquitectos de infraestructura o analistas de negocio respectivamente, por otro lado las
vistas lógicas suelen involucrar un grupo de desarrollo que de acuerdo con el tamaño
del proyecto podría ser muy numeroso, por tal motivo nos centraremos en el frente de
las arquitecturas de referencia que plantean plantillas de solución arquitectónica para
los modelos de las vistas físicas de una arquitectura.
Una clara diferenciación de los frentes físicos y lógicos, es presentada en la
definición de arquitectura de dominio propuesta en MDSD [4], la figura 2 ilustra los
conceptos que componen una arquitectura de dominio.

Fig. 2. Estructura de una Arquitectura de Dominio y su relación con las Líneas de Productos,
adaptado de [4].
 5

Para clarificar la diferencia entre los frentes físicos y lógicos definiremos los tres
conceptos que componen una arquitectura de dominio:
 Un DSL (Lenguaje Específico de Dominio): Se refiere a un concepto de carácter
lógico que se usa en el espacio del problema, se define como un lenguaje diseñado
para modelar o resolver problemas en un dominio particular bien definido, esto
significa que en vez de ser un lenguaje para propósito general, es un lenguaje que
captura con precisión la semántica de un dominio determinado.
 Una plataforma: Se refiere a conceptos de carácter físico que hacen parte del
espacio de la solución, se define como la agregación de conceptos como: el
Middlewares, Librerías, Frameworks, Componentes y Aspectos1.
 Las transformaciones: Definen los mecanismos para llevar los modelos desde el
espacio del problema hasta el espacio de la solución [12].
Los mecanismos que provee un DSL resultan de gran utilidad para definir un lenguaje
común para el grupo de desarrollo que le posibilite la asimilación y el uso de
conceptos lógicos que apoyen el reuso en el desarrollo de software, como por ejemplo
patrones de diseño o capas de una arquitectura.

3 Perspectivas para la definición de una arquitectura de software

En el estudio de las técnicas para el modelado de una arquitectura de referencia, es

importante conocer las perspectivas que existen para la definición de una arquitectura
de software. El número de definiciones de arquitectura de software alcanza un orden
de tres dígitos [10] y aunque existe un acuerdo general de que ella se refiere a la
estructura a grandes rasgos del sistema, existen múltiples perspectivas que plantean
estrategias a la hora de definirlas. A continuación se analizan las más representativas
de esas perspectivas:
 Perspectiva académica: la academia fue el ámbito que lideró la definición de lo
que hoy conocemos como arquitectura de software, sin embargo hoy por hoy existe
una brecha en lo que la academia, los grandes vendedores de software y la
industria, en general califican como relevante a la hora de definir una arquitectura
de software. La perspectiva académica se caracteriza por definir explícitamente la
arquitectura y dividirla en componentes y conectores de primera clase, dándole
prioridad a la funcionalidad y a la verificación formal. La descripción de la
arquitectura se realiza con la utilización de lenguajes específicos para este
propósito (ADL: Architecture Description Language) con el fin de generar
automáticamente la arquitectura en algunas ocasiones [10]. Una característica
particular de los componentes desde la perspectiva académica, es que estos son
entidades reutilizables de caja negra, con interfaces de un solo punto de acceso.
 Perspectiva de los grandes vendedores: Los grandes vendedores de software
también definen las características relevantes de una arquitectura de software, bajo
esta perspectiva prevalece la definición conceptual de la arquitectura sobre las
definiciones explícitas y las notaciones formales, siguiendo esta perspectiva los
componentes son grandes piezas de software complejas no necesariamente

1 Programación Orientada por Aspectos [11]

6

encapsuladas y las interfaces a estos se proporcionan mediante entidades (clases en

los componentes) [10]. Además se enfoca más en el espacio de la solución, pues
define la implementación en una plataforma específica (p.e. JEE, .NET, IBM), una
serie de patrones y mejores prácticas que implementan su catálogo de productos o
tecnologías.
 Perspectiva industrial: Es evidente que existe una brecha entre las propuestas de
la academia, los grandes vendedores y la industria, sin embargo no es conveniente
sobredimensionarla, imaginando que estas tres realidades están desconectadas, por
el contrario gran parte de las herramientas de la academia se desarrollaron en
contextos industriales o de apoyo al gobierno, la cuestión y la razón principal de
esta brecha radica en el desconocimiento que la industria tiene de la arquitectura
académica y en que llama arquitectura a lo que solo es Diseño.
La perspectiva industrial se caracteriza por adaptar las arquitecturas propuestas por
los grandes vendedores y enfocarse mucho más en el espacio de la solución,
proponiendo así una arquitectura menos formal y está dada por la integración de
servidores de aplicaciones, frameworks y patrones comerciales o sufriendo el
síndrome “no inventado aquí” (not invented here) desarrollando los suyos propios.
De esta manera la perspectiva de la industria se caracteriza por enfocarse en los
componentes, no definir conectores de primera clase, implementar soluciones
ad-hoc de binding en tiempo de ejecución, usar lenguajes de programación o
diagramas libres para representarla y dar igual importancia tanto a la funcionalidad
como a los atributos de calidad. [10].
 Perspectiva del desarrollo dirigido por modelos: Las recientes aproximaciones
de la ingeniería dirigida por modelos como MDA (Model Driven Architecture)
[13], MDSD (Model Driven Software Development) [4] y las Factorías de Software
(Software Factories) [14], le dan dentro de la arquitectura de software una
connotación muy marcada a los metamodelos, las plataformas y las
transformaciones, esto con el propósito de facilitar la generación de aplicaciones a
partir de modelos. Plantean la utilización de técnicas como el marcado y el mapeo
para construir modelos con base en una arquitectura de referencia. La arquitectura
de software es importante en el contexto de MDSD para la descripción de los
componentes más relevantes de una plataforma, su interacción y sus características
no funcionales [4].

4 Técnicas para el modelado de arquitecturas de referencia

En cada perspectiva arquitectónica se prefiere una técnica de modelado arquitectónico

diferente: La perspectiva académica suele usar ADL, la de los grandes vendedores
suele usar diagramas libres, la industrial suele usar diagramas de paquetes y la de
desarrollo dirigido por modelos suele usar perfiles.
 ADL: Un ADL es un lenguaje descriptivo de modelado que se focaliza en la
estructura de alto nivel de la aplicación antes que en los detalles de
implementación de módulos concretos [15]. Aunque no existe hoy una definición
consensuada e inequívoca de ADL, comúnmente se acepta que un ADL debe
 7

proporcionar un modelo explicito de componentes, conectores y sus respectivas

configuraciones [16].
Los componentes representan los elementos computacionales primarios del
sistema, algunos ejemplos serían: clientes, servidores, filtros, objetos, pizarras y
bases de datos, los componentes exponen varias interfaces, las cuales definen sus
puntos de interacción. Los conectores representan interacción entre los
componentes, por ejemplo: tuberías (pipes), llamadas a procedimientos, broadcast
de eventos, protocolos cliente-servidor o conexiones entre una aplicación y un
servidor de base de datos. Por último las configuraciones que se constituyen como
grafos de componentes y conectores en donde además se especifican propiedades
funcionales y no funcionales, restricciones, estilos y evolución de la arquitectura.

Fig. 3. Diagrama de tubería realizado con un ADL llamado Darwin [16]

 Diagramación libre: El modelado arquitectónico es el proceso de capturar y

documentar las decisiones del diseño arquitectónico y puede hacerse de diferentes
maneras. Una de estas técnicas es el uso de documentos de lenguaje natural y
diagramas abstractos de “cajas y flechas”. Aunque en apariencia este método puede
parecer más intuitivo y efectivo, carece de formalismo, rigor y la precisión
necesarias para describir de manera comprensible los elementos básicos de una
arquitectura [17].

Fig. 4. Diagrama libre de la arquitectura de referencia para aplicaciones .Net [18]

8

 Diagramas de Paquetes: Los diagramas de paquetes muestran una agrupación de

elementos en un modelo orientado a objetos, los diagramas de paquetes se utilizan
para representar agrupaciones de de clases, interfaces, componentes, procesos o
procesadores. Como mecanismo de representación de arquitecturas pueden resultar
muy útiles pues permiten representar diferentes vistas de la arquitectura, en
especial siguiendo la propuesta de las 4+1 vistas. Para la representación de una
arquitectura de referencia cada paquete podría representar una capa de una
arquitectura, y las clases en su interior podrían ser las clases del patrón que se
pueden utilizar en dicha capa.

Fig. 5. Diagrama de paquetes de una arquitectura de referencia implementando Hibernate y

capas, adaptado de [19]

 Perfiles: Los perfiles son una extensión de UML, realizada con el fin de poder
representar dominios de tipo técnico o profesional. Los perfiles de UML están
compuestos básicamente por tres tipos de artefactos: estereotipos, valores
etiquetados y restricciones. Siendo más claros, el paquete de perfiles de UML 2.0
define una serie de mecanismos para extender las metaclases de un modelo
cualquiera, para adaptarlas a una plataforma específica (p.e. JEE, .NET) o a un
dominio de aplicación. En general un perfil se define en un paquete estereotipado
<<profile>> que extiende a un metamodelo o a otro perfil.
La sintaxis concreta de un DSL se puede expresar de forma gráfica a través de un
perfil de UML [4], por lo que marcar un modelo arquitectónico con base en los
estereotipos de un perfil, se convierte en la definición de una arquitectura de
software que se basa en la arquitectura de referencia definida en dicho perfil.
 9

Fig. 6. Fragmento de un perfil para implantaciones en Java que utilicen el modelo EJB.

5 Selección de una técnica para el modelado de arquitecturas de

referencia

En este capítulo se presenta el marco de referencia para la selección de una técnica de

modelado de arquitecturas de referencia, dividido en tres partes: los criterios que se
utilizan para comparar las técnicas, la escala de evaluación de los criterios en cada
técnica y un análisis comparativo que muestra las evaluaciones realizadas.

5.1 Criterios de comparación

Los criterios de comparación presentados en esta propuesta son definidos con base en
trabajos que analizan las características de un lenguaje de descripción arquitectónica
[20] [15] [21], en la presente propuesta se busca ampliar estas características para
generalizarlas a las diferentes técnicas de modelado de arquitecturas de referencia, a
la par que se actualizan para apoyar las nuevas tendencias en arquitectura de software.
Adicionalmente, se realiza una clasificación de las características en tres categorías
que constituyen los pilares de MDA propuestos en el Manifiesto MDA [22] planteado
por IBM: (a) representación directa para enfocarse en el dominio del problema más
que en la tecnología, (b) automatización de las tareas mecánicas que no requieren
intervención humana y (c) estándares abiertos que posibiliten la interoperabilidad de
las herramientas y plataformas.
10

5.1.1. Representación Directa

En esta categoría se evalúan las características de la técnica de modelado que

reducen la distancia semántica entre una arquitectura de referencia y su respectiva
representación gráfica, de manera que se permita un acoplamiento directo de las
soluciones hacia los problemas para las cuales fueron construidas.
 Expresividad gráfica: comprensibilidad que se le puede dar a los diagramas de la
arquitectura de referencia, posibilitando por ejemplo la diferenciación de capas o la
forma de aplicación de un patrón.
 Múltiples vistas: posibilidad de representar las plantillas de solución probada para
la arquitectura, desde diferentes puntos de vista, por ejemplo vista conceptual,
física o lógica [10].
 Estructura y comportamiento: capacidad para modelar la estructura de la
arquitectura de referencia y su comportamiento.
 Modelado de restricciones: en [23] se define un ADL como una composición de
cuatro “Cs”: componentes, conectores, configuraciones y restricciones
(constraints), esto motiva la inclusión de las restricciones como una característica
importante para modelar una arquitectura de referencia.
 Inclusión de propiedades: posibilidad de definir propiedades no funcionales, o
admitir herramientas complementarias para analizarlas y determinar, por ejemplo,
el throughput y la latencia probables, o cuestiones de seguridad, escalabilidad,
configuraciones mínimas de hardware y tolerancia a fallas [15].

5.1.2. Automatización

En esta categoría se mide la capacidad de las técnicas de modelado de arquitecturas

de referencia para permitir la automatización de tareas de desarrollo de software que
son mecánicas y no dependen de la intuición humana, de tal forma que se incremente
la productividad y se reduzca el esfuerzo requerido. Este es uno de los propósitos
fundamentales de la naciente disciplina de Ingeniería de Modelos [24] [25].
 Herramientas de modelado: disponibilidad de herramientas que permitan
construir modelos de arquitecturas de referencia usando la técnica en cuestión.
 Herramientas de transformación: disponibilidad de herramientas que permitan
transformar modelos y generar código a partir de modelos que se basen en
arquitecturas de referencia que se hayan construido usando la técnica en cuestión.
 Configurabilidad: capacidad para modelar diferentes estrategias arquitectónicas
dentro de la arquitectura de referencia, dichas estrategias son llamadas en algunos
casos familias, estilos [26] y en otros configuraciones [23], y permitirían generar
hacia diversas arquitecturas de referencia a partir de un mismo modelo.
 Integración de patrones: capacidad de integrar patrones de software como
elemento participante de la arquitectura de referencia usando la técnica, de tal
forma que estos puedan ser usados en una arquitectura en particular.
 Modificabilidad: posibilidad de cambiar la arquitectura de referencia y regenerar
el código para arquitecturas específicas que se hayan construido con la técnica.
 11

5.1.3. Estándares Abiertos

En esta categoría se evalúa cada técnica de modelado en la medida en que esté

definida alrededor de un estándar. Los estándares industriales no solo ayudan a
eliminar la heterogeneidad de las diversas alternativas, sino que también fomentan el
desarrollo de un ecosistema de proveedores de herramientas interoperables para
diversos propósitos, siendo así más atractivo para la adopción en el sector industrial.
 Metamodelo disponible: Existencia y disponibilidad del metamodelo para
posibilitar la transformación de modelos, ya que de ésta forma se aprovechará su
potencial como activos de conocimiento y se obtendrán los beneficios que
proporciona la ingeniería de modelos. Un ejemplo característico de dicho
metamodelo se puede evidenciar en MOF2 [27].
 Estándar de intercambio: mecanismo para serializar arquitecturas de referencias
construidas con la técnica, a la par que permite la posibilidad de abrirla con otra
herramienta que soporte el mismo estándar de intercambio. Un ejemplo
característico de dicho estándar se puede evidenciar en XMI3 [28].
 Framework de Modelado: Implementación del metamodelo en un framework de
modelado como el propuesto en EMF4 [29], con el propósito de usarlo en
herramientas de transformación de manera que se facilite el mapeo hacia otros
tipos de modelos en otros niveles de abstracción.
 Herramientas open source: Existencia de herramientas open source que soporten
la técnica, ya que de ésta forma se podrá utilizar en el beneficio de la comunidad
que provee el desarrollo de software open source.
 Respaldo Consorcio Industrial: Respaldo por parte de algún consorcio de
estándares abiertos reconocido por la industria, debido a que éstos representan un
consenso entre las compañías con más experiencia en este tema.

5.2 Escala para la evaluación

En la Tabla 2 se presenta la escala de valores usada en el análisis comparativo. La

escala se basa en el nivel de soporte que tienen las técnicas para cada uno de los
criterios de comparación.

Tabla 3. Escala de comparación

Valor Nombre Nivel de Soporte
1 Nulo No soportado, no documentado.
2 Pobre Soportado con artificios, poca o ninguna documentación.
3 Regular Soportado y documentado, pero difícilmente aplicable.
4 Bueno Soportado, documentado y fácilmente aplicable.
5 Nativo Soportado, documentado y fácilmente aplicable desde la definición inicial
de la técnica.

2 Meta-Object Facility
3 XML Metadata Interchange
4 Eclipse Modeling Framework
12

5.3 Análisis Comparativo

En la Tabla 3 se presentan las calificaciones dadas a cada ítem propuesto en los

criterios de comparación, de igual forma se muestra un promedio para cada uno de los
ítems y una calificación promedio total para cada una de las técnicas.

Tabla 4. Análisis comparativo

Criterio ADL Libre Paquetes Perfiles Prom.

Expresividad gráfica 5 4 4 3 4,0
Múltiples vistas 5 4 5 4 4,5
Estructura y comportamiento 4 4 3 3 3,5
Modelado de restricciones 2 4 4 5 3,8
Inclusión de propiedades 3 4 1 4 3,0
Promedios Representación Directa 3,8 4 3,4 3,8 3,8
Herramientas de modelado 5 4 5 4 4,5
Herramientas de transformación 3 1 3 4 2,8
Configurabilidad 5 1 2 3 2,8
Integración de patrones 2 2 5 5 3,5
Modificabilidad 3 2 3 4 3,0
Promedios Automatización 3,6 2 3,6 4 3,3
Metamodelo disponible 3 1 5 5 3,5
Estándar de intercambio 2 1 5 5 3,3
Framework de Modelado 2 1 5 5 3,3
Herramientas open source 5 4 5 5 4,8
Respaldo Consorcio Industrial 1 3 5 5 3,5
Promedios Estándares Abiertos 2,6 2 5 5 3,7
Promedios Totales 3,3 2,7 4,0 4,3 3,6

La justificación de las calificaciones para cada técnica se describe a continuación:

 ADL: En el frente de representación directa los ADLs presentan ventajas, pues
muy son expresivos, permiten múltiples vistas inclusive en algunos casos soportan
la definición de propiedades no funcionales; en el frente de automatización aunque
existen herramientas de modelado para cada ADL muy pocas generan código o
integran patrones; y en el frente de estándares abiertos aunque la mayoría de
herramientas para los ADLs son open source, existen pocas definiciones comunes
de metamodelos o frameworks y su respaldo es preponderantemente académico.
 Diagramación libre: En el frente de representación directa la diagramación libre
es muy poderosa aunque no fue concebida inicialmente para modelos
arquitectónicos; en el frente de automatización aunque existen herramientas de
modelado muy pocas generan código o integran patrones; y en el frente de
estándares abiertos existen herramientas open source, no existen definiciones
comunes de metamodelos o frameworks, pero en algunos casos estas técnicas y
herramientas tienen el apoyo de consorcios industriales.
 Diagramación de paquetes: En el frente de representación directa los diagramas
de paquetes pueden ser expresivos y modelar múltiples vistas, sin embargo no se
pueden definir propiedades no funcionales aunque se pueden escribir restricciones
con OCL dentro de notas de UML; en el frente de automatización existen diversas
herramientas de modelado en UML pero muy pocas generan código a partir de
 13

diagramas de paquetes, los patrones se pueden integrar con las clases de los
patrones dentro de los paquetes; y en el frente de estándares abiertos existen
herramientas open source, existen un metamodelo como MOF y un estándar de
intercambio como XMI, también frameworks como EMF y muchos consorcios
industriales le apoyan.
 Perfiles: En el frente de representación directa los perfiles no son muy expresivos
y pueden usarse para modelar diversas vistas, se pueden escribir restricciones con
OCL y las propiedades no funcionales se pueden incluir con valores etiquetados;
en el frente de automatización existen varias herramientas para modelar perfiles, y
tienen como propósito posibilitar el marcado y la generación de código, los
patrones se pueden integrar fácilmente y el código se puede regenerar ante
cambios; y en el frente de estándares abiertos existen herramientas open source,
existen un metamodelo como MOF y un estándar de intercambio como XMI,
también frameworks como EMF y muchos consorcios industriales le apoyan.
El análisis comparativo nos muestra que los ADLs tienen fortalezas en la
representación arquitectónica y la diagramación libre brinda mucha libertad y
expresividad gráfica, pero bajo los preceptos de propuestas como MDA y MDSD
tienen gran acogida técnicas como los diagramas de paquetes y más aun los perfiles.

6 Conclusiones y Trabajos Futuros

Una arquitectura de referencia constituye un activo de software que puede resultar de

mucha utilidad para una empresa que realice desarrollos de software, sin embargo no
debe constituirse en una camisa de fuerza que lleve al grupo de desarrolladores a
cambiar de manera significativa sus hábitos en programación, pues el éxito de un
activo como este depende de su aceptación y comprensión, finalmente los beneficios
que se deben esperar de su utilización apropiada dentro de la empresas es la mejora de
la productividad pues se potencia el reuso temprano, y la calidad y homogeneidad del
software pues cada solución viene de una plantilla común probada previamente.
También es importante aclarar que no es necesario usarla en todos los proyectos, pues
no todos los desarrollos que realiza la empresa obedecen a las mismas plataformas.
En cuanto al análisis comparativo se evidencia que las recientes aproximaciones de
la ingeniería dirigida por modelos favorecen el uso de técnicas como los perfiles y los
diagramas de paquetes para la definición de una arquitectura de referencia, pues los
mecanismos en los que se apoyan como metamodelos, DSLs, estándares de
intercambio, etc., potencian la transformación de modelos y la generación de código.
El uso práctico del análisis comparativo, se puede dar a partir de un proceso de
toma de decisiones, en el que una empresa defina pesos para cada criterio de
comparación y pondere esos pesos con las calificaciones propuestas en este trabajo
para decidir cual técnica le conviene para modelar su arquitectura de referencia.

Referencias
1. Clements, P., Bass L., Kazman R.: Software Architecture in Practice. 2 ed. Addison-Wesley, 2003.
ISBN: 032115495
14

2. IEEE. IEEE Recommended Practice for Architecture Description of Software-Intensive Systems.

ANSI/IEEE 1471-2000. ISBN 0-7381-2518-0
3. Kruchten, P.: Architectural Blueprints--The 4+1 View Model of Software Architecture. En: IEEE
Software, Institute of Electrical and Electronics Engineers. November 1995. P. 42-50.
4. Völter, M. y Stahl, T. Model-Driven Software Development (Technology, Engineering, Management)
ISBN: 978-0-470-02570-3, 444 p, 2006.
5. Bézivin, J.: MDA™ : From Hype to Hope, and Reality. 6th International Conference on the Unified
Modelling Language, UML 2003. San Francisco.
6. Brown, A., Conallen J., Tropeano, D. Model-Driven Software Development, Introduction: Models,
Modeling, and Model-Driven Architecture (MDA) © Springer-Verlag Berlin Heidelberg 2005
7. Rogers, E.: Diffusion of Innovations. Free Press, 4a Ed. (Paperback). ISBN: 0029266718. 518 p,
Febrero 1995.
8. Moore, G.: Crossing the Chasm. HarperBusiness, Edicion Revisada. ISBN: 0066620023. 256 p, Julio
1999.
9. Reed, P.: Reference Architecture - The best of best practices. [Documento Electrónico]. IBM.
Septiembre de 2002. http://www.ibm.com/developerworks/rational/library/2774.html
10. Reynoso, C.: Introducción a la Arquitectura de Software Versión 1.0. [Documento Electrónico] Centro
de Arquitectura .NET Microsoft, Universidad de Buenos Aires, Marzo 2004.
http://www.hacienda.go.cr/centro/datos/Articulo/Introducción a la Arquitectura de Software.doc
11. Aspect-Oriented Software Association. Aspect-Oriented Software Development Community &
Conference. [Documento Electrónico]. AOSA, 2006. http://aosd.net/
12. Quintero, J., Anaya, R.: Marco de Referencia para la Evaluación de Herramientas Basadas en MDA.
Memorias del X Workshop IDEAS, 2007. p.225 – 238. ISBN 978-980-325-323-3
13. Object Management Group. MDA® Guide Version 1.0.1. [Documento Electrónico]. OMG, 2003.
http://www.omg.org/cgi-bin/apps/doc?omg/03-06-01.pdf
14. Greenfield, J., Short, K.: Software Factories: Assembling Applications with Patterns, Models,
Frameworks, and Tools. Wiley. 2004
15. Vestal, S.: A Cursory Overview and Comparison of Four Architecture Description Languages.
Honeywell Technology Center, Minneapolis, Febrero 1993
16. Reynoso, C., Kicillof, N.: De lenguajes de descripción arquitectónica de software. Universidad de
Buenos Aries [Documento electronico] http://www.willydev.net/descargas/prev/ADL.pdf
17. Georgas J., Dashofy, E., Taylor, R.: Desarrollo de software centrado en la arquitectura: Una Mirada
diferente de la ingeniería de software. The ACM Student Magazine [Documento electronico]
http://www.acm.org/crossroads/espanol/xrds12-4/arqcentric.html
18. Microsoft: Application Architecture for .Net: Designing Applications and Services. Microsoft
Corporation. 2002. ISBN 0-7356-1837-2
19. Dahan, U.: The Software Simplist , fetching Strategy Desing [Documento Electrónico]
http://www.udidahan.com/2007/04/23/fetching-strategy-design/
20. Medvidovic, N.: A Classification and Comparison Framework for Software Architecture
Description Languages. Technical Report, UCI-ICS-97-02, Universidad de California,
Irvine, Enero 1997.
21. Kogut, P., Clements, P.: Features of Architecture Description Languages. Draft of a CMU/SEI
Technical Report, Diciembre 1994
22. Booch, G., Brown, A., Iyengar, S., Selic, B. y Rumbaugh, J.: An MDA Manifesto. Rational MDA
Documentation, IBM Corporation, 2004
23. Wolf, A.: Succeedings of the Second International Software Architecture Workshop. (ISAW-2). ACM
SIGSOFT Software Engineering Notes, pp. 42-56, Enero 1997.
24. Bezivin, J. "In Search of a Basic Principle for Model Driven Engineering". UPGRADE-Cepis
(http://www.upgrade-cepis.org/issues/2004/2/up5-2Bezivin.pdf), Abril 2004.
25. Bezivin, J. "On The Unfication Power of Models". ATLAS Group, Universidad de Nantes, Francia
(http://www.sciences.univ-nantes.fr/lina/atl/), 2003.
26. Perry, D., Wolf, A.: “Foundations for the study of software architecture”. ACM SIGSOFT Software
Engineering Notes, 17(4), pp. 40–52, Octubre 1992
27. Object Management Group. MOF 2.0 / XMI Mapping Specification, V2.1.1. [Documento
Electrónico]. OMG, 2003. http://www.omg.org/docs/formal/06-01-01.pdf
28. Object Management Group. XML Metadata Interchange (XMI), v2.1.1. [Documento Electrónico].
OMG, 2003. http://www.omg.org/docs/formal/07-12-01.pdf
29. Merks, Ed et al. "Eclipse Modeling Framework". The Eclipse Series (http://www.eclipse.org/emf).
Agosto 2004.