Traducido del inglés al español - www.onlinedoctranslator.
com
Un método de diseño de arquitectura lógica para arquitecturas de microservicios
Nuno Santos, Carlos E. Salgado, Francisco Morais, helena rodrigues,
Mónica Melo, Sara Silva, Raquel Martins, Marco Pereira Ricardo J Machado
Instituto CCG/ZGDV Investigación ALGORITMI
Guimarães
Portugal
{nuno.santos, carlos.salgado, francisco.morais,
monica.melo, sara.silva, raquel.martins,
marco.pereira}@ccg.pt rmac}@dsi.uminho.pt
RESUMEN
El uso de arquitecturas de microservicios ha sido ampliamente adoptado en el
desarrollo de software, especialmente para soluciones basadas en la nube. El
desarrollo de tales soluciones enfrenta varios desafíos más allá de las
preocupaciones típicas de arquitectura y diseño de servicios, incluida la
exposición de servicios (API), la comunicación entre servicios y la
implementación de infraestructura, entre otros. Aunque los enfoques basados
en modelos permiten abstraer el comportamiento de los microservicios del
dominio comercial, faltan métodos adecuados para abordar los desafíos
mencionados. En este artículo, la elicitación de microservicios, su identificación
utiliza casos de uso de UML funcionalmente descompuestos como entrada
dentro de un método de derivación de arquitectura lógica, a saber, una versión
adaptada de laConjunto de reglas de cuatro pasos(4SRS), utilizando diagramas
SoaML, que responde a las características específicas de los microservicios.
Demostramos el enfoque utilizando un escenario dentro de un proyecto
industrial en vivo.
CONCEPTOS CCS
El software y su ingeniería.→Idiomas de descripción del sistema
→ Lenguajes de descripción de la arquitectura•Creación y gestión
de software→ Diseño de software → Análisis de requisitos,
Ingeniería de diseño de software;
PALABRAS CLAVE
microservicios, descomposición, UML, SoaML, lógico
arquitecturas, participantes del servicio.
Formato de referencia ACM:
Nuno Santos, Carlos E. Salgado, Francisco Morais, Mónica Melo, Sara
Silva, Raquel Martins, Marco Pereira, Helena Rodrigues, Nuno Ferreira,
Este trabajo fue desarrollado dentro del proyecto IMP_4.0: Plataforma de Gestión Integrada
4.0 (POCI-01-0247-FEDER-009147), bajo el Programa Nacional de Ayudas para proyectos de
I+D de Portugal (P2020 – SI IDT), y por FCT – Fundação para a Ciência e Tecnología dentro del
Alcance del Proyecto: UID/CEC/00319/2019.
Se otorga permiso para hacer copias digitales o impresas de todo o parte de este trabajo para
uso personal o en el aula sin cargo, siempre que las copias no se hagan o distribuyan con
fines de lucro o ventaja comercial y que las copias lleven este aviso y la cita completa en la
primera página. . Deben respetarse los derechos de autor de los componentes de este trabajo
que no pertenezcan a ACM. Se permite hacer resúmenes con crédito. Copiar de otro modo, o
volver a publicar, publicar en servidores o redistribuir a listas, requiere un permiso específico
previo y/o una tarifa. Solicitar permisos depermisos@acm.org . ECSA,Del 9 al 13 de
septiembre de 2019, París, Francia © 2019 Association for Computing Machinery. ACM ISBN
978-1-4503-7142-1/19/09…$15,00
nuño ferreira manuel pereira
Seguro i2S Sistemas de información F3M
Conocimiento, SA Braga, Portugal
Centro Oporto mapereira@f3m.pt
Guimarães Portugal
Portugal nuno.ferreira@i2s.pt
{helena,
Manuel Pereira, Ricardo J. Machado. 2019. Un método de diseño de arquitectura
lógica para arquitecturas de microservicios. Actas complementarias de ECSA 2019, 10
de septiembre de 2019, París, Francia. ACM. 7 páginas.
DOI: 10.1145/3344948.3344991.
1. INTRODUCCIÓN
La creciente adopción de la computación en la nube ha influido en el
proceso de desarrollo de software. El desarrollo de aplicaciones en la
nube ha llevado a adoptar arquitecturas de microservicios, en oposición
a las monolíticas, para aprovechar las características de la computación
en la nube como escalabilidad, disponibilidad o confiabilidad [1]. Esto se
debe a que incluso un pequeño cambio realizado en una parte de una
aplicación monolítica requiere la reconstrucción y el despliegue de toda
la aplicación. Además, escalar una aplicación monolítica requiere escalar
toda la aplicación en lugar de partes de ella, lo que requiere recursos
adicionales. Por otro lado, las arquitecturas de microservicios [2] (MSA)
son un estilo arquitectónico orientado a la modularización, donde la idea
es dividir la aplicación en servicios interconectados más pequeños,
ejecutándose como un proceso separado que se puede implementar,
escalar y probar de forma independiente [3]. Actualmente, MSA está
recibiendo una atención generalizada a medida que extiende la
'arquitectura de la etapa de diseño' a la implementación y las
operaciones como un estilo de desarrollo continuo [1].
El diseño de microservicios para una determinada capacidad o dominio
empresarial suele utilizar patrones como el diseño basado en dominios (DDD),
el principio de responsabilidad única (SRP) o la ley de Conway. Aseguran que
los microservicios están acotados para que puedan escalar de forma
independiente. Sin embargo, los proyectos a menudo tienen dificultades para
vincularlos correctamente, lo que da como resultado un conocimiento
insuficiente para las decisiones relacionadas con la partición de la base de
datos, el tamaño adecuado del microservicio, la comunicación entre servicios y
la mensajería, que no se abordan sistemáticamente en esos patrones. Al
aplicar un método de modelado en el proceso de diseño de un MSA, se pueden
prever problemas en contextos limitados para microservicios, a saber, el
comportamiento dentro del servicio, la separación de interfaces y modelos de
datos, y los requisitos de mensajería y comunicación entre servicios [2].
En consecuencia, este documento propone un enfoque para el diseño de
una arquitectura lógica orientada a microservicios (MSLA),es decir, una visión
lógica [4] sobre el comportamiento de los microservicios y las relaciones entre
microservicios. Este enfoque utiliza diagramas de casos de uso de UML para el
modelado de dominios, que luego se utilizan como entrada para diseñar un
MSLA utilizando un conjunto de decisiones basadas en reglas, utilizando una
adaptación delConjunto de reglas de cuatro pasos(4SRS) método [5]. Cada uno
de estos casos de uso de UML funcionalmente descompuestos da origen a uno
o más componentes, que luego compondrán los microservicios.
 FAACS, París, Francia
El método 4SRS asegura el alineamiento de la arquitectura diseñada
con los requerimientos del usuario obtenidos.
El propósito de este documento es presentar una
adaptación de este método para respaldar un diseño de
arquitectura adecuado que cumpla con los principios
fundamentales de la arquitectura de microservicios, el 4SRS-
MSLA. Problemas como la consistencia de los datos, la
seguridad, la comunicación, la implementación y otros
patrones [6]–[9] también se han abordado y se presentan en
este documento, aunque la discusión extensa sobre tales
patrones está fuera del alcance. Para fines de
representación, este enfoque adopta el lenguaje de
modelado de arquitectura orientado a servicios (SoaML).
Además, basado en la premisa de que una especificación
adecuada de los requisitos se beneficia de múltiples
perspectivas, el método adaptado incluye salidas para
diferentes diagramas SoaML, como participantes del
servicio, capacidades, arquitecturas del servicio e interfaces
del servicio.
Esta investigación se basa en un estudio de caso industrial, la
Plataforma de Gestión Integrada 4.0(IMP_4.0), diseñado en el contexto de
un proyecto financiado, donde un modelo de casos de uso UML con
respecto a los requisitos del software son la entrada para derivar el MSLA
del proyecto, utilizando el método 4SRS-MSLA.
La estructura de este documento es la siguiente: la Sección 2 describe
enfoques similares en la literatura, mientras que la Sección 3 presenta una
descripción general de los pasos y la justificación de 4SRS, y la Sección 4
describe el método 4SRS-MSLA adaptado y su salida utilizando diagramas
SoaML. Luego, la Sección 5 presenta el estudio de caso IMP_4.0 junto con los
artefactos modelados, la implementación de microservicios propuesta y la
discusión de los resultados asociados, mientras que la Sección 6 presenta las
conclusiones de este trabajo.
2. TRABAJO RELACIONADO
Aunque es una tendencia algo reciente, la adopción de arquitecturas de
microservicios ha surgido en la identificación de patrones, desde la migración
[16] hasta el desarrollo y la implementación de dichas arquitecturas [6]–[9],
que van desde el diseño de servicios, orquestación/coordinación,
implementación, distribución de datos, entre otros. El patrón de
'Descomposición' [6] se usa a menudo como punto de partida para diseñar
arquitecturas de microservicios, ya que pretende asegurar que el servicio dado
se refiera a un pequeño alcance del sistema. El alcance de un microservicio
puede relacionarse con las capacidades comerciales de la organización o con
un dominio comercial mediante la aplicación del enfoque de diseño basado en
el dominio (DDD) [17]. Nuestro enfoque también utiliza la lógica DDD para
estructurar los límites dentro del modelado de requisitos, que luego se
considera una entrada para el diseño de microservicios.
Además, el diseño de la arquitectura presenta muchos desafíos en lo que
respecta a la adopción de microservicios [10]. Por lo general, la implementación de
estas arquitecturas comienza con el desarrollo de servicios para un proceso comercial
dado [18], haciendo uso de patrones de microservicios simplificados [9]. En términos
de modelado de microservicios y su granularidad, los contextos acotados de DDD,
dentro de los requisitos modelados usando casos de uso, permiten definir pasos para
derivar un modelo de dominio para un microservicio [14]. Los casos de uso también
se consideran una entrada para definir correctamente la granularidad de los
microservicios en [8], es decir, en función de su descomposición funcional [19].
Además, la granularidad
N. Santos et al.
se gestiona utilizando modelos en [20]. Otros trabajos se centran en patrones de
diseño de bases de datos [21], [22] o relacionados con la implementación [23].
En general, el diseño continuo de MSA implica una adición,
modificación y eliminación iterativa de servicios incluso después de que
la implementación haya finalizado. Por esa razón, el arquitecto debe
tener un enfoque de apoyo para realizar un seguimiento de los cambios
en las necesidades comerciales de la MSLA. Los enfoques mencionados
permiten especificar y modelar un MSA pero no admiten la alineación y la
trazabilidad como lo hace el 4SRS-MSLA. En este documento, 4SRS-MSLA
contribuye a la arquitectura de microservicios y su granularidad, y
contribuye a definir modelos de datos y comunicaciones asociados.
3 ANTECEDENTES
3.1 Descripción general del 4SRS
El método 4SRS [5] utiliza la descomposición funcional de requisitos
(en casos de uso de UML) para derivar una arquitectura lógica compuesta
por componentes de UML que se remontan a cada funcionalidad
obtenida. El método (como su nombre lo indica) está organizado en
cuatro pasos, a saber: Paso 1, creación de componentes; Paso 2,
eliminación de componentes; Paso 3, empaquetado y agregación de
componentes; y Paso 4, asociación de componentes. La derivación de los
componentes sigue el patrón Modelo-Vista-Controlador (MVC).
Paso 1. Creación de Componentes
El primer paso se refiere a la creación de componentes, donde el método
4SRS asocia a cada componente, encontrado en análisis, una categoría dada:
interfaz (yo tecleo), donde la capa lógica se refiere principalmente a interfaces
con usuarios, software u otras entidades (por ejemplo, dispositivos, etc.); datos
(tipo d), donde la capa lógica se refiere principalmente a repositorios genéricos
(datos), que normalmente contienen el tipo de información que se almacenará
en una base de datos; y control (tipo c), donde la capa lógica se refiere
principalmente a un componente de control, donde se incluye la lógica de
negocio y el procesamiento programático.
Paso 2. Eliminación de Componentes
En el segundo paso, los componentes se someten a tareas de
eliminación según reglas predefinidas. En este momento, el arquitecto
del sistema decide cuál de los componentes (i-,d-, otipo c) se mantienen o
eliminan, teniendo en cuenta todo el sistema, analizando primero su
representación en el contexto de un caso de uso, y luego comparando su
redundancia dentro de todo el sistema. Además, cada componente
mantenido se nombra y describe textualmente en relación con su
comportamiento. Para obtener detalles descriptivos sobre estos
micropasos, consulte [5].
La descripción del componente debe abarcar la información
necesaria para pasar a la implementación, incluido cómo comprender su
propósito dentro de la solución global, así como también cómo
interactúa con las aplicaciones y servicios restantes.
Paso 3. Empaquetado de componentes
En este tercer paso, los restantes componentes (aquellos que se
mantuvieron después de ejecutar el paso 2), para los cuales existe la
ventaja de ser tratados en un proceso unificado, deben dar origen a
agregaciones o paquetes semánticamente consistentes.
Paso 4. Asociaciones de componentes
El paso final se refiere a las asociaciones entre componentes.
Estas asociaciones se definen siempre que sean originadas por la
 Un método de diseño de arquitectura lógica para microservicios FAACS, París, Francia

mismo caso de uso, que también se basan en los flujos entre los casos de Modelos de casos estructurados mediante la descomposición de
uso durante la fase de modelado de requisitos. funcionalidades en forma de árbol (Fig. 1). Las “ramas” del árbol son un
reflejo de los límites de los dominios y subdominios derivados de la
3.2 La variante 4SRS-SoaML aplicación del patrón DDD [25]. Si se trata de un proyecto brownfield, la

En [24], el método fue adaptado para soportar una derivación de una descomposición comienza analizando los procesos y su mapeo dentro de

arquitectura orientada a servicios (SOA), también usando casos de uso UML los componentes de los monolitos. La elicitación se refiere a los procesos

como entrada, pero esta vez con el objetivo de modelar la arquitectura usando que los sistemas heredados (o, en este caso, monolíticos) soportan

la notación SoaML. La génesis del método sigue siendo la misma, ya que utiliza actualmente. Los procesos son la base para identificar los dominios con

un conjunto de casos de uso, deriva un comportamiento del sistema para cada el patrón DDD. Al aplicar ingeniería inversa al modelado de requisitos, el

uno, define cuáles se mantienen y eliminan, los agrupa y define asociaciones. resultado es nuevamente un modelo de caso de uso UML.
Sistema
Sin embargo, en lugar de utilizar componentes UML, el comportamiento de los {UC1} uso {UC2} uso
ejemplo de caso ejemplo de caso 2
1...
casos de uso se deriva en participantes de SoaML, con naturalezas de {UC3} caso de uso
ejemplo 3

comportamiento específicas (i-,d-, otipo c). Luego, los pasos 3 (agrupación) y 4 {UC4} Uso
ejemplo de caso 4

(asociaciones) se utilizan para definir interfaces y canales de servicio.

{UC1} {UC3} {UC4}

{UC1.1}
ejemplo 1.1 {UC3.1}
...
{UC4.1} ...
Actorx actor Actor z
{UC1.2}

4 UN MÉTODO PARA DERIVAR UN MSLA

{UC3.2} ...
Acto
ox ejemplo 1.2
{UC4.2} ...
actor actor
{UC1.3} {UC3.3} ... Actorx
ejemplo 1.3 Actor z {UC4.3}
Actorx ...
{UC3.4} ...

Esta sección describe los pasos que componen el método 4SRS-MSLA

Encerrado Encerrado
{UC1.1} Encerrado
(Fig. 2), desde donde se especifica inicialmente cada componente UML. A {UC1.1.1} ... Contexto Contexto Contexto

continuación, se identifican estos componentes y se deriva su Actorx

{UC1.1.2} ...
actor

{UC1.1.3} ...

comportamiento en microservicios (Participantes del Servicio de SoaML),

así como los canales y contratos entre ellos.
Fig. 1. Inferir los contextos acotados del dominio y del subdominio

4.1 Modelado de requisitos Cada caso de uso se descompone funcionalmente en función de las

Cualquier proyecto de software se realiza en uno de estos contextos: ya tareas específicas que admite la solución actual. Además, este proceso de

sea en un proyecto greenfield,es decir, desde cero; o alternativamente, en un obtención de requisitos se puede utilizar para analizar las limitaciones actuales

proyecto brownfield,es decir, además de los sistemas heredados existentes. en el dominio comercial y, por lo tanto, las partes interesadas pueden obtener

Independientemente de si se diseña un sistema basado en MSA, greenfield o nuevos requisitos, que se agregan al modelo de caso de uso.

brownfield (mediante la descomposición de un monolito), es necesario La descomposición funcional se relaciona con la división de

identificar un conjunto de microservicios [2]. En consecuencia, el patrón funcionalidades en partes más pequeñas. Dentro de los casos de uso de UML,

'Descomposición por capacidad comercial' o 'Descomposición por esta técnica de requisitos se utiliza para permitir que una funcionalidad de

subdominio' [6], también conocido como DDD, es un enfoque común para software se divida en casos de uso refinados. Tal técnica permite proporcionar

diseñar arquitecturas de microservicios. detalles al describir un requisito dado. Esta organización en forma de árbol da

En esta etapa, los requisitos se modelan en diagramas de casos de como resultado una estructura para especificar detalles de nivel inferior en

uso UML, ya sea que el contexto sea greenfield o brownfield. El enfoque cada requisito, donde los requisitos de nivel inferior son una especialización de

utiliza estos diagramas como la salida final del proceso DDD, ya que son los requisitos de nivel superior. El analista de requisitos decide entonces

la entrada en cualquier ejecución de 4SRS. Si en un proyecto greenfield, cuándo puede terminar la descomposición. A menudo, la tendencia es realizar

los requisitos se obtienen con base en los procesos que MSA pretende andamios, donde los requisitos de bajo nivel terminan en operaciones de

apoyar, donde proponemos Use creación, lectura, actualización y eliminación (CRUD). Esto es simplemente
Participantes de SoaML

"Partícipe"
"Partícipe"

Componentes UML
Caso de uso de ULM s
Identificar EM
Participantes SoaML + Componentes UML

"Partícipe"
4SRS-MSLA
derivar EM
comportamiento

derivar EM
Participantes SoaML + Componentes UML
Canales y
Contratos "Partícipe"

Fig. 2. Especificación de microservicios usando 4SRS-MSLA

 FAACS, París, Francia N. Santos et al.

un ejemplo, ya que descomponer el objetivo de las operaciones CRUD es está destinado a identificar la necesidad de dichos canales,
una decisión que debe tomar el analista de requisitos. independientemente del Patrón de comunicación adoptado, es decir,
El objetivo de usar 4SRS-MSLA es tener una vista lógica del mensajería entre servicios o uso de middleware como API Gateways o bus
comportamiento interno y las comunicaciones de los microservicios, de de mensajes ligeros. El método proporciona pasos para identificar tales
modo que todos los requisitos funcionales obtenidos se cumplan en la asociaciones basadas en descripciones de casos de uso, así como de los
solución derivada. Los cuatro pasos del 4SRS-MSLA son los siguientes: propios componentes, durante la ejecución del paso 2. Este paso
Paso 1. Creación de Componentes permanece como en [5].
El primer paso se refiere a la creación de tres componentes, donde el Este paso tiene algunos comentarios ya que algunas asociaciones no
método 4SRS-MSLA asocia, para cada caso de uso, un componente de se pueden implementar en un canal de servicio. El hecho de que las
interfaz con usuarios o sistemas (yo tecleo), un componente para el asociaciones se definan en función de los casos de uso de origen, no debe
modelo de datos (tipo d), y un componente de lógica/control del dominio significar que se definen "todos para todos". Las asociaciones definen
de microservicios (tipo c). cómo se comporta internamente el servicio, pero también cómo se
Paso 2. Eliminación de Componentes comunican entre ellos (si los componentes forman parte de diferentes
En el segundo paso, los componentes se someten a tareas de microservicios). La figura 4 representa las asociaciones y reglas que debe
eliminación. En versiones anteriores del método, la identificación de seguir este paso dentro de cinco escenarios diferentes. Como se
redundancia a menudo incluye componentes que son funcionalmente mencionó en la Sección 3, las asociaciones se derivan si los componentes
similares pero con un uso diferente, lo que da como resultado la siempre se originan en el mismo caso de uso y también se basan en los
eliminación de componentes redundantes pero define una representación flujos entre los casos de uso. En el lado izquierdo de cada escenario, se
más amplia para el componente retenido. Esto ocurre a menudo dentroC- representan las asociaciones de componentes del mismo caso de uso y,
otipos i componentes Sin embargo, los principios de los microservicios en el lado derecho, las asociaciones de flujos de casos de uso.Escenario
sugieren que el microservicio tiene un solo propósito específico, por lo a):En el lado izquierdo, si se mantienen los tres componentes,yo tecleo
que se puede sugerir que un componente debe eliminarse solo si su debe asociarse contipo c, y tipo casociar contipo(s) d, asegurando un
propósito es exactamente el mismo que el del otro, y por lo tanto no adecuado flujo intraservicio. Escenarios a), b) y c):Las asociaciones con las
eliminar ninguno de ellos si su propósito es solo parecido ejemplificadas a la derecha, referentes a las comunicaciones entre
Paso 3. Empaquetado de componentes/identificación de microservicios servicios, deben asignarse siempre entretipos c.Escenario d):Notipos cse
El tercer paso consiste en agrupar un conjunto de componentes en mantuvieron, por lo que las asociaciones relacionadas con el flujo de
paquetes, que luego componen microservicios de nivel superior (Fig. 3). En casos de uso están entrei-o tipos d.Escenario e):solamentetipos dse
4SRS-MSLA, el empaquetado se basa en el modelo de casos de uso obtenido en mantuvieron, así, a pesar de ser un escenario insólito, se define la
el refinamiento de primer nivel. Los componentes, independientemente de su asociación. En este caso, se requiere un análisis por parte del arquitecto,
categoría (tipo i, d o c), se asignan a un paquete (microservicio de nivel superior) ya quetipos dgeneralmente responde (en acciones CRUD hacia los datos) a
según el proceso con el que se relacionan o según el caso de uso sin hoja (que la llamada de otro componente.
incluye la hoja ) derivado originalmente de. Tal empaque asegura que se siga el a) b) C)
Mismo caso de uso Flujos de casos de uso
patrón DDD.
X
Mismo caso de uso Flujos de casos de uso Mismo caso de uso Flujos de casos de uso

"interfaz" "interfaz"
"interfaz"

X
{C1.1.i} …. {C1.3.i} ….
Adicionalmente, es común queyo tecleoLos componentes que se relacionan {C1.3.i} ….

"control" "control"

con las acciones de la interfaz de usuario (UI) se agrupan en uno o más yo

"control" "control" "control" "control"
{C1.1.c} …. {C1.3.c} ….
{C1.1.c} …. {C1.3.c} …. {C1.1.c} …. {C1.3.c} ….

tecleocomponentes Esto ocurre porque estos componentes suelen ser parte de

"datos"
{C1.1.d} …. X "datos"
{C1.3.d} ….
"datos"
{C1.1.d} …. X "datos"
{C1.3.d} ….
"datos"
{C1.1.d} …. X "datos"
{C1.3.d} ….

una aplicación web en lugar de un servicio consumido dado.Tipos Dse incluyen

en el paquete del microservicio de nivel superior con el que se relacionan. Esta d) mi)
Mismo caso de uso Flujos de casos de uso Mismo caso de uso Flujos de casos de uso

decisión tiene como resultado la inclusióntipo d componentes que son "interfaz"

{C1.1.c} ….

responsables del acceso a los datos relacionados dentro del microservicio,

X
"datos" "datos"
"datos" "datos"
{C1.1.d} …. {C1.3.d} ….
{C1.1.d} …. {C1.3.d} ….

asegurando su independencia y SRP.

Sistema Fig. 4. Definición de asociaciones entre componentes

{UC1} uso {UC2} uso
ejemplo de caso ejemplo de caso 2

1...

{UC3} uso
ejemplo de caso 3
A continuación, se derivan directamente los microservicios, sus
{UC4}

componentes y respectivas asociaciones. Este modelo se utiliza como

administrar la nube

seguridad y
privacidad

Paquete {P4}
del caso de uso 4
entrada para definir los propios microservicios, su comportamiento y
Paquete {P3}
{UC1} Paquete {P1}
del caso de uso 3
{UC3} {UC4} comunicación entre servicios. En cuanto a la definición de microservicios,
{UC1.1} del caso de uso 1

las representaciones de MSLA colapsan los componentes y solo presentan

ejemplo 1.1 {UC3.1}
...
{UC4.1} ...
actor Actor z
Actorx
{UC1.2}
{UC3.2} ...
Actorx ejemplo 1.2

los microservicios en sí. Los componentes dentro del microservicio

actor {UC4.2} ... actor

{UC1.3} ejemplo {UC3.3} ... Actorx

1.3 Actor z {UC4.3}

determinan su comportamiento, tanto en términos de interfaz, lógica y

Actorx ...

{UC3.4} ...

{UC1.1} {P1.1} Paquete

del caso de uso 1.1
modelo de datos.
Finalmente, para derivar la comunicación entre servicios, solo se
{UC1.1.1} ...

{UC1.1.2} ...
Actorx actor

{UC1.1.3} ... mantienen las asociaciones entre componentes de diferentes

microservicios y se ocultan las que están dentro del mismo microservicio.
Fig. 3. Definición de paquetes basados en casos de uso no hoja
Las asociaciones existentes entre cada microservicio se generalizan en
una sola, que ahora engloba el conjunto de flujos de información de las
Paso 4. Asociaciones de Microservicios
asociaciones anteriores.P.ej, si entre los microservicios A y B existen 5
Luego, las asociaciones entre componentes se generalizan para
asociaciones entre componentes, entonces solo 1 asociación que abarca
representar las asociaciones entre microservicios. En un contexto de
los 5 se representa "gráficamente" entre los microservicios referidos. Cada
microservicios, estas asociaciones se relacionan con canales de servicio que
asociación permite que los microservicios puedan consumir o
existen para permitir la comunicación entre microservicios para respaldar un
proporcionar a otros
proceso comercial o flujo de información determinado. Esta vista
 Un método de diseño de arquitectura lógica para microservicios
microservicios. En este punto, la asociación es independiente de cualquier
enfoque de interfaz (p.ej, RESTfull u otro).
Por lo tanto, el MSLA modelado a partir de la ejecución del método 4SRS-
MSLA en los casos de uso iniciales de UML está de acuerdo con los principios de
los microservicios, a saber:
Componentización vía Servicios:El 4SRS-MSLA permite
especificar funcionalidades a nivel de componente, que están más
expuestas (por ejemplo, una API) bajo sus microservicios;
Organizado en torno a las capacidades comerciales:Las capacidades
comerciales para MSA se reflejan en el modelo de casos de uso de UML;
Productos no Proyectos:El modelado de requisitos para el producto
de software permite derivar microservicios de tamaño pequeño y baja
complejidad utilizando el 4SRS-MSLA, que en consecuencia se actualizan y
mantienen fácilmente;
Puntos finales inteligentes y canalizaciones tontas:Las asociaciones
(Paso 4 de 4SRS-MSLA) proporcionan las relaciones requeridas (proveedor o
consumidor) entre los microservicios;
Gobernanza descentralizada:El enfoque propuesto es independiente de la
tecnología, ya que los modelos lógicos se abstraen de la tecnología y, por lo
tanto, los microservicios diseñados pueden implementarse, cada uno en
cualquier idioma a elección;
Gestión de datos descentralizada:La descripción de los Participantes
incluye proporcionar las propiedades para cada gestión de datos;
Automatización de Infraestructura:La prueba de aceptación del
microservicio usa las especificaciones de los componentes (Paso 2 de
4SRS-MSLA) y la prueba de integración usa las asociaciones definidas
(Paso 4 de 4SRS-MSLA);
Diseño para el fracaso:La razón fundamental para diseñar
microservicios requiere la seguridad de que cada uno sea autónomo. Por
lo tanto, al no incluir dependencias, una falla dentro de un microservicio
dado es una falla dentro de una parte y no una falla de toda la aplicación.
Diseño evolutivo:El proceso propuesto permite que, cada vez que se
requieran nuevos microservicios, se eliciten y modelen nuevas
funcionalidades en casos de uso, y finalmente se incluyan de forma
incremental en el método 4SRS-MSLA para el diseño evolutivo.
4.3 Representación de MSLA en SoaML
La especificación SoaML define un conjunto de diagramas con
comportamiento interrelacionado y propósito complementario, que se
describen a continuación.Participantesse utilizan para definir los proveedores
de servicios y los consumidores en un sistema, mientras queArquitecturas de
serviciosdescribir cómo los participantes trabajan juntos proporcionando y
utilizando servicios expresados comoContratos de servicio. Por lo tanto, se
utilizan para describir patrones de interacción entre entidades de servicio. Por
otro lado, CapacidadesIdentificar o especificar un conjunto cohesivo de
funciones o recursos que podría ofrecer un servicio proporcionado por uno o
más participantes, mientras queInterfaces de serviciose utilizan para describir
las operaciones proporcionadas y requeridas para completar la funcionalidad
de un servicio. Es más,Datos de serviciose utilizan para describir mensajes de
servicio y archivos adjuntos de mensajes.
En este documento, el MSLA está compuesto por participantes del servicio
para cada microservicio (como en [17]), capacidades que reflejan las
funcionalidades de los microservicios en función de los componentes que lo
componen y las asociaciones entre ellos. Las asociaciones, en SoaML, se pueden
modelar a través de interfaces de servicio, canales de servicio, contratos de
servicio y diagramas de arquitectura de servicio. Sin embargo, no se discuten
más en este documento.
En [24], los detalles del participante incluyen propiedades como una breve
descripción (propósito), solicitudes, servicios y propiedades/recursos. El
enfoque actual propone mantener una descripción de propósito general para
microservicios, pero también la inclusión de verbos HTTP bajo los cuales se
llama a ese componente (utilizado para definir «solicitud»
FAACS, París, Francia
puertos). Además, se requiere la invocación de verbos HTTP para consumir servicios
que son necesarios para cumplir su propósito (utilizados para definir puertos de
«servicio»), y propiedades que componen la base de datos dedicada (entrada para
Datos de Servicio, pero fuera del alcance de este documento). ).
La figura 5 muestra un ejemplo de modelado de microservicios. Las
invocaciones requeridas para el Participante (Fig. 5a) fueron identificadas con
base en la descripción del caso de uso inicial, donde previamente se
describieron las interacciones con otros casos de uso. Además, las mismas
interacciones permitieron identificar la necesidad de métodos que llamen a
esos servicios dentro de las Capacidades (Fig. 5b), así como un método
relacionado con el cálculo del stock, que es el objetivo de este microservicio, por
lo tanto, relacionándolo con el servicio expuesto ( por ejemplo, en una API).
"Partícipe"
Microservicio 1
Puerto x
puerto z
"Solicitud" "Capacidad"
«de la asociación con el uso
Microservicio 1
caso 2»
GetEjemplo1(): int
"Servicio"
Puerto y
«de la asociación con el uso GetEjemplo2(): int
caso 2» PonerEjemplo3(): int
"Solicitud"
«de la asociación con el uso
caso 4»
(b)
(a)
Fig. 5. (a) Participante (es decir, un Microservicio) con puertos e interfaces; (b)
Capacidades dentro del Participante (es decir, el Microservicio)
5 DEMOSTRACIÓN: EL PROYECTO IMP_4.0
5.1 El escenario del proyecto
El surgimiento del paradigma de la industria 4.0 impulsó la migración
de los sistemas monolíticos actuales a las ofertas de computación en la
nube. La plataforma IMP_4.0 será desarrollada y soportada por una MSA,
que integrará los servicios de forma genérica y estandarizada, poniéndola
posteriormente a disposición del mercado en un modelo de Software-as-a-
Service (SaaS). Esta plataforma permite una casa de software,F3M
– Sistemas de Información, SA,optimizar el proceso de desarrollo para entregar
soluciones a sus clientes con herramientas para apoyar todos sus procesos de
toma de decisiones. El proyecto IMP_4.0 se trata de un sistema ERP para el
dominio de la producción textil, donde el enfoque es apoyar los procesos de
molienda, tejido y confección, al proporcionar un conjunto de módulos
reutilizables e integrados.
La investigación se lleva a cabo dentro del equipo de software de F3M.
El equipo estaba compuesto por un Product Manager, que poseía la visión
del negocio, un equipo de cuatro arquitectos de software y cuatro
analistas, que modelaron los requisitos y ejecutaron el método 4SRS-
MSLA, y dos equipos de desarrollo, responsables de implementar el MSA
resultante. Los arquitectos y analistas también realizaron las mediciones
dentro de esta investigación.
5.2 Los artefactos modelados
El proceso de descomposición comenzó con un esfuerzo completo de
elicitación y modelado de requisitos. Toda la gestión de productos de
software, desde la identificación de las necesidades del mercado, la
identificación de activos y la gestión de lanzamientos, se basó en una
ingeniería de dominio inicial, donde se pretendía caracterizar los procesos
de los dominios de hilados, textiles y prendas de vestir, así como sus
similitudes y variabilidades de dominio. .
Los requisitos de software para los procesos identificados dieron como
resultado una especificación de casos de uso de UML. El modelo de Casos de
Uso estuvo compuesto por los siguientes casos de uso, relacionados con los
módulos del ERP (Fig. 6a), a saber, Acciones; Ventas; compras; Producción;
Planificación; subcontratación; Control de calidad; Lista de empaque; Finanzas; y
Gestión de Partes Interesadas. También se incluyeron casos de uso adicionales
relacionados con la integración con infraestructuras en la nube. cada uso
 FAACS, París, Francia N. Santos et al.

case se refinó en casos de uso descompuestos funcionales, lo que resultó en 86 los dominios se validaron de forma iterativa y, cada vez que se
casos de uso de bajo nivel (también llamados hoja), es decir, los que no se implementó un dominio, también se validó su comunicación para que los
podían dividir más. El proceso de descomposición finalizó cuando los casos de procesos comerciales se respaldaran de manera incremental.

uso de hoja representaron operaciones CRUD básicas. La descomposición

funcional muestra que los 10 contextos acotados se estructuraron dentro de las
5.4 Discusión
“ramas” del árbol. Para fines representativos, la Fig. 6b muestra la El método 4SRS-MSLA propuesto se utilizó en un entorno de proyecto en el

descomposición funcional relacionada con las acciones. que un equipo de software de F3M tenía como objetivo dividir una aplicación
monolítica existente en microservicios, pero luchaba por definir una estrategia
{UC1} Acciones adecuada. Aunque la aplicación estaba estructurada en módulos, sus procesos
{UC1.1} Mando

eran profundamente dependientes y se compartían modelos de datos entre los

{UC1.2} Mando
Información sobre Información sobre
Stock de Mercancías
Existencias en Almacén

{UC1.3}
módulos.
{UC1.5} Mando

La aplicación del método presentado tuvo como principales

Analizar acciones Gerente de ventas
Stock mínimo
Estado
jefe de almacen

aportes al equipo de F3M en:

{UC1.6}
analizar
{UC1.8} Registro
Histórico
Entradas / Salidas

{UC1.4}
Stock de reserva
Identificación de los dominios necesariospara descomponer la aplicación
{UC1.7} Recuento
«se extiende»

monolítica de F3M existente en un conjunto de microservicios;

Inventario

{UC1.10} Enlace {UC1.9}

Entradas / Salidas
Documento
Llevar a cabo

Cosecha
Depósito
Operador
Proporcionar un soporte de modelado para especificar lacomportamiento
dentro del servicio, después de identificar requeridoi-,C-ytipo dcomponentes
Fig. 6. (a) Modelo de caso de uso; y (b) el refinamiento del caso de uso de {UC1} Acciones necesarios para los microservicios;
Representar las separaciones requeridas con elinterfaces de aplicaciones
La siguiente fase se relacionó con la ejecución del método 4SRS. Los weby elmodelos de datos, al envasari-ytipo dcomponentes; y
86 casos de uso de hoja se utilizaron como entrada, lo que permitió identificandocomunicación entre serviciosy mensajería que requiere
derivar 140 componentes después de crear (Paso 1) y eliminar/mantener un microservicio para realizar correctamente su misión.
los componentes (Paso 2). A continuación, el empaquetado de Además, también vale la pena mencionar algunas ventajas
componentes (Paso 3) formalizó la identificación de los microservicios adicionales del método informado durante el proyecto IMP_4.0.
dentro de la arquitectura, así como su interfaz entre las aplicaciones web Aunque no se incluyeron explícitamente en el método, los modelos
(módulos ERP) y el MSA. Basado en el primer nivel de casos de uso, el fueron el origen de algunas discusiones sobre el desarrollo y la
MSLA está compuesto por los siguientes microservicios:Cepo; Ventas; implementación de MSA, como sigue.
compras;Órdenes de producción;Listas de materiales;Planificación; Arquitectura de la base de datos: las decisiones sobretipo d componentes

Subcontratación;Control de calidad;Lista de empaque;Revisando cuentas; después de realizar los pasos 3 y 4 de 4SRS-MSLA originaron discusiones sobre
si el servicio tenía una base de datos compartida con otro servicio en lugar de
Bancario; yGestión de los interesados. El paso 4 permitió identificar los
uno dedicado. Decidir qué paquete en el Paso 3 para un determinadotipo d, o
flujos requeridos entre los microservicios derivados. La identificación
utilice asociaciones relacionadas con el flujo de casos para tipos d, fueron las
general de microservicios y la comunicación entre servicios, al colapsar los
principales razones para iniciar esas discusiones.
componentes, se muestra en la Fig. 8, mientras queError! Source du
Consultas (Composición API y CQRS): Las dependencias entre
renvoi introducible.muestra el comportamiento del componente
microservicios de las asociaciones en el Paso 4 y representadas en Canales
específico para el microservicio Stocks.
de servicio o puertos de servicio se ingresaron para discusiones de
patrones como Composición de API, Segregación de responsabilidad de
consulta de comando (CQRS) y Saga.
Pruebas:La prueba de componentes se habilita validando el
comportamiento del microservicio como se describe en los componentes que lo
componen. La prueba del contrato de integración de servicios se habilita
validando los escenarios en los que los servicios invocan a otros servicios. Estas
invocaciones se representan como ServiceChannels mediante las asociaciones
descritas en el Paso 4. Esta prueba es valiosa para una canalización de
integración/implementación continua (CI/CD) adecuada.
Estilo de comunicación:La MSLA solo define la necesidad de existencia de
Fig. 7. El microservicio Stocks un flujo entre microservicios. Sin embargo, cualquier decisión de diseño sobre
la adopción de un patrón dado (puertas de enlace API, invocación de
5.3 Implementación de microservicios procedimientos remotos, mensajería o un protocolo específico de dominio, etc.)
De los 86 casos de uso iniciales, la aplicación del 4SRS-MSLA puede incluirse directamente en la especificación de componentes.
permitió especificar 140 componentes, de donde el proyecto IMP_4.0 Sin embargo, el método todavía tiene sus limitaciones. En términos de partición
MSLA derivó a 12 microservicios. Sería muy difícil diseñar una de base de datos, el modelo derivado todavía estaba lejos de las especificaciones
arquitectura compuesta con tanto detalle en los componentes sin el requeridas para implementar bases de datos relacionales y no relacionales
apoyo de un método arquitectónico como el 4SRS. distribuidas, principalmente en cuanto a problemas de consistencia.
En cuanto a la implementación de MSLA, al momento de esta investigación,
dos equipos paralelos ya habían desarrollado 6 microservicios, de los 12 6 CONCLUSIONES Y TRABAJO FUTURO
resultantes del 4SRS-MSLA, y sus correspondientes aplicaciones web. Es decir,
Este artículo propone un enfoque basado en modelos para diseñar
los microservicios desplegados sonCepo({P1}), compras({P2}),Ventas({P3});
una vista lógica de un MSA, llamado 4SRS-MSLA. El enfoque se basa en
Órdenes de producción({P4.1}),Listas de materiales({P4.2}), yRevisando cuentas(
modelar un dominio comercial en casos de uso UML, derivando así un
{P9.1}). A medida que los equipos desarrollaban cada contexto delimitado
diagrama de componentes UML para el dominio y finalmente agrupando
(microservicio y aplicación web),
los componentes en microservicios. El 4SRS-MSLA se llevó a cabo en
 Un método de diseño de arquitectura lógica para microservicios
Fig. 8. Resumen de IMP_4.0 MSLA (con componentes colapsados)
un proyecto de investigación, donde un equipo de F3M tenía como objetivo descomponer una
solución monolítica en un conjunto de microservicios
La trazabilidad asociada al método 4SRS-MSLA asegura un alineamiento
entre el modelo de Caso de Uso inicial y la solución propuesta de la arquitectura
derivada. Además, las salidas del método sirven como entradas para varios
diagramas SoaML, que son complementarios para una especificación adecuada
del comportamiento y las asociaciones de los microservicios, como los
participantes del servicio y los contratos. Los pasos de 4SRS-MSLA se adaptaron
para cumplir con características de microservicios ampliamente conocidas. Los
diagramas restantes, como la interfaz de servicio, las capacidades, los datos de
servicio, la arquitectura de servicio y los contratos de servicio, entre otros, se
discutirán en trabajos futuros.
Además, la creciente adopción de microservicios en la industria llevó a
definir otros patrones adoptados cuando los MSA comienzan a escalar, como
los relacionados con comunicaciones, arquitecturas de bases de datos,
consistencia de datos, seguridad, implementación, entre muchos otros. Si bien
estos tienen implicaciones directas en la derivación de la arquitectura lógica y,
por lo tanto, en relación con el presente trabajo, el trabajo futuro abordará los
detalles de la definición de base de datos por servicio de 4SRS-MSLA.
Referencias
[1] C. Pahl y P. Jamshidi, "Microservicios: un estudio de mapeo sistemático".6to Int. Conf.
Computación en la nube. serv. ciencia, vol. 1, págs. 137–146, 2016.
[2] S. Newman,Creación de microservicios: diseño de sistemas detallados. O'Reilly
Media, Inc., 2015.
[3] J. Thönes, “Microservicios,”Software IEEE, vol. 32, núm. 1, págs. 116 y 116, 2015.
[4] P. Kruchten, "El modelo de arquitectura de vista 4+1",Software IEEE, vol. 12, núm. 6, págs.
42 a 50, 1995.
[5] RJ Machado, JM Fernandes, P. Monteiro y H. Rodrigues, “Transformación de modelos UML
para arquitecturas de software orientadas a servicios”,Actas de la 12.ª Conferencia y
Talleres Internacionales IEEE sobre Ingeniería de Sistemas Basados en Computadoras.
IEEE Computer Society, págs. 173–182, 2005.
[6] C.Richardson,Patrones de microservicio, 1ª ed. Manning, 2018.
[7] L. Krause,Microservicios: patrones y aplicaciones: diseño de servicios detallados mediante
la aplicación de patrones. microserviciosbook.io, 2014.
[8] D. Namiot y M. Sneps-Sneppe, “Sobre la arquitectura de microservicios”,En t. J. Abierta Inf.
Tecnología, vol. 2, núm. 9, págs. 24 a 27, 2014.
FAACS, París, Francia
[9] D. Taibi, V. Lenarduzzi y C. Pahl, "Patrones arquitectónicos para microservicios: un estudio de mapeo
sistemático", enConferencia internacional sobre ciencia de servicios y computación en la nube,
CLOSER, 2018.
[10] P. Di Francesco, I. Malavolta y P. Lago, "Investigación sobre arquitectura de
microservicios: tendencias, enfoque y potencial para la adopción industrial", en
Conferencia internacional IEEE sobre arquitectura de software (ICSA), 2017, págs. 21–30.
[11] P. Di Francesco, “Arquitectura de microservicios”, enConferencia internacional IEEE sobre
talleres de arquitectura de software: procedimientos secundarios, 2017.
[12] F. Rademacher, S. Sachweh y A. Zündorf, "Análisis de enfoques de modelado orientado a
servicios para el desarrollo de arquitectura de microservicios basado en modelos
específicos de puntos de vista"arXiv Prepr. arXiv1804.09946., 2018.
[13] N. Alshuqayran, N. Ali y R. Evans, "Un estudio de mapeo sistemático en la
arquitectura de microservicios"serv. computar, 2016.
[14] R. Kharbuja, "Diseño de una plataforma empresarial mediante microservicios", Technische
Universität München, 2016.
[15] F. Rademacher, J. Sorgalla y S. Sachweh, "Desafíos del diseño de microservicios basados
en dominios: una perspectiva basada en modelos"Software IEEE, vol. 35, núm. 3, págs.
36–43, mayo de 2018.
[16] A. Balalaie, A. Heydarnoori y P. Jamshidi, "Migrating to Cloud-Native Architectures
Using Microservices: An Experience Report", enAvances en Computación
Orientada a Servicios y en la Nube. Comunicaciones en Informática y Ciencias de
la Información, vol 567, 2015, págs. 201–215.
[17] E. Evans,Diseño basado en dominios: abordando la complejidad en el corazón del
software. Addison-Wesley, 2004.
[18] V. Lenarduzzi y D. Taibi, "Microservicios, arquitectura continua e interés de la
deuda técnica: un estudio empírico", en44ª Conferencia Euromicro sobre
Ingeniería de Software y Aplicaciones Avanzadas (SEAA),2018.
[19] S. Tyszberowicz, R. Heinrich, B. Liu y Z. Liu, "Identificación de microservicios
mediante descomposición funcional", Springer, Cham, 2018, págs. 50–65.
[20] S. Hassan, N. Ali y R. Bahsoon, "Ambientes de microservicios: un enfoque de
metamodelado arquitectónico para la granularidad de microservicios", enConferencia
internacional IEEE sobre arquitectura de software (ICSA), 2017, págs. 1 a 10.
[21] A. Furda, C. Fidge, O. Zimmermann, W. Kelly y A. Barros, "Migración del código fuente
heredado de la empresa a los microservicios: sobre multiusuario, estado y consistencia
de datos"Software IEEE, vol. 35, núm. 3, págs. 63 y 72, mayo de 2018.
[22] A. Messina, R. Rizzo, P. Storniolo, M. Tripiciano y A. Urso, “The Database-isthe-Service
Pattern for Microservice Architectures”, enConferencia internacional sobre tecnología de
la información en bioinformática y médica, 2016, págs. 223–233.
[23] L. Chen, "Microservicios: arquitectura para entrega continua y DevOps", en
Conferencia internacional IEEE sobre arquitectura de software (ICSA), 2018.
[24] CE Salgado, J. Teixeira, N. Santos, RJ Machado y RSP Maciel, “A SoaML Approach for
Derivation of a Process-Oriented Logical Architecture from Use Cases,”Explorar
serv. ciencia, págs. 80 a 94, 2015.
[25] N. Santos, J. Pereira, N. Ferreira y RJ Machado, “Modeling in Agile Software Development:
Decomposing Use Cases Towards Logical Architecture Design,” en Mejora del proceso de
software centrado en el producto, 2018, págs. 396–408.