Arquitectura de Software -...
61
Arquitectura de Software Juan Bernardo Quintero
Transcript of Arquitectura de Software -...
Arquitectura de Software
Juan Bernardo Quintero
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.
Contexto de la Arquitectura de Referencia
Principales conceptos implicados:
Arquitectura de software
Arquitectura de referencia
Arquitectura de dominio
Arquitectura generativa
Línea base de la arquitectura
Arquitectura destino
Contexto de la Arquitectura de Referencia
Clements: 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.
IEEE 1471-2000: 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.
Kruchten: 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, así
como requerimientos no funcionales, como la confiabilidad,
escalabilidad, portabilidad y disponibilidad.
Contexto de la Arquitectura de Referencia
Arquitectura de software
Proporciona una plantilla de solución probada para la arquitectura en un
dominio particular, y define un vocabulario común con el que se puede
discutir los detalles de implementación para un producto de software. 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 J2EE, es una
arquitectura de referencia por capas que ofrece una plantilla de solución
para muchos sistemas empresariales desarrollados en Java.
Contexto de la Arquitectura de Referencia
Arquitectura de referencia
En la propuesta de MDSD (Model Driven Software Development) se
precisan las arquitecturas de referencia a partir del concepto de
arquitectura de dominio que se define como la agregación de tres
conceptos:
Plataforma,
Lenguaje Especifico de Dominio
Transformaciones.
Es la especialización de una arquitectura de domino dentro del contexto
de AC- MDSD (Desarrollo de Software Dirigido por Modelos Centrado en
la Arquitectura).
Contexto de la Arquitectura de Referencia
Arquitectura de dominio
Arquitectura generativa
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.
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.
Contexto de la Arquitectura de Referencia
Línea base de la arquitectura
Arquitectura destino
Los modelos cada vez toman más relevancia en el proceso
de desarrollo de software, según Bézivin la construcción de
software ha evolucionado de plantear que “todo es un
objeto” a finales del siglo pasado, a proponer que “todo es
un modelo” a comienzos de este siglo.
Los modelos y la Arquitectura de Referencia
Objects
Models
1980 2000 2020
Promises
Delivery
Evaluation
Promises
Delivery
Evaluation
Extraído de: Bézivin, J.: MDA™ : From Hype to Hope, and Reality. 6th International Conference on the Unified
Modelling Language, UML 2003. San Francisco.
Los modelos y la Arquitectura de Referencia
Nombre Descripción
1 Solo código Se desconocen los modelos
2 Visualización de código El código es el modelo
3 Ingeniería de ida y vuelta El código y el modelo coexisten
4 Centrado en los modelos El modelo es el código
5 Solo modelos El código es invisible
Espectro de modelado
Extraído de: Brown, A., Conallen J., Tropeano, D. Model-Driven Software Development, Introduction: Models,
Modeling, and Model-Driven Architecture (MDA) © Springer-Verlag Berlin Heidelberg 2005
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:
Los modelos y la Arquitectura de Referencia
Fusión del espectro de modelos y
de la curva de adopción tecnológica
Adaptado de: Moore, G.: Crossing the Chasm. HarperBusiness, Edicion Revisada. ISBN: 0066620023. 256 p,
Julio 1999.
El reto lo constituye “cruzar el abismo” (Cross the Chasm),
Si los modelos se presentan de tanta utilidad en la construcción
de software, modelar la arquitectura de referencia puede resultar
de muy beneficioso.
Los modelos y 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”.
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
Los modelos y la Arquitectura de Referencia
Adaptado de: 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
Los modelos y la Arquitectura de Referencia
Propuesta de
arquitectura
Agrupación de
componentes enVistas propuestas
Zachman NivelesScope, Empresa, Sistema lógico, Tecnología,
Representación, Funcionamiento
TOGAF Arquitecturas Negocios, Datos, Aplicación, Tecnología
4+1 VistasDiseño, Proceso, Implementación ,
Despliegue, Casos de uso
POSA Vistas Lógica, Proceso, Física, Desarrollo
Microsoft Vistas Lógica, Conceptual, Física
Marcos de referencia arquitectónicos
Adaptado de: 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
Los modelos y la Arquitectura de Referencia
Estructura de una Arquitectura de Dominio
y su relación con las Líneas de Productos
Adaptado de: Völter, M. y Stahl, T. Model-Driven Software Development (Technology, Engineering, Management)
ISBN: 978-0-470-02570-3, 444 p, 2006.
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 Aspectos.
Las transformaciones: Definen los mecanismos para llevar los modelos
desde el espacio del problema hasta el espacio de la solución.
Los modelos y la Arquitectura de Referencia
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 (http://www.sei.cmu.edu/architecture/definitions.html) 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.
Perspectivas de la Arquitectura de Referencia
A continuación se analizan las más representativas de esas
perspectivas:
Perspectiva académica
Perspectiva de los grandes vendedores
Perspectiva industrial
Perspectiva del desarrollo dirigido por modelos
Perspectivas de la Arquitectura de Referencia
Perspectivas de la Arquitectura de Referencia
Basado en: 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
Consideraciones:
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 calificancomo relevante a la hora de definir una arquitectura de software.
Enfoque:
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.
Definición de Componente:
Entidades reutilizables de caja negra, con interfaces de un solo punto de acceso.
Perspectiva académica
Perspectivas de la Arquitectura de Referencia
Basado en: 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
Consideraciones:
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 notacionesformales.
Enfoque:
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.
Definición de Componente:
Grandes piezas de software complejas no necesariamente encapsuladas y las
interfaces a estos se proporcionan mediante entidades (clases en los
componentes).
Perspectiva de los grandes vendedores
Perspectivas de la Arquitectura de Referencia
Basado en: 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
Consideraciones:
Existe una brecha entre las propuestas de la academia, los grandes vendedores y
la industria, derivada de que frecuentemente la industria desconoce la idea que
tiene la academia de la arquitectura, y algunas veces llama arquitectura a lo que
solo es diseño.
Enfoque:
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
Definición de Componente:
Esta perspectiva se caracteriza por enfocarse en los componentes, implementar
soluciones ad-hoc de binding en tiempo de ejecución, usar lenguajes de
programación o diagramas libres para representarla, dar igual importancia a la
funcionalidad y a los atributos de calidad, y no definir conectores de primera clase.
Perspectiva industrial
Perspectivas de la Arquitectura de Referencia
Basado en: 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
Consideraciones:
Impulsada por las recientes aproximaciones de la ingeniería dirigida por modelos:• MDA (Model Driven Architecture)
• MDSD (Model Driven Software Development)
• Factorías de Software (Software Factories)
Para facilitar la generación de aplicaciones a partir de modelos, le dan una
connotación muy marcada a tres elementos dentro de la arquitectura de software:
los metamodelos, las plataformas y las transformaciones.
Enfoque:
Plantean la utilización de técnicas como el marcado y el mapeo para construir
modelos con base en una arquitectura de referencia.
Definición de Componente:
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..
Perspectiva del desarrollo dirigido por modelos
En cada perspectiva arquitectónica se prefiere una técnica de
modelado arquitectónico diferente:
Técnicas de diseño de una Arq. de Ref.
Perspectiva arquitectónica Técnica de modelado
Académica ADL (Architecture Description Language)
De los grandes vendedores Diagramas libres
Industrial Diagramas de paquetes
De desarrollo dirigido por modelos Perfiles en UML
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. Comúnmente se acepta que un
ADL proporcionar un modelo explicito de componentes, conectores y
sus respectivas configuraciones:
Componentes: representan elementos computacionales primarios del sistema,
por ejemplo: clientes, servidores, y bases de datos, los cuales exponen varias
interfaces, que definen sus puntos de interacción.
Conectores: representan interacción entre componentes, por ejemplo:
tuberías (pipes), llamadas a procedimientos, broadcast de eventos, protocolos
cliente-servidor o conexiones de una aplicación a una BD.
Configuraciones: 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.
ADL
Basado en: 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
Técnicas de diseño de una Arq. de Ref.
ADL (Ejemplos)
Diagrama de
tubería
realizado con
Darwin
Diagrama de
Arquitectura
Empresarial
realizado con
Archimate
Técnicas de diseño de una Arq. de Ref.
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.
Diagramación libre
Técnicas de diseño de una Arq. de Ref.
Diagramación libre (Ejemplo)
Diagrama libre de la
arquitectura de
referencia para
aplicaciones .Net
Tomado de: Microsoft: Application Architecture for .Net: Designing Applications and Services. Microsoft
Corporation. 2002. ISBN 0-7356-1837-2
Técnicas de diseño de una Arq. de Ref.
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.
Diagramas de Paquetes
Técnicas de diseño de una Arq. de Ref.
Diagramas de Paquetes (Ejemplo)
Diagrama de
paquetes de una
arquitectura de
referencia
implementando
Hibernate y capas
Tomado de: Dahan, U.: The Software Simplist , fetching Strategy Desing [Documento Electrónico]
http://www.udidahan.com/2007/04/23/fetching-strategy-design/
Técnicas de diseño de una Arq. de Ref.
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, 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.
Perfiles
Técnicas de diseño de una Arq. de Ref.
Perfiles (Ejemplo)
Fragmento de un
perfil para
implantaciones
en Java
que utilicen el
modelo EJB
Técnicas de diseño de una Arq. de Ref.
Definen las condiciones y propiedades que debe tener una
arquitectura de referencia para que cumpla apropiadamente se
objetivo. Para su análisis se clasifican en tres categorías:
Representación Directa: para enfocarse en el dominio del problema
más que en la tecnología.
Automatización: de tareas mecánicas que no requieren intervención
humana.
Estándares Abiertos: que posibiliten la interoperabilidad de las
herramientas y plataformas.
Características de una Arq. de Ref.
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
Múltiples vistas
Estructura y comportamiento
Modelado de restricciones
Inclusión de propiedades
Criterios de comparación: Representación Directa
Características de una Arq. de Ref.
Criterios de comparación: Representación Directa
Características de una Arq. de Ref.
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.
Estructura y comportamiento:
Capacidad para modelar la estructura de la arquitectura de referencia y su comportamiento.
Modelado de restricciones:
Un ADL se puede definir 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.
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.
Herramientas de modelado
Herramientas de transformación
Configurabilidad
Integración de patrones
Modificabilidad
Criterios de comparación: Automatización
Características de una Arq. de Ref.
Criterios de comparación: Automatización
Características de una Arq. de Ref.
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 basados en arquitecturas de referencia 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 y en otros
configuraciones, y permitirían generar hacia diversas arq. de ref. 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.
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
Estándar de intercambio
Framework de modelado
Herramientas open source
Respaldo Consorcio Industrial
Criterios de comparación: Estándares abiertos
Características de una Arq. de Ref.
Criterios de comparación: Estándares abiertos
Características de una Arq. de Ref.
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. Por ejemplo MOF.
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 XMI.
Framework de Modelado:
Implementación del metamodelo en un framework de modelado como el propuesto en EMF,
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, de ésta forma se podrá
utilizar en el beneficio de la comunidad que provee el desarrollo de software open source.
Respaldo Consorcio Industrial:
Respaldo 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.
Características de una Arq. de Ref.
En la siguiente tabla 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.
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
Análisis Comparativo: ADL
Características de una Arq. de Ref.
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.
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.
Análisis Comparativo: Diagramación libre
Características de una Arq. de Ref.
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.
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.
Análisis Comparativo: Diagramación de paquetes
Características de una Arq. de Ref.
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 diagramas de paquetes, los patrones se pueden integrar con las
clases de los patrones dentro de los paquetes.
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.
Análisis Comparativo: Perfiles
Características de una Arq. de Ref.
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.
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.
Ejemplo 1: J2EE
Ejemplo 2: J2EE
Capa de presentación
Capa de lógica de negocios
Capa de acceso a datos
Value
Objects
Bases de datos
Ejemplo 3: J2EE
Coordinación Aplicación
Clases Dominio
Esquema Persistencia
José Pérez: Cliente
Materialización /
Desmaterialización
de objetos
T-cliente
InterfacesLógica de
presentación
Lógica del
Negocio
Lógica de
Persistencia
Patrón
MVC?
Patrón
DAO?
Ejemplo 4: MVC-DAO
Ejemplo 5: Capas usando Frameworks
Conclusiones
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.
Conclusiones
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.
1. Clements, P., Bass L., Kazman R.: Software Architecture in Practice. 2 ed. Addison-Wesley,
2003. ISBN: 032115495
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.
Referencias
9. Reed, P.: Reference Architecture - The best of best practices. 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. 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. 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
Referencias
16. Reynoso, C., Kicillof, N.: De lenguajes de descripción arquitectónica de software.
Universidad de Buenos Aries 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
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
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.
Referencias
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. OMG, 2003.
http://www.omg.org/docs/formal/06-01-01.pdf
28. Object Management Group. XML Metadata Interchange (XMI), v2.1.1. 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.
Referencias
