Framework para el diseño de API REST basado

en BPMN y MDA
Victor Alfonso De Hoyos Paternina
Politécnico Gran Colombiano
Maestrı́a en Ingenierı́a de Sistemas
Septiembre 2019

1 Contexto
Cada dı́a se da más importancia al concepto de integración en el mundo de la
ingenierı́a de software, esto debido a que las organizaciones cuentan con una
gran cantidad de sistemas legacy que se convierte cada uno en una isla de
información, teniendo en si datos vitales según su tipo para el crecimiento de la
compañı́a.
Es en este punto en el que las API RESTful cobran gran importancia, pues
permiten integrar todos los sistemas legacy, haciendo de esta forma, que la
información parezca estar centralizada en una única fuente, lo cual minimiza la
complejidad para su análisis.
Al evaluar el modelos de ciclo de vida de desarrollo de software (En espe-
cial enfocado al desarrollo de Web Services), se pueden identificar las etapas
de diseño (Entre ellos el Diseño Funcional) e implementación (o Codificación)
como la base fundamental para que un proyecto resulte exitoso.

Figure 1: Proceso de Desarrollo de Software

1
 Durante la fase de diseño es donde se modela el proyecto, se traducen los
procesos a un lenguaje más técnico. Quienes participan en esta fase son las
personas más expertas en el negocio junto a los dueños del proceso.
Se debe aprovechar el conocimiento y expertiz de los analistas funcionales, e
involucrarlos un poco más en la etapa de codificación, permitiendo ası́ asegurar
que el producto final cumpla con lo inicialmente planteado.

2 Descripción del Problema

Si bien BPM define como crear los procesos de negocio y hace notar la impor-
tancia de esta tarea, se hace necesario una forma de plasmarlo gráficamente,
aquı́ es donde aparece BPMN (Business Process Model and Notation) en su
versión 2.0.
BPMN proporciona una notación gráfica para especificar procesos empre-
sariales en un diagrama de proceso empresarial. Su objetivo es respaldar el
modelado de procesos de negocios al proporcionar una notación estándar que es
comprensible para los usuarios de negocios, aunque representa una semántica
de procesos complejos para los usuarios técnicos.
BPMN se ha convertido en el estándar de facto para los diagramas de pro-
cesos de negocios. Está destinado a ser utilizado directamente por las partes
interesadas que diseñan, administran y realizan procesos de negocios, pero al
mismo tiempo son lo suficientemente precisos como para permitir que los dia-
gramas BPMN se traduzcan en componentes de procesos de software.
BPMN tiene una notación similar a un diagrama de flujo fácil de usar que es
independiente de cualquier entorno de implementación en particular, por esto
se considera perfecto para modelar el flujo que debe seguir un API RESTful que
se quiere desarrollar. Lo cual permitirá la fácil aplicación de pruebas de caja
negra y caja blanca.
Si bien en la etapa de codificación, el diseño funcional y más especı́ficamente
los diagramas diseñados son el insumo base. Estos siguen siendo solo una guı́a,
que es utilizada por los desarrolladores para cumplir con las reglas definidas. Lo
cual significa volver a iniciar la fase anterior, es decir, realizar un entendimiento,
pero esta vez desde otro punto de vista, con requerimientos más aterrizados y
acotados.
Suponer reiniciar una fase de entendimiento y contextualización del proceso
o lógica de negocio, del documento generado en la etapa anterior, asimilarlo y
convertirlo a un lenguaje más técnico, significa un costo considerable para el
proyecto en todos los aspectos, dado que todo el esfuerzo realizado durante la
etapa de análisis y diseño se podrı́a ver como innecesaria o poco provechosa. Lo
cual puede generar un riesgo de desviación al proyecto o simplemente dismin-
ución de la rentabilidad.

En la actualidad existen herramientas que permiten diseñar API RESTfull

mediante estructuras JSON, lo que significa que el diseñador de las mismas

2
deberá contar con un conocimiento base sobre el formato y por qué no, de
JavaScript. Por ende, esta tarea se le dificulta a aquellos analistas que no son
desarrolladores o no tienen nociones sobre desarrollo.
Lo cual significa que la definición y diseño de los procesos que se realiza du-
rante la fase de análisis solo queda plasmada en un documento como diagramas
de flujo, no genera un valor adicional al resto del proyecto, más allá de servir
como guı́a, no permite el sustancial aporte que podrı́an realizar los analistas de
negocio.

3 Quienes son los Interesados

Este proyecto va dirigido a los participantes del proceso de desarrollo de soft-
ware, aquellos que participan durante todo el flujo de un proyecto de desarrollo,
a continuación se relacionan los roles que se podrı́an ver beneficiados y su posible
aporte para el rol:

• Gerentes de Proyecto: Podrá obtener mayor rentabilidad en los proyec-

tos, dado que se optimizará la cantidad de horas invertidas en cada una
de las fases y a su vez se tendrán entregables mucho más rápido.
• Analistas Funcionales: Podrá realizar un mayor aporte al proyecto,
generando API Dummy a partir del diseño funcional, permitiendo de esta
manera que los desarrolladores tengan una versión inicial de lo que se
espera.
• Desarrolladores: Permitirá reducir el tiempo de desarrollo de un API
Rest, dado que contará con un proyecto base en el que solo deberá agregar
fuentes de datos y algunas customizaciones, centrándose en lo importante
que deberá ser la lógica de negocio.

4 Planteamiento de la Solución
MDA es un enfoque de desarrollo de software a través del uso de modelos previos
al código, estos proveen herramientas y mecanismos que asisten al desarrollador
para los procesos de concepción, desarrollo, implementación y mantenimiento
del software.

Entendiendo los conceptos de BPMN y MDA, y dado que BPMN es uno de

los lenguajes más utilizados para modelar los flujos de trabajo que se quieren
convertir en programa, se plantea tomar el modelo generado durante el diseño
funcional y a partir de las reglas y pasos definidos en este, generar un proyecto
Dummy completamente funcional.

Utilizando Arquitectura Dirigida por modelos, se podrı́a brindar la posibil-

idad a los analistas funcionales, de aportar en gran medida a la fase de desar-
rollo, dado que gran parte del trabajo se podrı́a entregar a los desarrolladores,

3
los cuales se centrarı́an en la lógica de negocio, dejando de lado la creación y
configuración de la versión inicial del proyecto.

Esto también podrı́a beneficiar a los equipos que requieran de la API para
continuar con sus trabajos, dado que al existir un Dummy de dicho API, no
se hace necesario esperar a que se termine 100% el desarrollo para que puedan
avanzar, es decir, tendrı́an una versión disponible lo más parecido al producto
final.

4
5 Referencias
1. Castro, S. J. B., Martinez, O. S., Crespo, R. G., Espada, J. P., Garcia, V. H.
M. 2012, in 7th Iberian Conference on Information Systems and Technologies
(CISTI 2012), 1–6.
2. Cortes Cornax, M., Dupuy-Chessa, S., Rieu, D., Mandran, N. 2014, Software
Systems Modeling, 15
3. Fielding, R. T. 2000, Architectural Styles and the Design of Network-based
Software Architectures
4. Foster, I., Parastatidis, S., Watson, P., Mckeown, M. 2008, Commun. ACM,
51, 34
5. Haupt, F., Leymann, F., Scherer, A., Vukojevic-Haupt, K. 2017, in 2017
IEEE
6. International Conference on Software Architecture (ICSA) (IEEE), 55–58
7. Haupt, F., Leymann, F., Vukojevic-Haupt, K. 2018, Computer Science -
Research and Development, 33, 291
8. Lindland, O. I., Sindre, G., Solvberg, A. 1994, IEEE Software, 11, 42
9. MG. 2019, Business Process Model and Notation (BPMN)
10. Pautasso, C. 2011, 74–87
11. Pautasso, C., Ivanchikj, A., Schreier, S. 2015, 87–94
12. RAML. 2019, RAML 1.0 Specification
13. SWAGGER. 2019, Swagger API Desing
14. Vinoski, S. 2008, IEEE Internet Computing, 12, 84
15. Weerawarana, S., Curbera, F., Leymann, F., Storey, T., Ferguson, D. F.
16. 2005, Web Services Platform Architecture: SOAP, WSDL, WS-Policy, WS-
Addressing, WS-BPEL, WS-Reliable Messaging and More ( Upper Saddle River,
NJ, USA: Prentice Hall PTR)
17. Weske, M. 2007, Business Process Management: Concepts, Languages, Ar-
chitectures