ArchiMet: Herramienta Dirigida Por Modelos para La Evaluaci On de Rendimiento Sobre SOAs

ArchiMet: Herramienta dirigida por modelos para la
evaluaci
on de rendimiento sobre SOAs
Trabajo de Tesis
presentado al
Departamento de Ingeniera de Sistemas
por
Andr
es Mauricio Jim
enez Torres
Asesor: Daro Ernesto Correal Torres
Para optar al ttulo de

Magister en Ingeniera
Ingeniera de Sistemas y Computacion

Universidad de los Andes
Julio,2011
ArchiMet: Herramienta dirigida por modelos para la

evaluaci
on de rendimiento sobre SOAs
Aprobado por:
Daro Ernesto Correal Torres, Asesor
Jorge Alberto Villalobos Salcedo
Alexis Eduardo Ocampo Ramirez
Fecha de Aprobacin
iii
A Sofi y a Dalis por ser una excelente compa

na y alegrar cada da de mi vida.
iv
RECONOCIMIENTOS
Mis m
as sinceros agradecimientos a
Pap
a y mam
a, por ense
narme todo lo que se y apoyarme en este u
ltimo proyecto que
me propuse hace 4 a
nos.
A Daro, por haber aceptado la direccion de esta tesis, por sus consejos y guas para culminar la misma.
A Jorge, por haberme aceptado inicialmente para trabajar en tesis y por guiarme durante
esos 6 meses.
A Sofi y Dalis, por comprenderme, consentirme y regalarme su paciencia y valioso tiempo.
A Alejandro, Boris, Vctor, Ramiro, Horacio, Daniel, Carolina y demas compa
neros que
me apoyaron durante este u
ltimo a
no.
TABLA DE CONTENIDOS
DEDICATORIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iii
RECONOCIMIENTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iv
LISTA DE TABLAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vi
LISTA DE FIGURAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vii
INTRODUCCION
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1
Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2
Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3
Objetivos especficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4
Contribuciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5
Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . .
CASO DE ESTUDIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
III CONTEXTO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
II
3.1
Arquitectura de software . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
3.1.1
Atributos de calidad . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.1.2
Dise
no de software . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.1.3
Decisiones de dise
no . . . . . . . . . . . . . . . . . . . . . . . . . .
15
Arquitecturas Orientadas a Servicios . . . . . . . . . . . . . . . . . . . . .
15
3.2.1
Clasificaci
on de servicios . . . . . . . . . . . . . . . . . . . . . . . .
17
3.2.2
Comunicaci
on entre servicios . . . . . . . . . . . . . . . . . . . . . .
18
3.2.3
Notaci
on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.3
Evaluaci
on de arquitectura de software . . . . . . . . . . . . . . . . . . . .
21
3.4
Ingeniera dirigida por Modelos . . . . . . . . . . . . . . . . . . . . . . . .
22
3.5
Archivol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.5.1
Paquete candidate
. . . . . . . . . . . . . . . . . . . . . . . . . . .
25
3.5.2
paquete evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.2
IV RENDIMIENTO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
ESTRATEGIA DE SOLUCION
. . . . . . . . . . . . . . . . . . . . . . . .
36
5.1
Expresar arquitecturas candidatas . . . . . . . . . . . . . . . . . . . . . . .
37
5.2
Especificar los requerimientos de calidad . . . . . . . . . . . . . . . . . . .
38
5.3
Predecir comportamiento de arquitecturas candidatas por cada atributo de

calidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
5.3.1
Generaci
on de los modelos de colas . . . . . . . . . . . . . . . . . .
40
5.3.2
Soluci
on de los modelos de colas . . . . . . . . . . . . . . . . . . . .
42
Resultado de la evaluacion . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
VI ARCHIMET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
5.4
6.1
Factores externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
6.2
Arquitectura de ArchiMet . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
6.3
plug-in co.edu.uniandes.moosas.archivol.qualityrequirements - DSL para especificar requerimientos de calidad . . . . . . . . . . . . . . . . . . . . . .
51
plug-in co.edu.uniandes.moosas.archivol.somfeaimporter - Adaptador Enterprise Architect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
6.5
plug-in co.edu.uniandes.moosas.archivol.archimet - Controlador . . . . . .
55
6.6
plug-in co.edu.uniandes.moosas.archivol.archimet.soaperformance - Evaluador de rendimiento en SOAs . . . . . . . . . . . . . . . . . . . . . . . . .
57
VII EXPERIMENTACION
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
6.4
7.1
Prop
osito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
7.2
Implementaci
on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
7.2.1
Ambiente de ejecucion . . . . . . . . . . . . . . . . . . . . . . . . .
59
Ejecuci
on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
7.3
7.3.1
Tiempos de servicio para servicios atomicos y tiempos de comunicacion 60
7.3.2
Tiempos de servicio para servicios compuestos . . . . . . . . . . . .
61
7.3.3
Flujo m
aximo de servicios atomicos . . . . . . . . . . . . . . . . . .
61
7.3.4
Flujo m
aximo de servicios compuestos . . . . . . . . . . . . . . . .
64
An
alisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
VIIITRABAJOS RELACIONADOS . . . . . . . . . . . . . . . . . . . . . . . .
67
7.4
8.1
Metodos y metricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
8.2
Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
vi
IX CONCLUSIONES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.1
72
Problemas resueltos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
9.1.1
Problema 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
9.1.2
Problema 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
9.1.3
Problema 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
9.1.4
Problema 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
9.1.5
Problema 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
9.2
Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
9.3
Contribuciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
9.4
Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
APENDICE
A
SINTAXIS QUALITY REQUIREMENTS DSL . . .
76
APENDICE
B
GUIA PARA USAR ARCHIMET . . . . . . . . . . . .
78
ENTERPRISE ARAPENDICE
C
FUENTES TRANSFORMACION
CHITECT A ARCHIVOL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
DE ARCHIVOL
APENDICE
D FUENTES DE TRANSFORMACION
A SOFTWAREQN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
REFERENCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
vii
viii
LISTA DE TABLAS
1
Escenario de calidad de ejemplo . . . . . . . . . . . . . . . . . . . . . . . . .
13
Escenario de calidad de rendimiento . . . . . . . . . . . . . . . . . . . . . .
39
Escenario de calidad de flexibilidad . . . . . . . . . . . . . . . . . . . . . . .
39
Escenario de calidad de reutilizacion . . . . . . . . . . . . . . . . . . . . . .
39
Tiempos de servicio estimados para servicios atomicos . . . . . . . . . . . .
43
Tiempos de servicio calculados para servicios compuestos . . . . . . . . . .
46
Soluci
on de modelo de colas de mas bajo nivel . . . . . . . . . . . . . . . . .
47
Ejemplo de resultado al evaluar los requerimientos 3 arquitecturas candidatas 47
Servidor de aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
10
Servidor de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
11
Tiempos de servicio de servicios atomicos . . . . . . . . . . . . . . . . . . .
61
12
Tiempos de servicio calculados usando ArchiMet . . . . . . . . . . . . . . .
61
13
Comparaci
on de herramientas existentes para la evaluacion de rendimiento
(parte 1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
Comparaci
on de herramientas existentes para la evaluacion de rendimiento
(parte 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
14
ix
LISTA DE FIGURAS
1
Impacto de usar una SOA sobre el atributo de calidad rendimiento [57] . . .
Proceso de negocio de registrar inmueble . . . . . . . . . . . . . . . . . . . .
Servicios candidatos identificados durante el analisis . . . . . . . . . . . . .
ejemplo de vista de tipo modulo
. . . . . . . . . . . . . . . . . . . . . . . .
11
ejemplo de vista de tipo componente conector . . . . . . . . . . . . . . . . .
12
Escenario de calidad[42] . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
Estructura b
asica de una SOA . . . . . . . . . . . . . . . . . . . . . . . . .
16
Ejemplo de ecosistema SOA . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
Niveles de abstracci
on UML[43] . . . . . . . . . . . . . . . . . . . . . . . . .
23
10
Niveles de abstracci
on Archivol . . . . . . . . . . . . . . . . . . . . . . . . .
25
11
Paquete candidate de Archivol - Fuente [73] . . . . . . . . . . . . . . . . . .
26
12
Paquete evaluation de Archivol - Fuente [73] . . . . . . . . . . . . . . . . . .
28
13
Modelo Archivol con elementos de la arquitectura de InAlpes . . . . . . . .
29
14
Modelo Archivol de arquitectura candidata para InAlpes . . . . . . . . . . .
30
15
Modelo Archivol con definicion de SOA . . . . . . . . . . . . . . . . . . . .
30
16
efecto Trashing[8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
17
Modelo de colas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
18
Proceso de evaluaci
on de arquitectura de software usando ArchiMet . . . .
36
19
Arquitecturas candidatas para evaluar . . . . . . . . . . . . . . . . . . . . .
37
20
Modelo de colas para arquitectura A . . . . . . . . . . . . . . . . . . . . . .
41
21
Diagrama de tiempos de SOA con comunicacion sincronica
. . . . . . . . .
44
22
Diagrama de tiempos de SOA con comunicacion asincronica . . . . . . . . .
45
23
Arquitectura de plug-ins ArchiMet . . . . . . . . . . . . . . . . . . . . . . .
50
24
Editor SOMF de Enterprise Architect . . . . . . . . . . . . . . . . . . . . .
53
25
Asistente para transformar SOMF a Archivol . . . . . . . . . . . . . . . . .
53
26
Metamodelo de Enterprise Architect . . . . . . . . . . . . . . . . . . . . . .
54
27
Ejemplo de modelo Archivol generado a partir de diagrama de dise

no de
relaciones SOMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
28
Interfaz definida para plug-ins de evaluacion . . . . . . . . . . . . . . . . . .
56
29
Asistente para evaluar arquitecturas candidatas . . . . . . . . . . . . . . . .
56
30
Metamodelo de colas para recursos de software . . . . . . . . . . . . . . . .
57
31
Comparaci
on de tiempos de servicio para RiskScoring Service . . . . . . . .
62
32
Comparaci
on de tiempos de servicio para ValidateCustomerProperty Process
usando Arquitectura A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
Comparaci
usando Arquitectura C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
34
Comparaci
on de flujo maximo para ClintonList Service
. . . . . . . . . . .
63
35
Comparaci
on de flujo maximo para Notification Service . . . . . . . . . . .
64
36
Comparaci
on de flujo maximo para Notification Service con 11 peticiones de
entrada por segundo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
37
Comparaci
on de flujo maximo para RiskScoring Service . . . . . . . . . . .
65
38
Comparaci
on de flujo maximo para ValidateCustomerProperty Process usando Arquitectura A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
Comparaci
on de flujo maximo para ValidateCustomerProperty Process usando Arquitectura C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
40
Nuevo proyecto en Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
41
Nuevo archivo de requerimientos de calidad . . . . . . . . . . . . . . . . . .
79
42
Abrir con Quality Requierements Editor . . . . . . . . . . . . . . . . . . . .
80
43
Asistente de contenido de Quality Requirements Editor . . . . . . . . . . .
81
44
Modelo Archivol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
45
Nuevo Architecture from Enterprise Architect File . . . . . . . . . . . . . .
82
46
Datos de entrada para asistente de transformacion de Enterprise Architect a

Archivol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
47
Nuevo Candidate Architecture Evaluation . . . . . . . . . . . . . . . . . . .
84
48
mostrar vista Archivol Evaluation
. . . . . . . . . . . . . . . . . . . . . . .
85
49
Visor de evaluaci
on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
33
39
CAPITULO I
INTRODUCCION
Seg
un Porter[10], las organizaciones se enfrentan a problemas complejos como la diferenciaci
on y la disminuci
on de costos. Como consecuencia, estas deben adaptarse rapidamente
al mercado cambiando sus procesos de negocio o creando nuevos productos. A partir de
estas exigencias, las organizaciones pueden decidir adoptar el estilo arquitectural orientado a servicios (SOA)[62], adquiriendo beneficios como: mayor flexibilidad, agilidad en sus
procesos, y reducci
on de costos[1].
SOA consiste en la implementacion de servicios que representan capacidades ofrecidas
por aplicaciones de la organizacion o de terceros. Los servicios especifican el contrato y
la capacidad ofrecida, mediante el uso de interfaces independientes de una implementaci
on
concreta. La identificaci
on y dise
no de los servicios a implementar dependen de las habilidades del arquitecto, la metodologa utilizada y el proposito de la solucion. Sin embargo, es
necesario identificar si realmente es SOA la alternativa correcta, analizando desde diferentes
enfoques sus ventajas y desventajas para evitar utilizarlo por moda o por persuasion de los
proveedores de tecnologa[66]. Adicionalmente, es posible implementar cada servicio y en
general una SOA de diferentes formas[59] y es responsabilidad del arquitecto decidir cu
al
alternativa ofrece el mayor beneficio para el negocio.
Para determinar cu
al es la mejor alternativa de dise
no las organizaciones deben realizar
una evaluaci
on de las diferentes arquitecturas propuestas a la luz de las propiedades de
calidad que beneficia cada una. Esta evaluacion puede ser cualitativa, cuantitativa o las
dos[22]. Las evaluaciones cualitativas normalmente se hacen por medio de metodos de
evaluaci
on basados en escenarios por lo que permiten la comunicacion con los stakeholders
a cambio de un costo de tiempo y horas de consultora de un experto en temas especficos

a evaluar. La evaluaci
on cuantitativa por lo general se hace implementando prototipos,
siendo este un enfoque muy costoso por lo cual se realiza solo en raras ocasiones donde el
beneficio justifica el costo[23].
Un requerimiento que normalmente se subestima es el rendimiento. Seg
un Smith y
Williams[38], las organizaciones siempre adoptan un posicion fix-it later en donde, siempre
los problemas de rendimiento se solucionan al final del ciclo de desarrollo por medio de la
optimizaci
on del c
odigo. Diferentes trabajos se han propuesto para permitir la evaluaci
on
de rendimiento en software[44], estos trabajos deben ser implementados en herramientas
para facilitar al evaluador la evaluacion de la arquitectura.
Performance
An SOA approach can have a negative impact on the

performance of an application due to network delays, the
overhead of looking up services in a directory, and the
overhead caused by intermediaries that handle
communication. The service user must design and
evaluate the architecture carefully, and the service
provider must design and evaluate its services carefully
to make sure that the necessary performance
requirements are met.
Red
Figura 1: Impacto de usar una SOA sobre el atributo de calidad rendimiento [57]
El rendimiento es un atributo de calidad que no beneficia directamente SOA, por lo que
se recomienda realizar una evaluacion para validar que la arquitectura propuesta cumple
con los requerimientos de rendimiento[57]. La figura 1 es un fragmento de un estudio
realizado por el SEI donde se presenta el impacto de usar SOAs sobre diferentes atributos
de calidad. No satisfacer los requerimientos de rendimiento puede traer consecuencias graves
para la organizaci
on como la perdida de sus clientes, perdida de credibilidad entre sus socios
de negocio[26]. Diferentes autores han documentado retrasos, sobrecostos y problemas de
imagen por causa de no evaluar el rendimiento desde el inicio del desarrollo[7][3]. Smith y
Williams presentan varios casos reales de software con problemas de rendimiento[38].
Finalmente, diferentes estudios han encontrado que no es lo mismo dise
nar pensando en
rendimiento, que dise
nar y optimizar al final del ciclo de vida del software[26] por: 1) La
optimizaci
on del c
odigo no garantiza el rendimiento esperado, es solo un mejor esfuerzo por
arreglar un defecto de calidad. 2). Optimizar el codigo puede traer consecuencias graves
2
como la perdida de otros beneficios por los cuales se escogio el dise

no original.
1.1
Problema
En este trabajo se identificaron los siguientes problemas en la evaluacion de SOAs, en

particular con respecto al atributo de calidad rendimiento:
Hacer evaluaci
on cuantitativa de una arquitectura de software es costoso, mas en una
SOA al ser una arquitectura distribuida y donde la infraestructura es muy compleja
teniendo en cuenta la variedad de middleware existente.
Cuando no se implementan prototipos, el resultado de la evaluacion de una arquitectura de software es subjetivo y depende de quien realiza la evaluacion.
Aplicar metodos formales para la evaluacion de rendimiento no es natural para los
practicantes, se debe tener conocimientos especializados como teora de colas, redes
de petri o procesos estoc
asticos. Adicionalmente debe saber como crear un modelo de
rendimiento a partir de su arquitectura. Finalmente la mayora de las herramientas
existentes asumen conocimiento de esta teora.
Algunas herramientas existentes para evaluar rendimiento dicen integrarse con el ciclo
de vida del software, pero este inicia desde la captura de los requerimientos, que son
principalmente importantes para validar una arquitectura de software, las herramientas para evaluar rendimiento no tienen en cuenta los requerimientos especficos de
rendimiento ni de otros atributos de calidad.
En algunos casos no se hace evaluacion del dise
no, algunas veces porque el costo de
conformidad es mayor que el costo de no conformidad. Es decir, las organizaciones no
ven justificado el costo de evaluar una arquitectura.
Realizar optimizaciones de codigo no garantiza el mejor rendimiento y puede afectar
otros beneficios que provee la arquitectura utilizada.
1.2
Objetivo general
Este trabajo se propone para apoyar las actividades de evaluacion de arquitecturas de software de forma cuantitativa teniendo en cuenta los requerimientos de calidad especficos.
Este trabajo debe permitir evaluar arquitecturas orientadas a servicios desde la perspectiva
de rendimiento pero debe ser extensible para permitir implementar otro tipo de evaluaciones. Para esto se propone una herramienta que aplica la ingeniera dirigida por modelos
(MDE) con la cual se logra reutilizar informacion de la documentacion de la arquitectura
de software.
1.3
Objetivos especficos
1. Dise
nar e implementar un lenguaje especfico de dominio (DSL) que permita especificar los requerimientos de calidad que se deberan tenerse en cuenta para la evaluaci
on
de la SOA.
2. Implementar un mecanismo de evaluacion de arquitecturas basado en modelos.
3. Implementar un mecanismo para calcular el beneficio de cada alternativa evaluada a
partir de los requerimientos de calidad, siendo este beneficio el puntaje que decida
cu
al de las alternativas es mejor.
4. Implementar la evaluaci
on de rendimiento sobre SOAs.
5. Implementar un conector con una herramienta conocida de dise
no de software.
6. Revisar y ajustar el metamodelo de arquitectura de software Archivol.
1.4
Contribuciones
En este trabajo se presenta ArchiMet, una herramienta basada en modelos[51] que asiste
en la evaluaci
on cuantitativa de una arquitectura orientada a servicios (SOA). ArchiMet
permite evaluar una SOA con respecto a varios atributos de calidad y maneja adecuadamente los conflictos entre requerimientos (tradeoffs en ingles). En este trabajo se presenta
la implementaci
on de la evaluacion del atributo calidad rendimiento y se deja abierta la
posibilidad de implementar m
as evaluaciones como reutilizacion, seguridad, disponibilidad,
4
entre otros. Tambien se puede realizar una implementacion de evaluacion de costo para
realizar un an
alisis costo-beneficio.
ArchiMet aprovecha la documentacion de la arquitectura de software que se produce
durante el ciclo de vida de construccion de software[75]. Esta informacion es transformada
a un modelo para utilizar una estrategia dirigida por modelos que permita realizar la evaluacion de la arquitectura. El resultado que presenta la herramienta lo puede utilizar un
arquitecto como un criterio m
as dentro de su toma de decisiones.
Dentro de las contribuciones de ArchiMet se encuentan: 1) un DSL para expresar requerimientos de calidad de una arquitectura. 2) Un transformador de modelos productidos
por la herramienta Enterprise Architect a Archivol(ver captulo 3). 3) Un metamodelo para
expresar modelos de colas de software (ver captulo 5). 4) Un transformador de modelos
Archivol a modelos de colas de software (ver captulo 5). 5) Un evaluador de modelos
de colas de software. 6) Una solucion generica que permite adicionar mas mecanismos de
evaluaci
on de arquitecturas de software.
1.5
Estructura del documento
El captulo 2 introduce el caso de estudio que se utilizara para explicar los conceptos y
propuestas presentadas en este documento. En el captulo 3 se resumen los conceptos y
teoras relevantes sobre las cuales se basa este trabajo. Entre los conceptos que se encuentran
estan las arquitecturas orientadas a servicios, evaluacion de arquitecturas de software e
ingeniera dirigida por modelos. El captulo 4 presenta los conceptos necesarios para evaluar
rendimiento en software. El captulo 5 describe la propuesta teorica de solucion para cumplir
con los objetivos planteados. El captulo 6 presenta ArchiMet, una herramienta que soporta
la propuesta que se plantea en este trabajo. El captulo 7 presenta la metodologa utilizada
en la experimentaci
on de la propuesta junto con los resultados. En el captulo 8 se presentan
los trabajos relacionados. El captulo 9 contiene las conlusiones de este trabajo junto con las
posibilidades abiertas, incluyendo integracion con otros trabajos desarrollados en paralelo.
En el apendice A, se encuentra el codigo del DSL propuesto para especificar requerimientos
de calidad. El Apendice B contiene una gua paso a paso de como utilizar ArchiMet. En el
Apendice C se encuentra el c
odigo del transformador de Enterprise Architect a Achivol. El
Apendice D se encuentra el c
odigo del componente del transformador de Archivol a modelo
de colas de software.
CAPITULO II
CASO DE ESTUDIO
Este captulo introduce el caso de estudio que se utilizara en este documento para ejemplificar los conceptos y la propuesta. El caso de estudio tambien se utilizo en la experimentaci
on de ArchiMet que se presenta en el captulo 7.
Inmobiliaria de los Alpes (InAlpes) es una empresa dedicada al arrendamiento de bienes
inmuebles. InAlpes tiene tres procesos de negocio principales que son: Registro de un
inmueble, Arriendo de un inmueble y Pagos de comisiones y n
omina.
Durante el caso de estudio se trabajara con el proceso de negocio Registro de un inmueble en el sistema de InAlpes por parte de un cliente para que este pueda para ser arrendado.
La figura 2 presenta el proceso de negocio Registrar inmueble utilizando notacion BPMN[5].
Pool Cliente
Proceso de Registrar Inmueble
Llenar
Entregar
cliente
Evaluar
Pool InAlpes
si
centrales
de riesgo
no
Verificar
certificado
rechazo
si
Aceptar
Publicar
no
Figura 2: Proceso de negocio de registrar inmueble

El proceso de registrar un inmueble comienza con la actividad Llenar registro de cliente
en la que el propietario ingresa en un formulario sus datos personales, la informacion relevante del inmueble y los soportes que acrediten la propiedad del inmueble. En la actividad
Evaluar cliente en centrales de riesgo, se verifica que no exista ning
un impedimento legal
para aceptar a la persona como cliente, para lo cual se utilizan servicios de terceros con el
fin de confirmar que el propietario no pertenece a listas negras. En la actividad Verificar
certificado de tradici
on se verifica que el inmueble no se encuentra impedido por la ley para
ser arrendado y que efectivamente el propietario es la persona que realiza la solicitud. Para
esto se verifica la existencia del certificado de tradicion y libertad que el cliente adjunt
o. Si
hay alg
un problema durante estas validaciones, el agente comercial procede a elaborar una
carta de rechazo del negocio y esta es enviada al solicitante durante la actividad Notificar
rechazo. Si todo sale bien, durante la actividad Aceptar inmueble se agenda una cita con el
propietario para realizar la visita al inmueble, donde se tomaran las fotos del inmueble y se
proceder
a a firmar un contrato de derechos de arrendamiento. Finalmente en la actividad
Publicar inmueble la informacion del cliente y del inmueble son cargados a las bases de
datos de InAlpes para iniciar la labor de promocion y arrendamiento del inmueble.
Para soportar su operaci
on y estrategia de negocio, InAlpes debe seleccionar una arquitectura de acuerdo a sus necesidades. Siguiendo una metodologa de desarrollo SOA[63][64][47]
en la construcci
on de su soluci
on tecnica, InAlpes realizo un analisis orientado a servicios en
el cual el objetivo principal fue identificar los servicios candidatos. Los servicios candidatos
que identific
o InAlpes para soportar el proceso de negocio de registrar inmueble se muestran
en la figura 3.
Business
Application
+ Customer Service
+ Property Service
+ RiskScoringService
+ ClintonListService
+ DataCreditoService
Utility
+ Notification Service
Figura 3: Servicios candidatos identificados durante el analisis

Customer service, Property service y Risk scoring service son servicios de negocio con
interfaces independientes de la aplicacion que los provee. Customer service permite realizar
operaciones de consulta, creaci
on, actualizacion y eliminacion de clientes (CRUD). Property
service se comporta de forma similar pero para la entidad de negocio inmueble. Risk scoring
service permite validar tanto clientes como inmuebles.
En el entorno en el que opera InAlpes, existen dos centrales de riesgo para personas
naturales, Data credito y la lista clinton. Para el caso de bienes inmuebles se utiliza un
certificado de tradici
on y libertad el cual contiene la informacion de los propietarios del
inmueble. Los servicios Clinton service y Datacredito service son servicios provistos por las
correspondientes centrales de riesgo y permiten la validacion de una persona natural a partir
de su n
umero de identificaci
on. Finalmente, tambien se identifico el servicio Notification
service, que permite enviar notificaciones a diferentes actores que intervienen en el negocio
de InAlpes, en este caso, los clientes.
En los captulos siguientes se presentaran diferentes requerimientos y arquitecturas candidatas usadas en la evaluaci
on de rendimiento para InAlpes. Finalmente en el captulo 7
se presentar
a en detalle la solucion tecnica de InAlpes construida para probar ArchiMet.
10
CAPITULO III
CONTEXTO
3.1
Arquitectura de software
Se considera como padres de la arquitectura de software a Dijkstra y Parnas quienes identificaron la importancia de la descomposicion estructural del software. Luego David Garlan y
Mary Shawn[15][18] introdujeron los estilos arquitecturales. Actualmente existen multiples
definiciones de arquitectura de software, entre las mas conocidas se encuentran las de Bass,
Clements y Kazman[42], Perry y Wolf[14] y Taylor, Dashofy y Medvidovic[70].
Para Bass, Clements y Kazman, arquitectura de software es el conjunto de estructuras
necesarias para razonar acerca del sistema. Esto incluye elementos de software, relaciones
entre ellos y las propiedades tanto de los elementos como de las relaciones.
Taylor define arquitectura de software como las principales decisiones de dise
no de un
sistema. Donde las decisiones de dise
no incluyen las dimensiones de estructura, comportamiento funcional, interacci
on, propiedades no funcionales e implementacion.
Dewayne Perry y Alexander Wolf definen arquitectura como el conjunto de elementos,
forma y raz
on. Por elementos se refieren a elementos de procesamiento, elementos de datos,
elementos conectores. Los tres se resumen en los conceptos arquitecturales, componentes
y conectores. Estos elementos representan el Que de la arquitectura. Por forma hacen
referencia a el modo en que los elementos del sistema son organizados en la arquitectura
es decir, la topologa de la arquitectura. La forma contesta las preguntas Como de la
arquitectura. Finalmente raz
on es la intencion de los dise
nadores del sistema, restricciones
externas, patrones y estilos seleccionados. La razon contesta las preguntas Porque de la
arquitectura.
Una arquitectura de software se describe por medio de vistas[75], donde cada vista es una
proyecci
on que hace enfasis en ciertas propiedades mientras oculta otras. Bass, Clements y
Kazman[40] definen 3 tipos de vistas (modulo, componente-conector y asignacion) mientras
que Rozanski y Woods[49] definen otras (funcional, informacion, concurrencia, desarrollo,
despliegue y operacional).
Para Bass, Clements y Kazman las vistas se clasifican de acuerdo a los estados del software: c
odigo, ejecuci
on y asignacion. En el estado de codigo, es importante proyectar la
descomposici
on, generalizaciones y usos entre los elementos. En el estado de ejecuci
on es
importante conocer como se sincronizan los elementos, en que procesos se ejecutan, como se
comunican, etc. En las vistas de asignacion se pretende comprender donde se ejecuta el software, donde se desarrolla, y demas relaciones por el estilo. La figura 4 presenta un ejemplo
de una vista modulo donde se observa la relacion de las entidades utilizadas en el proceso
Registrar inmueble de InAlpes. La figura 5 presenta una vista de tipo componente conector
utilizando notaci
on UML[77]. En esta figura se muestra una posible arquitectura de soluci
on
para InAlpes en donde un componente de orquestacion se encuentra entre los componentes
de presentaci
on y los componentes de negocio. Tambien se observa la comunicacion entre
algunos de los componentes que puede ser local o SOAP[33] sobre HTTP[24].
Person
RegisterPropertyDTO
id: int
name: string
documentType: string
documentNumber: string
Property
-
id: int
registerNumber: string
Video
-
content: base64binary
Photo
-
content: base64binary
Figura 4: ejemplo de vista de tipo modulo
3.1.1
Atributos de calidad
La arquitectura de software surge como una respuesta a los atributos de calidad. Los
atributos o propiedades de calidad son requerimientos transversales a los requerimientos
11
Clientes
Portal
Ejecucin
Cliente futuro
1
Cliente futuro
N
local
Orquestacin
Administracin
Consulta
Ejecucin
Bonita BPM
SOAP connector
soap/http
soap/http
soap/http
Services
Servicio de
negocio 1
Servicio de
negocio n
Servicio de
aplicacin 1
Servicio de
aplicacin n
Providers
Open bravo
ERP
Gmail
Clientes
Figura 5: ejemplo de vista de tipo componente conector

funcionales. Existen diferentes clasificaciones de atributos de calidad[42][17][53]. Los siguientes son atributos de calidad que se tienen en cuenta con frecuencia al dise
nar una arquitectura de software seg
un Bass[42]: rendimiento, disponibilidad, usabilidad, modificabilidad,
seguridad, interoperabilidad.
Esta no es la u
nica clasificacion de atributos de calidad, otros autores han propuesto
diferentes nombres y estructuras (sub-atributos de calidad), la ISO 9126-1[53] por ejemplo
incluye el atributo de calidad portabilidad. Adicionalmente, en la industria, algunas veces
aparecen nombres de requerimientos de calidad no documentados. Lo anterior genera un
problema de ambig
uedad, que puede llevar a mal interpretar los requerimientos de calidad de
un software. El SEI (Software Engineering Institute) propuso los escenarios de calidad[42]
como soluci
on a este problema.
Los escenarios de calidad son a los atributos de calidad como los casos de uso son
a los requerimientos funcionales. Por medio de un escenario de calidad se especifica en
forma detallada el requerimiento de calidad incluyendo cuando inicia, quien lo inicia, en
que condiciones debe poder ser manejado, sobre que parte especfica recae el requerimiento,
12
Fuente
Estmulo
Artefacto
Entorno
Respuesta
Medida
Usuarios de la aplicacion
Incremento en la cantidad de mensajes
Portal
Tiempo de ejecucion
Procesar los mensajes entrantes
Mnimo con una frecuencia de 11 transacciones por segundo
Table 1: Escenario de calidad de ejemplo
la respuesta que se debe dar al requerimiento y finalmente como se va a medir esa respuesta.
La figura 6 presenta un escenario de calidad como lo define el SEI mientras que la tabla 1
presenta un escenario de calidad para InAlpes.
Figura 6: Escenario de calidad[42]
3.1.2
Dise
no de software
Hablar de arquitectura de software es hablar del dise

no del software para satisfacer los
requerimientos de calidad. En general el proceso de dise
no de software se puede resumir en
los siguientes 4 pasos[13]:
Identificar un conjunto de combinaciones viables.
Seleccionar y desarrollar la mejor combinacion
Realizar un dise
no detallado de la mejor combinacion.
Evaluar y refinar de acuerdo a requerimientos de produccion, distribucion y consumo.
13
Para identificar el conjunto inicial de posibles alternativas de dise

no un arquitecto puede
recurrir a diferentes tecnicas como las que se describen a continuacion. Una lista m
as
completa se encuentra en[70].
3.1.2.1
Utilizar de las nociones basicas
La primera alternativa que tiene quien dise

na software, es utilizar las nociones o principios
basicos de la ingeniera como:
separaci
on de necesidades o preocupaciones: por medio de la division de un
problema en partes independientes. Por ejemplo: la interfaz grafica es independiente
de la l
ogica de negocio.
Abstracci
on: es ir hacia arriba, desde los detalles hacia la consolidacion de conceptos.
Luego hacia abajo para ir refinando las estructuras.
3.1.2.2
Utilizar la experiencia
Existen muchas formas de utilizar experiencia previa. Las arquitecturas de software de

dominio especfico son producto de conocimiento adquirido durante la experiencia de c
omo
construir aplicaciones completas para un dominio particular. Se puede decir que son arquitecturas de referencia para un dominio particular, libreras de componentes de software que contienen partes reusables y un metodo para escoger y configurar componentes
en una instancia de una arquitectura de referencia. Otra alternativa es utilizar patrones
arquitecturales[42]. Un patr
on arquitectural es un conjunto de decisiones arquitecturales
de dise
no aplicables en un problema de dise
no particular, parametrizadas para soportar
diferentes contextos de desarrollo en donde se encuentre el problema. En SOA existe el
patr
on Enterprise Service Bus[81] as como existe el patron Modelo-Vista-Controlador para
el desarrollo de interfaces gr
aficas. Los patrones de dise
no se encuentran documentados en
catalogos completos, algunas veces clasificados por estilo de aplicacion o por tipo de requerimiento que satisfacen. Ejemplos de estos catalogos son los propuestos por Gamma[16],
Taylor[70] y Erl[69].
14
Los pasos de seleccionar la mejor combinacion y detallar el dise

no dependen de las habilidades del arquitecto de software, pero finalmente se debe evaluar el dise
no para verificar
que el dise
no maneja adecuadamente todos los requerimientos. Esta evaluacion se explica
al final de este captulo.
3.1.3
Decisiones de dise
no
Una forma de describir que es arquitectura de software es: Arquitectura de software es el

resultado de un continuo proceso de decisiones de dise
no. Esta definicion no esta lejos de
la definici
on propuesta por Talor[70].
La anterior definici
on crea dos nuevas preocupaciones. 1) Como documentar las decisiones de dise
no. 2) Como guiar al arquitecto en la toma de estas decisiones de dise
no.
Jansen y Bosch[48] identificaron el problema de la vaporizacion del conocimiento arquitectural. Sobre este problema se han propuesto diferentes soluciones que se basan en el
uso de plantillas, ontologas, metamodelos y patrones arquitecturales para documentar las
decisiones de dise
no tomadas durante la elaboracion de una arquitectura de software.
Para guiar el proceso de toma de decisiones se han propuesto sistemas de soporte para la
toma de decisiones (Decision Support Systems en ingles), as como se han creado metodos
de evaluaci
on o an
alisis de una arquitectura de software. Estos metodos de evaluaci
on se
explican m
as adelante en este captulo.
3.2
Arquitecturas Orientadas a Servicios
Un estilo arquitectural particular es SOA (Arquitectura Orientada a Servicios). SOA permite maximizar la interoperabilidad y reutilizacion de las aplicaciones de una organizaci
on
manteniendo un bajo acoplamiento entre ellas. Al mismo tiempo acelera la respuesta del
negocio al mercado (time to market en ingles) dando una gran agilidad a la organizaci
on
para adaptarse sin problemas a los cambios requeridos.
El principio de SOA es la separacion de responsabilidades en peque
nos elementos llamados servicios, cada servicio se encarga de un problema especfico. Adicionalmente, cada
servicio es aut
onomo, lo que permite lograr un bajo acoplamiento. Un servicio puede agrupar otros servicios, lo que se denomina composicion de servicios o un servicio compuesto.
15
En su forma m
as b
asica, SOA se define como la interaccion entre un consumidor, un
proveedor y un localizador[47], la figura 7 presenta una SOA en su forma mas basica. Idealmente existe un registro de servicios, donde se suscribe el proveedor del servicio. Cuando
el consumidor desea invocar el servicio debe consultar inicialmente el registro de servicios
para obtener la direcci
on del servicio que debe invocar.
Con la aplicaci
on en la industria, SOA evoluciono permitiendo integracion de otro tipo de
componentes como enrutadores, transformadores e interceptores de mensajes[81]. Tambien
se introdujo conceptos como composicion, orquestacion y coreografa de servicios, finalmente
estandares para el manejo de transacciones, compensacion, coordinacion entre otros[47].
Figura 7: Estructura basica de una SOA

Por sus caractersticas, SOA es la estrategia que utilizan las organizaciones que buscan
alinear su negocio por medio de una arquitectura empresarial con sus componentes de
tecnologa, ll
amense aplicaciones, fuentes de datos o infraestructura.
La forma m
as com
un de implementar una SOA es utilizando servicios web[47] (Web Services en ingles), aunque no es la u
nica alternativa as como usar servicios web no es lo mismo
que implementar SOA. Otras tecnologas para implementar SOA puede ser CORBA[27],
SCA[72], REST[32], JEE[2], .NET[37], Middleware de mensajera entre otros.
16
3.2.1
Clasificaci
on de servicios
Los servicios que conforman una SOA se pueden clasificar en tipos (service mode[47] en
ingles) y roles.
3.2.1.1
Tipos de servicio
El tipo es una clasificaci

on permanente basada en el tipo de logica que provee el servicio.
Los tipos dentro de los cuales se puede clasificar un servicio son:
Servicio de aplicaci
on: cuando la logica del servicio es derivada de una soluci
on
tecnol
ogica existente.
Servicio de negocio: cuando el servicio contiene logica de negocio independiente
las soluciones tecnol
ogicas existentes. Un servicio de negocio puede ser orientado por
una actividad o por una entidad. Orientado por una actividad quiere decir que su
l
ogica est
a alineada con una o mas actividades de un proceso de negocio. Orientado
por entidad significa que contiene logica para manipular alguna de las entidades del
negocio.
Servicio de proceso: cuando es un servicio compuesto que representa un proceso
de negocio implementado por medio de orquestacion.
Servicio de utilidad: cuando el servicio es generico, es decir, se sabe que contiene
l
ogica reutilizable por otros servicios.
3.2.1.2
Roles de un servicio
El rol es una clasificaci

on temporal basada en el papel que desempe
na el servicio durante
el procesamiento de un mensaje. Dentro de los roles que puede asumir un servicio se
encuentran:
Proveedor: un servicio se considera proveedor cuando es llamado para completar una
operaci
on solicitada. Un servicio proveedor es equivalente a un servidor en un estilo
arquitectural cliente-servidor. Aunque un proveedor normalmente retorna el resultado
de la operaci
on ejecutada, existen casos en donde no se retorna informacion.
17
Consumidor: un consumidor es quien enva un mensaje de solicitud a un proveedor.

Siguiendo con la similitud entre SOA y el estilo cliente-servidor, un solicitante en SOA
es lo que en un estilo cliente-servidor se llama cliente.
Intermediario: un intermediario es quien recibe el mensaje y lo enruta hacia otro
intermediario o el proveedor. Tambien puede recibir el mensaje de respuesta entregado
por el proveedor y enrutarlo a otro intermediario o al solicitante. Los intermediarios
pueden clasificarse en pasivos o activos. Los intermediarios pasivos se encargan de
enrutar mensajes. Los intermediarios activos realizan modificaciones en el mensaje y
luego lo enrutan. Otra clasificacion de intermediarios se puede encontrar en [63].
3.2.2
Comunicaci
on entre servicios
La comunicaci
on entre un consumidor y un proveedor (o intermediario) se puede realizar
utilizando diferentes patrones de comunicacion comunes en aplicaciones distribuidas.
request-response: el consumidor enva un mensaje al proveedor, mientras el proveedor procesa la solicitud el consumidor bloquea el procesamiento. Cuando el proveedor
ha procesado la solicitud enva respuesta al consumidor y este continua su procesamiento.
invocaci
on asincr
onica (fire and forget en ingl
es): en este caso el consumidor
enva un mensaje asincr
onicamente a uno o mas proveedores.
publicaci
on-suscripci
on: Existe una lista conocida de suscriptores a quienes se
envan los mensajes de forma asincronica.
3.2.3
Notaci
on
Existen dos notaciones propuestas para modelar SOAs, SoaML[6] y SOMF[63].

3.2.3.1
Service Oriented Modeling Framework
SOMF es un framework propuesto por Bell[63] que busca simplificar problemas de SOA por
medio de modelos. Seg
un Bell, usando modelos es posible enfocarse en las estrategias de
modelado y no en el c
odigo fuente o en problemas de infraestructura.
18
SOMF no solo define una notacion para modelar diferentes aspectos de una SOA.
Tambien define toda una metodologa y unos principios que permiten guiar el proceso
de encontrar una soluci
on usando SOA. Entre otras cosas, SOMF define un conjunto de
perspectivas que permiten observar la evolucion de los servicios de una SOA a traves del
tiempo.
Entre las perspectivas que propone SOMF para el dise
no de una SOA se encuentran:
relaci
on entre servicios, composicion de la estructura y transacciones. Es de particular
interes en este trabajo la perspectiva de relacion entre servicios que permite observar la
comunicaci
on entre los servicios. Otros trabajos han utilizado esta perspectiva complement
andola con informaci
on de las zonas en que se encuentra cada servicio (proveedor,
consumidor o intermediario) y el proceso de negocio que se soporta. El resultado de esta
perspectiva complementada se llama Ecosistema SOA[76]. SOMF clasifica un conjunto de
factores que se deben tener en cuenta para el dise
no[63] de relaciones entre servicios y define
4 posibles relaciones:
La figura 8 presenta un ejemplo de un Ecosistema SOA. Mientras que la descripci
on de
los elementos que pueden incluirse en un ecosistema SOA se listan a continuacion:
zona: es una agrupaci
on logica de los servicios, por lo general esta agrupacion se hace
de acuerdo al rol que desempe
na el servicio durante la ejecucion de un proceso de
negocio.
consumidor: un consumidor es quien solicita un servicio a un proveedor de un servicio.
servicio at
omico: es un servicio que no se puede subdividir.
servicio compuesto: es un servicio que agrupa otros servicios y se puede dividir en
estos servicios o en otras configuraciones de servicios.
aparentemente unidireccional: se refiere a que un servicio realiza un llamado a
otro servicio sin pasar por un intermediario y no hay una respuesta de la llamada.
19
Clientes
Pool InAlpes
Evaluar
cliente en
si
Verificar
si
Aceptar
Publicar
tradicin
riesgo
no
no
rechazo
Servicios
Validate
Customer
Publish
Upload
Proveedores
Gmail
Customers
Products
(a) Ecosistema SOA - registrar inmueble de InAlpes

Key
sincrnica
Servicio
asincrnica
atmico
(b) Notaci
on
Figura 8: Ejemplo de ecosistema SOA

aparentemente bidireccional: en este caso se espera una respuesta por parte del
servicio llamado.
implcitamente unidireccional: cuando un consumidor no llama directamente al
proveedor ya que debe pasar primero por algunos intermediarios, en este caso no hay
respuesta por parte del proveedor.
implcitamente bidireccional: igual a implcitamente unidireccional pero si hay
respuesta por parte del proveedor.
20
3.3
Evaluaci
on de arquitectura de software
La evaluaci
on de arquitecturas de software permite identificar y mitigar riesgos en la construcci
on de un producto basado en software[36]. La evaluacion de una arquitectura de
software se concentra en los requerimientos de calidad mas que en los requerimientos funcionales. Normalmente la evaluacion se realiza antes de iniciar implementacion, cuando
los cambios en dise
no no son costosos[22][45]. Tambien se puede realizar una evaluaci
on
durante el desarrollo (para hacer seguimiento) o al final de la implementacion para verificar
que el dise
no implementado cumple con los requerimientos del producto.
En el pasado se han propuesto diferentes metodos para evaluar arquitecturas, estos se
han clasificado en basados en cuestionarios y basados en medidas[22].
M
etodos basados en cuestionarios: Las tecnicas basadas en cuestionarios permiten hacer una evaluaci
on cualitativa del dise
no, se basan en preguntas que se realizan sobre la soluci
on propuesta para intentar entenderla e identificar posibles riesgos.
Estas a su vez se clasifican en escenarios, cuestionarios y listas de verificacion. Dentro
de la academia, las tecnicas basadas en escenarios son conocidas por el trabajo del
SEI con sus metodos SAAM[4] (Software Architecture Analysis Method) y ATAM[30]
(Architecture Tradeoff Analysis Method).
M
etodos basados en medidas: Las tecnicas basadas en medidas son mas maduras
y permiten hacer una evaluacion cuantitativa. Estas se clasifican en metricas, simulaciones y prototipos. Las basadas en metricas se basan en interpretaciones sobre
observaciones en intentan establecer una relacion entre las variables que permita luego
aplicar una teora. Las basadas en prototipos son comunes cuando existe una incertidumbre muy alta, se implementa una parte del software que se desea probar y se
mide. Tambien son evitadas por el alto costo de implementar un prototipo.
Independiente de cu
al sea la tecnica de evaluacion a usar, el SEI recomienda hacer la evaluacion de la arquitectura lo m
as pronto posible dentro del ciclo de vida del software[22]. Es
importante tener en cuenta que hacer la evaluacion de la arquitectura genera un costo, este
costo depende del metodo de evaluacion utilizado y del tama
no del proyecto a evaluar[22].
21
Adicional al costo, la evaluacion permite obtener beneficios importantes para la organizacion como:
Financieros: A pesar del costo de evaluar un software, diferentes organizaciones han
reportado un ahorro final en la implementacion de sus soluciones[22].
Mejor documentaci
on: Debido a que el insumo para la evaluacion es la documentaci
on del dise
no, existe un motivador muy fuerte para realizar una documentaci
on
clara y completa.
Identificaci
on de conflictos en requerimientos: Dentro de la evaluaci
on se
pueden encontrar requerimientos que pueden ser incoherentes o entrar en conflicto.
Priorizaci
on de requerimientos: As mismo, en caso de encontrar conflicto entre
los requerimientos se puede asignar una prioridad.
Es importante, tener en cuenta que una arquitectura correcta no garantiza un producto
bien implementado, es necesario realizar seguimiento durante el resto del ciclo de vida del
software, incluyendo implementacion, pruebas y despliegue.
3.4
Ingeniera dirigida por Modelos
Los modelos permiten abstraer conceptos y relaciones importantes del mundo real en forma
de modelos para facilitar su entendimiento. Similar a la tecnica de programacion orientada a
objetos que permite abstraer conceptos del mundo real en forma de objetos para simplificar
el desarrollo de software.
Aunque la programaci
on orientada a objetos contin
ua siendo el paradigma dominante
para el desarrollo de software. Existen ciertas preocupaciones desde puntos de vista diferentes al del desarrollador. Un arquitecto de software requiere tener un nivel de abstracci
on
para comprender ciertas partes crticas del dise
no. Una organizacion se preocupa porque
en la programaci
on orientada a objetos existe una fuerte dependencia de las habilidades del
desarrollador al ser una pr
actica basada en tareas manuales, es decir no hay automatizaci
on
de tareas de desarrollo de software[43].
22
Mientras que en objetos todo se basa en herencia y composicion, en modelos lo principal son las transformaciones[43]. Las transformaciones son manipulacion de modelos por
medio de herramientas especializadas. Para que una herramienta de transformacion pueda
manipular un modelo es necesario un meta-modelo. Un metamodelo es la definicion del
lenguaje de modelado.
La OMG (Object Management Group) creo MDA[41] como herramienta para la producci
on de software orientada a modelos. Debido a la existencia de varios meta-modelos
(UML, SPEM[52], CWM[39]), la OMG propuso MOF[31] (Meta Object Facility), un metameta-modelo. Cada meta-modelo describe un lenguaje para modelar aspectos especficos.
UML[77] define el lenguaje para software orientado a objetos. SPEM define un leguaje para
procesos de desarrollo de software. Tanto UML como SPEM son conformes con MOF, esto
se ilustra en la figura 9
the SPEM
MM
another UML
model M
another
use of m
an execution
X of
program P
a particular
use of m
the CWM
MM
a Pascal
program P
a UML
model M
Level M2
Level M3
the UML
MM
the Pascal
grammar
Level M1
EBNF
the MOF
MMM
Level M0
Figura 9: Niveles de abstraccion UML[43]

MDA consiste en transformar modelos para producir software. Inicialmente se tiene un
modelo independiente de la plataforma (Platform Independent Model en ingles) que permite
modelar aspectos del software como funcionalidad, reglas de negocio, entre otros. Este
modelo es transformado a un modelo dependiente de la plataforma (Platform Dependent
23
Model en ingles) donde se adicionan aspectos tecnicos como estilo arquitectural y otros
conceptos propios de implementacion como vista, contenedor, entre otros. Finalmente este
modelo es transformado a c
odigo en un lenguaje de programacion especfico como Java,
C++, entre otros.
3.5
Archivol
Archivol[?] es el meta-modelo que define el lenguaje para modelar arquitecturas de software. En este trabajo, Archivol es utilizado como base para la evaluacion de arquitecturas.
Archivol ha sido producto de diferentes trabajos de investigacion[76][78]. En cada trabajo
se ha ido refinando Archivol, la version actual es M7, que incluye soporte para variabilidad
en arquitectura (un tema por fuera de este trabajo).
La figura 10 presenta los niveles de abstraccion que se usan al trabajar con Archivol.
Con un nivel cero de abstraccion se encuentra el mundo real, para el caso del software
el mundo real son porciones de codigo u otros artefactos como archivos de configuraci
on,
binarios, entre otros. El primer nivel de abstraccion se logra al modelar estos artefactos.
La arquitectura de software modela los principales elementos del software permitiendo al
arquitecto centrarse en los temas de mayor relevancia, como comprender las relaciones entre
los componentes. El lenguaje que permite modelar una arquitectura de software es Archivol,
que est
a a un nivel de abstraccion mayor. A su vez Archivol es conforme con ECore[60].
ECore es equivalente a MOF, ECore es un meta-modelo para crear meta-modelos es decir,
es un meta-meta-modelo propuesto por Eclipse y es la base de EMF (Eclipse Modeling
Framework) y otras herramientas de Eclipse.
Archivol est
a compuesto de diferentes modulos que permiten expresar diferente informaci
on relevante en una arquitectura de software. Estos modulos son:
Architecture: Dentro de este modulo, se encuentran los conceptos arquitectura y
requerimiento principalmente.
Business: Contiene conceptos de unidad de negocio, stakeholder, concern, que permiten describir el contexto de negocio que rodea la arquitectura de software. En este
trabajo no se hace uso del paquete Business.
24
M3
ECore
M2
Archivol
M1
Arquitectura de software
M0
Cdigo
Figura 10: Niveles de abstraccion Archivol

Quality: Contiene conceptos como estilo arquitectural, atributo de calidad con lo
que permite modelar diferentes estilos de arquitectura de software. En este trabajo
no se hace uso del paquete Quality.
Candidate: Contiene los elementos necesarios para expresar un dise
no de software,
elementos como m
odulo, componente, conector y nodo[75]. As mismo como los conceptos propiedad de un elemento, vista, relacion de elementos, interfaz de un elemento,
entre otros.
Evaluation: Este m
odulo contiene conceptos que representan los resultados de una
evaluaci
on.
ArchiMet hace uso de los modulos candidate y evaluation, por lo tanto el detalle de los
demas m
odulos de Archivol no se describen en el presente documento.
3.5.1
Paquete candidate
Archivol candidate especifica los elementos que conforman un modelo de dise

no arquitectural
junto con las posibles relaciones entre ellos. El nombre candidate, se debe a que un
25
Figura 11: Paquete candidate de Archivol - Fuente [73]

arquitecto puede expresar varios dise
nos que llamamos arquitecturas candidatas.
CandidateArchitecture: Representa una alternativa de dise
no. Una arquitectura
candidata est
a conformada por unos elementos de la arquitectura y unas relaciones entre ellos. Diferentes alternativas pueden usar los mismos elementos pero configurarlos
de forma diferente. Cada arquitectura candidata se describe por medio de diferentes
vistas que permiten resaltar diferentes propiedades de calidad.
ArchitecturalElement: Hace referencia a un activo con el que cuenta una organizaci
on, puede ser un componente de middleware, una carpeta con codigo de un
proyecto, una m
aquina desktop, entre otros. Cualquiera de estos elementos puede
hacer parte de diferentes alternativas de dise
no.
26
ArchitecturalElementProperty: Cada elemento arquitectural presenta diferentes

propiedades que lo describen, por ejemplo, un mainframe tiene 64GB de memoria principal y 5TB de espacio en disco, pero un componente de middleware puede especificar
que tiene un tiempo de respuesta de 2 segundos.
Interface: Una interfaz es el punto de interaccion que ofrece un elemento de la
arquitectura.
Capability: Cada operacion que puede realizar un elemento es una capacidad del
elemento. Los elementos ofrecen sus capacidades por medio de sus interfaces.
Input: Las capacidades ofrecidas por un elemento algunas veces requieren entradas.
Output: A partir de las entradas, se ejecuta una operacion de un elemento y esta
puede entregar informaci
on que llamamos una salida.
View: Diferentes vistas permiten observar diferentes propiedades de la arquitectura,
ejemplos de vistas son: funcional o de informacion. Cada vista puede describir el
sistema de forma est
atica o de forma dinamica.
Model: Un modelo agrupa elementos de la arquitectura y relaciones entre ellos.
ModelElement: Un elemento del modelo es una abstraccion para representar los
elementos que pueden estar presentes en un modelo.
ModeledArchitecturalElement: Es la forma en que se presenta un elemento arquitectural dentro de una arquitectura candidata particular.
Relationship: Permite configurar las relaciones entre elementos arquitecturales para
una arquitectura candidata particular.
Component: Un componente es un elemento en tiempo de ejecucion, puede ser un
proceso, una base de datos, un servicio, etc.
Port: Seg
un [75], los componentes se comunican a traves de los puertos.
Node: Un nodo permite desplegar componentes sobre el.
27
Module: Un modulo es un elemento de la arquitectura en tiempo de desarrollo. Por

ejemplo un proyecto de c
odigo, una clase, un archivo, etc.
Connector: Un conector es un elemento en tiempo de ejecucion que coordina, comunica, y facilita el uso de componentes.
ArchitecturalDecision: Permite describir las decisiones tomadas.
Enumerations: Las siguientes son las enumeraciones definidas en este modulo, las
cuales son utilizadas por conceptos de distintos modulos.
DirectionalityType: .
3.5.2
paquete evaluation
Figura 12: Paquete evaluation de Archivol - Fuente [73]
ArchitectureEvaluation: Sobre una arquitectura candidata se pueden hacer evaluaciones, el concepto evaluacion de arquitectura permite representar el resultado cada
evaluaci
on.
EvaluatedElement: Modela informacion del elemento evaluado.
EvaluatedElementProperty: Permite especificar propiedades del elemento evaluado.
EvaluatedRequirement: Modela informacion del requerimiento evaluado.
28
Un ejemplo de un modelo Archivol es presentado en las figuras 13 y 14. La primera presenta el contenedor de la arquitectura junto con la biblioteca de elementos arquitecturales.
Tambien presenta 2 arquitecturas candidatas que se tendran en cuenta seguramente en una
evaluaci
on. La segunda figura, presenta una de las dos arquitecturas candidatas desde un
punto de vista componente conector. Esta es una SOA por lo tanto la definicion del estilo
arquitectural es presentado en la figura 15
ArchitecturalElementProper...
LifeCycleState
tags
value = Production
LifeCycleState
Component
PropertyService
Component
ClintonListService
tags
value = Production
Component
DataCreditoService
CandidateArchitecture
ArchitectureB
ArchitectureA
architecture
InAlpes
Component
Portal
Mode
value = Utility
view
Ecosystem
Component
CustomerService
Model
RegisterProperty
Component
RiskScoringService
tags
Component
NotificationService
Mode
tags
value = Business
Figura 13: Modelo Archivol con elementos de la arquitectura de InAlpes
29
Model
RegisterProperty
view
Ecosystem
tags
familyType = ComponentAndConnector
level = 0
notation = SOMF
style = SOA
tags
viewType = Static
ModelArchitecturalEleme...
Portal
Connector
Portal ->
ValidateCustomerPropertyProcess
source
source
tags
element = Portal
styleElement = Consumer
tags
directionality = SourceToTarget
tags
viewType = Static
Connector
Portal ->
RegisterPublishProcess
tags
target
target
ModelArchitecturalElement
ModelArchitecturalElement
RegisterPublishProcess
tags
element = ValidateCustomerPropertyProcess
styleElement = CompositeService
tags
ArchitecturalElementProperty
Synchronicity
tags
value = Synchronous
source
source
Connector
ValidateCustomerPropertyProcess ->
RiskScoringService
tags
tags
target
NotificationService
RiskScoringService
tags
styleElement = AtomicService
tags
source
tags
Connector
RegisterPublishProcess ->
PropertyService
Connector
RegisterPropertyProcess ->
CustomerService
tags
tags
target
target
target
source
source
Connector
-> NotificationService
DataCreditoService
view
Portfolio
ArchitectureA
target
PropertyService
CustomerService
tags
styleElement = atomicService
tags
source
Connector
RiskScoringService ->
ClintonListService
Connector
RiskScoringService ->
DataCreditoService
tags
tags
target
ClintonListService
tags
styleElement = atomicService
Figura 14: Modelo Archivol de arquitectura candidata para InAlpes
StyleEleme...
Service
StyleElement
Intermediary
targetElement
StyleEleme...
Directory
Style
SOA
StyleRelationship
ServiceConsumption
source/targetElement
sourceElement
targetElement
StyleRelationship
ServiceLookup
StyleEleme...
Consumer
sourceElement
Figura 15: Modelo Archivol con definicion de SOA
30
31
CAPITULO IV
RENDIMIENTO
Dependiendo del atributo de calidad a evaluar, el equipo de evaluacion puede utilizar diferentes tecnicas para el an
alisis. Barbacci[21] explica por medio de ejemplos la evaluaci
on
de los atributos de calidad Confiabilidad y Rendimiento. Modarres[29] explica diferentes
tecnicas para evaluar confiabilidad, as como Laprie[12] usa modelos de confiabilidad igualmente para evaluar Confiabilidad.
Para evaluar rendimiento principalmente se utiliza teora de colas (queueing theory en
ingles) o teora de asignaci
on (scheduling theory en ingles)[21]. Este captulo describe la
teora de colas b
asica que se utiliza en la solucion propuesta en el captulo 6. Antes de
presentar la teora de colas, se presentan las variables relacionadas con el rendimiento de
un sistema[71][8]:
Tiempo de respuesta: Es el tiempo que debe esperar un consumidor desde que
realiza una petici
on a un servicio hasta que recibe respuesta de este. El tiempo de
espera incluye un tiempo de comunicacion, tiempo de espera cuando el servicio no est
a
disponible (est
a ocupado) y un tiempo de servicio (el tiempo que el servicio demora
en atender la solicitud).
Flujo (throughput en ingl
es): Es la frecuencia con la que un servicio procesa
peticiones. El flujo de un sistema es el mnimo entre la capacidad del mismo y la carga
aplicada al sistema. Este

se comporta como una funcion lineal cuando se aplica una
carga peque
na. La curva alcanza su maximo cuando se incrementa la carga aplicada y
uno de los recursos del sistema alcanza su maxima utilizacion. Generalmente aplicar
una carga m
as alta de la soportada en el sistema perjudica el flujo del sistema[8]. La
figura 16 muestra este comportamiento, llamado thrashing.

Cliente: Es quien inicia una transaccion.
Recurso: Es un elemento que atiende las peticiones.
Lnea de espera: Se refiere a la fila que deben hacer las peticiones antes de acceder
a un recurso.
Tiempo de espera: Es el tiempo que una transaccion debe esperar mientras se
encuentra en la lnea de espera.
Tiempo de servicio: Es el tiempo que le toma a un recurso en atender una petici
on
desde el momento en que el recurso es asignado hasta que es liberado.
Frecuencia de peticiones: Es el n
umero de transacciones por segundo que llegan
al sistema.
Demanda de servicio: Es el tiempo total que se utiliza un recurso por cada
transacci
on.
Utilizaci
on: Es la proporcion del tiempo que un recurso esta ocupado atendiendo
peticiones.
Tama
no de la cola: Es el n
umero total de clientes en la lnea de espera.
Tiempo de permanencia: Es el tiempo total de respuesta teniendo en cuenta si el
recurso es visitado varias veces por la misma transaccion.
Un modelo de colas es una coleccion de K recursos interconectados. Los recursos est
an
acompa
nados de una lnea de espera. Los consumidores (mensajes) se mueven de un recurso
a otro hasta que terminan su ejecucion[8]. La figura 17 presenta un modelo de colas simple
con 2 recursos interconectadas. El primero, representa el recurso fsico CPU de una maquina,
el segundo representa un disco donde se leen y escriben datos. En este caso los dos recursos
son independientes de la carga. Tambien existen recursos dependientes de la carga y recursos
de retraso.
32
Figura 16: efecto Trashing[8]
Sistema
Peticiones
entrantes
CPU
Transacciones
completadas
Disco
Figura 17: Modelo de colas

Un recurso independiente de la carga siempre tiene un mismo tiempo de servicio independiente de la carga aplicada al recurso. Un recurso dependiente tiene un tiempo de
servicio que depende de la carga aplicada sobre el mismo. Un recurso de espera no tiene
lnea de espera y es utilizado para representar recursos dedicados.
Un modelo de colas puede ser abierto o cerrado. Un modelo de colas abierto se caracteriza porque la cantidad de peticiones o mensajes es independiente del sistema (son eventos
externos). No existe un control sobre el n
umero de consumidores (mensajes) en el sistema
y finalmente se considera en equilibrio si el flujo de salida (throughput en ingles) es igual
a la frecuencia de peticiones (arrival rate en ingles). Un modelo de colas cerrado tiene
un n
umero de consumidores (mensajes) fijo que se denomina poblacion, a medida que va
terminando el procesamiento de estos, van ingresando otros para comenzar su ejecuci
on.
33
La teora de colas permite establecer relaciones entre las variables que describen el
rendimiento de un sistema. La simbologa que se utiliza en teora de colas se presenta a
continuaci
on:
Si : Tiempo de servicio por transaccion en el recurso i.
i : Frecuencia de peticiones que llegan al recurso i.
Xi : Flujo del recurso i.
X0 : Flujo del sistema.
Ui : Porcentaje de utilizacion del recurso i.
Vi : N
umero de visitas al recurso i que se hacen por cada peticion.
Di : Demanda de servicio del recurso i.
Ri : Tiempo de respuesta del recurso i.
R0 : Tiempo de respuesta del sistema.
Wi : Tiempo de espera del recurso i.
Ni : Tama
no de la cola del recurso i, incluye los mensajes en espera y los que estan
siendo atendidos.
Las relaciones que entre las variables de rendimiento se propuesto en forma de leyes
operacionales. Las siguientes son las leyes operacionales en las que se basa la teora de
colas:
4.0.2.1
Ley de la utilizaci
on
La ley de la utilizaci
on permite calcular el porcentaje de utilizacion de un recurso y dice
que esta depende del tiempo de servicio y la cantidad de peticiones sobre el recurso.
Ui = Si Xi
34
(1)
4.0.2.2
Ley de demanda de servicio
La ley de demanda de servicio permite encontrar la demanda que tiene un recurso por cada
transacci
on. La demanda de servicio se define como el tiempo requerido en atender una
petici
on en el recurso i, teniendo en cuenta el n
umero de visitas al recurso. Si la petici
on
realiza dos visitas a un recurso cada una de 1 ms de duracion, la demanda del servicio es
de 2 ms por cada petici
on.
Di =
4.0.2.3
Ui
X0
(2)
Ley de flujo forzado
La ley de flujo forzado permite relacionar el flujo de un recurso con el flujo del sistema.
Xi = Vi X0
4.0.2.4
(3)
Ley de Little[9]
La ley de Little permite relacionar el flujo, el tiempo de respuesta y la longitud de un cola.
Ni = Xi Ri
35
(4)
36
CAPITULO V
ESTRATEGIA DE SOLUCION
Este captulo presenta la estrategia de solucion propuesta en este trabajo para atacar los
problemas presentados en el captulo 1.
Figura 18: Proceso de evaluacion de arquitectura de software usando ArchiMet

La figura 18 presenta el proceso de evaluacion de arquitectura de software que se propone.
Inicialmente el arquitecto expresa sus arquitecturas candidatas a evaluar. Seguidamente
el arquitecto especifica los requerimientos de calidad. En el tercer paso, se realiza una
predicci
on del comportamiento de cada una de las arquitecturas candidatas. Finalmente
se comparan los resultados de las predicciones con los requerimientos de calidad. Estos se
presentan en forma de tabla con tantas filas como arquitecturas candidatas y una columna
por cada requerimiento de calidad. Finalmente una columna de total.
5.1
Expresar arquitecturas candidatas

Clientes
Procesos de negocio
Validate
Register
and
Property
Process
Process
Servicios
Service
Service
Service
(a) Arquitectura A
Clientes
Servicios
Service
Service
Service
(b) Arquitectura B
Key
sincrnica
Servicio
asincrnica
atmico
(c) Notaci
on
Figura 19: Arquitecturas candidatas para evaluar
37
Cada arquitectura que se desea evaluar debe ser expresada como un diagrama de dise
no
de relaciones SOMF(ver captulo 3). La figura 19 presenta 2 arquitecturas candidatas para
el caso de estudio InAlpes.
La primera alternativa, presentada en la figura 19a, contiene 2 servicios compuestos de
orquestaci
on que permitiran mayor flexibilidad[47]. La segunda alternativa, presentada en
la figura 19b no contiene servicios de orquestacion para evitar problemas de rendimiento.
Como consecuencia, Portal (consumidor de los servicios) debe realizar llamados individuales
a cada uno de los servicios. Estas dos arquitecturas seran evaluadas durante el resto de este
captulo.
5.2
Especificar los requerimientos de calidad
Diferentes arquitecturas candidatas pueden exhibir en diferente grado un atributo de calidad particular, pero es la organizacion la que define si esta diferencia es apreciada realmente
y como es la curva de utilidad[34]. Por ejemplo, si InAlpes espera recibir 11 tps (transacciones o peticiones por segundo) en alg
un proceso de negocio como Registrar inmuebe, una
arquitectura que soporte 50 tps tiene la misma utilidad que una arquitectura que soporte
200 tps.
La especificaci
on de los requerimientos de calidad por medio de escenarios de calidad
como los presentados en el captulo 3 permite eliminar ambig
uedades. Para especificar la
utilidad asociada a cada requerimiento de calidad es necesario complementar los escenarios
de calidad con el trabajo de Kazman[34] para especificar utilidad sobre las medidas de
respuesta.
Las tablas 2 3 y 4 presentan ejemplos de requerimientos de calidad para la arquitectura
de InAlpes. Para InAlpes la posibilidad de atender un gran n
umero de solicitudes concurrentes es de vital importancia. As mismo, InAlpes desea disminuir sus costos operacionales
y contar con una soluci
on que le permita adaptarse rapidamente a los cambios por ley o
negocio.
En el escenario de calidad de rendimiento (tabla 2) el escenario es iniciado por los
usuarios que registran sus inmuebles en el portal. El escenario se presenta cuando el sistema
38
Fuente
Estmulo
Artefacto
Entorno
Respuesta
Utilidad
Usuarios de la aplicacion
Incremento en la cantidad de mensajes
Portal
Tiempo de ejecucion
Procesar los mensajes entrantes
Procesando 11 tps obtiene 84 puntos
Table 2: Escenario de calidad de rendimiento
Fuente
Estmulo
Artefacto
Entorno
Respuesta
Utilidad
Negocio
Requerimiento funcional
Sistema
Tiempo de dise
no
Implementar cambios
En menos de 90 das obtiene 30 puntos
Table 3: Escenario de calidad de flexibilidad
esta en ejecuci
on y lo que se espera es un flujo de mnimo 11 transacciones por segundo.
Si se logran m
as de 50 transacciones por segundo la utilidad para InAlpes es mejor (puede
registrar m
as clientes en determinado momento).
El escenario de calidad de flexibilidad (tabla 3) es iniciado por un cambio en el negocio.
El nuevo requerimiento funcional debe implementarse en un tiempo menor a 90 das. Si se
logra implementar en menos de 30 das el negocio obtiene un mayor beneficio (menor costo
de implementaci
on y mayor time to market).
El escenario de calidad de reutilizacion (tabla 4) igualmente inicia a partir de un nuevo
Fuente
Estmulo
Artefacto
Entorno
Respuesta
Utilidad
Negocio
Requerimiento funcional
Sistema
Tiempo de dise
no
Reutilizar elementos
Si se mantiene el 20% de elementos obtiene 70 puntos
Si se mantiene el 50% de elementos obtiene 100 puntos
Table 4: Escenario de calidad de reutilizacion
39
requerimiento funcional, donde se requiere que sea implementado maximizando la reutilizaci

on de servicios existentes. InAlpes mide la reutilizacion de servicios como la cantidad
de servicios actuales que contin
uan siendo validos al finalizar la implementacion de un cambio. Si existe una reutilizaci
on de al menos 20% de los servicios existe cierta utilidad, pero
esta realmente es interesante cuando la reutilizacion de los servicios es de al menos un 50%.
5.3
Predecir comportamiento de arquitecturas candidatas por cada atributo de calidad
Para predecir el comportamiento de una arquitectura se utilizan metricas que se obtienen

a traves de observaci
on. Diferentes metricas se han propuesto para diferentes estilos arquitecturales y atributos de calidad. Estas definen diferentes relaciones entre las propiedades
de los elementos que conforman una arquitectura y las relaciones entre estos elementos.
Para el caso de rendimiento se utiliza teora de asignacion o teora de colas (ver captulo 4).
Esta secci
on describe como se realiza la prediccion de comportamiento de una SOA en
terminos de rendimiento.
El enfoque que se propone en este trabajo para predecir el comportamiento de rendimiento
de una SOA consiste en la generacion y solucion de uno o varios modelos de colas por cada
una de las arquitecturas candidatas. Estos modelos de colas son generados a partir de los
diagramas de dise
no de relaciones SOMF(ver captulo 4) y se solucionan utilizando teora
de colas.
5.3.1
Generaci
on de los modelos de colas
Tradicionalmente los modelos de colas para evaluar rendimiento en sistemas basados en

software representan cada recurso fsico ej. CPU y disco (ver captulo 4) como un recurso
dentro del modelo. El enfoque presentado en este trabajo es diferente en la medida en que
en este punto de la arquitectura no se tiene informacion del hardware donde se ejecutar
a la
soluci
on. Por lo tanto es necesario generar los modelos de colas a partir de los servicios que
componen la arquitectura. A diferencia de los recursos fsicos (CPU y disco), los servicios
de una SOA permiten hacer composicion de otros servicios. Como consecuencia, se genera
un modelo de colas por cada servicio compuesto que al resolverlo entrega los valores de
40
rendimiento solo para el servicio compuesto.

Estos modelos generados son modelos de colas abiertos (ver captulo 4), debido a que
en SOA es poco com
un la utilizacion de arquitecturas batch[78] (las cuales se analizan
utilizando modelos de colas cerrados).
La figura 20, presenta los modelos de colas generados para una de las arquitecturas presentadas anteriormente. En el modelo mas especfico se observan los servicios DataCredito
Service y ClintonList Service como recursos. Una transaccion obligatoriamente utiliza el
recurso DataCredito Service, pero con una probabilidad de 0.6 utiliza el recurso ClintonList
Service.
Figura 20: Modelo de colas para arquitectura A
41
En el modelo inmediatamente superior se encuentra el servicio compuesto RiskScoring

Service y el servicio at
omico Notification Service. En el modelo mas general solo existen los
recursos Validate Customer and Property Process y Register and Publish Process, que son
servicios compuestos.
5.3.2
Soluci
on de los modelos de colas
La soluci
on de cada uno de los modelos de colas generados anteriormente proporciona
valores de tiempos de respuesta, flujo y tama
no de la cola para cada uno de los servicios de
la arquitectura y el proceso de negocio soportado.
Los modelos de colas deben resolverse con una estrategia button-up, es decir, de m
as
especfico a m
as general. El modelo de colas mas especfico sera el que se compone de
servicios at
omicos, mientras que el mas general sera el que contiene los servicios que llama
directamente el consumidor (quien ejecuta el proceso de negocio). El resultado de los
modelos de colas especficos es la entrada para resolver los modelos de colas siguientes.
Como se present
o en el captulo 4, para solucionar un modelo de colas se requiere
conocer la carga a la que estar
a expuesto el sistema, el tiempo de servicio de cada recurso y
la cantidad de veces que se visita cada recurso. La carga a la que estara expuesto el sistema
se encuentra especificada en los escenarios de calidad presentados anteriormente en este
captulo. El tiempo de servicio de cada recurso es desconocido hasta ahora y la cantidad
de visitas a cada recurso se obtiene del diagrama de dise
no de relaciones SOMF anotado
con propiedades como order que permiten documentar la secuencia en que se realizan los
llamados a los servicios.
En los enfoques tradicionales que se aplica teora de colas, el tiempo de servicio de cada
recurso se obtiene por medio de observaciones[8]. Estas observaciones son posibles porque
ya se encuentra construido el software. En casos donde no existe software se debe realizar
una estimaci
on del tiempo de servicio. SPE[38] propone una metodologa para estimar,
otra alternativa es estimar por tipo de operacion realizada por el servicio. Estos tipos de
operaciones pueden ser, consulta de datos, modificacion de datos, logica de orquestaci
on,
logica de c
alculos, localizaci
on de un servicio, transformacion de datos, llamado a otro
42
Servicio
SDataCreditoService
SClintonListService
SN otif icationService
SCustomerService
SP ropertyService
Tiempo de servicio
7 ms
9 ms
1.99 s
41 ms
59 ms
Table 5: Tiempos de servicio estimados para servicios atomicos

servicio, entre otros. En el peor de los casos, tendra que implementarse una funcionalidad
especfica para medirla, y aunque esta alternativa es costosa, no lo es a comparaci
on de
implementar un prototipo de una SOA donde se requiere configuracion de middleware y
lidiar con curvas de aprendizaje altas y probar varias combinaciones de comunicacion entre
los servicios.
Esta estimaci
on se debe realizar sobre los servicios atomicos. Para los servicios compuestos el tiempo de servicio se obtiene a partir de la solucion del modelo de colas especfico.
La tabla 5 presenta los tiempos de servicio estimados para los servicios atomicos DataCredito Service, ClintonList Service, Notification Service, Customer Service y Property Service
de InAlpes.
Los servicios DataCredito Service y ClintonList Service tienen un tiempo de servicio
bajo porque realizan operaciones de consulta sencillas sobre una base de datos. Property
Service y Customer Service realizan operaciones de escritura sencillas sobre una base de
datos. El tiempo de Notification Service es el mas alto debido a que el servidor SMTP
(llamado por el servicio) realiza varias operaciones para el enviar cada correo.
5.3.2.1
Tiempo de servicio para servicios compuestos
Por medio de la soluci

on de los modelos de cola especficos es posible obtener el tiempo de
servicio de los servicios compuestos. En otras palabras, el tiempo de servicio de un servicio
compuesto es el tiempo de respuesta que se obtiene a partir del modelo de colas especfico
del servicio compuesto para una sola transaccion (no hay concurrencia ni tiempo de espera
por recursos). La forma en que se soluciona un modelo de colas para obtener este tiempo
de respuesta depende de los tiempos de servicio de los servicios atomicos, los tiempos de
comunicaci
on entre los servicios y el patron de mensajera utilizado en estas comunicaciones
43
entre servicios.
Figura 21: Diagrama de tiempos de SOA con comunicacion sincronica
Cuando la comunicaci
on entre dos servicios es sincronica, el consumidor enva un mensaje al servicio y pasa a estado inactivo o de espera, mientras el mensaje es recibido por el
servicio transcurre un tiempo de comunicacion. El servicio pasa a estado activo mientras
procesa la petici
on del consumidor. Cuando el procesamiento termina, la respuesta es enviada al consumidor y el servicio pasa a estado inactivo. Tras el tiempo de comunicaci
on,
el consumidor vuelve a un estado activo para procesar la respuesta del servicio y continuar
su ejecuci
on. Este comportamiento se presenta por medio de un diagrama de tiempos[77]
en la figura 21.
En este caso, el tiempo de respuesta del modelo de colas es calculado por medio de
la sumatoria de los tiempos de servicio de los servicios que lo componen y los tiempos de
comunicaci
on entre estos servicios. En el caso de que uno de los servicios solo sea llamado
de acuerdo a una condici
on se calculan mejor, peor y tiempo promedio de respuesta. El
44
mejor caso se obtiene cuando no se llama el servicio, el peor cuando se llama el servicio y
el promedio se obtiene multiplicando el tiempo del servicio atomico por la probabilidad de
ser llamado. La ecuaci
on 5 describe como se calcula el tiempo de servicio de un servicio
compuesto SServicioCompuesto a partir de la sumatoria de los tiempos de servicio de los
servicios que lo componen Si y el tiempo de comunicacion entre estos T i i0 multiplicados
por la probabilidad Pi de que se llame el servicio. Para el peor caso k es el n
umero total de
servicios que llama el servicio compuesto y se asume una probabilidad de llamado Pi = 1
para todos los servicios. En el mejor caso k es el n
umero de servicios que llama el servicio
compuesto y que tienen probabilidad Pi = 1.
SServicioCompuesto =
k
X
(Si + Tii0 ) Pi
(5)
Figura 22: Diagrama de tiempos de SOA con comunicacion asincronica

Cuando la comunicaci
on entre alguno de los servicios es asincronica, no se tiene en
cuenta el tiempo de servicio ni el tiempo de comunicacion de este servicio llamado asincronicamente en la sumatoria para calcular el tiempo de servicio del servicio compuesto.
Este comportamiento se presenta por medio de un diagrama de tiempos[77] en la figura 22.
La tabla 6 presenta el resultado de calcular cada uno de los 3 casos para cada uno de
los servicios compuestos presentados en la arquitectura A 19a.
45
Servicio
SRiskScoringService
SV alidateCustomerP ropertyP rocess
SRegisterP ublishP rocess
SP ortal
Peor caso
18 ms
2.018 s
0.1 s
2.119 s
Mejor caso
8 ms
9ms
0.1 s
110 ms s
Caso promedio
13 ms
1.413 s
0.1 s
1.514 s
Table 6: Tiempos de servicio calculados para servicios compuestos

Para el servicio compuesto RiskScoring Service, el mejor caso es cuando no se realiza
llamado al servicio ClintonList Service porque ya desde el llamado al servicio DataCredito
Service se identific
o que el cliente debe ser rechazado. El peor caso ocurre cuando se llaman
los dos servicios. El caso promedio esta asociado a la probabilidad de rechazar el cliente en
el primer llamado.
5.3.2.2
Flujo
El flujo m
aximo de un sistema esta relacionado con el porcentaje de utilizacion de sus
recursos. La utilizaci
on de los recursos se calcula por medio de la ley de la utilizaci
on
(ver captulo 4). La utilizaci
on de un recurso esta data por el factor entre el tiempo de
servicio del recurso y flujo esperado del recurso. El tiempo de servicio del recurso se obtuvo
anteriormente. El flujo esperado de cada recurso se obtiene aplicando la ley del flujo forzado
(ver captulo 4). Esta relaciona el flujo esperado de un sistema con el esperado de un recurso
a partir del n
umero de visitas que se realizan al recurso. Por lo tanto la utilizacion de cada
recurso est
a dada por el tiempo de servicio del recurso Si multiplicada por la probabilidad
de consumo del servicio Pi multiplicado por el n
umero de visitas al recurso Vi multiplicado
por el flujo esperado del sistema. Esta expresion se presenta en la ecuacion 6.
Ui = Si Xi
Xi = Vi X0
Ui = Si Vi X0 P (Vi )
(6)
Si la utilizaci
on de alguno de los recursos se acerca al 100% o esta por encima de este
valor el sistema no soportar
a el flujo X0 especificado.
46
La tabla presenta la utilizacion de los recursos para una de las arquitecturas planteadas
anteriormente para un flujo de 11 tps. Los servicios Notification Service y Validate Customer
and Property Process no permitiran lograr el flujo esperado del sistema.
Recurso (i )
SDataCreditoService
SClintonListService
SRiskScoringService
SN otif icationService
SV alidateCustomerandP ropertyP rocess
SRegisterandP ublishP rocess
Si
7sm
9 ms
8 ms
1.99 s
1.413 s
01 s
X0
11
11
11
11
11
11
Vi
1
1
1
0.7
1
0.3
Xi
11
11
11
7.7
11
3.3
Ui
8%
5%
9%
1539 %
1554 %
33 %
Table 7: Solucion de modelo de colas de mas bajo nivel

En este caso el servicio Notification Service presenta un cuello de botella que se propaga
hacia el servicio Validate Customer Property Process que utiliza un mecanismo de comunicacion sincr
onica.
5.4
Resultado de la evaluaci
on
Con los resultados de los pasos anteriores se determina por cada arquitectura candidata el
puntaje de cada requerimiento de calidad. Para esto se toman las utilidades especificadas en
los requerimientos de calidad y se comparan con los resultados de la evaluacion. La tabla 8
presenta los resultados de evaluar 3 arquitecturas candidatas con tres requerimientos de
calidad
Architectura C
Architectura A
Architectura B
Flexibility
70
70
30
Throughput
84
0
0
Reusability
70
70
70
Total
224
140
100
Table 8: Ejemplo de resultado al evaluar los requerimientos 3 arquitecturas candidatas
Para el requerimiento de calidad Throughput, la arquitectura C obtuvo 84 puntos que

corresponden a la utilidad especificada por InAlpes si la arquitectura logra soportar 11 tps.
Este valor podra ser 100 si al evaluar la arquitectura se hubiese obtenido un resultado de
al menos 101 tps. Los requerimientos de calidad Flexibility y Reusability fueron evaluados
de forma independiente. El total es la suma de los puntajes que obtuvo cada arquitectura.
47
La arquitectura con mayor puntaje sera la que se adapta mas a las necesidades de la
organizaci
on, en este caso InAlpes.
48
49
CAPITULO VI
ARCHIMET
Este captulo presenta ArchiMet. ArchiMet es la implementacion de la propuesta presentada

en el captulo 5. Primero se presenta la arquitectura de la herramienta con la descripci
on
de cada uno de sus componentes principales. Finalmente se explica como se implement
o
cada componente.
6.1
Factores externos
Los siguientes son los principales factores externos que influenciaron el dise
no de la arquitectura de la herramienta de evaluacion ArchiMet.
Archivol es un metamodelo que define un lenguaje para expresar arquitecturas de
software. Diferentes trabajos basados en Archivol se han presentado[78][76] y Otros
se encuentran en desarrollo[80][82]. Por lo tanto se hace necesario interoperar con
modelos Archivol.
Una organizaci
on no realizara la evaluacion de sus arquitecturas candidatas si para
esto debe aprender un nuevo lenguaje de modelado y/o volver a expresar sus dise
nos
en otra herramienta.
Por el alcance de este trabajo solo es posible implementar la evaluacion de rendimiento
utilizando teora de colas, pero no por esto debe terminar el desarrollo de ArchiMet,
se hace necesario permitir la implementacion de otros componentes de evaluaci
on de
otros atributos de calidad como reutilizacion, seguridad, entre otros.
6.2
Arquitectura de ArchiMet
ArchiMet se implement
o utilizando una arquitectura basada en plug-ins eclipse[46]. Cada
plug-in puede conectarse con otros plug-ins de dos formas: 1) por medio de llamado a sus
interfaces p
ublicas como lo define OSGi[56]. 2) por medio de puntos de extension. Los
puntos de extensi
on son definidos por un plug-in y utilizados por otros para extender las
capacidades del plug-in inicial. La figura 23 presenta la arquitectura ArchiMet usando el
estilo de plug-ins eclipse.
dll
SSJavaCOM
eclipsePlugin
co.edu.uniandes.moosas.
archivol.archimet.soaperformance
SOAPerformanceEvaluator
eclipsePlugin
archivol.somfeaimporter
SOMFEAImporter
Wizard
eclipsePlugin
archivol.qualityrequirements
eclipsePlugin
archivol
co.edu.uniandes.moosas.archivol.
evaluation.EvaluationPackage
ArchivolPackage
candidate.CandidatePackage
org.eclipse.ui.newWizards
org.eclipse.emf.ecore.generated_package
co.edu.uniandes.moosas.archivol.archimet.evaluators
eclipsePlugin
QualityRequirements
archivol.archimet
DSLEditor
ArchitectureEvaluation
ArchitectureEvaluation
Wizard
View
Eclipse platform
org.eclipse.ui.editors
eclipsePlugin
org.eclipse.emf.ecore
org.eclipse.ui.views
eclipsePlugin
org.eclipse.ui
org.eclipse.core
org.eclipse.runtime
Figura 23: Arquitectura de plug-ins ArchiMet

Todos los componentes son plug-ins (excepto org.eclpse.core y org.eclipse.runtime). org.
eclipse.ui define varios puntos de extension para crear visores (org.eclipse.ui.views), editores
(org.eclipse.ui.editors) y asistentes (org.eclipse.ui.newWizards). Un visor permite presentar
informaci
on asociada a un elemento dentro del espacio de trabajo de Eclipse. Un editor permite modificar un objeto que se encuentra dentro del espacio de trabajo. Un wizard permite
50
guiar al usuario en la realizaci

on de una tarea, como la evaluacion de una arquitectura.
El coraz
on de ArchiMet es el metamodelo Archivol implementado en el plug-in archivol.
Este permite la manipulaci
on de modelos de arquitectura de software, en este caso con el
prop
osito de facilitar la evaluacion. El plug-in somfeaimporter es un adaptador que permite a ArchiMet interactuar con herramientas de modelado de arquitectura de software
como Enterprise Architect para obtener las arquitecturas candidatas a evaluar. El plug-in
qualityrequirements permite capturar los requerimientos de calidad. El plug-in archimet define un punto de extensi
on para registrar diferentes plug-ins de evaluacion de arquitecturas
archivol. El plug-in soaperformance realiza la evaluacion de rendimiento en SOAs. SSJavaCOM.dll es la librera que se utiliza para acceder a los modelos de Enterprise Architect. A
continuaci
on se explica cada uno de estos plug-ins con mayor detalle.
6.3
plug-in co.edu.uniandes.moosas.archivol.qualityrequirements - DSL

para especificar requerimientos de calidad
Este plug-in eclipse, implementado utilizando Xtext[79] permite a un arquitecto escribir los
requerimientos de calidad en forma de escenarios de calidad por medio de un lenguaje textual
de domnio especfico (DSL). Los escenarios de calidad que puede expresar el arquitecto
permiten la anotaci
on de informacion adicional que permite obtener la utilidad una vez
evaluada la arquitectura como se presento en la estrategia de solucion (ver captulo 5).
La lista 6.1 presenta un ejemplo de un requerimiento de calidad expresado con Quality
Requirements DSL.
Listing 6.1: sintaxis Quality Requirements DSL
1 QualityRequirement P o r t a l T h r o u g h p u t {
2
stymulusType I n c r e a s e d M e s s a g e R a t e
over P o r t a l
when Runtime
requiredResponse Throughput
valuesOfResponses [
i f response between 101 and 500 Events value i s 100
51
10
11 }
Cada escenario de calidad inicia con la palabra QualityRequirement seguida del nombre
del escenario de calidad. stymulusType permite definir el tipo de evento que se quiere
controlar, este puede ser un conjunto de peticiones que entran al sistema, un incremento
o decremento en estas, un ataque, entre otros. La palabra over permite especificar el
elemento de la arquitectura sobre el cual recae el requerimiento. Las condiciones en las que
se debe manejar el estmulo se definen con la palabra when. Finalmente un requerimiento
de calidad es seleccionado por medio de requiredResponse y la utilidad que se da de acuerdo
al cumplimiento de este atributo de calidad se especifica en valuesOfResponses.
El requerimiento de calidad que presenta la lista 6.1 se puede entender como: se requiere
una capacidad de procesamiento de al menos 11 transacciones por segundo sobre Portal
(donde inicia el proceso de negocio Register Property). Adicionalmente, si se logra 51
transacciones por segundo hay un beneficio adicional para la organizacion. A partir de 101
transacciones en adelante el beneficio para la organizacion no cambia as se incremente la
capacidad del sistema.
Los posibles valores para los tipos de estmulo, las condiciones y las respuesta que se
pueden especificar con Quality Requirements DSL se definieron a partir de los escenarios
de calidad planteados por Bass[42]. La gramatica completa de Quality Requirements DSL
se encuentra en el apendice A.
6.4
plug-in co.edu.uniandes.moosas.archivol.somfeaimporter - Adaptador

Enterprise Architect
Este plug-in utiliza los APIs de EMF y Enterprise Architect para transformar modelos de
Enterprise Architect a modelos conformes con Archivol. De esta forma el arquitecto utiliza
sus dise
nos de relaciones SOMF como el que se presenta en la figura 24. Utilizando el
plug-in se reemplaza el uso de DSLs para expresar SOAs[78][76]. Este enfoque obligaba a
52
Figura 24: Editor SOMF de Enterprise Architect

los arquitectos a duplicar la documentacion de la arquitectura y por consiguiente caer en
los problemas de sincronizaci
on de la informacion y sobrecosto en tiempo. Para facilitar
esta tarea de transformar SOMF a Archivol se implemento un asistente (Wizard eclipse)
que se presenta en la figura 25.
Figura 25: Asistente para transformar SOMF a Archivol
53
Figura 26: Metamodelo de Enterprise Architect

Enterpirse Architect guarda la informacion de los modelos en un archivo con extensi
on
eap. El plug-in hace uso del API ofrecido por Enterprise Architect para manipular la
informaci
on de los modelos. Esta informacion es procesada utilizando un transformador
modelo a modelo (M2M), donde el metamodelo origen es el definido por Enterprise Architect
y el metamodelo destino es Archivol. La figura 26 presenta una version simplificada del
metamodelo de enterprise architect, mientras en el captulo 3 se hace una presentacion del
metamodelo Archivol.
De forma resumida, cada diagrama de relaciones SOMF es transformado en una arquitectura candidata Archivol, seguidamente cada uno de los elementos (consumidor, servicio
atomico y servicio compuesto) es transformado a un componente Archivol. Los tag values
asociados (por ejemplo serviceTime) son transformados en propiedades de un elemento arquitectural Archivol. Luego las relaciones son transformadas a conectores Archivol y sus
propiedades (order, communicationTime, probability) son transformadas en propiedades de
54
la relaci
on Archivol. La figura 27 presenta el resultado de transformar una de las arquitecturas candidatas de InAlpes en un modelo Archivol.
Figura 27: Ejemplo de modelo Archivol generado a partir de diagrama de dise

no de relaciones SOMF
6.5
plug-in co.edu.uniandes.moosas.archivol.archimet - Controlador
Este plug-in define el mecanismo de extension por medio del cual se adicionan diferentes
plug-ins para evaluar arquitecturas conformes con Archivol. La figura 28 presenta la interfaz
que debe implementar cada plug-in que se registra como evaluador. El metodo getRelevance
permite consultar la capacidad de un componente de evaluacion para evaluar determinado
55
escenario de calidad. El metodo evaluate es donde se realiza la evaluacion de la arquitectura

candidata.
interface
ArchiMetEvaluator
+
+
getRelevance(CandidateArchitecture, QualityScenario) : int

evaluate(CandidateArchitecture, QualityScenario) : ArchitectureEvaluation
Figura 28: Interfaz definida para plug-ins de evaluacion
Funcionalmente, este plug-in controla la evaluacion de las diferentes arquitecturas candidatas. Para esto implementa un asistente donde el arquitecto debe seleccionar las arquitecturas candidatas a evaluar. Tambien es necesario que el arquitecto seleccione los
requerimientos de calidad que se tendran en cuenta en la evaluacion. La figura 29 presenta
el asistente para evaluar arquitecturas candidatas.
Figura 29: Asistente para evaluar arquitecturas candidatas

Por cada combinaci
on de escenario de calidad y arquitectura candidata, se recorre cada
uno de los plug-ins registrados como evaluadores por medio del punto de extension de extensi
on co.edu.uniandes.moosas.archivol.archimet.evaluators y se llama el metodo getRelevance. En cada caso, el plug-in que conteste con el valor mas alto (0 a 100) ser
a el
seleccionado para evaluar el par (arquitectura candidata - requerimiento de calidad). El
resultado de todas las evaluaciones es transformado en una tabla de resultados donde las
56
filas son las arquitecturas candidatas y las columnas son los escenarios de calidad evaluados.
6.6
plug-in co.edu.uniandes.moosas.archivol.archimet.soaperformance - Evaluador de rendimiento en SOAs
Este plug-in permite la generacion y la solucion de los modelos de colas como se present
o en
la estrategia de soluci
on (ver captulo 5). Inicialmente la arquitectura candidata Archivol es
transformada en un modelo de colas conforme con el metamodelo presentado en la figura 30.
Figura 30: Metamodelo de colas para recursos de software

Este metamodelo define el lenguaje para expresar modelos de colas para recursos de
software, es decir, modelos que soportan composicion. Cada recurso en un modelo de colas
es conforme con Resource, donde se describen propiedades estaticas del recurso como tiempo
de servicio y tipo. Las propiedades dinamicas como flujo, utilizacion son resultado de cada
evaluaci
on y no hacen parte del metamodelo. Las conexiones entre recursos del modelo de
colas son conformes con Connection. Las propiedades que describen una conexion entre
recursos de un modelo de colas de software son el tiempo de comunicacion, la probabilidad
de que ocurra y la sincronicidad.
Tanto La transformaci
on de modelos Archivol a modelos de colas de software como la
soluci
on del estos modelos generados son realizados por medio del API de EMF.
57
58
CAPITULO VII
EXPERIMENTACION
Este captulo presenta y compara los resultados de la experimientacion utilizando ArchiMet

en la evaluaci
on de SOAs.
7.1
Prop
osito
La teora de colas (ver captulo 4) ha sido usada y validada para hacer predicciones de
rendimiento sobre recursos fsicos concretos (recursos de hardware). Una vez construido el
software se toman medidas y se puede realizar lo que se llama capacity planning[8].
La experimentaci
on de este trabajo esta orientada al uso de estos mismos modelos de
colas pero esta vez para predecir rendimiento desde recursos de software cuando este a
un
no ha sido construido, esto desde un enfoque de una SOA, es decir, teniendo en cuenta
diferentes organizaciones de servicios y mecanismos de comunicacion entre los mismos.
Debido a que parte de los datos requeridos para realizar la prediccion de rendimiento
seg
un la propuesta presentada en este trabajo es una estimacion de los tiempos de servicio
de los servicios at
omicos y los tiempos de comunicacion. Adicionalmente que una mala
estimaci
on impedira comparar el uso de modelos de colas de software vs el comportamiento
real de la arquitectura. No se realizo una estimacion, en cambio se tomaron tiempos de
servicio y tiempos de comunicacion reales obtenidos a partir la implementacion actual de los
servicios de InAlpes. De esta forma se controla una variable aleatoria dentro del proceso de
experimentaci
on que es la confiabilidad de las estimaciones de tiempos de servicio y tiempos
de comunicaci
on.
7.2
Implementaci
on
Los servicios implementados corresponden a los servicios presentados para soportar el proceso de negocio Registrar inmueble de InAlpes (ver captulo 2). En total se implementaron 8
servicios todos utilizando el lenguaje de programacion Java. El mecanismo de comunicaci
on
entre los servicios es SOAP sobre HTTP. Para esto se expuso cada servicio como un web
service utilizando el framework JAX-WS[67].
Los servicios ClintonList Service y DataCredito Service acceden una base de datos relacional para consultar si un cliente se encuentra reportado en alguna de estas dos centrales
de riesgo. Para este acceso a datos se utilizo el framework JPA[50] teniendo en cuenta que
la logica de los servicios se desplegara en un servidor de aplicaciones JEE.
El servicio Notification Service utiliza el API JavaMail[25] para enviar correos a traves
del servidor SMTP[35] de Google. La version asincronica del servicio registra los mensajes
en una cola utilizando el API JMS[2] donde luego un MDB[2] (Bean de mensajera) toma
estos mensajes y los procesa en secuencia.
Los servicios Customer Service y Property Service insertan datos en una base de datos
relacional utilizando JPA.
Los servicios RiskScoring Service, ValidateCustomerProperty Service y RegisterPublish
Service utilizan JAX-WS para consumir los servicios que los componen y java para la l
ogica
de orquestaci
on.
Estos servicios se conectaron en 2 configuraciones particulares que llamamos Arquitectura A y Arquitectura C. Los servicios que conforman las dos arquitecturas son los mismos,
la diferencia radica en el mecanismo de comunicacion que se utiliza para llamar al servicio
NotificationService.
7.2.1
Ambiente de ejecuci
on
Todos los servicios implementados se desplegaron sobre un servidor de aplicaciones Glassfish

3.1[74] apoyado de un motor de base de datos MySQL 5.5. Se realizo una separacion fsica
de la ejecuci
on de los componentes de aplicacion y datos como se acostumbra a realizar en
ambientes de implementaci
on de produccion. Las especificaciones completas del ambiente
59
de ejecuci
on donde se realizaron las pruebas se detalla en las tablas 9 y 10.
Caracterstica
Tipo de m
aquina
Procesador
Memoria
S.O.
Java
Servidor aplicaciones
Valor
PC Escritorio
Intel Core2Duo @ 2.4Ghz
4GB
Windows 7
JDK 1.6
Glassfish 3.1
Table 9: Servidor de aplicaciones
Caracterstica
Tipo de m
aquina
Procesador
Memoria
S.O.
Motor de base de datos
Valor
Virtual
Intel Xeon @ 2.93Ghz x2
6GB
Windows 7
MySQL 5.5
Table 10: Servidor de datos
7.3
Ejecuci
on
Esta secci
on presenta los datos obtenidos a partir de los servicios implementados usando las
dos configuraciones mencionadas. Tambien se presentan los datos que se obtuvieron usando
ArchiMet.
7.3.1
Tiempos de servicio para servicios at

omicos y tiempos de comunicaci
on
Los tiempos de servicio de los servicios atomicos y tiempos de comunicacion son necesarios
para utilizar ArchiMet en otros calculos mas interesantes como flujo, longitud de cola y
tiempos de respuesta. Para obtener los tiempos de servicio de los servicios atomicos se
implement
o un log de tiempos que registra el tiempo en el que un mensaje llega al servicio
y el tiempo en que el servicio termina su procesamiento.
Luego de varias pruebas se encontro que el tiempo de servicio no es constante por lo
que se calcul
o un promedio a partir de 50 llamados (no concurrentes) a cada uno de los
servicios. La tabla 11 presenta los tiempos de servicio para algunos de los servicios atomicos
implementados.
60
Servicio
DataCredito Service
ClintonList Service
Notification Service
Si
1.5 ms
1.8 ms
1.95 s
Table 11: Tiempos de servicio de servicios atomicos

Para tomar el tiempo de comunicacion se resto el tiempo de servicio del tiempo de
respuesta. El tiempo de respuesta se obtuvo por medio de un log de tiempos tambien, pero
esta registra el tiempo desde el cliente que invoca el servicio. Para todos los llamados el
tiempo de comunicaci
on estuvo cerca de los 5 ms.
7.3.2
Tiempos de servicio para servicios compuestos
Para obtener el tiempo de servicio de los servicios compuestos se utilizo la misma tecnica del
log de tiempos. Adicionalmente se obtuvo por aparte el tiempo de servicio teorico usando la
implementaci
on actual de ArchiMet. ArchiMet permite obtener el tiempo de servicio para
el peor, mejor y caso promedio. La tabla 12 presenta los tiempos de servicio teoricos para
los servicios RiskScoring Service y ValidateCustomerProperty Process.
Servicio
RiskScoring Service
ValidateCustomerProperty Process
Arquitectura A
Arquitectura C
6.8 ms - 13.3 ms
11.8 ms - 1923 ms s 11.8 ms - 23.3 ms
Table 12: Tiempos de servicio calculados usando ArchiMet

Los figuras 31, 32 y 33 presentan una comparacion de los datos tiempos de servicio
obtenidos con ArchiMet y los tiempos de servicio reales.
En la arquitectura C el tiempo de servicio del servicio ValidateCustomerProperty Process
es diferente a el tiempo de servicio obtenido en la arquitectura A. Esta diferencia se debe a
que en la arquitectura A se utilizo comunicacion sincronica, mientras que en la arquitectura
C se utiliza comunicaci
on asincronica.
7.3.3
Flujo m
aximo de servicios at
omicos
Para medir el comportamiento de las dos configuraciones con respecto al flujo se usaron
las herramientas SoapUI y LoadUI. SoapUI permite realizar pruebas funcionales de web
61
Real vs ArchiMet RiskScoring Service

60
50
40
peor real
peor ArchiMet
20
mejor ArchiMet
10
0
Figura 31: Comparaci

on de tiempos de servicio para RiskScoring Service
Real vs ArchiMet ValidateCustomer

Property Service Architecture A
7000
6000
5000
4000
mejor real
3000
peor ArchiMet
2000
1000
0

usando Arquitectura A
services, mientras LoadUI permite utilizar las pruebas de funcionales definidas para realizar
pruebas de carga.
Para comparar los datos te
oricos con los datos de la implementacion, se midio el flujo y
el tama
no de la cola de diferentes servicios de la arquitectura teniendo en cuenta diferentes
frecuencias de peticiones.
El flujo m
aximo de un recurso se obtiene a partir de la utilizacion (ver captulo 4) del
mismo. Para observar el comportamiento de esta relacion en servicios atomicos se obtuvo
el valor te
orico y luego por medio de la herramienta LoadUI se aplicaron diferentes cargas
62
Real vs ArchiMet ValidateCustomer

Property Service Architecture C
35
30
25
20
mejor real
15
peor ArchiMet
10
5
0

usando Arquitectura C
(frecuencias de peticiones) sobre los servicios reales. Las figuras 34 y 35 presentan una
comparaci
on de los flujos m
aximos teoricos y reales para algunos de los servicios atomicos.
ClintonList Service at 600 tps

800
700
600
500
real tps
300
ArhiMet tps
200
ArchiMet queue
100
0
Figura 34: Comparacion de flujo maximo para ClintonList Service

Para ClintonList Service el tiempo de servicio obtenido fue de 1.8 ms, teniendo en cuenta
que el flujo m
aximo se obtiene cuando la utilizacion se acerca al 100%. Despejando la
ecuaci
on de la ley de la utilizacion (ver captulo 4) se obtiene que el flujo maximo te
orico
es de 550 tps.
Para el servicio Notification Service el flujo maximo teorico es de menos de 1 tps. Su
63
Notification Service at 1 tps

10
9
8
7
6
real tps
4
3
2
1
0
ArhiMet tps
ArchiMet queue
Figura 35: Comparacion de flujo maximo para Notification Service

bajo flujo motiv
o una segunda prueba para observar el comportamiento del mismo bajo
una frecuencia de 11 peticiones por segundo. En la figura 36 se observa que el servicio
efectivamente no logra un flujo mayor al esperado, como consecuencia, el tama
no de la cola
empieza a crecer de forma lineal con el tiempo transcurrido.
Notification Service at 11 tps

500
400
queue
200
100
0

on de flujo maximo para Notification Service con 11 peticiones de
entrada por segundo
7.3.4
Flujo m
aximo de servicios compuestos
Se realiz
o el mismo ejercicio utilizando servicios compuestos. Para los servicios compuestos,
la utilidad depende del c
alculo previo del tiempo de servicio del mismo. La figura 37 presenta
64
RiskScoring Service at 30 tps

50
45
40
35
30
real tps
20
15
10
5
0
ArhiMet tps
ArchiMet queue
Figura 37: Comparacion de flujo maximo para RiskScoring Service

el flujo del servicio RiskScoring Service que es igual para las dos configuraciones. Para el
servicio ValidateCustomerProperty Process la figura 38 presenta el flujo para la arquitectura
A mientras que la figura 39 lo presenta para la arquitectura C.
Architecture A at 1 tps
40
35
30
20
15
10
5
0
real queue
ArhiMet tps

on de flujo maximo para ValidateCustomerProperty Process usando
Arquitectura A
7.4
An
alisis
La experimentaci
on muestra que la aproximacion que se logra usando ArchiMet tanto para
el calculo de los tiempos de servicio de servicios compuestos como en el calculo del flujo de
servicios at
omicos y compuestos se acerca a los tiempos reales.
65
Architecture C at 11 tps
120
100
60
real queue
40
ArhiMet tps
20
0

on de flujo maximo para ValidateCustomerProperty Process usando
Arquitectura C
Aunque para el caso de los servicios compuestos el flujo dista un poco de la realidad,
usar ArchiMet puede dar un orden de magnitud que es suficiente desde el enfoque de la
arquitectura inicial.
Las diferentes pruebas usando diferentes mecanismos de comunicacion (sincronica y
asincr
onica) muestran que la forma en que ArchiMet realiza los calculos tanto de tiempos
de servicio como de flujo es una buena aproximacion.
66
67
CAPITULO VIII
TRABAJOS RELACIONADOS
En este captulo se resumen los trabajos relacionados con ArchiMet. El primer grupo de
trabajos relacionados presenta los metodos o metricas definidas para evaluar rendimiento
de forma cuantitativa por medio de un modelo matematico de analisis o simulacion. El
segundo grupo de trabajos relacionados presenta las herramientas que se han construido
para soportar la evaluaci
on cuantitativa de arquitecturas de software.
8.1
M
etodos y m
etricas
Balsamo[44] realiza una comparacion de los diferentes metodos teniendo en cuenta el nivel
de integraci
on que existe entre el modelo de descripcion de la arquitectura y el modelo de
rendimiento, el nivel de integracion de la metodologa dentro del ciclo de vida del software y
el nivel de automaticaci
on del metodo. Entre los resultados se encontro que pocos metodos
se pueden aplicar desde un nivel de arquitectura de software, la mayor parte de estos se
aplican a partir de un dise
no detallado. As mismo, aunque la mayora de metodos presenta
alto potencial de automatizaci
on, no hay una herramienta que automatice por completo la
aplicaci
on del metodo. Entre los comparados, se encuentran metodos basados en teora de
colas, patrones arquitecturales, trazas de ejecucion del software, algebra, redes de petri y
simulaci
on. Los predominantes son los metodos basados en teora de colas influenciados
fuertemente por SPE.
Smith y Williams[11][38][54] proponen SPE (Software Performance Engineering). SPE
se basa en modelos de ejecuci
on de software y modelos de ejecucion del sistema. Los primeros
permiten calcular los tiempos de ejecucion cuando no hay congestion de recursos. Para esto
se utiliza un modelo matem
atico simple basado en sumas de tiempos de cada actividad
que realiza el sistema. Los segundos permiten utilizar modelos de colas para representar
los recursos fsicos y calcular valores mas interesantes como el flujo (throughput en ingles)
y el tiempo de respuesta cuando hay congestion de recursos. SPE ha sido validado en la
industria y documentado en varios casos de estudio[26] pero no se ha utilizado para evaluar
SOAs.
Bianco[19] propone un conjunto de guas de los elementos que se deben tener en cuenta al
momento de evaluar una SOA. Bianco describe las SOAs como una arquitectura distribuida
no tradicional en donde existen diferencias en la comunicacion, integracion, orquestaci
on,
entre otros.
Entre los aspectos que se deben tener en cuenta al evaluar una soa se encuentran, la
sincronicidad de los mensajes, el mecanismo de autenticacion, orquestacion, la granularidad
de las interfaces, entre otros. El enfoque usado por Bianco es evaluacion por escenarios,
particularmente menciona el metodo de evaluacion ATAM. Como ATAM es un metodo de
evaluaci
on cualitativo, Bianco presenta unas tablas con comentarios de como podra afectar
una u otra alternativa las diferentes propiedades de calidad.
Finalmente, Hofmeister[65] presenta un conjunto de metricas para evaluar el dise
no
de SOAs de forma cuantitativa. Estas metricas son adaptaciones de metricas propuestas
anteriormente para evaluar tama
no y acoplamiento de sistemas orientados a objetos. Las
metricas que propone Hofmeister estan limitadas a evaluar la complejidad de una SOA
pensando en beneficiar el atributo de calidad modificabilidad.
8.2
Herramientas
Un primer intento en la construccion de un sistema para la toma de decisiones relacionadas

con la implementaci
on de un sistema basado en software fue presentado es ESSE[28]. ESSE
permite evaluar software teniendo en cuenta criterios como calidad, costo, tiempos de entrega y est
andares. Entre los problemas de ESSE se encuentran: 1) El evaluador debe definir
los criterios de evaluaci
on para que la herramienta conozca como evaluar el software, adicionalmente el evaluador debe ingresar manualmente la informacion relevante del software
68
a evaluar. 2) La herramienta al ser de proposito general permite evaluar multiples arquitecturas pero as mismo no tiene el poder de una herramienta especfica lo cual implica calculos
manuales por parte del evaluador. Por ejemplo, para la evaluacion de rendimiento ESSE
sugiere ingresar la utilizaci
on de los recursos, pero este valor realmente debera ser calculado
durante la evaluci
on como se logra con ArchiMet. 3) No se encontro experimentaci
on en
mas de 10 a
nos desde que se propuso la herramienta.
Una segunda herramienta fue presentada por Smith y Williams[20]. SPEED es la herramienta que implementa SPE. SPEED permite generar los modelos de ejecucion de software a partir de varios diagramas UML donde los elementos son anotados con tagged values.
Aunque SPE dice estar integrado con el ciclo de vida del software no es totalmente cierto
porque deja a un lado los requerimientos de calidad que son la base para el dise
no y evaluacion de una arquitectura de software. Finalmente, SPEED esta dise
nado para evaluar
rendimiento en sistemas orientados a objetos, no se han realizado adaptaciones para evaluar
SOAs con SPEED.
Assmann[68], propone una herramienta para evaluacion de una SOEA (Service Oriented Enterprise Architecture) utilizando modelos y una tecnica de questionarios. En el
enfoque de Assmann, la SOEA es descrita en un modelo conforme con un metamodelo que
incluye conceptos de SOA y de arquitectura empresarial. Assmann propone un conjunto
de metricas e indicadores que permiten evaluar la SOEA de forma cuantitativa aunque no
especifica como se calculan las metricas, solo presenta unos valores sugeridos. La estrategia
de Assmann es comparar en que grado una SOEA cumple con respecto a una arquitectura
de referencia.
Bocciarelli[61] utiliza una extension de WSDL llamada Q-WSDL para describir propiedades
no funcionales como confiabilidad y rendimiento sobre los servicios. Luego por medio de
un enfoque basado en modelos se logra predecir el rendimiento y la confiabilidad de los
servicios compuestos.
Una herramienta similar a ArchiMet se encuentra en[58]. Revel8or es una herramienta
basada en modelos para la evaluacion de rendimiento de una arquitectura basada en componentes. Revel8or permite utilizar los modelos UML de la arquitectura existente, anotarlos
69
con los perfiles UML para rendimiento y finalmente generar el modelo de colas para ser evaluado. ArchiMet se diferencia de Revel8or en que puede ser extendido para evaluar otros
atributos de calidad como reutilizacion, seguridad, entre otros. Adicionalmente, ArchiMet
permite el manejo de conflictos (tradeoffs) entre ellos diferentes atributos de calidad, esto
lo logra por medio de la especificacion de los requerimientos de calidad usando QualityRequirementsDSL.
Finalmente, Palladio[55] es ua herramienta para la evaluacion de rendimiento en sistemas basados en componentes (Component Based Software Engineering en ingles) por
medio de abstracci
on de modelos. A diferencia de SPEED y Revel8or, Palladio utiliza su
propio metamodelo en vez de UML. Palladio se compone de diferentes lenguajes especficos
de dominio dise
nados pensando en los diferentes roles que desempe
na un equipo de desarrollo al utilizar una metodologa de desarrollo basado en componentes. Estos roles son:
desarrollador de componentes, arquitecto, desarrollador del sistema y experto del dominio.
Palladio facilita la integraci
on de la evaluacion de rendimiento con la metodologa utilizada
para el desarrollo evitando la incomodidad de la evaluacion. Para el caso de SOAs, Palladio
no es pr
actico por los diferentes DSLs definidos pensando en los roles especficos que existen
en el desarrollo de software basado en componentes.
Las tablas 13 y 14 resumen las diferentes herramientas existentes para la evaluaci
on de
rendimiento desde el punto de vista de la evaluacion de SOAs.
Esfuerzo
Metodo evaluaci
on
Atributos
Arquitectura
ESSE
Alto
MCDA
Abierto
Abierto
SPEED
Medio
QN
Rendimiento
Objetos
Q-WSDL
Alto
LQN
Rendimiento y Confiabilidad
SOA
Table 13: Comparaci

on de herramientas existentes para la evaluacion de rendimiento (parte
1)
El esfuerzo se evalu
o teniendo en cuenta el tiempo que requiere el evaluador para evaluar
una arquitectura usando la herramienta. Alto significa que el evaluador tiene que definir
los criterios de evaluaci
on porque la herramienta es totalmente abierta (como una hoja de
calculo). El esfuerzo es medio cuando debe expresar algunas cosas de forma manual en la
70
Esfuerzo
Metodo evaluaci
on
Atributos
Arquitectura
Revel8or
Simple
QN
Rendimiento
Componentes
Palladio
Simple
QN
Renidmiento
Componentes
ArchiMet
Simple
QN
Abierto
SOA
Table 14: Comparaci

on de herramientas existentes para la evaluacion de rendimiento (parte
2)
herramienta y simple cuando la herramienta se integra a la metodologa de desarrollo y no
es necesaria la descripci
on de la arquitectura de forma manual en la herramienta.
El metodo de evaluaci
on se refiere a como eval
ua la herramienta la arquitectura. MCDA
es evaluaci
on teniendo multiples criterios (Multi Criteria Decision Analysis en ingles), QN
es redes de colas (Queue Networks en ingles) y LQN es redes de colas por capas (Layered
Queue Networks).
Finalmente el tipo de atributos de calidad que se eval
uan y el estilo arquitectural que
soportan complementan la descripcion de estas herramientas.
71
72
CAPITULO IX
CONCLUSIONES
En el captulo 1 de este trabajo se presento la importancia de evaluar una arquitectura de

software antes de implementacion. En el captulo 3 se presento la teora de evaluaci
on de
arquitectura de software y otras teoras necesarias para el planteamiento de este trabajo.
El resto de este trabajo se dedico a la presentacion de ArchiMet, una herramienta dirigida
por modelos que asiste al arquitecto de software en su trabajo por medio de la evaluaci
on
de arquitecturas candidatas con respecto a un conjunto de requerimientos de calidad.
Adicionalmente se present
o la evaluacion de rendimiento en arquitecturas SOA utilizando ArchiMet por medio de la aplicacion de teora de colas adaptada para predecir
propiedades de rendimiento con una informacion mnima de la arquitectura a evaluar.
9.1
Problemas resueltos
En este trabajo se logr

o proponer una solucion a los problemas identificados en el captulo 1.
A continuaci
on se resumen estos problemas identificados y como este trabajo contribuye a
la soluci
on de los mismos.
9.1.1
Problema 1
Hacer evaluaci
on cuantitativa de una arquitectura de software es costoso, mas en una SOA
al ser una arquitectura distribuida y donde la infraestructura es muy compleja teniendo en
cuenta la variedad de middleware existente.
La soluci
on que se propone es el uso de evaluacion de arquitectura de software, especficamente de SOAs utilizando un metodo basado en metricas, este metodo se encuentra
soportado por una herramienta que automatiza el proceso de tal forma que el evaluador no
tiene que realizar c

alculos de forma manual.
9.1.2
Problema 2
Cuando no se implementan prototipos, el resultado de la evaluacion de una arquitectura de

software es subjetivo y depende de quien realiza la evaluacion.
Al automatizar el proceso de evaluacion con unos criterios claros, el resultado de la
evaluaci
on ya no es subjetivo y pasa a ser objetivo. En el captulo 7 se presentaron los
resultados de confiabilidad de ArchiMet.
9.1.3
Problema 3
Aplicar metodos formales para la evaluacion de rendimiento no es natural para los practicantes, se debe tener conocimientos especializados como teora de colas, redes de petri o
procesos estoc
asticos. Adicionalmente debe saber como crear un modelo de rendimiento
a partir de su arquitectura. Finalmente la mayora de las herramientas existentes asumen
conocimiento de esta teora.
Aunque ArchiMet utiliza teora de colas para la evaluacion de rendimiento de una SOA,
por medio de la aplicaci
on de la ingeniera dirigida por modelos se logra transformar el
modelo de la arquitectura al modelo de colas de forma automatica y as mismo se logra
la soluci
on del mismo. Finalmente por medio del plug-in eclipse implementado se puede
visualizar el resultado de esta evaluacion sin necesidad de conocer la teora de colas.
9.1.4
Problema 4
Algunas herramientas existentes para evaluar rendimiento dicen integrarse con el ciclo de
vida del software, pero este inicia desde la captura de los requerimientos, que son principalmente importantes para validar una arquitectura de software, las herramientas para evaluar
rendimiento no tienen en cuenta los requerimientos especficos de rendimiento ni de otros
atributos de calidad.
ArchiMet tiene en cuenta los requerimientos de calidad durante el proceso de evaluaci
on
de la arquitectura de software. Sin tener en cuenta estos no tendra sentido decir si la
arquitectura es v
alida o no. Para expresar los requerimientos de calidad, ArchiMet se basa
73
en los conocidos escenarios de calidad propuestos por el SEI y ofrece un DSL para que el
evaluador exprese estos.
9.1.5
Problema 5
En algunos casos no se hace evaluacion del dise

no, algunas veces porque el costo de conformidad es mayor que el costo de no conformidad. Es decir, las organizaciones no ven
justificado el costo de evaluar una arquitectura.
Por medio de la automatizacion del proceso de evaluacion de arquitectura de software y
con la ayuda del plug-in que transforma los modelos SOMF existentes en modelos Archivol
hacer la evaluaci
on de una SOA en terminos de rendimiento es cuestion de minutos y no de
das.
9.2
Conclusiones
Al analizar los procesos de dise

no, implementacion y experimentacion de la propuesta presentada en este documento, se llevan a las siguientes conclusiones:
El uso de la ingeniera dirigida por modelos acelero el desarrollo de la solucion.
El uso del metamodelo de arquitectura de software Archivol facilito la construcci
on
de la soluci
on y es un punto clave para los trabajos relacionados con el analisis de
arquitecturas de software.
El uso de una arquitectura de plug-ins eclipse facilito el desarrollo de la soluci
on y
permiti
o crear una herramienta extensible que se integra con un IDE de desarrollo
ampliamente conocido.
La teora de colas fue un excelente punto de partida para la evaluacion de rendimiento
de una SOA.
9.3
Contribuciones
Dentro de las contribuciones al finalizar este trabajo se encuentran:

Una metodologa para evaluar arquitecturas de software utilizando ingeniera dirigida
por modelos.
74
Una adaptaci
on de la teora de colas para predecir el comportamiento de arquitecturas
de software con informacion mnima y que permite la expresion de composici
on de
servicios y de mecanismos de comunicacion sincronica y asincronica.
Un DSL para especificar requerimientos de calidad en terminos de escenarios de calidad
que adicionalmente captura la utilidad que se obtendra al cumplir el requerimiento
especificado.
Un conjunto de plug-ins eclipse que se integran con el metamodelo Archivol y lo
complementan.
Un transformador de dise
nos expresados en SOMF con la herramienta Enterprise
Architect a modelos conformes con Archivol.
Un mecanismo de extension para adicionar diferentes evaluadores de arquitecturas
de software con el
animo de complementar este trabajo con evaluaciones de otros
atributos de calidad.
La implementaci
on de 8 servicios en forma de web services que soportan el proceso
de Registrar inmueble del caso de estudio InAlpes.
9.4
Trabajo futuro
Este trabajo abre nuevas posibilidades de investigacion como:

Se hace necesario realizar diferentes experimentaciones con arquitecturas reales de
gran tama
no, una alternativa tambien es experimentar con diferentes patrones de
dise
no de SOA.
Algunas de las decisiones que deben tomarse al definir la arquitectura de software son
del tipo comprar vs hacer. Una posibilidad de trabajo consiste en adicionar aspectos
econ
omicos en la evaluacion de arquitecturas de software.
En SOA existe el concepto de tareas manuales que no se tuvo en cuenta en este trabajo,
este trabajo se puede complementar adicionando la capacidad de evaluar rendimiento
en SOAs con tareas manuales.
75
76
APENDICE
A
SINTAXIS QUALITY REQUIREMENTS DSL
Listing A.1: sintaxis Quality Requirements DSL

1 grammar co . edu . u n i a n d e s . moosas . Q u a l i t y R e q u i r e m e n t s
2 with o r g . e c l i p s e . x t e x t . common . T e r m i n a l s
3
4 generate q u a l i t y R e q u i r e m e n t s
5 h t t p : / /www. edu . co / u n i a n d e s / moosas / Q u a l i t y R e q u i r e m e n t s
6
7
8
QualityRequirements :
( q u a l i t y R e q u i r e m e n t s+=Q u a li t yR e q ui r em e nt ) ;
9
10
Qua l it y R eq u ir e m en t :
11
QualityRequirement name=ID {
12
stymulusType stimulusType=StimulusType
13
over a r t i f a c t=STRING
14
when environment=EnvironmentType
15
r e q u i r e d R e s p o n s e r e s p o n s e=ResponseType
16
valuesOfResponses [
17
( r e s p o n s e M e a s u r e s+=ResponseMeasure )
18
19
} ;
20
21 enum StimulusType :
22
Attack | DecreasedMessageRate | D e f e c t R e p o r t e d |
23
DeliveredVersion | Failure | FunctionalModification |
24
IncreasedMessageRate | InteroperabilityRequirement |
25
NeedForUse | P l a t f o r m M o d i f i c a t i o n | TimeExeeded |
26
IncomingMessage | ComponentReplace ;
27
28 enum EnvironmentType :
29
NormalOperation | Degraded | Overloaded | UnderAttack |
30
S t a r t i n g U p | ShuttingDown | DesignTime | CompileTime |
31
BuildTime | Runtime | OnSafeZone | OnUnsafeZone ;
32
33 enum ResponseType :
34
FaultDetection | FaultRecovery | FaultPrevention |
35
Reuse | ResponseTime | Throughput | ResourceUsage |
36
A t t a c k D e t e c t i o n | AttackRecovery | A v a i l a b i l i t y |
37
A u t h e n t i c a t e | A u t h o r i z e | Log | I n t e r o p e r a t e ;
38
39 ResponseMeasure :
40
i f r e s p o n s e between min=INT and max=INT
41
u n i t=UnitType v a l u e i s v a l u e=INT ;
42
43 enum UnitType :
44
T i m e I n M i l l i s | TimeInHours | TimeInDays | TimeInPercentage |
45
Events | E v e n t s I n P e r c e n t a g e | Cost | Elements ;
77
78
APENDICE
B
GUIA PARA USAR ARCHIMET
Esta gua describe como un usuario puede utilizar ArchiMet y en general las funcionalidades
implementadas en este trabajo. Antes de poder utilizar cualquier funcionalidad el usuario
debe crear un proyecto Eclipse como se presenta en la figura 40.
Figura 40: Nuevo proyecto en Eclipse
B.1
Especificar requerimientos de calidad
Figura 41: Nuevo archivo de requerimientos de calidad

Para especificar los requerimientos de calidad, el usuario debe crear un nuevo archivo
con extensi
on qreq. Eclipse detectara por medio de la extension del archivo que se trata
de un archivo para definir requerimientos de calidad y preguntara si desea adicionar las
capacidades de Xtext al proyecto como se muestra en la figura 41. Seleccione Si (Yes en
ingles). Eclipse abrir
a autom
aticamente el archivo creado utilizando el editor proporcionado.
79
En caso de que esto no ocurra se puede seleccionar sobre el men

u contextual del archivo
abrir con (open with en ingles) Quality Requirements Editor como lo ilustra la figura 42.
Figura 42: Abrir con Quality Requierements Editor

Dentro del editor, el usuario puede presionar Ctrl+Espacio para utilizar el asistente
de edici
on. El asistente de edicion completa las palabras reservadas como Requirement,
stymulusType, entre otras. Adicionalmente permite guiar al usuario en la seleccion de los
posibles valores para tipo de estmulo, condicion, respuesta requerida y unidades de la
medida. La figura 43 presenta el asistente de contenido de Quality Requirements Editor.
B.2
Modelar arquitecturas candidatas
El usuario de ArchiMet tiene diferentes alternativas para expresar cada arquitectura candidata a evaluar. La primera opcion es utilizar el editor reflexivo de Ecore, en donde se
muestran los elementos del modelo en forma de arbol. La segunda alternativa es utilizar
Enterprise Architect y crear un diagrama de dise
no de relaciones SOMF que luego se puede
transformar a una arquitectura candidata Archivol.
80
Figura 43: Asistente de contenido de Quality Requirements Editor

B.2.1
Transformar un diagrama de dise

no de relaciones SOMF en una arquitectura candidata Archivol
Figura 44: Modelo Archivol
Para utilizar el tranformador de diagramas de dise

no de relaciones SOMF a Archivol
primero debe existir un modelo Archivol donde se crearan las nuevas arquitecturas candidatas. La figura 44 presenta un modelo Archivol vaco.
Una vez se ha modelado la arquitectura en Enterprise Architect el usuario puede iniciar
el asistente de transformaci
on usando Nuevo (New en ingles) Architecture from Enterprise
81
Figura 45: Nuevo Architecture from Enterprise Architect File

Architect File como se muestra en la figura 45.
Eclipse presentar
a una segunda pantalla que solicita los siguientes datos:
Nombre: El nombre que se le dara a la arquitectura candidata Archivol.
Archivo de Enterprise Architect: La ruta del archivo donde se encuentra el
modelo a importar.
Modelo a transformar: El modelo particular a importar.
Modelo Archivol: El modelo Archivol donde se creara la arquitectura candidata.
82
Figura 46: Datos de entrada para asistente de transformacion de Enterprise Architect a

Archivol
B.3
Evaluar arquitecturas candidatas
Para evaluar una o varias arquitecturas candidatas se utiliza un asistente igual que en la
transformaci
on de la arquitectura. Para acceder a este asistente el usuario debe seleccionar
Nuevo (New en ingles) Candidate Architecture Evaluation como se muestra en la figura 47.
Los datos requeridos para el asistente de evaluacion son:
Modelo archivol: El modelo donde se encuentran las arquitecturas candidatas a
evaluar.
Archivo de requerimientos: El archivo donde se especificaron los requerimientos
de calidad.
83
Figura 47: Nuevo Candidate Architecture Evaluation
B.4
Revisar resultados de la evaluaci

on
Una vez realizada la evaluaci

on de las arquitecturas candidatas, ArchiMet modifica el modelo Archivol para incluir el resultado de la evaluacion. Para mostrar el visor de evaluaci
on
que presenta el resultado de la evaluacion en forma de tabla el usuario debe seleccionar
mostrar vista (show view en ingles) Archivol evaluation como se presenta en la figura 48.
El usuario debe abrir el modelo archivol y seleccionar su elemento contenedor (la arquitectura). El visor de evaluaci
on presentara el resultado de la evaluacion en forma de tabla
donde cada fila es una arquitectura candidata evaluada y cada columna es un requerimiento
de calidad evaluado. La figura 49 muestra el visor de evaluacion.
84
Figura 48: mostrar vista Archivol Evaluation
Figura 49: Visor de evaluacion
85
86
APENDICE
C
ENTERPRISE
FUENTES TRANSFORMACION
ARCHITECT A ARCHIVOL
Listing C.1: sintaxis Quality Requirements DSL

1 package co . edu . u n i a n d e s . moosas . a r c h i v o l . e a i m p o r t e r ;
2
3 import . . . ;
4
5 /
6
This i s t h e i m p l e m e n t a t i o n o f E n t e r p r i s e A r c h i t e c t t o A r c h i v o l
t r a n s f o r m a t i o n (M2M). 
Main r e s p o n s i b i l i t i e s :

10
< l i >Transform Each EAElement t o a A r c h i t e c t u r a l Element and a
11
Modeled A r c h i t e c t u r a l Element </ l i >
12
< l i >Transform Each EAConnector t o a R e l a t i o n s h i p </ l i >
13
< l i >I f s o u r c e and t a r g e t e l e m e n t s o f t h e r e l a t i o n s h i p a r e
14
components , a c o n n e c t o r i s used </ l i >
15

16
Main r e s t r i c t i o n s :
17

18
< l i >Only f o r SOMF n o t a t i o n </ l i >
19
< l i >No m u l t i t h e a d i n g , be c a r e f u l i f a n o t h e r t h r e a d i s
20
m o d i f y i n g t h e a r c h i t e c t u r e a d d i n g or removing a r c h i t e c t u r a l
21
e l e m e n t s </ l i >
22

23
24
@author Andre s Jime nez <am . jimenez77@uniandes . edu . co>
25
26
27 public c l a s s EAtoArchivol {
28
29
IPreferencesService service ;
30
31
private S t r i n g name ;
32
private L i s t <Package> p a c k a g e s ;
33
private A r c h i t e c t u r e a r c h i t e c t u r e ;
34
private C a n d i d a t e A r c h i t e c t u r e c a n d i d a t e A r c h i t e c t u r e ;
35
36
// Maps t h a t f a c i l i t a t e i n d e x i n g o f e l e m e n t s f o r b e t t e r
37
// performance
38
private Map<S t r i n g , A r c h i t e c t u r a l E l e m e n t > elementsByName ;
39
private Map elementsByID ;
40
private Map r e l a t i o n s h i p s B y I D ;
41
42
//
43
private View ecosystemView ;
44
private Model model ;
45
46
47
public EAtoArchivol ( ) {
s e r v i c e = Platform . g e t P r e f e r e n c e s S e r v i c e ( ) ;
87
48
elementsByID = new HashMap ( ) ;
49
r e l a t i o n s h i p s B y I D = new HashMap ( ) ;
50
51
52
// G e t t e r s
53
54
public void setName ( S t r i n g name ) {
55
56
t h i s . name = name ;
}
57
58
public void s e t P a c k a g e s ( L i s t <Package> p a c k a g e s ) {
59
60
this . packages = packages ;

}
61
62
public void s e t A r c h i t e c t u r e ( A r c h i t e c t u r e a r c h i t e c t u r e ) {
63
this . a r c h i t e c t u r e = a r c h i t e c t u r e ;
64
elementsByName = new HashMap<S t r i n g , A r c h i t e c t u r a l E l e m e n t > ( ) ;
65
f o r ( A r c h i t e c t u r a l E l e m e n t ae : a r c h i t e c t u r e
. getElements ( ) ) {
66
67
elementsByName . put ( ae . getName ( ) , ae ) ;

}
68
69
70
71
public C a n d i d a t e A r c h i t e c t u r e g e t C a n d i d a t e A r c h i t e c t u r e ( ) {
72
73
return c a n d i d a t e A r c h i t e c t u r e ;
}
74
75
// l o g i c
76
88
77
public void e x e c u t e ( ) {
78
// C r e a t e s t h e new c a n d i d a t e a r c h i t e c t u r e
79
c a n d i d a t e A r c h i t e c t u r e = C a nd i da t eF a ct o ry . eINSTANCE
80
. createCandidateArchitecture ( ) ;
81
c a n d i d a t e A r c h i t e c t u r e . setName ( name ) ;
82
83
// C r e a t e s a e c o s y s t e m v i e w
84
ecosystemView = C an d id at e F ac t or y . eINSTANCE . c r e a t e V i e w ( ) ;
85
ecosystemView . setName ( Ecosystem view ) ;
86
ecosystemView . setViewType ( ViewType . STATIC ) ;
87
c a n d i d a t e A r c h i t e c t u r e . getViews ( ) . add ( ecosystemView ) ;
88
// C r e a t e s a model f o r t h e c u r r e n t e c o s y s t e m
89
model = C an d id a te F ac t o ry . eINSTANCE . c r e a t e M o d e l ( ) ;
90
model . setName ( t h i s . name ) ;
91
model . s e t N o t a t i o n ( SOMF ) ;
92
model . setFamilyType ( FamilyType .COMPONENT AND CONNECTOR) ;
93
ecosystemView . getModels ( ) . add ( model ) ;
94
f o r ( Package p : p a c k a g e s ) {
95
96
packages (p ) ;
}
97
98
99
100
101
P r o c e s s a EAPackage r e c u r s i v e l y
102
103
@param m
104
105
private void p a c k a g e s ( Package m) {
89
106
e l e m e n t s ( c a n d i d a t e A r c h i t e c t u r e , m. GetElements ( ) ) ;
107
c o n n e c t o r s ( c a n d i d a t e A r c h i t e c t u r e , m. GetConnectors ( ) ) ;
108
f o r ( short j = 0 ; j < m. GetPackages ( ) . GetCount ( ) ; j ++) {
109
Package p = m. GetPackages ( ) . GetAt ( j ) ;
110
packages (p ) ;
}
111
112
113
114
115
Transform a c o l l e c t i o n o f AEElement t o a c o l l e c t i o n o f
116
ArchitecturalElement
117
118
@param e l e m e n t s
119
@return
120
121
private void e l e m e n t s (
122
CandidateArchitecture candidateArchitecture ,
123
C o l l e c t i o n <Element> e l e m e n t s ) {
124
f o r ( short k = 0 ; k < e l e m e n t s . GetCount ( ) ; k++) {
125
Element e = e l e m e n t s . GetAt ( k ) ;
126
I n t e g e r i d = e . GetElementID ( ) ;
127
S t r i n g name = e . GetName ( ) ;
128
String stereoType = e . GetStereotype ( ) ;
129
S t r i n g type = e . GetType ( ) ;
130
131
// Tr a n s fo rm a t io n
132
A r c h i t e c t u r a l E l e m e n t a r c h i t e c t u r a l E l e m e n t = null ;
133
// I f t h e r e i s an e x i s t i n g element , i t w i l l be used
134
i f ( elementsByName . c o n t a i n s K e y ( name ) ) {
90
135
136
a r c h i t e c t u r a l E l e m e n t = elementsByName . g e t ( name ) ;
} else {
137
i f ( type . e q u a l s ( Component )
138
| | s t e r e o T y p e . e q u a l s ( consumer )
139
| | stereoType
140
. equals ( atomicDesignService )
| | stereoType
141
. equals ( compositeDesignService )) {
142
143
Component c = C a nd i da t eF a ct o ry . eINSTANCE
144
. createComponent ( ) ;
145
c . setName ( name ) ;
146
architecturalElement = c ;
147
a r c h i t e c t u r e . g e t E l e m e n t s ( ) . add (
148
architecturalElement ) ;
149
elementsByName . put ( name , c ) ;

}
150
151
152
153
i f ( a r c h i t e c t u r a l E l e m e n t != null ) {
154
// Adds t h e e l e m e n t t o t h e c u r r e n t c a n d i d a t e
155
// a r c h i t e c t u r e
156
c a n d i d a t e A r c h i t e c t u r e . g e t E l e m e n t s ( ) . add (
157
158
159
160
ModeledArchitecturalElement modeledArchitecturalElement =
C an d id a te F ac t or y . eINSTANCE . c r e a t e M o d e l e d A r c h i t e c t u r a l E l e m e n t ( ) ;
161
m o d e l e d A r c h i t e c t u r a l E l e m e n t . setName ( name ) ;
162
modeledArchitecturalElement
163
. setElement ( architecturalElement ) ;
91
164
model . g e t E l e m e n t s ( ) . add (
165
modeledArchitecturalElement ) ;
166
167
architecturalElement
168
. getProperties ()
169
. addAll ( t a g g e d V a l u e s T o A r c h i t e c t u r a l E l e m e n t P r o p e r t i e s ( e
170
. GetTaggedValues ( ) ) ) ;
171
c a n d i d a t e A r c h i t e c t u r e . g e t E l e m e n t s ( ) . add (
172
173
174
elementsByID
175
. put ( id , m o d e l e d A r c h i t e c t u r a l E l e m e n t ) ;
176
connectors ( candidateArchitecture ,
177
e . GetConnectors ( ) ) ;
}
178
}
179
180
181
182
183
Transform a c o l l e c t i o n o f AEElement t o a c o l l e c t i o n o f
184
ArchitecturalElement
185
186
@param e l e m e n t s
187
@return
188
189
private void c o n n e c t o r s (
190
CandidateArchitecture candidateArchitecture ,
191
C o l l e c t i o n <Connector> c o n n e c t o r s ) {
192
f o r ( short k = 0 ; k < c o n n e c t o r s . GetCount ( ) ; k++) {
92
193
Connector c = c o n n e c t o r s . GetAt ( k ) ;
194
I n t e g e r i d = c . GetConnectorID ( ) ;
195
S t r i n g name = c . GetName ( ) ;
196
S t r i n g metaType = c . GetMetaType ( ) ;
197
S t r i n g type = c . GetType ( ) ;
198
String stereoType = c . GetStereotype ( ) ;
199
I n t e g e r c l i e n t I D = c . GetCl ientI D ( ) ;
200
I n t e g e r supplierID = c . GetSupplierID ( ) ;
201
202
// Tr a n s fo r m a t i o n
203
Relationship relationship = relationshipsByID
204
205
206
207
208
209
210
211
. get ( id ) ;
i f ( elementsByID . c o n t a i n s K e y ( c l i e n t I D )
&& elementsByID . c o n t a i n s K e y ( s u p p l i e r I D ) ) {
M o d e l e d A r c h i t e c t u r a l E l e m e n t s o u r c e E l e m e n t = elementsByID
. get ( clientID ) ;
M o d e l e d A r c h i t e c t u r a l E l e m e n t t a r g e t E l e m e n t = elementsByID
. get ( supplierID ) ;
i f ( s o u r c e E l e m e n t . getElement ( ) instanceof Component
212
&& t a r g e t E l e m e n t . getElement ( ) instanceof Component ) {
213
co . edu . u n i a n d e s . moosas . a r c h i v o l . c a n d i d a t e . Connector ac =
214
215
C an d id a te F ac t or y . eINSTANCE . c r e a t e C o n n e c t o r ( ) ;
ac . setName ( name
216
+ (
217
+ ( s o u r c e E l e m e n t . getName ( ) + > + t a r g e t E l e m e n t
218
. getName ( ) ) + ) ) ;
219
ac . s e t S o u r c e ( s o u r c e E l e m e n t ) ;
220
ac . s e t T a r g e t ( t a r g e t E l e m e n t ) ;
221
r e l a t i o n s h i p = ac ;
93
222
223
224
relationship
225
. s e t D i r e c t i o n a l i t y ( D i r e c t i o n a l i t y T y p e .SOURCE TO TARGET ) ;
226
ArchitecturalElementProperty synchronicity =
227
C an d id a te F ac t or y . eINSTANCE
228
. createArchitecturalElementProperty ( ) ;
229
s y n c h r o n i c i t y . setName ( s y n c h r o n i c i t y ) ;
230
i f ( stereoType . equals ( apparentUnidirectional ) ) {
231
s y n c h r o n i c i t y . setValue ( asynchronous ) ;
} else i f ( stereoType
232
. equals ( apparentBidirectional )) {
233
234
s y n c h r o n i c i t y . setValue ( synchronous ) ;
235
236
i f ( s y n c h r o n i c i t y . g e t V a l u e ( ) != null ) {
237
r e l a t i o n s h i p . g e t P r o p e r t i e s ( ) . add (
238
synchronicity );
}
239
240
241
relationship
242
. getProperties ()
243
. addAll ( c o n n e c t o r T a g s T o A r c h i t e c t u r a l E l e m e n t P r o p e r t i e s ( c
244
. GetTaggedValues ( ) ) ) ;
245
246
247
248
249
250
i f ( r e l a t i o n s h i p != null ) {
i f ( ! relationshipsByID . containsKey ( r e l a t i o n s h i p ) ) {
model . g e t E l e m e n t s ( ) . add ( r e l a t i o n s h i p ) ;
94
251
r e l a t i o n s h i p s B y I D . put ( id , r e l a t i o n s h i p ) ;
}
252
}
253
}
254
255
256
257
private j a v a . u t i l . C o l l e c t i o n <A r c h i t e c t u r a l E l e m e n t P r o p e r t y >
258
taggedValuesToArchitecturalElementProperties (
259
C o l l e c t i o n <TaggedValue> t a g g e d V a l u e s ) {
260
A r r a y L i s t <A r c h i t e c t u r a l E l e m e n t P r o p e r t y > a r c h i t e c t u r a l E l e m e n t P r o p e r t i e s =
261
new A r r a y L i s t <A r c h i t e c t u r a l E l e m e n t P r o p e r t y > ( ) ;
262
f o r ( short l = 0 ; l < t a g g e d V a l u e s . GetCount ( ) ; l ++) {
263
// EA p a r t
264
TaggedValue tv = t a g g e d V a l u e s . GetAt ( l ) ;
265
S t r i n g name = tv . GetName ( ) ;
266
S t r i n g v a l u e = tv . GetValue ( ) ;
267
268
269
ArchitecturalElementProperty architecturalElementProperty =
270
C an d id a te F ac t or y . eINSTANCE
271
. createArchitecturalElementProperty ( ) ;
272
a r c h i t e c t u r a l E l e m e n t P r o p e r t y . setName ( name ) ;
273
architecturalElementProperty . setValue ( value ) ;
274
architecturalElementProperties
275
. add ( a r c h i t e c t u r a l E l e m e n t P r o p e r t y ) ;
276
277
return a r c h i t e c t u r a l E l e m e n t P r o p e r t i e s ;
278
279
95
280
private j a v a . u t i l . C o l l e c t i o n <A r c h i t e c t u r a l E l e m e n t P r o p e r t y >
281
connectorTagsToArchitecturalElementProperties (
282
C o l l e c t i o n <ConnectorTag> c o n n e c t o r T a g s ) {
283
A r r a y L i s t <A r c h i t e c t u r a l E l e m e n t P r o p e r t y > a r c h i t e c t u r a l E l e m e n t P r o p e r t i e s =
284
new A r r a y L i s t <A r c h i t e c t u r a l E l e m e n t P r o p e r t y > ( ) ;
285
f o r ( short l = 0 ; l < c o n n e c t o r T a g s . GetCount ( ) ; l ++) {
286
// EA p a r t
287
ConnectorTag c t = c o n n e c t o r T a g s . GetAt ( l ) ;
288
S t r i n g name = c t . GetName ( ) ;
289
S t r i n g v a l u e = c t . GetValue ( ) ;
290
291
292
ArchitecturalElementProperty architecturalElementProperty =
293
C an d id a te F ac t or y . eINSTANCE . c r e a t e A r c h i t e c t u r a l E l e m e n t P r o p e r t y ( ) ;
294
a r c h i t e c t u r a l E l e m e n t P r o p e r t y . setName ( name ) ;
295
architecturalElementProperty . setValue ( value ) ;
296
architecturalElementProperties
297
. add ( a r c h i t e c t u r a l E l e m e n t P r o p e r t y ) ;
298
299
return a r c h i t e c t u r a l E l e m e n t P r o p e r t i e s ;
300
301 }
96
97
APENDICE
D
DE ARCHIVOL A
FUENTES DE TRANSFORMACION
SOFTWAREQN
Listing D.1: sintaxis Quality Requirements DSL

1 package co . edu . u n i a n d e s . moosas . a r c h i v o l . e a i m p o r t e r ;
2
3 import . . . ;
4
5 /
6
This i s t h e i m p l e m e n t a t i o n o f A r c h i v o l t o SoftwareQN
t r a n s f o r m a t i o n (M2M). 
Main r e s p o n s i b i l i t i e s :

10
< l i >Transform each Component t o a Resource </ l i >
11
< l i >Transform each Connector t o a Connection </ l i >
12
< l i >C r e a t e a Model f o r e v e r y c o m p o s i t e S e r v i c e </ l i >
13

14
15
@author Andre s Jime nez <am . jimenez77@uniandes . edu . co>
16
17
18 public c l a s s ArchivolToSoftwareQN {
19
20
IPreferencesService service ;
21
22
private C a n d i d a t e A r c h i t e c t u r e c a n d i d a t e A r c h i t e c t u r e ;
23
24
//
25
26
private Model model ;
27
28
private S t r i n g elementName ;
29
30
public ArchivolToSoftwareQN ( ) {
31
32
s e r v i c e = Platform . g e t P r e f e r e n c e s S e r v i c e ( ) ;
}
33
34
// G e t t e r s
35
36
public void s e t C a n d i d a t e A r c h i t e c t u r e (
37
CandidateArchitecture candidateArchitecture ) {
38
this . candidateArchitecture = candidateArchitecture ;
39
40
41
public void setElementName ( S t r i n g elementName ) {
42
43
t h i s . elementName = elementName ;
}
44
45
public Model getSoftwareQN ( ) {
46
47
return model ;
}
98
48
49
// l o g i c
50
51
public void e x e c u t e ( ) {
52
// C r e a t e s t h e new c a n d i d a t e a r c h i t e c t u r e
53
model = S o f t w a r e q n F a c t o r y . eINSTANCE . c r e a t e M o d e l ( ) ;
54
model . setName ( c a n d i d a t e A r c h i t e c t u r e . getName ( ) ) ; // a d i c i o n a r
55
// i d de
56
// e l e m e n t o
57
// s o b r e
58
// e l
59
// c u a l
60
// s e
61
// e v a l u
a
62
// r e n d i m i e n t o
63
64
ModeledArchitecturalElement modeledArchitecturalElement =
65
A r c h i v o l Q u e r y U t i l s . getModeledArchitecturalElementByName (
66
c a n d i d a t e A r c h i t e c t u r e , elementName ) ;
67
68
model ( model , m o d e l e d A r c h i t e c t u r a l E l e m e n t ) ;
}
69
70
private void model (
71
Model model ,
72
ModeledArchitecturalElement modeledArchitecturalElement ) {
73
Map r e l a t i o n s h i p s M a p =
74
new HashMap ( ) ;
75
// g e t s t h e c a l l e d e l e m e n t s
76
for ( R e l a t i o n s h i p r e l a t i o n s h i p : modeledArchitecturalElement
99
. getOutgoings ( ) ) {
77
78
ArchitecturalElementProperty order = ArchivolQueryUtils
79
. getArchitecturalElementProperty (
80
relationship , order ) ;
i f ( o r d e r != null ) {
81
82
r e l a t i o n s h i p s M a p . put (
83
I n t e g e r . parseInt ( order . getValue ( ) ) ,
84
relationship );
}
85
86
87
88
R e l a t i o n s h i p l a s t R e l a t i o n s h i p = null ;
89
Resource l a s t R e s o u r c e = null ;
90
91
92
for ( I n t e g e r order : relationshipsMap . keySet ( ) ) {

Relationship relationship = relationshipsMap
93
. get ( order ) ;
94
95
Resource r e s o u r c e = S o f t w a r e q n F a c t o r y . eINSTANCE
96
. createResource ( ) ;
97
r e s o u r c e . setName ( r e l a t i o n s h i p . g e t T a r g e t ( ) . getName ( ) ) ;
98
ArchitecturalElementProperty serviceTime =
99
ArchivolQueryUtils . getArchitecturalElementProperty (
100
r e l a t i o n s h i p . getTarget ( ) ,
101
serviceTime ) ;
102
i f ( s e r v i c e T i m e != null ) {
103
r e s o u r c e . s e t S e r v i c e T i m e ( Double
104
105
. parseDouble ( serviceTime . getValue ( ) ) ) ;

}
100
106
r e s o u r c e . setType ( ResourceType .INDEPENDENT) ;
107
model . g e t R e s o u r c e s ( ) . add ( r e s o u r c e ) ;
108
109
Connection c o n n e c t i o n = S o f t w a r e q n F a c t o r y . eINSTANCE
110
111
. createConnection ( ) ;
ArchitecturalElementProperty synchronicity =
112
113
114
relationship , synchronicity );
i f ( s y n c h r o n i c i t y == null
| | s y n c h r o n i c i t y . getValue ( ) . equals (
115
synchronous ) ) {
116
117
connection
118
119
. s e t S y n c h r o n i c i t y ( S y n c h r o n i c i t y T y p e .SYNCHRONOUS) ;
} else i f ( s y n c h r o n i c i t y . getValue ( ) . equals (
asynchronous ) ) {
120
121
connection
122
123
. s e t S y n c h r o n i c i t y ( S y n c h r o n i c i t y T y p e .ASYNCHRONOUS) ;
}
124
125
i f ( l a s t R e s o u r c e != null ) {
126
connection . setSource ( lastResource ) ;
127
128
connection . setTarget ( resource ) ;
129
130
131
132
i f ( l a s t R e l a t i o n s h i p != null ) {
A r c h i t e c t u r a l E l e m e n t P r o p e r t y communicationTime1 =
133
lastRelationship ,
134
communicationTime ) ;
101
i f ( communicationTime1 != null ) {
135
136
c o n n e c t i o n . setCommunicationTime ( Double
137
. p a r s e D o u b l e ( communicationTime1
138
. getValue ( ) ) ) ;
}
139
140
141
A r c h i t e c t u r a l E l e m e n t P r o p e r t y communicationTime2 =
142
143
144
r e l a t i o n s h i p , communicationTime ) ;
i f ( communicationTime2 != null ) {
145
c o n n e c t i o n . setCommunicationTime ( Double
146
. p a r s e D o u b l e ( communicationTime2
147
148
. getValue ( ) ) ) ;
}
149
150
ArchitecturalElementProperty probability =
151
152
153
relationship , probability );
i f ( p r o b a b i l i t y != null ) {
154
c o n n e c t i o n . s e t P r o b a b i l t y ( Double
155
156
. parseDouble ( p r o b a b i l i t y . getValue ( ) ) ) ;
} else {
157
158
connection . setProbabilty ( 1 ) ;
}
159
160
model . g e t C o n n e c t i o n s ( ) . add ( c o n n e c t i o n ) ;
161
162
lastRelationship = relationship ;
163
lastResource = resource ;
102
164
165
i f ( ! r e l a t i o n s h i p . getTarget ( ) . getOutgoings ()
. isEmpty ( ) ) {
166
167
Model submodel = S o f t w a r e q n F a c t o r y . eINSTANCE
168
. createModel ( ) ;
169
submodel . setName ( r e s o u r c e . getName ( ) ) ;
170
r e s o u r c e . setSubmodel ( submodel ) ;
171
model ( submodel , r e l a t i o n s h i p . g e t T a r g e t ( ) ) ;
}
172
}
173
174
175 }
103
104
REFERENCIAS
[1] Arsanjani, A., Zhang, L.-J., Ellis, M., Allam, A., and Channabasavaiah,
K., March posted-at = 2007-12-17 16:05:57, priority = 0, publisher = IBM, title = Design an SOA solution using a reference architecture, url = http://www128.ibm.com/developerworks/library/ar-archtemp/index.html, year = 2007,.
[2] The java ee 5 tutorial.
[3] Registro unico nacional de transito.
[4] SAAM: a method for analyzing the properties of software architectures, 1994.
[5] Business process modeling notation specification, omg final adopted specification,
February 2006.
[6] Service oriented architecture modeling language, tech. rep., Object Management
Group, 2009.
[7] Das polizeiliche informationssystem inpol.
[8] Menasce, D. A., Almeida, V. A. F., and Dowdy, L. W., Performance by Design:
Computer Capacity Planning by Example: Computer Capacity Planning. Prentice Hall
International.
[9] Little, J. D. C., A Proof for the Queuing Formula: L= ? W, Operations Research,
vol. 9, p. 383387, 1961.
[10] Porter, M. E., Competitive Strategy: Techniques for Analyzing Industries and Competitors. Free Press, 1 ed., June 1980.
[11] Smith, C. U., Performance Engineering of Software Systems. Boston, MA, USA:
Addison-Wesley Longman Publishing Co., Inc., 1st ed., 1990.
[12] Laprie, J., Beounes, C., Kaaniche, M., and Kanoun, K., The transformation
approach to the modeling and evaluation of the reliability and availability growth,
p. 364 -371, jun 1990.
[13] Jones, J. C., Design Methods (Architecture). Wiley, Sept. 1992.
[14] Perry, D. E. and Wolf, A. L., Foundations for the study of software architecture,
SIGSOFT Softw. Eng. Notes, p. 4052, October 1992.
[15] Garlan, D. and Shaw, M., An introduction to software architecture, p. 139,
Publishing Company, 1993.
[16] Gamma, E., Helm, R., Johnson, R., and Vlissides, J. M., Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Professional, 1 ed., Nov.
1994.
[17] Barbacci, M., Klein, M. H., Longstaff, T. H., and Weinstock, C. B.,
Quality attributes, Tech. Rep. CMU/SEI-95-TR-021, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, Dec. 1995.
[18] Shaw, M. and Garlan, D., Software Architecture: Perspectives on an Emerging
Discipline. Prentice Hall, Apr. 1996.
[19] Bianco, P., Kotermanski, R., and Merson, P., Evaluating a Service Oriented Architecture, Tech. Rep. CMU/SEI-2007-TR-015, Software Engineering Institute, Sept.
1997.
[20] Smith, C. U. and Williams, L. G., Performance engineering evaluation of objectoriented systems with spe*ed, in Proceedings of the 9th International Conference
on Computer Performance Evaluation: Modelling Techniques and Tools, p. 135154,
Springer-Verlag, 1997.
[21] Barbacci, M., Klein, M., and Weinstock, C., Principles for Evaluating the Quality Attributes of a Software Architecture, Tech. Rep. CMU/SEI-96-TR-036, Software
Engineering Institute, May 1997.
[22] Recommended best industrial practice for software architecture evaluation, 1997.
[23] Slaughter, S. A., Harter, D. E., and Krishnan, M. S., Evaluating the cost of
software quality, Commun. ACM, p. 6773, August 1998.
[24] Fielding, R., Gettys, J., Mogul, J. C., Frystyk, H., Masinter, L., Leach,
P., and Berners-Lee, T., Hypertext Transfer Protocol HTTP/1.1, tech. rep.,
1998.
[25] Microsystems, I. S., Javamail api specification version 1.1 (javamail specification),
tech. rep., Sun Microsystems, Inc., 1998.
[26] Williams, L. G. and Smith, C. U., Performance evaluation of software architectures, in Proceedings of the 1st international workshop on Software and performance,
WOSP 98, p. 164177, ACM, 1998.
[27] Group, O. M., The common object request broker: Architecture and specification
(corba 2.3.1 specification), tech. rep., Object Management Group, Oct. 1999.
` s, A., esse: an expert
[28] Vlahavas, I., Stamelos, I., Refanidis, I., and Tsoukia
system for software evaluation, Knowledge-Based Systems, vol. 12, p. 183 197, 1999.
[29] Modarres, M., Kaminskiy, M., and Krivtsov, V., Reliability engineering and risk
analysis. Quality and reliability, 55, Marcel Dekker, 1999.
[30] ATAM: Method for Architecture Evaluation, 2000.
[31] OMG, Object Modeling Group, 2000.
105
[32] Fielding, R. T., REST: Architectural Styles and the Design of Network-based Software Architectures. Doctoral dissertation, University of California, Irvine, 2000.
[33] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, N., Nielsen,
H. F., Thatte, S., and Winer, D., Simple object access protocol (SOAP) 1.1, W3C
Note NOTE-SOAP-20000508, World Wide Web Consortium, May 2000.
[34] Kazman, R., Asundi, J., and Klein, M., Quantifying the costs and benefits of
architectural decisions, in ICSE 01: Proceedings of the 23rd International Conference
on Software Engineering, p. 297306, IEEE Computer Society, 2001.
[35] Klensin, L., Simple Mail Transport Protocol, RFC 2821, tech. rep., IETF, Apr.
2001.
[36] Dobrica, L. and Niemelä, E., A Survey on Software Architecture Analysis
Methods, IEEE Transactions on Software Engineering, vol. 28, p. 638653, 2002.
[37] .net framework, Programa de Computador, January 2002.
[38] Smith, C. U. and Williams, L. G., Performance Solutions- A Practical Guide to
Creating Responsive, Scalable Software. Addison-Wesley, 2002.
[39] Group, O. M., Common warehouse metamodel 1.1 specification, Specification Version 1.1, Volume 1, Object Management Group, March 2003.
[40] Clements, P., Garlan, D., Little, R., Nord, R., and Stafford, J., Documenting software architectures: views and beyond, in Proceedings of the 25th International
Conference on Software Engineering, ICSE 03, p. 740741, IEEE Computer Society,
2003.
[41] Miller, J. and Mukerji, J., Mda guide version 1.0.1, Tech. Rep. omg/03-06-01,
Object Management Group (OMG), June 2003.
[42] Bass, L., Clements, P., and Kazman, R., Software Architecture in Practice. SEI
Series in Software Engineering, Addison-Wesley Professional, second ed., April 2003.
zivin, J., In search of a basic principle for model driven engineering, Novatica
[43] Be
Journal Special Issue, vol. V, p. 2124, 2004.
[44] Balsamo, S., Di Marco, A., Inverardi, P., and Simeoni, M., Model-based
performance prediction in software development: a survey, Software Engineering,
IEEE Transactions on, vol. 30, p. 295310, 2004.
[45] Pressman, R. and Pressman, R., Software Engineering: A Practitioners Approach.
McGraw-Hill Science/Engineering/Math, 6 ed., Apr. 2004.
[46] Birsan, D., On plug-ins and extensible architectures, Queue, p. 4046, March 2005.
[47] Erl, T., Service-Oriented Architecture (SOA): Concepts, Technology, and Design.
Prentice Hall, August 2005.
[48] Jansen, A. and Bosch, J., Software Architecture as a Set of Architectural Design
Decisions, p. 109120, IEEE Computer Society, 2005.
106
[49] Rozanski, N. and Woods, E., Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives. Addison-Wesley Professional, 2005.
[50] Sun Microsystems, I., May 2006.
[51] Schmidt, D. C., Model-Driven Engineering, Computer, vol. 39, p. 2531, 2006.
[52] OMG, Software Process Engineering Metamodell SPEM 2.0 OMG Draft Adopted
Specification, tech. rep., OMG, 2006.
[53] Zeiss, B., Vega, D., Schieferdecker, I., Neukirchen, H., and Grabowski,
J., Applying the iso 9126 quality model to test specifications - exemplified for ttcn3 test specifications., in Software Engineering (Bleek, W.-G., Raasch, J., and
llighoven, H., eds.), p. 231-244, GI, 2007.
Zu
[54] Smith, C. U., Introduction to software performance engineering: origins and outstanding problems, in Proceedings of the 7th international conference on Formal methods for performance evaluation, SFM07, p. 395428, Springer-Verlag, 2007.
[55] Becker, S., Koziolek, H., and Reussner, R., Model-based performance prediction with the palladio component model, in Proceedings of the 6th international
workshop on Software and performance, WOSP 07, p. 5465, ACM, 2007.
[56] OSGi service platform core specification, release 4.1, http://www.osgi.org/
Specifications, 2007.
[57] OBrien, L., Merson, P., and Bass, L., Quality Attributes for Service-Oriented
Architectures, in SDSOA 07: Proceedings of the International Workshop on Systems
Development in SOA Environments, (Washington, DC, USA), IEEE Computer Society,
2007.
[58] Zhu, L., Liu, Y., Bui, N. B., and Gorton, J., Revel8or: Model driven capacity
planning tool suite, p. 797 -800, may 2007.
[59] Rosen, M., Lublinsky, B., Smith, K. T., and Balcer, M. J., Applied SOA:
Service-Oriented Architecture and Design Strategies. Wiley, June 2008.
[60] Steinberg, D., Budinsky, F., Paternostro, M., and Merks, E., EMF: Eclipse
Modeling Framework (2nd Edition). Addison-Wesley Professional, 2 ed., Jan. 2008.
[61] Bocciarelli, P. and D?Ambrogio, A., Model-driven performability analysis of
composite web services, in Performance Evaluation: Metrics, Models and Benchmarks (Kounev, S., Gorton, I., and Sachs, K., eds.), p. 228-246, Springer Berlin
/ Heidelberg, 2008.
[62] OASIS, Reference architecture for service oriented architecture version 1.0, tech.
rep., April 2008.
[63] Bell, M., Service-Oriented Modeling (SOA): Service Analysis, Design, and Architecture. Wiley, February 2008.
[64] Arsanjani, A., Ghosh, S., Allam, A., Abdollah, T., Gariapathy, S., and
Holley, K., Soma: a method for developing service-oriented solutions, IBM Syst.
J., vol. 47, p. 377396, 2008.
107
[65] Hofmeister, H. and Wirtz, G., Supporting service-oriented design with metrics,
p. 191 -200, sept. 2008.
[66] de Ingeniera de Sistemas, A. C., Arquitectura orientada a servicios, SISTEMAS, 2009.
[67] Kalin, M., Java web services: up and running. OReilly, 2009.
[68] Assmann, M., Model-Based Evaluation of Service-Oriented Enterprise Architectures.
PhD thesis, University of Paderborn, 2009.
[69] Erl, T., SOA Design Patterns (The Prentice Hall Service-Oriented Computing Series
from Thomas Erl). Prentice Hall PTR, 1 ed., Jan. 2009.
[70] Taylor, R. N., Medvidovic, N., and Dashofy, I. E., Software Architecture: Foundations, Theory, and Practice. Wiley, Jan. 2009.
[71] Liu, H. H., Software Performance and Scalability: A Quantitative Approach (Quantitative Software Engineering Series). Wiley, May 2009.
[72] Marino, J. and Rowley, M., Understanding SCA (Service Component Architecture).
Addison-Wesley Professional, 1 ed., July 2009.
[73] Archivol metamodel, 2010.
[74] Goncalves, A., Beginning Java EE 6 with GlassFish 3, Second Edition. Apress Series,
Apress, 2010.
[75] Garlan, D., Bachmann, F., Ivers, J., Stafford, J., Bass, L., Clements, P.,
and Merson, P., Documenting Software Architectures: Views and Beyond. AddisonWesley Professional, 2nd ed., 2010.
[76] Ortega, D. A. C., Estrategia dirigida por modelo para el gobierno soa, Masters
thesis, Universidad de los Andes, 2010.
[77] OMG, Omg unified modeling language (omg uml) infrastructure version 2.3, Tech.
Rep. formal/2010-05-03, 2010.
a, Y., Correal, D., and Hernandez, T., Reusing legacy systems in a service[78] Pen
oriented architecture: A model-based analysis, in Advances in Conceptual Modeling
a?? Applications and Challenges (Trujillo, J., Dobbie, G., Kangassalo, H.,
Hartmann, S., Kirchberg, M., Rossi, M., Reinhartz-Berger, I., ZimAnyi,

E., and Frasincar, F., eds.), p. 86-95, Springer Berlin / Heidelberg, 2010.
[79] Xtext user guide,
http://www.eclipse.org/, 2010.
rrez, B. R. P., Menta: Un enfoque dirigido por modelos para el analisis de
[80] Gutie
escenarios de calidad en sistemas soa auto-adaptables, Masters thesis, Universidad
de los Andes, 2011.
R fusion middleware concepts and architecture for oracle service bus 11g release
[81] Oracle
1 (11.1.1.4.0), Jan. 2011.
108
rrez, A. D., Somacgov: Clasificador de madurez en gobernanza asistido por

[82] Gutie
modelos para arquitecturas orientadas a servicios, Masters thesis, Universidad de los
Andes, 2011.
109

ArchiMet: Herramienta Dirigida Por Modelos para La Evaluaci On de Rendimiento Sobre SOAs

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

ArchiMet: Herramienta Dirigida Por Modelos para La Evaluaci On de Rendimiento Sobre SOAs

Загружено:

Авторское право:

Доступные форматы

ArchiMet: Herramienta dirigida por modelos para la

Para optar al ttulo de

Ingeniera de Sistemas y Computacion

ArchiMet: Herramienta dirigida por modelos para la

Daro Ernesto Correal Torres, Asesor

Jorge Alberto Villalobos Salcedo

Alexis Eduardo Ocampo Ramirez

A Sofi y a Dalis por ser una excelente compa

Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . .

Arquitecturas Orientadas a Servicios . . . . . . . . . . . . . . . . . . . . .

Ingeniera dirigida por Modelos . . . . . . . . . . . . . . . . . . . . . . . .

Expresar arquitecturas candidatas . . . . . . . . . . . . . . . . . . . . . . .

Especificar los requerimientos de calidad . . . . . . . . . . . . . . . . . . .

Predecir comportamiento de arquitecturas candidatas por cada atributo de

plug-in co.edu.uniandes.moosas.archivol.qualityrequirements - DSL para especificar requerimientos de calidad . . . . . . . . . . . . . . . . . . . . . .

plug-in co.edu.uniandes.moosas.archivol.somfeaimporter - Adaptador Enterprise Architect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

plug-in co.edu.uniandes.moosas.archivol.archimet - Controlador . . . . . .

plug-in co.edu.uniandes.moosas.archivol.archimet.soaperformance - Evaluador de rendimiento en SOAs . . . . . . . . . . . . . . . . . . . . . . . . .

Tiempos de servicio para servicios atomicos y tiempos de comunicacion 60

Tiempos de servicio para servicios compuestos . . . . . . . . . . . .

SINTAXIS QUALITY REQUIREMENTS DSL . . .

GUIA PARA USAR ARCHIMET . . . . . . . . . . . .

Escenario de calidad de ejemplo . . . . . . . . . . . . . . . . . . . . . . . . .

Escenario de calidad de rendimiento . . . . . . . . . . . . . . . . . . . . . .

Escenario de calidad de flexibilidad . . . . . . . . . . . . . . . . . . . . . . .

Escenario de calidad de reutilizacion . . . . . . . . . . . . . . . . . . . . . .

Tiempos de servicio estimados para servicios atomicos . . . . . . . . . . . .

Tiempos de servicio calculados para servicios compuestos . . . . . . . . . .

Ejemplo de resultado al evaluar los requerimientos 3 arquitecturas candidatas 47

Tiempos de servicio de servicios atomicos . . . . . . . . . . . . . . . . . . .

Tiempos de servicio calculados usando ArchiMet . . . . . . . . . . . . . . .

Impacto de usar una SOA sobre el atributo de calidad rendimiento [57] . . .

Proceso de negocio de registrar inmueble . . . . . . . . . . . . . . . . . . . .

Servicios candidatos identificados durante el analisis . . . . . . . . . . . . .

ejemplo de vista de tipo modulo

ejemplo de vista de tipo componente conector . . . . . . . . . . . . . . . . .

Ejemplo de ecosistema SOA . . . . . . . . . . . . . . . . . . . . . . . . . . .

Paquete candidate de Archivol - Fuente [73] . . . . . . . . . . . . . . . . . .

Paquete evaluation de Archivol - Fuente [73] . . . . . . . . . . . . . . . . . .

Modelo Archivol con elementos de la arquitectura de InAlpes . . . . . . . .

Modelo Archivol de arquitectura candidata para InAlpes . . . . . . . . . . .

Modelo Archivol con definicion de SOA . . . . . . . . . . . . . . . . . . . .

Arquitecturas candidatas para evaluar . . . . . . . . . . . . . . . . . . . . .

Modelo de colas para arquitectura A . . . . . . . . . . . . . . . . . . . . . .

Diagrama de tiempos de SOA con comunicacion sincronica

Diagrama de tiempos de SOA con comunicacion asincronica . . . . . . . . .

Arquitectura de plug-ins ArchiMet . . . . . . . . . . . . . . . . . . . . . . .

Editor SOMF de Enterprise Architect . . . . . . . . . . . . . . . . . . . . .

Asistente para transformar SOMF a Archivol . . . . . . . . . . . . . . . . .

Metamodelo de Enterprise Architect . . . . . . . . . . . . . . . . . . . . . .

Ejemplo de modelo Archivol generado a partir de diagrama de dise

Interfaz definida para plug-ins de evaluacion . . . . . . . . . . . . . . . . . .

Asistente para evaluar arquitecturas candidatas . . . . . . . . . . . . . . . .

Metamodelo de colas para recursos de software . . . . . . . . . . . . . . . .

Nuevo proyecto en Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Nuevo archivo de requerimientos de calidad . . . . . . . . . . . . . . . . . .

Abrir con Quality Requierements Editor . . . . . . . . . . . . . . . . . . . .

Asistente de contenido de Quality Requirements Editor . . . . . . . . . . .

Nuevo Architecture from Enterprise Architect File . . . . . . . . . . . . . .

Datos de entrada para asistente de transformacion de Enterprise Architect a

Nuevo Candidate Architecture Evaluation . . . . . . . . . . . . . . . . . . .

mostrar vista Archivol Evaluation

a cambio de un costo de tiempo y horas de consultora de un experto en temas especficos