Download IEEE Paper Template in A4 (V1)

>>Atas CIAIQ2015
>>Investigação Qualitativa em Engenharia e Tecnologia//Investigación Cualitativa en Ingeniería y Tecnología//Volume 4
Definición y validación de la capa arquitectónica de
aplicaciones a través de ADM-TOGAF y ADLs
Definition and validation of the architectural
application layer through ADM-TOGAF and ADLs
Armando Cabrera S, Marco Abad E, Danilo Jaramillo H,
Freddy Romero S.
Departamento de Ciencias de la Computación y Electrónica
Universidad Técnica Particular de Loja
Loja, Ecuador
aacabrera@utpl.edu.ec, mpabad@utpl.edu.ec,
djaramillo@utpl.edu.ec, flromero@utpl.edu.ec
Resumen — El presente trabajo muestra el proceso de
levantamiento y definición de la capa de aplicaciones utilizando la
descripción del modelo arquitectónico ADM-TOGAF; este
se adaptó al modelo “4 + 1” de Kruchten para la representación
del estado actual y el estado futuro de la arquitectura de
aplicaciones en base a los requerimientos definidos en las
iteraciones de capacidad y desarrollo del ADM. Como resultado se
obtuvo la arquitectura de aplicaciones orientada a servicios –
SOA - contemplando el uso de un bus de servicios empresariales
ESB [1]. La arquitectura fue implementada en código java en una
abstracción de alto nivel que nos permite el posterior diseño y
validación a través Sonargraph Architect como lenguaje de
descripción arquitectónica –ADL.
Palabras Clave— Arquitectura de Aplicaciones, TOGAF,
ADM, Arquitectura Empresarial, “Vistas 4+1”, SOA, ESB.
Abstract— This work shows the process of lifting and defining the
applications layer using the description of the ADM-TOGAF
architectural model; that was adapted to the Kruchten’s “ 4 + 1"
model for representing the current and future status of the
application architecture, based on the requirements defined in the
capacity and development iterations of the ADM. As a result, it
has been obtained an application service oriented architecture SOA – that considers the use of an ESB enterprise service bus [1].
The architecture was implemented in java code in a high level
abstraction that allows the subsequent design and validation
through Sonargraph Architect as an architectural description
language – ADL.
Keywords— Applications Architecture, TOGAF, Enterprise
Architecture, “4+1”SOA, ESB
I. INTRODUCCIÓN
El uso correcto de las herramientas tecnológicas más
conocidas de IT (Infraestructura Tecnológica) representa una
gran ventaja competitiva para las empresas, para esto es
importante una óptima gestión de los objetivos de negocio y de
55
José Carrillo Verdúm
Departamento de Lenguajes y Sistemas Informáticos
Universidad Politécnica de Madrid
Madrid, España
jcarrillo@fi.upm.es
IT. El enfoque tradicional es mantener separada gestión de IT
con la gestión de negocio, lo cual ocasiona problemas de
integración, adaptación e interoperabilidad entre aplicaciones de
software, debido al constante cambio del negocio y las
condiciones del mercado y a la falta de integración entre estos.
La Arquitectura Empresarial (AE) en contraste con el
enfoque tradicional propone la integración entre el negocio y la
infraestructura tecnológica. Para la correcta aplicación de la AE
existen marcos de referencia de arquitectura empresarial como
TOGAF (The Open Group Architecture Framework), el cual
incluye un Método de Desarrollo Arquitectónico (ADM), guías,
técnicas y modelos de referencia. Las principales características
de TOGAF son su aplicabilidad a diferentes contextos
empresariales y su adaptabilidad con diferentes marcos de
referencia que se basan entregables específicos, para este caso,
se adaptó con el Modelo “4+1”de Kruchten.
El presente estudio se aplicó en el Grupo Empresarial
Monterrey (GEM), que es uno de los principales ingenios
azucareros del Ecuador, ubicado al sur del país en la provincia
de Loja, cantón Catamayo. Fundado el año de 1959.
Actualmente cuenta con más de 1000 empleados los cuales
trabajan de forma distribuida veinticuatro (24) horas al día.
Actualmente la organización se encuentra en un proceso de
trasformación empresarial para lo cual se han establecido
diferentes grupos de trabajo tomando como referencia las
iteraciones arquitectónicas y fases definidas en ADM-TOGAF.
II. ANTECEDENTES
La arquitectura empresarial implica la organización lógica
de los procesos de negocio y la infraestructura tecnológica de
una empresa. [2]
>>Atas CIAIQ2015
>>Investigação Qualitativa em Engenharia e Tecnologia//Investigación Cualitativa en Ingeniería y Tecnología//Volume 4
DATOS
DATOS
ESTRATEGIA
ESTRATEGIA DEL
DEL
NEGOCIO
NEGOCIO
dirige
dirige
DISEÑO
DISEÑO DE
DE LA
LA
SOLUCION
SOLUCION
dirige
dirige
APLICACIONES
APLICACIONES
INFRAESTRUCTURA
INFRAESTRUCTURA
Figura 1. Nueva idea de la Arquitectura empresarial [2]
TOGAF , es un Framework de Arquitectura Empresarial, el
cual posee un método detallado para el desarrollo de la
arquitectura empresarial, y un conjunto de herramientas de
apoyo, para la aceptación, desarrollo, uso y mantenimiento de la
arquitectura. [4]
El método de desarrollo arquitectónico (ADM), no es un
método mandatorio, ya que permite su adaptación a necesidades
específicas. Una de las actividades previas a la aplicación del
ADM es generar una adaptación del mismo, para que se acople
a las circunstancias de la empresa. La adaptación e
implementación de un ciclo arquitectónico a través de ADM, se
fundamentó en la evaluación del nivel de madurez de la
empresa para adoptar la arquitectura empresarial. Las fases
necesarias para el desarrollo del trabajo arquitectónico y el
orden de dichas fases, se modifican de acuerdo a las
necesidades empresariales. [5]
ADM, sugiere cuatro (4) ciclos de iteraciones los cuales se
representan en la Fig. 1. Las iteraciones son:

Iteración de capacidad: apoya la creación y la
evolución de la capacidad arquitectónica. Actividades
que involucran la definición de propósitos, principios,
alcance, visión y gobernanza de la Arquitectura
Empresarial;

Iteración de desarrollo: facilita la creación del
contenido arquitectónico de manera cíclica o por
integración de las fases;

Iteración de Planificación de Transición.: apoya la
creación de hojas de ruta para cambios formales en una
arquitectura definida;

Iteración de Gobernanza Arquitectónica.: permite
gobernar las actividades referentes a los cambios
potenciales a implementar en la arquitectura objetivo:
Figura 2 ADM-TOGAF [4]
La fase de Arquitectura de Sistemas de Información. Está
compuesta por Arquitectura de Datos, y Arquitectura de
Aplicaciones. La arquitectura de aplicaciones permite
identificar los sistemas y aplicaciones que son relevantes para la
empresa, las aplicaciones son las encargadas de gestionar la
información necesaria para apoyar la ejecución de las funciones
del negocio de una manera ordenada y óptima. [3]. En las
Tablas 1 y 2 se presentan los objetivos y pasos planteados por
ADM-TOGAF en la fase de arquitectura de aplicaciones.
TABLA 1. OBJETIVOS FASE C – ARQUITECTURA DE APLICACIONES
OBJETIVOS
Desarrollar una Arquitectura de Aplicación Destino que sea funcional a la
Arquitectura de Negocio y a la Visión de la Arquitectura, y que responda a la
Petición de Trabajo Arquitectónico y a las preocupaciones de los interesados.
Identificar componentes candidatos del Plan de Itinerario de Arquitectura
basándose en las brechas identificadas entre la Arquitectura de Aplicaciones
de Línea de Base y la Arquitectura de Aplicaciones Futura (destino).
Fuente: Adaptado de TOGAF 9.1.
TABLA 2. PASOS FASE C - ARQUITECTURA DE APLICACIONES.
PASOS
Seleccionar modelos de referencia, puntos de vista y herramientas.
Desarrollar la descripción de la Arquitectura Línea Base.
Desarrollar la descripción de la Arquitectura Futura.
Desarrollar el Análisis de brechas.
Definir la hoja de ruta de componentes.
Realizar una revisión formal con los interesados.
Finalizar la arquitectura de Aplicaciones.
Crear el documento de Definición Arquitectónica.
Fuente: Adaptado de TOGAF 9.1.
El marco de contenidos TOGAF propone un conjunto de
artefactos para la Fase C-Arquitectura de Aplicaciones. Fig. 3
56
>>Atas CIAIQ2015
>>Investigação Qualitativa em Engenharia e Tecnologia//Investigación Cualitativa en Ingeniería y Tecnología//Volume 4
ARTEFACTOS
Catalogos

Catálogo del portafolio de Aplicaciones.
Catálogo de Interfaces.

Matrices
Matriz Organización/Aplicación
Matriz Organización/Aplicación
Matriz Rol/Aplicación
Matriz Funcion/Aplicación
Matriz de interaccion de Aplicaciones
integración y disponibilidad. Muestra como las unidades
de ejecución se comunican entre sí.
Vista de Desarrollo: Muestra la organización de los
módulos en el ambiente de desarrollo. Como el software es
empaquetado en pequeñas unidades para el desarrollo.
Vista de Despliegue: Considera requerimientos nofuncionales tales como disponibilidad, rendimiento,
escalabilidad. Muestra los elementos de red necesarios
para el soporte la solución de software, como nodos,
procesadores, servidores, computadoras.
-Programadores
-Gestion de Software
-Usuarios Finales
-Funcionalidad.
Diagramas
Diagrama de comunicación de Aplicaciones
VISTA
VISTA DE
DE
DESARROLLO
DESARROLLO
VISTA
VISTA LOGICA
LOGICA
Diagrama de ubicación de Aplicaciones y Usuarios
Diagrama de Casos de Uso
Diagrama de Gestion de la Empresa.
ESCENARIOS
VISTA
VISTA DE
DE PROCESOS
PROCESOS
Diagrama de Procesos/Aplicación
Diagrama de Ingeniería de Software
Diagrama de Migración de Aplicaciones.
Diagrama de Distribución de Software
-Integradores.
-Rendimiento.
-Escalabilidad.
VISTA
VISTA FISICA
FISICA
-Ingenieros en Sistemas.
-Topologia.
-Comunicaciones
Figura 5. Modelo 4+1 Vistas [7]
Figura 3 Artefactos Fase C – Arquitectura de Aplicaciones.
III. RESULTADOS.
Así mismo el marco de contenidos propone los entregables
como salidas que representan los resultados de la fase.
Entregables
Documento de Definición Arquitectónica.
Las vistas arquitectónicas [7] se obtuvieron directamente de
los interesados IT de la empresa, por medio de reuniones
presenciales y en base a documentación proporcionada por los
mismos.
RoadMap de componentes
Especificación de Requerimientos Arquitectónicos
Figura 4 Entregables Fase C – Arquitectura de Aplicaciones.
La arquitectura de aplicaciones es una vista de alto nivel de
las componentes de una aplicación y permite la toma de
decisiones a nivel estratégico. [6] La IEEE [6] define a la
arquitectura de sistemas/aplicaciones como “Conceptos
fundamentales o propiedades en un ambiente determinado. Las
propiedades como elementos y relaciones. Los conceptos
relacionados con principios de diseño y evolución.”
El modelo de vistas “4+1”, es un modelo para la
representación sistemas/aplicaciones de software. La
representación del software muestra las necesidades o
preocupaciones de los interesados de la aplicación. Las vistas
son cuatro (4): vista lógica, vista de procesos, vista de desarrollo
y vista de despliegue/física; más casos de uso.


Para el desarrollo del estudio se tomó como referencia los
entregables obtenidos en la iteración de capacidad
arquitectónica – Fase Preliminar – Fase Visón Arquitectónica y
en la iteración de desarrollo –Fase Arquitectura de NegocioADM TOGAF.
Vista Lógica: Se basa en la descomposición orientada a
objetos, muestra diagramas de clases que soporta los
requerimientos funcionales que brinda la aplicación.
Vista de Procesos: Muestra los requerimientos nofuncionales de la aplicación, tales como rendimiento,
57
La infraestructura tecnológica es un conjunto de sistemas
heredados los cuales presentan distintas limitaciones
relacionadas con la integración y escalabilidad e
interoperabilidad. Los sistemas heredados y su tecnología
actualmente son obsoletos. [9]
En el análisis y definición de la arquitectura línea base, se
pudo encontrar dos tipos de aplicaciones: aplicaciones que
interactúan con dispositivos físicos (hardware) como sensores y
actuadores; y aplicaciones de software en general. Los sensores
y actuadores forman parte de un sistema basado en un esquema
de control avanzado de fábrica debido un proceso de
automatización industrial. [10]
Los sistemas heredados están desarrollados bajo una
arquitectura cliente/servidor Fig. 6.
>>Atas CIAIQ2015
>>Investigação Qualitativa em Engenharia e Tecnologia//Investigación Cualitativa en Ingeniería y Tecnología//Volume 4
COMPUTADORA CLIENTE
Aplicación – Oracle-Forms
Tcp/Ip
SERVIDOR DE BASE D E DATOS
Diagrama de Gestión de la Empresa.
Vista Lógica.
Diagrama de Procesos/Aplicación.
Vista-Procesos.
Diagrama de Ingeniería de Software.
Vista Física.
Diagrama de Migración de Aplicaciones.
Vista Lógica.
Diagrama de Distribución de Software.
Vista Física.
Procedimientos Almacenados
En la capa de seguridad la propuesta contempla la
implementación de OpenLdap, el cual es un servidor que
implementa LDAP (Lightweight Directory Access Protocol).
Mantiene un alto grado de cumplimiento de estándares y es el
servidor de directorios más rápido en el mercado de código
abierto.
actualiza
Tablas/Vistas
serial
Tcp/Ip
Aplicación Industrial
cmp Desarrollo-SOA
SENSO RES/
ACTUADO RES
CAPA DE PRESENTACION
COMPUTADORA CLIENTE
BIZAGI - BPM
OFBIZ-ERP
WEB/ESCRITORIO/MOVIL
Figura 6. Arquitectura “AS IS” Actual.
SOAP
Los artefactos arquitectónicos definidos para la fase de
Sistemas de Información –ADM TOGAF- se desarrollaron una
vez definida la línea base de la arquitectura de aplicaciones
representada con el modelo de “4+1.
SERVIDOR APLICACIONES
ENTERPRISE SERVICE BUS (ESB)
SOAP
JAX-WS
La tabla 3 muestra la relación entre las vistas “4+1 y los
artefactos arquitectónicos correspondientes a la fase de Sistemas
de Información.
La Arquitectura Objetivo propuesta tiene un enfoque SOA
(Arquitectura Orientada a Servicios). SOA proporciona
eficiencia, productividad y agilidad, por su interoperabilidad
entre aplicaciones. [11][15].
CAPA SERVICIOS
serv icios
CAPA DE NEGOCIO
logica
Java Class
CAPA DE DATOS
entidades
En
la
Fig
7,
se
presenta
la
vista
de
implementación/desarrollo. La solución se basa en: tecnologías
open source y el uso de OracleDatabase 11g; lineamientos que
están definidos en los principios arquitectónicos de la iteración
de Capacidad Arquitectónica.
Las tecnologías son “Java Enterprise Edition” (JEE) [12]
con sus API’s presentes; Enterprise Java Bean (EJB) [13] para
capa de negocio; JAX-WS [14] para la implementación de
servicios y Java Persistence API (JPA) [15] para la capa de
acceso a datos.
TABLA 3. RELACIÓN ARTEFACTOS FASE C / MODELO KRUCHTEN
Artefacto
Modelo 4 +1/Otros
Catálogo del portafolio de Aplicaciones.
Vista-Procesos.
Catálogo de Interfaces.
Vista Procesos.
Matriz Organización/Aplicación.
Vista Proceso/
Organigrama de la empresa.
Matriz Role/Aplicación.
Casos de Uso.
Matriz Función/Aplicación.
Vista Lógica /Matriz de
Stakeholders.
Matriz de Interacción de Aplicaciones
Vista Lógica.
Diagrama de Comunicación de Aplicaciones
Diagrama de Ubicación de Aplicaciones y
Usuarios.
Diagrama de Casos de Uso.
serv icios
Java Persistence
API - JPA
JDBC
Oracle 11g
SERVIDOR BASE DE DATOS
TCP/IP
S
E
G
U
R
I
D
A
D
OpenLDAP
SERVIDOR DE SISTEMAS LEGADOS
Figura 7. Arquitectura de Aplicaciones “TO BE” (Futura).
El Bus Empresarial de Servicios (ESB) [16] permitirá la
orquestación de los servicios entre las aplicaciones con la
finalidad de integrar de sistemas empresariales. En la capa de
seguridad se gestiona la autenticación de usuarios y la gestión
de excepciones.
La representación y validación de la arquitectura se realizó a
través Sonargraph-Architec [17], herramienta que permite
evaluar y gestionar la arquitectura propuesta con un plugin del
IDE Eclipse. Evaluar la arquitectura involucra implementar
código java con una abstracción de alto nivel de una solución.
La implementación contiene las principales especificaciones de
la arquitectura “TO-BE”.
La herramienta brinda un conjunto de funcionalidades de las
cuales se usó únicamente las necesarias para la evaluación de la
arquitectura. A continuación se presentan tres figuras: Vista de
exploración de la Vista Lógica, Vista de la Arquitectura y el
Dashboard.
Vista-Procesos.
Vista Lógica.
Los requerimientos arquitectónicos se los define mediante
métricas y en relaciones entre capas. La definición de las capas
con sus relaciones se las muestra en la Fig.8.
Casos de Uso.
58
>>Atas CIAIQ2015
>>Investigação Qualitativa em Engenharia e Tecnologia//Investigación Cualitativa en Ingeniería y Tecnología//Volume 4
Figura 8. Representación de la Arquitectura SOA – Sonargh-Architect.
La vista de exploración de la Vista Lógica (Fig 9), nos
muestra las relaciones entre las capas, paquetes, y clases de la
solución. En caso de que exista un incumplimiento a los
requerimientos arquitectónicos de diseño, las relaciones se
pintan de color rojo y de verde si no existe incumplimiento.
Figura 10. Evaluación arquitectura SOA – Sonargraph-Architect.
IV. CONCLUSIONES.
La aplicación del ADM-TOGAT conduce a una empresa
hacia un nuevo esquema de gestión empresarial donde los
objetivos estratégicos de negocio se encuentren alineados con
las aplicaciones de software. Las guías brindadas por ADMTOGAF adaptadas al nivel de madurez de la empresa permiten
definir de manera eficiente la capa de sistemas de información.
El uso del modelo de Kruchten [6] en adaptación con el Método
de definición Arquitectónica - ADM de TOGAF apoya la
creación de la Arquitectura Línea Base y la Arquitectura Futura.
La definición de una arquitectura orientada a servicios
utilizando un ESB logra características de robustez y
extensibilidad en la estructura arquitectónica de aplicaciones,
permitiendo asumir los requerimientos del negocio, soportando
la integración de aplicaciones empresariales como Bizagi
(BPM) y Apache Ofbiz (ERP). Los lenguajes de descripción
arquitectónica –ADL- permiten evaluar la arquitectura a nivel
de diseño, código, y la obtención de métricas de cara a una
implementación de alto nivel.
Figura 9. Vista de Exploración /Vista lógica- Sonargrah-Architect
La Fig. 10, muestra los resultados de la evaluación de la
arquitectura. El código sometido a evaluación es un archivo
comprimido con la extensión “.war” de un proyecto Web-Java
[18]. Se puede ver que no existen violaciones a nivel
arquitectónico. En la sección tareas se listan las asignaciones
por parte del arquitecto hacia el grupo de desarrolladores. Las
asignaciones se muestran en eclipse como advertencias.
59
REFERENCIAS BIBLIOGRÁFICAS
[1]
IBM, Patterns: Implementing an SOA Using an Enterprise Service
Bus, 2004.
[2]
P. W. a. D. C. R. Jeanne W. Ross, Enterprise Architecture as
strategy: Creating a Foundation for Business Execution, United
States of America, 2006.
[3]
M. S. C. f. I. S. Research, “Semantic Community,” [Online].
Available:
http://semanticommunity.info/@api/deki/files/6830/JeanneRoss010
82007.pdf. [Accessed 12 03 2015].
[4]
T. O. Group, TOGAF 9.1, 2009.
[5]
T. O. Group, “The Open Group,” [Online].
http://pubs.opengroup.org/architecture/togaf9doc/arch/chap19.html. [Accessed 05 03 2015].
[6]
IEEE, “Systems and software engineering:Architecture description
ISO/IEC/IEEE42010,” IEEE, vol. First edition, p. 46, 2011.
[7]
P. Kruchten, “Architectural Blueprints—The “4+1” View,” IEEE
Software, 1995.
[8]
S.
Systems,
“Sparx
Systems,”
[Online].
Available:
http://www.sparxsystems.com/products/ea/. [Accessed 9 3 2015].
Available:
>>Atas CIAIQ2015
>>Investigação Qualitativa em Engenharia e Tecnologia//Investigación Cualitativa en Ingeniería y Tecnología//Volume 4
[9]
D. P. a. G. A. Robert C., Modernizing Legacy Systems., United
States of America: Pearson Education, 2003.
[10]
P. Campoy, “División De Ingeniería de Sistemas y AutomáticaUPM,”
[Online].
Available:
http://www.disam.upm.es/~campoy/Pascual_Campoy/teaching_files
/1_introduccion_al_control_de_procesos.ppt.pdf. [Accessed 09 03
2015].
[11]
T. Erl, SOA Principles of Services Desing, Boston: Pearson
Education, Inc., 2008.
[12]
Oracle, Java Plataform Enterprise Edition (Java EE) Specification,
v7, 2013 Oracle America, Inc, 2013.
[13]
Oracle, “Enterprise JavaBeans Tecnology,” [Online]. Available:
http://www.oracle.com/technetwork/java/javaee/ejb/index.html.
[Accessed 13 03 2015].
[14]
Java, “JAX-WS Reference Implementation — Project Kenai,”
[Online]. Available: https://jax-ws.java.net. [Accessed 13 03 2015].
[15]
Oracle,
“Java
Persistence
API,”
[Online].
Available:
http://www.oracle.com/technetwork/java/javaee/tech/persistencejsp-140049.html. [Accessed 13 03 2015].
[16]
M. Breest, “Centro de Informatica-Universidad Federal de
Pernambuco,”
[Online].
Available:
http://www.cin.ufpe.br/~in1062/intranet/bibliografia/fosethe_enterprise_service_bus.pdf. [Accessed 20 03 2015].
[17]
Hello2Morrow,
“Hello2Morrow,”
[Online].
Available:
https://www.hello2morrow.com/products/sonargraph/architect.
[Accessed 20 03 2015].
[18]
ORACLE, “Oracle Help Center,” [Online]. Available:
http://docs.oracle.com/javaee/6/tutorial/doc/bnaby.html. [Accessed
20 03 2015].
[19]
Bizagi, “Bizagi,” [Online]. Available: http://www.bizagi.com/es/.
[Accessed 25 03 2015].
[20]
Apache, “Apache OFBiz, The Apache Open For Business Project,”
[Online]. Available: http://ofbiz.apache.org. [Accessed 25 03 2015].
[21]
M. Fowler, Patters of Enterprise Application Architecture, Boston:
Pearson Education. Inc, 2003.
60