Analise do Processo de Tomada de Decisao para Adocao daArquitetura de Microsservicos, Baseado em Requisitos da

Norma ISO-25010 e do S-Cube

Douglas Soares da Cunha1, Willer Hiago de Souza Santos1

1Bacharelado em Engenharia de SoftwareInstituto de Ciencias Exatas e Informatica – PUC Minas

Ed. Fernanda. Rua Claudio Manoel, 1.162, Funcionarios, Belo Horizonte – MG – Brasil

{dcunha,willer.souza}@sga.pucminas.br

Abstract. The use of microservices architetural style in the development of dis-tributed applications has increased in the last years, basically due to its successin big enterprises like Netflix and Amazon. However, for the adoption of suchstyle it is necessary that the project teams evaluate the characteristics of eachapplication and the applicability of this style, considering that it is not possibleto adopt it in a unorganized, diffuse way. In this paper we tried to identify thecriteria utilized to adopt microservices, based on the pattern ISO-25010 and theS-Cube model. We also tried to evaluate the importance of these criteria, and itsinfluence on architectural decision process and the relevance of each criterionin the context.

Resumo. A utilizacao do estilo arquitetural orientado a microsservicos para odesenvolvimento de aplicacoes distribuıdas tem crescido nos ultimos anos, como sucesso de sua implantacao em grandes organizacoes, tais como Netflix eAmazon. No entanto, ao optar por sua utilizacao e necessario que as equipes deprojeto avaliem as caracterısticas de cada aplicacao e sua aderencia a este es-tilo, uma vez que utiliza-lo de maneira profusa e desorganizada nao e adequado.Neste estudo buscou-se identificar, baseado na norma ISO-25010 e no modeloS-Cube, os criterios utilizados para adocao da arquitetura de microsservicose sua importancia, bem como a influencia do processo de decisao arquiteturalsobre a relevancia desses criterios.

Bacharelado em Engenharia de Software - PUC MinasTrabalho de Conclusao de Curso (TCC)

Orientador de conteudo (TCC I): Laerte Xavier - laertexavier@gmail.comOrientador academico (TCC I): Lesandro Ponciano - lesandrop@pucminas.brOrientador do TCC II: Pedro Alves - pedroalves@pucminas.br

Belo Horizonte, 28 de abril de 2021.

1. IntroducaoO aumento da complexidade dos sistemas atuais, dos quais muitos sao aplicacoes dis-tribuıdas, trouxe consigo um novo desafio: a escolha da arquitetura que melhor atenda

aos requisitos do software a ser desenvolvido. A arquitetura de software pode ser de-finida como as decisoes de design que levam a uma solucao e o projeto da mesma[Jansen and Bosch 2005]. O estilo arquitetural que tem ganhado cada vez mais espaco naindustria e o de microsservicos [Thones 2015], com empresas de renome como Netflix eAmazon demonstrando sua eficiencia [Fowler and Lewis 2014]. Esta arquitetura baseia-se em tecnicas de desenvolvimento de aplicacoes de software que herdam princıpios econceitos da Arquitetura Orientada a Servicos (SOA, do ingles Software Oriented Ar-chiteture), permitindo a estruturacao de uma aplicacao como uma colecao de servicospequenos e fracamente acoplados [De Lauretis 2019]. Assim, elas se destacam pela altafacilidade de manutencao, escalabilidade e modularizacao, sendo uma abordagem reco-mendada para aplicacoes distribuıdas [Costa et al. 2019].

Apesar dos microsservicos terem ganhado destaque no desenvolvimento de soft-ware por apresentarem qualidades como manutenibilidade e escalabilidade, nao foramencontrados, pelos autores deste trabalho, estudos que apontem e classifiquem todas ascaracterısticas que sao consideradas por times de projeto de software para optarem porsua adocao. Nesse contexto, o problema tratado neste artigo e a falta de clareza sobrequais sao os reais criterios utilizados por arquitetos e equipes de projeto de software paraa escolha da arquitetura de microsservicos.

A escolha da arquitetura correta e crucial para o sucesso do design desoftware, uma vez que uma escolha equivocada pode trazer resultados desastrosos[Garlan and Shaw 1993]. A arquitetura baseada em microsservicos nao pode ser con-siderada uma bala de prata [Brooks and Kugler 1987], principalmente pelo aumento ine-rente de complexidade destas solucoes [Bucchiarone et al. 2019]. Portanto, identificaresses criterios para sua adocao e analisa-los pode auxiliar na compreensao de quais pon-tos os arquitetos consideram mais relevantes. Com isso, pode-se ter um ranqueamentodesses criterios, visando auxiliar nas decisoes acerca da adocao de arquiteturas baseadasem microsservicos. Tambem torna possıvel obter uma visao geral de como sao feitas astomadas de decisoes dos arquitetos no mercado, dentro do escopo avaliado.

O objetivo principal deste trabalho consiste em analisar os criterios que levam umaequipe de projeto de software a decidir por utilizar a arquitetura de microsservicos. Paraalcancar este objetivo foram propostos os seguintes objetivos especıficos: i) identificaros criterios que sao levados em consideracao para a tomada de decisao; ii) avaliar a re-levancia de cada um desses criterios; iii) identificar, com base em metodos estatısticos, seos processos utilizados para a escolha arquitetural influenciam na relevancia dos criteriose em que medida isto ocorre.

O resultado esperado deste estudo e a identificacao e analise dos criterios chave,como requisitos nao funcionais e atributos de qualidade, considerados para a escolhada arquitetura baseada em microsservicos. Tambem busca-se analisar se o processo detomada de decisao arquitetural pode influenciar na relevancia dos criterios definidos.Espera-se que os resultados obtidos auxiliem os desenvolvedores e arquitetos de softwarea terem maior assertividade e seguranca nas suas decisoes sobre a escolha da arquiteturade microsservicos com base nos criterios levantados e na sua relevancia.

Este trabalho esta dividido em seis secoes. A Secao 2 apresenta o referencialteorico, descrevendo o estado da arte sobre microsservicos e os conceitos relacionados a

tomada de decisao arquitetural. A Secao 3 explora os principais trabalhos relacionados.A Secao 4 descreve a metodologia proposta neste estudo. A Secao 5 apresenta e discuteos resultados obtidos. E por fim, na secao 6, as consideracoes finais e direcoes futuras doestudo.

2. Referencial TeoricoNesta secao sao apresentadas as tres principais bases teoricas abordadas pelo presente es-tudo, a saber: arquitetura de microsservicos, requisitos arquiteturais e processo de tomadade decisao arquitetural. Na Secao 2.1 apresenta-se a arquitetura de microsservicos e suascaracterısticas. A Secao 2.2 aborda os criterios para escolha da arquitetura que sera uti-lizada no desenvolvimento de software. Por fim, a Secao 2.3 trata o processo de decisaoarquitetural.

2.1. Arquitetura de Microsservicos

Microsservicos sao pequenos servicos que operam de forma independente, sendo fra-camente acoplados e tendo como ideias principais a alta modularidade, escalabilidade,resiliencia e reutilizacao [Petrasch 2017]. O estilo arquitetural de microsservicos herdaprincıpios e conceitos da arquitetura SOA (Software Oriented Architeture), que por suavez, e uma arquitetura que busca disponibilizar as funcionalidades do sistema em formade servicos, para facilitar seu compartilhamento e reutilizacao [De Lauretis 2019].

Na arquitetura de microsservicos, o sistema e subdividido em diversos peque-nos componentes de granularidade fina que operam de forma individual. Isso possibi-lita que cada servico siga um ciclo de desenvolvimento distinto dos demais, podendoser entregues de forma individual, reduzindo o tempo de entrega [Costa et al. 2019].A comunicacao entre microsservicos geralmente ocorre atraves de uma Interface deProgramacao De Aplicacao (API, do ingles Application Programming Interface), utili-zando o Protocolo de Transferencia de Hipertexto (HTTP, do ingles Hypertext TransferProtocol) [Fowler and Lewis 2014]. A Figura 1 apresenta um exemplo da arquitetura demicrosservicos. Observa-se que a aplicacao atraves de uma interface de usuario se co-munica com os microsservicos, que por sua vez, podem se comunicar com um banco dedados, com outros microsservicos ou com servicos externos.

Figura 1. Arquitetura de Microsservicos. Fonte: [RedHat 2021]

A utilizacao de microsservicos no desenvolvimento de software tem crescidogracas a sua facilidade de manutencao, escalabilidade, confiabilidade e disponibilidade[Khaleq and Ra 2019]. Outro fator que contribuiu para o crescimento da utilizacaode microsservicos foi a possibilidade de disponibiliza-los em conteineres na nuvem, oque torna a solucao ainda mais dinamica, distribuıda e escalavel [Khaleq and Ra 2019].Quando distribuıdos em conteineres na nuvem, microsservicos podem ser orquestradosou coreografados, de forma a aumentar ou diminuir o consumo de recursos individu-almente de acordo com a demanda, balanceando a carga de servicos entre os diferen-tes nos. Alem disso, caso algum servico falhe, os outros nao sao diretamente afetados[Candido et al. 2019].

2.2. Criterios para adocao da arquitetura de microsservicosOs criterios podem possuir diferentes caracterısticas de domınio, sendo eles de existencia,de propriedade ou executivo [Kruchten 2004a]. Criterio de existencia e um elemento quedeve estar presente no software, podendo ser descrito como elementos estruturais, taiscomo: apresentar uma camada de interface de usuario, ou a comunicacao entre classesutilizar o Metodo de Invocacao Remoto (RMI, do ingles Remote Method Invocation).Criterio de propriedade pode ser definido como o conjunto de caracterısticas ou diretrizesque o software deve seguir, como por exemplo, a nao utilizacao de componentes open-source. Por fim, os criterios de origem executiva sao aqueles que nao estao ligados aoselementos de design, mas ao ambiente de negocio que afeta o processo de desenvolvi-mento, por exemplo, o financiamento para execucao do projeto.

Ja sobre os atributos de qualidade de software, a norma ISO/IEC-25010:2011,define alguns requisitos nao funcionais importantes para um sistema. Ela foi criada em2011, em substituicao a norma ISO/IEC 9126, a qual foram adicionadas as caracterısticasprincipais seguranca e compatibilidade. A norma ISO/IEC-25010:2011 compreende oitocaracterısticas de qualidade, sendo elas: adequacao funcional, desempenho, compatibi-lidade, usabilidade, confiabilidade, seguranca, manutencao e portabilidade. Essas carac-terısticas, por sua vez, se dividem em subcaracterısticas, conforme apresentado na Tabela1, na Secao 3. A norma traz uma visao mais detalhada da qualidade de software, sobo ponto de vista da qualidade do produto. Existem tambem diversos modelos que defi-nem criterios arquiteturais relevantes, com destaque para o S-Cube, abordado no ultimoparagrafo da Secao 3 deste trabalho.

2.3. Processo de tomada de decisao arquiteturalO processo de escolha de uma arquitetura de software envolve a analise de varios criteriosrelacionados ao contexto da aplicacao, tais como: usabilidade, funcionalidade, perfor-mance, resiliencia e reuso, alem de fatores externos que influenciam diretamente naproducao de software, como poder economico da organizacao e restricoes de tecnolo-gia [Kruchten 2004b]. Dentre esses criterios percebe-se que a escalabilidade, a manute-nibilidade e a modularidade sao comumente associados a arquitetura de microsservicos[Costa et al. 2019].

Na engenharia de software existe uma ligacao entre os requisitos nao funcionais(NFR) e a arquitetura de software. A partir dessa conexao, a arquitetura de softwareevoluiu de uma representacao estrutural simples para um processo centrado na decisaoarquitetural [Kruchten et al. 2009]. Nessa perspectiva, os NFR podem servir como a base

para adocao de uma arquitetura, sendo o centro da decisao arquitetural e muitas vezesinfluenciando a equipe nas tomadas de decisoes [Ameller et al. 2013].

3. Trabalhos Relacionados

Nesta secao examina-se trabalhos de outros autores relacionados ao tema deste artigo.Alguns trabalhos contemplam a adocao da arquitetura de microsservicos para o desen-volvimento de software, enquanto outros comparam os criterios utilizados para escolheruma arquitetura de software e a relacao deles com microsservicos. Tambem sao apresen-tados trabalhos que mostram como o processo de tomada de decisao afeta na escolha daarquitetura.

Candido et al. (2019) destacam a migracao da arquitetura monolıtica para a ar-quitetura de microsservicos em um sistema denominado CAOS, visando maior escala-bilidade e maior facilidade de uso [Candido et al. 2019]. Apos a implantacao da novaarquitetura, foram realizados dois testes em razao de comparacao de desempenho e es-calabilidade entre o sistema monolıtico e o sistema de microsservicos. O primeiro testevisava comparar o desempenho dos sistemas desconsiderando a escalabilidade e obteveresultados semelhantes em ambos. O segundo teste teve o objetivo de comparar o tempode resposta considerando a escalabilidade. Os resultados mostraram que o sistema mo-nolito realmente possui limitacoes de escalabilidade e que a transicao para a arquiteturade microsservicos surtiu efeitos positivos nesse sentido. E possıvel perceber que foramidentificadas caracterısticas que levaram a migracao da arquitetura. Porem, nesse trabalhoo foco nao era analisar as caracterısticas encontradas, mas utiliza-las para escolher a novaarquitetura.

Farshidi et al. (2020) abordam o desafio com o qual arquitetos de software sedeparam durante a tarefa de selecionar um padrao arquitetural para o desenvolvimento deum sistema [Farshidi et al. 2020]. Isso ocorre devido ao fato de que todas as informacoesdesses padroes estao espalhadas em diferentes literaturas. Dado esse cenario, foi realizadauma revisao sistematica da literatura com o objetivo de prover um modelo de decisao ar-quitetural. Para a realizacao da revisao, foi utilizada uma combinacao de pesquisas quanti-tativas e qualitativas sobre os padroes existentes a fim de extrair seus efeitos nos atributosde qualidade de software. Como resultado da revisao sistematica da literatura, foi pro-vido um modelo de visao geral de 29 padroes arquiteturais e seus efeitos em 40 atributosde qualidade de software. Tambem foi relatada a aplicabilidade desses padroes e suaspossıveis combinacoes. O modelo foi validado por especialistas da area e concluiu-se queele facilita o processo de selecao e exclusao de padroes por arquitetos no desenvolvimentode um sistema. Esse estudo e relevante porque prove um modelo de decisao arquitetural,alem de abordar o processo de tomada de decisao arquitetural. Porem, diferente do pre-sente estudo, o trabalho de Farshidi et al. (2020) teve como foco trabalhar com diversasarquiteturas e nao apenas com microsservicos.

Em relacao ao processo de tomada de decisao, Muccini et al. (2018) realizaramum estudo sobre como os grupos de tomadas de decisao influenciam no estilo de arqui-tetura que sera escolhido [Muccini et al. 2018]. Os autores efetuaram uma pesquisa daspraticas adotadas por grupos de arquitetura na industria de software. Para tanto, foramdisponibilizados questionarios com perguntas direcionadas a arquitetura de software paravarios profissionais da area, distribuıdos em varios continentes. Eles conseguiram perce-

ber que a maioria das reunioes nao sao estruturadas; poucas equipes envolvem clientes emembros de todos os nıveis da hierarquia da empresa; a homogeneidade dos integrantesdos grupos pode ocasionar polarizacao das ideias; e as restricoes de custo, tempo e dis-ponibilidade de mao de obra tem grande impacto na decisao final. Portanto, os resultadosevidenciam o quanto a escolha da arquitetura pode ser influenciada nao so pelos requisi-tos do software ou criterios de qualidade, mas tambem pelo processo para a escolha daarquitetura em si.

Tofan et al. (2013) conduziram um trabalho demonstrando as principais dificul-dades encontradas pelos arquitetos para tomar decisoes arquiteturais [Tofan et al. 2013].Eles fizeram uma pesquisa com 43 arquitetos que estao diretamente envolvidos no pro-cesso de decisao arquitetural, com diferentes nıveis de experiencia. Em media, cada de-cisao arquitetural envolve tres pessoas. Arquitetos juniores demoram cerca de um quartodo tempo dos seniores. Tambem e evidenciado que, apesar da importancia dos stakehol-ders na decisao arquitetural ser largamente difundida na literatura, eles nem sempre estaoenvolvidos indiretamente nesse processo. Os resultados desse trabalho corroboram com oque foi levantado por Muccini (2018) sobre a importancia do processo de decisao arqui-tetural, demonstrando que ele tambem deve ser levado em conta ao analisar a escolha demicrosservicos.

CITY et al. (2008) elaboraram em seu estudo o modelo de referencia de qualidadeS-Cube. Este modelo descreve diferentes atributos de qualidade de aplicativos baseadosem servicos. Ele foi construıdo baseando-se em importantes modelos de qualidade dacomputacao orientada a servicos, gerenciamento de processos de negocio, computacaoem grade e engenharia de software [CITY et al. 2008]. Esse modelo evidencia a grandequantidade de atributos que podem ser considerados em sistemas baseados em servicos.Ja Ameller et al. (2016) demonstram em seu trabalho o papel dos atributos de quali-dade em sistemas baseados em servicos (SBS) [Ameller et al. 2016]. Por meio de umapesquisa com arquitetos, desenvolvedores e praticantes de software que trabalham comSBS, eles identificaram que os participantes percebiam os requisitos funcionais e atri-butos de qualidade (AQ) igualmente importantes. Em contrapartida, no estudo de VanHeesch and Avgeriou (2010), 80% dos participantes percebiam os AQ como mais impor-tantes [Van Heesch and Avgeriou 2010]. Diversos AQ foram consideradas importantes,entretanto eles divergem de trabalho para trabalho, demonstrando a dificuldade em iden-tificar os criterios que sao considerados relevantes para a decisao de usar arquitetura demicrosservicos.

4. Materiais e Metodos

O estudo proposto neste trabalho envolveu uma analise quali-quantitativa, em que busca-se identificar e compreender os criterios e processos utilizados para a escolha da arqui-tetura de microsservicos. Propoe-se identificar os criterios que levam a adocao da arqui-tetura de microsservicos, a relevancia desses criterios e a influencia dos processos de es-colha da arquitetura na relevancia dos mesmos. Para isso, foi realizado um levantamentode atributos de qualidade que sao levados em consideracao na escolha da arquitetura desoftware. Posteriormente, esses atributos foram utilizados em um formulario de pesquisaonde os respondentes deveriam definir aquelas caracterısticas que eram consideradas re-levantes para a definicao da arquitetura de microsservicos.

4.1. Criterios para Composicao do Formulario de Pesquisa

Os criterios que fizeram parte do formulario foram escolhidos com base na norma ISO-25010:2011 onde sao detalhados atributos de qualidade de software [ISO and IEC 2011],em conjunto com o modelo de atributos de qualidade S-Cube, proposto por CITY[CITY et al. 2008]. A partir dessas duas bases, foi realizada uma identificacao deequivalencias entre os atributos apresentados por ambos, para eliminacao de possıveisredundancias. Essa equivalencia foi feita de acordo com a descricao de cada caracterısticanas duas fontes e, apos a juncao e eliminacao de duplicatas, chegou-se a 10 caracterısticasprincipais e 47 subcaracterısticas. A Tabela 1 apresenta o resultado obtido:

Tabela 1: Detalhamento de equivalencias entre caracterısticas da ISO 25010 e S-Cube

Detalhamento de equivalencias ISO 25010 e S-CubeCaracterıstica ISO 25010 S-Cube Descricao

Performance

Comportamentodo tempo

Tempo de resposta/ Tempo de transacao Referente ao tempo de processamento e resposta de uma requisicao

Uso de recursos Referente as quantidades e tipos de recursos utilizados durante a execucaoCapacidade Capacidade Referente aos limites maximos de solicitacoes simultaneas que o servico pode suportar

Taxa de transferencia O Numero de transacoes concluıdas durante um perıodo de tempo

Usabilidade

Capacidade dereconhecer adequacao Compreensibilidade Capacidade do servico/produto de permitir que o usuario entenda qual a adequacao

de suas funcionalidades e qual sua aplicacaoCapacidade deaprendizagem Aprendizagem Capacidade do produto/servico que permite ao usuario aprender como usa-lo

Capacidade de uso EficaciaCapacidade do produto/servico que permite ao usuario opera-lo facilmente,sendo capaz de acessar todos osseus recursos.

Protecao contraerros do usuario Capacidade do sistema de proteger os usuarios de cometer erros

Estetica da interfacedo usuario Satisfacao Capacidade do produto/sistema de satisfazer a interacao com o usuario

Acessibilidade Acessibilidadede conteudo

Capacidade do produto/servico que permite sua utilizacao por qualquer usuario,independente de suas limitacoes

Confiabilidade

Maturidade Acessibilidade Capacidade do sistema de atender as necessidades em condicoes normaisDisponibilidade Disponibilidade Disponibilidade do servico para estar acessıvel e operacional quando necessarioTolerancia ao erro Semantica de falha Capacidade do sistema de se manter operando mesmo na presenca de falhasRecuperabilidade Robustez/Flexibilidade Capacidade do sistema de retornar ao estado desejado em caso de interrupcao ou falhas

DisponibilidadeContınua

Ele avalia a probabilidade com que um cliente pode acessar um

servico um numero infinito de vezes durante um determinado momento

perıodo

EscalabilidadeO poder de aumentar a capacidade de computacao do sistema de computador doprovedor de servicos e a capacidade do sistema de processar mais operacoes outransacoes em um determinado perıodo

AcuraciaDefine a taxa de erro produzida pelo servico calculado em

a base dos resultados esperados

PortabilidadeAdaptabilidade Robustez/Flexibilidade Capacidade do sistema de se adaptar a diferentes contextos, seja de preferencias

de usuario, hardware, ambientes operacionais, software, etc.Capacidade deinstalacao

Facilidade com que o produto pode ser instalado e / ou desinstalado com sucessoem um determinado ambiente

Capacidade de sersubstituıdo

Capacidade do produto ser usado no lugar de outro produto de software especıficopara a mesma finalidade e no mesmo ambiente

Manutenibilidade

Modularidade Capacidade de um sistema que permite uma mudanca em um componentecom impacto mınimo sobre outros.

Reutilizacao Capacidade de um ativo que permite sua utilizacao em mais de um sistema de softwareou na construcao de outros ativos

AnalisabilidadeFacilidade com a qual o impacto de uma determinada mudanca no restante do softwarepode ser avaliado, as deficiencias ou causas de falhas no software podem ser diagnosticadasou as partes a serem modificadas podem ser identificadas

Modificabilidade Capacidade do produto que permite que ele seja modificado de forma eficaz e eficiente,sem introduzir defeitos ou degradar o desempenho

TestabilidadeA facilidade com que os criterios de teste podem ser estabelecidos para um sistemaou componente e com os quais os testes podem ser realizados para determinar seesses criterios sao atendidos

Compatibilidade CoexistenciaCapacidade do produto de coexistir com outro softwareindependente, em um ambiente comum, compartilhando recursoscomuns sem prejuızo

Interoperabilidade A capacidade de dois ou mais sistemas oucomponentes de trocar informacoes e usar as informacoes trocadas

AdequacaoFuncional

Completudefuncional Completude O grau em que o conjunto de funcionalidades

cobre todas as tarefas e objetivos do usuario especificadosCorrecaofuncional Precisao Capacidade do produto ou sistema de fornecer

resultados corretos com o nıvel de precisao necessarioRelevanciafuncional

Capacidade do produto de software de fornecer umconjunto apropriado de funcoes para tarefas e objetivos especıficos do usuario

Atualidade Descreve a epoca das informacoes de contexto

Cobertura A quantidade de contexto potencialmente detectado sobre o qualinformacao e entregue

Dignidade de confianca A confiabilidade tambem descreve o quao a informacao fornecida esta corretaResolucao Resolucao denota a granularidade das informacoes

Seguranca

Confidencialidade Confidencialidade Capacidade de protecao contra acesso nao autorizado a dados e informacoes, sejaacidental ou deliberadamente

Integridade Integridade Capacidade do sistema ou componente de impedir o acesso naoautorizado ou modificacoes nos dados ou programas de computador

Nao repudiacao Nao repudiacao Capacidade de demonstrar as acoes ou eventos que ocorreram,de forma que tais acoes ou eventos nao possam ser repudiados posteriormente

Responsabilidade Rastreabilidade/Auditabilidade

Capacidade de rastrear inequivocamente as acoes de umaentidade

Autenticidade Autorizacao/Autenticacao Capacidade de comprovar a identidade de um sujeito ou recurso

Criptografia de dados Refere-se aos algoritmos adotados para protecao dos dados de acessos maliciososPrestacao de contas Responsabilidade a ser chamado a prestar contas

Configuracao eGerenciamento

Estabilidade Uma medida da frequencia de mudanca relacionada ao servicoem termos de sua interface e / ou implementacao

Reputacao A reputacao de um provedor e uma medida de sua confiabilidade. Depende principalmente daexperiencia do usuario final ao usar o servico do provedor

Nıvel de Servico E definido como o tipo de compromisso de QoS dado ao aplicativo ou usuario

CustosCustos Variaveis Custos que podem sofrer variacoes durante a prestacao de um servicoModelo de custos Define um conjunto de funcoes que transformam recursos (servicos) em custosCustos Fixos Custos que se manterao fixos durante a prestacao de um servico

Fonte: Adaptado da ISO-25010:2011 e [CITY et al. 2008]

4.2. Elaboracao e Distribuicao do FormularioPara a realizacao do estudo foi elaborado um questionario online por meio da ferramentaGoogle Forms, sendo distribuıdo para participantes que atuam no mercado de desenvol-vimento de software na regiao metropolitana de Belo Horizonte/MG. Seu proposito eraobter os criterios que sao considerados relevantes e propiciar sua classificacao ordinal,bem como identificar como e realizado o processo de tomada de decisao arquitetural nocontexto dos respondentes. O formulario possui ao todo 24 secoes. A secao 1 tem o obje-tivo de apresentar uma introducao ao trabalho e ao formulario; a secao 2 visa identificar efiltrar os respondentes; a secao 3 aborda os processos de tomada de decisao arquitetural;por fim, as secoes 4 a 24 tratam dos criterios a serem analisados .

Na secao 2, intitulada Identificacao, foram apresentadas perguntas relacionadas aexperiencia profissional do respondente como tempo de experiencia, area de atuacao eespecializacoes. A depender de suas respostas, o mesmo nao conseguia prosseguir paraas secoes posteriores e tinha o formulario encerrado. Essa decisao foi tomada porqueo respondente que nao possui nenhum tipo de experiencia com processos de tomada dedecisao arquitetural pode nao ter conhecimento necessario para entender e responder asperguntas do questionario.

A secao 3 do formulario foi elaborada com o objetivo de identificar os processos detomada de decisao arquitetural. Nela foram adicionadas perguntas sobre como e realizadoesse processo e sobre a maturidade de processos no ambiente de trabalho do respondente.Dessa forma, foi possıvel realizar uma analise posterior sobre a relacao entre o processode tomada de decisao arquitetural e a relevancia dos criterios definida pelo respondentenas secoes posteriores.

Nas secoes 4 a 24, foram apresentados os criterios identificados na etapa anteriorpara que o participante pudesse decidir se os mesmos eram relevantes e classificar suarelevancia. Estas secoes possuıam caracterısticas principais e subcaracterısticas, sendotrabalhadas de forma que nem sempre seria necessario responder todas as perguntas. Casouma caracterıstica principal fosse marcada como nao relevante, automaticamente suassubcaracterısticas eram consideradas como nao relevantes. Caso contrario, era exibidauma nova secao para classificacao das subcaracterısticas em uma escala Likert de 1 a 5,sendo possıvel ainda selecionar a opcao ”Nao e importante”.

4.3. Metodos e tecnicas estatısticosOptou-se por aplicar a analise de correlacao estatıstica, que serve para estabelecer relacoesentre variaveis em estudo. Neste sentido, foram analisados alguns softwares com amplaaplicacao na area de Estatıstica e Probabilidades, tais como: Orange, Statistica, SPSS eR1. Por fim, optou-se por utilizar o software R, por ser gratuito, de utilizacao intuitivae possuir ampla documentacao. Trata-se de um software livre para analise de dados,sendo extremamente poderoso e versatil para analise estatıstica e construcao de graficos[Landeiro 2011].

Os dados coletados, foram submetidos ao software R, com o objetivo de identificarcorrelacoes estatısticas entre os dados da pesquisa: os requisitos arquiteturais, o processode tomada de decisao e as outras perguntas do questionario. A ferramenta tambem foiutilizada para gerar graficos, visando auxiliar na identificacao das possıveis correlacoes.Posteriormente, foi realizada a analise desses resultados em conjunto com as medias ob-tidas para os criterios. Para que fosse possıvel realizar a analise de correlacao estatıstica,as variaveis qualitativas como foram convertidas em quantitativas de forma direta, numaescala ordinal.

5. Apresentacao dos ResultadosApos a distribuicao do formulario, foram obtidas 53 respostas. Desse total, 37 responden-tes passaram pelo filtro realizado na secao 2 e responderam as secoes 3 a 24. Entretanto,visando uma maior confiabilidade dos dados, foram retirados da amostra os participantesque responderam nunca ter participado de um projeto com arquitetura de microsservicosna secao 2. Dessa forma, restaram 30 respostas para serem analisadas.

A analise das respostas foi dividida em duas etapas, sendo a primeira etapa umaclassificacao dos criterios atraves da media aritmetica das respostas e a segunda umaanalise da relacao entre o processo de tomada de decisao e a avaliacao dos criterios. Estaultima estapa foi realizada com o auxılio da matriz de correlacao gerada no software R.

5.1. Classificacao das CaracterısticasPara realizar a classificacao das caracterısticas e subcaracterısticas foi utilizada a mediaaritmetica com base na avaliacao dos respondentes. A media de cada subcaracterıstica foicalculada atraves da avaliacao de cada respondente, ja a media da caracterıstica pai foicalculada com base na media de suas caracterısticas filhas. Por exemplo, para definir arelevancia da caracterıstica Performance foram calculadas as medias de cada um de suassubcaracterısticas, depois foi definida a relevancia da Performance atraves da media desuas subcaracterısticas.

Para o calculo da media de cada subcaracterıstica foram utilizadas apenas as res-postas onde os respondentes consideraram o criterio pai relevante, ou seja, a media foicalculada somente para respostas em que foi atribuıdo ”Sim”na avaliacao do criterio pai.Essa analise foi realizada para avaliar qual a relevancia dos criterios para as pessoas queos consideram importantes na arquitetura de microsservicos. Por exemplo, para um casohipotetico em que 5 respondentes consideraram a caracterıstica Confiabilidade importantee avaliaram suas subcaracterısticas e 3 respondentes nao consideraram esse criterio im-portante e, consequentemente, nao avaliaram suas subcaracterısticas. Para aqueles que

1Todos esses softwares sao marcas registradas de seus fabricantes.

responderam que Confiabilidade nao e importante, nao foi atribuıda nota 0 para as sub-caracterısticas; eles foram simplesmente desconsiderados no calculo, pois nao e possıvelinferir uma nota sendo que o respondente nao teve conhecimento das subcaracterısticas.Dessa forma, a media foi calculada considerando as 5 respostas em que os participantesresponderam ”Sim”na avaliacao da Confiabilidade.

Com base nessa analise, foram gerados graficos de barras que mostram os resulta-dos obtidos. A Tabela 2 apresenta os resultados obtidos para as caracterısticas e subcarac-terısticas, enquanto a Figura 2 apresenta o grafico com a media das caracterısticas baseadanas subcaracterısticas e a porcentagem de respostas, considerando cada criterio relevante.O levantamento da porcentagem de respostas ”Sim”e ”Nao”(Figura 2) na avaliacao darelevancia de cada criterio e importante porque como as respostas ”Nao”foram desconsi-deradas no calculo da media e necessario analisar tambem a quantidade de respondentesque nao consideraram os criterios relevantes.

Tabela 2. Avaliacao das SubcaracterısticasAvaliacao Subcaracterısticas

Caracterıstica Relevancia Desvio Padrao Subcaracterıstica Relevancia Desvio Padrao

Portabilidade 3,71 0,04Adaptabilidade 3,65 1,20

Capacidade de ser substituıdo 3,74 1,26Capacidade de instalacao 3,74 1,30

Custos 3,91 0,22Custos Variaveis 3,7 1,24

Custos Fixos 3,81 1,31Modelo de Custos 4,22 0,79

Usabilidade 4,02 0,36

Acessibilidade 3,32 1,43Protecao contra erros do usuario 3,96 1,15

Aprendizagem 4,04 1,15Compreensibilidade 4,04 1,15

Satisfacao 4,28 1,08Eficacia 4,48 0,75

Adequacao Funcional 4,05 0,50

Atualidade 3,19 1,54Cobertura 3,18 1,32Resolucao 4,00 1,12

Completude Funcional 4,11 0,92Relevancia Funcional 4,44 0,83

Precisao Funcional 4,48 0,74Confianca 4,63 0,67

Configuracao e Gerenciamento 4,08 0,14Reputacao 3,88 1,15

Estabilidade 4,15 0,91Nıvel de Servico 4,19 0,62

Performance 4,19 0,19

Taxa de Transferencia 3,9 0,92Utilizacao de Recursos 4,21 0,85

Capacidade 4,24 0,90Tempo de Resposta 4,41 0,77

Seguranca 4,32 0,41

Prestacao de Contas 3,68 1,34Nao Repudiacao 3,96 1,02

Criptografia de Dados 4,04 1,24Responsabilidade 4,29 0,84Confidencialidade 4,71 0,84

Autenticidade 4,75 0,51Integridade 4,79 0,77

Manutenibilidade 4,41 0,22

Analisabilidade 4,17 0,91Testabilidade 4,21 1,03Reutilizacao 4,41 0,97

Modificabilidade 4,48 0,81Modularidade 4,79 0,61

Confiabilidade 4,44 0,33

Acuracia 3,79 1,00Recuperabilidade 4,34 0,66

Tolerancia a Falhas 4,45 0,72Maturidade 4,55 0,89

Escalabilidade 4,66 0,80Disponibilidade 4,86 0,34

Compatibilidade 4,46 0,07 Coexistencia 4,39 0,64Interoperabilidade 4,52 0,50

Fonte: Os proprios autores

Figura 2. Avaliacao das Caracterısticas Pai e Caracterıstica Relevante/Nao rele-vante. Fonte: dados da pesquisa

5.2. Influencia do processo de tomada de decisao na relevancia dos criterios

Para a analise da influencia do processo de tomada de decisao arquitetural sobre os re-quisitos, como proposto neste trabalho, foi criada a matriz de correlacao de Pearson.Utilizou-se as perguntas relacionadas ao processo e a media das caracterısticas pai a partirdos dados obtidos no questionario. O calculo da media de cada caracterıstica foi realizadoda mesma forma que na Secao 5.1, porem de forma individual para cada respondente. Pri-meiramente, foi realizada uma analise geral, contendo todas as respostas relacionadas aoprocesso de tomada de decisao arquitetural, com excecao das respostas em que o parti-cipante descrevia o processo de forma aberta, pois estas foram utilizadas posteriormentepara analises mais especıficas.

Alem da analise de correlacao geral, foi realizada uma filtragem e agrupamentodos dados dos processos que possuem semelhanca entre si, para possibilitar o estabeleci-mento de uma correlacao entre o processo e a relevancia dos criterios. Por exemplo, asrespostas onde os respondentes afirmaram que o cliente ou seu representante participavadiretamente ou indiretamente do processo foram colocadas no agrupamento ”Participacaode Clientes”. A partir deste grupo, foi feita uma nova analise da relevancia dos criterios.

Foram realizados tres agrupamentos de dados para a utilizacao da analise decorrelacao. O primeiro agrupamento foi ”Atuacao Como Arquiteto de software”, sendo”Sim”, para quando o respondente informou que atua como Arquiteto de software e”Nao”para quando ele informou que atua em qualquer outra funcao. O segundo agru-pamento foi ”Processos Revisados”, sendo realizado a partir da descricao do processo detomada de decisao arquitetural. Para definir esse agrupamento, foi realizada uma analiseda resposta de cada participante. Assim foi possıvel identificar se o processo de tomadade decisao possuıa algum tipo de revisao, sendo marcado ”Sim”nesse caso, enquanto parao restante foi marcado ”Nao”. O terceiro e ultimo agrupamento foi o de ”Participacaodo cliente”e para sua idealizacao foram seguidos os mesmos criterios do agrupamento”Processos Revisados”.

As figuras 3 e 4 ilustram as analises da correlacao de Pearson das caracterısticase do processo de tomada de decisao, obtido no software R. A correlacao e um numeroque varia de -1 a +1, sendo interpretado assim: correlacao positiva para valores proximosde 1 indica que as variaveis mudam na mesma direcao; correlacao negativa para valoresproximos de -1 mostra que as variaveis mudam em direcoes opostas; correlacao nula ouvalores proximos de 0, nao ha relacao na mudanca das variaveis [Rocha 2018].

A Figura 3 representa a matriz de correlacao entre o processo de tomada de de-cisao arquitetural e a media das caracterısticas. A Figura 4, por sua vez, apresenta acorrelacao entre a media das caracterısticas e os agrupamentos de processos especıficos,como mostrado anteriormente.

Figura 3. Matriz Correlacao - Geral. Fonte: dados da pesquisa.

Figura 4. Matriz Correlacao - Agrupamentos Especıficos.Fonte: dados da pes-quisa.

5.2.1. Tipos de Processo de Tomada de Decisao

Nesta secao foram analisados os tipos de processo de tomada de decisao aplicados nasempresas onde os respondentes trabalham. Para isso, houve uma separacao das respostasem que foi informado se as empresas aplicam processos estruturados, nao estruturados ouambos os tipos de processos. A partir dessa separacao realizou-se uma nova analise darelevancia dos criterios para cada grupo, com excecao do grupo de processos estruturados,pois o numero de empresas que aplicam esse tipo de processo foi de apenas 3.A escassezde dados, neste caso, nao permite realizar uma analise confiavel. Desta forma, a novaanalise foi realizada para processos nao estruturados e para ambos os processos.

A partir da matriz de correlacao obtida na Figura 3 consegue-se percebercorrelacoes entre o tipo de processo de decisao e a media das caracterısticas, tanto posi-tivas quanto negativas. A Figura 5 apresenta a relevancia das caracterısticas para quandoas empresas aplicam processos nao estruturados e ambos os processos.

Figura 5. Media Caracterısticas - Processo Nao Estruturado e Ambos os Tiposde Processo. Fonte: dados da pesquisa.

A partir dos graficos obtidos, foi possıvel perceber que, em comparacao coma analise geral, processos nao estruturados mantiveram compatibilidade como a carac-terıstica mais importante, performance, que subiu 2 posicoes no ranking enquanto ma-nutenibilidade caiu para quarto lugar. Em contrapartida, quando a empresa aplica ambosos processos, manutenibilidade se tornou a caracterıstica mais relevante. Entretanto, as3 caracterısticas mais relevantes; confiabilidade, compatibilidade e manutenibilidade semantiveram as mesmas.

Tambem foram analisados processos em que a tomada de decisao arquiteturalpassa por algum tipo de validacao ou acompanhamento de pessoas que nao estao direta-mente envolvidas na concepcao do projeto. Considerou-se que nesta situacao o processoe revisado, pois nele geralmente a equipe de projeto de software desenha uma solucaoarquitetural para um problema e realiza uma validacao com arquitetos ou equipes ex-perientes. Dessa forma, torna-se possıvel validar se a arquitetura proposta e a ideal ouconceber uma nova solucao mais adequada. A Figura 4 apresenta a matriz de correlacao

contendo os processos revisados, ja a Figura 6 apresenta a relevancia das caracterısticaspara os mesmos.

Figura 6. Caracterısticas - Processo Revisado. Fonte: dados da pesquisa.

Na Figura 4 e possıvel perceber que existe pouca correlacao entre o processo dedecisao arquitetural revisado e a relevancia dos criterios, com destaque para performance,que tem correlacao levemente positiva. Ja o grafico da Figura 6 mostra que embora tenhaocorrido alteracao na ordem de relevancia, compatibilidade, manutenibilidade e confiabi-lidade se mantiveram no topo do ranking. Isto pode ter ocorrido devido a revisao atacarjustamente esses pontos, para que a solucao proposta seja a melhor possıvel para atendera demanda.

5.2.2. Participacao do Cliente

A figura 7 apresenta a relevancia das caracterısticas para os casos em que os clientes saoenvolvidos.

Figura 7. Caracterısticas - Participacao de Cliente. Fonte: dados da pesquisa

Para os processos onde os clientes ou seus representantes participam, compatibi-lidade, confiabilidade e adequacao funcional se mostraram mais importantes. Em todosos processos onde foram envolvidos clientes, esses requisitos possuem grande peso paraa escolha da arquitetura. Neste caso, os arquitetos apresentam as possıveis solucoes e osclientes decidem qual sera utilizada. A caracterıstica de custo se manteve nas posicoesmais baixas, podendo-se inferir que apesar dele possuir peso para a escolha da arquitetura,atender aos requisitos do cliente tambem e importante.

Na matriz de correlacao dos agrupamentos (Figura 4), pode-se perceber umacorrelacao negativa entre os processos onde clientes participam e as caracterısticas deconfiguracao e gerenciamento, e manutenibilidade. Isso tambem pode ser evidenciado noranqueamento dessas caracterısticas, onde respectivamente, um e o penultimo e o outroperde posicoes em contraste com outros agrupamentos.

5.2.3. Arquitetos de software

A Figura 8 apresenta a relevancia das caracterısticas para os respondentes que atuamdiretamente como arquitetos de software.

Figura 8. Caracterısticas - Arquitetos de Software. Fonte: dados da pesquisa.

Pela perspectiva de arquitetos de software, manutenibilidade, confiabilidadee seguranca sao as caracterısticas que possuem maior impacto para a escolha demicrosservicos. Os processos descritos por esses arquitetos possuem uma riqueza maiorde detalhes, em comparacao com outras areas de atuacao, possuindo muitas semelhancasentre eles, como a participacao de outros arquitetos ou equipes multidisciplinares e a im-portancia dada para os requisitos funcionais na a solucao final.

Isso pode ter refletido na escolha das caracterısticas de manutenibilidade e con-fiabilidade com as maiores notas, evidenciando uma preocupacao com a longevidade doproduto e se ele soluciona de fato o problema do cliente. A matriz de correlacao corro-bora com o argumento, com ambas caracterısticas possuindo correlacao moderada posi-tiva com arquitetos de software.

Outro fator importante a ressaltar sao os custos, sendo classificado como impor-tante para todos os arquitetos em microsservicos; observa-se correlacao negativa entrearquitetos e a caracterıstica de compatibilidade .

5.3. Discussao dos ResultadosEntender como os criterios sao percebidos pelas equipes de tomada de decisao arquite-tural e quais deles sao considerados relevantes em comparacao a outros, pode fornecerinformacoes valiosas para as equipes basearem sua decisao na escolha da arquitetura demicrosservicos. O estudo realizado fez uma analise da relevancia dos criterios definidosnas normas e modelos adotados e como esses podem vir a ser influenciados de acordocom a forma como ocorre o processo de tomada de decisao arquitetural.

Com os resultados obtidos, pode-se perceber que apesar de todos esses criteriosserem importantes para a arquitetura de microsservicos, alguns se destacam por seremo ponto forte no qual a arquitetura de microsservicos se sobressai. Compatibilidade de-monstrou ser o mais importante dentre eles, seguido por confiabilidade e manutenibili-dade. E importante ressaltar que a diferenca entre esses criterios e pequena, tornando-semaior quando comparado com os criterios menos relevantes.

Atraves das medias das subcaracterısticas, foi possıvel perceber quais delas pos-suem maior relevancia em cada caracterıstica. Na caracterıstica confiabilidade, por exem-plo, a subcaracterıstica disponibilidade obteve a nota mais alta (4,86), em contraste comacuracia, que obteve a menor nota (3,79). Com isso, fica evidente como a disponibilidadee crucial para microsservicos, em contrapartida com a acuracia, que e necessaria, masnao possui tanto peso na decisao final. Lembrando que esta analise foi feita considerandosistemas no geral. Em alguns casos especıficos, nao necessariamente disponibilidade emais importante que acuracia.

Outra observacao que pode ser realizada a partir dos dados da pesquisa e que,apesar de alguns criterios possuırem nota media alta, a quantidade de pessoas que osconsideram relevantes e menor em comparacao a outros. Isto e, seus subcriterios possuemboas notas, mas sua relevancia no geral pode nao ser tao alta quanto as medias refletirampois houveram muitas respostas ”Nao”na avaliacao do criterio. Pode-se observar isso nocaso de compatibilidade, que lidera o ranking de notas medias, porem aparece em ultimo,juntamente com portabilidade, nos criterios considerados relevantes para a escolha daarquitetura de microsservicos. Ou seja, quando compatibilidade e considerada importantepelo respondente, ela possui uma relevancia muito alta, porem para muitos participantesa mesma nao e importante.

Analisando se o processo de tomada de decisao arquitetural e capaz de interferir narelevancia dos criterios foi possıvel perceber que o mesmo possui influencia significativana classificacao. Em processos que aparentam ter uma estrutura mais madura ou quepassam por uma especie de revisao, foi notado que atributos mais voltados para qualidadede codigo e robustez do sistema tiveram um aumento em sua relevancia, estando presentesnas primeiras posicoes de prioridade. Em contrapartida, compatibilidade caiu algumasposicoes no ranking. Este era um resultado esperado, visto que microsservicos devemoperar de forma individual e isolada, nao havendo grande necessidade de compatibilidade,enquanto que buscam alcancar maior qualidade de codigo e maior robustez.

Com a analise da matriz de correlacao de Pearson foi possıvel identificar conexoes

entre os criterios. Alguns se correlacionam fortemente entre si, como manutenibilidade,usabilidade e confiabilidade, em contraste com outros inversamente relacionados, comoperformance e portabilidade. Percebe-se tambem a mesma correlacao entre o processo detomada de decisao e os criterios, como por exemplo os processos onde clientes participam,possuindo correlacao negativa com o criterio de configuracao e gerenciamento.

Dessa forma, e possıvel afirmar que, na amostra analisada, existe uma influenciaforte dos processos sobre os criterios para a arquitetura de microsservicos. As equipesresponsaveis pela escolha da arquitetura devem ter um cuidado especial para a formacomo esses processos ocorrem, quais pessoas participam, a diversidade de conhecimentodos membros da equipe e outros fatores que podem influenciar diretamente na escolha demicrosservicos.

6. Consideracoes finais e Direcoes futuras

Neste trabalho buscou-se identificar e classificar os criterios que sao mais relevantes paraa escolha da arquitetura de microsservicos. Alem disso, tambem foi realizada uma analiseda influencia do processo de tomada de decisao arquitetural na relevancia desses criterios.Realizou-se uma pesquisa com diversos respondentes que atuam no mercado de TI emBelo Horizonte/MG, com a qual foi possıvel realizar a analise dos dados coletados.

Atraves da analise dos resultados foi possıvel perceber que alguns criterios saomais relevantes em relacao a outros, para a adocao da arquitetura de microsservicos. Ealguns desses criterios, como manutenibilidade e compatibilidade, sao relatados na lite-ratura como pontos fortes em que microsservicos conseguem se sobressair em relacaoa outras arquiteturas, sendo esses criterios bem ranqueados nesse estudo. Tambem foipossıvel perceber que existe influencia do processo de tomada de decisao arquitetural narelevancia dos criterios.

Para trabalhos futuros, sugere-se realizar uma pesquisa com foco sobre a formacomo ocorrem os processos de tomada de decisao e com uma maior diversificacao ge-ografica. Tambem e possıvel realizar trabalhos com maior enfase nas subcaracterısticaslevantadas neste artigo, que podera ensejar diversas novas analises. Outra possibilidade aexplorar e especializar o levantamento de dados, visando identificar situacoes especıficasde cada nicho de negocio, tipo de empresa, dentre outros. Dessa forma, sera possıvel terresultados mais confiaveis e aplicaveis a situacoes reais.

Referencias

Ameller, D., Ayala, C., Cabot, J., and Franch, X. (2013). Non-functional requirements inarchitectural decision making. IEEE Software, 30(2):61–67.

Ameller, D., Galster, M., Avgeriou, P., and Franch, X. (2016). A survey on quality attri-butes in service-based systems. Software quality journal, 24(2):271–299.

Brooks, F. and Kugler, H. (1987). No silver bullet. April.

Bucchiarone, A., Soysal, K., and Guidi, C. (2019). A model-driven approach towards au-tomatic migration to microservices. International Workshop on Software EngineeringAspects of Continuous Development and New Paradigms of Software Production andDeployment, pages 15–36.

CITY, C., Lero, P., SZTAKI, T., and UniDue, U. (2008). Quality reference model for sba.

Costa, A. C. L., Colanzi, T. E., Marcolino, A. S., and Barbosa, E. F. (2019). Microservice-oriented product line architecture design: An exploratory study. In Proceedings of theXIII Brazilian Symposium on Software Components, Architectures, and Reuse, pages113–122.

Candido, A. L., Rego, P. A. L., Trinta, F. A. M., C., M. N., Rocha, L. S., and Garcia,V. C. (2019). A microservice based architecture to support offloading in mobile cloudcomputing. Proceedings of the XIII Brazilian Symposium on Software Components,Architectures, and Reuse, pages 93–102.

De Lauretis, L. (2019). From monolithic architecture to microservices architecture. In2019 IEEE International Symposium on Software Reliability Engineering Workshops(ISSREW), pages 93–96.

Farshidi, S., Jansen, S., and Van Der Werf, J. M. (2020). Capturing software architectureknowledge for pattern-driven design. Journal of Systems and Software, 169:110714.

Fowler, M. and Lewis, J. (2014). Microservices. Disponıvel em:https://martinfowler.com/articles/microservices.html. Ultimo acesso em: 18 deoutubro de 2020.

Garlan, D. and Shaw, M. (1993). An introduction to software architecture. In Advancesin software engineering and knowledge engineering, pages 1–39. World Scientific.

ISO, I. O. S. and IEC, I. E. C. (2011). Iso/iec 25010:2011. 1:1–34.

Jansen, A. and Bosch, J. (2005). Software architecture as a set of architectural design de-cisions. In 5th Working IEEE/IFIP Conference on Software Architecture (WICSA’05),pages 109–120.

Khaleq, A. A. and Ra, I. (2019). Agnostic approach for microservices autoscaling in cloudapplications. 2019 International Conference on Computational Science and Computa-tional Intelligence (CSCI). IEEE, pages 1411–1415.

Kruchten, P. (2004a). An ontology of architectural design decisions in software intensivesystems. In 2nd Groningen workshop on software variability, pages 54–61. Citeseer.

Kruchten, P. (2004b). The rational unified process: an introduction. Addison-WesleyProfessional.

Kruchten, P., Capilla, R., and Duenas, J. C. (2009). The decision view’s role in softwarearchitecture practice. IEEE Software, 26(2):36–42.

Landeiro, V. L. (2011). Introducao ao uso do programa r. Manaus: Instituto Nacional dePesquisas da Amazonia.

Muccini, H. et al. (2018). Group decision-making in software architecture: A study onindustrial practices. Information and Software Technology, 101:51–63.

Petrasch, R. (2017). Model-based engineering for microservice architectures using en-terprise integration patterns for inter-service communication. 2017 14th InternationalJoint Conference on Computer Science and Software Engineering (JCSSE). IEEE, pa-ges 1–4.

RedHat (2021). Arquitetura de microsserviCos. Disponıvel em:https://www.redhat.com/pt-br/topics/microservices/what-are-microservices. Ultimoacesso em: 13 de maio de 2021.

Rocha, D. (2018). Sobre correlacoes e visualizacoes de matrizes de correlacao nor. Disponıvel em: https://rstudio-pubs-static.s3.amazonaws.com/437792_df39a5ff0a55491fb71f0f4a0f5cd0bf.html. Acesso em: 9 deMaio 2021.

Thones, J. (2015). Microservices. IEEE Software, 32(1):116–116.

Tofan, D., Galster, M., and Avgeriou, P. (2013). Difficulty of architectural decisions–asurvey with professional architects. In European Conference on Software Architecture,pages 192–199. Springer.

Van Heesch, U. and Avgeriou, P. (2010). Naive architecting-understanding the reasoningprocess of students. In European Conference on Software Architecture, pages 24–37.Springer.